On 9/5/24 18:24, Konrad Dybcio wrote:
On 4.09.2024 4:20 PM, Cristian Marussi wrote:
On Wed, Sep 04, 2024 at 01:38:55PM +0100, Sudeep Holla wrote:
On Wed, Sep 04, 2024 at 01:29:29PM +0200, Konrad Dybcio wrote:
On 4.09.2024 9:00 AM, Johan Hovold wrote:
[...]
Unfortunately, this patch breaks resume from suspend on the x1e80100 crd:
[ 26.919676] CPU4: Booted secondary processor 0x0000010000 [0x511f0011]
[ 26.960607] arm-scmi firmware:scmi: timed out in resp(caller: do_xfer+0x164/0x568)
[ 26.987142] cpufreq: cpufreq_online: ->get() failed
and then the machine hangs (mostly, I saw an nvme timeout message after a
while).
Make sure you test suspend as well as some of the warnings I reported
only show up during suspend.
Eh it looks like PERF_LEVEL_GET (msgid 8) requires the use of FC, but
the firmware fails to inform us about it through BIT(0) in attrs..
Just trying to understand things better here. So the firmware expects OSPM
to just use FC only for PERF_LEVEL_GET and hence doesn't implement the
default/normal channel for PERF_LEVEL_GET(I assume it returns error ?)
but fails to set the attribute indicating FC is available for the domain.
Is not that FCs are optional BUT PERF_LEVEL_GET standard messages is
support is mandatory by the spec anyway ?
So doing a bit of poking I think it's that FC is not marked as supported,
but we need to read out the frequency from the .get_addr.. which is only
populated if we go through fastchannel_init
On further debug it was found that the SCP was servicing the request
but mailbox had the interrupt disabled during suspend which caused the
timeout. I just re-spun the series wit hte fix. So yeah PERF_LEVEL_GET
is expectedto work without any problems. There is no dependence on EC as
Konrad speculated. Just a straight forward case of interrupt being
disabled in the resume path.
-Sibi
Konrad
