From: Daniel Phillips <phillips@arcor.de>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: DAC960 Bitrot
Date: Tue, 23 Jul 2002 00:02:40 +0200 [thread overview]
Message-ID: <E17WlGV-00052g-00@starship> (raw)
In-Reply-To: <20020711100828.GE808@suse.de>
On Thursday 11 July 2002 12:08, Jens Axboe wrote:
> On Thu, Jul 11 2002, Daniel Phillips wrote:
> > On Thursday 11 July 2002 08:47, Jens Axboe wrote:
> > > Leonard has promised me to convert DAC960 to the "new" pci dma api for
> > > years (or so it seems, actual date may vary, no purchase necessary). I
> > > do have a Mylex controller here myself these days, so it's not
> > > completely impossible that I may do it on a rainy day.
> >
> > Well, tell me what the new api is and I'll dive in there. For the record,
>
> Documentation/DMA-mapping.txt. Also, DAC960 initial bio conversion
> happened before the interface was finalized, so it may need changes in
> that regard as well. Documentation/block/biodoc.txt is your friend there
> :-)
>
> a quick make drivers/block/DAC960.o shows the following stuff needs
> changing immediately:
>
> 1) q->queue_lock is a pointer to a lock, not the lock itself. Probably
> add a per-controller spinlock to DAC960_Controller_T, and pass that to
> blk_init_queue(). Then change DAC960_AcquireControllerLock and friends
> in DAC960.h accordingly.
The big change here appears to be the move to per-device request queues.
Somebody apparently already started to update this driver (you?) but
obviously didn't try to compile it. This is new territory for me, so I'll be
moving gingerly in here for a while.
For those locks, I just removed the &'s, which seems like the right thing to
do. The "Controller" lock really seems to be a request queue lock. Now I
think I need to allocate and initialize a request queue, possibly in
DAC960_CreateAuxiliaryStructures. Am I getting warm?
--
Daniel
next prev parent reply other threads:[~2002-07-22 22:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-06 5:31 [PATCH][RFT](2) minimal rmap for 2.5 - akpm tested Rik van Riel
2002-07-06 6:28 ` Andrew Morton
2002-07-06 19:06 ` Linus Torvalds
2002-07-06 20:00 ` Andrew Morton
2002-07-06 20:11 ` Linus Torvalds
2002-07-10 17:35 ` Sebastian Droege
2002-07-10 20:42 ` Rik van Riel
2002-07-10 21:56 ` Daniel Phillips
2002-07-11 6:47 ` Jens Axboe
2002-07-11 9:58 ` Daniel Phillips
2002-07-11 10:08 ` Jens Axboe
2002-07-22 22:02 ` Daniel Phillips [this message]
2002-07-24 14:39 ` DAC960 Bitrot Jens Axboe
2002-07-24 14:48 ` Jens Axboe
2002-07-24 16:19 ` Wakko Warner
2002-07-24 16:57 ` Daniel Phillips
2002-07-24 17:02 ` Jens Axboe
2002-07-24 17:30 ` Alexander Viro
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=E17WlGV-00052g-00@starship \
--to=phillips@arcor.de \
--cc=axboe@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®