[Intel-gfx] [PATCH] drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in dsi_init

Shobhit Kumar kumar at shobhit.info
Sat Jul 16 10:39:17 UTC 2016


On Sat, Jul 16, 2016 at 3:12 AM, Stephen J <stephenjust at gmail.com> wrote:
> On Fri, Jul 15, 2016 at 3:08 AM, Shobhit Kumar <kumar at shobhit.info> wrote:
>>
>> On Fri, Jul 15, 2016 at 2:33 PM, Shobhit Kumar <shobhit.kumar at intel.com> wrote:
>> > On devices that have MIPI DSI panel control and PWM control comming from
>> > CRC PMIC, we need the gpio and pwm exported from the intel_soc_pmic
>> > driver. Defer probing for later in case we fail to get these devices.
>> >
>> > v2: Rebased on latest drm-intel-nightly
>> >     Added failure check for pwm_get which got missed out
>> >
>>
>> [snip]
>>
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
>> > index b9a8117..9bfe0c8 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.c
>> > +++ b/drivers/gpu/drm/i915/i915_drv.c
>> > @@ -648,6 +648,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
>> >         /* Important: The output setup functions called by modeset_init need
>> >          * working irqs for e.g. gmbus and dp aux transfers. */
>> >         intel_modeset_init(dev);
>> > +       ret = intel_modeset_init(dev);
>> > +       if (ret == -EPROBE_DEFER)
>> > +               goto cleanup_deffered_probe;
>
> Did you intend to call intel_modeset_init twice? In my tests, I
> removed the first copy because it seemed like a mistake.
>

Nope I did not. It was a mistake. Thanks for pointing out.

>> >
>> >         intel_guc_init(dev);
>> >
>> > @@ -675,6 +678,7 @@ cleanup_gem:
>> >         i915_gem_fini(dev);
>> >  cleanup_irq:
>> >         intel_guc_fini(dev);
>> > +cleanup_deffered_probe:
>> >         drm_irq_uninstall(dev);
>> >         intel_teardown_gmbus(dev);
>> >  cleanup_csr:
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> > index 03e1bfa..a9eed22 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.h
>> > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > @@ -3778,7 +3778,7 @@ void intel_device_info_dump(struct drm_i915_private *dev_priv);
>> >
>> >  /* modesetting */
>> >  extern void intel_modeset_init_hw(struct drm_device *dev);
>> > -extern void intel_modeset_init(struct drm_device *dev);
>> > +extern int intel_modeset_init(struct drm_device *dev);
>> >  extern void intel_modeset_gem_init(struct drm_device *dev);
>> >  extern void intel_modeset_cleanup(struct drm_device *dev);
>> >  extern int intel_connector_register(struct drm_connector *);
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> > index be3b2ca..b1250f2 100644
>> > [snip]
>
> When testing on drm-intel-nightly, my system froze with your patch. I
> can't get a full dmesg because I haven't yet found a way to trigger
> the problem after I can get an ssh session up.
>
> The relevant logs I see before freeze are:
> [drm] Initialized drm 1.1.0 20060810
> [drm] Memory usable by graphics device = 2048M
> fb: switching to inteldrmfb from EFI VGA
>
> console is stuck at this point, my guess is that modeset fails and
> that isn't handled well. The screen does not go black, the log
> messages just stay on screen indefinitely.

Will try to force deferred probe on one of my device which has serial
console to get the serial logs and debug deferred probe in general.

Regards
Shobhit

>
> If I blacklist i915 and let X load the module (or manually load it
> later), everything seems to run fine and backlight works, but that was
> also true before applying the patch.
>
> Regards,
> Stephen


More information about the Intel-gfx mailing list