From: Tejun Heo <htejun@gmail.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: jeff@garzik.org, linux-ide@vger.kernel.org
Subject: Re: Subject should be [PATCHSET libata-dev#upstream-fixes] libata: prefer hardreset, take #3
Date: Mon, 17 Mar 2008 09:17:28 +0900 [thread overview]
Message-ID: <47DDB898.6050001@gmail.com> (raw)
In-Reply-To: <18397.39466.462694.412688@harpo.it.uu.se>
Hello, Mikael.
Thanks for testing.
Mikael Pettersson wrote:
> Tejun Heo wrote (in first mail with wrong Subject):
>> It still needs Mikael's ack regarding behavior
>> change on sata_promise.
>
> Unfortunately it breaks sata_promise:
>
> ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata5.00: ATA-7: ST3120813AS, 3.AAD, max UDMA/133
> ata5.00: 234441648 sectors, multi 0: LBA48 NCQ (depth 0/32)
> ata5.00: configured for UDMA/133
> ata5: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xf t4
> ata5: hotplug_status 0x10
> ata5: hard resetting link
Eeeek, this means that ->hardreset is already broken on sata_promise
which gotta be fixed as it will lead to hardreset loops whenever
softreset fails.
> What happens is that a hard reset triggers cable sensing and
> reporting, so we get stray hotplug events which confuses things.
>
> One solution is to mask/unmask a port's hotplug events around
> calls to sata_std_hardreset(). (This also matches what Promise's
> reference driver does, except their hard reset fiddles with
> Promise specific registers.) The patch below is a draft which
> implements that solution.
That can be done in either ->freeze/->thaw or ->postreset depending on
symmetry of things. If ->freeze plugs hotplug interrupts too, it's
probably best to clear hotplug events in ->thaw before unblocking
hotplug events.
> A problem is that Promise SATA chips implement per-port hotplug
> control using port-specific bits in a single global register.
> So I have to map the link to the corresponding ata engine number:
> this mapping doesn't seem to be present anywhere, so in this
> draft patch I'm resorting to searching the host's ports[] array.
Hmmm....
> Also, since the ports share a global register it's important that
> at most one port goes through a hard reset sequence at a time.
> Can I assume that libata EH guarantees mutual exclusion?
There currently is no cross-port synchronization but you can always grab
host->lock for that.
> With this patch in place the hard reset conversion does seem to
> work Ok on a SATA300 TX4 card.
[--snip--]
> + for(i = 0; i < 4/*XXX: how to detect # ports?*/ && host->ports[i] != ap; ++i)
host->n_ports?
> + ;
> + if (i >= 4) {
> + printk(KERN_ERR "%s: unable to map ap to ata_no\n", __FUNCTION__);
> + return sata_std_hardreset(link, class, deadline);
> + }
> + ata_no = pdc_port_no_to_ata_no(i, is_sataii_tx4);
> +
> + hotplug_status = readl(mmio_base + hotplug_offset);
> +
> + /* clear hotplug flags, mask hotplug ints */
> + hotplug_status |= (0x11 << ata_no);
> + hotplug_status |= (0x11 << ata_no) << 16;
> + writel(hotplug_status, mmio_base + hotplug_offset);
> + readl(mmio_base + hotplug_offset); /* flush */
I think this belongs to ->freeze().
> + ret = sata_std_hardreset(link, class, deadline);
> +
> + /* clear hotplug flags, unmask hotplug ints */
> + hotplug_status &= ~((0x11 << ata_no) << 16);
> + writel(hotplug_status, mmio_base + hotplug_offset);
> + readl(mmio_base + hotplug_offset); /* flush */
And this to ->thaw().
Thanks.
--
tejun
next prev parent reply other threads:[~2008-03-17 0:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-11 4:27 [PATCHSET #upstream-fixes] block/libata: update and use block layer padding and draining, take 3 Tejun Heo
2008-03-11 4:27 ` [PATCH 1/5] libata: prefer hardreset Tejun Heo
2008-03-11 4:27 ` [PATCH 2/5] libata: kill ATA_LFLAG_HRST_TO_RESUME Tejun Heo
2008-03-11 4:27 ` [PATCH 3/5] libata: kill ATA_EHI_RESUME_LINK Tejun Heo
2008-03-11 4:27 ` [PATCH 4/5] libata: kill ATA_LFLAG_SKIP_D2H_BSY Tejun Heo
2008-03-11 4:27 ` [PATCH 5/5] libata: kill ata_ehi_schedule_probe() Tejun Heo
2008-03-11 4:29 ` Subject should be [PATCHSET libata-dev#upstream-fixes] libata: prefer hardreset, take #3 Tejun Heo
2008-03-16 22:07 ` Mikael Pettersson
2008-03-17 0:17 ` Tejun Heo [this message]
2008-03-17 8:19 ` Mikael Pettersson
2008-03-17 9:36 ` Tejun Heo
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=47DDB898.6050001@gmail.com \
--to=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=mikpe@it.uu.se \
/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).