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]
Date:	Mon, 15 Apr 2013 11:50:37 +0000
From:	"Bedia, Vaibhav" <vaibhav.bedia@...com>
To:	Kevin Hilman <khilman@...aro.org>
CC:	"Poddar, Sourav" <sourav.poddar@...com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"tony@...mide.com" <tony@...mide.com>,
	"rmk+kernel@....linux.org.uk" <rmk+kernel@....linux.org.uk>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.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"

Hi Kevin,

On Thu, Apr 11, 2013 at 19:45:33, Kevin Hilman wrote:
> 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.
> 

Apologies for the delayed response. I was out of office for a couple of
days.

I don't recall the exact kernel version in which I ended up adding this flag
to keep the clock running but yes after the change mentioned below this flag
is not required. I just did a sanity check by removing this flag on v3.8
kernel and things work fine across suspend.

Regards,
Vaibhav 

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