[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZUJsqCG=dd9XdwxaAHxEHXgrZncH+DqtPYta4a30v87w@mail.gmail.com>
Date: Wed, 16 Mar 2016 11:10:21 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Maxime Ripard <maxime.ripard@...e-electrons.com>,
Alexandre Courbot <gnurou@...il.com>,
Lee Jones <lee.jones@...aro.org>, Chen-Yu Tsai <wens@...e.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [linux-sunxi] Re: [PATCH 0/4] Add AXP209 GPIO driver
On Wed, Mar 9, 2016 at 4:44 PM, Hans de Goede <hdegoede@...hat.com> wrote:
>> On Wed, Mar 09, 2016 at 01:17:50PM +0100, Hans de Goede wrote:
>> Eventually, yes, it needs both. But they don't even have to be the
>> same driver, since they provide two different features. The only
>> reason we have that construct in the pio case is because they share
>> the same address space, but in the AXP case, the regmap and our mfd
>> take care of that already.
>
> Hmm, so your suggesting to have mfd instantiate 2 platform devices
> for this, a gpio and a pinctrl device, each with their own
> driver. Yes that would work, but I'm a bit worried about the 2
> racing or some such since they both will end up touching
> bit 0-2 of register 0x90 / 0x92, more-over since they are both
> touching the exact same bits I've the feeling that this really
> should be one driver.
We can put the driver in drivers/pinctrl/pinctrl-axp209.c from day
one, add in comments stating that it only implements GPIO
for now and that the GPIO portion must call
pinctrl_request_gpio() and the pin controller must implement
.gpio_request_enable() the day it is added so the GPIOs do
not conflict with other use of the pins.
Requireing a huge slew of upfront code is a bit hard on simple
drivers I think.
Also we have the solution in drivers/mfd/stmpe.c that just add
a simple mux code when pins on mixsigs or simple expanders
can just mux some two-three different functions, then I think
pin control may be a bit too thick overhead. (Not sure where
the limit is though.)
Yours,
Linus Walleij
Powered by blists - more mailing lists