-
Notifications
You must be signed in to change notification settings - Fork 321
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
PTL upstream #9185
PTL upstream #9185
Conversation
|
||
void platform_pm_runtime_disable(uint32_t context, uint32_t index); | ||
|
||
bool platform_pm_runtime_is_active(uint32_t context, uint32_t index); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we have these prototypes in a common .h file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any suitable place in sof/include/sof/common.h . But I see place for a refactor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You accidentally removed the execute permission, this breaks all builds on Linux:
./sof/scripts/xtensa-build-zephyr.py: Permission denied
961f6aa
to
404ecc4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see multiple commits modifying .conf files and some others too. Can all those commits be merged?
404ecc4
to
8fdfe02
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good. A few minor things, please collapse mandatory conf file changes into one commit (or if we want to keep them separate, fix the git commit messages, each commit neesds a proper prefix in git summary line, etc). And the alh.h, idc.h and interrupt.h files can be dropped.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General "naming things" whine. PTL is being submitted in Zephyr as "ace30", to live in a single, mostly-shared codebase with "ace15" and "ace20".
SOF is merging "pantherlake" as a completely separate platform layer with 1500 lines of duplicated code? That seems to be going in exactly the wrong direction?
-
Shouldn't Zephyrization, which puts most hardware details in upstream drivers, be producing smaller deltas between SOF platforms and not bigger ones?
-
A lot of these deltas are declarators for addresses or device counts or whatever that really look like they can be extracted from the upstream drivers, or from devicetree. Why are we hardcoding stuff like DAI_NUM_HDA_OUT vs. just asking the Zephyr hda driver?
-
At the very least can't we name them the same? Put PTL code inside the "ace" directory like Zephyr does, call it "ace30" like Zephyr does, and discriminate where you need to in the headers via the SOC kconfig instead of having a completely separate include tree with variant naming?
Or alternatively catch up to @ceolin before his PR merges and get him to change the naming, of course :) But having skewed naming vs. your base OS is sort of a bad smell. |
Never mind. It merged four hours ago :) |
@andyross wrote:
This is a fair point, but this is not specific to this generation at least. ace30 is the IP block name while PTL is one integration to a product. E.g. in past we've had cAVS2.5 (the IP name) and Tiger Lake (one product using it). On SOF side, we've had regular debates whether to change the naming, but so far we've always stuck with this duality of naming. In SOF side we have (some) product specific logic, so using the product names makes more sense. This PR is at least following the style of both codebases. |
0dfd881
to
10a1b72
Compare
c1d9b59
to
bd3c248
Compare
bd3c248
to
b9d925c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comments have been addressed.
For syntax clearity changed if conditional to zephyr method Signed-off-by: Dobrowolski, PawelX <[email protected]>
Due to introducing new platform to sof we need to recognize which iteration of ace board we are dealing with. Signed-off-by: Dobrowolski, PawelX <[email protected]>
Patch adds PTL configuration basing on MTL DMIC depends on PM_DEVICE_RUNTIME and PM_DEVICE_POWER_DOMIAN settings. To effectively enable DMIC these flags must be set. Additionally DMIC Ownership bit is not supported on ACE 2.0 and ACE 3.0. Therefore CONFIG_DAI_DMIC_HAS_OWNERSHIP is switched off. Signed-off-by: Jakub Dabek <[email protected]>
Enable chain-dma hw support on PTL platform Signed-off-by: Piotr Makaruk <[email protected]>
Enable L3 HEAP to support D3 scenarios on PTL Signed-off-by: Jakub Dabek <[email protected]>
This PR enabled D3 flow on PTL platform. Signed-off-by: Jaroslaw Stelter <[email protected]>
Add PTL configuration changes required to build FW for FPGA. After next SOF rebase default target will be build for RVP, so for FPGA we will use configuration overlay. Signed-off-by: Jaroslaw Stelter <[email protected]>
FW infrastructure shall support buffering of historic data from 1ch up to 6 channels 24bit samples in 24bit container. For this reason, the heap should be extended.Increase HEAPMEM_SIZE by 0x90000 because for audio format 16000Hz/6ch/24bit history_buffer_size = 16 * 6 * 3 * 2100s = 604800 bytes (0x93A80) Signed-off-by: Jaroslaw Stelter <[email protected]>
Add base PTL config derived from MTL. Signed-off-by: Jaroslaw Stelter <[email protected]>
b9d925c
to
f7502b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some escalation of existing whines. Still not a -1 as none of it is really any of my business.
But a lot of the "we'll fix it later" replies seem maybe a little too aspirational. SOF is historically quite bad at consistent refactoring, and if we don't take time to get designs right when they merge the first time the history says that they'll never be revisited.
depends on ACE | ||
bool | ||
help | ||
Select for ACE version 3.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still whining that this is a 100% parallel and unconstrained recapitulation of platform selection that is already in the Zephyr tree. All this does is create the possibility of getting it wrong.
I get that this is "how it's always been done", but the time to fix that is now, when submitting a new platform. If PTL doesn't do it, then when will it happen?
At the very least (if the use of these older kconfigs is too hard to untangle) you should be deriving it from the existing constants and disallowing apps from setting it incorrectly:
- No "help" text or docstring after the type, which prevents it from being overriden without a warning
default y if SOC_INTEL_ACE30_PTL
sets it correctly always
#define ACE_VERSION_1_5 0x10500 /* TGL */ | ||
#define ACE_VERSION_2_0 0x20000 /* MTL */ | ||
#define ACE_VERSION_2_5 0x20500 /* LNL */ | ||
#define ACE_VERSION_3_0 0x30000 /* PTL */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still really dislike introducing numbered versions for a system that doesn't guaranteed backward compatibility. Is a PTL device always compatible with a LNL one? Clearly no, right? So this is creating a promise you can't keep, even if the handful of spots in this PR work that way.
And to repeat: this is a new API, not a legacy one you're trying to accomodate.
Really severe Zephyr crash at https://sof-ci.01.org/sofpr/PR9185/build5843/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-pause-resume-capture-100 While this PR is obviously focused on PTL, 1. I haven't seen any crash like this for weeks (and I stared at a LOT of test results recently) 2. there a little bit of So there is some suspicion that this crash could be caused by this PR.
The obvious way to isolate is to extract the cleanups and refactoring which are not PTL-specific is to submit them first in separate PR(s). |
I haven't but someone else has. Proving me wrong less than 5 minutes later: Ignore previous comment sorry (except the part about cleanups and smaller PRs) EDIT: this is a very recent regression actually. |
Please make sure we have PTL in CI before taking a merge attempt |
Add initial PTL configuration