Linux PWM subsystem development
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm@vger.kernel.org,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH v2] pwm: lpss: Make builtin so that i915 can find the pwm_backlight
Date: Fri, 20 Jan 2017 08:50:50 +0100	[thread overview]
Message-ID: <19a3bd82-8199-683d-d1f5-6da5c653be18@redhat.com> (raw)
In-Reply-To: <20170120071853.GE4894@ulmo.ba.sec>

Hi,

On 20-01-17 08:18, Thierry Reding wrote:
> 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@redhat.com>
>>> Acked-by: Jani Nikula <jani.nikula@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".

I will let the i915 devs answer this.

IIRC a lot of setup is already done at this point, including some changes
to the hw and we really do not want to change the init-sequence, or
repeat parts of it.

I myself was actually thinking about solving this by figuring out if the
pwm is necessary and getting it early on, but the figuring out bit is non
trivial.

Anyways as said I will let the i915 devs answer this.

Regards,

Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-01-20  7:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-19 17:58 [PATCH v2] pwm: lpss: Make builtin so that i915 can find the pwm_backlight Hans de Goede
2017-01-20  7:03 ` Thierry Reding
2017-01-20  7:18   ` Thierry Reding
2017-01-20  7:50     ` Hans de Goede [this message]
2017-01-20  8:02   ` Jani Nikula
2017-01-20  8:56     ` Thierry Reding
2017-01-20  9:48       ` Hans de Goede
2017-01-20  9:55         ` Andy Shevchenko
2017-01-20 10:18           ` Hans de Goede
2017-01-20 10:42             ` Thierry Reding
2017-01-22 16:21               ` Hans de Goede
2017-01-20  9:58         ` Thierry Reding
2017-01-20  9:55     ` Mika Westerberg
2017-03-08  9:40       ` Jani Nikula
2017-03-08  9:48         ` Hans de Goede
2017-03-08 10:15           ` Jani Nikula
2017-03-08 13:41             ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19a3bd82-8199-683d-d1f5-6da5c653be18@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox