lkml.org 
[lkml]   [1999]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kmalloc


On Thu, 28 Jan 1999, Gerard Roudier wrote:

> Some driver (at least one) also needs to know of the actual PCI base
> address values, since the chip may have to be provided with actual PCI BUS
> address in order to access its internal memory from SCRIPTS (8XX) or from
> some equivalent stuff. That does not mean that the chip will use PCI
> cycles, but just that it will uses the _actual_ PCI address window for
> address comparison to decide what memory to access.

Indeed, I know. The driver I had to patch was ncr53c8xx.c, remind you
something ? :-). The current situation is perhaps bad, but the patch is
very small and not uglier than what is done for sparc in the same driver.
Worse, if I have correctly understood all the preceding statements, the
sparc code is actually wrong since the dev->base_address entries are
actual kernel virtual address. So you can't even rely on Dave Miller's
code as a reference :-(

And also if I have understood the Sparc code, the bridges actually do not
add any offset like the PreP ones: dev->base_address[n] is
__va(corresponding_config_register) (simply adds KERNEL_BASE) and then
under an ifdef __sparc__ in the driver KERNEL_BASE is again
subtracted...

> The address values provided in the pcidev structure qualified as 'suitable
> for ioremap()' looks rather a bad hack than a clean abstraction to me and
> it is not enough for all drivers to be portable. A driver needs some
> handle to access the device and, as I just wrote twice:), may also need
> the _actual_ configured PCI base addresses, but does not care of your
> obscure cookie that just make sense as input of some kernel routine.

Suitable for ioremap actually means nothing since you can make ioremap do
what it likes as a function of the input value. These values are also
exported through the /proc interface and should be suitable for mmap on
/dev/mem for programs like X servers, hence physical CPU addresses.

There is another problem if you have peer host bridges on a 64 bit
systems: some devices might appear at the same PCI addresses on different
buses, but they will appear at different CPU addresses which is the only
way to distinguish them with the current ioremap scheme... (I might be
wrong on that one, but with 32 bit MMIO space hogs like some of the
chips I use, it seems hard to avoid this case from ever happening).

> All this stuff is to be redesigned for 2.3/4, in my opinion.

Oh yes...

> It may be now, but it must be changed in the future. It hides the reality
> in a stupid way, in my opinion. The right way to go is to tell the kernel
> with the parameters that correspond to the reality.

Which reality ? On PreP addresses on both sides of the bridge are real,
physically represented by electrical signals. Only the result of ioremap
is virtual (which is still represented by electrical levels, but on the
CPU so you can't get at it with a logic analyzer).

>
> A PCI device driver want to tell the kernel:
>
> - Give me some MMIO handle to access this configured PCI BUS address range
> on that PCI BUS, but I donnot care of how you will proceed for it.
>
> Instead of that, you tell the driver:
>
> - Provide ioremap() with some right-cooked address value supplied in the
> pcidev structure and you will get some address-typed value to access the
> device.

Perhaps, but do not forget the needs of some lesser known programs like
Xservers too, or propose a new interface for programs who need the
equivalent of mmap on /dev/mem. And anyway the cooked value is the
physical address on the processor pins as Martin repeated, it's not that
artificial and it's the lesser evil we have to live with for 2.2.

Regards,
Gabriel.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:1.823 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site