Re: [PATCH 1/2] clk: mvebu: armada 370/XP add clock gating controlprovider for DT

[Gregory CLEMENT]

Hi Andrew

On 11/17/2012 09:26 AM, Andrew Lunn wrote:
> Hi Gregory
> 
> Nice work

Thanks!

> 
> On Fri, Nov 16, 2012 at 07:01:59PM +0100, Gregory CLEMENT wrote:
>> Signed-off-by: Gregory CLEMENT <gregory.clement@xxxxxxxxxxxxxxxxxx>
>> ---
>>  .../bindings/clock/mvebu-gated-clock.txt           |   43 ++++++++++++++
>>  arch/arm/mach-mvebu/Kconfig                        |    1 +
>>  drivers/clk/mvebu/clk-gating-ctrl.c                |   61 ++++++++++++++++++++
>>  3 files changed, 105 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
>> index 7497cc0..9dbcdd9 100644
>> --- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
>> @@ -6,6 +6,49 @@ the clock ID in its "clocks" phandle cell. The clock ID is directly mapped to
>>  the corresponding clock gating control bit in HW to ease manual clock lookup
>>  in datasheet.
>>  
>> +The following is a list of provided IDs for Armada XP:
> 
> Should that the 370, not XP?

Yes indeed, it was a wrong copy and paste.

> 
>> +ID	Clock	Peripheral
>> +-----------------------------------
>> +0	Audio	AC97 Cntrl
>> +1	pex0_en	PCIe 0 Clock out
>> +2	pex1_en	PCIe 1 Clock out
>> +3	ge1	Gigabit Ethernet 1
>> +4	ge0	Gigabit Ethernet 0
>> +5	pex0	PCIe Cntrl 0
>> +9	pex1	PCIe Cntrl 1
>> +15	sata0	SATA Host 0
>> +17	sdio	SDHCI Host
>> +25	tdm	Time Division Mplx
>> +28	ddr	DDR Cntrl
>> +30	sata1	SATA Host 0
> 
> Not many clocks there. USB? XOR? Crypto?

Yes I was surprised too, but it was I found on the datasheet.
For USB, for example you can turn the USB in low power mode but
at the PHY level.


> 
> What is the ddr clock for? Does bad things happen if you turn it off?
> Kirkwood has a similar clock, dunit, which i decided not to export,
> since when you turn it off, the whole SoC locks up.

Well of course if you code run in DDR then it could be a problem. But
I think it could be useful to turn it off when going to suspend, it
the DDR can do self-refresh. In this case it should be possible to run
the code from SRAM or L2 Cache.

Gregory
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/