Skip to contentSkip to conversation

revert ARM SCPI changes for v4.15-rc1

GIT PULL Kevin Hilman 4 participants 4 messages Dec 1, 2017 – Dec 4, 2017 Arm/Amlogic Meson SoC support

lore
Share & tools
lore

Kevin Hilman

author maintainer
#0 lore raw

Arnd, Olof,

These ARM SCPI changes caused SCPI regressions resulting in CPUfreq failures on most Amlogic SoCs (found by kernelci.org.)

Unfortunately, this was not caught in linux-next due to other bugs/panics on these platforms masking this problem so we've only found it since we've fixed the other issues.

Since we're already in the -rc cycle, I'd prefer to revert to a known working state (that of v4.14) rather than finding/reverting a subset, which would just lead to another untested state.

These changes can then have some time to be better reviewed and tested and resubmitted for v4.16.

I've tested this revert on the affect Amlogic SoCs and verified that we're back to the previous (working) condition.

Also, I'm sending the pull directly to arm-soc instead of Sudeeep because I understand that Sudeep is currently out-of-office and unlikely to be able to address this himself during the -rc cycle.

Please pull,

Thanks,

Kevin

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/scpi-revert

for you to fetch changes up to 5f56b7f4854aaab34eb570c24a1866b2050fc3f5:

Revert "Merge tag 'scpi-updates-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers" (2017-12-01 10:56:35 -0800)

----------------------------------------------------------------
Revert ARM SCPI changes since v4.14.

Untested changes caused regressions in SCPI and CPUfreq/DVFS failures on most Amlogic SoCs. Changes reverted for v4.15 so they can be better reviewed and tested.

----------------------------------------------------------------
Kevin Hilman (1):
Revert "Merge tag 'scpi-updates-4.15' of git://git.kernel.org/.../sudeep.holla/linux into next/drivers"

 drivers/firmware/arm_scpi.c | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------
 1 file changed, 129 insertions(+), 87 deletions(-)
#1 lore raw
Quoted 16 lines · Kevin Hilman

Arnd, Olof,

These ARM SCPI changes caused SCPI regressions resulting in CPUfreq failures on most Amlogic SoCs (found by kernelci.org.)

Unfortunately, this was not caught in linux-next due to other bugs/panics on these platforms masking this problem so we've only found it since we've fixed the other issues.

Since we're already in the -rc cycle, I'd prefer to revert to a known working state (that of v4.14) rather than finding/reverting a subset, which would just lead to another untested state.

These changes can then have some time to be better reviewed and tested and resubmitted for v4.16.

Quoted 7 lines

I've tested this revert on the affect Amlogic SoCs and verified that we're back to the previous (working) condition.

Also, I'm sending the pull directly to arm-soc instead of Sudeeep because I understand that Sudeep is currently out-of-office and unlikely to be able to address this himself during the -rc cycle.

Sounds like the right approach here. I've merged this and added the above text to the merge commit as well.

-Olof

#2 lore raw

Am 03.12.2017 um 02:04 schrieb Olof Johansson:

Quoted 20 lines · Kevin Hilman
Quoted 19 lines

Arnd, Olof,

These ARM SCPI changes caused SCPI regressions resulting in CPUfreq failures on most Amlogic SoCs (found by kernelci.org.)

Unfortunately, this was not caught in linux-next due to other bugs/panics on these platforms masking this problem so we've only found it since we've fixed the other issues.

Since we're already in the -rc cycle, I'd prefer to revert to a known working state (that of v4.14) rather than finding/reverting a subset, which would just lead to another untested state.

These changes can then have some time to be better reviewed and tested and resubmitted for v4.16.

I've tested this revert on the affect Amlogic SoCs and verified that we're back to the previous (working) condition.

Quoted 8 lines
Quoted 4 lines

Also, I'm sending the pull directly to arm-soc instead of Sudeeep because I understand that Sudeep is currently out-of-office and unlikely to be able to address this himself during the -rc cycle.

Sounds like the right approach here. I've merged this and added the above text to the merge commit as well.

I can't reproduce the issue on my systems, however I'm quite sure that commit 931cf0c53e69 "firmware: arm_scpi: pre-populate dvfs info in scpi_probe" causes the problem.
I could re-submit the series w/o this patch, the other patches then need some re-basing.

I'd include a patch addressing the following question from Kevin because I was asking myself the same thing too:
"Also, is this the expected result for the pre-1.0 firmware:
scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version"

In case a legacy firmware doesn't provide version information I propose to print the following message instead:
scpi_protocol scpi: SCP Protocol legacy pre-1.0 firmware

The series could be applied to a devel branch first to give the Baylibre Amlogic team some time for testing.

Rgds, Heiner

Quoted 3 lines

-Olof

#3 lore raw
In reply to Olof Johansson
Quoted 17 lines · Olof Johansson
Quoted 16 lines · Kevin Hilman

Arnd, Olof,

These ARM SCPI changes caused SCPI regressions resulting in CPUfreq failures on most Amlogic SoCs (found by kernelci.org.)

Unfortunately, this was not caught in linux-next due to other bugs/panics on these platforms masking this problem so we've only found it since we've fixed the other issues.

Since we're already in the -rc cycle, I'd prefer to revert to a known working state (that of v4.14) rather than finding/reverting a subset, which would just lead to another untested state.

These changes can then have some time to be better reviewed and tested and resubmitted for v4.16.

Quoted 7 lines
Quoted 7 lines

I've tested this revert on the affect Amlogic SoCs and verified that we're back to the previous (working) condition.

Also, I'm sending the pull directly to arm-soc instead of Sudeeep because I understand that Sudeep is currently out-of-office and unlikely to be able to address this himself during the -rc cycle.

Thanks Kevin for taking care of this in my absence.

As mentioned in the other thread, I would like to get a list of AmLogic SoCs using SCPI and the ones that are broken. If my analysis is correct, then it's more likely to be firmware issue that is popping up as we now allow other SCPI protocols to work even when DVFS fails. This is useful on some platforms where firmware is under development or only DVFS is broken partially/fully.

Quoted 4 lines

Sounds like the right approach here. I've merged this and added the above text to the merge commit as well.

Thanks.

--
Regards,
Sudeep