Messages in this thread | | | Subject | Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight | From | Hans de Goede <> | Date | Wed, 11 Dec 2019 18:29:32 +0100 |
| |
Hi Lee,
On 10-12-2019 09:51, Lee Jones wrote: > On Tue, 19 Nov 2019, Hans de Goede wrote: > >> At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 >> different PWM controllers for controlling the LCD's backlight brightness. >> >> Either the one integrated into the PMIC or the one integrated into the >> SoC (the 1st LPSS PWM controller). >> >> So far in the LPSS code on BYT we have skipped registering the LPSS PWM >> controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is >> present, assuming that in this case the PMIC PWM controller will be used. >> >> On CHT we have been relying on only 1 of the 2 PWM controllers being >> enabled in the DSDT at the same time; and always registered the lookup. >> >> So far this has been working, but the correct way to determine which PWM >> controller needs to be used is by checking a bit in the VBT table and >> 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. >> >> Since only the i915 driver has access to the VBT, this commit renames >> the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM >> controller to "pwm_pmic_backlight" so that the i915 driver can do a >> pwm_get() for the right controller depending on the VBT bit, instead of >> the i915 driver relying on a "pwm_backlight" lookup getting registered >> which magically points to the right controller. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> drivers/mfd/intel_soc_pmic_core.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > For my own reference: > Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
As mentioned in the cover-letter, to avoid breaking bi-sectability as well as to avoid breaking the intel-gfx CI we need to merge this series in one go through one tree. Specifically through the drm-intel tree. Is that ok with you ?
If this is ok with you, then you do not have to do anything, I will just push the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c does not see much changes so I do not expect this to lead to any conflicts.
Regards,
Hans
| |