On 06/25/2013 05:59 AM, Christian Ruppert wrote:
> On Fri, Jun 21, 2013 at 03:17:33PM -0600, Stephen Warren wrote:
...
> To define some terminology, let's call a set of pins affected by the
> same register / bit field a "port".
Well, the terminology "group" already exists for this really, but I
On Tue, Jun 25, 2013 at 5:39 PM, Stephen Warren wrote:
> On 06/25/2013 09:28 AM, Linus Walleij wrote:
>> But I do seem to recall some endless discussions about this,
>> I think we need to agree to disagree.
>
> But the whole point of a subsystem is to provide clear common semantics
> across all
On Tue, Jun 25, 2013 at 5:31 PM, Stephen Warren wrote:
> On 06/25/2013 08:56 AM, Linus Walleij wrote:
>> On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren
>> wrote:
>>> On 06/20/2013 05:57 AM, Christian Ruppert wrote:
>>
Your remark seems to reflect one of the following two hardware
On 06/25/2013 08:56 AM, Linus Walleij wrote:
> On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren
> wrote:
>> On 06/20/2013 05:57 AM, Christian Ruppert wrote:
>
>>> Your remark seems to reflect one of the following two hardware
>>> architectures:
>>>
>>>
On 06/25/2013 09:28 AM, Linus Walleij wrote:
> On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren
> wrote:
>
>> And finally, I don't really like using pin groups for the purpose of
>> defining these mappings, since I intended them to purely represent the
>> mapping from register fields to the set
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren wrote:
> And finally, I don't really like using pin groups for the purpose of
> defining these mappings, since I intended them to purely represent the
> mapping from register fields to the set of affected pins. However, I can
> see an argument for
On 06/25/2013 08:32 AM, Linus Walleij wrote:
> On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren
> 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
On 06/25/2013 08:27 AM, Linus Walleij wrote:
> On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren
> wrote:
>
>> When I pushed for the concept of groups, I intended it to mean precisely
>> one single thing. The points below describe this.
>>
>> 1) A pin is a single pin/ball/pad on the package.
>>
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren wrote:
> On 06/20/2013 05:57 AM, Christian Ruppert wrote:
>> Your remark seems to reflect one of the following two hardware
>> architectures:
>>
>> +- SPI
>> Physical pins ---
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren 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
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren wrote:
> When I pushed for the concept of groups, I intended it to mean precisely
> one single thing. The points below describe this.
>
> 1) A pin is a single pin/ball/pad on the package.
>
> 2) Some register fields affect just a single pin. For
On Fri, Jun 21, 2013 at 03:17:33PM -0600, Stephen Warren wrote:
> On 06/20/2013 05:57 AM, Christian Ruppert wrote:
> > Hello Stephen,
> >
> > On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
> >> On 06/19/2013 12:10 PM, Stephen Warren wrote:
> >>> On 06/14/2013 03:12 AM, Christian
On Fri, Jun 21, 2013 at 03:17:33PM -0600, Stephen Warren wrote:
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
Hello Stephen,
On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
On 06/19/2013 12:10 PM, Stephen Warren wrote:
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org wrote:
When I pushed for the concept of groups, I intended it to mean precisely
one single thing. The points below describe this.
1) A pin is a single pin/ball/pad on the package.
2) Some register fields affect just a
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.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
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
Your remark seems to reflect one of the following two hardware
architectures:
+- SPI
Physical
On 06/25/2013 08:27 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
When I pushed for the concept of groups, I intended it to mean precisely
one single thing. The points below describe this.
1) A pin is a single pin/ball/pad on the
On 06/25/2013 08:32 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.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
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org wrote:
And finally, I don't really like using pin groups for the purpose of
defining these mappings, since I intended them to purely represent the
mapping from register fields to the set of affected pins. However, I can
On 06/25/2013 09:28 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
And finally, I don't really like using pin groups for the purpose of
defining these mappings, since I intended them to purely represent the
mapping from register
On 06/25/2013 08:56 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
Your remark seems to reflect one of the following two hardware
architectures:
On Tue, Jun 25, 2013 at 5:31 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/25/2013 08:56 AM, Linus Walleij wrote:
On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
Your remark seems to reflect one of the
On Tue, Jun 25, 2013 at 5:39 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/25/2013 09:28 AM, Linus Walleij wrote:
But I do seem to recall some endless discussions about this,
I think we need to agree to disagree.
But the whole point of a subsystem is to provide clear common semantics
On 06/25/2013 05:59 AM, Christian Ruppert wrote:
On Fri, Jun 21, 2013 at 03:17:33PM -0600, Stephen Warren wrote:
...
To define some terminology, let's call a set of pins affected by the
same register / bit field a port.
Well, the terminology group already exists for this really, but I
suppose
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
> Hello Stephen,
>
> On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
>> On 06/19/2013 12:10 PM, Stephen Warren wrote:
>>> On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
Hello Stephen,
On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
On 06/19/2013 12:10 PM, Stephen Warren wrote:
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On
Hello Stephen,
On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
> On 06/19/2013 12:10 PM, Stephen Warren wrote:
> > On 06/14/2013 03:12 AM, Christian Ruppert wrote:
> >> On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
> >>> On 06/13/2013 06:55 AM, Christian Ruppert
Hello Stephen,
On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
On 06/19/2013 12:10 PM, Stephen Warren wrote:
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
On 06/19/2013 12:10 PM, Stephen Warren wrote:
> On 06/14/2013 03:12 AM, Christian Ruppert wrote:
>> On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
>>> On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
> On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
>> On 06/13/2013 06:55 AM, Christian Ruppert wrote:
>>> This patch adds the infrastructure required to register non-linear gpio
>>> ranges through gpiolib and the standard GPIO device
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree
On 06/19/2013 12:10 PM, Stephen Warren wrote:
On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
> On 06/13/2013 06:55 AM, Christian Ruppert wrote:
> [...]
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
> > b/Documentation/devicetree/bindings/gpio/gpio.txt
>
> > +In addition, named groups of pins can be mapped
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
[...]
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
+In addition, named groups of pins can be mapped to pin
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
> On 06/13/2013 06:55 AM, Christian Ruppert wrote:
> > This patch adds the infrastructure required to register non-linear gpio
> > ranges through gpiolib and the standard GPIO device tree bindings.
>
> That's not exactly true. The
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
That's not exactly true. The existing
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
> This patch adds the infrastructure required to register non-linear gpio
> ranges through gpiolib and the standard GPIO device tree bindings.
That's not exactly true. The existing gpio-ranges property already
allows non-linear ranges to be
On Thu, Jun 13, 2013 at 2:55 PM, Christian Ruppert
wrote:
> This patch adds the infrastructure required to register non-linear gpio
> ranges through gpiolib and the standard GPIO device tree bindings.
>
> Signed-off-by: Christian Ruppert
Splendid. I'll just wait some more time before applying
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
Signed-off-by: Christian Ruppert
---
Documentation/devicetree/bindings/gpio/gpio.txt | 37 ++
drivers/gpio/gpiolib-of.c
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
---
Documentation/devicetree/bindings/gpio/gpio.txt | 37 ++
On Thu, Jun 13, 2013 at 2:55 PM, Christian Ruppert
christian.rupp...@abilis.com wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
That's not exactly true. The existing gpio-ranges property already
allows non-linear ranges to be
42 matches
Mail list logo
