On 28/12/2025 15:59, Rob Clark wrote: > 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?
No. Either hardware has it or not. If hardware has it, then both DTS and binding should have it. If people decided that DTS should not have it (for whatever reason), then apparently that's the desired hardware description and let's remove it from the binding to match the ABI. Best regards, Krzysztof
