Re: Removing duplication in /boot - affects kernel development
On Wed, Sep 5, 2012 at 3:46 PM, Daniel Drake wrote: > Hi, > > I'd like to renew this thread, since we didn't get a great amount of > feedback last time. Also, one of the issues mentioned (but a little > downplayed) is the significance of removing the firmware updating code > from olpc.fth. Having stale code duplicated from the firmware in > olpc.fth bit us today with XO-4 development; the approach implemented > below would have avoided this problem. It would be nice if we could > land this before it bites again. > > So, CCing various kernel developers, as this does affect kernel > development patterns a little. Will anyone be upset by the changes > proposed here? Thanks for the feedback. I've gone ahead and made this change for the next 13.1.0 build: x86-3.3 and arm-3.0-wip include the new olpc.fth, olpc-os-builder only ships the zipped kernel/initramfs variant (either signed or unsigned), and olpc-utils now includes olpc-dev-kernel as described (plus Paul's earlier suggestion). Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Backporting 3.6 USB/EHCI fixes for XO-1
On Mon, Sep 10, 2012 at 6:54 PM, Daniel Drake wrote: > Anyway, a load of work landed in Linux 3.6 to address this, to make > the EHCI driver more resilient to odd hardware. Backporting to 3.3 is > very simple, and fixes the problem. The commits in question are: +1, though IANAKD so dilute it appropriately... m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Backporting 3.6 USB/EHCI fixes for XO-1
Hi, Kevin Gordon showed me a case of a USB microscope (UVC) not working on XO-1. It confuses the host controller and even knocks the wifi off the bus. On XO-1.5 and XO-1.75 it is fine. These microscopes are used in the field (e.g. http://ntugigroup.org/) We're not alone with this class of problem; in other cases, hardware oddities (in the host controller) have been shown to be the cause. Anyway, a load of work landed in Linux 3.6 to address this, to make the EHCI driver more resilient to odd hardware. Backporting to 3.3 is very simple, and fixes the problem. The commits in question are: USB: EHCI: resolve some unlikely races USB: EHCI: fix up locking USB: EHCI: initialize data before resetting hardware USB: EHCI: simplify isochronous scanning USB: EHCI: use hrtimer for the I/O watchdog USB: EHCI: always scan each interrupt QH USB: ehci-sched.c: remove dbg() usage USB: EHCI: don't lose events during a scan USB: EHCI: use hrtimer for unlinking empty async QHs USB: EHCI: unlink multiple async QHs together USB: EHCI: use hrtimer for the IAA watchdog USB: EHCI: don't refcount iso_stream structures USB: EHCI: use hrtimer for (s)iTD deallocation USB: EHCI: use hrtimer for controller death USB: EHCI: use hrtimer for interrupt QH unlink USB: EHCI: use hrtimer for async schedule USB: EHCI: remove PS3 status polling USB: EHCI: return void instead of 0 USB: EHCI: use hrtimer for the periodic schedule USB: EHCI: introduce high-res timer USB: EHCI: add new root-hub state: STOPPING USB: EHCI: add pointer to end of async-unlink list USB: EHCI: rename "reclaim" USB: EHCI: add symbolic constants for QHs USB: EHCI: don't refcount QHs USB: EHCI: remove unneeded suspend/resume code USB: EHCI: initialize data before resetting hardware USB: fix PS3 EHCI systems USB: EHCI: fix command register configuration lost problem USB: EHCI: improve full-speed isochronous scheduling routine EHCI: maintain the ehci->command value properly EHCI: keep track of ports being resumed and indicate in hub_status_data EHCI: don't try to clear the IAAD bit 10 files changed, 1123 insertions(+), 967 deletions(-) I'm proposing backporting this to 3.3 for the 13.1.0 release (affecting XO-1 and XO-1.5). I feel comfortable about it; this all landed in 3.6-rc1 and hasn't needed followup in the form of later fixes, we generally get a good amount of external device testing (I'm sure Kevin will test a gazillion devices as well), and if it presents problems which don't have obvious fixes we can revert. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel