Hello.
Thomas Bogendoerfer wrote:
request_resource will fail, because the range is already taken by
sni_io_resource, while insert_region inserts the resource into
sni_io_resource.
No, it shouldn't according to what I'm seeing in the code. Perhaps I'm
missing something and need to actually try executing alike code a see...
after startup there is ioport_resource, which is 0x0000-IO_SPACE_LIMIT.
My change in register_pci_controller will request the PCI IO space
from 0x0000 to 0x3bffff (the maximum the PCI host bridge could address).
Why do you need to claim I/O ports from 0, at the first place (especially
if nobody else does this)? Apparently in your EISA system, ports 0x0 thru
0x100 are reserved for ISA compat pereiplerals (they are behind the PCI-ISA
bridge but that doesn't matter for this purpose), ports 0x100-0x3ff are not
for PCI anyway (besides, that's legacy ISA card range, along with all the
aliases), 0x1000-0x1cff, 0x2000-0x2cff, ... 0x8000-0x8cff are reserved for
EISA slots and everything in beetween you're marking as unavailable to PCI too
(besides, those ranges are ISA card alias ranges). So, what was the point of
claiming all the lagacy ranges to belong to PCI and then prevent it from using
them, (and break 8259 code by doing that)?
request_resource from ioport_resource, which i8259.c tried to do, will
fail now in that range, because it'ss taken by the PCI bridge. Therefore
anybody wanting IO space in that range, must take it from the PCI
IO space. So doing request_region (&sni_io_resource, &pci1_io_resource);
would have worked as well. But the code right now doesn't have a
handle for the parent resource. insert_region() on the other side
searches for the parent resource over the whole given resource and
plugs the wanted resource to the right sub resource.
OK, seeing my mistake in the code interpretation now. But I must note that
the comment to that function *is* misguiding:
Fine for simple house keeping, which is IMHO ok in that place.
It's OK but I'm still not seeing why we need it at all.
The problem is that init_i8259 doesn't have the right
resource for doing the request_resource, if ioport_resource starting from
0x0000 is already taken by a PCI host bridge.
I'm not at all sure that giving out I/O addresses from 0 to PCI is a
great idea -- is it indeed necessary?
I'm feeling like an oldtimer right now. Ever heard of ISA busses ? The
Alas, your irony is lost on me. :-)
address space there starts from 0x0000. There is this infamous DMA
controller waiting exactly at IO address 0x0000-0x001f. Floppy DMA
needs to use that for example. Of course this would work even without
I even programmed ISA bus masters. :-)
the silly resource stuff (inb/outb don't care), EISA code wants to see
0x0000 as base address of the PCI/EISA bridge.
Does EISA code care about PCI bridge?
Well, looking at drivers/eisa/pci_eisa.c looks like it indeed may care.
Well, then I've probably lost the case. :-)
I could probably write a
patch, which adds a parameter to init_i8259 for the resource, where the
request_resource is correct. No idea, whether this is worth the efford.
Opions ?
Did you mean options, opinions, or something else? :-)
I wanted to know from someone, who knows what I talking about, if my
current code is acceptable or needs more workout.
You wanted it, you got it.
Thomas.
WBR, Sergei
