On Mon, 16 Dec 2019, Andy Shevchenko wrote: > On Sun, Dec 15, 2019 at 05:38:05PM +0100, Hans de Goede wrote: > > Hi All, > > > > This is a new (completely rewritten) version of my patches to make the > > i915 code control the SoC panel- and backlight-enable GPIOs on Bay Trail > > devices when the VBT indicates that the SoC should be used for backlight > > control. This fixes the panel not lighting up on various devices when > > booted with a HDMI monitor connected, in which case the firmware skips > > initializing the panel as it inits the HDMI instead. > > > > This series has been tested on; and fixes this issue on; the following models: > > > > Peaq C1010 > > Point of View MOBII TAB-P800W > > Point of View MOBII TAB-P1005W > > Terra Pad 1061 > > Thundersoft TST178 > > Yours Y8W81 > > > > Linus, this series starts with the already discussed pinctrl change to > > export the function to unregister a pinctrl-map. We can either merge this > > through drm-intel, or you could pick it up and then provide an immutable > > branch with it for merging into drm-intel-next. Which option do you prefer? > > > > Lee, I know you don't like this, but unfortunately this series introcudes > > some (other) changes to drivers/mfd/intel_soc_pmic_core.c. The GPIO subsys > > allows only one mapping-table per consumer, so in hindsight adding the code > > which adds the mapping for the PMIC panel-enable pin to the PMIC mfd driver > > was a mistake, as the PMIC code is a provider where as mapping-tables are > > per consumer. The 4th patch fixes this by moving the mapping-table to the > > i915 code, so that we can also add mappings for some of the pins on the SoC > > itself. Since this whole series makes change to the i915 code I plan to > > merge this mfd change to the drm-intel tree. > > FWIW, Lee, I believe there will be no (significant) changes in the driver Hans > touched. For the record it seems only Hans is touching drivers for old Intel > platforms (such as Baytrail and Cherryview). More exceptions, yay! Again, in *this* case, it's probably fine. What I want to know is; what happens when it's not fine? What happens when you or someone else starts changing MFD and DRM on more active files? Then I will have to insist on an immutable branch. So it would be better for the DRM tree to be able to handle that use-case sooner rather than later, regardless of who has the most churn. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
