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@xxxxxxxxxxxxxx> 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
--
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
