From: Jun Sun <jsun@mvista.com>
To: jim@jtan.com
Cc: Ralf Baechle <ralf@oss.sgi.com>, linux-mips@oss.sgi.com
Subject: Re: [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA]
Date: Tue, 18 Dec 2001 11:21:43 -0800 [thread overview]
Message-ID: <3C1F9747.60DFB70@mvista.com> (raw)
In-Reply-To: 20011218135712.B11726@neurosis.mit.edu
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
next prev parent reply other threads:[~2001-12-18 20:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-17 20:15 [ppopov@mvista.com: Re: [Linux-mips-kernel]ioremap & ISA] Jim Paris
2001-12-17 21:34 ` Ralf Baechle
2001-12-18 5:45 ` Jim Paris
2001-12-18 7:03 ` Jim Paris
2001-12-18 4:03 ` hanishkvc
2001-12-18 18:10 ` Jun Sun
2001-12-18 18:45 ` Jim Paris
2001-12-18 18:45 ` Jim Paris
2001-12-18 19:09 ` Jun Sun
2001-12-18 19:30 ` Ralf Baechle
2001-12-19 9:40 ` Geert Uytterhoeven
2001-12-18 18:25 ` Ralf Baechle
2001-12-18 18:57 ` Jim Paris
2001-12-18 19:21 ` Jun Sun [this message]
2001-12-18 20:58 ` Ralf Baechle
2001-12-18 21:28 ` Jim Paris
2001-12-18 21:53 ` Maciej W. Rozycki
2001-12-19 9:34 ` Geert Uytterhoeven
2001-12-22 12:47 ` Ralf Baechle
2001-12-18 19:16 ` Jun Sun
2001-12-18 19:31 ` Ralf Baechle
2001-12-18 19:36 ` Jun Sun
2001-12-18 20:02 ` Karsten Merker
2001-12-18 20:22 ` Maciej W. Rozycki
2001-12-18 22:28 ` Ralf Baechle
2001-12-19 9:34 ` Geert Uytterhoeven
2001-12-19 16:47 ` Ralf Baechle
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=3C1F9747.60DFB70@mvista.com \
--to=jsun@mvista.com \
--cc=jim@jtan.com \
--cc=linux-mips@oss.sgi.com \
--cc=ralf@oss.sgi.com \
/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.