questions on Realtek 8139D driver - Linux

This is a discussion on questions on Realtek 8139D driver - Linux ; Hello,
I've been researching the source code of 8139too.c shipped with kernel
2.4.18 and stuck in confused with I/O and memory spaces provided by chip. As
far as I understood the datasheet, PCI_BASE_ADDRESS_0 contains the address
of I/O space, while ...

questions on Realtek 8139D driver

Hello,

I've been researching the source code of 8139too.c shipped with kernel
2.4.18 and stuck in confused with I/O and memory spaces provided by chip. As
far as I understood the datasheet, PCI_BASE_ADDRESS_0 contains the address
of I/O space, while BASE_ADDRESS_1 - PCI memory space.

Then - where are the registers are mapped to? If those are mapped in to both
spaces, does it mean driver maintains two copies of registers?

How does the driver decide what space to use? It seems it relies on kernel
configuration option, CONFIG_8139TOO_PIO (is it realtek feature or kind of
hack?)

Re: questions on Realtek 8139D driver

"Roman Mashak" wrote in
news:eo1sck$24cq$1@relay.tomsk.ru:
> I've been researching the source code of 8139too.c shipped with kernel
> 2.4.18 and stuck in confused with I/O and memory spaces provided by
> chip. As far as I understood the datasheet, PCI_BASE_ADDRESS_0
> contains the address of I/O space, while BASE_ADDRESS_1 - PCI memory
> space.
>
> Then - where are the registers are mapped to? If those are mapped in
> to both spaces, does it mean driver maintains two copies of registers?

No, there's only one set of registers; you can choose to access them via
I/O space or by memory mapping, but either way you're accessing the same
registers. I don't know why one would want to use I/O space (might be
easier for PXE boot or real-mode DOS scenarios).
> How does the driver decide what space to use? It seems it relies on
> kernel configuration option, CONFIG_8139TOO_PIO (is it realtek feature
> or kind of hack?)

The CONFIG_8139TOO_PIO config option is a feature of the linux driver
allowing the kernel builder to choose whether the driver should use I/O
or mmap operations. I've no idea why the author decided to include the
ability to go either way. (Possibly because using I/O space avoided the
"bug w/ posted MMIO writes" referenced in the source, but that's just a
guess.)