Hi,
> It looks like you didn't add the dump_stack() call to the UDC driver's
> queue function. You need to add it.
The attached is the log of dump_stack() call in the UDC driver queue
function, for the last few USB request in the USBCV "device descriptor
test – addressed state". From the log, af
Hi,
> The text capture is incomplete. It is missing lots of packets. In
> particular, it is missing all the packets between 202489 and 202502.
The missing packets are NAK, I added the NAK after Set-Config setup
stage. I hide the NAK when i export the packet capture to text format.
> Also, I do
Hi,
> Victor, if you can get hold of a USB bus analyzer, you would be able to
> see directly when the DATA1 packet does or does not get sent.
I am in the process of getting a USB bus analyzer.
> No -- the problem is that the UDC completes the Set-Config request
> before it should. In other word
Hi,
>> However, the USB-2 spec says (section 9.2.6.4) that devices should be
>> able to carry out requests with no Data stage (such as Set-Config)
>> within 50 ms. Does your gadget really take longer than that to handle
>> the exception?
>>
>> To find out, collect a usbmon trace showing what happ
Hi,
> However, the USB-2 spec says (section 9.2.6.4) that devices should be
> able to carry out requests with no Data stage (such as Set-Config)
> within 50 ms. Does your gadget really take longer than that to handle
> the exception?
>
> To find out, collect a usbmon trace showing what happens wh
Hi,
>> May i know which part of the do_set_config() or do_set_interface() has
>> to be run in process context?
>
> Well, it's not exactly true that the routine has to run in process
> context. More accurately, it has to run at a time when the main thread
> isn't using any of the endpoints or requ
Hi,
>> Yes, this should be the root cause. For the setup stage of Set-Config
>> request, the UDC driver can handle it well. But for the status stage
>> of Set-Config request, somehow it is not handled correctly. When UDC
>> driver receives the endpoint 0 IN token, it only clears the interrupt
>> r
Hi,
> Than either there is a bug in the UDC (or the UDC driver), or else the
> host doesn't wait for the Set-Config request to complete before sending
> the next request. What were the values of fsg->ep0_req_tag and
> exception_req_tag?
>From the printk added, the values of fsg->ep0_req_tag and
Hi,
>> I can't tell what's going on in your log. Look at the
>> FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code:
>>
>> rc = do_set_config(fsg, new_config);
>> if (fsg->ep0_req_tag != exception_req_tag)
>> break;
>>
Hi,
> I can't tell what's going on in your log. Look at the
> FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code:
>
> rc = do_set_config(fsg, new_config);
> if (fsg->ep0_req_tag != exception_req_tag)
> break;
>
Hi,
> No, that's not right. Set-Config has only two stages, Setup and
> Status; there is no Data stage. The flow is:
>
> Host Device
> - Setup Packet ---> |
> - Data0 Packet ---> |== Setup stage
> < Ack Packet -- |
>
> - In Packet -->
Hi,
>> Yes, UDC driver has bug. After modifying it, it can receive Set-Config
>> request with a config value of 0. However, the "device descriptor test
>> - addressed state" still fails.
>>
>> Please see the attached log. The Set-Config request with a config
>> value of 0 is the second last USB re
Hi,
>>> No, i don't see that (Set-Config request with a config value of 0)
>>
>> Well, then I don't know where the problem is, but obviously the problem
>> occurred before the gadget driver was involved. Either the host sent a
>> wrong packet, or more likely the UDC received the packet incorrectl
Hi,
>> No, i don't see that (Set-Config request with a config value of 0)
>
> Well, then I don't know where the problem is, but obviously the problem
> occurred before the gadget driver was involved. Either the host sent a
> wrong packet, or more likely the UDC received the packet incorrectly.
Y
Hi,
>> g_file_storage gadget: ep0-setup, length 8:
>> : 00 09 01 00 00 00 00 00
>> g_file_storage gadget: set configuration
>
> Yes, that is a Set-Config request with configuraiton value 1. You
> probably got hold of the wrong part of the log. Elsewhere there should
> be a Set-Config req
Hi,
> You should not be concerned about variables in the gadget driver. The
> problem is in the UDC driver.
>
> For some examples of what the UDC driver needs to do, look at
> handle_control_request() in drivers/usb/gadget/dummy_hcd.c or the
> "switch (u.r.bRequest)" statement of handle_stat0_irq
Hi,
>> I re-attach the usbmon log. If possible, please show me which line
>> indicates that usb_ep_set_wedge routine is not working, or how to look
>> for the clue. Is it from the control transfer line?
>
> Here's an example:
>
> f4148f80 308532 S Bo:1:011:1 -115 31 = 55534243 0600 c00
Hi,
>> Ok, is the usb_ep_set_wedge routine not working? I can't see that in
>> the log file.
>
> It is not working. This can be seen in the usbmon log.
I re-attach the usbmon log. If possible, please show me which line
indicates that usb_ep_set_wedge routine is not working, or how to look
for th
Hi,
>> The problem is in UDC driver. i made the change, it is ok now.
>
> Good. I noticed that the usb_ep_set_wedge routine still isn't working
> right. You might try to fix that.
>
> Alan Stern
>
Ok, is the usb_ep_set_wedge routine not working? I can't see that in
the log file.
Now, in USB 2.
Hi,
>> Yes, i see the bad characters in the log file. I apologize for that,
>> my eyes was in pain after looking thru the log files and did not
>> notice that when i attached the log file.
>>
>> The good news is i can get gadget to work with Lenovo x100e on Ubuntu
>> and Windows. The change is add
Hi,
> Yes, i see the bad characters in the log file. I apologize for that,
> my eyes was in pain after looking thru the log files and did not
> notice that when i attached the log file.
>
> The good news is i can get gadget to work with Lenovo x100e on Ubuntu
> and Windows. The change is adding mo
Hi,
>> There is a mistake in the previous log file, because the fifo size is
>> still set to 512 byte. Now i change it to 64 byte if it is Full speed.
>
> The FIFO size should always be set to the value in the endpoint
> descriptor, no matter what speed the connection is.
>
>> The log file are att
Hi,
>> I did another usbmon capture from the moment usb cable is plugged into
>> the Ubuntu x100e laptop. This time the usbmon does not have -75 error.
>> When the SCSI_READ_10 command request for 4096 bytes of data, and the
>> data is returned by the gadget, usbmon simply shows -108 error. The
>>
Hi,
> The usbmon trace shows lots of errors. All those -75 (EOVERFLOW)
> status codes mean that the gadget sent a packet that was too large,
> i.e., more than 512 bytes. This happened in all the READ(10) commands
> except the last one -- none of them succeeded in transferring any data.
>
> After
Hi,
> Another possibility is to set up a virtual Windows system inside your
> Linux host. Then try running the USB CV program on the virtual
> machine, and use usbmon on the host system to capture the USB traffic.
>
> I don't know if that will work, but it might.
Thanks. i will find a way to set
Hi,
>> The hardware handles Set Address request, and i can see the address of
>> the USB gadget being shown in Windows host. Here i attach the gadget
>> driver log for the "Device Descriptor Test - Addressed State". The
>> test just failed after Get Configuration request.
>
> I can't tell what's w
Hi,
>> Thanks a lot. i understand this part now. Do you notice the Set
>> Address request is not seen by the gadget driver? The Set Address
>> request is handled by the hardware. Could it be the root cause? As
>> gadget driver may expect the address information from the host, and
>> for now UDC dr
Hi,
>> The CV log is attached (Dev_desc_test-Address state.html). Is it helpful?
>
> It doesn't help very much. Can you get a more verbose log, one that
> lists all the transfers?
>
> It looks like the problem could be that the host and the gadget don't
> agree on what packets have been sent and
Hi,
>> When i run USB 2.0 Command Verifier on file gadget and UDC driver, an
>> error in Command Verifier says "Device must support being set to
>> Addressed/Configured state". Does it mean the gadget cannot support
>> putting device in addressed state or configured state, as in
>> supporting the
Hi,
On Thu, May 30, 2013 at 10:44 PM, Alan Stern wrote:
> On Thu, 30 May 2013, victor yeo wrote:
>
>> I tested the g_zero with USB 2.0 Command Verifier. After the Command
>> Verifier is run, the UDC gadget driver queue function is continuously
>> being called, and the
Hi,
>> Ok. What other gadget driver can i test with UDC driver? Is it the
>> mass storage driver (mass_storage.c)?
>
> That is essentially the same as g_file_storage. But there are lots of
> others. You should start with g_zero and run the testusb suite. See
>
> http://www.linux-usb.org
Hi,
>> Is it possible to
>> contribute the code to Linux community?
>
> Yes. But first you should test it with other gadget drivers, not just
> g_file_storage.
Ok. What other gadget driver can i test with UDC driver? Is it the
mass storage driver (mass_storage.c)?
Has the g_file_storage passed t
Hi,
>> Yes, it is silly. The hardware interrupt is not being generated for
>> every SCSI command received, so the driver has to poll. I put the
>> polling code in a thread, and this dilemma is fixed.
>
> Are you sure about this? If it is correct, you should _fix_ the
> interrupt problem. Don't t
Hi,
>> I am able to solve the SCSI command timeout problem by adding a code
>> to check the hardware register busy bit continuously, in
>> kagen2_ep_queue():
>>
>> do {
>> read_hardware_register_busy_bit
>> } while (hardware_is_busy)
>
> This is silly. Drivers shouldn't poll in this way. That'
Hi,
> Thanks! Indeed, the req->buf pointer was the one causing the crash
> problem. It happened when combining multiple 512 bytes data. I have
> fixed this bug.
>
> Now my UDC driver is almost ready. That is probably one more SCSI
> command timeout problem remaining, i am adding more printk to UDC
Hi,
>> When copying a file to the USB gadget, sometimes the USB gadget will
>> hang, sometimes the USB gadget will crash, sometimes the copy is ok.
>>
>> From the UDC driver log, when the USB gadget crashes, the host is
>> sending 16384 bytes of data. It seems that bulk_out_complete() is not
>> ab
Hi,
>> Another question from the bulk_out_complete() printout which is shown
>> below. The req->actual is 512 byte. The bh->bulk_out_intended_length
>> is 31. Is this a bug?
>>
>> g_file_storage gadget: get_next_command
>> [start_transfer] 6f007442 7000
>> ept1 out queue len 0x200, buffer 0xc13300
Hi,
>> Just curious. The crash log shows the following UDC driver code which
>> is responsible to receive endpoint 0 setup data. However, the host PC
>> is sending SCSI_WRITE_10 command at the time of the crash. These two
>> does not correlate, right?
>>
>> unsigned int rdata, rdata1
Hi,
>> Thanks. I will add more printk statements gradually. Now i discover if
>> i write to a large text file (> 48k) on USB gadget, linux will crash.
>> The full log of UDC and gadget driver when linux crashes, and
>> corresponding usbmon trace are attached. If these logs are not
>> helpful, i sh
Hi,
> All I can tell is that the gadget got hung after receiving the second
> WRITE command. Can you figure out where it got hung and why?
>
> Victor, you don't seem to get the big pattern that keeps repeating
> here. Every time something does wrong, you tell me about it. Then I
> point out tha
Hi,
>> Ok, i just fixed the last three bytes in the bulk-out transfer
>> problem. Please see below for the log. Now the last three bytes are
>> read correctly. After SCSI_WRITE_10 is received, the gadget driver
>> prints "g_file_storage gadget: disconnect or port reset", it means USB
>> reset inte
Hi,
> Obviously this "disconnect or port reset" message is related to the
> "EP1 OUT IRQ 0x28" line above. But why? It looks like another bug.
>
> I see you still haven't fixed the last three bytes in the bulk-out
> transfer.
Ok, i just fixed the last three bytes in the bulk-out transfer
proble
Hi,
>> > That's right. Interrupts can occur at almost any time (on
>> > multiprocessor systems they can occur even when interrupts are disabled
>> > on some of the CPUs).
>>
>> I am confused. I add the spinlock functions to kagen2_ep_queue function.
>>
>> spin_lock_irqsave(&dev->lock, flags
Hi,
>> > It is likely that this bug occurs because you don't use a spinlock in
>> > kagen2_ep_queue. Does the interrupt handler routine use a spinlock?
>>
>> Spinlock is Not used in interrupt handler routine.
>
> Then that's the reason for this bug.
>
>> >[start_transfer] 53425355 10d
>> >ept1 ou
Hi,
>> I made some changes regarding req.actual. Now the UDC driver still
>> cannot process SCSI_WRITE_10 command. Please see the attached UDC
>> driver log when i try to write to a text file. There should be three
>> SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and
>> SCSI_W
Hi,
>> How the UDC driver know when the request is really complete?
>
> An OUT request is really complete when either:
>
> The total number of bytes copied into req.buffer (i.e.,
> req.actual) is equal to req.length, or
>
> The number of bytes received in the last packet is
Hi,
>> Please see the attached kagen2_ep_queue(). As long as it is called, it
>> will queue the request and read packets from hardware, in the same
>> if-else branch for bulk out endpoint. The interrupt handler will NOT
>> accept packet if request is NOT queued. If request is queued,
>> interrupt
Hi,
> While kagen2_ep_queue() is running, there shouldn't be any packets in
> the USB hardware. The hardware should refuse to accept any packets,
> sending NAKs back to the host, until a request has been submitted and
> queued.
>
> When the request is queued, that's when you should tell the hardw
Hi,
>> Yes, the kagen2_ep_queue() calls req->req.complete directly. I thought
>> this is necessary to pass the packets to gadget driver for processing?
>
> It is necessary to call req.complete when the request has _completed_!
> That's why the callback is named "complete"!
>
>> req->req.complete i
Hi,
>> This is the stack dump when the completion routine is called without
>> an interrupt occurring first, is it useful?
>>
>> Backtrace:
>> [] (dump_backtrace+0x0/0x110) from []
>> (dump_stack+0x18/0x1c)
>> r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
>> [] (dump_stack+0x0/0x1c) from []
>>
Hi,
>> I change that in UDC driver queue function, adding in a length check:
>>
>> if (len > 0)
>> {
>> ka_req->req.complete(&ka_ep->ep,
>> &ka_req->req);
>> list_del_init(&ka_req->queu
Hi,
>> Here is a full log from the beginning which shows another problem.
>> When the SCSI_READ_10 command below is received, there is a disconnect
>> or port reset which causes the (-32) broken pipe problem.
>
> You really need to fix the old problems before worrying about new
> problems. The se
Hi,
>> I modified the UDC driver to send out zero length data packet. Now the
>> linux host is able to see the USB gadget as a mass storage device and
>> read from USB gadget. However, writing to USB gadget fails. The
>> SCSI_WRITE_10 command often receives (-104). The usbmon trace showing
>> this
Hi,
>> >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12,
>> >> Hi=512
>> >> g_file_storage gadget: bulk-in, length 0:
>> >> [start_transfer] 43425355 12
>> >> ept1 in queue len 0x0, buffer 0xc12ac000
>> >> g_file_storage gadget: bulk-in set halt
>>
>> I think here is the
Hi,
>> I think the get_next_command() calls start_transfer() to read the next
>> CBW. After unknown command 0xa1 is received, and if UDC driver doesn't
>> halt the endpoint, why the get_next_command() does not call
>> start_transfer() to read the next CBW? Somehow, i don't understand.
>
> I think
Hi,
>> From the usbmon trace and driver log, i can only see that TEST UNIT
>> READY command is sent out but UDC driver does not receive it. May i
>> ask, under what circumstances, is gadget driver calling
>> start_transfer() to schedule reading from bulk-out endpoint ?
>
> file_storage.c calls sta
Hi,
>> >In fact, this problem starts even _before_ the INQUIRY command is
>> >received. The log shows that the UDC driver calls the
>> >bulk_out_complete routine over and over, even though no packet was
>> >received and ka2000_ack_irq didn't run. The same thing happens after
>> >the INQUIRY is r
Hi,
>> Here are another problem. In usbmon trace, the time difference
>> between first SCSI_INQUIRY command and the second TEST_UNIT_READY
>> command is large. So i check the driver log file. When SCSI_INQUIRY is
>> received, start_transfer() is called, then UDC ep_queue function is
>> called, the
Hi,
>> Thanks, i print out additional information in gadget driver and UDC
>> driver. Here are another problem. In usbmon trace, the time difference
>> between first SCSI_INQUIRY command and the second TEST_UNIT_READY
>> command is large. So i check the driver log file. When SCSI_INQUIRY is
>> rec
Hi,
>> Thanks for the detailed write-up. I have checked the UDC driver
>> set_halt(), it is called by the gadget driver. The full ascii text of
>> usbmon trace for one usb session is also attached. This usbmon trace
>> shows a few EOVERFLOW(-75) error. I don't know why EOVERFLOW error
>> happened.
Hi,
>> I use kernel 3.4.4, the code in handle_stat1_irqs() is as below. There
>> is no reset or disconnect member function in "struct
>> usb_gadget_driver" in kernel 3.4.4.
>>
>> if (stat & (1 << SUSPEND_REQUEST_INTERRUPT)) {
>> if (dev->driver->suspend)
>>
Hi,
>> Earlier, i used file=/dev/mmcblk0p1. Now i use
>> file=/mnt/sd/backing_file. This backing_file is a dummy file system
>> that i created. I attached two jpeg files. One show the MBR and Boot
>> Sector of the backing_file. Another shows the usbmon of the Linux Host
>
> Why did you send jpeg f
Hi,
>> Now i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the
>> SCSI_READ_10 command is still not working properly.
>
> What makes you think that?
Because the SCSI_READ_10 is able to read the MBR from the backing
file, and after that, SCSI_READ_10 reads all zeroes (fails to read
Hi,
> the parameter is file=/dev/mmcblk0p1
>>>
>>> Perhaps you have already realized this... mmcblk0p1 is the first
>>> partition of the mmcblk0 device. Block 0 of the partition is the boot
>>> sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So
>>> perhaps you really meant
Hi,
>>> > the parameter is file=/dev/mmcblk0p1
>>
>> Perhaps you have already realized this... mmcblk0p1 is the first
>> partition of the mmcblk0 device. Block 0 of the partition is the boot
>> sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So
>> perhaps you really meant to use
Hi,
>> > the parameter is file=/dev/mmcblk0p1
>
> Perhaps you have already realized this... mmcblk0p1 is the first
> partition of the mmcblk0 device. Block 0 of the partition is the boot
> sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So
> perhaps you really meant to use:
>
>
Hi,
>>> > It looks like the data is wrong, but I have no way of knowing what the
>>> > data actually should be. Only you know that.
>>> >
>>> >> f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
>>> >> 8a28 0008 00
>>> >> f31a9740 4037054176 C Bo:
Hi,
>> > It looks like the data is wrong, but I have no way of knowing what the
>> > data actually should be. Only you know that.
>> >
>> >> f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
>> >> 8a28 0008 00
>> >> f31a9740 4037054176 C Bo:2:071:
Hi,
>> Here is the fresh usbmon trace. Four SCSI commands are shown. The
>> first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10
>> command has LBA of 0x00ed2900, which is wrong. Somehow, the first
>> SCSI_READ_10 command got the wrong data, i think. Isn't it?
>
> It looks like the dat
Hi,
>>> Thanks. Working on this problem now. Another problem observed for
>>> SCSI_READ_10 command, when reading from the SD card, the gadget driver
>>> never sends the MBR address, the FAT boot record address, the start of FAT
>>> address, and the start of FAT cluster address to the SD card drive
Hi,
>> Thanks. Working on this problem now. Another problem observed for
>> SCSI_READ_10 command, when reading from the SD card, the gadget driver
>> never sends the MBR address, the FAT boot record address, the start of FAT
>> address, and the start of FAT cluster address to the SD card driver.
>
Hi,
>> f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010
>> 8a28 0008 00
>> f59e13c0 3246885582 C Bo:2:046:1 0 31 >
>> f59e15c0 3246885594 S Bi:2:046:1 -115 4096 <
>> f59e15c0 3247150217 C Bi:2:046:1 -75 0
>
> This is the problem. -75 is -EOVERFLO
Hi,
>> Here is the gadget log when receiving SCSI_READ_10 from Linux host.
>>
>> g_file_storage gadget: bulk-out, length 31:
>> : 55 53 42 43 0f 00 00 00 00 10 00 00 80 00 0a 28
>> 0010: 00 00 00 00 00 00 00 08 00 00 00 00 e0 f8 02
>> SCSI CDB: 28 00 00 00 00 00 00 00 08 00
>> g_file_s
Hi,
>> Understand, UDC driver will call driver->setup(), and if the return
>> value is negative, UDC driver has to set dev->protocol_stall = 1 and
>> maybe call usb_ep_set_halt(). However, the hardware won't be able to
>> send out zero length response.
>
> Don't be silly; of course it can. Nobody
Hi,
>> >> ok, i will add code to UDC to instruct hardware to send NAK upon
>> >> receiving invalid request on endpoint 0. Does it mean that UDC driver
>> >> has to check for invalid request on endpoint 0?
>> >
>> > No. The UDC driver has no way to know whether a request is valid or
>> > not. Rea
Hi,
>> >> In the log file, is there any invalid request received on endpoint 0?
>> >
>> > In the usbmon file there is. It is this line:
>> >
>> >> f4ae6f40 1217192721 S Co:2:018:0 s 21 ff 0
>>
>> ok, i will add code to UDC to instruct hardware to send NAK upon
>> receiving invalid
Hi,
>> I do not know when to set the Halt feature for the bulk-in endpoint. I
>> see gadget code have this line printed out:
>> g_file_storage gadget: bulk-in set halt
>
> The UDC driver is supposed to set the Halt feature when the set_halt()
> routine in the usb_ep_ops table is called with a nonz
Hi,
>> I have a serial console to access the platform. Today i use Linux as
>> USB host. The log of the usb gadget is attached (gadget-log.txt).
>>
>> The Linux usbmon log file is also attached (usbmon-log.txt). Hopefully
>> the log data will be useful.
>
> It looks like you cut out a lot of infor
Hi,
>> > First you have to figure out why it isn't working. What does the
>> > debugging information show?
>>
>> Here is some debugging information:
>>
>> receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20
>> receive SET_CONFIGURATION, 0, 9 index 0 value 1 len 0
>> set curlun->unit_attention_
Hi,
On Wed, Mar 20, 2013 at 10:22 PM, Alan Stern wrote:
> On Wed, 20 Mar 2013, victor yeo wrote:
>
>> Thanks, i add processing the pending data from FIFO after queue was
>> called. The UDC driver can process the SCSI INQUIRY command and SCSI
>> READ FORMAT CAPACITIES c
Hi,
On Sat, Mar 16, 2013 at 1:49 AM, Felipe Balbi wrote:
> On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote:
>> On Fri, 15 Mar 2013, Felipe Balbi wrote:
>>
>> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote:
>> > > Hi,
>> >
Hi,
> On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote:
>> For bulk transfer, the new UDC driver has one problem. When SCSI
>> Inquiry command is received, the UDC driver interrupt routine will
>> receive it first. However, the queue function is not yet called, a
Hi,
For bulk transfer, the new UDC driver has one problem. When SCSI
Inquiry command is received, the UDC driver interrupt routine will
receive it first. However, the queue function is not yet called, and
queue buffer is not yet added. Thus, interrupt routine is not able to
store the SCSI Inquiry
Hi,
>> Thanks, i added in UDC driver to call bulk_in_complete for every
>> request over a bulk in ep, now the gadget driver is able to process
>> the SCSI Inquiry command. When it comes to SCSI Read Format Capacities
>> command, the gadget driver gives attention condition error in
>> check_command
Hi,
>>> Thanks, i added in UDC driver to call bulk_in_complete for every
>>> request over a bulk in ep, now the gadget driver is able to process
>>
>> UDC shouldn't call bulk_in_complete() directly, you should be calling
>> request->complete() instead.
>>
>
> Yes, the UDC driver calls the request-
Hi,
>> >> How to set "bh->state" to BUF_STATE_EMPTY after the buffer is processed?
>> >
>> > It gets set to BUF_STATE_EMPTY in several different places, depending
>> > on the purpose the buffer was used for. See bulk_in_complete (your UDC
>> > driver should call this routine for every request ove
Hi,
>> How to set "bh->state" to BUF_STATE_EMPTY after the buffer is processed?
>
> It gets set to BUF_STATE_EMPTY in several different places, depending
> on the purpose the buffer was used for. See bulk_in_complete (your UDC
> driver should call this routine for every request over a bulk-IN
> e
Hi,
>> I put printk in fsg_main_thread. After insmod g_file_storage, the
>> fsg_main_thread goes to fsg->running. Then it sleeps.
>
> Do you mean that it executes these lines?
>
> if (!fsg->running) {
> sleep_thread(fsg);
> continue;
Hi,
>> i have list_add_tail() in my ep_queue() function. Prior to ep1
>> receiving data, my ep_queue() is called to send 0x00 to ep0. then it
>> is not called. how to make it to be called by file gadget, in order to
>> queue the request before ep1 interrupt?
>
> This should happen when get_next_co
Hi,
>> When ep1 receives CBW data, the isr routine is called. Then in isr, to
>> get the usb_request:
>>
>> usb_request * req;
>> req = list_entry(dev->ep[2].queue.next, struct kagen2_request, queue);
>>
>> however, the list_empty(&dev->ep[2].queue) is true. Where is the
>> appropriate place to ad
Hi,
>> In the udc driver, i can't assign a single ep0 descriptor to both
>> ep0_in_desc and ep0_out_desc. i think i should skip ep0_out_desc. Bear
>> in mind that i only define 3 endpoints in udc driver: ep0, ep1 bulk
>> in, ep1 bulk out. Will it cause any problem to gadget driver?
>
> There is no
Hi,
>> i do not see where req->length is checked in gadget
>> driver.
>
> It isn't _checked_; it is _set_ in set_bulk_out_req_length().
> req->actual is checked in received_cbw().
>
>> g_file_storage gadget: ep0-setup, length 8:
>> : 00 09 01 00 00 00 00 00
>> g_file_storage gadget: set co
Hi,
>> >> is it this code? i will remove the redundant code after complete.
>> >>
>> >> ka_ep_p->req.complete(&ka_ep_p->ep, &req->req);
>> >> if (num == 0) {
>> >> ka_ep_p->req.length = 0;
>> >> usb_ep_queue(&ka_ep_p->ep, &req->req, 0);
>> >>
Hi,
>> >> > Also, you shouldn't requeue the request yourself, gadget driver owns the
>> >> > request.
>> >> which request do i requeue? please kindly point that out. Thanks!
>> >
>> > look at your code. Look what you do after you call complete.
>>
>> is it this code? i will remove the redundant co
Hi,
>> > you should an interrupt handler to handle interrupts from your device.
>> > Also, there are way too many mistakes on your driver, run checkpatch.pl,
>> > compile it with sparse, don't hardcode addresses, don't reimplement a
>> > bunch of infrastructure the kernel already gives you and ch
Hi,
>> >> Here are the last two setup data and CBW data received. the
>> >> get_next_command() is not called when CBW data is received. the
>> >> bulk_out_complete() wakes up the thread, however, get_next_command()
>> >> still sleeps. i do not see where req->length is checked in gadget
>> >> drive
Hi,
>> Here are the last two setup data and CBW data received. the
>> get_next_command() is not called when CBW data is received. the
>> bulk_out_complete() wakes up the thread, however, get_next_command()
>> still sleeps. i do not see where req->length is checked in gadget
>> driver.
>>
>> g_file
Hi,
>> >> In my udc driver, i set the req->length to the number of bytes i
>> >> received from HW, which is 31 bytes. Is it necessary to do that? How
>> >
>> > you shouldn't touch req->lenght, you should only update req->actual.
>> > req->length is readonly for the UDC.
>> >
>> >> to know the gadg
Hi,
>> >> Ok. In the gadget driver, it keeps on receiving the same bulk_out
>> >> data, maybe because the data is not processed. The get_next_command is
>> >> not called.
>> >>
>> >> g_file_storage gadget: bulk-out, length 31:
>> >> : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12
>> >> 0
Hi,
>> >> In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and
>> >> intr_in. Why is the intr_out endpoint not defined?
>> >
>> > because it's not needed. Read the USB Mass Storage Class specification
>> > from usb.org
>>
>> Ok. In the gadget driver, it keeps on receiving the same bulk
1 - 100 of 116 matches
Mail list logo
