linux-kernel - Re: [RFC PATCH] clk: add extension API

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, 31 May 2012 14:50:00 +0200
From:	"Cousson, Benoit" <b-cousson@...com>
To:	Peter De Schrijver <pdeschrijver@...dia.com>
CC:	Felipe Balbi <balbi@...com>, Russell King <linux@....linux.org.uk>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mike Turquette <mturquette@...com>
Subject: Re: [RFC PATCH] clk: add extension API

Hi Peter,

On 5/31/2012 11:05 AM, Peter De Schrijver wrote:
>>
>> What if a module needs two clocks and you drive the reset on both of the
>> clocks ? What would happen ?
>>
>
> Only 'leave clocks' have this reset method and a module can only have 1 of
> them.
>
>>> but then we would have the keep a list of IDs (1 per module) which the drivers
>>> can use to call some tegra reset function which would in the end use registers
>>> in the same memory area to cause a reset. (the registers controlling
>>> modulereset are interleaved with those controlling the enable/disable of the
>>> main moduleclock and bitpositions are identical)
>>
>> Well, under a generic device-level API, you could just call an internal
>> clk_reset() function because you know which clocks feed into which
>> devices anyway. It could look something like:
>>
>> on Tegra:
>>
>> device_reset(dev)
>> 	->  dev_pm_domain->reset()
>> 		->  tegra_periph_reset()
>>
>
> These methods are also needed internally by the powergating code.
>
>> on OMAP:
>>
>> device_reset(dev)
>> 	->  dev_pm_domain->reset()
>> 		->  omap_hwmod_reset()
>>
>>
>> btw:
>>
>> tegra_periph_reset(....)
>> {
>> 	tegra_periph_reset_assert(...);
>> 	udelay(2);
>> 	tegra_periph_reset_deassert(...);
>> }
>
> which uses the clockframework currently.

Hehe, that a little bit why we had to introduce hwmod for OMAP.
A HW IP cannot just be represented by a clock node like it used to be in 
the good old time.

Now the question is should we extend the Linux device structure to 
handle such HW IP, or should we extend the clock definition to handle 
this kind of extended clock node.

It looks to me that this kind of function does belong to the device more 
than to the clock node.

FWIW, we do have as well issue managing properly the reset for OMAP IPs. 
It is done using custom OMAP hooks today and hwmod whereas it looks like 
it is really a common problem for SoC in general.

Regards,
Benoit
--
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/