Rockbox mail archive

• Next message: Nielsen Linus (ext): "RE: potential bug report"
• Previous message: Greg Haerr: "Re: source suggestings (was missing win32 file)"
• In reply to: Greg Haerr: "potential bug report"
• Next in thread: Greg Haerr: "Re: potential bug report"
• Reply: Greg Haerr: "Re: potential bug report"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Greg Haerr wrote:

> A quick review of the source shows that, although not a bug yet, the
> code in firmware/drivers/ata.c::ata_read_sectors() won't work if the
> count parameter is ever called with a value != 1.

Right, we haven't tested with >1 sector reads. Nice spotting, we're fixing
it now.

> BTW, I'm trying to understand exactly how many threads are running in
> the current version. Is it just the mpeg_thread, or is there a seperate
> UI/button thread?

Currently there are three threads in use:

- Main/UI thread
- Mpeg thread
- Scroll thread

The buttons are polled in interrupt context (every X timer tick) and
events are posted to a queue, which is read by the main thread.

> I ask because the ATA disk routines have mutex sections, and was
> wondering whether the entire disk subsystem was built to work using open
> "files" from multiple threads... Very cool low-level code, BTW.

Thanks. Yes, we are today opening and reading files in both the main
thread (playlist files) and mpeg thread (mp3 files), hence the mutexes.

> In the kernel.c mutex_lock function, there's no STI/CLI pair around the
> mutex, is this because there's no preemptive scheduling?

Exactly. We delierately chose to use cooperative scheduling to keep
complexity and reentrancy issues to a minimum.

> I see that the queue_post routines have it, and I assume that's because
> those routines can be called from a bottom-half interrupt routine (which
> aren't scheduled, just interrupt-driven?

Correct again. :-)

> I haven't seen yet what gcc emits for SH1, but for some systems,
> ++m->count is much faster than m->count++. (same for decrement)

About optimisation in general, I have instructed people to not think about
instruction-level optimisation when writing C code, instead focusing on
making the code simple and straight-forward, just like any normal C code.

Your example is not complex or counter-intuitive, so it's not a problem,
but in general I prefer simple code over fast code. Most code doesn't need
to be fast and thus we gain more from it being simple.

-- 
Björn

• Next message: Nielsen Linus (ext): "RE: potential bug report"
• Previous message: Greg Haerr: "Re: source suggestings (was missing win32 file)"
• In reply to: Greg Haerr: "potential bug report"
• Next in thread: Greg Haerr: "Re: potential bug report"
• Reply: Greg Haerr: "Re: potential bug report"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]