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

[Simon Arlott]

On 31/05/12 02:25, Stephen Warren wrote:
> 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?

The first one is just adding the machine. It happens to provide a
working serial console because the UART is already supported.

The second one is all the platform device drivers.

The third one is for independent changes to existing drivers (the pl011
driver needs to claim the pins from pinctrl when the device is in use).

>> 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.

Unfortunately I think there will never be an open source GL driver, it
all appears to be layered on top of proprietary userspace libraries.

>> 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.

Ok, but this was getting very complex to maintain because the
overlapping device commits cause many conflicts.

>>> 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.

Yes, I don't see any benefit in hard coding them. The bootloader will
most likely gain DT support before a kernel is released with support
for the hardware.

-- 
Simon Arlott