Infrastructure: Duplicated ACPI Tables, impacting updates for ref platforms

[gus33000]

Select QTI platforms have their ACPI files fully provided by the ACPI binary repository, due to this repo build system it is required to duplicate these files currently into the device ACPI folder with no possibility to override such requirement to instead use the file naturally available under SurfaceDuoACPI\QcomACPI\8350\builtin\DSDT_8350_MTP.aml for example.

It would be great if this could get improved for easy updates, currently we have to manually copy over each file one by one and even rename them to address this.

Further more; select devices may need to override more tables in the future, like for the debug table due to different GENI UART QUP usage for debugging (See OEM Corporation OEMZE device for a prime example of such thing)

[sunflower2333]

If there is a way to override it ...

[sunflower2333]

How about make a symbol link to the reference devices' acpi in reference devices' ACPI/DSDT.aml

[gus33000]

I was thinking at some point given the links keep increasing, that maybe we should adopt the normal edkII/mu model to have multiple platforms here. I would be up for one package for one device. This would also resolve a few issues where a device may not have a memory map compatible enough to afford reusing the existing defacto base address in the fdf. That was a bit of the spirit in SurfaceDuo1Pkg and 2Pkg, it also contains very minimal lines in the end and you would be able to dial in the dxes you want with ease, and the acpi tables

[sunflower2333]

well that make sense. But it will take time to refactor the whole repo and will reduced reusability, slow down ci, increase porting difficulty etc.
However as you say it can solve some issues currently meeting.
So i hope to find compromise solution that ensure reusability while meeting standards.

[gus33000]

Build times shouldn't be an issue anymore ever since we modified the ci to build every target in parallel and not consecutively. Of course this will increase aggregated custom workflows, like the one building only ref platforms or everything 855 but those iirc are also parallelized? Or should be made to be parallel

[sunflower2333]

OK i will try refactor next year. Do you have any ideas about folder structure?

Is Platforms/<PlatformName>/<VendorName>/<DeviceCodeName> okay?

For example:
Platforms/Lahaina/QTI/MTP888Pkg

[gus33000]

I do believe having the soc codename is redundant as as a platform you are going to take dependency on something under silicon anyway.

I propose this instead:

Platforms/Qualcomm/MTP8350Pkg/MTP8350Pkg.fdf etc

BTW: Some personal nits:

• Prefer Qualcomm over QTI, as it is more explicit
• Prefer 8150 over 855 (rename was official by that point)

[sunflower2333]

Platforms/Qualcomm/MTP8350Pkg/MTP8350Pkg.fdf etc

This form perhaps good for qti devices. But for other devices it will be mess i think.
That's why i say add a redundant folder under Platform.(it's just a folder for sorting and no other files there)

[sunflower2333]

• Prefer Qualcomm over QTI, as it is more explicit
• Prefer 8150 over 855 (rename was official by that point)

okay.

[gus33000]

Im drafting up a layout for a non made by Qualcomm Technologies Inc. series of devices to explain my thought process here:

First, here is what I am suggesting:

+-Platforms
+-+-OnePlus
| +---OnePlus5Pkg
| +---OnePlus6Pkg
| +---OnePlus6TPkg
| +---OnePlus7Pkg
| +---OnePlus7ProPkg
| +---OnePlus7TPkg
| +---OnePlus7TProPkg
...

Second, here is your proposal:

+-Platforms
+-+-OnePlus
| +-+-MSM8998
| | +---OnePlus5Pkg
| |
| +-+-SDM850
| | +---OnePlus6Pkg
| | +---OnePlus6TPkg
| |
| +-+-SM8150
| | +---OnePlus7Pkg
| | +---OnePlus7ProPkg
| | +---OnePlus7TPkg
| | +---OnePlus7TProPkg
...

I honestly do not see how it would start being a mess, looks quite reasonable to me on my first example. Everyone also gets what their device is, I would even go as far as potentially say that probably most people wouldnt know what soc they use more than their device...

[gus33000]

I mixed up your proposal so redoing it again with the right layout (it doesnt change what I think, i potentially think both ways dont really provide a major help, hw manufacturers dont make thousands of diff phone models, and im seeing a ton of empty folders otherwise)

+-Platforms
+-+-MSM8998
| +-+-OnePlus
| | +---OnePlus5Pkg
| |
+-+-SDM850
| +-+-OnePlus
| | +---OnePlus6Pkg
| | +---OnePlus6TPkg
| |
+-+-SM8150
| +-+-OnePlus
| | +---OnePlus7Pkg
| | +---OnePlus7ProPkg
| | +---OnePlus7TPkg
| | +---OnePlus7TProPkg
...

[sunflower2333]

For some vendors(like poco/redmi/realme), it uses different SoC in same series like will make the devices under quite confusing.

As a exmaple:
PocoX3 Pkg-> SM7150
PocoX3Pro Pkg -> SM8150
or:
Realme X3 -> SM8150
Realme X3 Pro -> SM8250
Realme X3 Superzoom -> SM8150
or:
Redmi K80 -> SM8650
Redmi K80 Pro -> SM8750

Not everyone can&will remember all this relationships. When there is an platform issue being found and needs fix (like replacing a dxe inf for in devcies' fdf, or memory map region optimize for all devices under same platforms),
i can't image how terrible it will be:
You have to find out all device pkgs under a same platform, search their name on google one by one or grep platform strings in / or read docs to them out and edit their fdf(s) /dsc{s}/map(s) to fix a platform-general issue.

[gus33000]

I mean wouldn't in this case the problem also occur with your layout? People will confuse it too if they don't know how their device is named