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


On Thu, 28 Jan 1999, Martin Mares wrote:

> Hello,
>
> > Indeed, but I'm probably too stupid and I would like to understand what
> > the following code on the Alpha means (in arch/alpha/kernel/bios32.c,
> > but there is something similar in Sparc64):
> >
> > pcibios_write_config_dword(bus->number, dev->devfn,
> > off, base);
> > new_io_reset(dev, off, orig_base);
> >
> > handle = PCI_HANDLE(bus->number) | base;
> > dev->base_address[idx] = handle;
> >
> > Obviously, unless the code is needlessly obfuscated, dev->base_address
> > will _not_ have the same value as the base register in the PCI
> > configuration space. Shouldn't it be the same on PreP, where to access the
> > MMIO at address 0x123456, the physical address is 0xC0123456 since the bridge
> > subtracts 0xc0000000 from the address appearing on the CPU pins ?
>
> This is exactly the reason why do we have dev->base_address[] and the
> drivers use it instead of reading the addresses from the configuration space.
> dev->base_address[] should contain addresses suitable as an argument to
> ioremap() [after stripping off the region type in lower bits] and as a
> file offset in /dev/mem.

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.

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.

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

> > I've been trying to solve this problem but never got a clear answer. I had
> > come to the conclusion that it should be:
> >
> > pci_read_config_dword(dev, PCI_BASE_ADDRESS_n, &base)
> >
> > dev->base_address[n] = base+0xc0000000 (adjusted by pcibios_fixup())
> >
> > address used in driver = ioremap(dev->base_address[n])
> >
> > in this case, lspci -v and lspci -vb do not display the same addresses.
>
> Yes, this is the right way to go.

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.

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.


Regards,
Gérard.


-
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:0.080 / U:0.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site