Re: Sharp CE-RH2 remote kernel driver

On 1/18/07, Justin Patrin <[email protected]> wrote:
> On 1/18/07, Richard Purdie <[email protected]> wrote:
> > On Thu, 2007-01-18 at 12:31 -0800, Justin Patrin wrote:
> > > I finally got another hint and have a working kernel driver for the
> > > CE-RH2 in-line audio remote. It outputs the correct keys.
> > >
> > > There is a problem with the IRQ handling as well as I see this in dmesg:
> > > enable_irq(45) unbalanced from bf1483e0
> >
> > Keep in mind the effects of enable_irq and disable_irq are cumulative
> > i.e. if you call disable_irq 4 times, you have to call enable_irq 4
> > times too. It may well be better to leave the interrupt handler enabled
> > all the time, I'm undecided...
> >
>
> Not taken care of yet, will look further when I work on the big state function.
>

Ok, I've rewritten the majority of the code now. It's about the same
length but it makes more sense to me now...

http://oe.reversefold.com/sharpsl-rc/sharpsl-rc-r1.patch

Some notes:

1) I've kept the DPRINTK define as I can't figure out what dev I
should pass into dev_dbg (no other input devices seem to use it).

2) The logic is similar to the Sharp driver but has less craziness (I
know I saw a few bugs while trolling that old code).

3) Remote insert/removal is sent via a switch event, same as the
keyboard driver does. Unfortunately, SPITZ_GPIO_AK_INT doesn't show
anything when the remote is inserted so we have a duplicate of this
info. SPITZ_GPIO_AK_INT works fine for normal headphones, the logic in
this driver deals with the remote.

3a) Knowing whether the headphone should be turned on is essentially a
simple OR of the 2 switches. Setting up another instance of switchevd
for the remote causes it to set the output correctly. The correct
solution would be, I think, to listen to *both* switches, but check
the values of both whenever an event is received. Or perhaps we need
to combine the drivers somehow...

3b) The insertion logic doesn't always work quite correctly. Sometimes
inserting the remote doesn't cause the insert event to happen. Perhaps
this is because it happens too fast... To work around this whenever a
key event is received the insertion state is checked and if the remote
is not set as inserted it will send an insertion switch event.

3c) When the remote is inserted there are often spurious removal
events. To fix this the module does 2 things:
  i) keeps track of whether the previous event was a switch event and
throws away any following removal events if the last event was a
switch
  ii) added a second timer function which happens 500ms after the last
event which resets the "last_was_switch" state so that an insert can
be followed by a real removal. If another event happens within 500ms
this timer is reset.

4) sharpsl_pm_pxa_read_max1111 and the MAX1111 defines have been moved
to sharpsl_pm.h and sharpsl_pm_pxa_read_max1111 is now exported.

-- 
Justin Patrin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV