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.
