[Intel-gfx] [PATCH v2] pwm: lpss: Make builtin so that i915 can find the pwm_backlight

[Jani Nikula]

On Fri, 20 Jan 2017, Thierry Reding <thierry.reding at gmail.com> 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.
>
> That said, if everyone else thinks that it really can't be done and
> this workaround is the best way forward, I'll just shut up about it
> and stop caring.

Superficially, it is, of course, easy to agree we should handle deferred
probing.

i915 is a complex driver for complex hardware. We require a ton of
initialization before we even get to the point we realize we might need
the PWM. Naturally, we'd need to gracefully tear all that down for
-EPROBE_DEFER handling. And we've been slowly working towards this;
we've even added injected probe failures in CI to test this. But we're
not there yet. This patch seems like a rather simple workaround for the
time being.

There are two other related things I wonder about.

I see module reloading mostly as a developer feature. I don't think I'm
alone in that. You just don't recommend anyone doing module reloads in a
production environment. However, deferred probing is in some ways more
demanding than module reload, because it needs to gracefully handle
partial probes. Yet that is the solution of choice for init
ordering. Makes you wonder.

Another thing that comes up a lot with graphics is that people really do
appreciate any crappy degraded image over a black screen. If the PWM
never shows up, all the external screens will be black in addition to
the embedded display. We're always torn between failing fast
vs. plunging on despite failures.

---

That said, I suppose there could be an alternative to handling pwm_get()
failures at probe. We could just go on with our init, but schedule a
retry later. Perhaps a bit hacky, but it would address both of the
concerns above. Again, this patch seems a simple workaround in the mean
time.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center