On Mon, Apr 09, 2007 at 06:42:40PM +0400, Sergei Shtylyov wrote: > >workaround for not fully working interrupts on UART1. IRQ 0 means > >polling. Read the source. > > Thanks, I've read it quite a lot already. But is UART3 IRQ working > (being the same as UART1's)? right now, none of the ISA interrupts are working on that machine, probably because I'm missing some IRQ routing setup. The workaround is there to get serial console working in userspace. > To me, it doesn't make much sense with or without reading the code. > And note that no other boards claim ports 0x0000 thru 0x0fff to PCI. no other board MIPS board has EISA behind PCI afaik. So this is a new situation. > Yeah, and I'd given 0x00009000 as PCI I/O start address for that same > purpose. [E]ISA resources, while being accessed (via PCI bus as a proxy) > are generally not a part of PCI bus. it would help, if you would try to understand the stuff first. Just read the EISA code... > You're changing PCI I/O space start address for no apparent reason which > seems to break general 8259 code. could you try to understand the issue please ? I could leave the i8259 code alone and everything will work as before. Only the entries for the PIC would be missing in /proc/iomem (which I could kludge around by adding them to the pcit/pcimt resource list). Every other platform won't see a difference, because no other platform needs to request the PCI IO space starting at 0x0000. I've checked the platform device code, and it uses insert_region() like my proposed change for i8259. So I'm pretty sure, that's the way to go. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ]
