From: Sergei Shtylyov <sshtylyov@mvista.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Tejun Heo <tj@kernel.org>,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
Jeff Garzik <jeff@garzik.org>,
"\"linux-ide@vger.kernel.org\" st" <linux-ide@vger.kernel.org>,
stable <stable@kernel.org>, Milan Kocian <milan.kocian@wq.cz>
Subject: Re: [PATCH #upstream-fixes] pata_cmd64x: revert commit d62f5576
Date: Tue, 17 Aug 2010 21:41:24 +0400 [thread overview]
Message-ID: <4C6AC9C4.3070307@ru.mvista.com> (raw)
In-Reply-To: <20100817163917.58ea1d06@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>> Does it really need to merge the DMA timings too? If the device can't
>> do certain timing, it's PIO configuration should reflect that so
>> merging PIO part only should be enough for PIO configuration, no?
> The timing code knows about DMA/PIO constraints itself. The whole mucking
> around passing both timings is just bogus.
> Pass pair->dma_mode only and it'll work out the PIO for you. Not that it
> matters - no real hardware has a DMA mode with a slower address setup
> than its PIO mode.
The address setup timing means *exactly nothing* for DMA modes. I keep
wondering why it has been added to the libata timing table...
MBR, Sergei
next prev parent reply other threads:[~2010-08-17 17:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-17 12:13 [PATCH #upstream-fixes] pata_cmd64x: revert commit d62f5576 Tejun Heo
2010-08-17 12:56 ` Bartlomiej Zolnierkiewicz
2010-08-17 15:01 ` Tejun Heo
2010-08-17 15:39 ` Alan Cox
2010-08-17 16:39 ` Bartlomiej Zolnierkiewicz
2010-08-17 17:41 ` Sergei Shtylyov [this message]
2010-08-17 21:30 ` Jeff Garzik
2010-08-19 10:30 ` Milan Kocian
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=4C6AC9C4.3070307@ru.mvista.com \
--to=sshtylyov@mvista.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bzolnier@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=milan.kocian@wq.cz \
--cc=stable@kernel.org \
--cc=tj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox