From: Tejun Heo <tj@kernel.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: benh@kernel.crashing.org, Pavel Machek <pavel@suse.cz>,
Andreas Schwab <schwab@suse.de>,
kernel list <linux-kernel@vger.kernel.org>,
jgarzik@pobox.com,
IDE/ATA development list <linux-ide@vger.kernel.org>,
Trivial patch monkey <trivial@kernel.org>
Subject: Re: sata_svw data corruption, strange problems
Date: Mon, 23 Jun 2008 22:05:40 +0900 [thread overview]
Message-ID: <485F9FA4.3050608@kernel.org> (raw)
In-Reply-To: <20080623104221.3b4fb350@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>>> BTW. Tejun, I suppose that usually starting DMA after issuing the
>>> command is a standard practice of legacy/sff type controllers ? Or it's
>>> just because that's how linux did it until now ?
>> It's how the standard says it should be programmed. Please take a look
>> at section 3 of the following document.
>>
>> http://www.centrillium-it.com/Projects/idems100.pdf
>>
>> It's a non-issue for PATA ones as the host is responsible for running
>
> It's very much an issue for PATA. If you start the DMA before time things
> go wrong. The DMA has to start after the command is issued (or for ATAPI
> after the command and the cdb are issued). Various ATAPI devices get
> quite cross if you mess this up.
>
> In some cases the driver code also depends upon this as we software drive
> the data clocks so have to reprogram them after command issue and before
> data transfer begins.
I was saying drive getting ready before command issue was non issue.
--
tejun
next prev parent reply other threads:[~2008-06-23 13:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 9:36 sata_svw data corruption, strange problems Pavel Machek
2008-06-23 0:37 ` Tejun Heo
2008-06-23 8:20 ` Pavel Machek
2008-06-23 8:22 ` Tejun Heo
2008-06-23 8:39 ` Andreas Schwab
2008-06-23 8:53 ` Pavel Machek
2008-06-23 8:56 ` Tejun Heo
2008-06-23 9:01 ` Pavel Machek
2008-06-23 9:04 ` Benjamin Herrenschmidt
2008-06-23 9:26 ` Pavel Machek
2008-06-23 9:48 ` Tejun Heo
2008-06-23 9:42 ` Alan Cox
2008-06-23 10:23 ` Benjamin Herrenschmidt
2008-06-23 13:05 ` Tejun Heo [this message]
2008-06-27 6:41 ` Jeff Garzik
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=485F9FA4.3050608@kernel.org \
--to=tj@kernel.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=benh@kernel.crashing.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=schwab@suse.de \
--cc=trivial@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.