-
Notifications
You must be signed in to change notification settings - Fork 140
Support extended manifest config data for clock config #2297
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
Support extended manifest config data for clock config #2297
Conversation
b7cee8d to
3530dcf
Compare
|
Testing is pending as I couldn't get extended manifest from the firmware. I compiled @abonislawski 's branch with debug option as well. But I couldn't get ext_man_size. @abonislawski , can you proivde test firmware? I have test devcies, apl and cnl. Thank you! |
|
@fredoh9 at the moment ext_manifest is not included in any FW image. |
|
I'm able to see extended manifest data with merging a commit from thesofproject/sof#2957. And I built own firmware for APL. |
3530dcf to
a77904e
Compare
a77904e to
f553993
Compare
|
I tested with CML Helios, |
f553993 to
1e5fc3b
Compare
8d59191 to
b8b3314
Compare
b8b3314 to
4a4b2f5
Compare
d6e8f01 to
4b34c3c
Compare
kv2019i
left a comment
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.
Thanks @fredoh9 -- this starts to look good. One bigger issue I'm left wondering is that what is the first actual use of this information. Unless we have a real user for the info, I don't think we can send the series forward. What would be the first user and could we add it to this PR?
I will submit new PR for supporting ICL ICCMAX. It will use of clk_config_lpro. |
82c8b05 to
7ec7010
Compare
|
No more formal objections, but yes, as @kv2019i pointed out, without use-cases it's difficult to review properly |
7ec7010 to
d918d7e
Compare
|
In this PR one thing which concerns me is inconsistence between |
xiulipan
left a comment
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.
Please make alignment with #2459
- ABI header need alignment
- parser need to be in loader.c and clk config should be in ops.
- The size is really a problem. A question here, how could we know how many config elem we have? like the elem_num is calculated by alignment size.
include/sound/sof/ext_manifest.h
Outdated
| struct sof_ext_man_config_data { | ||
| struct sof_ext_man_elem_header hdr; | ||
|
|
||
| struct sof_config_elem elems[SOF_EXT_MAN_CONFIG_LAST_ELEM]; |
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.
| struct sof_ext_man_elem_header hdr; | ||
|
|
||
| struct sof_config_elem elems[SOF_EXT_MAN_CAVS_CONFIG_LAST_ELEM]; | ||
| } __packed; |
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 finding about the elem_size here. see https://github.com/thesofproject/linux/pull/2459/files#r508172578
@fredoh9 @ktrzcinx how could we get real elem size with align up here?
.hdr.elem_size = ALIGN_UP(sizeof(struct ext_man_config_data),
EXT_MAN_ALIGN),
| .post_fw_run = hda_dsp_post_fw_run, | ||
|
|
||
| /* parse platform specific extended manifest */ | ||
| .parse_platform_ext_manifest = hda_dsp_ext_man_get_cavs_config_data, |
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.
Why add this parse as ops?
Will we have different type of ext_manifest for different platform?
I think you can make something same with #2459
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.
@xiulipan yes we will. For example, why would the IMX platforms have the LPRO config elem?
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.
@ranj063 A good question here, but I think we should parse the platform manifest in one place and config them to each platform.
Otherwise we will need to add a almost same function for parse in each platform.
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.
@xiulipan I'm afraid this is a bit wrong audience. The ABI was already added to FW with 3.17 in thesofproject/sof#2893
It's possible to just ignore this and agree a new interface to pass clock information in non-hw-specific way, but this needs to be raised in FW.
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.
@ranj063 @fredoh9 @kv2019i My only concern here is about the generic part in hda_dsp_ext_man_get_cavs_config_data, if we need implement this for each platform there will be too many duplicate code. I will suggest to only wrap specific handler to platform and fallback to unknown handler to unsupported platforms.
| /* skip empty token */ | ||
| break; | ||
| case SOF_EXT_MAN_CAVS_CONFIG_CAVS_LPRO: | ||
| hda->clk_config_lpro = config_data->elems[i].value; |
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 think you would better to have some ops for the clk_config setting for each platform.
The parse should be unify for all platform, but how to se the clk should be platform specific.
| .post_fw_run = hda_dsp_post_fw_run, | ||
|
|
||
| /* parse platform specific extended manifest */ | ||
| .parse_platform_ext_manifest = hda_dsp_ext_man_get_cavs_config_data, |
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.
@ranj063 @fredoh9 @kv2019i My only concern here is about the generic part in hda_dsp_ext_man_get_cavs_config_data, if we need implement this for each platform there will be too many duplicate code. I will suggest to only wrap specific handler to platform and fallback to unknown handler to unsupported platforms.
| int hda_dsp_ext_man_get_cavs_config_data(struct snd_sof_dev *sdev, | ||
| const struct sof_ext_man_elem_header *hdr) | ||
| { | ||
| const struct sof_ext_man_cavs_config_data *config_data = | ||
| container_of(hdr, struct sof_ext_man_cavs_config_data, hdr); | ||
| struct sof_intel_hda_dev *hda = sdev->pdata->hw_pdata; | ||
| int i, elem_num; | ||
|
|
||
| /* calculate total number of config data elements */ | ||
| elem_num = (hdr->size - sizeof(struct sof_ext_man_elem_header)) / sizeof(struct sof_config_elem); | ||
| if (elem_num <= 0) { | ||
| dev_err(sdev->dev, "cavs config data is inconsistent: %d\n", elem_num); | ||
| return -EINVAL; | ||
| } | ||
|
|
||
| for (i = 0; i < elem_num; i++) | ||
| switch (config_data->elems[i].token) { | ||
| case SOF_EXT_MAN_CAVS_CONFIG_EMPTY: | ||
| /* skip empty token */ | ||
| break; | ||
| case SOF_EXT_MAN_CAVS_CONFIG_CAVS_LPRO: | ||
| hda->clk_config_lpro = config_data->elems[i].value; | ||
| dev_dbg(sdev->dev, "FW clock config: %s\n", hda->clk_config_lpro ? "LPRO" : "HPRO"); | ||
| break; | ||
| case SOF_EXT_MAN_CAVS_CONFIG_OUTBOX_SIZE: | ||
| case SOF_EXT_MAN_CAVS_CONFIG_INBOX_SIZE: | ||
| /* This elem is supported but config data is not being used yet */ | ||
| break; | ||
| default: | ||
| dev_warn(sdev->dev, "unsupported token type: %d\n", | ||
| config_data->elems[i].token); | ||
| } | ||
|
|
||
| return 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.
I will suggest to move this function to loader.c and only do something like
ext_man_config_cvas_lpro(...);
break;
case SOF_EXT_MAN_CAVS_CONFIG_OUTBOX_SIZE:
case SOF_EXT_MAN_CAVS_CONFIG_INBOX_SIZE:
ext_man_config_box_size(...);
break;
default:
dev_warn(sdev->dev, "unsupported token type: %d\n",
config_data->elems[i].token);
}
}
Then in ext_man_config_cvas_lpro and ext_man_config_box_size we can have platform ops check and fallback to
warn unsupported ext_man
|
@plbossart Sorry for delay, i couldn't finish icl iccmax implementation. I will submit a PR for it today. And I will work with @ranj063 |
Add parse_platform_ext_manifest() op to parse platform-specific config data in the extended manifest. Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
Define the parse_platform_ext_manifest() op for HDA platforms to parse the SOF_EXT_MAN_CAVS_CONFIG_CAVS_LPRO config item to determine if the FW is configured for LPRO. The default clock configuration is assumed to be HPRO in the absence of this item in the extended manifest. New member clk_config_lpro is added to struct sof_intel_hda_dev to store the FW clock config information and that this will be used later to perform platform-specific operations in the post_fw_run op. Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
OUTBOX_SIZE, INBOX_SIZE are supported but not being used yet. Handle these elements to avoid warning about unknown token type. Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
d918d7e to
8cf6b73
Compare
|
Closing this. Will be reviewed and merged with ICL ICCMAX implementation. #2548 |
This need to be finalized to support SOF firmware change, thesofproject/sof#2893.