Re: [PATCH v1 2/2] drm/tegra: Support disabled CONFIG_PM

[Dmitry Osipenko]

On 15.12.2017 00:41, Lucas Stach wrote:
> Am Montag, den 11.12.2017, 18:26 +0300 schrieb Dmitry Osipenko:
>> On 11.12.2017 17:27, Thierry Reding wrote:
>>> On Mon, Dec 11, 2017 at 04:53:56PM +0300, Dmitry Osipenko wrote:
>>>> On 11.12.2017 13:13, Thierry Reding wrote:
>>>>> On Mon, Dec 11, 2017 at 02:19:44AM +0300, Dmitry Osipenko
>>>>> wrote:
>>>>>> Add manual HW power management to drivers probe/remove in
>>>>>> order to
>>>>>> not fail in a case of runtime power management being disabled
>>>>>> in kernel
>>>>>> config.
>>>>>>
>>>>>> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx>
>>>>>> ---
>>>>>>  drivers/gpu/drm/tegra/dc.c   | 164
>>>>>> +++++++++++++++++++++++++++----------------
>>>>>>  drivers/gpu/drm/tegra/dsi.c  | 138 +++++++++++++++++++++--
>>>>>> -------------
>>>>>>  drivers/gpu/drm/tegra/hdmi.c |  90 ++++++++++++++++--------
>>>>>>  drivers/gpu/drm/tegra/sor.c  | 103 +++++++++++++++++------
>>>>>> ----
>>>>>>  4 files changed, 310 insertions(+), 185 deletions(-)
>>>>>
>>>>> I think that's the wrong way around. We unconditionally select
>>>>> PM on
>>>>> 64-bit ARM already, and I think we should do the same on 32-bit 
>>>>> ARM.
>>>>> There's really no excuse not to enable runtime PM these days.
>>>>
>>>> What is the rational behind enabling PM unconditionally? It is
>>>> actually a very
>>>> useful debug feature when there is something wrong with the PM.
>>>> It looks like
>>>> Tegra DRM driver is the only driver on Tegra that doesn't work
>>>> properly with PM
>>>> being disabled. Please, let's just fix it.
>>>
>>> What's useful about disabling PM? The problem with allowing !PM is
>>> that
>>> it adds one more combination that needs to be build- and runtime
>>> tested.
>>
>> As I already stated, disabling PM is very useful for debugging when
>> system hangs
>> unexpectedly. I found it very helpful several times.
> 
> This assumes that the bootloader/firmware left the power domains
> powered up. Without PM_GENERIC_DOMAINS, which depends on CONFIG_PM the
> kernel has no means to control the state of the power domains. Probe
> deferral based on the power domain will also not work, so driver may
> probe and try to access power-gated devices, leading to system hangs in
> the common case.

BTW, this probably explains why ARM64 has CONFIG_PM enabled, thanks.