Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@debian.org>
To: "Michael S . Zick" <mszick@pflash.com>
Cc: Matthew Wilcox <willy@debian.org>, parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] EISA support
Date: Wed, 10 Oct 2001 15:48:10 +0100	[thread overview]
Message-ID: <20011010154810.D24923@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <01101003320900.00964@Wolf-01>; from mszick@pflash.com on Wed, Oct 10, 2001 at 03:32:09AM -0500

On Wed, Oct 10, 2001 at 03:32:09AM -0500, Michael S . Zick wrote:
> Old ISA boards only do a 10-bit decode and it is a frequent occurance
> that old drivers don't "clean up" the unused high 6 bits.
> 
> Would it be reasonable to mask port numbers to 10 bits for ISA in the
> inb/outb routines?

Actually, I currently do this, but I'm not sure I should be.  The EISA
adapter has to do different things for ISA port IO and EISA port IO.
I'm not sure which IO ports correspond the ISA and which to EISA.
Guessing based on the hp100 driver, I decided that ports less than 0x400
were ISA and the rest were EISA.  Anyone want to explain port numbers
to me properly?  The description in the Mongoose ERS assumes you know
a fair bit about EISA, and I don't.

Here's the current code for this:

+static inline unsigned long eisa_permute(u16 port)
+{
+       if (port >= 0x400) {
+               return 0xfc000000 | port;
+       } else {
+               return 0xfc000000 | ((port & 0x3f8) << 9) | (port & 7);
+       }
+}

The ERS adds in (port & 0xfc00) >> 6, but the test ensures those bits
are clear, so there's no point.

-- 
Revolutions do not require corporate support.

  parent reply	other threads:[~2001-10-10 14:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-10  6:24 [parisc-linux] EISA support Matthew Wilcox
2001-10-10  8:32 ` Michael S.Zick
2001-10-10 11:01   ` Alan Modra
2001-10-10 14:11     ` Michael S.Zick
2001-10-10 14:48   ` Matthew Wilcox [this message]
2001-10-10 15:38     ` Matthew Wilcox
2001-10-10 16:57       ` Michael S.Zick
2001-10-10 12:45 ` Richard Hirst
2001-10-10 14:28   ` Matthew Wilcox
2001-10-10 17:36     ` Grant Grundler
2001-10-11  1:40     ` Matthew Wilcox
2001-10-11  3:56       ` Grant Grundler
2001-10-11 11:23       ` Richard Hirst
2001-10-11 20:22         ` Matthew Wilcox
2001-10-11  8:15     ` Richard Hirst
2001-10-12  6:44 ` Matthew Wilcox
2001-10-12  8:47   ` Richard Hirst
2001-10-12  9:01     ` Richard Hirst
2001-10-16 19:17 ` Tom
2001-10-16 19:46   ` Jochen Friedrich
2001-10-16 20:00     ` Matthew Wilcox
2001-10-16 22:26       ` Jochen Friedrich
2001-10-16 22:32         ` Matthew Wilcox
2001-10-18 14:31 ` Tom
2001-10-18 15:08   ` Matthew Wilcox
  -- strict thread matches above, loose matches on Subject: below --
2001-10-10 11:37 Pedot, Wolfgang

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=20011010154810.D24923@parcelfarce.linux.theplanet.co.uk \
    --to=willy@debian.org \
    --cc=mszick@pflash.com \
    --cc=parisc-linux@parisc-linux.org \
    /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