Re: isa_read/write not available on ppc - solution suggestions ??

Re: isa_read/write not available on ppc - solution suggestions ??

[mike_phillips]

>mike_phillips@urscorp.com wrote:
>> 
>> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
>> isa_read/write's have to be changed to regular read/write due to the 
lack
>> of the isa_read/write functions for ppc.

> Treat it like a PCI device and use ioremap().  Then change isa_readl()
> to readl() etc.

Bleurgh, the latest version of the driver (not in the kernel yet) searches 
for turbo based cards by checking the isa address space from 0xc0000 - 
0xe0000 in 8k chunks. So we'd have to ioremap each 8k section, check it, 
find out the adapter isn't there and then iounmap it. 

Oh well, if that's what it takes =:0

Mike

Re: isa_read/write not available on ppc - solution suggestions ??

[Linus Torvalds]

In article <OF7A9C6B22.E1638E60-ON85256A3F.004EADC7@urscorp.com>,
 <mike_phillips@urscorp.com> wrote:
>>mike_phillips@urscorp.com wrote:
>>> 
>>> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
>>> isa_read/write's have to be changed to regular read/write due to the 
>lack
>>> of the isa_read/write functions for ppc.
>
>> Treat it like a PCI device and use ioremap().  Then change isa_readl()
>> to readl() etc.
>
>Bleurgh, the latest version of the driver (not in the kernel yet) searches 
>for turbo based cards by checking the isa address space from 0xc0000 - 
>0xe0000 in 8k chunks. So we'd have to ioremap each 8k section, check it, 
>find out the adapter isn't there and then iounmap it. 
>
>Oh well, if that's what it takes =:0

I would suggest the opposite approach instead: make the PPC just support
isa_readx/isa_writex instead.

Much simpler, and doesn't need changes to (correct) driver sources.

I bet that the patch will be smaller too. It's a simple case of
 - do the ioremap() _once_ at bootup, save the result in a static
   variable somewhere.
 - implement the (one-liner) isa_readx/isa_writex functions.

On many architectures you don't even need to do the ioremap, as it's
always available (same as on x86).

		Linus

Re: isa_read/write not available on ppc - solution suggestions ??

[Russell King]

On Tue, May 01, 2001 at 10:22:39AM -0700, Linus Torvalds wrote:
> I bet that the patch will be smaller too. It's a simple case of
>  - do the ioremap() _once_ at bootup, save the result in a static
>    variable somewhere.
>  - implement the (one-liner) isa_readx/isa_writex functions.
> 
> On many architectures you don't even need to do the ioremap, as it's
> always available (same as on x86).

Talking around this issue, is there any chance of getting the
official use of the first parameter to ioremap documented in
Documentation/IO-mapping.txt please?  There appears to be
confusion as to whether it is:

a) PCI bus address
b) CPU untranslated address

Currently, IO-mapping.txt seems to imply (a), but I believe that
a lot of people on lkml will disagree with that.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: isa_read/write not available on ppc - solution suggestions ??

[Linus Torvalds]

On Tue, 1 May 2001, Russell King wrote:
>
> Talking around this issue, is there any chance of getting the
> official use of the first parameter to ioremap documented in
> Documentation/IO-mapping.txt please?  There appears to be
> confusion as to whether it is:
>
> a) PCI bus address
> b) CPU untranslated address

It's neither.

It's a cookie that you can do arithmetic off and pass on to the
readx/writex, and nothing more. You cannot make any assumptions at all
about what it means.

In particular, you can _not_ assume that it is a PCI bus address ("WHICH
bus?") and you can absolutely not assume that it is a CPU address (many
CPU's do not "memory map" PCI at all).

		Linus

Re: isa_read/write not available on ppc - solution suggestions ??

[Russell King]

On Tue, May 01, 2001 at 02:19:33PM -0700, Linus Torvalds wrote:
> On Tue, 1 May 2001, Russell King wrote:
> > Talking around this issue, is there any chance of getting the
> > official use of the first parameter to ioremap documented in
> > Documentation/IO-mapping.txt please?  There appears to be
> > confusion as to whether it is:
> >
> > a) PCI bus address
> > b) CPU untranslated address
> 
> It's neither.
> 
> It's a cookie that you can do arithmetic off and pass on to the
> readx/writex, and nothing more. You cannot make any assumptions at all
> about what it means.
> 
> In particular, you can _not_ assume that it is a PCI bus address ("WHICH
> bus?") and you can absolutely not assume that it is a CPU address (many
> CPU's do not "memory map" PCI at all).

In which case, can we change the following in IO-mapping.txt please?

        /*
         * remap framebuffer PCI memory area at 0xFC000000,
         * size 1MB, so that we can access it: We can directly
         * access only the 640k-1MB area, so anything else
         * has to be remapped.
         */
        char * baseptr = ioremap(0xFC000000, 1024*1024);

since its not true?  (since 0xfc000000 is a cookie).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: isa_read/write not available on ppc - solution suggestions ??

[Linus Torvalds]

On Tue, 1 May 2001, Russell King wrote:
>
> In which case, can we change the following in IO-mapping.txt please?

Oh, sorry. I misread your question. The _return_ value is a cookie.

The first argument should basically be the start of a "struct pci_dev"
resource entry, but obviously architecture-specific code can (and does)
know what the thing means. And the ISA space (ie 0xA0000-0x100000) has
been considered an acceptable special case.

So the only usage that is "portable" is to do something like

	cookie = ioremap(pdev->resource[0].start, pdev->resource[0].len);

and I guess we should actually create some helper functions for that too.

You can use ioremap in other ways, but there's nothing to say that they
will work reliably across multiple PCI buses etc.

		Linus

Re: isa_read/write not available on ppc - solution suggestions ??

[Paul Mackerras]

Linus Torvalds writes:

> I would suggest the opposite approach instead: make the PPC just support
> isa_readx/isa_writex instead.

We can certainly do that, no problem.

BUT that won't get a token ring pcmcia card working in the newer
powerbooks, such as the titanium G4 powerbook, because the PCI host
bridge doesn't map any cpu addresses to the bottom 16MB of PCI memory
space.  This is not a problem as far as pcmcia cards are concerned -
the pcmcia stuff just picks an appropriate address (typically in the
range 0x90000000 - 0x9fffffff) and sets the pcmcia/cardbus bridge to
map that to the card.  But it means that the physical addresses for
the card's memory space will be above the 16MB point, so it is
essential to do the ioremap.

Paul.

Re: isa_read/write not available on ppc - solution suggestions ??

[Geert Uytterhoeven]

On 1 May 2001, Linus Torvalds wrote:
> In article <OF7A9C6B22.E1638E60-ON85256A3F.004EADC7@urscorp.com>,
>  <mike_phillips@urscorp.com> wrote:
> >>mike_phillips@urscorp.com wrote:
> >>> 
> >>> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
> >>> isa_read/write's have to be changed to regular read/write due to the 
> >lack
> >>> of the isa_read/write functions for ppc.
> >
> >> Treat it like a PCI device and use ioremap().  Then change isa_readl()
> >> to readl() etc.
> >
> >Bleurgh, the latest version of the driver (not in the kernel yet) searches 
> >for turbo based cards by checking the isa address space from 0xc0000 - 
> >0xe0000 in 8k chunks. So we'd have to ioremap each 8k section, check it, 
> >find out the adapter isn't there and then iounmap it. 
> >
> >Oh well, if that's what it takes =:0
> 
> I would suggest the opposite approach instead: make the PPC just support
> isa_readx/isa_writex instead.
> 
> Much simpler, and doesn't need changes to (correct) driver sources.

And while you're at it, please add isa_{request,release}_mem_region() as well.

Reasoning: while we can (and do) make ioremap(0xa0000, ...) work fine on PPC
(you must not use ioremap() for RAM, so it must be ISA memory space), we can't
distinguish between the first 16 MB of RAM and ISA memory space for
{request,release}_mem_region()...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: isa_read/write not available on ppc - solution suggestions ??

[Jonathan Lundell]

At 3:46 PM -0700 2001-05-01, Linus Torvalds wrote:
>On Tue, 1 May 2001, Russell King wrote:
>  >
>>  In which case, can we change the following in IO-mapping.txt please?
>
>Oh, sorry. I misread your question. The _return_ value is a cookie.
>
>The first argument should basically be the start of a "struct pci_dev"
>resource entry, but obviously architecture-specific code can (and does)
>know what the thing means. And the ISA space (ie 0xA0000-0x100000) has
>been considered an acceptable special case.
>
>So the only usage that is "portable" is to do something like
>
>	cookie = ioremap(pdev->resource[0].start, pdev->resource[0].len);
>
>and I guess we should actually create some helper functions for that too.
>
>You can use ioremap in other ways, but there's nothing to say that they
>will work reliably across multiple PCI buses etc.

What's the Linu[sx] attitude to using a type to help control (and 
illuminate) the use of these objects? I'm thinking here in particular 
of the cookie returned by ioremap() and used by readx/writex, but I 
suppose there might be similar applicability to its first parameter.
-- 
/Jonathan Lundell.

