On Fri, Aug 30, 2013 at 10:08 PM, Stephen Warren wrote:
> On 08/29/2013 01:00 PM, Linus Walleij wrote:
>> No but I think there should be one ... maybe I'm an oddball
>> but it seems natural to request a GPIO before tying
>> IRQs to fire off it.
>
> What if there is no GPIO?
>
> There are plenty o
Am Freitag, 30. August 2013, 14:08:41 schrieb Stephen Warren:
> On 08/29/2013 01:00 PM, Linus Walleij wrote:
> > On Fri, Aug 23, 2013 at 9:52 PM, Stephen Warren
wrote:
> >> On 08/23/2013 12:45 PM, Linus Walleij wrote:
> >>> This is a perfectly OK thing to do as long as it is done like
> >>> this:
On 08/29/2013 01:00 PM, Linus Walleij wrote:
> On Fri, Aug 23, 2013 at 9:52 PM, Stephen Warren wrote:
>> On 08/23/2013 12:45 PM, Linus Walleij wrote:
>
>>> This is a perfectly OK thing to do as long as it is done like
>>> this:
>>>
>>> request_gpio(gpio);
>>> gpio_direction_input(gpio);
>>> reque
On Fri, Aug 23, 2013 at 9:52 PM, Stephen Warren wrote:
> On 08/23/2013 12:45 PM, Linus Walleij wrote:
>> This is a perfectly OK thing to do as long as it is done like
>> this:
>>
>> request_gpio(gpio);
>> gpio_direction_input(gpio);
>> request_irq(gpio_to_irq(gpio));
>
> But I'm not aware that th
On Fri, Aug 23, 2013 at 9:49 PM, Stephen Warren wrote:
> On 08/23/2013 12:38 PM, Linus Walleij wrote:
>> It can't be stopped but I consider it a bug if they do, as the proper
>> way to handle such GPIO lines is the sequence:
>>
>> request_gpio(gpio);
>> request_irq(gpio_to_irq(gpio));
>
> Back in
On 08/26/2013 04:45 AM, Lars Poeschel wrote:
> On Friday 23 August 2013 at 21:52:20, Stephen Warren wrote:
>> On 08/23/2013 12:45 PM, Linus Walleij wrote:
>>> On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren
> wrote:
On 08/21/2013 05:36 PM, Linus Walleij wrote:
> On Thu, Aug 22, 2013 at
On 2013-08-26 16:04, Lars Poeschel wrote:
On Monday 26 August 2013 at 13:29:07, Andreas Larsson wrote:
On 2013-08-26 12:56, Lars Poeschel wrote:
This call to of_irq_find_parent breaks gpiolib-of for SPARC due to
the fact that the function is undefined when !defined(CONFIG_OF_IRQ)
&& defined(CON
On Monday 26 August 2013 at 13:29:07, Andreas Larsson wrote:
> On 2013-08-26 12:56, Lars Poeschel wrote:
> > Hi Andreas!
> >
> > On Thursday 22 August 2013 at 15:16:18, Andreas Larsson wrote:
> >> On 2013-08-21 15:38, Lars Poeschel wrote:
> >>> +static void of_gpio_scan_irq_lines(const struct devi
On 2013-08-26 12:56, Lars Poeschel wrote:
Hi Andreas!
On Thursday 22 August 2013 at 15:16:18, Andreas Larsson wrote:
On 2013-08-21 15:38, Lars Poeschel wrote:
+static void of_gpio_scan_irq_lines(const struct device_node *const
node, +struct device_node *const gcn,
+
Hi Andreas!
On Thursday 22 August 2013 at 15:16:18, Andreas Larsson wrote:
> On 2013-08-21 15:38, Lars Poeschel wrote:
> > +static void of_gpio_scan_irq_lines(const struct device_node *const
> > node, +struct device_node *const gcn,
> > +
On Friday 23 August 2013 at 21:52:20, Stephen Warren wrote:
> On 08/23/2013 12:45 PM, Linus Walleij wrote:
> > On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren
wrote:
> >> On 08/21/2013 05:36 PM, Linus Walleij wrote:
> >>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
> >>> wrote: [Me]
> >>>
On Friday 23 August 2013 at 21:48:43, Stephen Warren wrote:
> On 08/23/2013 03:40 AM, Lars Poeschel wrote:
> > On Thursday 22 August 2013 at 23:10:53, Stephen Warren wrote:
> >> On 08/21/2013 05:36 PM, Linus Walleij wrote:
> >>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
> >>> wrote: [Me]
> >
On 08/23/2013 01:55 PM, Tomasz Figa wrote:
> On Friday 23 of August 2013 13:52:20 Stephen Warren wrote:
>> On 08/23/2013 12:45 PM, Linus Walleij wrote:
>>> On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren
> wrote:
On 08/21/2013 05:36 PM, Linus Walleij wrote:
> On Thu, Aug 22, 2013 at 1:1
On Friday 23 of August 2013 13:52:20 Stephen Warren wrote:
> On 08/23/2013 12:45 PM, Linus Walleij wrote:
> > On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren
wrote:
> >> On 08/21/2013 05:36 PM, Linus Walleij wrote:
> >>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
> >>> wrote: [Me]
> >>>
>
On 08/23/2013 12:45 PM, Linus Walleij wrote:
> On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren
> wrote:
>> On 08/21/2013 05:36 PM, Linus Walleij wrote:
>>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
>>> wrote:
>>> [Me]
>> check if these in turn reference the interrupt-controller, and
On 08/23/2013 12:38 PM, Linus Walleij wrote:
> On Thu, Aug 22, 2013 at 10:53 PM, Stephen Warren
> wrote:
>> On 08/21/2013 05:27 PM, Linus Walleij wrote:
>>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
>>> wrote:
> On Wednesday 21 of August 2013 15:38:54 Lars Poeschel wrote:
>>>
>> T
On 08/23/2013 03:40 AM, Lars Poeschel wrote:
> On Thursday 22 August 2013 at 23:10:53, Stephen Warren wrote:
>> On 08/21/2013 05:36 PM, Linus Walleij wrote:
>>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
>>> wrote: [Me]
>>>
>> check if these in turn reference the interrupt-controller, and
On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren wrote:
> On 08/21/2013 05:36 PM, Linus Walleij wrote:
>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
>> wrote:
>> [Me]
> check if these in turn reference the interrupt-controller, and
> if they do, loop over the interrupts used by that
On Thu, Aug 22, 2013 at 10:53 PM, Stephen Warren wrote:
> On 08/21/2013 05:27 PM, Linus Walleij wrote:
>> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
>> wrote:
On Wednesday 21 of August 2013 15:38:54 Lars Poeschel wrote:
>>
> To solve this dilemma, perform an interrupt consistency c
On Thursday 22 August 2013 at 22:53:09, Stephen Warren wrote:
> On 08/21/2013 05:27 PM, Linus Walleij wrote:
> > On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
wrote:
> >>> On Wednesday 21 of August 2013 15:38:54 Lars Poeschel wrote:
> To solve this dilemma, perform an interrupt consistency
On Thursday 22 August 2013 at 23:10:53, Stephen Warren wrote:
> On 08/21/2013 05:36 PM, Linus Walleij wrote:
> > On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren
> > wrote: [Me]
> >
> check if these in turn reference the interrupt-controller, and
> if they do, loop over the interrupts us
On Thursday 22 of August 2013 15:08:12 Stephen Warren wrote:
> On 08/22/2013 03:01 AM, Lars Poeschel wrote:
> > On Thursday 22 August 2013 at 01:10:27, Stephen Warren wrote:
> >> On 08/21/2013 03:49 PM, Tomasz Figa wrote:
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> >
On 08/21/2013 05:36 PM, Linus Walleij wrote:
> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren wrote:
> [Me]
check if these in turn reference the interrupt-controller, and
if they do, loop over the interrupts used by that child and
perform gpio_request() and gpio_direction_input() o
On 08/22/2013 03:01 AM, Lars Poeschel wrote:
> On Thursday 22 August 2013 at 01:10:27, Stephen Warren wrote:
>> On 08/21/2013 03:49 PM, Tomasz Figa wrote:
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
+ */
+ if (irq_domain && i
On 08/21/2013 05:27 PM, Linus Walleij wrote:
> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren wrote:
>>> On Wednesday 21 of August 2013 15:38:54 Lars Poeschel wrote:
>
To solve this dilemma, perform an interrupt consistency check
when adding a GPIO chip: if the chip is both gpio-contro
On 2013-08-21 15:38, Lars Poeschel wrote:
+static void of_gpio_scan_irq_lines(const struct device_node *const node,
+ struct device_node *const gcn,
+ struct irq_domain *const irq_domain,
+ const u3
On Thursday 22 August 2013 at 01:10:27, Stephen Warren wrote:
> On 08/21/2013 03:49 PM, Tomasz Figa wrote:
> >> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> >>
> >> +static void of_gpio_scan_irq_lines(const struct device_node *const
> >>
> >> + for (i = 0; i < int
On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren wrote:
[Me]
>>> check if these in turn reference the interrupt-controller, and
>>> if they do, loop over the interrupts used by that child and
>>> perform gpio_request() and gpio_direction_input() on these,
>>> making them unreachable from the GPIO s
On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren wrote:
>> On Wednesday 21 of August 2013 15:38:54 Lars Poeschel wrote:
>>> To solve this dilemma, perform an interrupt consistency check
>>> when adding a GPIO chip: if the chip is both gpio-controller and
>>> interrupt-controller, walk all children
On 08/21/2013 03:49 PM, Tomasz Figa wrote:
> Hi Lars, Linus,
>
> On Wednesday 21 of August 2013 15:38:54 Lars Poeschel wrote:
>> From: Linus Walleij
>>
>> Currently the kernel is ambigously treating GPIOs and interrupts
>> from a GPIO controller: GPIOs and interrupts are treated as
>> orthogonal.
Hi Lars, Linus,
On Wednesday 21 of August 2013 15:38:54 Lars Poeschel wrote:
> From: Linus Walleij
>
> Currently the kernel is ambigously treating GPIOs and interrupts
> from a GPIO controller: GPIOs and interrupts are treated as
> orthogonal. This unfortunately makes it unclear how to actually
From: Linus Walleij
Currently the kernel is ambigously treating GPIOs and interrupts
from a GPIO controller: GPIOs and interrupts are treated as
orthogonal. This unfortunately makes it unclear how to actually
retrieve and request a GPIO line or interrupt from a GPIO
controller in the device tree
32 matches
Mail list logo
