Hi Alex

-----Original Message-----
From: Alexander Graf [mailto:agraf@suse.de]

[...]

quoted

quoted

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.

quoted

quoted

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

quoted

quoted

get migrated to extio instead. Then we only have a single framework

to

quoted

quoted

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

quoted

extio, so extio manages all PIO?

Yes, I guess so.

quoted

And having a single type of node to
register PIO ranges, by amalgamating struct extio_node and io_range

(as

quoted

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.

quoted

It would make sense. We would be somewhat decoupling PIO from PCI.

Yes :).

quoted

I think that other architectures, like PPC, and other code would need

to

quoted

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.

quoted

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

[...]