Sorry for my English!
I am working on davinci kernel 2.6.34. I have a board with two processors one is DM365 and other C5515. The exchanging with data by usb, 365 is host and 5515 slave.
On 365 I also have another one usb jack, for other usb devices, but I don't have hub, and I am using special key on gpio for switching usb port, I name this "internal"(5515) and "external"(other usb devices on second port).
Most time I am working with 5515 processor, but in any time I need to save my data to external flash device, for this I switch usb to "external" port , 5515 disconnecting and after that I am inserting usb-stick, and work with it! All good, but if insert usb-stick before switching ports, I haven't got disconnect message on switching. And after removing, inserting stick, in /proc/bus/usb/devices I have seen that 5515 is connected, after reverse switching to 5515 I couldn't work with it, I had error "usb 1-1: device descriptor read/64, error -19"
I ve begun to find where is problem, and I noticed that on switching I am getting interrupt 0x04(MUSB_INTR_RESET) in musb_core.c. This means that we got hardware reset on a bus. This means that controller clear all registers to their initial state. After reinsmoding musb driver I can work with usb device! We all know that this takes a lot of time.
I have patched musb_core.c, and now on recieving reset, I am disconnecting all usb devices, and reiniting all control regs, cppi regs and epoints .
My question is: Why musb_hdrc doesn't process this interrupt?
Is there another solution for my problem?
If any one needs this patch I can upload it.
Its always better to upload if you have found anything new. That may help someone else in future. Also, Other experts can comment on the solution.
The BUS_RESET bit D2 indicates BABBLE interrupt in host mode. D2 bit is read as RESET interrupt only in peripheral mode. Babble is generated when there is some electrical noise on usb bus and so should be avoided at first place. As a workaround you can try setting the SESSION bit in DEVCTL register when you get BABBLE (D2 bit) interrupt.
If my reply answers your question then please click on the green button "Verify Answer"
I thought that it is babble, too. But in my situation devctl is 0x98 and it goes outside babble interrupt process.This interrupt only handled but no one work with it it.
There seem to be some issue with ID pin being grounding as DEVCTL-0x98 menas D7=1 indicating musb is in device mode, and thus D2 bit set means RESET interrupt. You may want to check the ID pin value when switching the port from internal to external one.
Additionally try switching off the session before swicthing internal <-> external and then set session bit again after switching.
Here is another problem, I can't control switching, it controls by other processor (5515) , and I can't track this process. That' s why it very important to process this irq correctly.
This is strange, DM365 being host should known and be able to control switching. To me it looks like that when SESSION is on and suddenly usb pins are switched then ID pin goes floating for a short period of time and mentor controller thinks its in device mode. To reflect the new mode, we need to switch off the session and switch on it again.
You said DEVCTL is 0x98 that is indicating that session is indeed off D0 =0. Can you just try sessting SESSION bit when you get this interrupt?
Ok I tried, I set SESSION bit in devctl and nothing has happened, I tried to reverse switching to device which marked as connected and I couldn't work with it.
Do you see Devctl.D0 = 1 after setting the session bit?
Yes its 1
Sme question after re-reading the main post.
=>but if insert usb-stick before switching ports, I haven't got disconnect message on switching.
I guess you are talking about disconnect of "internal" 5515 processor right? If so then why it's not coming? Disconnect is detected when host finds both D+ and D- going low for >=2.5us. This may happen as external port has devices connected and so D+ pull up also enabled. Can you put some delay of say >=2.5 micro seconds between the switching events? It should be like, 5515 does the disconnect then pauses for >=2.5us and then connects the usb pins to external port.
=>And after removing, inserting stick, in /proc/bus/usb/devices I have seen that 5515 is connected,
That means usb stack still thinks same old device is connected as there was no disconnect event.
=>That means usb stack still thinks same old device is connected as there was no disconnect event.
Yes I know, because this switching is very fast.
=>Can you put some delay of say >=2.5 micro seconds between the switching events?
I repeat that I couldn't control switching, and this looks like workaround. And I am not sure that 5515 who control switching can put delay, because it can only control gpio, for example 0 - internal, 1 - external. Board designer put there special key chip, it only can switch d+,d- lines and it is not possible to put any delay in switching.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.