RE: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

From: Gabriele Paoloni
Date: Wed Feb 01 2017 - 07:30:53 EST


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

[...]