[ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jim Paris]

Ralf, perhaps you (or someone else here) can help:

> From: Pete Popov <ppopov@mvista.com>
> To: jim@jtan.com
>
> On Sun, 2001-12-16 at 18:37, Jim Paris wrote:
> > I'm confused.  Shouldn't ioremap use isa_slot_offset for ISA
> > addresses, and if not, why not?  Where should isa_slot_offset go?  It
> > can't go into read[bwl]/write[bwl], because ioremap would add KSEG1,
> > and isa_slot_offset would already include KSEG1.
> 
> What would be considered an ISA address -- the standard PC definition? 
> I don't think that would work on most mips boards.
> 
> I'm not sure what isa_slot_offset is meant to do at all.  Shoot Ralf an
> email, perhaps he has a clear explanation (and then let us know :-)). 

If I make ioremap use isa_slot_offset for addresses under 16MB, then
PCMCIA works for me.  I don't see any other way to get isa_slot_offset
in there without hacking PCMCIA in ways that break other arches.

--

On a somewhat related note, I've noticed that if I include IDE disk
support in my kernel (CONFIG_BLK_DEV_IDEDISK, ide-disk.o), then stuff
breaks; most noticibly, the PCMCIA IRQ scan returns the negative (!)
of the correct values.  I'm guessing this is something miscompiling --
I'm using the latest binutils plus gcc-3.0.2 -- has anyone see these
problems with ide-disk?  Or can you suggest a newer gcc CVS that
you've used successfully?  (I suppose I should set up gdb and try to
find where the problem is, but I'm in the middle of finals right now
and won't have time to do that for a while)

-jim

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Mon, Dec 17, 2001 at 03:15:15PM -0500, Jim Paris wrote:

> > What would be considered an ISA address -- the standard PC definition? 
> > I don't think that would work on most mips boards.

ISA, the good old stonage PC bus system with all it's limitations that also
infected some MIPS systems.

> > I'm not sure what isa_slot_offset is meant to do at all.  Shoot Ralf an
> > email, perhaps he has a clear explanation (and then let us know :-)). 

It points to the virtual address at which memory address 0 of the ISA
bus is accessible.  There is a wealth of old ISA drivers that don't know
about the wonders of ioremap so that's why there is isa_slot_offset as
a killer solution for all ISA crapola.

> If I make ioremap use isa_slot_offset for addresses under 16MB, then
> PCMCIA works for me.  I don't see any other way to get isa_slot_offset
> in there without hacking PCMCIA in ways that break other arches.

Is your PCMCIA bridge really behind an ISA bus?

What is an address less than 16mb in your case?  Most MIPS systems have
memory at that physical address so maybe you're not talking about
physical addresses?

> On a somewhat related note, I've noticed that if I include IDE disk
> support in my kernel (CONFIG_BLK_DEV_IDEDISK, ide-disk.o), then stuff
> breaks; most noticibly, the PCMCIA IRQ scan returns the negative (!)
> of the correct values.  I'm guessing this is something miscompiling --
> I'm using the latest binutils plus gcc-3.0.2 -- has anyone see these

Try something older instead.

  Ralf

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[hanishkvc]

Hi Jim,

If a device or a bus/Interface controller has some memory, then its up 
to the corresponding driver to make it available to the system. So yes 
If I am not wrong you should use ioremap to make this memory visible 
somewhere in the kernel address space. Inturn doing read/write on it 
should succeed.

I don't get the reason has to why u want to use isa_slot_offset. As you 
know the physical address range for ur interface/bus(and devices) you 
use that value in ioremap. This would give u a new virtual address which 
inturn you should/would use in your read/write calls.

However has I haven't worked on PCMCIA logic of linux, I may be wrong, 
if they have some of their own conventions interms has to where they map 
the memory and or what standard function/macro names they use.

Keep :-)
HanishKVC

Jim Paris wrote:

