Linux MIPS Architecture development
 help / color / mirror / Atom feed
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

  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