Quoting Akhil P Oommen (2022-07-18 21:07:05) > On 7/14/2022 11:10 AM, Akhil P Oommen wrote: > > On 7/12/2022 4:57 AM, Doug Anderson wrote: > >> Hi, > >> > >> On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen > >> <quic_akhilpo@xxxxxxxxxxx> wrote: > >>> Update gpu register array with gpucc memory region. > >>> > >>> Signed-off-by: Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> > >>> --- > >>> > >>> (no changes since v1) > >>> > >>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++++-- > >>> 1 file changed, 4 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi > >>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi > >>> index e66fc67..defdb25 100644 > >>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > >>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > >>> @@ -2228,10 +2228,12 @@ > >>> compatible = "qcom,adreno-635.0", > >>> "qcom,adreno"; > >>> reg = <0 0x03d00000 0 0x40000>, > >>> <0 0x03d9e000 0 0x1000>, > >>> - <0 0x03d61000 0 0x800>; > >>> + <0 0x03d61000 0 0x800>, > >>> + <0 0x03d90000 0 0x2000>; > >>> reg-names = "kgsl_3d0_reg_memory", > >>> "cx_mem", > >>> - "cx_dbgc"; > >>> + "cx_dbgc", > >>> + "gpucc"; > >> This doesn't seem right. Shouldn't you be coordinating with the > >> existing gpucc instead of reaching into its registers? > >> > > IIUC, qcom gdsc driver doesn't ensure hardware is collapsed since they > > are vote-able switches. Ideally, we should ensure that the hw has > > collapsed for gpu recovery because there could be transient votes from > > other subsystems like hypervisor using their vote register. > > > > I am not sure how complex the plumbing to gpucc driver would be to allow > > gpu driver to check hw status. OTOH, with this patch, gpu driver does a > > read operation on a gpucc register which is in always-on domain. That > > means we don't need to vote any resource to access this register. > > > > Stephen/Rajendra/Taniya, any suggestion? Why can't you assert a gpu reset signal with the reset APIs? This series seems to jump through a bunch of hoops to get the gdsc and power domain to "reset" when I don't know why any of that is necessary. Can't we simply assert a reset to the hardware after recovery completes so the device is back into a good known POR (power on reset) state?
