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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox