[PATCH v5 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[Stephen Boyd]

Quoting spanda at codeaurora.org (2018-05-03 02:41:29)
> On 2018-05-02 22:31, Stephen Boyd wrote:
> > Quoting Sandeep Panda (2018-05-01 21:32:00)
> >> diff --git 
> >> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
> >> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> >> new file mode 100644
> >> index 0000000..0d042ce
> > 
> > Please use the clocks property instead. We may need to turn the clk on
> > first before this can work so the driver would use the clk framework 
> > (at
> > least in linux). clock-names could have 'refclk' because that's the pin
> > name.
> > 
> > Is there a way in DRM to figure out the frequency of the clock 
> > frequency
> > for DACP/N? It looks like if refclk is grounded, then the DACP/N pins
> > from the DSI side should be one of a set of frequencies, so I'm just
> > curious how that will work and if the binding would need to be updated
> > to indicate what the frequency of the DSI clock lane is, or if DRM can
> > tell this driver through the port/graph stuff somehow.
> > 
> 
> Can we do something like below?
>     1. Add a required dt-property to indicate what is the source of 
> refclk, ti,sn-refclk-src = <0> ---> means refclk is derived from refclk 
> pin.
>                                                                           
>    ti,sn-refclk-src = <1> ---> means refclk is derived from DACP/N pin.
>     2. Add a clock property to indicate the refclk frequency for refclk 
> pin.
>     3. In driver, parse the refclk source dt-property. If the source is 
> refclk pin then get the frquency from clock dt-property and program the 
> i2c register accordingly.
>        Else if the source is DACP/N pin then calculate the DSIA frequency 
> based on current display mode (by the time we go for configuring refclk, 
> drm_mode_set is already done and in  diver we can calculate the 
> frequency) and program the i2c register accordingly.

The presence or non-presence of the refclk should still be indicated via
the standard clock property instead of some TI specific property. The
driver can try to clk_get() the refclk and if its there it can call
clk_get_rate() to figure out the reference clk frequency. It should also
turn it on with clk_prepare_enable() to make sure the clk is clocking
and turn it off when the driver isn't using it.

If the reference clk is recovered from the DACP/N pin then there won't
be a clocks property, and the driver can do what you describe in #3.

> 
> >> +
> >> +- gpio-controller: Marks the device has a GPIO controller.
> >> +- #gpio-cells: Number of GPIO cells. Refer to binding document 
> >> "gpio/gpio.txt"
> > 
> > What's the number? 2?
> number is 4, i will update this in binding

Really? What do you need 4 cells for? The number of cells doesn't
indicate the number of GPIOs on the device.