[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYTriHeSQz0St6kVDEtMcbMDK+LUr=n9TYzGQ6RnSaG6w@mail.gmail.com>
Date: Thu, 11 Aug 2016 13:50:33 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Álvaro Fernández Rojas <noltari@...il.com>
Cc: "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alexandre Courbot <gnurou@...il.com>,
Christian Lamparter <chunkeey@...glemail.com>
Subject: Re: [PATCH v2 2/2] gpio: mmio: add brcm,bcm6345 support
On Wed, Aug 3, 2016 at 2:05 PM, Álvaro Fernández Rojas
<noltari@...il.com> wrote:
> From: Christian Lamparter <chunkeey@...glemail.com>
>
> This patch adds support for the GPIO found in Broadcom's bcm63xx-gpio
> chips.
> This GPIO controller is used in the following Broadcom SoCs: BCM6338, BCM6345.
> It can be used in newer SoCs, without the capability of pin multiplexing.
>
> Signed-off-by: Christian Lamparter <chunkeey@...glemail.com>
> Signed-off-by: Álvaro Fernández Rojas <noltari@...il.com>
> ---
> v2: fix build
Aha now I understand why the binding looks like it does.
Sorry for being too stupid to understand it was using the
generic GPIO MMIO bindings :(
I see that it is tempting to use MMIO for this. But surely,
with all the registers you left out, this controller can do a bunch of
other stuff with the registers you're not using right now.
I think the right solution is to use GPIO_GENERIC but create
a unque GPIO driver for this hardware. It's just not that simple,
if you look at the register map, can this hardware also do open
drain? Interrupts? Biasing? etc. Then it needs its own driver,
it can use the generic GPIO library but still needs its own driver.
Yours,
Linus Walleij
Powered by blists - more mailing lists