[Intel-gfx] [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

Daniel Vetter daniel at ffwll.ch
Tue Mar 7 10:52:18 UTC 2017


On Tue, Mar 07, 2017 at 12:48:26PM +0200, Andy Shevchenko wrote:
> On Sun, 2017-02-26 at 22:45 +0100, Daniel Vetter wrote:
> > On Tue, Feb 21, 2017 at 06:52:24PM +0200, Andy Shevchenko wrote:
> > > On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> > > > On Tue, 21 Feb 2017, Andy Shevchenko <andriy.shevchenko at linux.inte
> > > > l.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.
> > 
> > Why exactly is this being discussed on an internal mailing list?
> > Upstream
> > happens in public ...
> 
> It was a prelininary discussion and it's sad you didn't notice it.

The problem isn't that I didn't notice (I don't think I can provide
anything of value here), but that technical discussion should happen in
the open, on public mailing lists, because otherwise we just have a big
coordination chaos. GFX is huge, and just the automatic public archiving
mailing lists provides is super important to get people up to speed when
suddenly you realize you need them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list