Reason for PIO_MASK?

Reason for PIO_MASK?

[Manuel Lauss]

In arch/mips/lib/iomap.c  there's this "#define PIO_MASK 0x0ffff"
which limits the ability to successfully call ioport_map() to the
first 64kB.  This causes pata_pcmcia to error out on CF card
probe because devm_ioport_map() is called with the remapped
PCMCIA IO area, which is somewhere in MAP_BASE space.

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?

Thanks,
        Manuel Lauss

Re: Reason for PIO_MASK?

[Ralf Baechle]

On Sat, Oct 03, 2009 at 04:48:12PM +0200, Manuel Lauss wrote:

> In arch/mips/lib/iomap.c  there's this "#define PIO_MASK 0x0ffff"
> which limits the ability to successfully call ioport_map() to the
> first 64kB.  This causes pata_pcmcia to error out on CF card
> probe because devm_ioport_map() is called with the remapped
> PCMCIA IO area, which is somewhere in MAP_BASE space.

Remapped, so that then actually be a physical address?  That'd be wrong.

> 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/O ports are x86 legacy and deprecated.  PCI limits allocations to at
most 256 bytes and I don't know of any devices that even come close to
that.

When I wrote ioport_map I reviwed all uses of ioport addresses > 64k and
found each of them to be buggy ...

  Ralf

Re: Reason for PIO_MASK?

[Manuel Lauss]

On Tue, Oct 6, 2009 at 1:52 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Sat, Oct 03, 2009 at 04:48:12PM +0200, Manuel Lauss wrote:
>
>> In arch/mips/lib/iomap.c  there's this "#define PIO_MASK 0x0ffff"
>> which limits the ability to successfully call ioport_map() to the
>> first 64kB.  This causes pata_pcmcia to error out on CF card
>> probe because devm_ioport_map() is called with the remapped
>> PCMCIA IO area, which is somewhere in MAP_BASE space.
>
> Remapped, so that then actually be a physical address?  That'd be wrong.

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)


>> 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).

Thanks!
        Manuel Lauss

Re: Reason for PIO_MASK?

[Ralf Baechle]

On Tue, Oct 06, 2009 at 02:11:15PM +0200, 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.

> >> 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.

  Ralf

Re: Reason for PIO_MASK?

[Manuel Lauss]

On Tue, Oct 6, 2009 at 4:25 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Oct 06, 2009 at 02:11:15PM +0200, 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!

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


>> >> 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?

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

        Manuel Lauss

Re: Reason for PIO_MASK?

[Sergei Shtylyov]

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

Re: Reason for PIO_MASK?

[Manuel Lauss]

Hi Sergei!

On Wed, Oct 7, 2009 at 5:49 PM, Sergei Shtylyov <sshtylyov@ru.mvista.com> 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.

Oh I don't doubt that, but how else am I supposed to access the
PCMCIA IO (which is outside the directly addressable address space!)
area on a non-PC arch?  Since this isn't a PC I don't really see why
the IO port space should be viewed as a sacred area between 0 and 0xffff
rather than another memory area with slightly different electrical
characteristics
(and the fact that it pulls the IOW#/IOR#/ lines on the PCMCIA interface
instead of the "standard" bus r/w signals).

I understand that drivers written for PC-XT hardware won't work, but I can
live with this burden..


>> 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.

The Alchemy pcmcia socket drivers haven been doing this since before
I knew Alchemy even existed (so > 3 years).


>>>>>> 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.

That probably is the reason why every arch with pcmcia support does implement
its own pass-through variant.   And I'm not nearly smart enough to
figure out what
*else* to do...

In any case. thanks for the comment,
      Manuel Lauss