Alan,
On Fri, Jan 22, 2016 at 11:48 AM, Alan Stern <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
