Rockbox mail archiveSubject: Re: Classic holdswitch polling
Re: Classic holdswitch polling
From: Michael Sevakis <jethead71_at_comcast.net>
Date: Sat, 10 Mar 2012 16:37:05 -0500
>> 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
> Really a nice hack, just one line of code to check if the mutex is locked.
No, don't look at mutexes like that since I make no promise to not break
code peeking under their skirt. I'll write you up a mutex_lock_w_tmo if you
really must have it. Semaphore have no priority inheritance so I wouldn't
use those either because you _will_ notice when priority inversions happen
(and it's not nice).
> Its great to see as many ideas for solving this issue, i am new to
> Rockbox code so prefer to stay a bit away, will try to summarize:
> 1) Use an existing thread: this is a target specific patch, it should
> not be placed into unrelated sections in order to maintain clean a big
> multitarget project, discarded?
Not sure what. The existing thread that does it should be the thread that
already does it.
> 2) Async I2C: i will look at this code ASAP, seems it could be
> implemented as a generic driver for all targets that HAVE_I2C_STACK?,
> will it work for the holdswitch polling?
Not so bad really. No mutexes required. Just a quick interrupt disable to
protect a linked list. Synchronous stuff can just init and wait on a
semaphore. Additional complexity is minor and complex read/write cycles can
be synthesized and be atomic against both threads and interrupts.
> 3) Create a specific thread for Classic: other targets are using this
> method, to factorize code a generic target thread (?) could be added,
> all targets defining HAVE_TARGET_THREAD can use it to register some
> specific tasks, and continue using the tick IRQ handler for other
I don't own one and so long as it's not in the way of anything I do.
> 4) Create a new button thread for all targets: should this option
> include other input methods? (clickwheel, touchscreen, remotes...),
> maybe some actions actually done on the target drivers should be moved
> to a more generic input thread.
No way I'll accept that and it would suck with scrollwheels. De-threading
things if possible is better. Most have no need for this whatsoever. Thread
structures are in IRAM on some targets (which helps keep scheduler overhead
down significantly) and in many cases it is already pretty tight there.
Received on 2012-03-10