Re: [PATCH v2 2/2] media: imagination: Add E5010 JPEG Encoder driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Krzysztof, Nicholas,

Thanks for the quick review.

On 27/07/23 19:49, Nicolas Dufresne wrote:
> Hi Krzysztof,
> 
> Le jeudi 27 juillet 2023 à 14:13 +0200, Krzysztof Kozlowski a écrit :
>> On 27/07/2023 13:25, Devarsh Thakkar wrote:
>> ...
>>
>>> +
>>> +static int e5010_release(struct file *file)
>>> +{
>>> +	struct e5010_dev *dev = video_drvdata(file);
>>> +	struct e5010_context *ctx = file->private_data;
>>> +
>>> +	dprintk(dev, 1, "Releasing instance: 0x%p, m2m_ctx: 0x%p\n", ctx, ctx->fh.m2m_ctx);
>>
>> Why do you print pointers? Looks like code is buggy and you still keep
>> debugging it.
> 
> Its relatively common practice in linux-media to leave a certain level of traces
> to help future debugging if a bug is seen. These uses v4l2 debug helper, and are
> only going to print if users enable them through the associated sysfs
> configuration. I do hope though there isn't any issue with IRQ triggering after
> the instance is released, that would be buggy for sure, but I don't think this
> is the case considering the level of documented testing that have been done.
> 
> I'd be happy to see what others have to say on the subject, as its been a
> recurrent subject of confrontation lately. With pretty agressive messages
> associated with that.
> 
> regards,
> Nicolas
> 
> p.s. does not invalidate the question, since for this driver, there is only ever
> going to be one m2m_ctx, so the question "Why do you print pointers?" is
> entirely valid I believe.
> 

There is a possible scenario with multiple applications accessing the device
node simultaneously (and so multiple m2m_ctx are possible as seen in below
logs) and these prints were helpful to debug/analyze these scenarios.

[181955.443632] e5010 fd20000.e5010: e5010_open: Created instance:
0x00000000bea83b70, m2m_ctx: 0x00000000d068a951
[181955.449587] e5010 fd20000.e5010: e5010_open: Created instance:
0x0000000046749df9, m2m_ctx: 0x000000000ff56aa6
[181955.450407] e5010 fd20000.e5010: e5010_open: Created instance:
0x00000000e33791b5, m2m_ctx: 0x00000000217634a8
[181955.457067] e5010 fd20000.e5010: e5010_open: Created instance:
0x00000000d77f83fe, m2m_ctx: 0x000000000c8ec99e


Infact, actually I had added these prints while debugging an issue with this
type of multistream scenario, where I was launching like 20 instances of JPEG
encoding and some of the instances were hanging, these prints were helpful to
fix that scenario and I later still kept these prints as they may help in
future in case any issue is encountered while adding a new feature or in
further testing.

I have also already put the logs for this multi-stream scenario in gist shared
in commit message, below is the exact line :

https://gist.github.com/devarsht/ea31179199393c2026ae457219bb6321#file-e5010_jpeg_upstream_manualtests-txt-L89


Regards
Devarsh
> . . .



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux