Message-ID: <CACRpkdY-yFKsYbCrMpnViMFoQEugyGQivaV0M+GDzLrbDO7i6Q@mail.gmail.com>
Date:	Wed, 14 Jan 2015 13:58:36 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Darren Hart <dvhart@...ux.intel.com>,
	Arnd Bergmann <arnd@...db.de>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding

On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
<heikki.krogerus@...ux.intel.com> wrote:

> This makes it possible to assign GPIOs at runtime. The
> motivation for it is because of need to forward GPIOs from
> one device to an other. That feature may be useful for
> example with some mfd devices, but initially it is needed
> because on some Intel Braswell based ACPI platforms the GPIO
> resources controlling signals of the USB PHY are given to
> the controller device object for whatever reason, so the
> driver of that controller needs be able to pass them to the
> PHY device somehow.
>
> So basically this is meant to allow patching of bad (bad
> from Linux kernels point of view) hardware descriptions
> provided by system fw in the drivers.
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> ---
>
> Hi,
>
> I'm sending this first as a RFC in case you guys have some better
> idea how to solve our problem. I actually already have couple
> platforms where the GPIO resources are given to the "wrong" device
> objects now.
>
> Originally we were thinking about simply handling our problem with
> hacks to the PHY drivers, basically also checking if the parent has
> GPIOs. That would only work if the controller is always the parent,
> which it's not, but even if it was, it would be too risky. The PHY
> drivers don't know which controller they are attached to, so what is
> to say that the GPIOs aren't really attached to the controller.
>
> So the safest way to handle our problem is to deal with it in quirks
> in the controller drivers. Solving it by bouncing the GPIOs did not
> feel ideal there doesn't seem to be any other way. The API is copied
> from clkdev (clk_register_clkdev). In the end it's really only one
> function for adding the lookups and one for removing them.
>
> The way it's implemented is by modifying the current style of handling
> the lookups a little bit. The per device lookup table is basically
> reverted back to the single linked-list format since it seems that
> these lookups may have to be assigned from several sources.

Oh ain't that great.

So now we start patching around the kernel because the ACPI
tables are erroneous for GPIOs. I'd like some feedback from
Rafael &| Darren on this patch, i.e. if you two think this is a good
way of accounting for bad GPIO descriptions in ACPI tables then
ACK this patch.

I guess the other option would be to fix up the ACPI DSDT
itself to put resources right, correct? Is this not possible?

Alexandre also need to ACK it before I dare do anything with
it.

Do we want to use the same mechanism for augmenting
bad device trees too?

What I like about it so far is the create/remove symmetry
though.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists