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

[spanda at codeaurora.org]

On 2018-05-08 03:48, Stephen Boyd wrote:
> 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.

It should be 2, got confused with number GPIOs.