From mboxrd@z Thu Jan 1 00:00:00 1970 From: "james qian wang (Arm Technology China)" Subject: Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints Date: Fri, 18 Oct 2019 06:38:59 +0000 Message-ID: <20191018063851.GA18702@jamwan02-TSP300> References: <20191004143418.53039-4-mihail.atanassov@arm.com> <20191009055407.GA3082@jamwan02-TSP300> <5390495.Gzyn2rW8Nj@e123338-lin> <20191016162206.u2yo37rtqwou4oep@DESKTOP-E1NTVVP.localdomain> <20191017030752.GA3109@jamwan02-TSP300> <20191017082043.bpiuvfr3r4jngxtu@DESKTOP-E1NTVVP.localdomain> <20191017102055.GA8308@jamwan02-TSP300> <20191017104812.6qpuzoh5bx5i2y3m@DESKTOP-E1NTVVP.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20191017104812.6qpuzoh5bx5i2y3m@DESKTOP-E1NTVVP.localdomain> Content-Language: en-US Content-ID: <534A4133140A7F41969D6124426D8D8A@eurprd08.prod.outlook.com> Sender: linux-kernel-owner@vger.kernel.org To: Brian Starkey Cc: Mihail Atanassov , "dri-devel@lists.freedesktop.org" , David Airlie , Liviu Dudau , Russell King , Maxime Ripard , "linux-kernel@vger.kernel.org" , nd , Sean Paul List-Id: dri-devel@lists.freedesktop.org On Thu, Oct 17, 2019 at 10:48:12AM +0000, Brian Starkey wrote: > On Thu, Oct 17, 2019 at 10:21:03AM +0000, james qian wang (Arm Technology= China) wrote: > > On Thu, Oct 17, 2019 at 08:20:56AM +0000, Brian Starkey wrote: > > > On Thu, Oct 17, 2019 at 03:07:59AM +0000, james qian wang (Arm Techno= logy China) wrote: > > > > On Wed, Oct 16, 2019 at 04:22:07PM +0000, Brian Starkey wrote: > > > > >=20 > > > > > If James is strongly against merging this, maybe we just swap > > > > > wholesale to bridge? But for me, the pragmatic approach would be = this > > > > > stop-gap. > > > > > > > > >=20 > > > > This is a good idea, and I vote +ULONG_MAX :) > > > >=20 > > > > and I also checked tda998x driver, it supports bridge. so swap the > > > > wholesale to brige is perfect. :) > > > >=20 > > >=20 > > > Well, as Mihail wrote, it's definitely not perfect. > > >=20 > > > Today, if you rmmod tda998x with the DPU driver still loaded, > > > everything will be unbound gracefully. > > >=20 > > > If we swap to bridge, then rmmod'ing tda998x (or any other bridge > > > driver the DPU is using) with the DPU driver still loaded will result > > > in a crash. > >=20 > > I haven't read the bridge code, but seems this is a bug of drm_bridge, > > since if the bridge is still in using by others, the rmmod should fail > >=20 >=20 > Correct, but there's no fix for that today. You can also take a look > at the thread linked from Mihail's cover letter. >=20 > > And personally opinion, if the bridge doesn't handle the dependence. > > for us: > >=20 > > - add such support to bridge >=20 > That would certainly be helpful. I don't know if there's consensus on > how to do that. >=20 > > or > > - just do the insmod/rmmod in correct order. > >=20 > > > So, there really are proper benefits to sticking with the component > > > code for tda998x, which is why I'd like to understand why you're so > > > against this patch? > > > > >=20 > > This change handles two different connectors in komeda internally, comp= are > > with one interface, it increases the complexity, more risk of bug and m= ore > > cost of maintainance. > >=20 >=20 > Well, it's only about how to bind the drivers - two different methods > of binding, not two different connectors. I would argue that carrying > our out-of-tree patches to support both platforms is a larger > maintenance burden. >=20 > Honestly this looks like a win-win to me. We get the superior approach > when its supported, and still get to support bridges which are more > common. > My consideration is: if we support both link methods, we may suffering - 1. bridge reference cnt problem - 2. maintance two link methods. the 1) seems unavoidable, so swap all to bridage at least can avoid the pain of 2). that's why I thought your idea "swap all to bridage" is good. Thanks James. > As/when improvements are made to the bridge code we can remove the > component bits and not lose anything. >=20 > > So my suggestion is keeping on one single interface in komeda, no > > matter it is bridge or component, but I'd like it only one, but not > > them both in komeda. >=20 > If we can put the effort into fixing bridges then I guess that's the > best approach for everyone :-) Might not be easy though! >=20 > -Brian >=20 > >=20 > > Thanks > > James > >=20 > > > Thanks, > > > -Brian