>My system (Vadem Clio 1000, vr4111) has a VG-469 (i82365) PCMCIA
>controller with IO port space at 0x14000000, and IO memory space
>at 0x10000000.
>
>3) it can use check/request/release_mem_region on I/O memory
> - this fails, because the iomem resource map contains the kernel:
>   > -more /proc/iomem
>   00000000-00ffffff : System Ram
>     00002000-001bc6af : Kernel code
>     001cf300-00299fff : Kernel data
> (this seems very wrong to me, since the kernel is most definately
>  not in the I/O memory space; real memory, of course, but I/O memory??)
>4) it can use ioremap, and then read[bwl] and write[bwl] with the result
> - this fails with the current ioremap; neither ioremap nor read/write[bwl]
>   take isa_slot_offset into account
>
>Am I misunderstanding how this stuff is supposed to work?  Is the
>i82365 driver doing anything wrong?
>
>(The i82365 driver also makes the incorrect assumption that PCMCIA IRQs
>directly correspond to system IRQs, but this is definately a problem
>with the driver and I've fixed that.)
>
>-jim
>

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jim Paris]

> Is your PCMCIA bridge really behind an ISA bus?
> 
> What is an address less than 16mb in your case?  Most MIPS systems have
> memory at that physical address so maybe you're not talking about
> physical addresses?

My PCMCIA controller is a VG-469, handled by i82365.c.  Its memory
space is at physical address 0x10000000-0x10FFFFFF.  By "address less
than 16mb" I meant from i82365.c's point of view; it's passing that to
ioremap and needs read[bwl] and write[bwl] to work on the result.
When ioremap adds 0x10000000, things are (mostly) happy, but is that
the wrong way to do it?

> > of the correct values.  I'm guessing this is something miscompiling --
> > I'm using the latest binutils plus gcc-3.0.2 -- has anyone see these
> 
> Try something older instead.

That fixed those problems.

-jim

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jim Paris]

> ISA, the good old stonage PC bus system with all it's limitations that also
> infected some MIPS systems.

Let me restate my problem differently, and perhaps a bit more clearly
(as I see it):

My system (Vadem Clio 1000, vr4111) has a VG-469 (i82365) PCMCIA
controller with IO port space at 0x14000000, and IO memory space
at 0x10000000.

The i82365 driver makes the following (reasonable?) expectations:

1) it can use check/request/release_region on I/O ports
 - this works fine.
2) it can use in[bwl] and out[bwl] with absolute port numbers
 - this also works fine.  
3) it can use check/request/release_mem_region on I/O memory
 - this fails, because the iomem resource map contains the kernel:
   > -more /proc/iomem
   00000000-00ffffff : System Ram
     00002000-001bc6af : Kernel code
     001cf300-00299fff : Kernel data
 (this seems very wrong to me, since the kernel is most definately
  not in the I/O memory space; real memory, of course, but I/O memory??)
4) it can use ioremap, and then read[bwl] and write[bwl] with the result
 - this fails with the current ioremap; neither ioremap nor read/write[bwl]
   take isa_slot_offset into account

Am I misunderstanding how this stuff is supposed to work?  Is the
i82365 driver doing anything wrong?

(The i82365 driver also makes the incorrect assumption that PCMCIA IRQs
directly correspond to system IRQs, but this is definately a problem
with the driver and I've fixed that.)

-jim

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jun Sun]

Jim Paris wrote:
> 
> > ISA, the good old stonage PC bus system with all it's limitations that also
> > infected some MIPS systems.
> 
> Let me restate my problem differently, and perhaps a bit more clearly
> (as I see it):
> 
> My system (Vadem Clio 1000, vr4111) has a VG-469 (i82365) PCMCIA
> controller with IO port space at 0x14000000, and IO memory space
> at 0x10000000.
> 
> The i82365 driver makes the following (reasonable?) expectations:
> 
> 1) it can use check/request/release_region on I/O ports
>  - this works fine.
> 2) it can use in[bwl] and out[bwl] with absolute port numbers
>  - this also works fine.
> 3) it can use check/request/release_mem_region on I/O memory
>  - this fails, because the iomem resource map contains the kernel:
>    > -more /proc/iomem
>    00000000-00ffffff : System Ram
>      00002000-001bc6af : Kernel code
>      001cf300-00299fff : Kernel data
>  (this seems very wrong to me, since the kernel is most definately
>   not in the I/O memory space; real memory, of course, but I/O memory??)
> 4) it can use ioremap, and then read[bwl] and write[bwl] with the result
>  - this fails with the current ioremap; neither ioremap nor read/write[bwl]
>    take isa_slot_offset into account
> 
> Am I misunderstanding how this stuff is supposed to work?  Is the
> i82365 driver doing anything wrong?
> 

It seems like i82365.c implies a PCI device.  If this is true, then things do
make sense here.

Just setting iomem_resource.end to 0xffffffff should get you by resource range
problem.

It has nothing to isa_slot_offset here.  I don't know about the history of
isa_slot_offset, but it appears to be faint effort to allow the access to what
is called "ISA memory" space on PC.  This region, if it ever exists, should
never be a separate region on a MIPS machine.  It should just be the beginning
part of PCI Memory space.

Ralf, we should just delete isa_slot_offset to avoid any further confusions.

> (The i82365 driver also makes the incorrect assumption that PCMCIA IRQs
> directly correspond to system IRQs, but this is definately a problem
> with the driver and I've fixed that.)

My understanding is that PCMCIA does it own IRQ re-mapping (somewhat similar
to P2P bridge IRQ re-mapping).

Jun

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Tue, Dec 18, 2001 at 02:03:44AM -0500, Jim Paris wrote:
> Date: Tue, 18 Dec 2001 02:03:44 -0500
> From: Jim Paris <jim@jtan.com>
> To: Ralf Baechle <ralf@oss.sgi.com>
> Cc: linux-mips@oss.sgi.com
> Subject: Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]
> 
> > ISA, the good old stonage PC bus system with all it's limitations that also
> > infected some MIPS systems.
> 
> Let me restate my problem differently, and perhaps a bit more clearly
> (as I see it):
> 
> My system (Vadem Clio 1000, vr4111) has a VG-469 (i82365) PCMCIA
> controller with IO port space at 0x14000000, and IO memory space
> at 0x10000000.

Therefore:

	set_io_port_base(0xb4000000);
	isa_slot_offset = 0xb0000000;

> The i82365 driver makes the following (reasonable?) expectations:
> 
> 1) it can use check/request/release_region on I/O ports
>  - this works fine.
> 2) it can use in[bwl] and out[bwl] with absolute port numbers
>  - this also works fine.  
> 3) it can use check/request/release_mem_region on I/O memory
>  - this fails, because the iomem resource map contains the kernel:
>    > -more /proc/iomem
>    00000000-00ffffff : System Ram
>      00002000-001bc6af : Kernel code
>      001cf300-00299fff : Kernel data
>  (this seems very wrong to me, since the kernel is most definately
>   not in the I/O memory space; real memory, of course, but I/O memory??)

No, this makes perfect sense on a 16mb system.

> 4) it can use ioremap, and then read[bwl] and write[bwl] with the result
>  - this fails with the current ioremap; neither ioremap nor read/write[bwl]
>    take isa_slot_offset into account

And that's right because isa_slot_offset is used by the isa_{read,write}[bwl]
functions which do not require ioremap having been called before.  You're
(fortunately ...) using PCI and PCI drivers are required to use ioremap.
I assume that your PCMCIA bridge is at a physical address < 0x20000000, is
that right?  If so, what ioremap returns is trivial, it's just 0x80000000
 + the argument to ioremap().  Verify that.  Also note that read[wl] and
write[wl] do byteorder swapping on the data if your system is big endian
and CONFIG_SWAP_IO_SPACE is set.

  Ralf

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jim Paris]

> It seems like i82365.c implies a PCI device.  If this is true, then things do
> make sense here.

No, the VG469 (and original i82365) is most definately an ISA device.
>From the manual: "The VG-469 has built in a standard ISA interface ..."
My machine, as much as I hate it, _does_ have an ISA bus located at
isa_slot_offset.

> It has nothing to isa_slot_offset here.  I don't know about the
> history of isa_slot_offset, but it appears to be faint effort to
> allow the access to what is called "ISA memory" space on PC.  This
> region, if it ever exists, should never be a separate region on a
> MIPS machine.  It should just be the beginning part of PCI Memory

The complete memory map of my machine is:

1FC0 0000 - 1FFF FFFF   Boot ROM
1E00 0000 - 1EFF FFFF   Flash Mem Space
1400 0000 - 14FF FFFF   VG-469 I/O Space
1000 0000 - 10FF FFFF   VG-469 Mem
0C00 0000 - 0CFF FFFF   Processor internal IO Area 1
0A00 0000 - 0A1F FFFF   LCD Frame buffer
0A20 0000 - 0A3F FFFF   S-MOS Registers
0000 0000 - 01FF FFFF   DRAM Space

As I see it, the VG-469 Mem (ie. an ISA bus, since the VG-469 is ISA)
is a separate region.

> Ralf, we should just delete isa_slot_offset to avoid any further confusions.

But my PCMCIA contoller _is_ an ISA device, and we need _something_ to
indicate where its "ISA memory" is physically mapped.  If it's not
stuck into a variable, then it's just going to be hard-coded with an
#ifdef for each architecture that does this .. ??

> My understanding is that PCMCIA does it own IRQ re-mapping (somewhat similar
> to P2P bridge IRQ re-mapping).

It's a driver issue.  Again, the i82365 is on an ISA bus, and so has
physical interrupt pins IRQ3-15, and uses these values in its
configuration and status registers.  The driver expected that these
matched system interrupts, as they usually would on an ISA
architecture; but that of course is not the case, as they're all
wired to the same GPIO pin on my system.  I've fixed this in the
driver.

-jim

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jim Paris]

> It seems like i82365.c implies a PCI device.  If this is true, then things do
> make sense here.

No, the VG469 (and original i82365) is most definately an ISA device.
From the manual: "The VG-469 has built in a standard ISA interface ..."
My machine, as much as I hate it, _does_ have an ISA bus located at
isa_slot_offset.

> It has nothing to isa_slot_offset here.  I don't know about the
> history of isa_slot_offset, but it appears to be faint effort to
> allow the access to what is called "ISA memory" space on PC.  This
> region, if it ever exists, should never be a separate region on a
> MIPS machine.  It should just be the beginning part of PCI Memory

The complete memory map of my machine is:

1FC0 0000 - 1FFF FFFF   Boot ROM
1E00 0000 - 1EFF FFFF   Flash Mem Space
1400 0000 - 14FF FFFF   VG-469 I/O Space
1000 0000 - 10FF FFFF   VG-469 Mem
0C00 0000 - 0CFF FFFF   Processor internal IO Area 1
0A00 0000 - 0A1F FFFF   LCD Frame buffer
0A20 0000 - 0A3F FFFF   S-MOS Registers
0000 0000 - 01FF FFFF   DRAM Space

As I see it, the VG-469 Mem (ie. an ISA bus, since the VG-469 is ISA)
is a separate region.

> Ralf, we should just delete isa_slot_offset to avoid any further confusions.

But my PCMCIA contoller _is_ an ISA device, and we need _something_ to
indicate where its "ISA memory" is physically mapped.  If it's not
stuck into a variable, then it's just going to be hard-coded with an
#ifdef for each architecture that does this .. ??

> My understanding is that PCMCIA does it own IRQ re-mapping (somewhat similar
> to P2P bridge IRQ re-mapping).

It's a driver issue.  Again, the i82365 is on an ISA bus, and so has
physical interrupt pins IRQ3-15, and uses these values in its
configuration and status registers.  The driver expected that these
matched system interrupts, as they usually would on an ISA
architecture; but that of course is not the case, as they're all
wired to the same GPIO pin on my system.  I've fixed this in the
driver.

-jim

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jim Paris]

> Therefore:
> 
> 	set_io_port_base(0xb4000000);
> 	isa_slot_offset = 0xb0000000;

Yep, that's what I have.

> >    > -more /proc/iomem
> >    00000000-00ffffff : System Ram
> >      00002000-001bc6af : Kernel code
> >      001cf300-00299fff : Kernel data
> >  (this seems very wrong to me, since the kernel is most definately
> >   not in the I/O memory space; real memory, of course, but I/O memory??)
> 
> No, this makes perfect sense on a 16mb system.

How so?  See the memory map I just sent in my other mail.  Should I be
adding isa_slot_offset to calls to check/request/release_mem_region?
Or should I make a isa_{check,request,release}_mem_region that adds
this in?  In which case, doesn't that turn /proc/iomem into a general
memory map rather than an I/O memory map?

> > 4) it can use ioremap, and then read[bwl] and write[bwl] with the result
> >  - this fails with the current ioremap; neither ioremap nor read/write[bwl]
> >    take isa_slot_offset into account
> 
> And that's right because isa_slot_offset is used by the isa_{read,write}[bwl]
> functions which do not require ioremap having been called before.  You're
> (fortunately ...) using PCI and PCI drivers are required to use ioremap.

No, I'm not using PCI, but it's calling ioremap anyway.  So, yes, I
suppose I could change the driver to not call ioremap and use
isa_{read,write}[bwl] (since doing both adds KSEG1 twice).
But why shouldn't ioremap + {read,write}[bwl] also work?
If it did, I wouldn't have to touch the driver.

-jim

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jun Sun]

Jim Paris wrote:
> 
> > It seems like i82365.c implies a PCI device.  If this is true, then things do
> > make sense here.
> 
> No, the VG469 (and original i82365) is most definately an ISA device.
> From the manual: "The VG-469 has built in a standard ISA interface ..."
> My machine, as much as I hate it, _does_ have an ISA bus located at
> isa_slot_offset.
> 

Really?!

Hmm, how does the driver access ISA memory area?  I did not find ioremap() nor
readb/writeb stuff.  Usually those two macros are used to access PCI memory
space.  That is the reason I said "the driver implies a PCI device".

If it is purely ISA driver, may it should use isa_read/isa_write macros, in
which case we can make use of isa_slot_offset (maybe isa_slot_offset is useful
after all. :-0)

Jun

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jun Sun]

Ralf Baechle wrote:
> 
> On Tue, Dec 18, 2001 at 02:03:44AM -0500, Jim Paris wrote:
> > Date: Tue, 18 Dec 2001 02:03:44 -0500
> > From: Jim Paris <jim@jtan.com>
> > To: Ralf Baechle <ralf@oss.sgi.com>
> > Cc: linux-mips@oss.sgi.com
> > Subject: Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]
> >
> > > ISA, the good old stonage PC bus system with all it's limitations that also
> > > infected some MIPS systems.
> >
> > Let me restate my problem differently, and perhaps a bit more clearly
> > (as I see it):
> >
> > My system (Vadem Clio 1000, vr4111) has a VG-469 (i82365) PCMCIA
> > controller with IO port space at 0x14000000, and IO memory space
> > at 0x10000000.
> 
> Therefore:
> 
>         set_io_port_base(0xb4000000);
>         isa_slot_offset = 0xb0000000;
> 

I see.  So isa_slot_offset is for isa_read/isa_write, although I still don't
see what kind of drivers would use isa_read/isa_write.

Jun

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jun Sun]

Jim Paris wrote:
 
> How so?  See the memory map I just sent in my other mail.  Should I be
> adding isa_slot_offset to calls to check/request/release_mem_region?
> Or should I make a isa_{check,request,release}_mem_region that adds
> this in?  In which case, doesn't that turn /proc/iomem into a general
> memory map rather than an I/O memory map?
> 

My understanding is that it is from PCI memory space perspective.  System ram
is mapped at lower range.

> > > 4) it can use ioremap, and then read[bwl] and write[bwl] with the result
> > >  - this fails with the current ioremap; neither ioremap nor read/write[bwl]
> > >    take isa_slot_offset into account
> >
> > And that's right because isa_slot_offset is used by the isa_{read,write}[bwl]
> > functions which do not require ioremap having been called before.  You're
> > (fortunately ...) using PCI and PCI drivers are required to use ioremap.
> 
> No, I'm not using PCI, but it's calling ioremap anyway.  So, yes, I
> suppose I could change the driver to not call ioremap and use
> isa_{read,write}[bwl] (since doing both adds KSEG1 twice).
> But why shouldn't ioremap + {read,write}[bwl] also work?
> If it did, I wouldn't have to touch the driver.

It seems like the driver assumes the ISA device is accessed through a PCI bus,
in which case the code would work.

Jun

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Tue, Dec 18, 2001 at 10:10:20AM -0800, Jun Sun wrote:

