Re: Reason for PIO_MASK?

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

Hello.

Manuel Lauss wrote:

>>>I meant the result of ioremap() of the 36bit address of PCMCIA IO space:
>>>so the ioport base is somewhere at 0xc0000000, which pata_pcmcia
>>>tries to devm_iomap(), and this is rejected by the above mentioned file.

>>>The old ide-cs.c driver takes the given IO base as-is (without trying to
>>>do funky things to it) and just works. (i.e. there are 2 entries in the
>>>0xc0000000-range per cf-card in /proc/ioports)

>>Feeding a virtual address as input to devm_ioremap or ioremap does not
>>make sense.  Ioremap is only to be used for memory resources anyway.

> Somewhere in the pcmcia socket driver I need to ioremap the 36bit
> base of pcmcia io area:
> io_base = ioremap(0xF 0000 0000, 0x10000) (->0xc1086000)

> This is passed as io base to all drivers attached to this particular
> pcmcia socket:

> pata_pcmcia::pcmcia_init_one:
>    devm_ioport_map(0xc1086000)
>       ioport_map(0xc1086000) => no way!

    But this is incorrect. You can't pass the result of ioremap to 
ioport_map() -- it's already a virtual *memory* address.

> With 2 sockets I have 2 isolated IO bases, and so far this works as
> expected, except on drivers which use ioport_map().

    There's something up with either your code or these drivers -- as what 
you're trying to do is just mixing the memory vs I/O port and physical vs 
virtual addresses.

>>>>>I've temporarily removed the PIO_MASK check and pata_pcmcia
>>>>>works as expected. Is there any way around this, other than
>>>>>creating an Alchemy-specific ioport_map() function?
>>>>
>>>>The provocative question - why would you want to have more than 64k I/O port
>>>>space?
>>>
>>>*I* don't want more; I want a smarter pata_pcmcia driver ;-)  I'll go bug other
>>>people about this.  I brought this up here because one of my SH boards has
>>>similar needs (need to do an ioremap() with special TLB flags to get access to
>>>pcmcia IO space) but pata_pcmcia does work there (because SH kernel
>>>either asks the board to translate an x86-IO port to memory address or
>>>simply returns the port plus an offset).
>>
>>Well, Alchemy does this:
>>
>>...
>>       if (!virt_io_addr) {
>>               printk(KERN_ERR "Unable to ioremap pci space\n");
>>               return 1;
>>       }
>>       au1x_controller.io_map_base = virt_io_addr;
>>...
>>set_io_port_base(virt_io_addr);
>>...
>>
>>Which sets up a mapping for the entire port space.  Normally the PCMCIA
>>I/O port space should also be part of this range so inb, outb etc. for
>>the low 64k or so of port address range should just work without further
>>iomap calls of any sort.

> With this scheme, if I put CF cards in both sockets, I think I'm screwed,
> since both cards will use the same io ports.

> /proc/ioports with 2 cf cards, independet pcmcia sockets:
> c1086000-c1086007 : ide-cs
> c108600e-c108600e : ide-cs
> c108a000-c108a007 : ide-cs
> c108a00e-c108a00e : ide-cs

> Of all non-x86 archs which implement ioport_map(), MIPS is the only one
> which excplicitly checks the argument; most simply return it unchanged,

> some adjust the address space (and complain), add an offset,
> or ioremap it (AVR32).  Why is MIPS special in this regard?

    Look at the default implementation in lib/iomap.c please -- it gets used 
when the arch doesn't implement ioport_map() and it makes use of PIO_MASK.

> Maybe the whole logic should be turned around? Complain loudly if a driver
> tries to access the range covered by PIO_MASK?

    I didn't get the idea. PIO_MASK defined the *valid* address range for 
in*()/out*(), not invalid.

>         Manuel Lauss

WBR, Sergei