I have been using the mcf_qspi.c QSPI driver on several mcf5329
Coldfire boards, both the Freescale/LogicPD evaluation board and our
custom hardware, and it has largely worked fine - when using only one
minor device - specifically, minor number 0. However, now that I am
using several separate minor numbers, I get occasional, mysterious
hangs, but never on minor number 0! When I say "hangs", I mean that
the call to write never seems to return.
For example, I open and use them something like this:
int dev0;
int dev5;
...
int main(...) {
...
dev0 = open("/dev/qspi0", O_RDWR);
dev5 = open("/dev/qspi5", O_RDWR);
...
printf("Writing 0\n");
numWritten0 = write(dev0, outbuffer0, num0);
printf("Writing 5\n");
numWritten5 = write(dev5, outbuffer5, num5);
printf("Finished writing\n");
...
Here is the output:
Writing 0
Writing 5
Note, no "Finished writing". If I break out of the code (while using
a BDM debugger), the processor is almost always in the idle task - in
other words, the rest of the system seems fine.
The first write _always_ works - at least, I've never seen it fail.
The second write, however, fails more often than not, but it does
succeed 20-30% of the time. The order of the writes don't matter
either. However, if a write to dev5 actually does succeed, it seems
to work for the duration of the program; in other words, it either
crashes the first time write is called, or it never fails.
I think the problem is in the following snippet of code, where I've
added two printk's to illustrate my theory.
printk("qspi_write: Sleeping\n"); /* RSG */
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
save_flags(flag); cli();
#else
local_irq_save(flag);
#endif
QDLYR |= QDLYR_SPE;
sleep_on(&wqueue);
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
restore_flags(flag);
#else
local_irq_restore(flag);
#endif
printk("qspi_write: Waking up\n"); /* RSG */
Sure enough, the first printk gets executed, but the second never
seems to get hit. So I'm guessing it's stuck waiting for an interrupt
that is lost somehow.
Anyone have any ideas or similar experiences?
Thanks,
-Bob
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
