From: Tejun Heo <htejun@gmail.com>
To: jgarzik@pobox.com, alan@lxorguk.ukuu.org.uk,
linux-ide@vger.kernel.org, htejun@gmail.com
Subject: [PATCHSET] prep for PMP support, take 3
Date: Mon, 16 Oct 2006 08:17:47 +0900 [thread overview]
Message-ID: <11609542672061-git-send-email-htejun@gmail.com> (raw)
In-Reply-To:
Hello, all.
This is the third take of libata-pmp-prep patchset. This patchset
contains 5 patches and implements various stuff needed for PMP.
Changes from the last take[L] are.
* rebased
* sata_link_hardreset() separation is done earlier by vt8251-ahci
patchset and thus dropped from this patchset.
This patchset is against
upstream (da54f5fe54c7d75e2db7d17961fb36a8c28a8501)
+ [1] hp-poll patchset, take #5
+ [2] vt8251-ahci patchset, take #2
+ [3] libata-link patchset, take #3
Git tree can be accessed at
http://htj.dyndns.org/git/?p=libata-tj.git;a=shortlog;h=pmp-prep
git://htj.dyndns.org/libata-tj pmp-prep
Jeff, I couldn't merge ->qc_defer() into ->qc_prep() or ->qc_issue().
The problem is that ->qc_prep() is done after sg mapping is done which
is a bit costly to throw away if the qc has to be deferred.
->qc_defer() is called right after qc is allocated and translated but
before any resource for qc execution is acuquired.
Another way would be to let ->qc_issue() determine whether deferring
is needed and cache prepared qc while deferred. This has the
following problems.
* qc and related resources are held by deferred command. Currently,
qc directly maps to hardware command slots and w/ PMP this can get
messy.
* Separate requeueing/restarting mechanism must be implemented. ATM,
libata depends on SCSI for retrying deferred commands with
reasonable fairness. To hold prepared qc, libata needs to implement
its own mechanism and I don't think the added benefits justify the
complexity.
So, I think it's better to keep ->qc_defer().
Thanks.
--
tejun
[L] http://article.gmane.org/gmane.linux.ide/11928
[1] http://article.gmane.org/gmane.linux.ide/13467
[2] http://article.gmane.org/gmane.linux.ide/13471
[3] http://article.gmane.org/gmane.linux.ide/13478
next reply other threads:[~2006-10-15 23:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-15 23:17 Tejun Heo [this message]
2006-10-15 23:17 ` [PATCH 5/5] [PATCH] libata-pmp-prep: implement qc_defer helpers Tejun Heo
2006-10-15 23:17 ` [PATCH 4/5] [PATCH] libata-pmp-prep: implement ops->qc_defer() Tejun Heo
2006-10-15 23:17 ` [PATCH 2/5] [PATCH] libata-pmp-prep: make a number of functions global to libata Tejun Heo
2006-10-15 23:17 ` [PATCH 1/5] [PATCH] libata-pmp-prep: add @new_class to ata_dev_revalidate() Tejun Heo
2006-10-15 23:17 ` [PATCH 3/5] [PATCH] libata-pmp-prep: add @is_cmd to ata_tf_to_fis() Tejun Heo
2006-10-15 23:41 ` [PATCHSET] prep for PMP support, take 3 Tejun Heo
2006-11-01 2:22 ` Jeff Garzik
2006-11-01 4:25 ` 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=11609542672061-git-send-email-htejun@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=linux-ide@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 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).