From: Daniel Vetter <daniel@ffwll.ch>
To: "Kumar, Shobhit" <shobhit.kumar@linux.intel.com>
Cc: jani.nikula@intel.com, Daniel Vetter <daniel.vetter@intel.com>,
intel-gfx@lists.freedesktop.org, bloften80@gmail.com
Subject: Re: [PATCH] drm/i915: Retry few time if gpiod_get fails during intel_dsi_init
Date: Wed, 20 Jan 2016 10:01:56 +0100 [thread overview]
Message-ID: <20160120090156.GY19130@phenom.ffwll.local> (raw)
In-Reply-To: <569F476E.2050004@linux.intel.com>
On Wed, Jan 20, 2016 at 02:08:06PM +0530, Kumar, Shobhit wrote:
>
> On 01/20/2016 01:50 AM, Daniel Vetter wrote:
> >On Tue, Jan 19, 2016 at 09:00:40PM +0530, Kumar, Shobhit wrote:
> >>On 01/19/2016 08:45 PM, Shobhit Kumar wrote:
> >>>INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get and
> >>>pwm_get calls in i915. Add a retry to give time for the INTEL_SOC_PMIC
> >>>to load. This was fine till now but broke in latest kernel. Maybe load
> >>>time for the INTEL_SOC_PMIC has increased.
> >>>
> >>>Since the lookup tables for GPIO (panel enable) and PWM both are
> >>>exported by same intel_soc_pmic driver, just retrying for the driver to
> >>>load in intel_dsi_init is sufficient. By the time we come to
> >>>setup_backlight, pwm would have been exported as well.
> >>
> >>Maybe we should play with initcalls here but I was not sure how it will
> >>impact if I change it for PMIC driver. IIRC, this discussion came up from
> >>Daniel at the time of original patches also but somehow did not close
> >>decidedly and has come back as a regression.
> >
> >The correct way to handle this is to bail out with -EPROBE_DEFER. This is
> >how this is meant to be, no amount of random retrying will fix this
> >properly for such dynamic inter-module depencies.
>
> Yeah, you are right, retries are working pretty randomly. I made a quick
> changes all the way up to i915_driver_load returning -EPROBE_DEFER form
> intel_setup_outputs and it seems to work.
>
> >
> >And yes this is going to be a world-class test for our module load unwind
> >code.
>
> Well it seems to be working :) Will have a cleaned up patch for review. Also
> need to take care of this in the LPSS_PWM patches as well.
You're extremely lucky then I'd say. Let's see whether CI agrees and then
merge this ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-01-20 9:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 15:15 [PATCH] drm/i915: Retry few time if gpiod_get fails during intel_dsi_init Shobhit Kumar
2016-01-19 15:30 ` Kumar, Shobhit
2016-01-19 20:20 ` Daniel Vetter
2016-01-20 8:38 ` Kumar, Shobhit
2016-01-20 9:01 ` Daniel Vetter [this message]
2016-01-19 15:49 ` ✓ Fi.CI.BAT: success for " Patchwork
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=20160120090156.GY19130@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=bloften80@gmail.com \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=shobhit.kumar@linux.intel.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