linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Olien <dmo@osdl.org>
To: "David S. Miller" <davem@redhat.com>
Cc: phillips@arcor.de, davidm@hpl.hp.com, davidm@napali.hpl.hp.com,
	axboe@suse.de, _deepfire@mail.ru, linux-kernel@vger.kernel.org
Subject: Re: DAC960 in 2.5.38, with new changes
Date: Tue, 24 Sep 2002 09:54:56 -0700	[thread overview]
Message-ID: <20020924095456.A17658@acpi.pdx.osdl.net> (raw)
In-Reply-To: <20020923.135447.24672280.davem@redhat.com>; from davem@redhat.com on Mon, Sep 23, 2002 at 01:54:47PM -0700


I haven't been ignoring the discussion.  Just thinking it over.
I was going to dig out an old PCI spec last night, but got involved
with other things.  I wanted to review how 64-bit PCI and 32-bit PCI busses
handle 32 and 64-bit writes from the processor.

I don't have a spec for these controllers.  IBM is selling Mylex
to LSI logic, so "All contracts, NDA's and agreements are on hold
until a transition to lsi is complete"  But, I'm guessing this
controller actually implements a 64-bit register at this location.
The 32-bit write from ia32 works probably because the controller either
clears the upper-32 bits when the lower-32 bits are written, or
those upper-32 bits are zero because we never set them to non-zero.

According to the Documentation/DMA-mapping.txt file, the new
DMA mapping interfaces should allow all PCI transfers to use 32-bit DMA
addresses. Controllers on the PCI bus should never need to use DAC
PCI transfers.  Based on this, writel() should work even on ia64.

It's possible there's something peculiar about the ia64 hardware
that lead to using writeq().  I might be able to get my hands on
an ia64 platform that I could try this on.

OR, the driver COULD always write 64 bits to this register.  ia32 doesn't
have a writeq() macro.  The only way I know to write 64 bits on ia32
is with one of the xchg instructions.  But that's mostly used if you
really want an atomic 64-bit operation.  Probably writeq() implemented as
two writel()'s would work.  It depends on the behavior of this particular
register's implementation on the controller.

I'll experiment with this later, after the other changes
I'm working on.  I'll try to identify a way to write this register
that is uniform across platforms, and won't require an #ifdef.

On Mon, Sep 23, 2002 at 01:54:47PM -0700, David S. Miller wrote:
>    From: Daniel Phillips <phillips@arcor.de>
>    Date: Mon, 23 Sep 2002 22:44:08 +0200
> 
>    On Monday 23 September 2002 21:19, David Mosberger wrote:
>    > This looks like a porting-nightmare in the making.  There's got to be a
>    > better way to determine whether you need a writeq() vs. a writel().
>    
>    Even if an #ifdef is necessary here (and we are in trouble if it is) it
>    should not trigger on __ia64__, it should trigger on the size of (long).
> 
> There is nothing preventing a 32-bit long platform from being able
> to store 64-bits at once to PCI space.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2002-09-24 16:49 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-23 19:04 Dave Olien
2002-09-23 19:19 ` David Mosberger
2002-09-23 20:40   ` David S. Miller
2002-09-23 20:53     ` David Mosberger
2002-09-23 20:57       ` David S. Miller
2002-09-23 21:24         ` David Mosberger
2002-09-23 21:17           ` David S. Miller
2002-09-23 21:32             ` David Mosberger
2002-09-23 21:28               ` David S. Miller
2002-09-23 21:31           ` Daniel Phillips
2002-09-23 21:33             ` David Mosberger
2002-09-23 21:28               ` David S. Miller
2002-09-23 21:40               ` Daniel Phillips
2002-09-23 21:45                 ` David Mosberger
2002-09-23 20:44   ` Daniel Phillips
2002-09-23 20:54     ` David S. Miller
2002-09-24 16:54       ` Dave Olien [this message]
2002-09-24 17:11         ` David Mosberger
2002-09-24 17:28           ` Dave Olien
2002-09-24 18:21             ` David Mosberger
2002-09-24 18:25               ` Dave Olien
2002-09-24 19:12                 ` David Mosberger
2002-09-24 18:45               ` Dave Olien
2002-09-24 17:50           ` Daniel Phillips
2002-09-24 18:27             ` David Mosberger
2002-09-24 17:39         ` Daniel Phillips
2002-09-25 22:20           ` DAC960, documentation links Daniel Phillips
2002-09-25 22:23             ` Daniel Phillips
2002-09-26  0:02             ` Mr. James W. Laferriere
2002-09-26 16:13           ` DAC960 in 2.5.38, with new changes Alan Cox
2002-09-24 17:45         ` Daniel Phillips
2002-09-25 21:42           ` davide.rossetti
2002-09-23 20:39 ` Daniel Phillips
2002-09-23 21:41   ` Dave Olien
2002-09-23 21:53     ` Daniel Phillips
2002-09-23 22:03       ` Dave Olien
2002-09-23 22:22         ` Daniel Phillips

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=20020924095456.A17658@acpi.pdx.osdl.net \
    --to=dmo@osdl.org \
    --cc=_deepfire@mail.ru \
    --cc=axboe@suse.de \
    --cc=davem@redhat.com \
    --cc=davidm@hpl.hp.com \
    --cc=davidm@napali.hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@arcor.de \
    --subject='Re: DAC960 in 2.5.38, with new changes' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).