linux-kernel - Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using "no_console

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y5cpxiey.fsf@linaro.org>
Date:	Thu, 11 Apr 2013 07:15:33 -0700
From:	Kevin Hilman <khilman@...aro.org>
To:	"Bedia\, Vaibhav" <vaibhav.bedia@...com>
Cc:	"Poddar\, Sourav" <sourav.poddar@...com>,
	"gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
	"tony\@atomide.com" <tony@...mide.com>,
	"rmk+kernel\@arm.linux.org.uk" <rmk+kernel@....linux.org.uk>,
	"linux-omap\@vger.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial\@vger.kernel.org" <linux-serial@...r.kernel.org>,
	"Shilimkar\, Santosh" <santosh.shilimkar@...com>,
	"Balbi\, Felipe" <balbi@...com>, "Nayak\, Rajendra" <rnayak@...com>
Subject: Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using "no_console_suspend"

Kevin Hilman <khilman@...aro.org> writes:

> "Bedia, Vaibhav" <vaibhav.bedia@...com> writes:
>
>> Hi Sourav,
>>
>> On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
>> [...]
>>> Yes, had a look at that and found your situation similar to UART.
>>> 
>>> But how exactly this gets used, I mean I don't  see any drivers/ in mainline
>>> making use of this compatible string  "ti,am3352-ocmcram".  ?
>>
>> OCMC clock is enabled during bootup (not sure whether that's the h/w
>> default or ROM does it) since the initial bootloader runs from there.
>> By marking the corresponding hwmod with HWMOD_INIT_NO_IDLE we leave the
>> clock running. Right now the sram code under arch/arm/plat-omap/ is what
>> manages the OCMC. I guess this needs to move somewhere under drivers/
>> and start managing the clocks. Even then we'll need a mechanism
>> to leave the clocks running as part of the kernel suspend process
>> since the assembly code which runs at the fag end of the suspend
>> process runs out of OCMC and hence we can't cut its clock.
>>
>> On AM335x, the OCMC clock is cut to have PER power domain transition
>> but that's done in the WKUP-M3 firmware when going down. During the
>> wakeup sequence, WKUP-M3 re-enables the OCMC clock so that when the
>> kernel resumes the h/w state is same.
>
> OK, but *today*, in *mainline*, where in the linux kernel (not the M3
> firmware) is the OCMRAM clock cut during suspend?
>
> From what I can see, there is no driver for this device, so there are no
> system PM calls being done for that device, and thus no omap_device
> calls being done for that device, so the no_idle_on_suspend has no
> effect.

OK, I think I confused things here, sorry. I was thinking runtime PM
here, but wrote system PM.  The no_idle_on_suspend feature only affects
system PM, and the omap_device calls will still be called during system
PM, even without a driver.

That being said, the commit below[1], added in v3.6 should prevent the
any automaic clock gating for devices without drivers bound.  Since
there is no driver for the OCM RAM block, you shouldn't be affected by
the automatic idle on suspend anyways.

So, my proposal is that Sourav remove that flag from the AM33xx hwmod
when he removes this feature.

Kevin


[1]
commit 72bb6f9b51c82c820ddef892455a85b115460904
Author: Kevin Hilman <khilman@...com>
Date:   Tue Jul 10 15:29:04 2012 -0700

    ARM: OMAP: omap_device: don't attempt late suspend if no driver bound
    
    Currently, the omap_device PM domain layer uses the late suspend and
    early resume callbacks to ensure devices are in their low power
    states.
    
    However, this is attempted even in cases where a driver probe has
    failed.  If a driver's ->probe() method fails, the driver is likely in
    a state where it is not expecting its runtime PM callbacks to be
    called, yet currently the omap_device PM domain code attempts to call
    the drivers callbacks.
    
    To fix, use the omap_device driver_status field to check whether a
    driver is bound to the omap_device before attempting to trigger driver
    callbacks.
    
    Reviewed-by: Paul Walmsley <paul@...an.com>
    Signed-off-by: Kevin Hilman <khilman@...com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/