Subject: Re: IPL_LOCK oddity
To: Thor Lancelot Simon <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 08/24/2006 16:40:53
Content-Type: text/plain; charset=us-ascii
On Thu, Aug 24, 2006 at 02:04:23PM -0400, Thor Lancelot Simon wrote:
> On Thu, Aug 24, 2006 at 10:55:42AM -0700, Bill Studenmund wrote:
> > On Thu, Aug 24, 2006 at 09:38:11AM +0200, Manuel Bouyer wrote:
> > That would probably be the best solution. I'd rather not have spllock()=
> > block serial interrupts.
> > The one problem is that the lock that the com driver takes for interrup=
> > is also the one it takes for normal uses. The latter uses may want to s=
> > with normal spin locks. If so, that'd be an arguement against changing=
> > serial drivers to use __cpu_simple_lock.
> I think it makes more sense to think of the code that shuffles bytes out
> of the hardware FIFO and into the driver proper as, well... a separate
> entity, like the old "pseudo-DMA" routines in VAX drivers. I don't see
> why _these_ routines using __cpu_simple_lock should imply that serial
> drivers in general (or other code in the same serial driver) should do
The only reasons I can see are:
1) The code only uses one lock, so this lock has to be safe for >=20
IPL_LOCK, which has some tradeoffs (i.e. we lose everything we gain by=20
having locks that work at IPL_LOCK).
The simple fix is to have two different locks, but that leads to...
2) Some of the times when we grab the lock on the softc, we want to lock
access to the softc. i.e. we want to do things like process characters
from the silo, check for modem status, etc. It's ok for the pseudo-DMA
routines to run durring this. Other times, though, we want to touch the
hardware. For the latter times, we want to touch the chip, and for that we=
need to block the pseudo-DMA routines.
This too isn't hard to work out, we just have to audit to make sure we do=
it right. Having one spinlock for most of the softc, which say runs at=20
either splsofttty or spltty, and another spinlock that runs at splserial=20
is probably the best way to go.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----