Linux Media Controller development
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Tsuchiya Yuto <kitakar@gmail.com>,
	Yury Luneff <yury.lunev@gmail.com>,
	Nable <nable.maininbox@googlemail.com>,
	andrey.i.trufanov@gmail.com, Fabio Aiuto <fabioaiuto83@gmail.com>,
	Kate Hsuan <hpa@redhat.com>,
	linux-media@vger.kernel.org, linux-staging@lists.linux.dev
Subject: Re: [PATCH 3/3] media: atomisp: Improve binary finding debug logging
Date: Tue, 3 Sep 2024 11:27:19 +0200	[thread overview]
Message-ID: <a3363c07-6595-450d-abe0-c1ff4a3e9955@redhat.com> (raw)
In-Reply-To: <ZtWpi7_S5d7NZx61@smile.fi.intel.com>

Hi Andy,

Thank you for the reviews.

On 9/2/24 2:03 PM, Andy Shevchenko wrote:
> On Mon, Sep 02, 2024 at 11:52:29AM +0200, Hans de Goede wrote:
>> The atomisp firmware contains a number of different pipeline binaries
>> inside its firmware file and the driver selects the right one depending
>> on the selected pipeline configuration.
>>
>> Sometimes (e.g. when the selected output resolution is too big) it fails
>> to find a binary. This happens especially when adding support for new
>> sensors.
>>
>> Improve the logging when this happens to make debugging easier:
>>
>> 1. Replace ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, ...) with standard
>>    dev_dbg() calls so that the logs can be enabled with dyndbg
>>
>> 2. Do not dump_stack() when this fails, doing so adds no useful extra
>>    info
>>
>> 3. With the dump_stack() call gone, remove the wrapper and rename
>>    __ia_css_binary_find() to ia_css_binary_find()
>>
>> 4. On error use dev_err() instead of dev_dbg() so that when things
>>    fail it is clear why they fail without needing to enable dyndbg
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> Note the log messages could also do with a bit of rewording and
>> reflowing them to put more arguments on a single line to use less
>> lines. I consider that out of scope for this patch which already
>> enough (see the 1-4 enough) something like this should be done
>> in a follow-up patch IMHO.
> 
> Yes, but...
> 
> ...
> 
>> -static int __ia_css_binary_find(struct ia_css_binary_descr *descr,
>> -				struct ia_css_binary *binary) {
>> +int ia_css_binary_find(struct ia_css_binary_descr *descr,
>> +		       struct ia_css_binary *binary)
> 
> ...for example, in this case you touched both lines, so making them a single
> line just reduces the future churn.

Ack, fixed in my media-atomisp branch.

> 
> ...
> 
>> -	ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE,
>> -			    "ia_css_binary_find() enter: descr=%p, (mode=%d), binary=%p\n",
>> -			    descr, descr->mode,
>> -			    binary);
>> +	dev_dbg(atomisp_dev,
>> +		"ia_css_binary_find() enter: descr=%p, (mode=%d), binary=%p\n",
> 
>> +		descr, descr->mode,
>> +		binary);
> 
> So does this.

Ack, fixed in my media-atomisp branch.

> 
> ...
> 
>>  	/* print a map of the binary file */
>> -	ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE,	"BINARY INFO:\n");
>> +	dev_dbg(atomisp_dev,	"BINARY INFO:\n");
> 
> TAB instead of space.

Ack, fixed in my media-atomisp branch.

> ...
> 
>> -			ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE,
>> -					    "ia_css_binary_find() [%d] continue: !%d && %d && (%d != %d)\n",
>> -					    __LINE__, candidate->enable.continuous,
>> -					    continuous, mode,
>> -					    IA_CSS_BINARY_MODE_COPY);
>> +			dev_dbg(atomisp_dev,
>> +				"ia_css_binary_find() [%d] continue: !%d && %d && (%d != %d)\n",
>> +				__LINE__, candidate->enable.continuous,
> 
>> +				continuous, mode,
>> +				IA_CSS_BINARY_MODE_COPY);
> 
> Now one line?

Ack, fixed in my media-atomisp branch.

> ...
> 
>> -			ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE,
>> -					    "ia_css_binary_find() [%d] continue: binary is not striped\n",
>> -					    __LINE__);
>> +			dev_dbg(atomisp_dev,
>> +				"ia_css_binary_find() [%d] continue: binary is not striped\n",
>> +				__LINE__);
> 
> Now the __LINE__ argument is redundant as one may run-time turn it on and off.
> So, trimming it while converting to dev_dbg() makes sense to me as a one
> logical change. Ditto for other __LINE__ cases.

Dropping __LINE__ is the bit which I want to postpone to a follow-up patch,
the messages rejecting certain binaries as not suitable are not very
unique and the __LINE__ print is necessary (atm) to help find which check
exactly is failing. Not ideal I know, something for the TODO list.

> Otherwise it's a good clean up!

Thanks.

Regards,

Hans


  reply	other threads:[~2024-09-03  9:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02  9:52 [PATCH 1/3] media: atomisp: csi2-bridge: Add DMI quirk for t4ka3 on Xiaomi Mipad2 Hans de Goede
2024-09-02  9:52 ` [PATCH 2/3] media: atomisp: Drop dev_dbg() calls from hmm_[alloc|free]() Hans de Goede
2024-09-02 11:06   ` Andy Shevchenko
2024-09-02  9:52 ` [PATCH 3/3] media: atomisp: Improve binary finding debug logging Hans de Goede
2024-09-02 12:03   ` Andy Shevchenko
2024-09-03  9:27     ` Hans de Goede [this message]
2024-09-03 10:30       ` Andy Shevchenko
2024-09-03 11:12         ` Hans de Goede
2024-09-02 10:37 ` [PATCH 1/3] media: atomisp: csi2-bridge: Add DMI quirk for t4ka3 on Xiaomi Mipad2 Hans de Goede
2024-09-02 11:06 ` Andy Shevchenko

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=a3363c07-6595-450d-abe0-c1ff4a3e9955@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andrey.i.trufanov@gmail.com \
    --cc=andy@kernel.org \
    --cc=fabioaiuto83@gmail.com \
    --cc=hpa@redhat.com \
    --cc=kitakar@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=nable.maininbox@googlemail.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=yury.lunev@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