[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48FF0FB7.5070706@tremplin-utc.net>
Date: Wed, 22 Oct 2008 13:34:15 +0200
From: Eric Piel <eric.piel@...mplin-utc.net>
To: Pavel Machek <pavel@...e.cz>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, burman.yan@...il.com, pau@...ack.org
Subject: Re: [PATCH] LIS3LV02Dx Accelerometer driver (take 4)
Pavel Machek schreef:
Hello,
> Ok, I guess you have better eyeballs. Yes, the locking was totaly
> broken (and disabled by initing semaphore to 1 by default).
To which value the semaphore should have been initialised? I can see
DECLARE_MUTEX(name) declared as:
struct semaphore name = __SEMAPHORE_INITIALIZER(name, 1)
(I'm still learning about the locking in the kernel. To me, it looks
like a maze, and I couldn't find one simple document detailing all the
mechanisms.)
> Sorry
> about that.
>
> This strips some more code, turns semaphore into mutex, and should
> solve more problems.
>
> I killed the "power down on timer" thingie. I guess we can reintroduce
> it when we get the basics right (and driver works just fine without
> that... I did not detect unusual slowness).
I inserted the timer thingie because I have a program on my laptop which
reads the position twice per second. Using the joystick interface uses
two much CPU (it's 20 Hz) and so it's using the sysfs interface.
However, turning on and off the device twice per second is rather costly
(especially due to the ACPI access). That's why I made it delayed... and
I'd like to keep it this way.
I'll send this evening a "delayed power down" based on workqueue. Within
the work of a workqueue, it's not possible to use a mutex, right? Only
semaphores are allowed?
Eric
--
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