jamesh wrote:Unfortunately it's a less than efficient driver, as provided by the chip supplier.
Never put yourselves at the mercy of closed software. It always bites you eventually.dom wrote:(My knowledge on this is pretty limited. We bought in a block of hardware and got with it the dwc_otg linux driver. No one at Broadcom knows in detail how it works.)
The dwc_otg driver is many things but it isn't closed. The source is here and here. Though reading what has been written it is probably fair to say nobody really understands it well enough to rewrite it without additional documentation.Morgaine wrote: Never put yourselves at the mercy of closed software. It always bites you eventually.
This is a problem with a lot of FLOSS. While the source code is there, it can be hard to do anything with it without a lot of exploration, detective work, and reverse engineering. It often seems easier (and more fun) to write something new rather than adapt something that exists.
Yep, I agree fully there. Without reasonable documentation on hardware APIs, it's in the lap of the gods how good FOSS code can ever be, even with very dedicated and competent reverse-engineering effort. You simply cannot guess with any high degree of certainty what low-level operations are actually doing even when you see them happening before your very eyes with debug equipment.reggie wrote:I think that's the issue here isn't it though? Lack of proper documentation, ...
Th problem, however, is that the experts appear very unlikely to solve these issues, at least not by taking the vendor-supplied buggy-as-hell drivers as a starting point. It's almost evident that this is the case, given that the dwc drivers have been out there for a couple of years or more, and they are still, not to put a fine a point on it, broken.obarthelemy wrote:I think the idea is that experts will solve these issues for them. Once the faulty drivers are fixed, nobody needs to worry about them anymore, except people who actually want to ^^