[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdaPJaZb7z+ua91MJ_krDRXGSaZS_5_3vHc7VcAFjUfdfQ@mail.gmail.com>
Date: Tue, 25 Jun 2013 16:32:52 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Stephen Warren <swarren@...dotorg.org>
Cc: Christian Ruppert <christian.ruppert@...lis.com>,
Patrice CHOTARD <patrice.chotard@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Grant Likely <grant.likely@...retlab.ca>,
Rob Herring <rob.herring@...xeda.com>,
Rob Landley <rob@...dley.net>,
Sascha Leuenberger <sascha.leuenberger@...lis.com>,
Pierrick Hascoet <pierrick.hascoet@...lis.com>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Alexandre Courbot <acourbot@...dia.com>
Subject: Re: [PATCH 2/2] Make non-linear GPIO ranges accesible from gpiolib
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 06/20/2013 05:57 AM, Christian Ruppert wrote:
> The Linux pinctrl subsystem specifically doesn't provide mutual
> exclusion between "mux function" and GPIO usage within a pin group,
> although perhaps a driver could internally.
It used to block this at one point. But it doesn't make sense
when the hardware looks like so:
>> +- SPI
>> Physical pins --- GPIO --- pinctrl -+- I2C
>> +- mmc
As in this case it is perfectly legal to enable the GPIO as
input while the I2C bus is running and "spy" on the signals.
The driver should probably not allow the GPIO output to be
driven while some peripheral is muxed in though, that could be
disastrous...
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