On Sat, Dec 27, 2025 at 11:56 PM Krzysztof Kozlowski <[email protected]> wrote: > > On 27/12/2025 23:01, Rob Clark wrote: > > On Sat, Dec 27, 2025 at 3:05 AM Krzysztof Kozlowski > > <[email protected]> wrote: > >> > >> DTS files for qcom,adreno-610.0 and qcom,adreno-07000200 contain only one > >> "reg" entry, not two, and the binding defines the second entry in > >> "reg-names" differently than top-level part, so just simplify it and > >> narrow to only one entry. > > > > I'll defer to Akhil about whether this is actually needed (vs just > > incomplete gpu devcoredump support for certain GPUs). In general > > cx_dbgc is needed to capture state for gpu devcoredump state > > snapshots, but not directly used in normal operations. It seems > > similar to the situation with mapping gpucc as part of gmu, ie. not > > something the CPU normally deals with directly, but necessary to > > capture crash state. > > I don't get why binding was added with cx_dbgc, but DTS not. Neither > binding nor DTS depends on actual usage, so I assume someone > intentionally did not want DTS to contain cx_dbgc and binding should > follow. Otherwise we should make the DTS complete and make the binding > strict (leading to warnings if DTS is not updated).
I'm not sure about the history.. but I can say that cx_dbgc is only used for gpu state snapshot / devcoredump. So it would be easy to not notice if it were missing. We have a similar slightly ugly thing where gpucc is included in the gmu map.. only for devcoredump. Maybe we need a different way to handle these things that are only mapped for state capture? BR, -R
