[RFC PATCH] Very minimal bcm2708 support for linux-next

[Stephen Warren]

On 05/30/2012 05:12 AM, Simon Arlott wrote:
> On Wed, May 30, 2012 04:45, Stephen Warren wrote:
>> (RFC - not for commit yet)
> 
> Have you looked at the rpi01-mach, rpi02-plat and rpi03-extra branches?
> 
> They have everything in separate commits and they're roughly ready for
> mainline (there's no documentation on DT yet). Everything going into
> rpi-linear is also merged as a fixup to the commits in those branches.

No, I haven't explored all the various branches at all. Is there any
kind of information out there that enumerates what repos and branches
exist and what they're intended for?

> It also has a working frame buffer and there's no reason to leave this
> out of any submission to mainline.

The issue isn't so much that it should be left out, but more that it
might be one of the more difficult things to upstream, and shouldn't
block anything else.

One issue is that any features that exist only to support binary-only
user-space components are generally not acceptable upstream. Something
like a simple frame-buffer driver that provides standalone FB and KMS
services to the kernel would probably be fine. Features to support an
open-source X driver or even GL driver would most likely be fine too.

> Is there any reason not to commit the final .dts files in the initial
> patch rather than adding them in with other patches?

Anything that gets put into the upstream .dtsi/.dts file really needs
the relevant binding(s) to be fully documented either before that, or in
the same patch. Upstreaming the whole .dtsi file at once would therefore
require waiting until all the bindings were fully reviewed, which might
take quite a while; the more complex stuff would block the simpler
stuff. Conversely, starting out with a very simple .dtsi file, and
adding chunks to it incrementally as the relevant drivers and bindings
are reviewed will allow features to be streamed in as fast as practical,
yet without being blocked by unrelated stuff.

>> TO DO:
...
>> * Remove mem and bootargs values once the bootloader is enhanced to fill
>>   these in.
> 
> These are not required. If not using the future bootloader, ftdput can be
> used to set up those values. Memory is not fixed (256MB below is invalid as
> the GPU requires some memory).

I assume you mean that those properties could be removed right now, and
manually inserted as a post-build step using fdtput.