[PATCH v2 2/5] clk: sunxi: Add USB clock register defintions

Hans de Goede hdegoede at redhat.com
Tue Jan 28 05:00:45 EST 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 01/28/2014 10:44 AM, Maxime Ripard wrote:
> On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote:
>>>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
>>> 
>>> Maybe we can just remove the gates from there? Even though they are gates, they are also (a bit) more than that.
>> 
>> To be clear you mean s/usb-gates-clk/usb-clk/ right ?
> 
> Yep, exactly
> 
>>> I guess that means that we will have the OHCI0 gate declared with <&...-gates-clk 6>, while it's actually the first gate for this clock?
>> 
>> Correct.
>> 
>>> Maybe introducing an offset field in the gates_data would be a good idea, so that we always start from indexing the gates from 0 in the DT?
>> 
>> Well for the other "gates" type clks we also have holes in the range, and we always refer to the clk with the bit number in the reg as the clock-cell value.
> 
> Yes, we have holes, but I see two majors differences here: - the other gates are just gates, while the usb clocks are a bit more than that.

The usb-clk registers contain more then that, but the bits we are talking
about now are gates.

> - the other gates' gating bits thus all start at bit 0, while here, since it's kind of a "mixed" clock, the gating bits start at bit 6 (on the A20 at least)

Right, still I believe that the consistent thing to do is keeping the
bit-number for the bit in the register controlling the gate as the
specifier.  When adding new dts entries / reviewing existing ones
I'm used to matching the specifier to the bit-nr in the data-sheet,
I think making things different just for this one register is counter
productive.

Regards,

Hans

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLnf80ACgkQF3VEtJrzE/udugCdEDpN65hazG7H+FD45iOVnTY9
548An3dXeF6f8wp5REck5H3gqQPQkIoX
=6yba
-----END PGP SIGNATURE-----



More information about the linux-arm-kernel mailing list