All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: Tejun Heo <tj@kernel.org>, Peter Favrholdt <linux-ide@how.dk>,
	linux-ide@vger.kernel.org
Subject: Re: [PATCH #upstream-fixes] sata_promise: request follow-up SRST
Date: Mon, 09 Feb 2009 23:30:29 -0500	[thread overview]
Message-ID: <499102E5.6000603@garzik.org> (raw)
In-Reply-To: <18737.47407.218634.726384@harpo.it.uu.se>

Mikael Pettersson wrote:
> Jeff Garzik writes:
>  > hrm....   at this point we have deviated massively from the standard 
>  > Promise method of hard reset...
>  > 
>  > * set PMP port
>  > * make hotplug irqs
>  > * reset port# in PDC_GLOBAL_CTL
>  > * pdc_reset_port()
>  > * reset FPDMA -- probably a good idea even if not doing FPDMA
>  > * clear SATA Error register (0xffffffff)
>  > * clear errors-reported-from-link-layer register
>  > * wait standard length of time for SATA connection
>  > * clear hotplug bits
>  > * set PMP port
>  > 
>  > The PDC_GLOBAL_CTL bitbang is the most notable missing element in the 
> 
> I assume you meant the PCI control register (offset 0x48).
> 
>  > hard reset path, though we also miss clearing an apparently-important 
>  > error register as well.  FPDMA reset would be a good idea I think, even 
>  > if not in use, mainly for paranoia's sake and because that's what 
>  > Promise's driver does.
> 
> Here's a patch on top of 2.6.28-rc6 that should make sata_promise's
> reset sequences a closer match to what Promise's drivers do.
> 
> - soft reset (pdc_reset_port):
>   * wait for ATA engine to not be in packet command mode (2nd gen only)
>   * write reset bit in PDC_CTLSTAT before the first read in the loop
>   * for 2nd gen SATA follow up with FPDMA reset and clearing error status registers
> - hard reset (pdc_sata_hardreset):
>   * wait for ATA engine to not be in packet command mode (2nd gen only)
>   * reset ATA engine via the PCI control register
>   * Tejun's change to use non-waiting hardreset + follow-up SRST
> 
> I'm not changing the hotplug mask bits since they are taken care
> of by sata_promise's ->freeze() and ->thaw() operations. And I'm
> not writing the PMP port # because that's always zero (for now).
> 
> Tested here on a SATAII150 TX2plus w/ two sata disks, some hdparm -y
> + smartctl tests which used to cause timeouts on one of those disks,
> and some parallel dd:s to stress things a little. No issues found.
> I'll test it on a 1st gen 20378 next week.
> 
> Testers welcome.

Any updates?



  parent reply	other threads:[~2009-02-10  4:30 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-13 21:21 FYI: BUG in SATA Promise 300 TX4 (2.6.24 - 2.6.27-3) w/Linux Linda Walsh
2008-11-13 21:21 ` Linda Walsh
2008-11-16  6:04 ` Tejun Heo
2008-11-16  6:04   ` Tejun Heo
2008-11-16 11:08   ` Mikael Pettersson
2008-11-16 11:08     ` Mikael Pettersson
2008-11-16 14:24     ` Tejun Heo
2008-11-16 14:24       ` Tejun Heo
2008-11-16 16:48     ` Brad Campbell
2008-11-16 16:48       ` Brad Campbell
2008-11-17  2:01       ` Tejun Heo
2008-11-17  2:01         ` Tejun Heo
2008-11-16 17:34     ` Peter Favrholdt
2008-11-16 17:39       ` Peter Favrholdt
2008-11-17  2:01         ` Tejun Heo
2008-11-17 11:47           ` Peter Favrholdt
2008-11-18  1:11             ` Tejun Heo
2008-11-18 18:03               ` Peter Favrholdt
2008-11-19  1:55                 ` Tejun Heo
2008-11-20 10:22                   ` Peter Favrholdt
2008-11-20 11:10                     ` Mikael Pettersson
2008-11-21  4:42                       ` Tejun Heo
2008-11-21  4:56                       ` [PATCH #upstream-fixes] sata_promise: request follow-up SRST Tejun Heo
2008-11-22 16:30                         ` Mikael Pettersson
2008-11-23 22:38                         ` Peter Favrholdt
2008-11-25 13:00                         ` Peter Favrholdt
2008-11-26  2:46                           ` Tejun Heo
2008-11-26  8:12                             ` Peter Favrholdt
2008-11-26 23:07                               ` Peter Favrholdt
2008-11-25 17:27                         ` Jeff Garzik
2008-11-25 21:17                           ` Mikael Pettersson
2008-11-29 21:50                           ` Mikael Pettersson
2008-11-30 15:06                             ` Peter Favrholdt
2009-02-10  4:30                             ` Jeff Garzik [this message]
2009-02-10 17:28                               ` Mikael Pettersson
2009-02-10 21:13                                 ` Jeff Garzik
2009-02-23 12:17                                   ` [PATCH #upstream-fixes] sata_promise: request follow-up SRST - it works Peter Favrholdt
2009-09-25  5:24 [PATCH #upstream-fixes] sata_promise: request follow-up SRST Walter Hutchins
2009-09-26  2:57 ` Robert Hancock
2009-09-26 18:42   ` Walter Hutchins

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=499102E5.6000603@garzik.org \
    --to=jeff@garzik.org \
    --cc=linux-ide@how.dk \
    --cc=linux-ide@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    --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 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.