ISA

ISA

[Jim Paris]

Okay, so I'll change the i82365 driver to use isa_{read,write}[bwl]
instead of ioremap & {read,write}[bwl], when CONFIG_ISA is defined.
That shouldn't break other architectures.

But how should I deal with {check,request,release}_mem_region? 
Should I make isa_{check,request,release}_mem_region which adds
isa_slot_offset to all of the memory addresses?  Or should I add
isa_slot_offset - KSEG1?  Or..?

-jim

Re: ISA

[Bradley D. LaRonde]

----- Original Message ----- 
From: "Jim Paris" <jim@jtan.com>
To: <linux-mips@oss.sgi.com>
Sent: Tuesday, December 18, 2001 3:04 PM
Subject: ISA


> Okay, so I'll change the i82365 driver to use isa_{read,write}[bwl]
> instead of ioremap & {read,write}[bwl], when CONFIG_ISA is defined.
> That shouldn't break other architectures.

Admittedly I haven't studied this, but ugh... can't we let isa_* die?

Regards,
Brad

Re: ISA

[Bradley D. LaRonde]

----- Original Message ----- 
From: "Jim Paris" <jim@jtan.com>
To: <linux-mips@oss.sgi.com>
Sent: Tuesday, December 18, 2001 3:04 PM
Subject: ISA


> Okay, so I'll change the i82365 driver to use isa_{read,write}[bwl]
> instead of ioremap & {read,write}[bwl], when CONFIG_ISA is defined.
> That shouldn't break other architectures.

Admittedly I haven't studied this, but ugh... can't we let isa_* die?

Regards,
Brad

Re: ISA

[Jim Paris]

> > Okay, so I'll change the i82365 driver to use isa_{read,write}[bwl]
> > instead of ioremap & {read,write}[bwl], when CONFIG_ISA is defined.
> > That shouldn't break other architectures.
> 
> Admittedly I haven't studied this, but ugh... can't we let isa_* die?

I am all for letting it die, but I'm still not getting a clear answer
on what the alternative is.  The only way to avoid isa_* as I see it
is to fix two problems in the MIPS kernel:

1) Isn't the purpose of ioremap to remap I/O memory addresses to
   physical ones?  For an ISA architecture like mine, this means
   it needs to add isa_slot_offset.
2) /proc/iomem should not contain system RAM.  The RAM is not 
   in I/O memory space on my system, so why does it show up in the
   iomem resource?  On x86, sure, I/O and RAM memory space are the
   same, but they're not here.

Please explain to me again why the current implementation of these two
behaviors is correct.  If both of these problems are fixed, the i82365
driver will work _as is_, as will any other ISA driver that calls 
ioremap() before using {read,write}[bwl].

-jim

 

Re: ISA

[Maciej W. Rozycki]

On Tue, 18 Dec 2001, Jim Paris wrote:

> 1) Isn't the purpose of ioremap to remap I/O memory addresses to
>    physical ones?  For an ISA architecture like mine, this means
>    it needs to add isa_slot_offset.

 Yes it is.  Also see Documentation/IO-mapping.txt and the Alpha port.

> 2) /proc/iomem should not contain system RAM.  The RAM is not 
>    in I/O memory space on my system, so why does it show up in the
>    iomem resource?  On x86, sure, I/O and RAM memory space are the
>    same, but they're not here.

 It *has to* contain the system RAM.  Otherwise a device driver would be
allowed to grab a chunk of that memory successfully, possibly destroying
the system.  Now it gets an error and can gracefully handle it if it tries
to get the memory for some, possibly legitimate reason. 

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

Re: ISA

[Jim Paris]

> > 1) Isn't the purpose of ioremap to remap I/O memory addresses to
> >    physical ones?  For an ISA architecture like mine, this means
> >    it needs to add isa_slot_offset.
> 
>  Yes it is.  Also see Documentation/IO-mapping.txt and the Alpha port.

So I should modify ioremap to return (addr+isa_slot_offset) when
CONFIG_ISA is defined and the given I/O address is in the 16 MB ISA
range.  That will make things work according to Linus' description of
how they should.

>  It *has to* contain the system RAM.  Otherwise a device driver would be
> allowed to grab a chunk of that memory successfully, possibly destroying
> the system.  Now it gets an error and can gracefully handle it if it tries
> to get the memory for some, possibly legitimate reason. 

Okay, point.  So the i82365 driver is at fault when it calls
check_mem_region(ISA_address).  How should I fix that?  Should it
call check_mem_region(ioremap(ISA_address)) instead?  

Or should /proc/iomap contain physical addresses, which the i82365
driver has no way of knowing without breaking abstractions?  (And if
that's the case, how should I do it?  Create isa_check_mem_region?)

-jim

Re: ISA

[Jun Sun]

Jim Paris wrote:
> 
> > > 1) Isn't the purpose of ioremap to remap I/O memory addresses to
> > >    physical ones?  For an ISA architecture like mine, this means
> > >    it needs to add isa_slot_offset.
> >
> >  Yes it is.  Also see Documentation/IO-mapping.txt and the Alpha port.
> 
> So I should modify ioremap to return (addr+isa_slot_offset) when
> CONFIG_ISA is defined and the given I/O address is in the 16 MB ISA
> range. 

I would consider it only as a workaround rather than a fix.

You need to make sure all other PCI-based boards have isa_slot_offset set to
0.

ioremap() has been used by many PCI device drivers, and on MIPS it assumes 1:1
mapping between PCI memory space and CPU physical space.  It have been working
so far either because PCI device BARs are shuffled around to match their
physical address (from CPU point of view) or dev structure is modified
propoerly with special fixups.

Now when people using ioremap/readb/writeb method to access ISA memory space,
which lives in the lower range of the "bus memory space", it will collide with
system ram under 1:1 mapping assumption.

Extending isa_slot_offset to something like 'mips_io_mem_offset' may be the
right way to go.  This implies 

1) all PCI-based systems need to set this value to the physical address of the
beginning of PCI memory space window.

2) ioremap() always add this base.

3) when assigning PCI BARs, we need to substract this offset from the
corresponding physical address.  Host-PCI controller needs to be setup
accordingly to do the above substractive address translation.

