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 at 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 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
