-----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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
