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
> 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
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]