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 fall to the > > floor (me)? > > > > Hi, > > Sorry about the delay. I'm taking over Sarah's role as usb3 xhci > maintainer and got my hands full over there. I can look at these > patches now and then but you might need to kick me. > > In general, I'd agree with Mika, Andy and Heikki (and Rafael obviously) > opinion regarding baytrail gpio / acpi related matters.
This patch and discussion reminds me an old one where I was trying to solve quite similar issue on Medfield [1], in particular [2, and 3]. For my opinion irq mapping framework should be redesigned to solve the issue regarding to devices which require fixed interrupt lines. [1] https://lkml.org/lkml/2012/7/5/152 [2] https://lkml.org/lkml/2012/7/5/155 [3] https://lkml.org/lkml/2012/7/16/173 > > > Second: this fix is ugly like hell, is it really the best we can think > > of, plus in the commit message I'd very much like to know the > > real issue behind this as people in the x86 camp seem to be > > using some strange static IRQ line assignments that I cannot > > really understand so I don't know what the proper fix for this is :-( > > > > This patch went out a bit early, a new version (which is not mangled) > can be found at: > > http://marc.info/?l=linux-kernel&m=139765010717522&w=2 > > But that one still produces some compiler warning which should be fixed. > > There might be some touchscreen related issues recently found related to > this patch that need to be investigated ( see bug link in commit message) > > This is a hack to get T100TA working. This is one of many bad ways to > workaround the real issue instead of fixing it, and I hope it can be > reverted later, but this is the best we can do with our (my) limited > io-apic and interrupt knowledge. But in the end, with this the Asus > T100TA gpio works somehow, without it, it doesn't. > > 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 world, from there on we got io-apic PCI interrupts > ( I think io-apic interrupt controller handles something like 24 - 48 > interrupts?) we want to be outside that range until this is fixed. > > The x86 io-apic code does nasty things, for example the function > that allocates the irq and the private chip data assumes that if the irq > descriptor is taken, (returns -EEXISTS) then io-apic just must have > reserved it earlier and can anyway use it, and access the chip data in a > format only io-apic (struct irq_cfg) uses. This is of course not the > case if a gpio interrupt controller like pinctrl-baytrail reserved the > interrupt descriptor earler. -> oops > > here's the io_apic.c function: > > static struct irq_cfg *alloc_irq_and_cfg_at(unsigned int at, int node) > { > int res = irq_alloc_desc_at(at, node); > struct irq_cfg *cfg; > > if (res < 0) { > if (res != -EEXIST) > return NULL; > cfg = irq_get_chip_data(at); > if (cfg) > return cfg; > } > > cfg = alloc_irq_cfg(at, node); > if (cfg) > irq_set_chip_data(at, cfg); > else > irq_free_desc(at); > return cfg; > } > > We tried to fix this particular issue (make sure the interrupt belongs > to a io_apic controller before letting io_apic touch it), but we just > opened a can of worms of other issues I don't know how to deal with. > > -Mathias > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