Re: isa_read/write not available on ppc - solution suggestions ??

[Benjamin Herrenschmidt]

>> I would suggest the opposite approach instead: make the PPC just support
>> isa_readx/isa_writex instead.
>
>We can certainly do that, no problem.
>
>BUT that won't get a token ring pcmcia card working in the newer
>powerbooks, such as the titanium G4 powerbook, because the PCI host
>bridge doesn't map any cpu addresses to the bottom 16MB of PCI memory
>space.  This is not a problem as far as pcmcia cards are concerned -
>the pcmcia stuff just picks an appropriate address (typically in the
>range 0x90000000 - 0x9fffffff) and sets the pcmcia/cardbus bridge to
>map that to the card.  But it means that the physical addresses for
>the card's memory space will be above the 16MB point, so it is
>essential to do the ioremap.

What about isa_ioremap ? Result from it is a token passed to
isa_readx/isa_writex and the arch side can be implemented with a
couple of #defines on x86. 

It's easy to change I beleive, and it paves the way for archs to
add a notion of "token" in the high bits (as we _know_ an ISA address
is small). Those token can be used by arch to route to proper PCI
bus when several host bridges exist, to route to PCMCIA when the
PCMCIA uses it's own "ISA" memory space like on PPC, etc...

Later on, we can see things like

ulong pci_get_bus_isa_base(int busno);

And the same for PCMCIA & whatever 16 bits busses that can exist on
embedded hardware.

That way, support for multiple busses (either real ISA, embedded custom
busses using legacy devices, several PCI hosts with ISA bridges, ...)
can be implemented very easily. In most case adjusting the drivers
probe code.

I'd like to see the same kind of things for IOs in fact but that's
another debate ;)

Regards,
Ben.

Re: isa_read/write not available on ppc - solution suggestions ??

[Anton Blanchard]

 
> This is where the multiple support issue comes in. In ibmtr_cs.c we do 
> ioremap the addresses so pcmcia all works nicely. What we don't do at 
> present is an ioremap in ibmtr.c for the non-pcmcia adapters (isa & mca). 
> So, I suppose the real fix would be to implement the ioremap in ibmtr.c so 
> that regular read/writes can be used everywhere in the driver. (This is 
> half the battle with changes to the driver, it supports so many 
> combinations that one change for one type of adapter can kill support for 
> another adapter, and that's my bottom line with updates: No loss of 
> functionality we already had.)

Yes since we ioremap both regions in ibmtr_cs.c and pass the cookies into 
ibmtr.c we should be using read*/write*. With the simple fix to do this
and use the non byteswapping versions of read*/write* the token ring
pcmcia driver works fine on a titanium powerbook.

My suggestion is to throw this into ibmtr.h:

#ifdef PCMCIA
#define tr_readb(addr)		readb(addr)
#define tr_readw(addr)		__raw_readw(addr)
#define tr_readl(addr)		__raw_readl(addr)
#define tr_writeb(val, addr)	writeb(val, addr)
#define tr_writel(val, addr)	__raw_writel(val, addr)
#define tr_writew(val, addr)	__raw_writew(val, addr)
#else
#define tr_readb(addr)		isa_readb(addr)
#define tr_readw(addr)		isa_readw(addr)
#define tr_readl(addr)		isa_readl(addr)
#define tr_writeb(val, addr)	isa_writeb(val, addr)
#define tr_writel(val, addr)	isa_writel(val, addr)
#define tr_writew(val, addr)	isa_writew(val, addr)
#endif

Anton

Re: isa_read/write not available on ppc - solution suggestions ??

[mike_phillips]

> We can certainly do that, no problem.

> BUT that won't get a token ring pcmcia card working in the newer
> powerbooks, such as the titanium G4 powerbook, because the PCI host
> bridge doesn't map any cpu addresses to the bottom 16MB of PCI memory
> space.  This is not a problem as far as pcmcia cards are concerned -
> the pcmcia stuff just picks an appropriate address (typically in the
> range 0x90000000 - 0x9fffffff) and sets the pcmcia/cardbus bridge to
> map that to the card.  But it means that the physical addresses for
> the card's memory space will be above the 16MB point, so it is
> essential to do the ioremap.

This is where the multiple support issue comes in. In ibmtr_cs.c we do 
ioremap the addresses so pcmcia all works nicely. What we don't do at 
present is an ioremap in ibmtr.c for the non-pcmcia adapters (isa & mca). 
So, I suppose the real fix would be to implement the ioremap in ibmtr.c so 
that regular read/writes can be used everywhere in the driver. (This is 
half the battle with changes to the driver, it supports so many 
combinations that one change for one type of adapter can kill support for 
another adapter, and that's my bottom line with updates: No loss of 
functionality we already had.)

