Re: [PATCH 05/11] spi/pxa2xx: make clock rate configurable from platform data

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]