On Wednesday, January 09, 2013 12:51:07 PM Mika Westerberg wrote: > 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: > > >>On Tue, Jan 08, 2013 at 11:02:28AM +0000, Mark Brown wrote: > > >>>No, the way to do this is to fix x86 to enable the clock API there. The > > >>>x86 maintainers couldn't be bothered when I submitted a patch and > > >>>getting anyone to take a patch to make it available by default appears > > >>>to be unreasonably hard but perhaps if someone from Intel tries the x86 > > >>>maintainers might take a patch... > > >>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. > > > > >>>We shouldn't be adding special case code to every driver that might need > > >>>a clock that gets used on an Intel system. > > >>I agree and it is cleaner to have the same API for all arches. However, > > >>I'm > > >>not sure how do we create the fixed clocks then? There is nothing in ACPI > > >>namespace (or in the ACPI 5.0 spec) that allows you to describe clocks and > > >>their relationships. > > >I'm sure it's not beyond the bounds of possibility that we could solve > > >this problem... > > > > No, it isn't. Any suggestions? > > I have one suggestion. > > Since even on x86 we are now starting to see peripherals that exists > normally on traditional SoCs, like the SPI controller, and the drivers > expect to have clock for these. > > What if we make drivers/clk/clk-x86.c that initializes necessary clocks > like the LPSS 100MHz fixed clock and registers this to all the LPSS > devices? Something along the lines of: > > clk = clk_register_fixed_rate(NULL, "lpss_iclk", NULL, CLK_IS_ROOT, > 100000000); > > ... > > clk_register_clkdev(clk, NULL, "INT33C0:00"); > > These are clocks that you really can't control (enable/disable) but they > allow one to get the clock rate using the standard clk API. > > One problem (among other things) with this is that now we have these clocks > created and registered on every single x86 system.
Well, we can make them depend on some .config options. > Other problem is that this setup needs manual maintenance as we can't get > the configuration from ACPI. So we just happen to know what the rate is supposed to be? What's the source of that information? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
