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@xxxxxxxxxx
> > > 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.
Nevertheless, Hans started it in public mailing list here [1].
I would include you in Cc list for my further replies there.
Mika K., my branch is here [2] with above patch included. Can you,
please, test your use case? Because it sounds too strange to me that
connection ID in there affects somehow the PM flow. It very likely
unveils a bug somewhere else.
[1] https://www.spinics.net/lists/linux-input/msg49127.html
[2] http://bitbucket.org/andy-shev/linux/branch/topic%2Fuart%2frpm
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
