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]
Date:	Thu, 25 Apr 2013 16:21:24 +0100
From:	James Hogan <james.hogan@...tec.com>
To:	Catalin Marinas <catalin.marinas@....com>,
	Arnd Bergmann <arnd@...db.de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	"Linus Walleij" <linus.walleij@...aro.org>,
	<devicetree-discuss@...ts.ozlabs.org>,
	Rob Landley <rob@...dley.net>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 2/8] metag: minimal TZ1090 (Comet) SoC infrastructure

On 24/04/13 15:51, James Hogan wrote:
> On 24/04/13 14:26, Catalin Marinas wrote:
>> On 23 April 2013 17:06, James Hogan <james.hogan@...tec.com> wrote:
>>> It's certainly heading in that direction a lot. For this patchset I
>>> could get away with dropping arch/metag/soc/*, and deal with anything
>>> that really requires something like it later.
>>>
>>> The machine callbacks I was planning on using in future patches are:
>>> * init_time() for calling into the appropriate common clock driver from
>>> time_init(), prior to setting up the timer so that the right frequency
>>> can be reported based on the clock hierarchy specified in DT. I guess
>>> this could be made more general, allowing any enabled clock component to
>>> be initialised at this time.
>>
>> This is driven by DT on arm64, no need for platform callback (see
>> drivers/clocksource/arch_arm_timer.c).
> 
> Right. The problem is that the frequency of the core clock in TZ1090
> (and hence the arch timer that is derived from it) isn't discoverable in
> an arch generic way. I can do something similar to tegra (see
> tegra_clocks_init()) to init the common clk stuff early and then do:
> 
> node = of_find_compatible_node(NULL, NULL, "img,meta");
> clk_core = of_clk_get_by_name(node, "core");
> rate = clk_get_rate(clk_core);
> 
> From time_init prior to setting up the arch timer, but I need a platform
> callback for that.

I take that back, I've just noticed commit
f2f6c2556dcc432e50003bc8fa4d62d95906f149 which makes clock setup
callbacks automatic using section cunningness. :-)

Cheers
James

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