> 
> >  It *has to* contain the system RAM.  Otherwise a device driver would be
> > allowed to grab a chunk of that memory successfully, possibly destroying
> > the system.  Now it gets an error and can gracefully handle it if it tries
> > to get the memory for some, possibly legitimate reason.
> 
> Okay, point.  So the i82365 driver is at fault when it calls
> check_mem_region(ISA_address).  How should I fix that?  Should it
> call check_mem_region(ioremap(ISA_address)) instead?
>
> Or should /proc/iomap contain physical addresses, which the i82365
> driver has no way of knowing without breaking abstractions?  (And if
> that's the case, how should I do it?  Create isa_check_mem_region?)

Creating isa_check_mem_region() seems to be the right thing but not
necessarily the desirable thing to do, especially people are moving from ISA.

In fact, if isa_read/isa_write do break for other arches (Why would they?),
modifying the driver to use these macros might be best way to solve this
problem.

Jun


> 
> -jim

Re: ISA

[Maciej W. Rozycki]

On Tue, 18 Dec 2001, Jim Paris wrote:

> So I should modify ioremap to return (addr+isa_slot_offset) when
> CONFIG_ISA is defined and the given I/O address is in the 16 MB ISA
> range.  That will make things work according to Linus' description of
> how they should.

 Yep.

> Okay, point.  So the i82365 driver is at fault when it calls
> check_mem_region(ISA_address).  How should I fix that?  Should it
> call check_mem_region(ioremap(ISA_address)) instead?  

 Hmm, it looks no ISA device driver bothers to handle iomem resources.  I
believe check_mem_region(virt_to_phys(ioremap(ISA_address)), ...) should
work, but I haven't checked.  Note that you should probably look at the
*_resource() functions (as declared in <linux/ioport.h>) as *_region() 
ones seem to be doomed obsolete. 

> Or should /proc/iomap contain physical addresses, which the i82365
> driver has no way of knowing without breaking abstractions?  (And if
> that's the case, how should I do it?  Create isa_check_mem_region?)

 /proc/iomem (I suppose it is what you meant) does contain physical
addresses. 

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

Re: ISA

[Maciej W. Rozycki]

On Tue, 18 Dec 2001, Jun Sun wrote:

> > So I should modify ioremap to return (addr+isa_slot_offset) when
> > CONFIG_ISA is defined and the given I/O address is in the 16 MB ISA
> > range. 
> 
> I would consider it only as a workaround rather than a fix.

 Why?

> You need to make sure all other PCI-based boards have isa_slot_offset set to
> 0.

 I don't think it's needed.  Why to refer to isa_slot_offset for PCI
accesses at all?

> ioremap() has been used by many PCI device drivers, and on MIPS it assumes 1:1
> mapping between PCI memory space and CPU physical space.  It have been working
> so far either because PCI device BARs are shuffled around to match their
> physical address (from CPU point of view) or dev structure is modified
> propoerly with special fixups.
> 
> Now when people using ioremap/readb/writeb method to access ISA memory space,
> which lives in the lower range of the "bus memory space", it will collide with
> system ram under 1:1 mapping assumption.

 Hmm, I believe there should be no such problem.  For systems equipped
with the PCI bus we may just assume the low 16MB of PCI memory address
space is reserved for ISA memory addresses (it's hardwired for many
platforms, so there should be no problem with it), i.e. avoid programming
BARs to point to that space and make ioremap() (or __ioremap(), actually)
act accordingly, i.e. assume a 1:1 mapping for addresses above 16MB and
perform an ISA mapping for ones below 16MB. 

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

Re: ISA

[Bradley D. LaRonde]

----- Original Message -----
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Jun Sun" <jsun@mvista.com>
Cc: <jim@jtan.com>; <linux-mips@oss.sgi.com>
Sent: Tuesday, December 18, 2001 8:50 PM
Subject: Re: ISA


> On Tue, 18 Dec 2001, Jun Sun wrote:
> > Now when people using ioremap/readb/writeb method to access ISA memory
space,
> > which lives in the lower range of the "bus memory space", it will
collide with
> > system ram under 1:1 mapping assumption.
>
>  Hmm, I believe there should be no such problem.  For systems equipped
> with the PCI bus we may just assume the low 16MB of PCI memory address
> space is reserved for ISA memory addresses (it's hardwired for many
> platforms, so there should be no problem with it), i.e. avoid programming
> BARs to point to that space and make ioremap() (or __ioremap(), actually)
> act accordingly, i.e. assume a 1:1 mapping for addresses above 16MB and
> perform an ISA mapping for ones below 16MB.

That sounds like the simplest and best solution.

Regards,
Brad

Re: ISA

[Bradley D. LaRonde]

----- Original Message -----
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Jun Sun" <jsun@mvista.com>
Cc: <jim@jtan.com>; <linux-mips@oss.sgi.com>
Sent: Tuesday, December 18, 2001 8:50 PM
Subject: Re: ISA


> On Tue, 18 Dec 2001, Jun Sun wrote:
> > Now when people using ioremap/readb/writeb method to access ISA memory
space,
> > which lives in the lower range of the "bus memory space", it will
collide with
> > system ram under 1:1 mapping assumption.
>
>  Hmm, I believe there should be no such problem.  For systems equipped
> with the PCI bus we may just assume the low 16MB of PCI memory address
> space is reserved for ISA memory addresses (it's hardwired for many
> platforms, so there should be no problem with it), i.e. avoid programming
> BARs to point to that space and make ioremap() (or __ioremap(), actually)
> act accordingly, i.e. assume a 1:1 mapping for addresses above 16MB and
> perform an ISA mapping for ones below 16MB.

That sounds like the simplest and best solution.

Regards,
Brad

Re: ISA

[Jun Sun]

"Maciej W. Rozycki" wrote:

>  Hmm, I believe there should be no such problem.  For systems equipped
> with the PCI bus we may just assume the low 16MB of PCI memory address
> space is reserved for ISA memory addresses (it's hardwired for many
> platforms, so there should be no problem with it), i.e. avoid programming
> BARs to point to that space and make ioremap() (or __ioremap(), actually)
> act accordingly, i.e. assume a 1:1 mapping for addresses above 16MB and
> perform an ISA mapping for ones below 16MB.

I see.  I missed that part where you have a pivoting point at 16MB.

That sounds like a working solution to me.

Overall, I still feel using isa_xxx() macros in the driver seems like a
cleaner solution.  That essentially treats ISA memory space as a separate
space.  The ioremap/readb/writeb approach tries to lump ISA memory and PCI
memory space together but in fact we still have treat them differently (based
on whether the address is greater than 16MB, which is a little hackish.)

Jun

Re: ISA

[Maciej W. Rozycki]

On Tue, 18 Dec 2001, Jun Sun wrote:

> Overall, I still feel using isa_xxx() macros in the driver seems like a
> cleaner solution.  That essentially treats ISA memory space as a separate

 It depends on what you want to do.  For one isa_xxx() functions/macros
do not permit to control caching.

> space.  The ioremap/readb/writeb approach tries to lump ISA memory and PCI
> memory space together but in fact we still have treat them differently (based
> on whether the address is greater than 16MB, which is a little hackish.)

 The problem is a lone address doesn't really tell us what bus is it
expected to come from.  And practically there are few systems having
unrelated I/O buses implemented.  I don't know if any of them is supported
by Linux.  PCI and ISA are historically related, i.e. ISA is usually
accessed via a PCI-ISA bridge with a hardwired address mapping.  I don't
know any system doing it differently -- even Alphas do it this way.

 The *_resource() functions might help as you may refer to particular
resources with them, but I don't think a generic way for a multi-bus
system was defined.  Maybe the problem needs to be discussed at
linux-kernel.  It's generic after all. 

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

Re: ISA

[Geert Uytterhoeven]

On Wed, 19 Dec 2001, Maciej W. Rozycki wrote:
> On Tue, 18 Dec 2001, Jun Sun wrote:
> > Overall, I still feel using isa_xxx() macros in the driver seems like a
> > cleaner solution.  That essentially treats ISA memory space as a separate
> 
>  It depends on what you want to do.  For one isa_xxx() functions/macros
> do not permit to control caching.
> 
> > space.  The ioremap/readb/writeb approach tries to lump ISA memory and PCI
> > memory space together but in fact we still have treat them differently (based
> > on whether the address is greater than 16MB, which is a little hackish.)

You must _not_ use readb()/writeb() and friends with ISA memory space!
You must use isa_readb()/isa_writeb() and friends!

>  The problem is a lone address doesn't really tell us what bus is it
> expected to come from.  And practically there are few systems having
> unrelated I/O buses implemented.  I don't know if any of them is supported
> by Linux.  PCI and ISA are historically related, i.e. ISA is usually
> accessed via a PCI-ISA bridge with a hardwired address mapping.  I don't
> know any system doing it differently -- even Alphas do it this way.
> 
>  The *_resource() functions might help as you may refer to particular
> resources with them, but I don't think a generic way for a multi-bus
> system was defined.  Maybe the problem needs to be discussed at
> linux-kernel.  It's generic after all. 

The problem is that ISA memory space is only half-assed considered separate:
you have seperate isa_readb()/isa_writeb() and friends, but not the
corresponding isa_io{re,un}map() and isa_{request,release}_mem_region().

So while isa_readb()/isa_writeb() and friends can add isa_slot_offset (or
how-is-it-called on your random architecture), io{re,un}map() and
{request,release}_mem_region() can't.

For I/O accesses (inb() and friends), there's no problem, since ISA I/O is a
real subset of PCI I/O.

But for memory accesses, ISA memory space is not necessarily 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: ISA

[Alan Cox]

> You must _not_ use readb()/writeb() and friends with ISA memory space!
> You must use isa_readb()/isa_writeb() and friends!

Linus is saying the reverse. Drivers are moving away from isa_

> But for memory accesses, ISA memory space is not necessarily at `address 0'.

ioremap uses ookies, its up to yoyu what you hide in the cookie from an ISA
ioremap

Re: ISA

[Alan Cox]

> You must _not_ use readb()/writeb() and friends with ISA memory space!
> You must use isa_readb()/isa_writeb() and friends!

Linus is saying the reverse. Drivers are moving away from isa_

> But for memory accesses, ISA memory space is not necessarily at `address 0'.

ioremap uses ookies, its up to yoyu what you hide in the cookie from an ISA
ioremap

Re: ISA

[Geert Uytterhoeven]

On Wed, 19 Dec 2001, Alan Cox wrote:
> > You must _not_ use readb()/writeb() and friends with ISA memory space!
> > You must use isa_readb()/isa_writeb() and friends!
> 
> Linus is saying the reverse. Drivers are moving away from isa_
> 
> > But for memory accesses, ISA memory space is not necessarily at `address 0'.
> 
> ioremap uses ookies, its up to yoyu what you hide in the cookie from an ISA
> ioremap

OK, so I can check for < 16 MB in ioremap(), and readb() and friends will
handle it fine. You're not supposed to call ioremap() for real RAM anyway, so
there's no ambiguity.

But what about request_mem_region() and friends? How can I distinguish between
ISA memory and the first 16 MB of RAM (or ROM, or whatever my board has there)?

Or am I not supposed to let those things show up in /proc/iomem?

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

[Maciej W. Rozycki]

On Wed, 19 Dec 2001, Geert Uytterhoeven wrote:

> OK, so I can check for < 16 MB in ioremap(), and readb() and friends will
> handle it fine. You're not supposed to call ioremap() for real RAM anyway, so
> there's no ambiguity.
> 
> But what about request_mem_region() and friends? How can I distinguish between
> ISA memory and the first 16 MB of RAM (or ROM, or whatever my board has there)?

 Well, as I stated in another mail (but in another thread, I think) you
may try request_mem_region(virt_to_phys(ioremap(...))), especially as you
really want to reserve an area in the CPU's physical address space and not
in the bus's one.

> Or am I not supposed to let those things show up in /proc/iomem?

 I think the appearance is not the point here.  The point is to prevent a
driver from accessing an already occupied area. 

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

Re: ISA

[Geert Uytterhoeven]

On Thu, 20 Dec 2001, Maciej W. Rozycki wrote:
> On Wed, 19 Dec 2001, Geert Uytterhoeven wrote:
> > OK, so I can check for < 16 MB in ioremap(), and readb() and friends will
> > handle it fine. You're not supposed to call ioremap() for real RAM anyway, so
> > there's no ambiguity.
> > 
> > But what about request_mem_region() and friends? How can I distinguish between
> > ISA memory and the first 16 MB of RAM (or ROM, or whatever my board has there)?
> 
>  Well, as I stated in another mail (but in another thread, I think) you
> may try request_mem_region(virt_to_phys(ioremap(...))), especially as you
> really want to reserve an area in the CPU's physical address space and not
> in the bus's one.

So we must update all existing drivers that use ISA memory space anyway.

IMHO still better to add isa_request_mem_region() while we're at it, so we can
solve this in an arch-specific way. Ia32 can still say

    #define isa_request_mem_region	request_mem_region

> > Or am I not supposed to let those things show up in /proc/iomem?
> 
>  I think the appearance is not the point here.  The point is to prevent a
> driver from accessing an already occupied area. 

Right.

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

[Maciej W. Rozycki]

On Thu, 20 Dec 2001, Geert Uytterhoeven wrote:

> >  Well, as I stated in another mail (but in another thread, I think) you
> > may try request_mem_region(virt_to_phys(ioremap(...))), especially as you
> > really want to reserve an area in the CPU's physical address space and not
> > in the bus's one.
> 
> So we must update all existing drivers that use ISA memory space anyway.

 Not many of them calls request_mem_region()...  Not that it is good. 

> IMHO still better to add isa_request_mem_region() while we're at it, so we can
> solve this in an arch-specific way. Ia32 can still say
> 
>     #define isa_request_mem_region	request_mem_region

 And then "<bus>_request_mem_region" for every new bus supported??? 

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

Re: ISA

[Geert Uytterhoeven]

On Thu, 20 Dec 2001, Maciej W. Rozycki wrote:
> On Thu, 20 Dec 2001, Geert Uytterhoeven wrote:
> > >  Well, as I stated in another mail (but in another thread, I think) you
> > > may try request_mem_region(virt_to_phys(ioremap(...))), especially as you
> > > really want to reserve an area in the CPU's physical address space and not
> > > in the bus's one.
> > 
> > So we must update all existing drivers that use ISA memory space anyway.
> 
>  Not many of them calls request_mem_region()...  Not that it is good. 
> 
> > IMHO still better to add isa_request_mem_region() while we're at it, so we can
> > solve this in an arch-specific way. Ia32 can still say
> > 
> >     #define isa_request_mem_region	request_mem_region
> 
>  And then "<bus>_request_mem_region" for every new bus supported??? 

Yes, you have <bus>_ioremap() anyway, since plain ioremap() is for PCI only.

And then struct busops starts looking like an interesting direction...

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

[Maciej W. Rozycki]

On Thu, 20 Dec 2001, Geert Uytterhoeven wrote:

> Yes, you have <bus>_ioremap() anyway, since plain ioremap() is for PCI only.

 Indeed.  But then ioremap() naming is inconsistent -- pci_ioremap()
should be defined and used for PCI and ioremap() should be reserved for
mapping devices straightly from the CPU's physical space (think devices
plugged into CPU's local memory sockets -- I have one here).

> And then struct busops starts looking like an interesting direction...

 Agreed.

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

Re: ISA

[Alan Cox]

> But what about request_mem_region() and friends? How can I distinguish between
> ISA memory and the first 16 MB of RAM (or ROM, or whatever my board has there)?
> 
> Or am I not supposed to let those things show up in /proc/iomem?

Interesting - I'd not considered that. Is ISA and non ISA space seperate on
MIPS or is it all rather ambiguous ?

Re: ISA

[Alan Cox]

> But what about request_mem_region() and friends? How can I distinguish between
> ISA memory and the first 16 MB of RAM (or ROM, or whatever my board has there)?
> 
> Or am I not supposed to let those things show up in /proc/iomem?

Interesting - I'd not considered that. Is ISA and non ISA space seperate on
MIPS or is it all rather ambiguous ?

Re: ISA

[Jim Paris]

> Interesting - I'd not considered that. Is ISA and non ISA space seperate on
> MIPS or is it all rather ambiguous ?

On my particular machine, system RAM is at 0x00000000, and ISA I/O
memory is at 0x10000000.  The driver I'm currently trying to work with
calls check_mem_region with ISA addresses, which of course breaks when
ISA memory isn't at zero.  One suggestion was to patch the driver to
use something like

    check_mem_region(virt_to_phys(ioremap(ISA_address)), ...)

which might be the best way for now?  I think a more generic way to
abstract away a bus (and support multiple types and numbers of I/O
busses) is really necessary though.  Some way to register a bus with
the kernel, and bind particular busses to particular instances of
drivers, or something.

-jim

Re: ISA

[Jun Sun]

On Fri, Dec 21, 2001 at 01:44:52PM -0500, Jim Paris wrote:
> > Interesting - I'd not considered that. Is ISA and non ISA space seperate on
> > MIPS or is it all rather ambiguous ?
> 
> On my particular machine, system RAM is at 0x00000000, and ISA I/O
> memory is at 0x10000000.  The driver I'm currently trying to work with
> calls check_mem_region with ISA addresses, which of course breaks when
> ISA memory isn't at zero.  One suggestion was to patch the driver to
> use something like
> 
>     check_mem_region(virt_to_phys(ioremap(ISA_address)), ...)
> 
> which might be the best way for now? 

I agree with Geert and think isa_xxx_mem_region is a better approach.
Unfortunately, this requires a change in both dirver and
arch-specific part.

> I think a more generic way to
> abstract away a bus (and support multiple types and numbers of I/O
> busses) is really necessary though.  Some way to register a bus with
> the kernel, and bind particular busses to particular instances of
> drivers, or something.
>

I have talked with somebody before about the address apace idea, which
is rather similar to what you are talking :

1. each address space has an id.
2. kernel pre-defines a couple of well-known ones, 0 for CPU physical, 
   1 for virtual, etc.
3. When drivers discover the devices, they get the address and also
   the address space id where the address resides.
4. there are a set of macro's that converts/maps an address or an
   address region from one space to another.

This generalized form allows multiple-PCI buses to use substractive decoding.
Also removes the 1:1 mapping requirement between PCI memory space and
CPU physical address space.

However, the detailed implementation can be hairy, which is why it 
is still an idea. :-)

Jun

Re: ISA

[Bradley D. LaRonde]

----- Original Message -----
From: "Jun Sun" <jsun@mvista.com>
To: "Jim Paris" <jim@jtan.com>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>; "Geert Uytterhoeven"
<Geert.Uytterhoeven@sonycom.com>; "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>;
"Linux/MIPS Development" <linux-mips@oss.sgi.com>
Sent: Tuesday, January 01, 2002 2:22 PM
Subject: Re: ISA


> 1. each address space has an id.
> 2. kernel pre-defines a couple of well-known ones, 0 for CPU physical,
>    1 for virtual, etc.
> 3. When drivers discover the devices, they get the address and also
>    the address space id where the address resides.
> 4. there are a set of macro's that converts/maps an address or an
>    address region from one space to another.

The first thing that jumps out at me is that now every bus access has an
added switch in it.

Either that or drivers would get back access function pointers, but that
eliminates the chance to inline trivial bus accesses.

Regards,
Brad

Re: ISA

[Alan Cox]

> >     check_mem_region(virt_to_phys(ioremap(ISA_address)), ...)
> > 
> > which might be the best way for now? 
> 
> I agree with Geert and think isa_xxx_mem_region is a better approach.
> Unfortunately, this requires a change in both dirver and
> arch-specific part.

Its something that can be done progressively however as we fixup stuff.
It'll just "happen" to work on x86 either way.

Alan

Re: ISA

[Alan Cox]

> >     check_mem_region(virt_to_phys(ioremap(ISA_address)), ...)
> > 
> > which might be the best way for now? 
> 
> I agree with Geert and think isa_xxx_mem_region is a better approach.
> Unfortunately, this requires a change in both dirver and
> arch-specific part.

Its something that can be done progressively however as we fixup stuff.
It'll just "happen" to work on x86 either way.

Alan

Re: ISA

[M. Warner Losh]

You should look at BSD's bus_space.  IT solves this problem without
having to put architecturally specific kludged into each driver.

Warner

Re: ISA

[Geert Uytterhoeven]

On Tue, 1 Jan 2002, Bradley D. LaRonde wrote:
> ----- Original Message -----
> From: "Jun Sun" <jsun@mvista.com>
> To: "Jim Paris" <jim@jtan.com>
> Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>; "Geert Uytterhoeven"
> <Geert.Uytterhoeven@sonycom.com>; "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>;
> "Linux/MIPS Development" <linux-mips@oss.sgi.com>
> Sent: Tuesday, January 01, 2002 2:22 PM
> Subject: Re: ISA
> 
> 
> > 1. each address space has an id.
> > 2. kernel pre-defines a couple of well-known ones, 0 for CPU physical,
> >    1 for virtual, etc.
> > 3. When drivers discover the devices, they get the address and also
> >    the address space id where the address resides.
> > 4. there are a set of macro's that converts/maps an address or an
> >    address region from one space to another.
> 
> The first thing that jumps out at me is that now every bus access has an
> added switch in it.
> 
> Either that or drivers would get back access function pointers, but that
> eliminates the chance to inline trivial bus accesses.

Not completely. ioremap() and friends can handle the address space ID and
return an appropriate pointer. That pointer can still be handled by readl() and
friends.

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

[Bradley D. LaRonde]

----- Original Message -----
From: "Geert Uytterhoeven" <geert@linux-m68k.org>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: "Jun Sun" <jsun@mvista.com>; "Jim Paris" <jim@jtan.com>; "Alan Cox"
<alan@lxorguk.ukuu.org.uk>; "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>;
"Linux/MIPS Development" <linux-mips@oss.sgi.com>
Sent: Wednesday, January 02, 2002 4:41 AM
Subject: Re: ISA


> On Tue, 1 Jan 2002, Bradley D. LaRonde wrote:
> > ----- Original Message -----
> > From: "Jun Sun" <jsun@mvista.com>
> > To: "Jim Paris" <jim@jtan.com>
> > Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>; "Geert Uytterhoeven"
> > <Geert.Uytterhoeven@sonycom.com>; "Maciej W. Rozycki"
<macro@ds2.pg.gda.pl>;
> > "Linux/MIPS Development" <linux-mips@oss.sgi.com>
> > Sent: Tuesday, January 01, 2002 2:22 PM
> > Subject: Re: ISA
> >
> >
> > > 1. each address space has an id.
> > > 2. kernel pre-defines a couple of well-known ones, 0 for CPU physical,
> > >    1 for virtual, etc.
> > > 3. When drivers discover the devices, they get the address and also
> > >    the address space id where the address resides.
> > > 4. there are a set of macro's that converts/maps an address or an
> > >    address region from one space to another.
> >
> > The first thing that jumps out at me is that now every bus access has an
> > added switch in it.
> >
> > Either that or drivers would get back access function pointers, but that
> > eliminates the chance to inline trivial bus accesses.
>
> Not completely. ioremap() and friends can handle the address space ID and
> return an appropriate pointer. That pointer can still be handled by
readl() and
> friends.

Yup.  I forgot about having to run all bus addresses through ioremap.

Regards,
Brad