reserving memory only to enabled features

[amery]

On Fri, 18 May 2012 23:49:26 +0100 David Given sent the following patch to the mailing list:

Attached is a patch which prevents memory being reserved for
framebuffer, G2D and video engine if the relevant bits aren't enabled in
the kernel configuration. This whole area looks very much under
construction, and I've no idea whether this is the right approach or
not, but on my server system this gains me an extra 115MB or so of
usable RAM.

(Incidentally, the G2D area is apparently never reserved. Is that correct?)

http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20120518/d327754f/attachment.bin

[amery]

shouldn't this also be bound to the foo_used thing in script.bin?

[amery]

As I'm not yet sure about this I've created yet another branch, wip/allwinner-v3.0-android-v2/memblock_reserve, please comment.

[davidgiven]

Is script.bin still used in v2? I can't find any calls to sw_cfg_get_int() outside arch/mach-sun4i/core.c, and they're both in the #if 0 block.

If the relevant drivers are disabled, then the symbols ve_start, fb_start and g2d_start etc won't be provided, so hopefully anything that tries to use those reserved areas will cause compilation/module load failure. Unless they have hard-coded addresses, of course.

What's the right way to submit an updated path? Check out the branch, modify, push? (I don't know github.)

[amery]

@davidgiven yes, script.bin is still used, and allwinner uses it in newer SoCs too. see arch/arm/mach-sun4i/include/mach/sys_config.h. About submiting you can either make a "fork" here and issue a "pull request" or mail the patches or upload the patches somewhere.

[hno]

Looks ok to me unless there is hardcoded address constants somewhere.

The conditionals on the global variables should be extended into arch/arm/mach-sun4i/include/mach/system.h and drivers cleaned up to use this making compilation fail early.

MALI driver do have hardcoded constants for memory locations and is handled quite uglly with 64MB MALI region completely hidden from Linux memory map instead of reserved, see sw_core_fixup.

memory map:

0x40000000 Memory start
...
0x43000000 64KB SYS_CONFIG
...
0x44000000 48MB(32+16) VE
....
0x58000000 16MB G2D
0x58000000 16MB Memory? (or configurable G2D size)
0x5a000000 32MB Framebuffer
0x5c000000 64MB MALI, Reserved outside Linux memory map
0x60000000 Memory > 512MB

The change to not reserve G2D memory is most likely a bug. Looks like someone tried to clean things up here and did not bother to fix G2D. Maybe G2D is not used in the product these sources are from?

sw_cfg_get* are used in early boot. script_parser* are used everywhere else. Only the latter handles gpio parameters.
Oh, so that's where the top 64Mb of the first dram module goes! Was wondering.
The G2D unit seems to be a DMA blitter with scaling and colour space conversion; the Disp engine has something similar in its Scaler, although sans DMA?

[davidgiven]

Ah, I see. Okay, I'll update to use #if defined CONFIG_ and check the script. Unfortunately I'm currently fighting unrelated issues so it may be a bit of time until I get round to it. If anyone wants to jump in, go ahead.

And yes, interesting to finally see where that 64MB went!

[davidgiven]

Sorry about the long delay, but I finally have an improved version of this patch. With luck and github willing, it's here:

https://github.com/amery/linux-allwinner/pull/34

This now checks the startup script and only reserves the regions when the particular feature is enabled. If they're not, the relevant symbols get set to 0 which at the worst should cause a clean crash if anything tries to use them rather than random memory corruption. If the feature is not compiled into the kernel at all, the symbols aren't defined.

The video engine (which uses the VE block) doesn't appear to have such a startup script setting.

It also now allocates the G2D block, which upstream wasn't doing --- I think this fixes a bug.