From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Dooks Date: Mon, 10 Mar 2014 11:51:37 +0000 Subject: Re: [PATCH RFC] ARM: shmobile: r8a7791 legacy: Disable RMSTP clocks Message-Id: <531DA749.7000607@codethink.co.uk> List-Id: References: <1394135648-10193-1-git-send-email-geert@linux-m68k.org> In-Reply-To: <1394135648-10193-1-git-send-email-geert@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sh@vger.kernel.org On 10/03/14 11:45, Laurent Pinchart wrote: > Hi Geert, > > On Monday 10 March 2014 10:00:29 Geert Uytterhoeven wrote: >> On Fri, Mar 7, 2014 at 5:34 PM, Laurent Pinchart wrote: >>> On Friday 07 March 2014 17:17:04 Geert Uytterhoeven wrote: >>>> On Fri, Mar 7, 2014 at 4:44 PM, Ben Dooks wrote: >>>>>>> - How to tell the system that it should (not) disable the RMSTP >>>>>>> clocks? Someone may want to run something on the SH core, and we >>>>>>> don't want to interfere with that. >>>>>> >>>>>> Those are tricky questions. RMSTPCRs are supposed to be managed by the >>>>>> SH-4A core. If the SH-4A core isn't booted the only option we have is >>>>>> to manage them elsewhere. In that case the registers should be >>>>>> configured at boot time to disable all modules from the SH-4A side. >>>>>> This could be done either when booting the kernel, or in the boot >>>>>> loader. >>>>>> >>>>>> If the SH-4A core is booted by Linux we could require the SH-4A code >>>>>> to disable all unused clocks, but we could also do so before booting >>>>>> it without any drawback (I expect the SH-4A firmware to enable the >>>>>> clocks it needs). >>>>>> >>>>>> The SH-4A core could be booted first, and then only boot the ARM cores >>>>>> running Linux. I don't know if that configuration is commonly used, or >>>>>> even supported, but in theory that should be possible. In that case >>>>>> the Linux kernel must not touch the RMSTPCRs. >>>>>> >>>>>> We could disable all realtime clocks from the Linux kernel at boot >>>>>> time (with a way to bypass that depending on whether booting the SH-4A >>>>>> first is a use case we need to support), or decide to leave this to >>>>>> the boot loader. >>>>> >>>>> I agree with Laurent, we don't really have a good way yet to know >>>>> if the SH-4A is going to be used. >>>> >>>> If the SH-4A is used, there must be some synchronization between the >>>> two cores, to avoid both cores touching the same hardware at the same >>>> time. >>>> >>>> If there is no sharing (which CPU uses which hardware block is fixed), >>>> Linux can just disable the RMSTP clocks for the hardware blocks that are >>>> used by Linux only (i.e. those that are enabled in DT --- I'm ignoring >>>> the legacy case for now). This requires adding new regs to the >>>> bindings[*]. >>>> >>>> If there is sharing (both CPUs access the same hardware block, but not >>>> at the same time), synchronization code needs to be written. >>>> >>>> As the sharing case needs new code anyway, I think we can ignore it for >>>> now? >>>> >>>> That leaves us with the hardware blocks that are not used by Linux. I.e. >>>> (1) blocks we have in the .dtsi, but not enabled in the .dts, and >>>> (2) blocks that are not in the .dtsi because we don't have a driver yet. >>>> These may or may not be used by the SH-4A, but if not, we want to disable >>>> the clocks for power management reasons. >>> >>> As soon as SH-4A is involved I believe Linux shouldn't touch the RMSTPCRs. >>> As we currently have no standard way to handle this, I would be inclined >>> to leave the responsibility of disabling clocks for unused peripherals to >>> the boot loader. If the boot loader doesn't behave we'll end up using >>> more power than we should, but I don't think there would be any other >>> adverse effect. On the other hand, it's tempting to let the kernel cover >>> the bugs introduced by the boot loader developers, especially when the >>> boot loader is not easily modifiable. >> >> Sounds reasonable. >> >> Currently I'm most worried by bugs slipping in in our drivers' clock >> handling due to the clock still being enabled on the SH-4A side. > > I can share that concern. One possible solution would be a debug option to > force disabling of all RMSTPCRs from the Linux side. It's a bit hackish > though. Another one would be to fix the boot loader for our development > boards, but I don't know where the sources are located, and whether we could > push the modification "upstream" internally. > > Magnus, I'd also like to hear your opinion on all this. It isn't as if most boot-loaders are script-able, it would not be difficult to do the relevant pokes. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius