ARM: bcm2708: overlay to set cma to 128M@128M

[msperl]

Added overlay to set cma-boot parameter to 128M@128M.

This may be most helpful for system with 512MB when running vc4-kms

Signed-off-by: Martin Sperl [email protected]

[popcornmix]

@pelwell I guess we should support arbitrary cma settings as dt parameters (which may require firmware changes).

[pelwell]

String manipulation would require firmware changes, but there is a new mechanism in the most recent firmware releases (kernel 4.1.21 - dea25fa - and later). An overlay can include both active and inactive fragments - an inactive fragment has a __dormant__ node where an active one would have __overlay__. There is a new syntax to control the activation of fragments that I've called "overlay" overrides, because they don't just modify a single property.

Recall that a DT parameter declaration is a sequence of <phandle>, "<property-name><options>" pairs. Overlay overrides are indicated with a phandle of zero, and a string containing a list of directives. So far the directives all control the activation of fragments:

+n  Activate fragment n
-n  Dectivate fragment n
=n  Activate fragment n if the parameter value is true (on, yes, etc.),
    otherwise deactivate it
!n  Activate fragment n if the parameter value is false (off, no, etc.),
    otherwise deactivate it

For example:

fragment@0 {
    target-path = "/chosen";
    __overlay__ {
        bootargs = "cma=256M@256M";
    };
};

fragment@1 {
    target-path = "/chosen";
    __dormant__ {
        bootargs = "cma=128M@128M";
    };
};

__overrides__ {
    cma_256_256 = <0>, "+0-1";
    cma_128_128 = <0>, "+1-0";
};

Here the parameter values are ignored, but the i2c-rtc overlay could be rewritten this way with each RTC declaration in its own fragment and using:

// fragment 1 = ds1307
// fragment 2 = ds1339
// fragment 3 = ds3231
// fragment 4 = pcf2127

ds1307 = <0>,"=1!2!3";
ds1339 = <0>,"=2!1!3";
ds1339 = <0>,"=3!1!2";
pcf2127 = <0>,"=4";
...

and

dtoverlay=i2c-rtc,ds1307=on,ds1339=off,pcf2127=off

The usage here is slightly contrived because you don't need to allow the explicit offs, but the negation has allowed us to marek the three DS RTCs as being mutually exclusive (they all use address 0x68).

Although this structure would make the i2c-rtc overlay file larger, because inactive fragments aren't merged the resulting DTB is smaller and cleaner.

Old firmware will automatically ignore __dormant__ fragments, and the zero phandle will be treated as the end of the parameter declaration, so provided you don't put property overrides after overlay overrides in the same parameter declaration and you choose the default activation states to be sensible then adding this new syntax should be harmless to users who haven't upgraded.

[msperl]

I will leave it up to you - in principle it is a problem during migration, as I assume that when we have completely switched to kms then these settings will go into the board-specific dts...

I will leave it as is and up to you to decide how you want to manage this in the meantime.

[pelwell]

On the subject of changes in DT parameter handling, I've also recently removed the restriction that integer parameters may not create or extend and existing property.

[pelwell]

I'll create a new PR with vc4-kms-v3d parameters for a few CMA positions and sizes, to give people a chance to comment.

[pelwell]

New pull request at #1434.

[pelwell]

Superseded by #1434, which is now merged.