[lkml]   [2019]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/5] drm/i915/dsi: Control panel and backlight enable GPIOs from VBT
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 │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

 \ /
  Last update: 2019-12-16 17:11    [W:0.165 / U:3.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site