Hi Soren/Boris, On Mon, Sep 14, 2015 at 8:14 PM, Sören Brinkmann <soren.brinkmann@xxxxxxxxxx> wrote: > On Mon, 2015-09-14 at 09:58AM +0200, Boris Brezillon wrote: >> Hi Harini, >> >> On Mon, 14 Sep 2015 09:39:05 +0530 >> Harini Katakam <harinikatakamlinux@xxxxxxxxx> wrote: >> >> > On Fri, Sep 11, 2015 at 10:22 PM, Sören Brinkmann >> > <soren.brinkmann@xxxxxxxxxx> wrote: >> > > Hi Harini, >> > > >> > > On Fri, 2015-09-11 at 01:27PM +0530, Harini Katakam wrote: >> > >> Add TSU clock frequency to be used for 1588 support in macb driver. >> > >> >> > >> Signed-off-by: Harini Katakam <harinik@xxxxxxxxxx> >> > >> --- >> > >> Documentation/devicetree/bindings/net/macb.txt | 3 +++ >> > >> 1 file changed, 3 insertions(+) >> > >> >> > >> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt >> > >> index b5d7976..f7c0ea8 100644 >> > >> --- a/Documentation/devicetree/bindings/net/macb.txt >> > >> +++ b/Documentation/devicetree/bindings/net/macb.txt >> > >> @@ -19,6 +19,9 @@ Required properties: >> > >> Optional elements: 'tx_clk' >> > >> - clocks: Phandles to input clocks. >> > >> >> > >> +Optional properties: >> > >> +- tsu-clk: Time stamp unit clock frequency used. >> > > >> > > Why are we not using the CCF and a clk_get_rate() in the driver? >> > > >> > >> > If the clock source was only internal, we could use this >> > approach as usual. But TSU clock can be configured to >> > come from an external clock source or internal. >> >> How about declaring a fixed-rate clk [1] if it comes from an external >> clk, and using a clk driver for the internal clk case? >> This way you'll be able to use the clk API (including the >> clk_get_rate() function) instead of introducing a new way to retrieve a >> clk frequency. > > Right. Also, Zynq does already support external clock inputs (actually, > every clock originates from some external clock/oscillator at some > point). Maybe that code needs some additions to handle the TSU clock > too. But either way, I can't see why a clock cannot be modeled using the > CCF. Ok, I'm going to try this. Regards, Harini -- 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