Or we could just tell people to use the cardbus token ring adapter on ppc 
instead ;)

Mike

Re: isa_read/write not available on ppc - solution suggestions ??

[mike_phillips]

> I would suggest the opposite approach instead: make the PPC just 
> support isa_readx/isa_writex instead.
>
> Much simpler, and doesn't need changes to (correct) driver sources.
>
> I bet that the patch will be smaller too. It's a simple case of
> - do the ioremap() _once_ at bootup, save the result in a static
>   variable somewhere.
> - implement the (one-liner) isa_readx/isa_writex functions.
>
> On many architectures you don't even need to do the ioremap, as it's
> always available (same as on x86).

That would be my preferred solution as well. The one-liners are easy, the 
ioremap may be more fun. Time to investigate the ppc code and docs. 

Unless one of the kindly ppc maintainers who knows far more about the arch 
than me would like to do it :)

Mike

Re: isa_read/write not available on ppc - solution suggestions ??

[Geert Uytterhoeven]

On Tue, 1 May 2001 mike_phillips@urscorp.com wrote:
> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the 
> isa_read/write's have to be changed to regular read/write due to the lack 
> of the isa_read/write functions for ppc.
> 
> So, the question is should I simply:
> 
> a) change everything to read/write and friends (the way the driver used to 
> be before the isa_read/write function were introduced)
> b) Put ugly macros in the driver to use the different functions depending 
> upon architecture.
> c) Implement the isa_read/write functions for ppc ? 
> or d) something completely different I haven't thought of. 

Please go for option c.

Also note that ISA memory space is not available on all PPC platforms.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: isa_read/write not available on ppc - solution suggestions ??

[Alan Cox]

> > for ioremap and are meant for lazy porting
> 
> You meant isa_read* were for lazy porting.  read* require ioremap be
> done before hand, even for ISA.

Indeed I do

Re: isa_read/write not available on ppc - solution suggestions ??

[Brian Gerst]

Alan Cox wrote:
> 
> > a) change everything to read/write and friends (the way the driver used to
> > be before the isa_read/write function were introduced)
> 
> readb/readw/readl have always worked for ISA bus. They simply avoid the need
> for ioremap and are meant for lazy porting

You meant isa_read* were for lazy porting.  read* require ioremap be
done before hand, even for ISA.

--

				Brian Gerst

Re: isa_read/write not available on ppc - solution suggestions ??

[Brian Gerst]

mike_phillips@urscorp.com wrote:
> 
> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
> isa_read/write's have to be changed to regular read/write due to the lack
> of the isa_read/write functions for ppc.

Treat it like a PCI device and use ioremap().  Then change isa_readl()
to readl() etc.

--

				Brian Gerst

Re: isa_read/write not available on ppc - solution suggestions ??

[Alan Cox]

> a) change everything to read/write and friends (the way the driver used to 
> be before the isa_read/write function were introduced)

readb/readw/readl have always worked for ISA bus. They simply avoid the need
for ioremap and are meant for lazy porting

isa_read/write not available on ppc - solution suggestions ??

[mike_phillips]

To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the 
isa_read/write's have to be changed to regular read/write due to the lack 
of the isa_read/write functions for ppc.

So, the question is should I simply:

a) change everything to read/write and friends (the way the driver used to 
be before the isa_read/write function were introduced)
b) Put ugly macros in the driver to use the different functions depending 
upon architecture.
c) Implement the isa_read/write functions for ppc ? 
or d) something completely different I haven't thought of. 

Remember, this driver must support isa, pcmcia, mca, ix86 and now ppc. 

Personally I'd rather not have arch dependent macros in the driver, but I 
know there is a good reason why the isa_read/write functions were 
introduced in the first place. 

Suggestions ?

Mike
Linux Token Ring Project
http://www.linuxtr.net

Re: isa_read/write not available on ppc - solution suggestions ??

[Arnaldo Carvalho de Melo]

Em Tue, May 01, 2001 at 09:52:30AM -0400, mike_phillips@urscorp.com escreveu:
> Personally I'd rather not have arch dependent macros in the driver, but I 
> know there is a good reason why the isa_read/write functions were 
> introduced in the first place. 

I did that because I was lazy to use ioremap in my driver, but I found time
and fixed it properly eventually, too late, lots of other drivers started
using it, now its in the janitor's TODO list to get rid of that and use
ioremap, then we'll be able to get rid of that hack 8)

- Arnaldo