All of lore.kernel.org
 help / color / mirror / Atom feed
From: tsbogend@alpha.franken.de (Thomas Bogendoerfer)
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Change PCI host bridge setup/resources
Date: Mon, 9 Apr 2007 17:16:30 +0200	[thread overview]
Message-ID: <20070409151630.GA9284@alpha.franken.de> (raw)
In-Reply-To: <461A50E0.1060602@ru.mvista.com>

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 ]

  reply	other threads:[~2007-04-09 15:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-08 11:34 [PATCH] Change PCI host bridge setup/resources Thomas Bogendoerfer
2007-04-08 17:20 ` Sergei Shtylyov
2007-04-08 23:07   ` Thomas Bogendoerfer
2007-04-09  8:29     ` Geert Uytterhoeven
2007-04-09 14:44       ` Sergei Shtylyov
2007-04-09 14:42     ` Sergei Shtylyov
2007-04-09 15:16       ` Thomas Bogendoerfer [this message]
2007-04-10 15:50         ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070409151630.GA9284@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=linux-mips@linux-mips.org \
    --cc=sshtylyov@ru.mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.