Replies inline. On Wed, Aug 26, 2009 at 3:59 PM, Sergei Shtylyov <sshtyl...@ru.mvista.com>wrote:
> Hello. > > Brian Rhodes wrote: > > I just got my audio working this evening with a TLV320DAC32 DAC on a >>> near-copy of the DM6446 EVM board (we use the TLV320DAC32 instead of the >>> TLV320AIC33 and drop the I2C port expanders). I've had USB host mode >>> working for a while, but now when I try to use audio after mounting a flash >>> disk, or mount a flashdisk after using audio, I'm getting various errors as >>> shown below. >>> >>> I thought I read a post here somewhere about a problem along these lines, >>> but I can't seem to find it in the archives. Is this anything new? This is >>> 2.6.31-rc7. CPPI DMA is enabled. >>> >> > I constantly see alike messages when running USB test #12 (testusb.c can > be found at http://www.linux-usb.org/usbtest/). > > We recently had this problem with one of our boards, but it appears to >> have been completely a circuitry issue, though the driver may also have a >> couple issues when there are some problems with the signals. The board >> layout had some issues where the impedance was not being maintained properly >> either because of distance between traces, or switching layers on the board. >> I believe the major problem was a couple of right angle turns in the traces >> which were causing signal reflection. I have not heard that it was >> reproduced since our layout issues were fixed. >> >> I think the impedance between the differential pairs should be 90 ohms. >> We had one spot where that was not maintained to avoid a through hole and a >> couple right angles in the traces close to the connector. >> > > That's interesting point... I know the engineer spent a lot of time checking impedances and such. I know most of the clocks are modeled down to around 10 picoseconds. Obsessive-compulsive as a description comes to mind. I will load this on the Davinci DVEVM board and check for it also. If it occurs on that board also, I'd be more inclined to say it's a software issue. USB is touchy, but not THAT touchy. I've run USB 2.0 at full speed over a few inches of wire-wrap wire with success. And I can reproduce this problem every time. > > > The git kernel version which I was using was 2.6.30-rc7. I was thinking >> perhaps musb_h_tx_flush_fifo should simply clear MUSB_TXCSR_FLUSHFIFO from >> MUSB_TXCSR if it failed >> > > This bit is self-clearing, and the register readback show it as cleared, > so there's no point. > > so that at least USB could become usable again. >> > > It is usable regardless. I'm not what "usable" means, as it seems to take at least a few minutes to recover. > > > Trying to recreate it just now is not proving easy. Even before it was a >> fairly rare occurrence. >> > > Try to use the aforementioned test suite... > > _______________________________________________ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source@linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> > > WBR, Sergei >
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
