From: Mark Lord <liml@rtr.ca>
To: Grant Grundler <grundler@google.com>
Cc: Jeff Garzik <jgarzik@pobox.com>, Tejun Heo <htejun@gmail.com>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: [PATCH 1/8] sata_mv more cosmetics
Date: Fri, 25 Apr 2008 13:31:54 -0400 [thread overview]
Message-ID: <4812158A.2010400@rtr.ca> (raw)
In-Reply-To: <da824cf30804250940o4f0e0396k1696348f8d86cb77@mail.gmail.com>
Grant Grundler wrote:
> On Fri, Apr 25, 2008 at 6:46 AM, Mark Lord <liml@rtr.ca> wrote:
> ...
>> But there are just *so many* irq cause / mask registers in these chips,
>> (one for PCI, one for the host function, and one per-port for EDMA,
>> plus the SATA SError + mask, ..), that even I was getting confused
>> while working on the code.
>
> Yeah, it's confusing because most of the bits from one "interrupt"
> (quotes explained in the next paragraph) register are rolled up into one bit
> and available in another register. It seems like someone thought it
> would be more efficient to read one register for all possible "causes"
> and then have evidence a second register read is really necessary
> (because a bit was set). Unfortunately, the result was the default
> programming model as suggested by Marvell asks for at least two
> MMIO reads just to find out if any IO completions are pending. 'Nuf said.
> Kudos to Mark for figuring out how to reduce that to one MMIO read.
..
Readers may note that the interrupt path (for a real mv interrupt)
currently reads three registers (or four if more than one hc interrupts).
Grant was refering to a plan we have formulated to reduce that to
a single read for the non-error cases. Not currently implemented
in the driver (though there are comments marking where to change it).
I'm leaving those optimizations for after the rest of the EH fixes are completed.
Hopefully within a week or less.
Cheers
next prev parent reply other threads:[~2008-04-25 17:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-19 18:42 [PATCH 0/8] sata_mv interrupt/eh fixes etc Mark Lord
2008-04-19 18:43 ` [PATCH 1/8] sata_mv more cosmetics Mark Lord
2008-04-25 5:15 ` Jeff Garzik
2008-04-25 13:46 ` Mark Lord
2008-04-25 16:40 ` Grant Grundler
2008-04-25 16:57 ` Jeff Garzik
2008-04-25 17:35 ` Mark Lord
2008-04-25 17:39 ` Grant Grundler
2008-04-25 17:31 ` Mark Lord [this message]
2008-04-19 18:44 ` [PATCH 2/8] sata_mv mask all interrupt coalescing bits Mark Lord
2008-04-19 18:45 ` [PATCH 3/8] sata_mv simplify freeze/thaw bit-shift calculations Mark Lord
2008-04-19 19:05 ` REPOST: " Mark Lord
2008-04-19 18:46 ` [PATCH 4/8] sata_mv simplify request/response queue handling Mark Lord
2008-04-19 19:06 ` REPOST: " Mark Lord
2008-04-19 18:52 ` [PATCH 5/8] sata_mv tidy host controller interrupt handling Mark Lord
2008-04-19 19:07 ` REPOST: " Mark Lord
2008-04-19 18:53 ` [PATCH 6/8] sata_mv more interrupt handling rework Mark Lord
2008-04-19 18:53 ` [PATCH 7/8] sata_mv leave SError bits untouched in mv_err_intr Mark Lord
2008-04-19 19:07 ` REPOST: " Mark Lord
2008-04-19 18:54 ` [PATCH 8/8] sata_mv re-enable hotplug, update TODO list Mark Lord
2008-04-19 19:09 ` Mark Lord
2008-04-23 13:32 ` [PATCH 0/8] sata_mv interrupt/eh fixes etc Mark Lord
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=4812158A.2010400@rtr.ca \
--to=liml@rtr.ca \
--cc=grundler@google.com \
--cc=htejun@gmail.com \
--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).