> It seems like i82365.c implies a PCI device.  If this is true, then things do
> make sense here.
> 
> Just setting iomem_resource.end to 0xffffffff should get you by resource range
> problem.

Certainly not as that is the default.

> It has nothing to isa_slot_offset here.  I don't know about the history of
> isa_slot_offset, but it appears to be faint effort to allow the access to what
> is called "ISA memory" space on PC.  This region, if it ever exists, should
> never be a separate region on a MIPS machine.  It should just be the beginning
> part of PCI Memory space.
> 
> Ralf, we should just delete isa_slot_offset to avoid any further confusions.

No way as long as there are (E)ISA systems :-(

  Ralf

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Tue, Dec 18, 2001 at 11:16:24AM -0800, Jun Sun wrote:

> I see.  So isa_slot_offset is for isa_read/isa_write, although I still don't
> see what kind of drivers would use isa_read/isa_write.

Dumb answer - ISA drivers.

  Ralf

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jun Sun]

Ralf Baechle wrote:
> 
> On Tue, Dec 18, 2001 at 11:16:24AM -0800, Jun Sun wrote:
> 
> > I see.  So isa_slot_offset is for isa_read/isa_write, although I still don't
> > see what kind of drivers would use isa_read/isa_write.
> 
> Dumb answer - ISA drivers.
> 

(Hmm, do you mean "dumb question"? :-0)  

I was thinking most ISA dirvers should simply use inb/outb to access ioports.
Don't really any ISA devices have their own memory space.  But, anyway, who
can still remember those dark ages?

Jun

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Karsten Merker]

On Tue, Dec 18, 2001 at 11:36:50AM -0800, Jun Sun wrote:

> I was thinking most ISA dirvers should simply use inb/outb to access ioports.
> Don't really any ISA devices have their own memory space.  But, anyway, who

Hm, what is with network cards such as the WD8013 or the SMC Ultra
(8 kb SRAM send- and receive-buffer)?

Greetings,
Karsten
(still happily using these, albeit on i386)
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Maciej W. Rozycki]

On Tue, 18 Dec 2001, Jun Sun wrote:

> I was thinking most ISA dirvers should simply use inb/outb to access ioports.
> Don't really any ISA devices have their own memory space.  But, anyway, who
> can still remember those dark ages?

 The so called "shared memory" (mapped in the ISA space; usually below
1MB) for frame storage existed on a few models of better ISA Ethernet
boards.  And, of course, VGA boards have memory mapped in the ISA space.
Certain implementations occupy up to 4MB of ISA space when used in a SVGA
mode.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Tue, Dec 18, 2001 at 01:57:12PM -0500, Jim Paris wrote:

> > >    > -more /proc/iomem
> > >    00000000-00ffffff : System Ram
> > >      00002000-001bc6af : Kernel code
> > >      001cf300-00299fff : Kernel data
> > >  (this seems very wrong to me, since the kernel is most definately
> > >   not in the I/O memory space; real memory, of course, but I/O memory??)
> > 
> > No, this makes perfect sense on a 16mb system.
> 
> How so?  See the memory map I just sent in my other mail.  Should I be
> adding isa_slot_offset to calls to check/request/release_mem_region?
> Or should I make a isa_{check,request,release}_mem_region that adds
> this in?  In which case, doesn't that turn /proc/iomem into a general
> memory map rather than an I/O memory map?

It's a general memory map.  Basically you have an memory address space
and an I/O space.  The latter should be treated as an entirely independant
thing just like on x86 where special instructions (in / out) are necessary
to access it.  On MIPS the difference is more blurry as this I/O port
addres space is accessible through normal load / store instructions.

> > And that's right because isa_slot_offset is used by the isa_{read,write}[bwl]
> > functions which do not require ioremap having been called before.  You're
> > (fortunately ...) using PCI and PCI drivers are required to use ioremap.
> 
> No, I'm not using PCI, but it's calling ioremap anyway.  So, yes, I
> suppose I could change the driver to not call ioremap and use
> isa_{read,write}[bwl] (since doing both adds KSEG1 twice).
> But why shouldn't ioremap + {read,write}[bwl] also work?
> If it did, I wouldn't have to touch the driver.

