From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Johan Hovold <johan@kernel.org>
Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Robert Foss <rfoss@kernel.org>, Todor Tomov <todor.too@gmail.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] media: qcom: camss: vfe: Stop spamming logs with version
Date: Tue, 20 May 2025 10:30:16 +0200 [thread overview]
Message-ID: <8a2f2269-d07f-42b2-ab6c-dcff30a1f431@linaro.org> (raw)
In-Reply-To: <aCw78CRda6VS6ost@hovoldconsulting.com>
On 20/05/2025 10:23, Johan Hovold wrote:
> On Tue, May 20, 2025 at 10:02:32AM +0200, Krzysztof Kozlowski wrote:
>> On 20/05/2025 09:53, Johan Hovold wrote:
>
>>> Spamming the logs as the driver currently does is clearly broken and
>>> should be fixed. Keeping a hw version dev_dbg() is generally perfectly
>>> fine, though.
>
>> My main argument, expressed in the commit msg to which no one objected,
>> is that this debug is 100% useless: deducible from the compatible,
>> always known upfront, always the same.
>
> To me that deduction does not seem straightforward, at least not without
> access to internal qualcomm docs, for example:
>
> compatible = "qcom,sc8280xp-camss";
>
> qcom-camss ac5a000.camss: VFE:0 HW Version = 1.2.2
> qcom-camss ac5a000.camss: VFE:1 HW Version = 1.2.2
> qcom-camss ac5a000.camss: VFE:2 HW Version = 1.2.2
> qcom-camss ac5a000.camss: VFE:3 HW Version = 1.2.2
> qcom-camss ac5a000.camss: VFE:4 HW Version = 1.3.0
> qcom-camss ac5a000.camss: VFE:5 HW Version = 1.3.0
> qcom-camss ac5a000.camss: VFE:6 HW Version = 1.3.0
> qcom-camss ac5a000.camss: VFE:7 HW Version = 1.3.0
>
I understand that deduction is not straightforward, but it is also a
fixed one, meaning it will be always sc8280xp -> (vFOO, vBAR), thus the
only usefulness of above is to map each compatible to pair of two HW
versions. This can be done via debugfs interface once and stored in
public docs. No need to do that mapping every time driver probes and my
patches drop nice chunk of code, including indirect function calls.
At least so far no one objected that same compatible maps to same pairs
of HW versions.
> Whether the hw version is actually useful to anyone debugging this
> driver I can't say, but keeping it printed *once* seems perfectly
> alright if someone wants to keep it (e.g. as we have a long history of
> working around hw bugs based on revision information like this).
Now if you claim that one needs access to qcom docs to deduce it, I
claim this version would be useful only to qcom people (or
qcom-NDA-access-to-HPG) folks.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-05-20 8:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 18:08 [PATCH 1/3] media: qcom: camss: vfe: Stop spamming logs with version Krzysztof Kozlowski
2025-04-29 18:08 ` [PATCH 2/3] media: qcom: camss: csid: " Krzysztof Kozlowski
2025-04-29 18:08 ` [PATCH 3/3] media: qcom: camss: csiphy: " Krzysztof Kozlowski
2025-04-29 18:11 ` [PATCH 1/3] media: qcom: camss: vfe: " Krzysztof Kozlowski
2025-04-29 19:40 ` Bryan O'Donoghue
2025-04-30 6:15 ` Krzysztof Kozlowski
2025-04-30 7:25 ` Johan Hovold
2025-04-30 8:19 ` Krzysztof Kozlowski
2025-04-30 8:30 ` Bryan O'Donoghue
2025-04-30 8:33 ` Krzysztof Kozlowski
2025-05-20 6:06 ` Krzysztof Kozlowski
2025-05-20 7:53 ` Johan Hovold
2025-05-20 8:02 ` Krzysztof Kozlowski
2025-05-20 8:23 ` Johan Hovold
2025-05-20 8:30 ` Krzysztof Kozlowski [this message]
2025-05-20 8:39 ` Johan Hovold
2025-05-20 8:44 ` Bryan O'Donoghue
2025-05-20 8:51 ` Krzysztof Kozlowski
2025-05-20 8:58 ` Bryan O'Donoghue
2025-05-20 9:16 ` Krzysztof Kozlowski
2025-05-20 9:17 ` Johan Hovold
2025-04-30 12:31 ` Johan Hovold
2025-04-30 8:24 ` Bryan O'Donoghue
2025-04-30 12:34 ` Johan Hovold
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=8a2f2269-d07f-42b2-ab6c-dcff30a1f431@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=bryan.odonoghue@linaro.org \
--cc=johan@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rfoss@kernel.org \
--cc=todor.too@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).