Hi, On Fri, Mar 15, 2024 at 10:26 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > On Fri, Mar 15, 2024 at 10:12:12AM -0700, Doug Anderson wrote: > > Hi, > > > > On Fri, Mar 15, 2024 at 8:24 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > > > On Thu, Mar 14, 2024 at 04:20:59PM -0700, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Mon, Jul 3, 2023 at 1:56 AM Maulik Shah <quic_mkshah@xxxxxxxxxxx> wrote: > > > > > > > > > > Add power-domains for cpuidle states to use psci os-initiated idle states. > > > > > > > > > > Cc: devicetree@xxxxxxxxxxxxxxx > > > > > Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> > > > > > Signed-off-by: Maulik Shah <quic_mkshah@xxxxxxxxxxx> > > > > > --- > > > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 98 +++++++++++++++++++++------- > > > > > 1 file changed, 73 insertions(+), 25 deletions(-) > > > > > > > > FWIW, I dug up an old sc7280-herobrine board to test some other change > > > > and found it no longer booted. :( I bisected it and this is the change > > > > that breaks it. Specifically, I can make mainline boot with: > > > > > > > > git revert --no-edit db5d137e81bc # arm64: dts: qcom: sc7280: Update > > > > domain-idle-states for cluster sleep > > > > git revert --no-edit 7925ca85e956 # arm64: dts: qcom: sc7280: Add > > > > power-domains for cpuidle states > > > > > > > > > > IIRC, this could be issue with psci firmware. There were some known > > > issues which were discussed few years back but I am not aware of the > > > details and if/how it is applicable here. > > > > > > Not sure if you are getting any logs during the boot, if you do have > > > worth look at logs related to PSCI/OSI/Idle/... > > > > Given that the new firmware fixes it I'm going to say it's not worth > > looking into any longer. > > > > But it would be good to know if that is the exact reason, see if it can > be upgraded, or else we can disable them by default. The bootloader or > something else can detect the f/w version and enable them so that the > board with old f/w(if can't be upgraded) can still be used. > > Otherwise it is a regression IMO. I think it only would really matter if the problematic firmware actually made it out into the real world. In this case the only people who run into this are developers at Google and Qualcomm who had early versions of hardware and had old firmware sitting around on them. I can count the number of folks affected on one hand, and that's even if one of my fingers gets cut off. All of those folks can just upgrade their firmware since there is no downside in doing so. -Doug
