From: Mark Lord <liml@rtr.ca>
To: Robert Hancock <hancockr@shaw.ca>
Cc: ltuikov@yahoo.com, linux-arch@vger.kernel.org,
ide <linux-ide@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-scsi@vger.kernel.org
Subject: Re: DMA mapping on SCSI device?
Date: Wed, 30 Jan 2008 11:56:19 -0500 [thread overview]
Message-ID: <47A0AC33.1060504@rtr.ca> (raw)
In-Reply-To: <479FDA52.8050204@shaw.ca>
Robert Hancock wrote:
> Luben Tuikov wrote:
>> --- On Mon, 1/28/08, Robert Hancock <hancockr@shaw.ca> wrote:
>>> The trick is that if an ATAPI device is connected, we (as
>>> far as I'm aware) can't use ADMA mode, so we have to switch that
>>> port into legacy mode.
>>
>> Can you double check this with the HW architect of the
>> HW DMA engine of the ASIC?
>
> Will do so. However, previous statements from NVIDIA fairly clearly
> indicate that this is the case.
>
>>
>>> This means it's only capable of 32-bit DMA.
>>> However the other port on the controller may be connected to a hard
>>> drive and therefore still capable of 64-bit DMA.
>>
>> If this is indeed the case as you've presented it here,
>> it sounds like a HW shortcoming. I cannot see how the device
>> type (or protocol) dictate how the DMA engine operates.
>> They live in two different domains.
>
> Well, there is an indirect link. The ADMA interface (which supports
> 64-bit DMA) cannot be used to issue ATAPI commands, so if an ATAPI
> device is connected we have to go to legacy mode, which supports only
> 32-bit DMA.
>
> I'm not sure why ADMA mode doesn't support ATAPI. The only reason I can
> think of is that there's issues since ATAPI commands can potentially be
> of unpredictable transfer size. The "real" ADMA spec that the NVIDIA
> implementation is loosely based on does have some special "ignore
> excess" controls that don't seem to be in the NVIDIA version (or at
> least not to the knowledge I have on this hardware).
..
The original Pacific Digital ADMA cores *do* support most ATAPI commands
in ADMA mode, including READ_CD, READ_10, etc.. With the caveat that if
DSC completion state is required, the driver has to drop out of ADMA
and poll for it after the ADMA command completes.
Commands which were not ADMA compatible (eg. MODE_SENSE, TEST_UNIT_READY, ..)
were simply handled with PIO (in the driver) rather than any form of DMA,
which is okay because those commands are relatively infrequent.
Note that Pacific Digital "officially" said "no ATAPI" for the ADMA design,
but I implemented it regardless (for Linux) and it worked rather well.
We could burn DVDs and back-up to tape simultaneously, with the burner
and the tape unit sharing a single IDE cable/channel.
Cheers
next prev parent reply other threads:[~2008-01-30 16:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 0:08 DMA mapping on SCSI device? Robert Hancock
2008-01-29 3:21 ` Grant Grundler
2008-01-29 3:37 ` Matthew Wilcox
2008-01-29 4:28 ` Andi Kleen
2008-01-29 15:33 ` James Bottomley
2008-01-29 22:23 ` Luben Tuikov
2008-01-29 22:09 ` Luben Tuikov
2008-01-30 2:00 ` Robert Hancock
2008-01-30 16:56 ` Mark Lord [this message]
2008-01-30 17:00 ` Mark Lord
2008-01-31 0:09 ` Robert Hancock
2008-01-31 5:01 ` Matthew Wilcox
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=47A0AC33.1060504@rtr.ca \
--to=liml@rtr.ca \
--cc=hancockr@shaw.ca \
--cc=linux-arch@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ltuikov@yahoo.com \
/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;
as well as URLs for NNTP newsgroup(s).