• Conor Dooley's avatar
    Revert "clocksource/drivers/riscv: Events are stopped during CPU suspend" · d9f15a9d
    Conor Dooley authored
    This reverts commit 232ccac1.
    
    On the subject of suspend, the RISC-V SBI spec states:
    
      This does not cover whether any given events actually reach the hart or
      not, just what the hart will do if it receives an event. On PolarFire
      SoC, and potentially other SiFive based implementations, events from the
      RISC-V timer do reach a hart during suspend. This is not the case for the
      implementation on the Allwinner D1 - there timer events are not received
      during suspend.
    
    To fix this, the CLOCK_EVT_FEAT_C3STOP (mis)feature was enabled for the
    timer driver - but this has broken both RCU stall detection and timers
    generally on PolarFire SoC and potentially other SiFive based
    implementations.
    
    If an AXI read to the PCIe controller on PolarFire SoC times out, the
    system will stall, however, with CLOCK_EVT_FEAT_C3STOP active, the system
    just locks up without RCU stalling:
    
    	io scheduler mq-deadline registered
    	io scheduler kyber registered
    	microchip-pcie 2000000000.pcie: host bridge /soc/pcie@2000000000 ranges:
    	microchip-pcie 2000000000.pcie:      MEM 0x2008000000..0x2087ffffff -> 0x0008000000
    	microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
    	microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
    	microchip-pcie 2000000000.pcie: axi read request error
    	microchip-pcie 2000000000.pcie: axi read timeout
    	microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
    	microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
    	microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
    	microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
    	microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
    	microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
    	Freeing initrd memory: 7332K
    
    Similarly issues were reported with clock_nanosleep() - with a test app
    that sleeps each cpu for 6, 5, 4, 3 ms respectively, HZ=250 & the blamed
    commit in place, the sleep times are rounded up to the next jiffy:
    
    == CPU: 1 ==      == CPU: 2 ==      == CPU: 3 ==      == CPU: 4 ==
    Mean: 7.974992    Mean: 7.976534    Mean: 7.962591    Mean: 3.952179
    Std Dev: 0.154374 Std Dev: 0.156082 Std Dev: 0.171018 Std Dev: 0.076193
    Hi: 9.472000      Hi: 10.495000     Hi: 8.864000      Hi: 4.736000
    Lo: 6.087000      Lo: 6.380000      Lo: 4.872000      Lo: 3.403000
    Samples: 521      Samples: 521      Samples: 521      Samples: 521
    
    Fortunately, the D1 has a second timer, which is "currently used in
    preference to the RISC-V/SBI timer driver" so a revert here does not
    hurt operation of D1 in its current form.
    
    Ultimately, a DeviceTree property (or node) will be added to encode the
    behaviour of the timers, but until then revert the addition of
    CLOCK_EVT_FEAT_C3STOP.
    
    Fixes: 232ccac1 ("clocksource/drivers/riscv: Events are stopped during CPU suspend")
    Signed-off-by: default avatarConor Dooley <conor.dooley@microchip.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Reviewed-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
    Acked-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
    Acked-by: default avatarSamuel Holland <samuel@sholland.org>
    Link: https://lore.kernel.org/linux-riscv/YzYTNQRxLr7Q9JR0@spud/
    Link: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/98/
    Link: https://lore.kernel.org/linux-riscv/bf6d3b1f-f703-4a25-833e-972a44a04114@sholland.org/
    Link: https://lore.kernel.org/r/20221122121620.3522431-1-conor.dooley@microchip.com
    d9f15a9d
timer-riscv.c 5.06 KB