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

Message

Hans de Goede Nov. 29, 2019, 6:58 p.m. UTC

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?

Regards,

Hans

Comments

Andy Shevchenko Nov. 29, 2019, 8:07 p.m. UTC | #1

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! :-)