From: Mark Yeck (y3k@gti.net)
Date: Mon Aug 26 2002 - 11:32:14 EDT
Ron wrote: > I have the qspi working OK on the 2.4 release on the Arcturus 5272 > board. I ported the driver over from the 2.0 release. What linux > release are you using? What processor? What do your IOCTL calls look > like? Is the driver compiled into the kernel or is it loaded? Are you > using 8-bit or 16 bit mode? I believe that the driver may not do > anything when set to 16- bit transfers if you only try to send/receive > 1 byte? - it always needs a multiple of 2 bytes in 16-bit mode. I don't > believe usleep can sleep les s than one tick, so your usleep(10 > microseconds) may only be wishfull thinking, you might want to check > that with a scope. You should check the result of your open() to see if > it is suceeding, a previous open may have left qspi1 locked. Does > /dev/qspi0 still work when your /dev/qspi1 program is hung? You are > aware that your while(1) never finishes, so your routine never returns, > so you must be using a scope or other external device to 'see' that the > qspi transfers have! > stopp > ed. > Ron Fial Hi Ron, I'm using the 2.0 kernel from the 20020701 release on the Coldfire 5272 compiled with uC-libc. I've tried a few different ioctls, but I can reproduce the problem without setting any ioctls. I'm using 8-bit mode, so i dont think that's the problem. I've checked the results of open() and everything seems okay. In fact, I can write or read hundreds of bytes successfully before it stops working. Indeed, the usleep sleeps for an entire tick, but I dont think that's part of the problem. I'm only opening qspi0, and you're correct that my while() never finishes and that I'm using a scope to check for qspi transfers. To add a bit more information, I was wrong before when I thought that I didnt have the problem during writes, it happens with reads or writes to the qspi device. I'm fairly certain that it gets hung at teh interruptible_sleep_on(&wqueue) line. Here's some nitty gritty info that may help. When things stop, the QAR is set to 0x21, which means that the QDR was written to. The SPE bit in the QDLYR is clear, which means that either it was never set (enabling the qspi port) or that the qspi operation was successful and it was cleared by the hardware. The SPIF bit in the QIR register is clear, so either the qspi operation never took place, or the bit was cleared by the interrupt routine (qspi_interrupt). The real kicker is that I have now turned off the qspi interrupt and replaced the interruptible_sleep_on(&wqueue) line with a couple of lines to poll the QIR for the QSPIF bit (which is set by the hardware when the transfer is done), and everything works great. Polling that register is an alright workaround for now, but it would be nice to make it work as intended. I'm just not exactly sure how to go about debugging it beyond what I've done. -mark This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/
This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:21:45 EDT