Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
To: Jorge Ramirez <jorge.ramirez@oss.qualcomm.com>
Cc: vikash.garodia@oss.qualcomm.com, bod@kernel.org,
	mchehab@kernel.org, linux-media@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: venus: assign unique bus_info strings for encoder and decoder
Date: Wed, 26 Nov 2025 11:01:25 +0530	[thread overview]
Message-ID: <791d7bb3-a96a-ed5c-a59c-90cbbd712ffa@oss.qualcomm.com> (raw)
In-Reply-To: <aSYdUzpqX38xxywI@trex>



On 11/26/2025 2:49 AM, Jorge Ramirez wrote:
> On 25/11/25 18:39:14, Dikshita Agarwal wrote:
>>
>>
>> On 11/25/2025 6:22 PM, Jorge Ramirez wrote:
>>> On 25/11/25 13:59:56, Dikshita Agarwal wrote:
>>>>
>>>>
>>>> On 11/22/2025 12:13 AM, Jorge Ramirez-Ortiz wrote:
>>>>> The Venus encoder and decoder video devices currently report the same
>>>>> bus_info string ("platform:qcom-venus").
>>>>>
>>>>> Assign unique bus_info identifiers by appending ":dec" and ":enc" to the
>>>>> parent device name. With this change v4l2-ctl will display two separate
>>>>> logical devices
>>>>>
>>>>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
>>>>> ---
>>>>>  drivers/media/platform/qcom/venus/vdec.c | 5 +++++
>>>>>  drivers/media/platform/qcom/venus/venc.c | 5 +++++
>>>>>  2 files changed, 10 insertions(+)
>>>>>
>>>>> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
>>>>> index 4a6641fdffcf..63f6ae1ff6ac 100644
>>>>> --- a/drivers/media/platform/qcom/venus/vdec.c
>>>>> +++ b/drivers/media/platform/qcom/venus/vdec.c
>>>>> @@ -433,9 +433,14 @@ vdec_g_selection(struct file *file, void *fh, struct v4l2_selection *s)
>>>>>  static int
>>>>>  vdec_querycap(struct file *file, void *fh, struct v4l2_capability *cap)
>>>>>  {
>>>>> +	struct venus_inst *inst = to_inst(file);
>>>>> +	struct venus_core *core = inst->core;
>>>>> +
>>>>>  	strscpy(cap->driver, "qcom-venus", sizeof(cap->driver));
>>>>>  	strscpy(cap->card, "Qualcomm Venus video decoder", sizeof(cap->card));
>>>>>  	strscpy(cap->bus_info, "platform:qcom-venus", sizeof(cap->bus_info));
>>>>> +	snprintf(cap->bus_info, sizeof(cap->bus_info),
>>>>> +		 "platform:%s:dec", dev_name(core->dev));
>>>>
>>>> Is there a reason to keep both strscpy() and snprintf() for cap->bus_info?
>>>> The second call to snprintf() seems to overwrite the value set by
>>>> strscpy(), making the first assignment redundant. Would it be cleaner to
>>>> remove the strscpy() line and rely solely on snprintf()?
>>>
>>> argh, my bad, you are right. will fix.
>>>
>>> perhaps we should just have instead
>>>
>>> decoder:
>>> strscpy(cap->bus_info,"platform:qcom-venus-dec", sizeof(cap->bus_info));
>>>
>>> encoder:
>>> strscpy(cap->bus_info, "platform:qcom-venus-enc",sizeof(cap->bus_info)); on the encoder
>>>
>>> I suppose the additional info provided by the dev_name is not really
>>> important to consumers.
>>
>> In-fact, we don't even need to fill the bus_info, received a similar
>> comment on iris [1]
>> [1]:
>> https://lore.kernel.org/linux-media/c4350128-a05c-47af-a7e7-2810171cd311@xs4all.nl/
> 
> 
> Nope, that is wrong. 
> 
> if we dont fill bus_info we will end up with the following again:
> 
> root@qrb2210-rb1-core-kit:~# v4l2-ctl --list-devices
> Qualcomm Venus video encoder (platform:5a00000.video-codec):
> 	 /dev/video0
> 	 /dev/video1  
> 
> instead of something like this:
> 
> root@qrb2210-rb1-core-kit:~# v4l2-ctl --list-devices
> Qualcomm Venus video decoder (platform:qcom-venus_dec):
> 	 /dev/video1
> 
> Qualcomm Venus video encoder (platform:qcom-venus_enc):
> 	 /dev/video0

Got it.

Thanks,
Dikshita

      reply	other threads:[~2025-11-26  5:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3FJhEomSdQ2CUrDJZaWiNVmSKYmUGylmoUUZc_15p0xnLmG_gydDxIyJDrUnemnatDXNOtQAqbWytjZ-xZAJ_w==@protonmail.internalid>
2025-11-21 18:43 ` [PATCH] media: venus: assign unique bus_info strings for encoder and decoder Jorge Ramirez-Ortiz
2025-11-21 19:22   ` Konrad Dybcio
2025-11-25 12:55     ` Jorge Ramirez
2025-11-27 11:47       ` Konrad Dybcio
2025-11-27 17:11         ` Jorge Ramirez
2025-11-27 18:34           ` Konrad Dybcio
2025-11-22 16:17   ` Bryan O'Donoghue
2025-11-25  8:29   ` Dikshita Agarwal
2025-11-25 12:52     ` Jorge Ramirez
2025-11-25 13:09       ` Dikshita Agarwal
2025-11-25 21:19         ` Jorge Ramirez
2025-11-26  5:31           ` Dikshita Agarwal [this message]

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=791d7bb3-a96a-ed5c-a59c-90cbbd712ffa@oss.qualcomm.com \
    --to=dikshita.agarwal@oss.qualcomm.com \
    --cc=bod@kernel.org \
    --cc=jorge.ramirez@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=vikash.garodia@oss.qualcomm.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