Hi, On Tue, Nov 18, 2014 at 03:41:43PM -0500, Jorge Ramirez-Ortiz wrote: > >>> you have no clue what these mean, do you ? How about reading the USB > >>> specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml > >> > >> Unfortunately I do. > >> It was easier to temporarily hack the driver code for a test - while I > >> was at it - rather than modifying the host code. > >> Since you asked for them, I though you would read the logs and wonder > >> where the funny ids where coming from. > > why do you even need to hack the host driver for these ? The driver > > shows a Printer Class interface and the linux host side driver should > > bind to it without any issues. > > the hack was on the gadget side. > > the usbhost test code in charge of sending the file to the device had the wrong ids. > to save time -since I was modifying the gadget driver code and only for the > tests (it is not part of the final patch) - I hacked those ids on the printer.c > file. > but anyway. lets move on. I removed those, recompiled the usb host code and sent > the new traces. then the host side needs a fix because it shouldn't really care about the device ID, rather it should care about the class being printer. > >> That hack above would have given you an answer: so I kind of know what > >> the ids are for. honestly. anyway, will send the new logs - it took > >> me a while to find and modify the host test code. > > Which host test code ? Why don't you just use lpr or even cat file > > > /dev/lp0 or something like that ? > > it is some proprietary code that links libusb -part of a different project: it > was useful as it generated some metrics I was interested in. I would be surprised if lpr doesn't work for the same purpose. > >>> do you want to debug that and find the culprit since you're already at > >>> it ? > >> probably: I still need to get used to this process, thanks for bearing > >> with me on this. > > no problem. > > > >> I spoke to Ricardo Ribalda three months ago while I was doing this > >> stuff. but yes, I might work on this -after I finish with this > >> patch!- since I have access to the hardware locally. > > cool, that'll help. > > notice that the original PLX driver was still far from the theoretical 5Gbps > target (I was expecting to measure at least 3Gbps and could only get 1Gbps). > So 1Gbps should be the target to meet on the kernel.org net2280 - do you agree? this depends on a whole bunch of things. Mainline is a lot different from PLX's kernel tree, I'm sure. It also depends on how many PCIe lanes you're using. Just because USB3 guarantees 5Gbps bandwidth, if you use a 1x PCIe connector, you'll never get that ;-) -- balbi
Attachment:
signature.asc
Description: Digital signature
