[Top] [All Lists]

Re: Modpost warning on Alchemy

To: Sergei Shtylyov <>
Subject: Re: Modpost warning on Alchemy
From: "Maciej W. Rozycki" <>
Date: Wed, 1 Aug 2007 17:54:37 +0100 (BST)
Cc: Ralf Baechle <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <>
On Wed, 1 Aug 2007, Sergei Shtylyov wrote:

> > And regarding what you have written above and the size issue you mentioned
> > in another e-mail (do you map the whole PCI config space linearly in the
> > physical address space of the CPU or suchlike?) -- PCI 
>    No, I don't.  But that was why the original code preferred the wired entry
> approach over ioremap() -- not to map a whole range...

 So what is the issue with the size then?  How big is the area?

> > config space accesses are rare (by design rather than chance), so 
>    That depends on the drivers used (some IDE drivers access it really often).

 It is their problem I would say -- there is a design problem either in 
these drivers or the hardware handled.  The PCI spec is very explicit that 
the config space is meant to be seldom accessed only.  Device 
initialization/shutdown and bus error recovery are the normal places.

> > performance is a non-issue and it should be absolutely fine for you to call
> > ioremap() and iounmap() in code specific for your PCI host bridge for the
> > required fragment upon every access.  There is no need for a permanent 
>    That's an idea -- however, as the currecnt code uses a cached mapping, this
> part would certainly need to be saved in the new implementaion -- if someone
> will go and fix it eventually. :-)

 Well, cached mapping does not seem particularly wise with PCI 
configuration registers, but you have got the ioremap_cachable() call if 
you insist. ;-)

> > Well, more about Linux perhaps than MIPS in general. :-)
>    Let's say that was about Linux/MIPS.  But the key word was "wasting". ;-)

 I reckon the key is how you look at it. ;-)


<Prev in Thread] Current Thread [Next in Thread>