Re: [OpenWrt-Devel] DWC OTG USB, round 3

2012-01-23 Thread John Crispin
 
 Nevermind. I've meanwhile found some code crafted by Amlogic (or whoever
 it was) addressing exactly this problem. It does not work well because
 it is buggy, however the idea is simple enough: do not push data to Tx
 FIFO if it still holds some previous unsent data for another EP. I think
 I can fix this workaround to actually do what it tries to.
 (This somewhat reduces the whole usefullness of EPs probably, but at
 least the damned thing stops throwing EP mismatch, I've checked)
 
 Thank you.
 NIkolai

Hi,

there is a forked/rewritten version of the dwc driver made by
infineon/lantiq which gets used on the xway family of socs.

i looked around the several downloadable GPL drops made by the various
cpe vendors using this soc

inside the fritzbox3370 code you can find

$ grep GPL GPL/linux-2.6.28/drivers/usb/musb/*
ifxusb_driver.c:MODULE_LICENSE(GPL);

files can be found here
ftp://ftp.avm.de/fritz.box/fritzbox.wlan_3370/x_misc/opensrc/

maybe there is some useful info inside those files.

John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] DWC OTG USB, round 3

2012-01-22 Thread Nikolai Zhubr

Hello,
22.01.2012 1:40, I wrote:
[...]

if matters). Without that, controller starts raising IN Token Received
with EP mismatch instead of normal Transfer complete bit. If I
understand it correctly, this means that Tx FIFO happened to be filled
in some particular order that controller disliked (and refused). I've
also found a fragment of code with possibly relevant comment (quoted
below). Indeed, apparently this EP mismatch event is not handled
anywhere in the driver (other than providing a line for dmesg). If it
should, then I'd guess it means the driver is just plain unfininshed and
I have no idea if it can even be fixed with a reasonable effort. Not


Nevermind. I've meanwhile found some code crafted by Amlogic (or whoever 
it was) addressing exactly this problem. It does not work well because 
it is buggy, however the idea is simple enough: do not push data to Tx 
FIFO if it still holds some previous unsent data for another EP. I think 
I can fix this workaround to actually do what it tries to.
(This somewhat reduces the whole usefullness of EPs probably, but at 
least the damned thing stops throwing EP mismatch, I've checked)


Thank you.
NIkolai


sure what was meant exactly by one endpoint at once though.. Of course
usefull gadget drivers would probably employ  1 EPs, even
g_file_storage does so? Strange thing.

Thank you.
Nikolai

/* Reactive the EP */
dwc_otg_ep_activate(GET_CORE_IF(pcd), ep-dwc_ep);
if (ep-stopped) {
ep-stopped = 0;
/* If there is a request in the EP queue start it */

/** @todo FIXME: this causes an EP mismatch in DMA mode.
* epmismatch not yet implemented. */

/*
* Above fixme is solved by implmenting a tasklet to call the
* start_next_request(), outside of interrupt context at some
* time after the current time, after a clear-halt setup packet.
* Still need to implement ep mismatch in the future if a gadget
* ever uses more than one endpoint at once
*/
ep-queue_sof = 1;
tasklet_schedule (pcd-start_xfer_tasklet);
}
/* Start Control Status Phase */
do_setup_in_status_phase(pcd);

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel