From: "David S. Miller" <davem@redhat.com>
To: davidm@hpl.hp.com
Cc: alan@lxorguk.ukuu.org.uk, arjanv@redhat.com,
linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org,
marcelo@conectiva.com.br
Subject: Re: [Linux-ia64] patch to no longer use ia64's software mmu
Date: Tue, 04 Dec 2001 12:22:54 -0800 (PST) [thread overview]
Message-ID: <20011204.122254.110116318.davem@redhat.com> (raw)
In-Reply-To: <15372.63827.716885.948119@napali.hpl.hp.com>
In-Reply-To: <15371.62205.231945.798891@napali.hpl.hp.com> <E16BC09-0001Ql-00@the-village.bc.nu> <15372.63827.716885.948119@napali.hpl.hp.com>
From: David Mosberger <davidm@hpl.hp.com>
Date: Tue, 4 Dec 2001 08:26:59 -0800
I think the issue at hand is whether, longer term, it is desirable to
move all bounce buffer handling into the PCI DMA layer or whether
Linux should continue to make bounce buffer management visible to
drivers. I'd be interested in hearing opinions.
Well, this whole ia64 situation should be the example that shows that
for severely broken 64-bit platforms, like IA64, doing the bounce
buffering in the PCI DMA layer is a lose. The HIGHMEM option is the
optimal one in this case, and I think that is fine.
If what you are asking is should we tweak the APIs again so that
situations like current IA64 can be done more sanely in the PCI DMA
layer, I say definitely no.
There really is no excuse for the current IA64 hardware situation,
there were probably well over 3 or 4 major 64-bit platforms from
competitors, whose PCI controllers were pretty well documented
publicly, from which Intel could have derived a working 64-bit
platform PCI controller design.
When a saner IA64 hardware implementation comes about (if ever), you
can make CONFIG_IA64_WHATEVER_PLATFORM which undoes the HIGHMEM stuff
and enables PCI DMA support code for those chipsets. As Alan has
suggested. That is a perfectly fine way of dealing with this.
Franks a lot,
David S. Miller
davem@redhat.com
next prev parent reply other threads:[~2001-12-04 20:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-03 21:00 patch to no longer use ia64's software mmu Arjan van de Ven
2001-12-03 21:47 ` [Linux-ia64] " David Mosberger
2001-12-03 21:53 ` Arjan van de Ven
2001-12-04 9:36 ` Alan Cox
2001-12-04 16:26 ` David Mosberger
2001-12-04 16:32 ` Arjan van de Ven
2001-12-04 17:18 ` Alan Cox
2001-12-04 17:43 ` David Mosberger
2001-12-04 17:59 ` Alan Cox
2001-12-04 18:06 ` David Mosberger
2001-12-04 18:19 ` Alan Cox
2001-12-04 18:14 ` David Mosberger
2001-12-04 20:22 ` David S. Miller [this message]
2001-12-04 20:32 ` David Mosberger
2001-12-04 14:25 ` Andreas Schwab
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=20011204.122254.110116318.davem@redhat.com \
--to=davem@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjanv@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=linux-ia64@linuxia64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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