On Mon, Jan 15, 2018 at 10:47 PM, Rob Herring <robh+dt@xxxxxxxxxx> wrote: > On Mon, Jan 15, 2018 at 9:53 AM, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote: >> On Mon, Jan 15, 2018 at 8:45 PM, Rob Herring <robh+dt@xxxxxxxxxx> wrote: >>> On Mon, Jan 15, 2018 at 7:05 AM, <jassisinghbrar@xxxxxxxxx> wrote: >>>> From: Jassi Brar <jaswinder.singh@xxxxxxxxxx> >>>> >>>> This patch adds documentation for Device-Tree bindings for the >>>> Socionext Synquacer spi driver. >>>> >>>> Signed-off-by: Jassi Brar <jaswinder.singh@xxxxxxxxxx> >>>> --- >>>> .../devicetree/bindings/spi/spi-synquacer.txt | 24 ++++++++++++++++++++++ >>>> 1 file changed, 24 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/spi/spi-synquacer.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/spi/spi-synquacer.txt b/Documentation/devicetree/bindings/spi/spi-synquacer.txt >>>> new file mode 100644 >>>> index 0000000..d013cfd >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/spi/spi-synquacer.txt >>>> @@ -0,0 +1,24 @@ >>>> +* Socionext Synquacer HS-SPI bindings >>>> + >>>> +Required Properties: >>>> +- compatible: should be "socionext,synquacer-spi" >>>> +- reg: physical base address of the controller and length of memory mapped >>>> + region. >>>> +- clocks: Must contain an entry for rate source clock(s). >>>> +- clock-names: Shall be "iHCLK" or "iPCLK". iHCLK is preferred over iPCLK >>> >>> Huh? The clock binding should reflect all clocks connected to a block, >>> not a selection of which one you want to use. >>> >> Both the clocks are internal to the block and derived from the same source. >> Instead of defining a new "use-ipclk" property, the driver uses the >> clock-names to choose the appropriate divider. >> I am open to any better option. > > If one is preferred, then why not always use it? Or how does one > decide which clock to use? > A slight correction, there is a mux inside the block which selects clock from two input ports (iPCLK and iHCLK) and send that to the divider. Depending upon the spi slave speed requirements the platform may choose to connect either PCLK or HCLK (or maybe both but switching is said to be not feasible without block reset and DT can't suggest switch in runtime so we ask DT to provide only the source clock). Now the idea dawns that DT provide both clocks and the driver select from the mux looking at speed requirements of the slave at runtime. However, then, there will be a wide range of speeds that both could provide. Not to forget the block drives 4 slaves and optimising speed for one could potentially break other slaves. Practically the h/w designer would have already thought of speed requirements of the slaves and made sure that port is populated .... the driver could simple count upon that good design. Thanks -- 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
