From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Jani Nikula" <jani.nikula@intel.com>,
"David Airlie" <airlied@linux.ie>,
"Daniel Vetter" <daniel.vetter@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID
Date: Tue, 21 Feb 2017 18:52:24 +0200 [thread overview]
Message-ID: <1487695944.20145.15.camel@linux.intel.com> (raw)
In-Reply-To: <87h93njyrx.fsf@intel.com>
On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Andy Shevchenko <andriy.shevchenko@linux.intel.co
> m> wrote:
> > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> > support") enables GPIO support for Broxton based platforms.
> >
> > While using that API we might get into troubles in the future,
> > because
> > we can't rely on label "panel" in the driver since vendor firmware
> > might
> > provide any GPIO pin there, e.g. "reset", and even mark it in _DSD
> > (in
> > which case the request will fail).
> >
> > To avoid inconsistency and potential issues we have two options:
> > a) generate GPIO ACPI mapping table and supply it via
> > acpi_dev_add_driver_gpios(), or
> > b) just pass NULL as connection ID.
> >
> > The b) approach is much simplier and would work since the driver
> > relies
> > on GPIO indeces only. Moreover, the _CRS fallback mechanism, when
> > requesting GPIO, is going to be stricter, and supplying non-NULL
> > connection ID when neither _DSD, nor GPIO ACPI mapping is present,
> > will
> > make request fail.
>
> The patch version log in the commit suggests otherwise; we'd tried and
> failed with NULL,
Can I see DSDT excerpts of the platform that fails?
> until Mika realized passing "panel" works:
>
> v2 by Mika: switch *NULL* to *"panel"* when requesting gpio for
> MIPI/DSI
> panel.
>
> See also [1]. What has changed since then that should make this work
> now? We shouldn't apply until we get Tested-by's.
Not changed yet, but *going to be*. See my repository here [2].
To fix the mess with GPIO ACPI stuff we are going to make request
stricter as I pointed in commit message above, i.e. asking for a GPIO by
connection ID without _DSD present will guarantee -ENOENT since it will
be no fallback to _CRS. You may follow discussion in our internal
mailing list for drivers.
> [1] http://mid.mail-archive.com/1480597671.26172.82.camel@intel.com
[2] http://bitbucket.org/andy-shev/linux/branch/topic%2Fuart%2frpm
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-02-21 16:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 15:19 [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID Andy Shevchenko
2017-02-21 16:26 ` Jani Nikula
2017-02-21 16:52 ` Andy Shevchenko [this message]
2017-02-26 21:45 ` [Intel-gfx] " Daniel Vetter
2017-03-07 10:48 ` Andy Shevchenko
2017-03-07 10:52 ` Daniel Vetter
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=1487695944.20145.15.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=ville.syrjala@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