Hi Alex > -----Original Message----- > From: Alexander Graf [mailto:agraf@xxxxxxx] [...] > >> > >> I like the extio idea. That allows us to handle all PIO requests on > >> platforms that don't have native PIO support via different routes > >> depending on the region they're in. Unfortunately we now we have 2 > >> frameworks for handling sparse PIO regions: One in extio, one in > PCI. > >> > >> Why don't we just merge the two? Most of the code that has #ifdef > >> PCI_IOBASE throughout the code base sounds like an ideal candidate > to > >> get migrated to extio instead. Then we only have a single framework > to > >> worry about ... > > > > To be clear, are you suggesting we merge the functionality from > > pci_register_io_range(), pci_pio_to_address(), pci_address_to_pio() > into > > extio, so extio manages all PIO? > > Yes, I guess so. > > > And having a single type of node to > > register PIO ranges, by amalgamating struct extio_node and io_range > (as > > Bjorn mentioned)? > > I'm not quite sure I follow you here. Basically I think you want a > generic "non-x86 PIO" framework that PCI just plugs into. > > I don't think that necessarily means you want to statically allocate > regions of that PIO space to separate (pseudo-)devices. Instead, > everyone shares that space and should be able to fail gracefully if > some > space is already occupied. > > > It would make sense. We would be somewhat decoupling PIO from PCI. > > Yes :). > > > I think that other architectures, like PPC, and other code would need > to > > be fixed up to handle this. > > I think only PPC, Microblaze and ARM are using this. Grep for > PCI_IOBASE. It's not that many. > > > We need to consider all the other challenges/obstacles to this. > > Well, getting our abstraction levels right to me sounds like it's worth > the obstacles. > I have had a quick look and I think it should not be too difficult to unify the two frameworks. I'll follow up soon on this thread with a code sketch Thanks Gab [...]