Well, calling ioremap anyway is ok.  The whole isa_* thing was invented to
make keeping the large number of antique ISA drivers that don't have any
maintainers alive.

  Ralf

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Jim Paris]

> > How so?  See the memory map I just sent in my other mail.  Should I be
> > adding isa_slot_offset to calls to check/request/release_mem_region?
> > Or should I make a isa_{check,request,release}_mem_region that adds
> > this in?  In which case, doesn't that turn /proc/iomem into a general
> > memory map rather than an I/O memory map?
> 
> It's a general memory map.  Basically you have an memory address space
> and an I/O space.  The latter should be treated as an entirely independant
> thing just like on x86 where special instructions (in / out) are necessary
> to access it.  On MIPS the difference is more blurry as this I/O port
> addres space is accessible through normal load / store instructions.

The ports are dealt with by /proc/ioports.  What about /proc/iomem?
The ISA ports and ISA memory are seperate, and the ports work fine and
just as I would expect them to.  But for memory, where should the
PCMCIA driver be reserving space?  Should I 
1) make /proc/iomem contain addresses relative to the start of I/O memory,
   just as /proc/ioports contains addresses relative to the start of
   I/O port space?  This will only work if I stop letting the kernel
   reserve the iomem resource for system memory.
2) make the i82365 driver use absolute addresses in /proc/iomem, by
   adding (isa_slot_offset - KSEG1) to all *_mem_resource calls?
   (breaks i82365 for other arches)
3) Invent a new resource "isamem", reserve the correct absolute
   addresses in "iomem", and the modify the i82365 driver to use 
   "isamem" instead?  (again breaks i82365 for other arches)

> Well, calling ioremap anyway is ok. 

How is calling ioremap anyway ok?  If I

1) call ioremap and then use read[bwl], then isa_slot_offset never
   comes into play and nothing works
2) call ioremap and then use isa_read[bwl], then KSEG1 gets included
   twice and nothing works

> The whole isa_* thing was invented to
> make keeping the large number of antique ISA drivers that don't have any
> maintainers alive.

I'm willing to take the "maintainer" role here and rewrite the driver
properly, but I'm still not understanding what the proper way is.
Given the current way the I/O memory is handled on MIPS, the only way
I can get the i82365 driver working breaks it for every other arch.

-jim

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Maciej W. Rozycki]

On Tue, 18 Dec 2001, Jim Paris wrote:

> The ports are dealt with by /proc/ioports.  What about /proc/iomem?
> The ISA ports and ISA memory are seperate, and the ports work fine and
> just as I would expect them to.  But for memory, where should the
> PCMCIA driver be reserving space?  Should I 
> 1) make /proc/iomem contain addresses relative to the start of I/O memory,
>    just as /proc/ioports contains addresses relative to the start of
>    I/O port space?  This will only work if I stop letting the kernel
>    reserve the iomem resource for system memory.

 There should probably be an ISA memory space reserved somewhere in the
CPU memory space (/proc/iomem reflects memory addresses as seen by the
CPU).  You should reserve resources within it.

 There should be an ISA I/O space reserved somewhere in /proc/iomem, too,
as the I/O space is real only for CPUs defining special bus cycles for I/O
accesses (MIPS is not one of them, hence it must be done by the chipset).
The /proc/ioports reports addresses relative to that space.

> 2) make the i82365 driver use absolute addresses in /proc/iomem, by
>    adding (isa_slot_offset - KSEG1) to all *_mem_resource calls?
>    (breaks i82365 for other arches)

 Mapping between physical addresses and MIPS virtual addresses (KSEG1 is a
virtual address) should be done by bus access functions (or macros), such
as inb/outb/readl/readw/isa_readb/isa_readw, etc.  See the Alpha port for
how it should be done.  It appears to have done it particularly cleanly. 

> 3) Invent a new resource "isamem", reserve the correct absolute
>    addresses in "iomem", and the modify the i82365 driver to use 
>    "isamem" instead?  (again breaks i82365 for other arches)

 Don't do it.

> Given the current way the I/O memory is handled on MIPS, the only way
> I can get the i82365 driver working breaks it for every other arch.

 Then the MIPS I/O memory handling is broken.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Tue, Dec 18, 2001 at 11:36:50AM -0800, Jun Sun wrote:

> > > I see.  So isa_slot_offset is for isa_read/isa_write, although I still don't
> > > see what kind of drivers would use isa_read/isa_write.
> > 
> > Dumb answer - ISA drivers.
> 
> (Hmm, do you mean "dumb question"? :-0)  

Somewhere I heared there are only dumb answers, no dumb questions :-)

> I was thinking most ISA dirvers should simply use inb/outb to access ioports.
> Don't really any ISA devices have their own memory space.  But, anyway, who
> can still remember those dark ages?

Isa_slot_offset is related to memory mapped I/O, in and out are not
memory mapped I/O.

  Ralf

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Geert Uytterhoeven]

On Tue, 18 Dec 2001, Jim Paris wrote:
> > Therefore:
> > 
> > 	set_io_port_base(0xb4000000);
> > 	isa_slot_offset = 0xb0000000;
> 
> Yep, that's what I have.
> 
> > >    > -more /proc/iomem
> > >    00000000-00ffffff : System Ram
> > >      00002000-001bc6af : Kernel code
> > >      001cf300-00299fff : Kernel data
> > >  (this seems very wrong to me, since the kernel is most definately
> > >   not in the I/O memory space; real memory, of course, but I/O memory??)
> > 
> > No, this makes perfect sense on a 16mb system.
> 
> How so?  See the memory map I just sent in my other mail.  Should I be
> adding isa_slot_offset to calls to check/request/release_mem_region?
> Or should I make a isa_{check,request,release}_mem_region that adds
> this in?  In which case, doesn't that turn /proc/iomem into a general
> memory map rather than an I/O memory map?

IMHO you should create isa_{check,request,release}_mem_region().

I said it many times before on linux-kernel, but it doesn't help :-(
I'm facing the same problem on PPC, where ISA memory space is not at address 0.

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: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Geert Uytterhoeven]

On Tue, 18 Dec 2001, Jun Sun wrote:
> Ralf Baechle wrote:
> > Therefore:
> > 
> >         set_io_port_base(0xb4000000);
> >         isa_slot_offset = 0xb0000000;
> > 
> 
> I see.  So isa_slot_offset is for isa_read/isa_write, although I still don't
> see what kind of drivers would use isa_read/isa_write.

E.g. VGA and ISA NVRAM.

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: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Geert Uytterhoeven]

On Tue, 18 Dec 2001, Jun Sun wrote:
> It has nothing to isa_slot_offset here.  I don't know about the history of
> isa_slot_offset, but it appears to be faint effort to allow the access to what
> is called "ISA memory" space on PC.  This region, if it ever exists, should
> never be a separate region on a MIPS machine.  It should just be the beginning
> part of PCI Memory space.

It's indeed the beginning of PCI memory space, but only when viewed from the
viewpoint of the PCI bus itself, not necessarily from the viewpoint of the CPU.

On ia32 PCs it is, but not on many PPC boxes. And I guess on some MIPS boxes as
well.

> Ralf, we should just delete isa_slot_offset to avoid any further confusions.

Ugh...

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: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Wed, Dec 19, 2001 at 10:34:37AM +0100, Geert Uytterhoeven wrote:

> > >         set_io_port_base(0xb4000000);
> > >         isa_slot_offset = 0xb0000000;
> > 
> > I see.  So isa_slot_offset is for isa_read/isa_write, although I still don't
> > see what kind of drivers would use isa_read/isa_write.
> 
> E.g. VGA and ISA NVRAM.

Correct.  And much much more, the whole PC insanity.  There are plenty of
MIPS systems that are essentially PCs with a MIPS CPU glued on so you get
all the fun, ISA, EISA, VLB etc.  Barf bag technology.

  Ralf

Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]

[Ralf Baechle]

On Wed, Dec 19, 2001 at 10:34:04AM +0100, Geert Uytterhoeven wrote:

> IMHO you should create isa_{check,request,release}_mem_region().
> 
> I said it many times before on linux-kernel, but it doesn't help :-(
> I'm facing the same problem on PPC, where ISA memory space is not at address 0.

Sounds good to me.  That would also solve certain problems on machine like
the RM200C where we have to cheat a little bit to get things to work.

  Ralf