Raspberry Pi Upstreaming

Lee Jones lee.jones at linaro.org
Wed Oct 22 09:46:02 PDT 2014


On Thu, 16 Oct 2014, Stephen Warren wrote:
> On 10/16/2014 06:02 AM, Lee Jones wrote:
> > So, I'm interested in helping out with the Raspberry Pi Kernel
> > Upstreaming effort.  I found [1], but there isn't any information on
> > the critical stuff; mainlining status, who's working on what,
> > outstanding tasks, etc.
> 
> The primary missing features are anything that relies on the VC
> (VideoCore) firmware, i.e.:
> 
> * Clocks
> * Display (except via simplefb)
> * Graphics
> * VC firmware mailbox/... driver, as support for the above.
> 
> Things like SD card (faster transfer modes or timing tweakings) or USB
> might need some tweaking.
> 
> I don't know of anyone working on those (except DWC2 USB which Synopsys
> is now actively contributing to). I had hoped that by getting something
> running in the mainline kernel, the RPi Foundation would come along and
> finish the job. However, I that hasn't happened unfortunately.

Okay, so I've been poking my nose around and managed to kludge some
information together.  I've taken the liberty of moving all
information I found at [1], which was really regarding booting an
upstream kernel rather than upstreaming RPi code to [2] which was out
of date.  There is a small band of merry men (emphasis on the merry)
who are working on various upstreaming tasks.  A few of them/us hang
around in the newly created #raspberrypi-kernel if anyone else would
like to join/contribute.

> I've personally deliberately avoided coding anything up that relies on
> the firmware interface. I'm not sure if the interface to firmware is
> guaranteed to be an ABI. The documented messages don't tell the whole
> story; someone with more knowledge of the firmware/chip would be needed
> to correctly model the parent/child links in the clock tree for example.
> I had hoped that someone would complete the VC reverse-engineering
> effort (or make use of the headers published along with the graphics
> source code) and write either open firmware or Linux-hosted drivers.

After some discussion with the Raspberry Pi people, it appears that the
Firmware Maintainer is extremely keen on backwards compatibility.  It
is my feeling that we can rely on him to keep it as ABI as it needs to
be.

There are 2 large hurdles to face, which actually become 1 hurdle only
yesterday when Linus finally pulled in the Mailbox FW.  The VCHIQ
driver(s) are pretty large and complex.  It is understood that if we
tried to upstream it, there would be a huge push for us to convert it
to rpmsg, despite the fact that it'll be slower (higher latency) than
the current VCHIQ code.

Beside that things are moving along nicely.  We have some drivers
which will be on the list shortly.  They will almost certainly
require a few submission iterations, but at least they'll be out on
the list attracting attention.

> > Is there a Wiki with more information on this?
> > How about an IRC channel that we can talk on informally?
> 
> I am on #armlinux, although mostly during work time when I shouldn't be
> discussing RPi stuff.

I tried to contact you at various times of the day and via a couple of
different mediums, but to no avail.  I guess email will have to
suffice.

> To be honest, I haven't been using my Pi much recently. If you have the
> motivation to take over as Pi maintainer, or simply start sorting out
> the best approach to VC firmware and pushing on the layers above that,
> I'd be OK with that.

If you've lost interest, I'd be happy to take the torch no problem.
If you'd like to draft an MAINTAINERS patch, I'd be happy to Ack it.

Kind regards,
Lee

[1] http://elinux.org/RPI_Upstreaming
[2] http://elinux.org/RPi_Upstream_Kernel_Compilation

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog



More information about the linux-rpi-kernel mailing list