Rockbox mail archiveSubject: Re: Classic holdswitch polling
Re: Classic holdswitch polling
From: Michael Sparmann <theseven_at_gmx.net>
Date: Thu, 08 Mar 2012 22:01:39 +0100
>> Tick tasks are run from ISR. There is absolutely no need to read keys
>> in ISR IMO, reading in ISR gives no benefits in this case.
> As far as I can see, there's no reason at all to poll keys all the time
> except in the sense of generating consistent repeat behavior, which
> means the button tick is only needed when a key is pressed. ISR should
> be the defacto method. It's also lower in overhead and can consistently
> capture input into the queue.
Please note that we're actually talking about reading the hold switch
status here. The actual key reading is IRQ-driven, IIRC pushing down raw
clickwheel data packets to a clickwheel/button handler thread. Reading
actual key presses/wheel positions doesn't involve I2C at all.
Reading the hold switch is not all that critical because it physically
shuts down the clickwheel hardware. I think it's only neccessary to
control the backlight and lock icon, and possibly to reset the
clickwheel after the hold switch is turned off.
Currently it's done from a tick task, and that's somewhat likely to
clash with another, already ongoing, I2C access, e.g. to the codec.
I fail to see how an async I2C driver could resolve that clash from IRQ
The least invasive way to fix this bug would probably be to figure out
if I2C is already in use when trying to read the hold switch in the tick
task, and if it is just skip updating the hold switch status for that tick.