Moiz,
On 04/15/2011 10:08 PM, ext Sonasath, Moiz wrote:
Roger,
On Tue, Apr 12, 2011 at 12:18 AM, Roger Quadros<roger.quadros@xxxxxxxxx> wrote:
Hi,
On 04/11/2011 07:11 PM, ext Alan Stern wrote:
On Mon, 11 Apr 2011, Roger Quadros wrote:
On 04/06/2011 10:11 PM, ext Alan Stern wrote:
On Wed, 6 Apr 2011, Sonasath, Moiz wrote:
All,
I am working on android kernel based on K35, and I see these bunch of
device configure failures. Any pointers would really help.
Which gadget driver are you using?
Have you enabled verbose debugging in the gadget driver?
I've kind of come to realize why this is happening.
It is a timing related issue. MSC tests issues two set configurations and
set
interface (alt 0) and immediately follow with a CBW.
In the current composite framework + f_mass_storage setup, the actual
enabling
and disabling of endpoints is done in a background thread, while the
setup
requests are allowed to complete through composite.c.
(notice that DELAYED_RESPONSE is not correctly implemented here as in
file_storage.c)
I meant DELAYED_STATUS.
The CBW is received by the controller but due to large latency in
scheduling the
thread to process the CONFIG_STATE_CHANGE state, the endpoints get reset
after
the CBW is received, instead of before, thus loosing the CBW.
That certainly would explain the problem.
Can you come up with a patch for implemented DELAYED_RESPONSE properly
in the composite framework? And maybe give it a name more suitable for
public use, like USB_GADGET_DELAYED_RESPONSE?
Yes, I'll try to come up with something.
Any luck on this one? Any pointers on solving this one would really
help. I tried a few things but no luck.
I was busy with other things last week. I did play with a few things though.
Don't have a fully working solution yet.
I don't see the DELAYED_STATUS mechanism fitting well with the composite
framework, because, for control transfers like SET_CONFIG, the composite
framework is responsible for the status phase, unlike in file_storage.c where it
is responsible for everything.
One way to make it work would be to split the endpoint resetting mechanism and
the FSG state machine's reset mechanism. Currently both are done in
handle_exception.
We could do the endpoint resetting synchronously in fsg_set_alt() and
fs_disable() and leave the state machine resetting to be done in the thread
(handle_exception) at leisure. This way we can ensure that we don't reset the
endpoints again midway when the thread schedules.
I will be working on it this week.
--
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
