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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
