[GIT PULL] Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

[Russell King - ARM Linux]

Okay, I've queued this into my own for-next branch, along with the now
reviewed and tested set of tda998x patches that I sent out for comment
and testing.

I'm still hopeful that Dave's going to pull the initial patch at some
point... please?

On Tue, Nov 15, 2016 at 09:46:31AM +0000, Russell King - ARM Linux wrote:
> I guess Dave must have missed this as I can't see it in drm-next, so
> I'm resending the pull request.
> 
> 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.
> > 
> > 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.
> 
> -- 
> 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.

-- 
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.