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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux