[Intel-gfx] [PATCH v2] pwm: lpss: Make builtin so that i915 can find the pwm_backlight
Thierry Reding
thierry.reding at gmail.com
Fri Jan 20 07:18:53 UTC 2017
On Fri, Jan 20, 2017 at 08:03:33AM +0100, Thierry Reding wrote:
> On Thu, Jan 19, 2017 at 06:58:30PM +0100, Hans de Goede wrote:
> > The primary consumer of the lpss pwm is the i915 kms driver,
> > the i915 driver does not support get_pwm returning -EPROBE_DEFER and
> > its init is very complex making this is almost impossible to fix.
> >
> > This commit changes the PWM_LPSS Kconfig from a tristate to a bool, so
> > that when the i915 driver loads the lpss pwm will be available avoiding
> > the -EPROBE_DEFER issue. Note that this is identical to how the same
> > problem was solved for the pwm-crc driver, which is used by the i915
> > driver on other platforms.
> >
> > Signed-off-by: Hans de Goede <hdegoede at redhat.com>
> > Acked-by: Jani Nikula <jani.nikula at intel.com>
> > ---
> > Changes in v2:
> > -Drop the pwm_add_table call (this has been moved to the acpi_lpss driver)
> > ---
> > drivers/pwm/Kconfig | 12 +++---------
> > 1 file changed, 3 insertions(+), 9 deletions(-)
>
> For the record I think this is completely wrong and i915 should be
> taught how to deal with -EPROBE_DEFER. We've gone through a lot of
> pain to clean up this kind of init-level ordering on other devices
> and the result is, in my opinion, a *lot* better than what we had
> before. It'd be shame to see i915 backpedal on that.
Looking into i915 a little, I don't see why handling -EPROBE_DEFER would
be very complicated. The call stack looks somewhat like this:
i915_pci_probe()
i915_driver_load()
i915_load_modeset_init()
intel_modeset_init()
intel_setup_outputs()
intel_dsi_init()
intel_panel_setup_backlight()
pwm_setup_backlight()
In the above, intel_modeset_init() is the last one that propagates
errors, but its caller, i915_load_modeset_init() properly handles
failure from other function calls. Also, pwm_setup_backlight() can
return errors to intel_panel_setup_backlight(), which will in turn
propagate them to intel_dsi_init().
So I'd think that in order to properly handle -EPROBE_DEFER you'd only
need to propagate errors back up this way:
intel_panel_setup_backlight()
intel_dsi_init()
intel_setup_outputs()
intel_modeset_init()
That seems to me to be far from "almost impossible".
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170120/7cec94ed/attachment.sig>
More information about the Intel-gfx
mailing list