From: Jens Axboe <axboe@suse.de>
To: "Gérard Roudier" <groudier@free.fr>
Cc: Jeff Garzik <jgarzik@mandrakesoft.com>,
Linux <linux-kernel@vger.kernel.org>,
linux-scsi@vger.kernel.org
Subject: Re: SYM-2 patches against latest kernels available
Date: Sun, 4 Nov 2001 19:51:45 +0100 [thread overview]
Message-ID: <20011104195145.J10022@suse.de> (raw)
In-Reply-To: <3BE564A4.D88D1951@mandrakesoft.com> <20011104160540.X1663-100000@gerard>
In-Reply-To: <20011104160540.X1663-100000@gerard>
On Sun, Nov 04 2001, G?rard Roudier wrote:
>
>
> On Sun, 4 Nov 2001, Jeff Garzik wrote:
>
> > Gérard Roudier wrote:
> > > The patch against linux-2.4.13 has been sent to Alan Cox for inclusion in
> > > newer stable kernels. Alan wants to test it on his machines which is a
> > > good thing. Anyway, those patches just add the new driver version to
> > > kernel tree and leave stock sym53c8xx and ncr53c8xx in place.
> >
> > Are the older sym/ncr drivers going away in 2.5?
> >
> >
> > > Any report, especially on large memory machines using 64 bit DMA (2.4
> > > kernels + PCI DAC capable controllers only), is welcome. I can't test 64
> > > bit DMA, since my fatest machine has only 512 MB of memory.
> > >
> > > To configure the driver, you must select "SYM53C8XX version 2 driver" from
> > > kernel config. For large memory machines, a new "DMA addressing mode"
> > > option is to be configured as follows (help texts have been added to
> > > Configure.help):
> > >
> > > Value 0: 32 bit DMA addressing
> > > Value 1: 40 bit DMA addressing (upper 24 bytes set to zero)
> > > Value 2: 64 bit DMA addressing limited to 16 segments of 4 GB (64 GB) max.
> >
> > Are you using the new pci64 API under 2.4.x?
>
> Didn't see any. Only the dma_addr_t thing can be 32 bit or 64 bit
> depending on some magic. Apart this, the driver is asking for the
> appropriate dma mask given the configured dma adressing mode.
I've looked over the sym-2 and it is using pci_map_sg so it's 64-bit
safe for sg transfers at least. For non-sg requests you are using
pci_map_single, but you can't do any better because the mid layer is
handing you virtual addresses in request_buffer currently anyways...
> PS: There is some pci64* API on some arch., but nobody will want to
> ever use it, in my opinion.
You are doing it right :-)
--
Jens Axboe
next prev parent reply other threads:[~2001-11-04 18:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-04 13:04 SYM-2 patches against latest kernels available Gérard Roudier
2001-11-04 15:54 ` Jeff Garzik
2001-11-04 15:12 ` Gérard Roudier
2001-11-04 18:51 ` Jens Axboe [this message]
2001-11-04 16:56 ` Gérard Roudier
2001-11-05 7:21 ` Jens Axboe
2001-11-05 18:48 ` Gérard Roudier
2001-11-04 15:49 ` Gérard Roudier
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=20011104195145.J10022@suse.de \
--to=axboe@suse.de \
--cc=groudier@free.fr \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.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 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.