mbox series

[v2,0/3] Add NVIDIA Tegra114 support to video decoder driver

Message ID 20211114224732.11550-1-digetx@gmail.com (mailing list archive)
Headers show
Series Add NVIDIA Tegra114 support to video decoder driver | expand

Message

Dmitry Osipenko Nov. 14, 2021, 10:47 p.m. UTC
Video decoder of Tegra114/124 SoCs uses additional memory buffer required
for decoding of protected content. We won't support that content, but it
is impossible to disable access to the buffer, hence a stub buffer needs
to be provided. This series enables decoder driver only for Tegra114
because Tegra124 support requires more non-trivial changes on both kernel
and userspace sides.

Changelog:

v2: - Changed tegra_vde_alloc_bo() to return errno and fix unassigned
      error code in tegra_vde_probe().

Dmitry Osipenko (1):
  media: staging: tegra-vde: Reorder misc device registration

Thierry Reding (2):
  media: staging: tegra-vde: Support reference picture marking
  media: staging: tegra-vde: Properly mark invalid entries

 drivers/staging/media/tegra-vde/vde.c | 147 +++++++++++++++++++++++---
 drivers/staging/media/tegra-vde/vde.h |  18 ++++
 2 files changed, 152 insertions(+), 13 deletions(-)

Comments

Nicolas Dufresne Nov. 15, 2021, 2:43 p.m. UTC | #1
Hi Dmitry,

Le lundi 15 novembre 2021 à 01:47 +0300, Dmitry Osipenko a écrit :
> Video decoder of Tegra114/124 SoCs uses additional memory buffer required
> for decoding of protected content. We won't support that content, but it
> is impossible to disable access to the buffer, hence a stub buffer needs
> to be provided. This series enables decoder driver only for Tegra114
> because Tegra124 support requires more non-trivial changes on both kernel
> and userspace sides.

I believe the stateless API is quite in place now, but I only see maintenance on
this staging driver. I don't believe it really make sense to keep maintaining a
staging driver without any step forward de-staging it. I believe it gives the
wrong message on the Kernel staging purpose.

I'm not criticizing your effort, I believe you are doing nice work for you
community, but would prefer to see this driver be ported to the official kernel
APIs rather then being maintain as staging till the end of time.

regards,
Nicolas

> 
> Changelog:
> 
> v2: - Changed tegra_vde_alloc_bo() to return errno and fix unassigned
>       error code in tegra_vde_probe().
> 
> Dmitry Osipenko (1):
>   media: staging: tegra-vde: Reorder misc device registration
> 
> Thierry Reding (2):
>   media: staging: tegra-vde: Support reference picture marking
>   media: staging: tegra-vde: Properly mark invalid entries
> 
>  drivers/staging/media/tegra-vde/vde.c | 147 +++++++++++++++++++++++---
>  drivers/staging/media/tegra-vde/vde.h |  18 ++++
>  2 files changed, 152 insertions(+), 13 deletions(-)
>
Hans Verkuil Nov. 15, 2021, 2:49 p.m. UTC | #2
On 15/11/2021 15:43, Nicolas Dufresne wrote:
> Hi Dmitry,
> 
> Le lundi 15 novembre 2021 à 01:47 +0300, Dmitry Osipenko a écrit :
>> Video decoder of Tegra114/124 SoCs uses additional memory buffer required
>> for decoding of protected content. We won't support that content, but it
>> is impossible to disable access to the buffer, hence a stub buffer needs
>> to be provided. This series enables decoder driver only for Tegra114
>> because Tegra124 support requires more non-trivial changes on both kernel
>> and userspace sides.
> 
> I believe the stateless API is quite in place now, but I only see maintenance on
> this staging driver. I don't believe it really make sense to keep maintaining a
> staging driver without any step forward de-staging it. I believe it gives the
> wrong message on the Kernel staging purpose.
> 
> I'm not criticizing your effort, I believe you are doing nice work for you
> community, but would prefer to see this driver be ported to the official kernel
> APIs rather then being maintain as staging till the end of time.

I agree with Nicolas here. This driver only support H264 and the stateless API
for that is now in mainline. So there is no reason not to convert to the
stateless codec API and move this driver to mainline.

It would be really nice to see that happen.

Without any progress on that I am inclined to remove this driver some time
next year.

Regards,

	Hans

> 
> regards,
> Nicolas
> 
>>
>> Changelog:
>>
>> v2: - Changed tegra_vde_alloc_bo() to return errno and fix unassigned
>>       error code in tegra_vde_probe().
>>
>> Dmitry Osipenko (1):
>>   media: staging: tegra-vde: Reorder misc device registration
>>
>> Thierry Reding (2):
>>   media: staging: tegra-vde: Support reference picture marking
>>   media: staging: tegra-vde: Properly mark invalid entries
>>
>>  drivers/staging/media/tegra-vde/vde.c | 147 +++++++++++++++++++++++---
>>  drivers/staging/media/tegra-vde/vde.h |  18 ++++
>>  2 files changed, 152 insertions(+), 13 deletions(-)
>>
>
Dmitry Osipenko Nov. 15, 2021, 3:12 p.m. UTC | #3
15.11.2021 17:49, Hans Verkuil пишет:
> On 15/11/2021 15:43, Nicolas Dufresne wrote:
>> Hi Dmitry,
>>
>> Le lundi 15 novembre 2021 à 01:47 +0300, Dmitry Osipenko a écrit :
>>> Video decoder of Tegra114/124 SoCs uses additional memory buffer required
>>> for decoding of protected content. We won't support that content, but it
>>> is impossible to disable access to the buffer, hence a stub buffer needs
>>> to be provided. This series enables decoder driver only for Tegra114
>>> because Tegra124 support requires more non-trivial changes on both kernel
>>> and userspace sides.
>>
>> I believe the stateless API is quite in place now, but I only see maintenance on
>> this staging driver. I don't believe it really make sense to keep maintaining a
>> staging driver without any step forward de-staging it. I believe it gives the
>> wrong message on the Kernel staging purpose.
>>
>> I'm not criticizing your effort, I believe you are doing nice work for you
>> community, but would prefer to see this driver be ported to the official kernel
>> APIs rather then being maintain as staging till the end of time.
> 
> I agree with Nicolas here. This driver only support H264 and the stateless API
> for that is now in mainline. So there is no reason not to convert to the
> stateless codec API and move this driver to mainline.
> 
> It would be really nice to see that happen.
> 
> Without any progress on that I am inclined to remove this driver some time
> next year.

I'll prioritize the v4l patches of this driver. The reason it wasn't
done yet is because the current custom UAPI works perfectly fine and I
was busy with a bit more important patches so far.