Hi,
Vincent Pelletier <plr.vincent@xxxxxxxxx> writes:
> Hello,
>
> On Tue, Jan 24, 2017 at 12:20 AM, Felipe Balbi
> <felipe.balbi@xxxxxxxxxxxxxxx> wrote:
>> Seems like HW engineer wanted these last few endpoints to *not* support
>> full USB3 packets. They are probably supposed to be used for Isochronous
>> and/or Interrupts endpoints. At some point we need to support this as
>> well. During initialization we should read FIFO size configuration and
>> extract wMaxPacketSize for $endpoint from the HW.
>
> If my understanding of your register explanation is correct, the >9 IN
> endpoints could still work as bulk in LS/FS speeds (I don't have the
> board at hand to try right now). If this is correct, won't your patch
> (in your testing/next branch) make these endpoints unusable for bulk
> use even in LS/FS ?
that's correct. Maybe I should always set bulk capability. Thanks for
catching that, I'll send v2 shortly.
> A bit more generally, I have the feeling (from reading epautoconf.c
> and f_fs.c) that the endpoint dispatching (and hence, endpoint
> capabilities) lacks the notion of speed (SS has it, kind of, via the
> companion descriptor argument in epautoconf.c). I noticed something a
> few weeks back which may come from this lack: when I tried only
> populating the HS descriptors, the host xHCI would complain about
> non-standard endpoint size (64B instead of HS-required 512B). In my
> understanding, this is because f_fs.c allocates endpoints using the
> first populated descriptor set (in LS/FS, then HS, then SS order), and
> epautoconf.c overwriting the buffer size to 64 on non-SS bulk
> descriptors.
yeah, order matters. That's documented for f_fs.
> I think extending such API is over my head still. Do you have ideas on
> this ?
Well, we can't easily change the way it works because it's an ABI to
userspace. I would have very much preferred for us to pass descriptors
using ioctl(). That way we could have:
ioctl(fd, FFS_IOCTL_SS_EP_DESC, ep1_ss_desc);
ioctl(fd, FFS_IOCTL_SS_EP_COMP_DESC, ep1_ss_comp_desc);
and so on.
> FWIW, the Intel Edison (the board I'm using as device) is not USB 3
> capable despite dwc3 usage. If my undrstanding is correct, it is
> because it lacks the USB 3 companion phy, and of course does not
right
> expose the corresponding tracks on the expansion connector (would it
> be possible to host the companion outside the edison module ? I have
> no idea how it is supposed to interract with the dwc3 and USB 2 phy).
I'm pretty sure PIPE3 interface doesn't go outside the SoC, so no.
One thing you _can_ try, however, is to pass maximum-speed property to
tell dwc3 you wanna run in high-speed, not super.
--
balbi
Attachment:
signature.asc
Description: PGP signature
