On Tue, 22 Oct 2013, Victor Yeo wrote:
> 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 "devic
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
On Fri, 18 Oct 2013, Victor Yeo wrote:
> With your input, i re-do the USBCV test, and put up a table for
> comparison between analyzer log and device log. The comparison result
> is saved as a jpeg file for easy viewing. The analyzer and device log
> are attached as well.
>
> Back to the Set-Conf
On Thu, 17 Oct 2013, Victor Yeo wrote:
> > Here's another experiment you can try. In do_set_config(), just after
> > the "rc = do_set_interface(fsg, -1);" line, add a statement saying
> >
> > INFO(fsg, "fsg->config %d new_config %d\n",
> > fsg->config, new_config);
On Wed, 16 Oct 2013, Victor Yeo wrote:
> 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 e
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
On Mon, 14 Oct 2013, Victor Yeo wrote:
> 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 comple
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
On Fri, 12 Jul 2013, Felipe Balbi wrote:
> On Fri, Jul 12, 2013 at 10:46:48AM -0400, Alan Stern wrote:
> > > You should be naking
> > > those extra requests until you're ready to ack.
> >
> > Well, that's not quite right. Devices cannot NAK new control requests;
> > a NAK is not a valid respon
On Fri, Jul 12, 2013 at 10:46:48AM -0400, Alan Stern wrote:
> > You should be naking
> > those extra requests until you're ready to ack.
>
> Well, that's not quite right. Devices cannot NAK new control requests;
> a NAK is not a valid response to a SETUP packet.
there would be no SETUP request
On Fri, 12 Jul 2013, Felipe Balbi wrote:
> > As can be seen in the gadget driver log below, after Set-Config
> > request is received, another two more requests are received before
> > handle_exception() is called. If there is a way to call
> > handle_exception() immediately after Set-Config reques
On Fri, 12 Jul 2013, Victor Yeo wrote:
> >> Does your gadget really take longer than that to handle the exception?
> > Yes, i think there is a delay before gadget calls the
> > handle_exception() routine. So the problem is before
> > handle_exception() of Set-Config request is called, the next req
On Fri, 12 Jul 2013, Victor Yeo wrote:
> 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
Hi,
On Fri, Jul 12, 2013 at 04:20:04PM +0800, Victor Yeo wrote:
> >> 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 ex
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
On Thu, 11 Jul 2013, Victor Yeo wrote:
> Thanks. The USBCV test has tight timing requirement. Once Set-Config
> request is sent out, USBCV sends out Get-Config request to get the
> config value immediately. At that time, gadget driver has not yet done
> the handle_exception. So Get-Config request
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
On Fri, 5 Jul 2013, Victor Yeo wrote:
> 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
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
On Thu, 4 Jul 2013, Victor Yeo wrote:
> 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
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
On Wed, 3 Jul 2013, Victor Yeo wrote:
> 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
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;
>
On Tue, 2 Jul 2013, Victor Yeo wrote:
> 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
> > <
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 -->
On Tue, 2 Jul 2013, Victor Yeo wrote:
> > This looks like another bug in the UDC driver. It performs the Status
> > stage of the Set-Config request before the gadget driver has finished
> > carrying out the request.
> >
> > Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req()
>
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
On Mon, 1 Jul 2013, Victor Yeo wrote:
> 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 o
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
On Fri, 28 Jun 2013, victor yeo wrote:
> 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 o
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
On Thu, 27 Jun 2013, victor yeo wrote:
> I find some clue. From USB 2.0 Compliance Test Spec, quoted:
>
> "Address State:
> 1. Put the device in the configured state following the procedure below.
> 2. Issue a valid Set Configuration command to the device with
> configuration value zero.
> 3.
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
On Wed, 26 Jun 2013, victor yeo wrote:
> The fsg->state in gadget driver, is used for exception handling. Is
> there any variable to track the USB device state of Figure 9-1 of the
> USB 2.0 Spec? Now the gadget driver does not pass the "USB2.0 CV - Get
> Device Descriptor - Address State test".
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
On Mon, 24 Jun 2013, victor yeo wrote:
> 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_
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
On Mon, 24 Jun 2013, victor yeo wrote:
> 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
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.
On Thu, 20 Jun 2013, victor yeo wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" i
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
On Mon, 17 Jun 2013, victor yeo wrote:
> > I have an important finding. When the problem (SCSI_READ_10 command
> > reads 4096 bytes of data, causing gadget to reset) happens, the PC
> > shows that the gadget is detected as Full-speed device, but gadget
> > reports that it is set to High-speed from
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
>>
On Wed, 12 Jun 2013, victor yeo wrote:
> 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
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
On Tue, 11 Jun 2013, victor yeo wrote:
> Yes, the matching gadget log and usbmon trace are attached in this
> email. From the usbmon trace, the error (-108) is ESHUTDOWN from
> SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10
> command is received twice. First time it is ok, second
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
On Tue, 11 Jun 2013, victor yeo wrote:
> 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
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
On Fri, 7 Jun 2013, victor yeo wrote:
> 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 requ
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
On Wed, 5 Jun 2013, victor yeo wrote:
> 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 t
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
On Tue, 4 Jun 2013, victor yeo wrote:
> > I have no idea what the CV test is doing. If you can get a log from
> > the CV program, that would help.
>
> 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
On Mon, 3 Jun 2013, victor yeo wrote:
> The gadget log when Command Verifier says "Device must support being
> set to Addressed/Configured state" is attached. The log shows get
> device descriptor, get configuration descriptor, and set configuration
> requests are received. I see nothing wrong in
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
On Fri, 31 May 2013, victor yeo wrote:
> 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
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 linux command prompt is froz
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 linux command prompt is frozen. Please see the
> attached UDC driver log. It looks like endp
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
On Wed, 29 May 2013, victor yeo wrote:
> 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 stor
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
On Tue, 28 May 2013, victor yeo wrote:
> Now the UDC driver is working on both Linux and Windows host, meaning
> the read/write operation is ok. I still use the polling method,
> because waiting for interrupt is not reliable.
Why aren't the interrupts reliable? Is this a known erratum for your
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
On Mon, 27 May 2013, victor yeo wrote:
> > I can't say much more without seeing the code. However, you should not
> > need to wait for the hardware to do something -- instead the interrupt
> > handler routine should be called when the hardware is finished.
>
> Yes, it is silly. The hardware inte
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'
On Wed, 22 May 2013, victor yeo wrote:
> 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'
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
On Mon, 20 May 2013, victor yeo wrote:
> 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 b
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
On Thu, 16 May 2013, victor yeo wrote:
> 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 que
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
On Tue, 14 May 2013, victor yeo wrote:
> 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?
>
>
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
On Tue, 14 May 2013, victor yeo wrote:
> 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 thes
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
On Mon, 13 May 2013, victor yeo wrote:
> Thanks, i will enable the CONFIG_PRINTK_TIME. Nonetheless, now the
> gadget driver and UDC driver are able to process some SCSI_WRITE_10
> commands (i ignore the USB reset interrupt in UDC driver). Please see
> the attached usbmon log. Will the log help?
A
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
On Fri, 10 May 2013, victor yeo wrote:
> 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
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
On Thu, 9 May 2013, victor yeo wrote:
> The "BUG: scheduling while atomic" is solved. Need to add extra
> spinlock functions for req->complete() as below:
> spin_unlock(&dev->lock);
> req->complete(ep, req);
> spin_lock(&dev->lock);
Yes, I forgot to
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
On Wed, 8 May 2013, victor yeo wrote:
> >> Is the kagen2_ep_queue function gotten interrupted here? So the
> >> kagen2_ep_queue and interrupt routine need spinlock for
> >> synchronisation?
> >
> > That's right. Interrupts can occur at almost any time (on
> > multiprocessor systems they can occur
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
On Tue, 7 May 2013, victor yeo wrote:
> > 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
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
On Tue, 7 May 2013, victor yeo wrote:
> 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
> >
> >
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
On Wed, 1 May 2013, victor yeo wrote:
> > Why do you expect there to be any data in the hardware FIFO at this
> > point? You said that the hardware will not accept any data if a
> > request is not queued. Well, before this point the request wasn't
> > queued, so there shouldn't be any data.
>
>
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
On Fri, 26 Apr 2013, victor yeo wrote:
> 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 r
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
On Thu, 25 Apr 2013, victor yeo wrote:
> For bulk out endpoint, I code the kagen2_ep_queue() to read the
> packets from the USB hardware, then call bulk_out_complete() via
> req->req.complete. Is this the correct way?
While kagen2_ep_queue() is running, there shouldn't be any packets in
the USB h
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
1 - 100 of 268 matches
Mail list logo
