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 linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
