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. -- 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
