On 04/22/2016 04:06 AM, Laurent Pinchart wrote:
Hi Archit,
On Monday 18 Apr 2016 15:18:30 Archit Taneja wrote:
On 04/17/2016 05:01 PM, Xinliang Liu wrote:
On 9 March 2016 at 18:57, Archit Taneja architt@codeaurora.org wrote:
ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an additional DSI RX block that takes in DSI video mode output.
Trying to get this driver merged has had some challenges:
ADV7533 has an I2C control bus, but acts as a DSI peripheral too. After discussions, it was concluded that we'd want to provide an API to create MIPI DSI devices, rather than expose two different interfaces on DT. The first version [1] tried the former approach the second version [2] showed how the driver would look like if exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI device creation API provided by [3], this has been accepted and should be merged for 4.6.
The driver was designed as an I2C slave encoder. When ADV7533 patches were posted [1], it was modelled as a bridge, but ADV7511 and others were still left as I2C slave encoders. This wasn't accepted. After discussions, it was decided that ADV7511 too would be converted into a bridge driver, and all the users of ADV7511 should assume it is a bridge. This bridge conversion was done in [4]. There is still some debate over whether the bridge driver be involved in the connector creation, or the KMS driver that has the whole view of the display pipeline. This discussion shouldn't affect this patch set, though.
I also agree with Laurent Pinchart that bridge driver shoudn't get involved in in the connector creation. It is better for KMS driver that has the whole view of the display pipeline.
Yes, that's the eventual plan. We were thinking of creating an additional drm bridge api (drm_bridge_create_connector) that helps the KMS driver create a connector for the bridge.
Since there are certain connector related properties that the KMS driver may not be aware of, we were thinking of creating another drm_bridge op which fills up connector properties. Some properties (like whether we want POLLED HPD or not) are more platform specific, and would be parsed via the connector's DT node (that is, if DT is supported on that platform)
For now, this series creates the connector in the bridge's attach op, but relies on the KMS driver to call drm_connector_register. The other stuff I mentioned above can come later.
Do you think you'd have time to lead that effort ?
Yeah, I think I should.
I'll prepare a RFC and we can see how that goes.
Thanks, Archit