[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
Archit Taneja
architt at codeaurora.org
Fri Apr 22 05:44:23 UTC 2016
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
More information about the dri-devel
mailing list