[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48462.85.118.17.158.1197902160.squirrel@newgolddream.dyndns.info>
Date: Mon, 17 Dec 2007 14:36:00 -0000 (UTC)
From: "Adrian McMenamin" <adrian@...golddream.dyndns.info>
To: "Jens Axboe" <jens.axboe@...cle.com>
Cc: "Adrian McMenamin" <lkmladrian@...il.com>,
"Paul Mundt" <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org,
linux-ide@...r.kernel.org, linux-sh@...r.kernel.org
Subject: Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast
On Mon, December 17, 2007 2:06 pm, Jens Axboe wrote:
> On Sun, Dec 16 2007, Adrian McMenamin wrote:
>
> Few notes:
Thanks for these, very helpful.
>
> - Compare rq_data_dir() with WRITE, don't just assume that any non-zero
> will be a write.
>
> - You need to offload this request handling to a workqueue of some sort,
> your current request handling is very broken for two reasons: One is
> that interrupts are still disabled when you drop your queue lock, so
> you cannot use sleeping functions like GFP_KERNEL allocations or
> wait_event(). The other is that it's illegal to sleep from your
> request_fn context in the first place, since you could be stalling
> others.
Ah. OK. Funnily enough an earlier version did offload to a workqueue but i
thought that was too convoluted. I didn't realise interrupts were disabled
inside the request_fn context.
>
> - You also seem to be busy waiting for other transactions to finish. Any
> idea how long those might take? Perhaps put an upper bound on this
> waiting, and/or do blocking waits?
>
Well, when the register bit clears they are over, seems to be about 200 -
400 microseconds or there abouts (ie that length of time between the
interrupt signalling that the transfer is over and the bit clearing to
allow a new transfer) - so I could time that out at say HZ/2 and be very
safe.
> - I'm assuming this hardware can't do sg transfers?
>
Afraid not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists