Architecture Code

[Alan-Cox]

This will need splitting up - eg big chunks of it are for the USB driver and that is probably a "no hope" item in itself.

1. Platform code references stuff that doesn't seem PI relevant or included (eg touchscreen)
2. Minor style stuff - usual plus strip out LINUX_VERSION_CODE checks when upstreaming
3. DMA manager - you assume there is only one, so you should check that in bcm_dmaman_probe()
4. General - bound to get asked if you can not use devicetree for all the device and IRQ description rather than yet more platform files.
5. Some bits (eg pcm_power) need a fairly serious revisit and exposing via the properly kernel power interfaces eventually. Also lose the semaphores for mutexes as they are not counting. Otherwise you muck up real time.
6. vc_mem.c - LOG_xxx crap - and in general a nop hoper that needs major work (so again best split out)
7. MMC - split this off because it needs major work to get anywhere upstream and probably to be done in small steps beginning with PIO. For MMC I think a lot of it may well look better as of 3.2 because MMC/SDHC now has a proper power infrastructure

For this I think you've got a good chance of getting the various quirks, basic board bits upstream easily. A lot of the other more driver-ish stuff is going to need stuff addressing.

[Alan-Cox]

Oh a ps vc_ is the symbol space used for the virtual console code so you want to move from vc_ to something else (bcmvc_ etc) [yes C sucks]

[asb]

Regarding USB: APM have been trying to get the driver upstream but as you suggest, it's not looking hopeful http://thread.gmane.org/gmane.linux.usb.general/53348

[Alan-Cox]

There is a whole pile of stuff going on here, although I'm not entirely sure where the APM driver stuff went as it seems it was never submitted for staging as requested. Various vendors and groups of people are involved in trying to produce a single decent, clean, multi-arch upstream OTG core for these IP blocks, because they are all using them. It might be a good thing to worry about later on in any merge if the ugly driver works for now.

Alan

[sjenning]

I was looking at the dwc3 driver (drivers/usb/dwc3), and I think that the USB driver for the RPi's use can be drastically simplified. Afaik, the RPi just uses the Synopsis Designware USB2.0 OTG in host mode only. If that is the case you can just make a ECHI HCD wrapper for it, yes?

[sjenning]

Also, Alan, do you know if new ARM stuff is going to need to use Device Tree?

[Alan-Cox]

Device tree is a yes

The Designware USB is an ongoing mess (there are several variant drivers for it already most differing on the power handling side and they range from ARM to X86 devices). It's now at the point people are actively thinking about getting the mess sorted by turning it into one properly written driver but that will take a bit of time.

Certainly a wrapper might be a good initial integration approach until that is done.

[nomis]

I'm working on reorganising the code into a device tree implementation for the base devices as I now have it booting a serial console only rebased against 3.4.

[nomis]

The usb driver is writing to freed memory: http://s85.org/aygDp9tm:view