4.10-rc3 rpi issues

[Michael Zoran]

On Fri, 2017-01-13 at 21:44 +0100, Stefan Wahren wrote:
> Hi Michael,
> 
> > Michael Zoran <mzoran at crowfest.net> hat am 12. Januar 2017 um 01:26
> > geschrieben:
> > 
> > 
> > On Wed, 2017-01-11 at 23:22 +0100, Stefan Wahren wrote:
> > > Hi Michael,
> > > 
> > > > Michael Zoran <mzoran at crowfest.net> hat am 11. Januar 2017 um
> > > > 22:38
> > > > geschrieben:
> > > > 
> > > > 
> > > > On Wed, 2017-01-11 at 16:46 +0000, Peter Robinson wrote:
> > > > > On Wed, Jan 11, 2017 at 2:29 PM, Gerd Hoffmann <kraxel at redhat
> > > > > .com
> > > > > > 
> > > > 
> > > > I'm actually surprised that somebody hasn't tried to upstream
> > > > the
> > > > downstream USB driver which has less limitations.  The DWC USB
> > > > controller is not Broadcom specific so it would apply to more
> > > > then
> > > > the
> > > > RPI.  I would be interested in helping with such an effort and
> > > > it
> > > > may
> > > > even be possibly to write the driver from "scratch".  The
> > > > hardest
> > > > part
> > > > would be getting something like a PI Zero that doesn't have the
> > > > USB
> > > > hub
> > > > soldered onto the board so that it's easy to attach a USB bus
> > > > analyzer
> > > > for better debugging.
> > > 
> > > This isn't a surprise. A new driver for a platform which is
> > > already
> > > supported by a mainline driver won't be accepted. Maybe the dwc2
> > > driver would have a better quality for bcm2835 if the Foundation
> > > would use it instead of the separate downstream driver. Instead
> > > of
> > > adding new driver it would be better to fix the existing one.
> > 
> > The two drivers have a different architecture.  The upstream driver
> > submits all the I/O to the hardware at once and relies on the
> > hardware
> > sorting it out.  When the fixed number of slots are used, it just
> > breaks.
> > 
> > The downstream driver attempts to schedule the I/O in software and
> > submit it to the hardware piecemeal.
> 
> do you mean the microframe scheduler which is also available in dwc2
> but disabled for bcm2835?

Very interesting... I didn't know about that feature. Is it disabled on
bcm2835 because some hardware functionality was intentionally disabled
for marketing reasons?

What I was referring to was the FIQ based scheduler in dwc_otg that
submits periodic transfers to the hardware one at a time.  I thought
the upstream dwc2 driver submits then all at once and relies on the
hardware scheduling them.

Perhaps I'm being too undiplomatic about this.  Perhaps it might be
possible to somehow include the functionality of dwc_otg into the dwc2
driver?

What I was thinking is that perhaps an improved driver could rely on
the hardware until all the hardware slots are full.  When then happens,
shift to the dwc_otg style of using the ARM processor to do the
scheduling.  That way you can take full advantage of the hardware when
a small number of devices are attached, but fall back to the software
under "heavy loads" for correctness and reliability.

BTW, I think the reason a new driver was written in the downstream tree
rather then improving the old one was because it was perceived to be
too hard to add this functionality and still support both host and
device modes.