Re: [PATCH 1/3] media: qcom: camss: vfe: Stop spamming logs with version

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 20/05/2025 09:30, Krzysztof Kozlowski wrote:
> 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

I find the debug prints useful in that I know the hardware block has 
been powered on, clocked etc. I agree the number of those prints seems 
excessive.

The reason it is printed out multiple time is the blocks get powered on/off.

Personally I agree with Johan - it would be nice/useful to print it out 
once with DEBUG on, so that we know we have successfully powered-on and 
identified the blocks once.

Doing it over and over again is excessive as failure to power-on will 
surely produce error messages anyway.

---
bod