[Openpvrsgx-devgroup] [Letux-kernel] letux v5.4 + suspend

H. Nikolaus Schaller hns at goldelico.com
Sun Dec 1 19:46:46 CET 2019


Hi,

> Am 01.12.2019 um 19:33 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Wed, 27 Nov 2019 22:05:12 +0100
> Andreas Kemnade <andreas at kemnade.info> wrote:
> 
>> On Wed, 27 Nov 2019 21:49:16 +0100
>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> 
>>>> Am 27.11.2019 um 21:38 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>>> 
>>>> Hi,
>>>> 
>>>> On Tue, 26 Nov 2019 23:01:08 +0100
>>>> Andreas Kemnade <andreas at kemnade.info> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> while I get down to the typical 26mA idle current on GTA04A5, I do not
>>>>> wake up from suspend there. 
>>>>> Not investigated yet.
>>>>> 
>>>> Played around on the letux3704:
>>>> 
>>>> init=/bin/bash
>>>> mounting sysfs, proc
>>>> /etc/rcS.d/udev start
>>>> 
>>>> and then doing rtcwake -s 20 -m mem
>>>> does not wake up
>>>> 
>>>> rm -rf /lib/modules/5.4.0-letux+/kernel/drivers/gpu/drm/pvrsgx
>>>> 
>>>> fixes the issue.    
>>> 
>>> Important finding. So this means the SGX driver stops wakeup from suspend?
>>> I have added Tony and the openpvrsgx mailing list.
>>> 
>>> For more dynamic tests you could
>>> * boot
>>> * lsmod | grep pvrsgx
>>> * echo blacklist pvrsrvkm_driver_name >/etc/modprobe.d/pvr.conf
>>> * reboot
>>> * modprobe pvrsrvkm_driver_name to see what it does influence
>>> 
>> well, no_console_suspend gives more interesting results:
>> [  296.323822] Freezing user space processes ... (elapsed 0.001 seconds) done.
>> [  296.342559] OOM killer disabled.
>> [  296.350738] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>> [  296.374755] dmtimer posted=0
>> [  296.456512] wwan_on_off_suspend: WWAN suspend
>> [  296.473388] ------------[ cut here ]------------
>> [  296.478881] WARNING: CPU: 0 PID: 1410 at drivers/gpu/drm/drm_modeset_lock.c:266 modeset_lock+0xc8/0xf4 [drm]
>> [  296.489410] Modules linked in: omapdrm libertas_sdio libertas cfg80211 snd_soc_simple_card snd_soc_simple_card_utils snd_soc_omap_twl4030 wwan_on_off panel_simple encoder_opa362 pvrsrvkmy
>> [  296.575866] CPU: 0 PID: 1410 Comm: rtcwake Not tainted 5.4.0-letux+ #3
>> [  296.582794] Hardware name: Generic OMAP36xx (Flattened Device Tree)
>> [  296.589508] [<c010fe8c>] (unwind_backtrace) from [<c010b28c>] (show_stack+0x10/0x14)
>> [  296.597717] [<c010b28c>] (show_stack) from [<c07ca8d0>] (dump_stack+0x88/0xa8)
>> [  296.605407] [<c07ca8d0>] (dump_stack) from [<c013130c>] (__warn+0xcc/0xe8)
>> [  296.612701] [<c013130c>] (__warn) from [<c01316c8>] (warn_slowpath_fmt+0x74/0xa0)
>> [  296.621002] [<c01316c8>] (warn_slowpath_fmt) from [<bf03d2b0>] (modeset_lock+0xc8/0xf4 [drm])
> 
> shouln't we initialie the mutex there by calling drm_mode_config_init()?
> Seems we do not do that and then using an unitialized mutex here.

Could at least be a reason for the suspend problem.

> 
>> [  296.630706] [<bf03d2b0>] (modeset_lock [drm]) from [<bf03d370>] (drm_modeset_lock_all_ctx+0x14/0xb4 [drm])
>> [  296.641540] [<bf03d370>] (drm_modeset_lock_all_ctx [drm]) from [<bf280d54>] (drm_atomic_helper_suspend+0x34/0xc8 [drm_kms_helper])
>> [  296.654357] [<bf280d54>] (drm_atomic_helper_suspend [drm_kms_helper]) from [<bf28406c>] (drm_mode_config_helper_suspend+0x28/0x5c [drm_kms_helper])
>> [  296.669006] [<bf28406c>] (drm_mode_config_helper_suspend [drm_kms_helper]) from [<bf2d4a50>] (pvr_suspend+0x18/0x48 [pvrsrvkm_omap3630_sgx530_125])
>> [  296.683349] [<bf2d4a50>] (pvr_suspend [pvrsrvkm_omap3630_sgx530_125]) from [<c0539380>] (dpm_run_callback+0x28/0x54)
> [...]

I have added Tony and the openpvrsgx mailing list for better discussion. The more eyes look on the issue the easier we can solve it.

BR,
Nikolaus



More information about the openpvrsgx-devgroup mailing list