can't access PCIe card under sbc8548

[Scott Wood]

On 05/30/2013 07:49:48 AM, wolfking wrote:
> tiejun.chen wrote
> > On 05/30/2013 03:32 PM, wolfking wrote:
> >> (continued)
> >>    I traced the 8139too.c when it uses pci_iomap, the pci_iomap  
> called
> >> the
> >> ioport_map. The difference between 8139 and my PCIe card lies in  
> the
> >> "port" value :
> >> void __iomem *ioport_map(unsigned long port, unsigned int len)
> >> {
> >> 	return (void __iomem *) (port + _IO_BASE);
> >
> > _IO_BASE is equal to isa_io_base. So if this is not zero, I think  
> there's
> > a isa
> > bridge in your platform. So you can access these I/O ports based on  
> that
> > isa
> > bridge/bus with ioreadx/iowritex.
> >
> > I tried ioread8/iowriet8 after ioremap, it doesn't work
> >
> >> }
> >>    in 8139too.c, the "port" value is 0x1000; for my PCIe card, the  
> "port"
> >> value
> >> is 0xfefff000. And the value is got from pci_resource_start. So  
> you see,
> >> the
> >
> > But this means the port is as memory-mapped

Are you sure?  It could mean that it's on a non-primary bus and I/O for  
this bus is mapped at a lower address than the primary.  Just because  
the addition is wrapping around doesn't mean it's wrong.

> > so ioremap() should be workable in this case. Then out_bex/in_bex  
> should be fine.

ioremap() and out_bex/in_bex are not appropriate for PCI I/O regions  
(and presumably that's what it is, if pci_iomap is calling  
ioport_map).  Big-endian is not appropriate for PCI in any case.

The whole point of pci_iomap() appears to be that the driver doesn't  
need to care whether it's MMIO or PIO, and can use ioread/writeX on the  
resulting cookie.  If PPC is messing this up it's not the driver's  
fault.

-Scott