mbox series

[0/3] drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT

Message ID 20191119151818.67531-1-hdegoede@redhat.com (mailing list archive)
Headers show
Series drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT | expand

Message

Hans de Goede Nov. 19, 2019, 3:18 p.m. UTC
Hi All,

This series needs to be merged through a single tree, to keep things
bisectable. I have even considered just squashing all 3 patches into 1,
but having separate commits seems better, but that does lead to an
intermediate state where the backlight sysfs interface will be broken
(and fixed 2 commits later). See below for some background info.

The changes to drivers/acpi/acpi_lpss.c and drivers/mfd/intel_soc_pmic_core.c
are quite small and should not lead to any conflicts, so I believe that
it would be best to merge this entire series through the drm-intel tree.

Lee, may I have your Acked-by for merging the mfd change through the
drm-intel tree?

Rafael, may I have your Acked-by for merging the acpi_lpss change through the
drm-intel tree?

Regards,

Hans

p.s.

The promised background info:

We have this long standing issue where instead of looking in the i915
VBT (Video BIOS Table) to see if we should use the PWM block of the SoC
or of the PMIC to control the backlight of a DSI panel, we rely on
drivers/acpi/acpi_lpss.c and/or drivers/mfd/intel_soc_pmic_core.c
registering a pwm with the generic name of "pwm_backlight" and then the
i915 panel code does a pwm_get(dev, "pwm_backlight").

We have some heuristics in drivers/acpi/acpi_lpss.c to not register the
lookup if a Crystal Cove PMIC is presend and the mfd/intel_soc_pmic_core.c
code simply assumes that since there is a PMIC the PMIC PWM block will
be used. Basically we are winging it.

Recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012

Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.

This series renams the PWM lookups registered by the LPSS /
intel_soc_pmic_core.c code from "pwm_backlight" to "pwm_soc_backlight" resp.
"pwm_pmic_backlight" and in the LPSS case also dropping the heuristics when
to register the lookup. This combined with teaching the i915 panel to call
pwm_get for the right lookup-name depending on the VBT bits resolves this.

Comments

Jani Nikula Nov. 19, 2019, 3:43 p.m. UTC | #1
On Tue, 19 Nov 2019, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> intermediate state where the backlight sysfs interface will be broken
> (and fixed 2 commits later). See below for some background info.
>
> The changes to drivers/acpi/acpi_lpss.c and drivers/mfd/intel_soc_pmic_core.c
> are quite small and should not lead to any conflicts, so I believe that
> it would be best to merge this entire series through the drm-intel tree.
>
> Lee, may I have your Acked-by for merging the mfd change through the
> drm-intel tree?
>
> Rafael, may I have your Acked-by for merging the acpi_lpss change through the
> drm-intel tree?
>
> Regards,
>
> Hans
>
> p.s.
>
> The promised background info:
>
> We have this long standing issue where instead of looking in the i915
> VBT (Video BIOS Table) to see if we should use the PWM block of the SoC
> or of the PMIC to control the backlight of a DSI panel, we rely on
> drivers/acpi/acpi_lpss.c and/or drivers/mfd/intel_soc_pmic_core.c
> registering a pwm with the generic name of "pwm_backlight" and then the
> i915 panel code does a pwm_get(dev, "pwm_backlight").
>
> We have some heuristics in drivers/acpi/acpi_lpss.c to not register the
> lookup if a Crystal Cove PMIC is presend and the mfd/intel_soc_pmic_core.c
> code simply assumes that since there is a PMIC the PMIC PWM block will
> be used. Basically we are winging it.
>
> Recently I've learned about 2 different BYT devices:
> Point of View MOBII TAB-P800W
> Acer Switch 10 SW5-012
>
> Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
> PWM controller (and the VBT correctly indicates this), so here our old
> heuristics fail.
>
> This series renams the PWM lookups registered by the LPSS /
> intel_soc_pmic_core.c code from "pwm_backlight" to "pwm_soc_backlight" resp.
> "pwm_pmic_backlight" and in the LPSS case also dropping the heuristics when
> to register the lookup. This combined with teaching the i915 panel to call
> pwm_get for the right lookup-name depending on the VBT bits resolves this.

Hans, thanks for your continued efforts in digging into the bottom of
this!

I'm sure there are a number of related bugs still open at fdo bugzilla.

It all makes sense,

Acked-by: Jani Nikula <jani.nikula@intel.com>

for merging through whichever tree.


Thanks,
Jani.
Andy Shevchenko Nov. 19, 2019, 4:32 p.m. UTC | #2
On Tue, Nov 19, 2019 at 04:18:15PM +0100, Hans de Goede wrote:
> Hi All,
> 
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> intermediate state where the backlight sysfs interface will be broken
> (and fixed 2 commits later). See below for some background info.
> 
> The changes to drivers/acpi/acpi_lpss.c and drivers/mfd/intel_soc_pmic_core.c
> are quite small and should not lead to any conflicts, so I believe that
> it would be best to merge this entire series through the drm-intel tree.
> 
> Lee, may I have your Acked-by for merging the mfd change through the
> drm-intel tree?
> 
> Rafael, may I have your Acked-by for merging the acpi_lpss change through the
> drm-intel tree?
> 

Entire series (or a single patch) makes sense to me.
Thanks for fixing this old hardware!

FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> Regards,
> 
> Hans
> 
> p.s.
> 
> The promised background info:
> 
> We have this long standing issue where instead of looking in the i915
> VBT (Video BIOS Table) to see if we should use the PWM block of the SoC
> or of the PMIC to control the backlight of a DSI panel, we rely on
> drivers/acpi/acpi_lpss.c and/or drivers/mfd/intel_soc_pmic_core.c
> registering a pwm with the generic name of "pwm_backlight" and then the
> i915 panel code does a pwm_get(dev, "pwm_backlight").
> 
> We have some heuristics in drivers/acpi/acpi_lpss.c to not register the
> lookup if a Crystal Cove PMIC is presend and the mfd/intel_soc_pmic_core.c
> code simply assumes that since there is a PMIC the PMIC PWM block will
> be used. Basically we are winging it.
> 
> Recently I've learned about 2 different BYT devices:
> Point of View MOBII TAB-P800W
> Acer Switch 10 SW5-012
> 
> Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
> PWM controller (and the VBT correctly indicates this), so here our old
> heuristics fail.
> 
> This series renams the PWM lookups registered by the LPSS /
> intel_soc_pmic_core.c code from "pwm_backlight" to "pwm_soc_backlight" resp.
> "pwm_pmic_backlight" and in the LPSS case also dropping the heuristics when
> to register the lookup. This combined with teaching the i915 panel to call
> pwm_get for the right lookup-name depending on the VBT bits resolves this.
>