Re: [PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support

From: Archit Taneja <architt@codeaurora.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-arm-msm@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Amit Kucheria <amit.kucheria@linaro.org>,
	treding@nvidia.com
Subject: Re: [PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
Date: Fri, 22 Apr 2016 11:14:23 +0530	[thread overview]
Message-ID: <5719BA37.6050203@codeaurora.org> (raw)
In-Reply-To: <7946010.9Qhcp8D76N@avalon>

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

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel