Skip to content

PMP: initialization and experiments#545

Open
WhatAmISupposedToPutHere wants to merge 5 commits intoAsahiLinux:mainfrom
WhatAmISupposedToPutHere:feldspar
Open

PMP: initialization and experiments#545
WhatAmISupposedToPutHere wants to merge 5 commits intoAsahiLinux:mainfrom
WhatAmISupposedToPutHere:feldspar

Conversation

@WhatAmISupposedToPutHere
Copy link
Contributor

The thingy that makes your mac use less power.


ADT_FOREACH_PROPERTY(adt, pmp_iop_anode, prop)
{
if (fdt_setprop(dt, tunables_node, prop->name, prop->value, prop->size))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect we want to filter this at least lightly. compatible = [iop-nub,rtbuddy-v2] and AAPL,phandle shouldn't be copied. There are further properties an OSS driver probably does not need.
I hope "these are the property names apple uses in the ADT" is a convincing argument during dt-bindings / driver review but don't really see a sane alternative.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The annoying part is that firmware requests the property values from this node by name, so i don't even have a static list of properties that it needs. Can only treat them as an opaque key/value dict.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it request "soc-device" / "controller" / "lts-config"? looking at the larger properties.
I'd expected "region-", "segment-", "pre-loaded", "firmware-name", "dram-capacity", "coredump-enable" can be removed as well. Primarily looking at properties which could end up confusing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the big three are requested, but the others on the list can be excluded

pio_base = u.adt["/arm-io/dart-pmp"].pio_vm_base
granularity = u.adt["/arm-io/dart-pmp"].pio_granularity
i = 0
for (host_addr, size) in [(0x282000000, 0x1000000),(0x304000000, 0x1000000),(0x383000000, 0x1000000),(0x402000000, 0x1000000),(0x210e70000, 0x90000),(0x211e70000, 0x90000),(0x212e70000, 0x90000)]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these address/size pairs observed by tracing? On which device? Can we derive them from the ADT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is on a m1 pro, they are derived from adt (reg 4 and following, i have written them down in linux driver's dt)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we documents that this is only expected to run on t6000 (and maybe other t600x or t602x devices)? An compatibility check with early exit would be enough. Please mention it in the commit message as well.

@WhatAmISupposedToPutHere WhatAmISupposedToPutHere force-pushed the feldspar branch 2 times, most recently from 973ac05 to c2b0c93 Compare February 26, 2026 11:40
Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>

ADT_FOREACH_PROPERTY(adt, pmp_iop_anode, prop)
{
if (fdt_setprop(dt, tunables_node, prop->name, prop->value, prop->size))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it request "soc-device" / "controller" / "lts-config"? looking at the larger properties.
I'd expected "region-", "segment-", "pre-loaded", "firmware-name", "dram-capacity", "coredump-enable" can be removed as well. Primarily looking at properties which could end up confusing

Copy link
Member

@jannau jannau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The commits are missing Signed-off-by:

bail("FDT: failed to transfer pmp tunable");
next_adt_prop:;
}
return 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update pmp_node's "status" to "okay". I will disable the pmp node in the linux device trees so we can merge the kernel bits before the next m1n1 release

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized that this isn't possible due to the power-domains dependencies. This has to be handled in the driver. I don't remember if this is already handled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be fine. pmp itself will stay disabled, while the kernel harmlessly writes to pmp_reporting (a shared sram area). Just like macos does, we do not wait for pmp acknowledgements until it has booted

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I think so too after looking at it. So I will disable pmp in the kernel DT.

This reverts commit f41676c.

Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
This reverts commit bfe4027.

Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
This reverts commit 4be960c.

Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
Copy all the things that PMP needs in order to boot.

Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
if (ADT_GETPROP(adt, pmp_iop_anode, "dram-capacity", &dram_capacity) < 0)
bail("ADT: failed to get dram capacity\n");

int pmp_node = fdt_path_offset(dt, "pmp");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please move this to the beginning of the function. The j504 (M3 macbook pro) does not have dram-capacity in /arm-io/pmp/iop-pmp-nub.
Checking the FDT first for pmp avoids to fail on new devices with different ADT properties.

bail("ADT: failed to get board id\n");
if (ADT_GETPROP(adt, chosen_anode, "dram-vendor-id", &dram_vendor_id) < 0)
bail("ADT: failed to get dram vendor id\n");
if (ADT_GETPROP(adt, pmp_iop_anode, "dram-capacity", &dram_capacity) < 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we use /chosen/dram-size instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/chosen/dram-size from the ADT? Don't think so, whatever this field specifies, i haven't seen an obvious relationship with the system ram size, as both my 32gb and 8gb machines have it set to 8

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All device ADTs I could quickly grep have dram-capacity = 8. I just assumed it is the RAM size and only verified that dram-size matches the installed RAM. Leave it as it is then and we'll have to adjust once we support PMP on M3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants