[Top] [All Lists]

Re: Modpost warning on Alchemy

To: "Maciej W. Rozycki" <>
Subject: Re: Modpost warning on Alchemy
From: Sergei Shtylyov <>
Date: Wed, 01 Aug 2007 21:06:33 +0400
Cc: Ralf Baechle <>,
In-reply-to: <>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Maciej W. Rozycki 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?

I've already said: 4 gigs! At least in theory, actually it's 2 gigs due to a device # being limited to 0 thru 19 (address bits 11 thru 30 are used as IDSELx).

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. ;-)

I meant that the implementation "caches" the 8 KiB mapping used for the last config. access.

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. ;-)

There was no need to tell me about how KSEG0/1/2 work -- that's why I cosidered it wasting time. :-)


WBR, Sergei

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