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

[Andy Shevchenko]

On Thu, May 17, 2018 at 10:30 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * Andy Shevchenko <andy.shevchenko@xxxxxxxxx> [180517 16:41]:
>> On Thu, May 17, 2018 at 4:56 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
>> > * Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> [180516 13:12]:
>> >> On Wed, 2018-05-16 at 12:47 +0200, Sebastian Andrzej Siewior wrote:
>> >> > 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.
>> >
>> > Hmm parse the kernel cmdline maybe? :)
>> >
>> > BTW, kernel already has earlycon doing exactly what you're trying to do.
>>
>> I'm sorry, I didn't follow. What exactly earlycon does?
>
> It provides a console very early on, see earlycon in
> Documentation/admin-guide/kernel-parameters.txt

Yes, but what we are talking is to put the kernel console out of power
management due to _real_ issues with it.

>> The problem is in 8250 driver. The issue with runtime PM used in atomic context.
>
> So how about add some "noidle" kernel command line parameter for console
> that calls
> pm_runtime_forbid() and then you have the UART permanently
> on.

IIUC _forbid() can be overwritten via sysfs.
And I would prefer to do other way around, something like console.idle
and put default for OMAP to yes and no for everything else.

> Hmm I guess you could make also serial8250_rpm_get() do nothing
> based on that.

Have you seen entire series which I keep here:
https://bitbucket.org/andy-shev/linux/branch/topic/uart/rpm?
Among other things it gets rid of those specific callbacks entirely.

> I do agree the serial runtime PM has an issue if it depends on
> pm_runtime_irq_safe() being set.

It's more than an issue. The  so called "support" of RPM for UART is
_based on the hack_.
I would love to NAK that in the first place if I would have known of it in time.

>> So, I can, of course just remove callbacks from the console ->write().
>> Though it will prevent to use kernel console anyway.
>
> Please et's not start breaking things, we already see a constant
> flow of regressions on weekly basis.

Now we are stick with a hack and the case based on that is against
fixing things.
This is how it looks from my side.

-- 
With Best Regards,
Andy Shevchenko