From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: [rfc/patch] libata -- port configurable delays
Date: Fri, 13 May 2005 22:52:59 +0100 [thread overview]
Message-ID: <1116021178.20545.3.camel@localhost.localdomain> (raw)
In-Reply-To: <20050513200312.GA6555@kvack.org>
On Gwe, 2005-05-13 at 21:03, Benjamin LaHaise wrote:
> > 3) IIRC some rare PATA devices don't like having their Status register
> > banged "too hard". No data, just a vague memory.
Not that I am aware of. There are a few ICH/PIIX variants where if you
read status during a transaction at the wrong time bad stuff occurs
including to the block on disk. That may be what you are thinking of
> >
> > 4) It may be worthwhile to rewrite the loop to check the Status register
> > _first_, then delay.
The 400nS delay after a command is required before status becomes valid.
This isn't about 'incorrect' devices in the command case. It is about
strictly correct behaviour and propogation/response times. For the cases
its not required and you wan to keep PCI load down then checking first
is clearly logical.
Also btw beware of PCI posting - writel/ndelay(400) isn't going to do
the right thing.
next prev parent reply other threads:[~2005-05-13 21:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 18:58 [rfc/patch] libata -- port configurable delays Benjamin LaHaise
2005-05-13 19:13 ` Jeff Garzik
2005-05-13 20:03 ` Benjamin LaHaise
2005-05-13 21:52 ` Alan Cox [this message]
2005-05-13 23:07 ` Jeff Garzik
2005-05-14 1:51 ` Mark Lord
2005-05-13 19:17 ` Jeff Garzik
2005-05-13 21:20 ` Alan Cox
2005-05-13 23:21 ` Jeff Garzik
2005-05-14 21:11 ` Alan Cox
2005-05-14 21:47 ` 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=1116021178.20545.3.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=bcrl@kvack.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.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.