On Thu, Apr 24, 2014 at 04:40:25PM +0200, Thomas Gleixner wrote:
> On Thu, 24 Apr 2014, Linus Walleij wrote:
> > On Thu, Apr 24, 2014 at 9:25 AM, Thomas Gleixner wrote:
> >
> > > I'm traveling until friday, so please wait before you commit that
> > > fugly hack. I'll have a closer look how we
On Thu, Apr 24, 2014 at 04:40:25PM +0200, Thomas Gleixner wrote:
On Thu, 24 Apr 2014, Linus Walleij wrote:
On Thu, Apr 24, 2014 at 9:25 AM, Thomas Gleixner t...@linutronix.de wrote:
I'm traveling until friday, so please wait before you commit that
fugly hack. I'll have a closer look
On Thu, 24 Apr 2014, Linus Walleij wrote:
> On Thu, Apr 24, 2014 at 9:25 AM, Thomas Gleixner wrote:
>
> > I'm traveling until friday, so please wait before you commit that
> > fugly hack. I'll have a closer look how we can handle that at the core
> > level.
>
> Thanks a *lot* Thomas, I'll stand
On Thu, Apr 24, 2014 at 9:25 AM, Thomas Gleixner wrote:
> I'm traveling until friday, so please wait before you commit that
> fugly hack. I'll have a closer look how we can handle that at the core
> level.
Thanks a *lot* Thomas, I'll stand by for action.
Yours,
Linus Walleij
--
To unsubscribe
On Wed, 23 Apr 2014, Linus Walleij wrote:
> However this is a first time for an embedded irqchip (coupled
> with GPIO ACPI) creeping into the x86 world, so it needs some
> attention I think, do we have a direction forward for peaceful
> coexistence of several irq controllers picking some IRQ
>
On Wed, 23 Apr 2014, Linus Walleij wrote:
However this is a first time for an embedded irqchip (coupled
with GPIO ACPI) creeping into the x86 world, so it needs some
attention I think, do we have a direction forward for peaceful
coexistence of several irq controllers picking some IRQ
On Thu, Apr 24, 2014 at 9:25 AM, Thomas Gleixner t...@linutronix.de wrote:
I'm traveling until friday, so please wait before you commit that
fugly hack. I'll have a closer look how we can handle that at the core
level.
Thanks a *lot* Thomas, I'll stand by for action.
Yours,
Linus Walleij
--
On Thu, 24 Apr 2014, Linus Walleij wrote:
On Thu, Apr 24, 2014 at 9:25 AM, Thomas Gleixner t...@linutronix.de wrote:
I'm traveling until friday, so please wait before you commit that
fugly hack. I'll have a closer look how we can handle that at the core
level.
Thanks a *lot* Thomas,
On Wed, 2014-04-23 at 14:35 +0300, Mathias Nyman wrote:
> >
> > Urgent fix and the maintainers did not react in a week? Well maybe they need
> > to be on the To: line...
> >
> > Mathias: can you send a patch adding yourself as maintainer of this
> > driver in the MAINTAINERS file so stuff like
On Wed, Apr 23, 2014 at 1:35 PM, Mathias Nyman
wrote:
> The real issue to my understanding is that the x86 io-apic code is not
> really capable of living together with other interrupt controllers at the
> same time. There are some assumptions that interrupts 0-15 belong to the
> legacy ISA
Urgent fix and the maintainers did not react in a week? Well maybe they need
to be on the To: line...
Mathias: can you send a patch adding yourself as maintainer of this
driver in the MAINTAINERS file so stuff like this does not fall to the
floor (me)?
Hi,
Sorry about the delay. I'm taking
Urgent fix and the maintainers did not react in a week? Well maybe they need
to be on the To: line...
Mathias: can you send a patch adding yourself as maintainer of this
driver in the MAINTAINERS file so stuff like this does not fall to the
floor (me)?
Hi,
Sorry about the delay. I'm taking
On Wed, Apr 23, 2014 at 1:35 PM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
The real issue to my understanding is that the x86 io-apic code is not
really capable of living together with other interrupt controllers at the
same time. There are some assumptions that interrupts 0-15 belong
On Wed, 2014-04-23 at 14:35 +0300, Mathias Nyman wrote:
Urgent fix and the maintainers did not react in a week? Well maybe they need
to be on the To: line...
Mathias: can you send a patch adding yourself as maintainer of this
driver in the MAINTAINERS file so stuff like this does not
allocated_irqs, IRQ_BITMAP_BITS,
from, cnt, 0);
ret = -EEXIST;
/* Jin Yao: irq = 16, start = 17 */
/* A */ if (irq >=0 && start != irq)
goto err;
..
err:
}
When graphics driver probing, the irq is 16 and
bitmap_find_next_zero_area() returns 17. T
On Mon, Apr 14, 2014 at 4:48 AM, Jin, Yao wrote:
> A crash is triggered on the ASUS T100TA Baytrail-T because of a IRQ
> descriptor conflict. There are two gpio triggered acpi events in this
> device, GPIO 6 and 18. These gpios are translated to irqs by calling
> gpio_to_irq which in turn will
On Mon, Apr 14, 2014 at 4:48 AM, Jin, Yao yao@linux.intel.com wrote:
A crash is triggered on the ASUS T100TA Baytrail-T because of a IRQ
descriptor conflict. There are two gpio triggered acpi events in this
device, GPIO 6 and 18. These gpios are translated to irqs by calling
gpio_to_irq
controllers, eg gpio than io_apic.
2. fix graphics driver / bios to not request the not needed irq 16
Probably the above fixes need long time, so I decide to use a simple and
direct way by just shifting the irq for GPIO pins to avoid the conflict.
This patch [PATCH] pinctrl-baytrail: workaround for irq
A crash is triggered on the ASUS T100TA Baytrail-T because of a IRQ
descriptor conflict. There are two gpio triggered acpi events in this
device, GPIO 6 and 18. These gpios are translated to irqs by calling
gpio_to_irq which in turn will call irq_create_mapping(vg->domain, offset).
A crash is triggered on the ASUS T100TA Baytrail-T because of a IRQ
descriptor conflict. There are two gpio triggered acpi events in this
device, GPIO 6 and 18. These gpios are translated to irqs by calling
gpio_to_irq which in turn will call irq_create_mapping(vg-domain, offset).
20 matches
Mail list logo
