From mboxrd@z Thu Jan 1 00:00:00 1970 From: Archit Taneja Subject: Re: [PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions Date: Sat, 9 Jan 2016 22:33:12 +0530 Message-ID: <56913D50.40504@codeaurora.org> References: <1437977819-24199-1-git-send-email-architt@codeaurora.org> <2033050.HoN4SD9MIx@avalon> <1942478.kD5aMJIFbO@avalon> <56606997.6000700@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:44107 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753482AbcAIRDV (ORCPT ); Sat, 9 Jan 2016 12:03:21 -0500 In-Reply-To: <56606997.6000700@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Laurent Pinchart Cc: Rob Clark , linux-arm-msm , "dri-devel@lists.freedesktop.org" , Andy Green , Srinivas Kandagatla Hi Laurent, On 12/3/2015 9:41 PM, Archit Taneja wrote: > > > On 12/3/2015 9:25 PM, Rob Clark wrote: >> On Thu, Dec 3, 2015 at 10:28 AM, Laurent Pinchart >> wrote: >>> On Thursday 03 December 2015 10:02:02 Rob Clark wrote: >>>> On Mon, Jul 27, 2015 at 4:59 AM, Laurent Pinchart wrote: >>>>> On Monday 27 July 2015 11:46:57 Archit Taneja wrote: >>>>>> ADV7511 is represented as an i2c drm slave encoder device. >>>>>> ADV7533, on >>>>>> the other hand, is going be a normal i2c client device creating >>>>>> bridge >>>>>> and connector entities. > > Laurent, as we'd discussed in the past, I did an initial study of how > we could map bridge ops to the encoder slave ops, and change it for the > rcar kms driver (and others) that might use adv7511. > > The drm_encoder_slave_funcs ops are a superset of bridge ops. The > rcar-du driver uses a subset of these ops (encoder-like ops) to > implement the hdmi encoder (rcar_du_hdmienc.c) and the other > (connector-like ops)for implementing the hdmi connector > (rcar_du_hdmicon.c) > > We have two options: > > 1. If we want to use drm_bridge as it is, the rcar driver shouldn't > create a hdmi connector anymore, and rely on the adv7511 driver to make > a connector for it. This is the easiest way, but it will break the nice > representation of the hardware in DT. > > 2. We add more drm_bridge ops (the ones that implement the connector > ops), and make the hdmi connector created by rcar-du use these bridge > ops. > > Both these options have issues. The 2) one is the probably the better of > the two, but I don't know if adding more ops to the bridge is the right > way to go. > > Therefore, I don't know how we can solve this straight away. If there is > more debate needed on this, then it is probably easier to get adv7533 > support in, and then figure out how two merge the two. > I gave approach (1) a try. I modified the rcar-du driver to use bridge instead of i2c slave encoder and posted a RFC [1]. The hdmi connector DT nodes (like in r8a7790-lager.dts) aren't really used by the rcar-du driver. Now, with the adv7511 driver creating its own connector, they mean even much less. The adv7511 refactor from i2c slave encoder to bridge is done in [2]. [1] http://marc.info/?l=dri-devel&m=145235835902378&w=1 [2] http://marc.info/?l=dri-devel&m=145235823602353&w=1 Could you please review and test? Thanks, Archit > >> >> BR, >> -R >> >>> -- >>> Regards, >>> >>> Laurent Pinchart >>> > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project