Re: [PATCH 0/2] drm/i915/vlv_dsi: Control panel and backlight enable GPIOs on BYT

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel@lists.freedesktop.org, linux-gpio@vger.kernel.org,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH 0/2] drm/i915/vlv_dsi: Control panel and backlight enable GPIOs on BYT
Date: Fri, 29 Nov 2019 22:07:39 +0200	[thread overview]
Message-ID: <20191129200739.GB32742@smile.fi.intel.com> (raw)
In-Reply-To: <20191129185836.2789-1-hdegoede@redhat.com>

On Fri, Nov 29, 2019 at 07:58:34PM +0100, Hans de Goede wrote:
> Hi All,
> 
> On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
> do not control the LCD panel- and backlight-enable GPIOs. So far, when
> the VBT indicates we should use the SoC for backlight control, we have
> been relying on these GPIOs being configured as output and driven high by
> the Video BIOS (GOP) when it initializes the panel.
> 
> This does not work when the device is booted with a HDMI monitor connected
> as then the GOP will initialize the HDMI instead of the panel, leaving the
> panel black, even though the i915 driver tries to output an image to it.
> 
> Likewise on some device-models when the GOP does not initialize the DSI
> panel it also leaves the mux of the PWM0 pin in generic GPIO mode instead
> of muxing it to the PWM controller.
> 
> This series contains 2 patches which together fix this.
> 
> To avoid new errors in the intel-gfx CI (assuming there is atleast 1
> BYT device there with a DSI panel), we need both of these patches to
> be merged through the drm-intel tree.
> 
> Unfortunately there is some churn currently going on in the
> pinctrl-baytrail.c code, but not in the part of the file which this
> touches, so merging the pinctrl-baytrail.c changes through the
> drm-intel tree should not lead to conflicts later.
> 
> Andy, Mika, assuming you are happy with the changes, can I get your ack
> for merging the pinctrl-baytrail patch throught the drm-inteol tree?

I'm not okay with this. I will tell more next week how I see this to be
implemented in a better way.

Happy Black Friday! :-)

-- 
With Best Regards,
Andy Shevchenko