> > I was discussing USB master chips with Steve a while back (trying to
avoid
> > the ghastly cache shattering 1KHz interrupt-to-do-nothing overhead that
the
> This isn't much of an issue for me, since I typically have
> the USB on for a few minutes every week - but it would be
> good to fix. [I've not (fully) read the docs for this chip
> - but is it really that bad - philips generally have a
> little more clue than that..]
This seems to be a common requirement of usb masters. In the multi-gigahz PC
arena it isn't a big deal so OHCI/UHCI just implements it and expects to
have to service things that fast.
I tried doing USB networking and DVD browsing on Philips master chip. This
caused the chip/driver to lockup. I can cope with retries but lockups are
not nice.
Philips .. yes, I would have hoped that it wasn't this bad. SW said it was
probably just rubbish drivers and DB concurred. However it does seem to be
true. The data sheet quite explicitly says that if you miss an interrupt
(when they are enabled) then the chip locks up and needs resetting - ouch.
>
> > There are linux drivers (2.4) for both (I think) and the Transdimension
> > permitted theirs to be shipped with the GPL sources for the Cerf board.
> > However, the Copyright messages in the drivers do not mention GPL so i
am
> > unclear of the legals.
> I'm unclear about non GPL code in the kernel, what are the
> implications of this.
Binary only drivers are legal only if they don't include any GPL executable
code - constants are fine. My understanding is that if a #include-ed GPL
header (as opposed to LGPL) has an inline macro then in principle the whole
code must be GPL. of course, without the source this is largely unprovable.
I hate stuff I cannot compile. It is wrong all too often anyway and a change
in an implementation detail (eg cpld bit change) makes it all die.
Personally I wouldn't want to have anything I hadn't got source for. Imagine
the problems of adding a PXA chip .. kernel drivers need to be PXA optimised
(I think) so one binary may not even work properly.
> I don't care so long as
>
> 1) it works as well as the existing chip.
Agreed.
> 2) i can (still) power up and down the the USB ports
Agreed.
> 3) it's supported in 2.4, I have a whole bunch of drivers
> esp. block drivers, and I don't want to have my
> 2.4->2.6 migration forced by hardware in both
> directions.
Agreed.
Ok, I'll do some investigation tomorrow.
Nick
>
> J.
> ====================================================
> The information in this email and in any attachments is confidential
> and intended solely for the attention and use of the named addressee(s).
> This information may be protected by work product immunity or other
> legal rules. It must not be disclosed to any person without our
> authority.
> If you are not the intended recipient, or a person responsible for
> delivering it to the intended recipient, you are not authorised to and
> must not disclose, copy, distribute, or retain this message or any part
> of it.
>
> _______________________________________________
> Balloon mailing list
> Balloon@balloonboard.org
> http://balloonboard.org/mailman/listinfo/balloon
(text/plain)