ASoC: SOF: increase baytrail shim window #1578
Conversation
The window contains definitions according to the firmware headers up to 0x114 which means that it is at least 0x118. Lets share the debug information. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
paulstelian97
left a comment
paulstelian97
left a comment
There was a problem hiding this comment.
Sure, I see no problem with that. Just correct a typo in the commit description ("Lets" -> "Let's").
plbossart
left a comment
plbossart
left a comment
There was a problem hiding this comment.
@cujomalainey while we are at it, you may want to check the firmware side, the definition doesn't seem to exist:
git grep SHIM_HDMC
src/platform/baytrail/include/platform/lib/shim.h:#define SHIM_SHIM_END SHIM_HDMC
|
I noticed that as well. I will see what is going on there. Also apparently 0x118 is only for CHT. I will send a follow up PR. |
|
Do we have any way to discern from a CHT or BYT platform at compile time? I don't think we do for the kernel, so is it ok if we let byt dump an extra 0x18 bytes? |
|
no, for the kernel we have to assume the build supports multiple architectures, but we have helper functions you can use e.g. soc_intel_is_cht() I can confirm the last address for BYT is 0x0F8 (SSP2_DIV_CTRL), so the SHIM end should be 100 (excluded). I am not sure if we want to dump undefined registers. That's asking for trouble. better to add a test and increment the size for cht to dump the additional 0x18 bytes. |
|
turns out it was just referenced in two tables (one for byt and one for cht) so I just split the definition. #1585 |
3 participants
The window contains definitions according to the firmware headers up to
0x114 which means that it is at least 0x118. Lets share the debug
information.
Signed-off-by: Curtis Malainey cujomalainey@chromium.org