Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: rob.clark@oss.qualcomm.com
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>,
	Sean Paul <sean@poorly.run>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Akhil P Oommen <akhilpo@oss.qualcomm.com>,
	Dmitry Baryshkov <lumag@kernel.org>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Jessica Zhang <jesszhan0024@gmail.com>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: display/msm/gpu: Narrow reg and reg-names for Adreno 610.0 and alike
Date: Mon, 29 Dec 2025 08:23:56 +0100	[thread overview]
Message-ID: <8288af85-13da-46e3-8d89-71995fbd17f8@kernel.org> (raw)
In-Reply-To: <CACSVV03FfvZVzuKGfaJrsXmE7VVxEF5zN4-R7h1PXA11jOO3gw@mail.gmail.com>

On 28/12/2025 15:59, Rob Clark wrote:
> On Sat, Dec 27, 2025 at 11:56 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 27/12/2025 23:01, Rob Clark wrote:
>>> On Sat, Dec 27, 2025 at 3:05 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@oss.qualcomm.com> 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

  reply	other threads:[~2025-12-29  7:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-27 11:05 [PATCH 1/2] dt-bindings: display/msm/gpu: Narrow reg and reg-names for Adreno 610.0 and alike Krzysztof Kozlowski
2025-12-27 11:05 ` [PATCH 2/2] dt-bindings: display/msm/gpu: Drop redundant reg-names in one if:then: Krzysztof Kozlowski
2025-12-27 22:01 ` [PATCH 1/2] dt-bindings: display/msm/gpu: Narrow reg and reg-names for Adreno 610.0 and alike Rob Clark
2025-12-28  7:56   ` Krzysztof Kozlowski
2025-12-28 14:59     ` Rob Clark
2025-12-29  7:23       ` Krzysztof Kozlowski [this message]
2025-12-29 20:09         ` Konrad Dybcio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8288af85-13da-46e3-8d89-71995fbd17f8@kernel.org \
    --to=krzk@kernel.org \
    --cc=abhinav.kumar@linux.dev \
    --cc=airlied@gmail.com \
    --cc=akhilpo@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jesszhan0024@gmail.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzysztof.kozlowski@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lumag@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marijn.suijten@somainline.org \
    --cc=mripard@kernel.org \
    --cc=rob.clark@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=sean@poorly.run \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox