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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux