Re: [RESEND LIST PATCHv7 1/4] clk: socfpga: Add a clk-phase property to the "altr, socfpga-gate-clk"

[Arnd Bergmann <arnd@arndb.de>]

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