On Wednesday 18 December 2013, Mike Turquette wrote: > > diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi > > index f936476..616d9ee 100644 > > --- a/arch/arm/boot/dts/socfpga.dtsi > > +++ b/arch/arm/boot/dts/socfpga.dtsi > > @@ -413,6 +413,7 @@ > > compatible = "altr,socfpga-gate-clk"; > > clocks = <&f2s_periph_ref_clk>, <&main_nand_sdmmc_clk>, <&per_nand_mmc_clk>; > > clk-gate = <0xa0 8>; > > + clk-phase = <0 3>; > > Looking at this again, I have a hard time understanding the values in > the clk-phase property. You reference some functions in the property > definition above, but they are not obvious to me. > > Additionally I wonder if the binding would better if the clock-phase > property was simply the value in degrees. E.g: > > clk-phase = <315>; // 315 degrees I would definitely prefer using degrees over an arbitrary enumeration that might work on some platforms but not on others. I'm also a bit skeptical about the idea of putting the phase into the clock provider rather than the consumer, given the comments about the clk_set_phase() interface earlier. Generally we try to avoid having consumer-specific settings in a provider node (for any DT binding, not just clocks). Can't you have the same numbers in the dw-mshc node instead and let the mmc driver call clk_set_phase instead? If every clock has a fixed phase for a given piece of hardware, it could even be set automatically by making the common clk code read the clk-phase attribute at the time a driver calls clk_get. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
