Re: [PATCH v1 0/3] console, serial8250: Disable PM and DMA ops

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, 2018-05-16 at 12:47 +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-16 13:17:36 [+0300], Andy Shevchenko wrote:
> > > The output is usually short so there
> > > shouldn't be much benefit from using it.
> > > I remember Tony wanted runtime-pm on the kernel console, too. And
> > > he
> > > told me explicit how to test it so that it works. Once the UART
> > > goes
> > > into PM (down), the whole IP block can go into power save mode.
> > > The
> > > board can be woken up by sending a character via the UART. The
> > > first few
> > > (incoming / read) characters are lost until the IP block is up
> > > again the
> > > frequency stable. This is known / expected.
> > 
> > Don't consider world the OMAP only. The things more complicated if
> > we
> > go out of it. Which I tried to explain in the commit message of
> > patch
> > 2.
> 
> I am not saying the world is OMAP only. I just tried to explain how
> any
> why it got there and its purpose. I haven't NACKed it. I would believe
> that with that information and Tony not defending his use case or
> possible change it somehow so it is not standing in your way, Greg
> would
> have enough information to go your way.

Yes, I got it.

> But since I am on it. You have to enable runtime-PM for the UART. So
> what is the problem if you simply don't enable it for the UART which
> used as the kernel console?

How do I know at the ->probe() time that device in question is going to
be kernel console? Maybe I missed simple way of it.

> From reading the description of #2, my understanding is that you are
> afraid that enabling the UART (bringing it from power-down mode) might
> take too long because it requires (or might require) an ACPI function
> call. This brings me again to: why bother and enable it in the first
> place? Because this might not work from NMI context.

> From looking at #2. You remove put/get in console_write()

...which must be removed in any case...

>  and avoid
> runtime PM by pm_runtime_get_noresume() and need the extra hook on
> console exit. I wasn't aware that you can remove the console at
> runtime
> (and assumed you have to stick to what said in console= at bootime).

> Because if that is the case, you could simply strip UART_CAP_RPM and
> then there is no more runtime-PM for you. Or is it too simple and I
> miss something here?

See above question. IIRC it's either too early or too late to decide on
per port basis.

> 
> > > In order to achieve the same thing you would have to disable the
> > > kernel
> > > console on that UART. I leave this to Tony.
> > 
> > Precisely the point of the series.

Besides above this would be needed _at least_ for several 8250 glue
drivers, so, I decide to go once for all.

> 
> Sebastian

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy