-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide more information about RAM from the bootloader #62
Comments
I think this duplicates a bit Documentation/devicetree/bindings/memory-controllers/ddr/ in Linux kernel. We already describe memory under memory controllers. I guess the top level memory is only for parsing size/location for FW/OS. |
@krzk Generally I'd agree with you. The problem is:
I hate to ask this, but is there a chance to receive a pardon for this property, provided it is limited to Qualcomm platorms? |
Go look at 'lshw'. It already supports some similar properties in the memory nodes dating back to PowerMac days. |
@robherring I'm not sure if you comment is 'pro' or 'contra', could you please be more specific? |
I'm saying if what's supported by lshw works for you, then I'd be open to supporting it. However, note that with UEFI boot, there are no memory nodes... |
@robherring no, they are not supported by lshw. We are currently in the following position: the existing bootloader writes this DT property. While we potentially can try persuading Qualcomm to use correct DT entry (no guarantees on the result though), existing devices are already Parsing this DDR memory type becomes important for the display and GPU drivers to properly setup the hardware. Thus we are asking for an "exception": we'd like to document the mentioned |
Qualcomm currently does
/memory[@somewhere]/ddr_device_type
=with 1, 2, 3, 4 presumably going to LPDDR(1 / 2_S2 / 2_S4 / 2N), though no sources prove that
Introducing a common property to propagate that information to the operating system seems rather useful. In this Qualcomm-specific example, many on-SoC IP blocks need different settings based on the DDR type.
The text was updated successfully, but these errors were encountered: