[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161108112748.lw45lrefnolkgqit@phenom.ffwll.local>
Date: Tue, 8 Nov 2016 12:27:48 +0100
From: Daniel Vetter <daniel@...ll.ch>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...ux.ie>,
Brian Starkey <brian.starkey@....com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector
registration
On Tue, Nov 08, 2016 at 10:59:43AM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote:
> > Hm, I entirely missed that part of the troubles. Anyway, if you all agree
> > on a patch I certainly won't block it, feel free to merge through suitable
> > trees (or I can smash it into drm-misc if that's wanted).
>
> I think those who are interested in seeing the drm_connector_register()
> call disappear from tda998x only care about that happening, but not how
> it happens.
>
> We have agreement between myself, Brian and Liviu on this approach, and
> I think everyone else is waiting for me to push out the commit so it can
> be used as the basis for their work. I think everyone else is waiting
> for me to push something out which gets us past this log-jam.
>
> I don't understand the connectivity between drm-misc and David's drm
> tree - so I'm going to let you make the decision on whether to merge
> this into drm-misc. I normally send my pull requests for Armada and
> TDA998x changes to David, which means when I send my other TDA998x
> changes, the mali/tda998x commit will be included in that pull
> request too. So I'm wondering whether it would make more sense for
> me to send it to David instead, or whether I need to send my other
> changes through drm-misc instead. I find the whole drm vs drm-misc
> thing rather confusing.
>
> I think we should get this accepted into drm trees before anyone bases
> their work on this commit (which is why I've been holding off during
> the last week, waiting for DRM folk to get back from Santa Fe and
> readjust to the higher atmospheric pressure!)
>
> Anyway, here is my pull request for the mali/hdlcd/tda998x commit which
> I'd normally send to David - I don't mind which tree it goes into as
> long as things work out nicely.
drm-misc is just the collector for when it doesn't make sense to have a
driver or topic/feature pull request (or there isn't really a permanent
driver tree). Pull to Dave directly makes sense.
-Daniel
> 8<===
>
> David,
>
> Please incorporate the latest TDA998x I2C driver (drm-tda998x-mali
> branch), which can be found at:
>
> git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-mali
>
> with SHA1 90731c24d2db7ec04df43ddbcee9605183d05187.
>
> This change removes the call to drm_connector_register() which has been
> blocking the proper de-midlayer conversion of other DRM drivers.
> Unfortunately, hdlcd and mali have intimate dependencies on this change,
> which is why these drivers need to be fixed up in the same commit - they
> can't be separate commits without these drivers breaking. All other
> DRM drivers which make use of tda998x (to my knowledge - armada, tilcdc)
> cope with this change.
>
> This will update the following files:
>
> drivers/gpu/drm/arm/hdlcd_drv.c | 19 +++++++++++--------
> drivers/gpu/drm/arm/malidp_drv.c | 18 +++++++++++-------
> drivers/gpu/drm/i2c/tda998x_drv.c | 8 --------
> 3 files changed, 22 insertions(+), 23 deletions(-)
>
> through these changes:
>
> Brian Starkey (1):
> drm/i2c: tda998x: mali-dp: hdlcd: refactor connector registration
>
> Many thanks.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists