Re: [PATCH v10 6/9] media: uapi: Add a control for HANTRO driver
On 05/05/2021 17:20, Benjamin Gaignard wrote:
>
> Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
>> On 20/04/2021 14:10, Benjamin Gaignard wrote:
>>> The HEVC HANTRO driver needs to know the number of bits to skip at
>>> the beginning of the slice header.
>>> That is a hardware specific requirement so create a dedicated control
>>> for this purpose.
>>>
>>> Signed-off-by: Benjamin Gaignard
>>> ---
>>> .../userspace-api/media/drivers/hantro.rst| 19 +++
>>> .../userspace-api/media/drivers/index.rst | 1 +
>>> include/media/hevc-ctrls.h| 13 +
>>> 3 files changed, 33 insertions(+)
>>> create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst
>>>
>>> diff --git a/Documentation/userspace-api/media/drivers/hantro.rst
>>> b/Documentation/userspace-api/media/drivers/hantro.rst
>>> new file mode 100644
>>> index ..cd9754b4e005
>>> --- /dev/null
>>> +++ b/Documentation/userspace-api/media/drivers/hantro.rst
>>> @@ -0,0 +1,19 @@
>>> +.. SPDX-License-Identifier: GPL-2.0
>>> +
>>> +Hantro video decoder driver
>>> +===
>>> +
>>> +The Hantro video decoder driver implements the following driver-specific
>>> controls:
>>> +
>>> +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)``
>>> +Specifies to Hantro HEVC video decoder driver the number of data (in
>>> bits) to
>>> +skip in the slice segment header.
>>> +If non-IDR, the bits to be skipped go from syntax element
>>> "pic_output_flag"
>>> +to before syntax element "slice_temporal_mvp_enabled_flag".
>>> +If IDR, the skipped bits are just "pic_output_flag"
>>> +(separate_colour_plane_flag is not supported).
>> I'm not very keen on this. Without this information the video data cannot be
>> decoded, or will it just be suboptimal?
>
> Without that information the video can't be decoded.
>
>>
>> The problem is that a generic decoder would have to know that the HW is a
>> hantro,
>> and then call this control. If they don't (and are testing on non-hantro
>> HW), then
>> it won't work, thus defeating the purpose of the HW independent decoder API.
>>
>> Since hantro is widely used, and if there is no other way to do this beside
>> explitely
>> setting this control, then perhaps this should be part of the standard HEVC
>> API.
>> Non-hantro drivers that do not need this can just skip it.
>
> Even if I put this parameter in decode_params structure that would means that
> a generic
> userland decoder will have to know how the compute this value for hantro HW
> since it
> isn't something that could be done on kernel side.
But since hantro is very common, any userland decoder will need to calculate
this anyway.
So perhaps it is better to have this as part of the decode_params?
I'd like to know what others think about this.
Regards,
Hans
>
>
> Regards,
> Benjamin
>
>>
>> Regards,
>>
>> Hans
>>
>>> +
>>> +.. note::
>>> +
>>> +This control is not yet part of the public kernel API and
>>> +it is expected to change.
>>> diff --git a/Documentation/userspace-api/media/drivers/index.rst
>>> b/Documentation/userspace-api/media/drivers/index.rst
>>> index 1a9038f5f9fa..12e3c512d718 100644
>>> --- a/Documentation/userspace-api/media/drivers/index.rst
>>> +++ b/Documentation/userspace-api/media/drivers/index.rst
>>> @@ -33,6 +33,7 @@ For more details see the file COPYING in the source
>>> distribution of Linux.
>>>
>>> ccs
>>> cx2341x-uapi
>>> +hantro
>>> imx-uapi
>>> max2175
>>> meye-uapi
>>> diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
>>> index 8e0109eea454..b713eeed1915 100644
>>> --- a/include/media/hevc-ctrls.h
>>> +++ b/include/media/hevc-ctrls.h
>>> @@ -224,4 +224,17 @@ struct v4l2_ctrl_hevc_decode_params {
>>> __u64 flags;
>>> };
>>>
>>> +/* MPEG-class control IDs specific to the Hantro driver as defined by
>>> V4L2 */
>>> +#define V4L2_CID_CODEC_HANTRO_BASE
>>> (V4L2_CTRL_CLASS_CODEC | 0x1200)
>>> +/*
>>> + * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
>>> + * the number of data (in bits) to skip in the
>>> + * slice segment header.
>>> + * If non-IDR, the bits to be skipped go from syntax element
>>> "pic_output_flag"
>>> + * to before syntax element "slice_temporal_mvp_enabled_flag".
>>> + * If IDR, the skipped bits are just "pic_output_flag"
>>> + * (separate_colour_plane_flag is not supported).
>>> + */
>>> +#define V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP
>>> (V4L2_CID_CODEC_HANTRO_BASE + 0)
>>> +
>>> #endif
>>>
>>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 6/9] media: uapi: Add a control for HANTRO driver
>On 05/05/2021 17:20, Benjamin Gaignard wrote:
>>
>> Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
>>> On 20/04/2021 14:10, Benjamin Gaignard wrote:
The HEVC HANTRO driver needs to know the number of bits to skip at
the beginning of the slice header.
That is a hardware specific requirement so create a dedicated control
for this purpose.
Signed-off-by: Benjamin Gaignard
---
.../userspace-api/media/drivers/hantro.rst| 19 +++
.../userspace-api/media/drivers/index.rst | 1 +
include/media/hevc-ctrls.h| 13 +
3 files changed, 33 insertions(+)
create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst
diff --git a/Documentation/userspace-api/media/drivers/hantro.rst
b/Documentation/userspace-api/media/drivers/hantro.rst
new file mode 100644
index ..cd9754b4e005
--- /dev/null
+++ b/Documentation/userspace-api/media/drivers/hantro.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Hantro video decoder driver
+===
+
+The Hantro video decoder driver implements the following driver-specific
controls:
+
+``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)``
+Specifies to Hantro HEVC video decoder driver the number of data (in
bits) to
+skip in the slice segment header.
+If non-IDR, the bits to be skipped go from syntax element
"pic_output_flag"
+to before syntax element "slice_temporal_mvp_enabled_flag".
+If IDR, the skipped bits are just "pic_output_flag"
+(separate_colour_plane_flag is not supported).
>>> I'm not very keen on this. Without this information the video data cannot be
>>> decoded, or will it just be suboptimal?
>>
>> Without that information the video can't be decoded.
>>
>>>
>>> The problem is that a generic decoder would have to know that the HW is a
>>> hantro,
>>> and then call this control. If they don't (and are testing on non-hantro
>>> HW), then
>>> it won't work, thus defeating the purpose of the HW independent decoder API.
>>>
>>> Since hantro is widely used, and if there is no other way to do this beside
>>> explitely
>>> setting this control, then perhaps this should be part of the standard HEVC
>>> API.
>>> Non-hantro drivers that do not need this can just skip it.
>>
>> Even if I put this parameter in decode_params structure that would means
>> that a generic
>> userland decoder will have to know how the compute this value for hantro HW
>> since it
>> isn't something that could be done on kernel side.
>
>But since hantro is very common, any userland decoder will need to calculate
>this anyway.
>So perhaps it is better to have this as part of the decode_params?
>
>I'd like to know what others think about this.
I don't know exactly what I think on this - its all a bit of a mess. I
don't think this is going to be the last HEVC decoder that needs some
non-standard setup that can't be trivially extracted from a standard
slice header parse. So if future decoders are going to have to generate
custom attributes to cope with their quirks then Hantro probably should
too. And if Hantro is common then the userspace progs will at least have
a framework for dealing with this sort of thing so when the next oddity
comes along.
Regards
John Cox
>Regards,
>
> Hans
>
>>
>>
>> Regards,
>> Benjamin
>>
>>>
>>> Regards,
>>>
>>> Hans
>>>
+
+.. note::
+
+This control is not yet part of the public kernel API and
+it is expected to change.
diff --git a/Documentation/userspace-api/media/drivers/index.rst
b/Documentation/userspace-api/media/drivers/index.rst
index 1a9038f5f9fa..12e3c512d718 100644
--- a/Documentation/userspace-api/media/drivers/index.rst
+++ b/Documentation/userspace-api/media/drivers/index.rst
@@ -33,6 +33,7 @@ For more details see the file COPYING in the source
distribution of Linux.
ccs
cx2341x-uapi
+hantro
imx-uapi
max2175
meye-uapi
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index 8e0109eea454..b713eeed1915 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -224,4 +224,17 @@ struct v4l2_ctrl_hevc_decode_params {
__u64 flags;
};
+/* MPEG-class control IDs specific to the Hantro driver as defined by
V4L2 */
+#define V4L2_CID_CODEC_HANTRO_BASE
(V4L2_CTRL_CLASS_CODEC | 0x1200)
+/*
+ * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
+ * the number of data (in bits) to skip in the
+ * slice segment header.
+ * If non-IDR, the bits to be skipped go from syntax element
"pic_output_flag"
+ * to before syntax element "slice_temporal
Re: [PATCH v10 6/9] media: uapi: Add a control for HANTRO driver
Le jeudi 06 mai 2021 à 14:11 +0100, John Cox a écrit : > > On 05/05/2021 17:20, Benjamin Gaignard wrote: > > > > > > Le 05/05/2021 à 16:55, Hans Verkuil a écrit : > > > > On 20/04/2021 14:10, Benjamin Gaignard wrote: > > > > > The HEVC HANTRO driver needs to know the number of bits to skip at > > > > > the beginning of the slice header. > > > > > That is a hardware specific requirement so create a dedicated control > > > > > for this purpose. > > > > > > > > > > Signed-off-by: Benjamin Gaignard > > > > > --- > > > > > .../userspace-api/media/drivers/hantro.rst| 19 > > > > > +++ > > > > > .../userspace-api/media/drivers/index.rst | 1 + > > > > > include/media/hevc-ctrls.h| 13 + > > > > > 3 files changed, 33 insertions(+) > > > > > create mode 100644 Documentation/userspace- > > > > > api/media/drivers/hantro.rst > > > > > > > > > > diff --git a/Documentation/userspace-api/media/drivers/hantro.rst > > > > > b/Documentation/userspace-api/media/drivers/hantro.rst > > > > > new file mode 100644 > > > > > index ..cd9754b4e005 > > > > > --- /dev/null > > > > > +++ b/Documentation/userspace-api/media/drivers/hantro.rst > > > > > @@ -0,0 +1,19 @@ > > > > > +.. SPDX-License-Identifier: GPL-2.0 > > > > > + > > > > > +Hantro video decoder driver > > > > > +=== > > > > > + > > > > > +The Hantro video decoder driver implements the following driver- > > > > > specific controls: > > > > > + > > > > > +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)`` > > > > > +Specifies to Hantro HEVC video decoder driver the number of data > > > > > (in bits) to > > > > > +skip in the slice segment header. > > > > > +If non-IDR, the bits to be skipped go from syntax element > > > > > "pic_output_flag" > > > > > +to before syntax element "slice_temporal_mvp_enabled_flag". > > > > > +If IDR, the skipped bits are just "pic_output_flag" > > > > > +(separate_colour_plane_flag is not supported). > > > > I'm not very keen on this. Without this information the video data > > > > cannot be > > > > decoded, or will it just be suboptimal? > > > > > > Without that information the video can't be decoded. > > > > > > > > > > > The problem is that a generic decoder would have to know that the HW is > > > > a hantro, > > > > and then call this control. If they don't (and are testing on non-hantro > > > > HW), then > > > > it won't work, thus defeating the purpose of the HW independent decoder > > > > API. > > > > > > > > Since hantro is widely used, and if there is no other way to do this > > > > beside explitely > > > > setting this control, then perhaps this should be part of the standard > > > > HEVC API. > > > > Non-hantro drivers that do not need this can just skip it. > > > > > > Even if I put this parameter in decode_params structure that would means > > > that a generic > > > userland decoder will have to know how the compute this value for hantro > > > HW since it > > > isn't something that could be done on kernel side. > > > > But since hantro is very common, any userland decoder will need to calculate > > this anyway. > > So perhaps it is better to have this as part of the decode_params? > > > > I'd like to know what others think about this. > > I don't know exactly what I think on this - its all a bit of a mess. I There is no better way to describe the state of my own opinion about this. > don't think this is going to be the last HEVC decoder that needs some > non-standard setup that can't be trivially extracted from a standard > slice header parse. So if future decoders are going to have to generate > custom attributes to cope with their quirks then Hantro probably should > too. And if Hantro is common then the userspace progs will at least have > a framework for dealing with this sort of thing so when the next oddity > comes along. To add to this, when we moved it out of the decode_params, we were actually making it an example. We use large structure for the common stuff because is convenient, but with the current infrastructure, the cost of adding controls is rather low. So we need to think if we want to hide or highlight what looks like hardware design specific needs. There is nothing particularly wrong in the hardware, as Hantro traditionally parse a lot of the headers, but I suppose they don't really want to implement skip parsers because at some point the hardware becomes quite big and complex, skipping bits is just trivial. One thing I've been discussing with Benjamin yesterday is that while splitting, we also made the data exactly what the HW wants, which is a skip. A more reusable representation would have been to provide two offsets in the header. This way if another HW need a different skip, but with a different stop position, you can share the start position. Though, it's no longer a 1:1 match with how the HW is programmed, so not an easy call. As for having more quirks in more HW,
Your Approved Fund
THE WORLDS LOCAL BANK International Banking FOREIGN EXCHANGE UNIT RE: MANDATORY RELEASE ORDER OF YOUR OVERDUE FUND Dear Valued Beneficiary: We are pleased to inform you that we have finally concluded arrangement towards your refund/lottery pay out which has been delayed for a Long Period of time because of your Cooperation and Dealings with Wrong Officials and importers of banks as your fund returned back to us on the 4th of Jan 2021 when we confirmed the rate of delays and questionable activities that has been related by the previous administrative banks alongside with others that collaborated in delaying the release of your fund after all charges and payments demanded were paid. Recently, the Ministry of Finance of United Kingdom, Bank of England, HSBC Bank Plc UK and United Kingdom Inland Revenue Services held a meeting on how this fund will be released to the beneficiaries to their designated bank accounts in their country without further delay since we are in the first half of the economic year 2021 and it is now overdue to be released as the said funds belongs to them. We apologize for the delay of the payment and all the inconveniences that this might have caused you during this period of time. However we have instructed all the banks in the globe which we previously asked to help us pay out this fund to the general public to STOP the process of the release of the fund due to their incompetence and negligence of duty towards the release of this fund. After our findings, some were arrested and charged for theft according to Section 1 of the Theft Act 1978, as amended by the Theft (Amendment) Act 1996 law of the United Kingdom. The Bank of England Governor (Mr Andrew Bailey) has given serious warning and Instructions and ordered the Inland Revenue Services Department of England to quickly release all on hold funds which are in their escrow account to the sole beneficiaries which you are among those who will receive their Inheritance funds. Please contact ONLY the Executive member of the Monetary Policy Committee of South African Reserve Bank (Dr Rashad Cassim) on his email: sarb_bnk...@meta.ua to advise you on how to procure the certificate of claim as the law of South Africa demands that without it there will not be any payment whether pending loan amount, lottery fund, inheritance funds or whatsoever fund locally or internationally perhaps you have not yet received it. Provide below details to Dr Rashad Cassim for his clarification: Full Name... Tel. Address. Amount.. City Country. Copies of documents pertaining to the fund. Best Regards, Mr.James Emmett. Chief Executive Officer, HSBC Bank plc. United Kingdom ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:kbuild] BUILD SUCCESS 9eb7055796f1a1b1e7a237b426d2d54c12801e10
nfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210506 i386 randconfig-a006-20210506 i386 randconfig-a001-20210506 i386 randconfig-a005-20210506 i386 randconfig-a004-20210506 i386 randconfig-a002-20210506 x86_64 randconfig-a014-20210506 x86_64 randconfig-a015-20210506 x86_64 randconfig-a012-20210506 x86_64 randconfig-a013-20210506 x86_64 randconfig-a011-20210506 x86_64 randconfig-a016-20210506 i386 randconfig-a015-20210506 i386 randconfig-a013-20210506 i386 randconfig-a016-20210506 i386 randconfig-a014-20210506 i386 randconfig-a012-20210506 i386 randconfig-a011-20210506 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a001-20210506 x86_64 randconfig-a003-20210506 x86_64 randconfig-a005-20210506 x86_64 randconfig-a002-20210506 x86_64 randconfig-a006-20210506 x86_64 randconfig-a004-20210506 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS e120332923e13d8d9386594a83dc7cbf327e3edf
mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210506 i386 randconfig-a006-20210506 i386 randconfig-a001-20210506 i386 randconfig-a005-20210506 i386 randconfig-a004-20210506 i386 randconfig-a002-20210506 x86_64 randconfig-a014-20210506 x86_64 randconfig-a015-20210506 x86_64 randconfig-a012-20210506 x86_64 randconfig-a013-20210506 x86_64 randconfig-a011-20210506 x86_64 randconfig-a016-20210506 i386 randconfig-a015-20210506 i386 randconfig-a013-20210506 i386 randconfig-a016-20210506 i386 randconfig-a014-20210506 i386 randconfig-a012-20210506 i386 randconfig-a011-20210506 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a001-20210506 x86_64 randconfig-a003-20210506 x86_64 randconfig-a005-20210506 x86_64 randconfig-a002-20210506 x86_64 randconfig-a006-20210506 x86_64 randconfig-a004-20210506 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:umn.edu-reverts] BUILD SUCCESS 7b997c23c121e00902c60e35d36c0c84898b8789
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git umn.edu-reverts branch HEAD: 7b997c23c121e00902c60e35d36c0c84898b8789 cdrom: gdrom: initialize global variable at init time elapsed time: 724m configs tested: 107 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig riscvallmodconfig x86_64 allyesconfig riscvallyesconfig i386 allyesconfig mips cu1830-neo_defconfig x86_64 alldefconfig mipsjmr3927_defconfig sparc sparc64_defconfig mips bigsur_defconfig arm sama5_defconfig m68k m5249evb_defconfig arm integrator_defconfig sh sh7724_generic_defconfig mips jazz_defconfig m68k amcore_defconfig powerpc mpc834x_mds_defconfig armoxnas_v6_defconfig arm nhk8815_defconfig sh sdk7780_defconfig powerpc rainier_defconfig powerpc katmai_defconfig powerpcwarp_defconfig microblaze mmu_defconfig archsdk_defconfig armrealview_defconfig m68k m5275evb_defconfig arm multi_v4t_defconfig powerpcsam440ep_defconfig sh kfr2r09-romimage_defconfig mips cobalt_defconfig mips ip22_defconfig arm alldefconfig x86_64allnoconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210506 i386 randconfig-a006-20210506 i386 randconfig-a001-20210506 i386 randconfig-a005-20210506 i386 randconfig-a004-20210506 i386 randconfig-a002-20210506 x86_64 randconfig-a014-20210506 x86_64 randconfig-a015-20210506 x86_64 randconfig-a012-20210506 x86_64 randconfig-a013-20210506 x86_64 randconfig-a011-20210506 x86_64 randconfig-a016-20210506 i386 randconfig-a015-20210506 i386 randconfig-a013-20210506 i386 randconfig-a016-20210506 i386 randconfig-a014-20210506 i386 randconfig-a012-20210506 i386 randconfig-a011-20210506 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin
