From: Andi Kleen <andi@firstfloor.org>
To: Michael Buesch <mb@bu3sch.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
vojtech@suse.cz, muli@il.ibm.com, jdmason@kudzu.us,
tglx@linutronix.de, mingo@redhat.com, davem@davemloft.net
Subject: Re: [PATCH RFC] x86: Fix 64-bit DMA masks on VIA
Date: Thu, 24 Apr 2008 16:12:46 +0200 [thread overview]
Message-ID: <4810955E.6080903@firstfloor.org> (raw)
In-Reply-To: <200804241606.00883.mb@bu3sch.de>
Michael Buesch wrote:
> On Thursday 24 April 2008 15:43:50 Andi Kleen wrote:
>> Michael Buesch <mb@bu3sch.de> writes:
>>
>>> This untested patch is supposed to fix DMAing on some VIA boards.
>>> Currently the DMA subsystem returns an error, if the driver does
>>> tell that it supports a 64bit DMA mask. So the driver probing
>>> would fail in that case.
>> The driver is broken then. It is supposed to retry with a small
>> mask on an error. Please fix the driver.
I must admit my comment was slightly wrong. In some cases
it can make sense to start with a small mask and retry bigger.
>
> I already added a workaround to the driver.
> Why do we need to workaround this in _every_ driver?
The API was designed this way because many devices support different
hardware interfaces for different address sizes. So for example with a
32bit mask you might be able to transfer less data than with a 64bit
mask. And with the retry steps you should be able to figure out the
most efficient format for the current system.
See the discussion in Documentation/DMA-mapping.txt
cc: DaveM; I think the concept was from him originally.
-Andi
next prev parent reply other threads:[~2008-04-24 14:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-23 18:55 [PATCH RFC] x86: Fix 64-bit DMA masks on VIA Michael Buesch
2008-04-24 13:43 ` Andi Kleen
2008-04-24 14:06 ` Michael Buesch
2008-04-24 14:12 ` Andi Kleen [this message]
2008-04-24 14:18 ` David Miller
2008-04-24 14:32 ` Alan Cox
2008-04-24 15:19 ` Michael Buesch
2008-04-28 16:53 ` Ingo Molnar
2008-04-28 17:04 ` Jesse Barnes
2008-04-28 21:48 ` Michael Buesch
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=4810955E.6080903@firstfloor.org \
--to=andi@firstfloor.org \
--cc=davem@davemloft.net \
--cc=jdmason@kudzu.us \
--cc=linux-kernel@vger.kernel.org \
--cc=mb@bu3sch.de \
--cc=mingo@redhat.com \
--cc=muli@il.ibm.com \
--cc=tglx@linutronix.de \
--cc=vojtech@suse.cz \
/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.