All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: jim@jtan.com
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, linux-mips@oss.sgi.com
Subject: Re: ISA
Date: Tue, 18 Dec 2001 17:17:45 -0800	[thread overview]
Message-ID: <3C1FEAB9.F590DFFE@mvista.com> (raw)
In-Reply-To: 20011218172456.A12735@neurosis.mit.edu

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

  reply	other threads:[~2001-12-19  2:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-18 20:04 ISA Jim Paris
2001-12-18 20:27 ` ISA Bradley D. LaRonde
2001-12-18 20:27   ` ISA Bradley D. LaRonde
2001-12-18 21:44   ` ISA Jim Paris
2001-12-18 22:01     ` ISA Maciej W. Rozycki
2001-12-18 22:24       ` ISA Jim Paris
2001-12-19  1:17         ` Jun Sun [this message]
2001-12-19  1:50           ` ISA Maciej W. Rozycki
2001-12-19  2:05             ` ISA Bradley D. LaRonde
2001-12-19  2:05               ` ISA Bradley D. LaRonde
2001-12-19  2:09             ` ISA Jun Sun
2001-12-19  2:30               ` ISA Maciej W. Rozycki
2001-12-19  9:52                 ` ISA Geert Uytterhoeven
2001-12-19 13:59                   ` ISA Alan Cox
2001-12-19 13:59                     ` ISA Alan Cox
2001-12-19 14:06                     ` ISA Geert Uytterhoeven
2001-12-20 13:09                       ` ISA Maciej W. Rozycki
2001-12-20 13:14                         ` ISA Geert Uytterhoeven
2001-12-20 13:39                           ` ISA Maciej W. Rozycki
2001-12-20 13:45                             ` ISA Geert Uytterhoeven
2001-12-20 14:06                               ` ISA Maciej W. Rozycki
2001-12-21 16:12                       ` ISA Alan Cox
2001-12-21 16:12                         ` ISA Alan Cox
2001-12-21 18:44                         ` ISA Jim Paris
2002-01-01 19:22                           ` ISA Jun Sun
2002-01-01 19:34                             ` ISA Bradley D. LaRonde
2002-01-02  1:03                               ` ISA M. Warner Losh
2002-01-02  9:41                               ` ISA Geert Uytterhoeven
2002-01-02 14:36                                 ` ISA Bradley D. LaRonde
2002-01-01 20:13                             ` ISA Alan Cox
2002-01-01 20:13                               ` ISA Alan Cox
2001-12-19  1:28         ` ISA Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C1FEAB9.F590DFFE@mvista.com \
    --to=jsun@mvista.com \
    --cc=jim@jtan.com \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.