On Tue, Jan 08, 2013 at 10:33:55PM +0100, Rafael J. Wysocki wrote: > On 1/8/2013 2:10 PM, Mark Brown wrote: > >On Tue, Jan 08, 2013 at 02:41:53PM +0200, Mika Westerberg wrote:
> >>Do you mean enabling CONFIG_COMMON_CLK on x86? > >Yes. > Why so? x86 doesn't have a notion of direct clock control, at least > not on the ACPI systems. So, a couple of things here. One is that your SFI systems *do* have user controllable clocks so they really should be using the clock API. The other is that even if the CPU doesn't want to use clocks off-CPU devices may wish to - for example, a PCI card using off the shelf components or in this case a device on the SPI bus on the laptop which requires a clock and wants to manage it at runtime if possible. We should be able to arrange things so that drivers can work with clocks using the standard clock API. I'm really hopinng that having the clock API will eventually enable us to work with clocks in off-SoC devices but right now the only option is open coding. > >I'm sure it's not beyond the bounds of possibility that we could solve > >this problem... > No, it isn't. Any suggestions? Well, the most obvious solution would be to just hard code this information in the kernel and set it up based on what you do know. For example if this is a SoC-internal clock then set it up based on knowing the SoC (this seems to be basically what Mika is suggesting). > >It is something that needs to be resolved for your smartphone SoCs for > We're not talking about smartphones and even not about SoCs here, sorry. > This is a laptop CPU that happens to have an SPI controller integrated. These are still x86 systems so are part of why it seems like a good idea to make the clock API available on x86. > >this and for other things like platform data for external chips, what's > >actually happening in practical systems here is that people are just > >hacking the arch code as there's no mechanism for providing > >configuration at present. > I'm not sure what you're referring to, but here we have ACPI as a > configuration mechanism. > Which doesn't allow us to control clocks directly. Right, and because the BIOS guys don't provide any mechanism for handling this stuff using the BIOS information what people actually deploying systems are doing is just hacking the arch code which gets us the worst of both worlds - we have to put things into the BIOS but we then have to put extra information into the kernel to actually make things functional.
signature.asc
Description: Digital signature
