-----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----- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html