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

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]

Message-ID: <4864369.rBqnVsbbLM@vostro.rjw.lan>
Date:	Wed, 09 Jan 2013 22:52:12 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, eric.y.miao@...il.com,
	linux@....linux.org.uk, haojian.zhuang@...il.com,
	chao.bi@...el.com, "H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH 05/11] spi/pxa2xx: make clock rate configurable from platform data

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