Alan,

On Fri, Jan 22, 2016 at 11:48 AM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 21 Jan 2016, Doug Anderson wrote:
>
>> This doesn't sound familiar to me, but as far as I know all the
>> official Raspberry Pi kernels use a pretty different dwc2 driver.  See
>> the (non-mainline) code in drivers/usb/host/dwc_otg/ in the Raspberry
>> Pi tree at <https://github.com/raspberrypi/linux.git>.
>
> Ah, thanks for that pointer.  I also found the page at raspberrypi.org
> which describes how to build and install a custom kernel.
>
>> The Raspberry Pi driver and the mainline driver are pretty different
>> (though they have the same heritage).  As far as I remember the
>> Raspberry Pi driver has feature to enable FIQ for helping deal with
>> some of the dwc2 issues.  That gives it a chunk of code that's totally
>> rewritten...
>
> Indeed, dwc_otg is quite different from dwc2.  I found what appears to
> be a bug in the dwc_otg's _hub_info() routine.  (This is the subroutine
> that gets the upstream hub address and port number for devices behind a
> TT.)  It does:
>
>         *port_addr = urb->dev->tt->multi ? urb->dev->ttport : 1;

Hrm.  Yeah, in the mainline driver it looks like we just have:

void dwc2_host_hub_info(struct dwc2_hsotg *hsotg, void *context, int *hub_addr,
                        int *hub_port)
{
        struct urb *urb = context;

        if (urb->dev->tt)
                *hub_addr = urb->dev->tt->hub->devnum;
        else
                *hub_addr = 0;
        *hub_port = urb->dev->ttport;
}


> However, the USB spec says that the SPLIT packet's third byte is
> supposed to contain the port for both single-TT and multi-TT hubs.
> And sure enough, the upstream hub for this non-working device is
> single-TT.  Presumably that explains why the third byte in the SPLIT
> packet was 0x01 rather than 0x04.
>
> The corresponding line in the dwc2_host_hub_info() routine simply does:
>
>         *hub_port = urb->dev->ttport;
>
> Unfortunately, even after I changed the dwc_otg routine the device
> still didn't work.  My bus analyzer isn't on hand today, so I'll have
> to work on it more next week.
>
>> It would be really interesting to see if the patch series I just
>> posted helps you (it fixes lots of problems in the mainline driver
>> with splits), though it might still not be enough on the Raspberry Pi
>> since the CPU clock there is much slower than on my 1.8GHz A12-based
>> system and thus maybe FIQ is a must have there...
>
> Can you tell me how to configure a mainline kernel to work on the
> Raspberry Pi?  There is no arch/arm/configs/bcmrpi_defconfig.

Not offhand.  Again, perhaps someone else on this thread will have
more.  I did do a quick Google search and came up with:

http://elinux.org/RPi_Upstream_Kernel_Compilation

...but the Raspberry Pi I have at home is running some home automation
stuff so I don't want to give that a try.  :-P

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to