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@xxxxxxxxxxxxxx
> > 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 ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
