hi
Please reply me back I am Sgt.Sherri.
dvbv5-scan --- report bugs to Mauro Carvalho Chehab
Hi. I think I ran into a bug, but... I have a 3 way lnb setup, with a TBS HD capable satellite tuner. I am in Netherlands, Europe, and therefore I can receive Astra2 channels ( mainly UK based channels) with the old dvbscan, I can tune and record from stations on frequency 10714 : FIlm4 and More4 +1 , they are both free to air. With the dvbv5-scan, (and consequently also kaffeine ) I am not able to scan, tune to or record from these channels. My scan file looks like this: _ =>cat x6 S 10714000 H 2200 5/6 __ #dvbv5-scan -V dvbv5-scan version 1.8.0 =>dvbv5-scan -S 2 -w -1 -I CHANNEL -l UNIVERSAL x6 Using LNBf UNIVERSAL Europe 10800 to 11800 MHz and 11600 to 12700 MHz Dual LO, IF = lowband 9750 MHz, highband 10600 MHz ERROR command BANDWIDTH_HZ (5) not found during retrieve Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet). Scanning frequency #1 10714000 RF (0x01) Signal= -37.00dBm 4.4.114-42-vanilla:vmhost1:/root _ with the same x6 file and using dvbscan : I do get the stations on that frequency. Any suggestion if I am doing something wrong / what is going on here ?? # rpm -qf `which dvbscan ` dvb-1.1.1_20150120-3.2.x86_64 _ # dvbscan -s 2 -l UNIVERSAL x6 scanning x6 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 10714000 H 2200 5 >>> tune to: 10714:h:2:22000 DVB-S IF freq is 964000 0x 0x23fb: pmt_pid 0x0100 BSkyB -- Channel 4 (running) 0x 0x23fc: pmt_pid 0x0101 BSkyB -- Channel 4 (running) 0x 0x23fd: pmt_pid 0x0102 BSkyB -- Channel 4 (running) 0x 0x23fe: pmt_pid 0x0103 BSkyB -- Channel 4 (running) 0x 0x2400: pmt_pid 0x0105 BSkyB -- Channel 4 (running) 0x 0x2404: pmt_pid 0x010a BSkyB -- Film4 (running) 0x 0x240e: pmt_pid 0x0108 BSkyB -- More4+1 (running) 0x 0x240f: pmt_pid 0x010b BSkyB -- More4 (running, scrambled) 0x 0x2419: pmt_pid 0x0107 BSkyB -- E4 (running) 0x 0x241d: pmt_pid 0x010d BSkyB -- Channel 4+1 (running, scrambled) 0x 0x2422: pmt_pid 0x0109 BSkyB -- E4+1 (running, scrambled) 0x 0x2441: pmt_pid 0x0106 BSkyB -- c4 l (running) Network Name 'ASTRA' __ -- Met vriendelijke groet / Best regards, Rens
Re: [PATCH v4 5/6] media: Add controls for JPEG quantization tables
Hi Ezequiel, On 03/09/2018 18:15, Ezequiel Garcia wrote: On Mon, 2018-09-03 at 16:51 +0100, Ian Arkver wrote: Hi Hans, Ezequiel, On 03/09/2018 16:33, Hans Verkuil wrote: On 09/03/2018 05:27 PM, Ezequiel Garcia wrote: Hi Ian, Hans: On Mon, 2018-09-03 at 14:29 +0100, Ian Arkver wrote: Hi, On 03/09/2018 10:50, Hans Verkuil wrote: On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: From: Shunqian Zheng Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace configure the JPEG quantization tables. Signed-off-by: Shunqian Zheng Signed-off-by: Ezequiel Garcia --- .../media/uapi/v4l/extended-controls.rst | 23 +++ .../media/videodev2.h.rst.exceptions | 1 + drivers/media/v4l2-core/v4l2-ctrls.c | 10 include/uapi/linux/v4l2-controls.h| 5 include/uapi/linux/videodev2.h| 1 + 5 files changed, 40 insertions(+) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index 9f7312bf3365..e0dd03e452de 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -3354,7 +3354,30 @@ JPEG Control IDs Specify which JPEG markers are included in compressed stream. This control is valid only for encoders. +.. _jpeg-quant-tables-control: +``V4L2_CID_JPEG_QUANTIZATION (struct)`` +Specifies the luma and chroma quantization matrices for encoding +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The two matrices +must be set in JPEG zigzag order, as per the JPEG specification. Can you change "JPEG specification" to a reference to the JPEG spec entry in bibio.rst? + + +.. c:type:: struct v4l2_ctrl_jpeg_quantization + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_jpeg_quantization +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - __u8 + - ``luma_quantization_matrix[64]`` + - Sets the luma quantization table. + +* - __u8 + - ``chroma_quantization_matrix[64]`` + - Sets the chroma quantization table. Just checking: the JPEG standard specifies this as unsigned 8-bit values as well? I thought this was already discussed, but I think the only thing I've added is this comment in one of the driver's headers: JPEG encoder The VPU JPEG encoder produces JPEG baseline sequential format. The quantization coefficients are 8-bit values, complying with the baseline specification. Therefore, it requires application-defined luma and chroma quantization tables. The hardware does entrophy encoding using internal Huffman tables, as specified in the JPEG specification. Certainly controls should be specified better. As far as I can see ISO/IEC 10918-1 does not specify the precision or signedness of the quantisation value Qvu. The default tables for 8-bit baseline JPEG all fit into __u8 though. Paragraph 4.7 of that spec, indicates the "sample" precision: 8-bit for baseline; 8-bit or 12-bit for extended. For the quantization coefficients, the DQT segment contains a bit that indicates if the quantization coefficients are 8-bit or 16-bit. See B.2.4.1 for details. See below (and Tq which follows the Pq field) However there can be four sets of tables in non-baseline JPEG and it's You lost me here, which four sets of tables are you refering to? not clear (to me) whether 12-bit JPEG would need more precision (I'd guess it would). It seems it would. From B.2.4.1: "An 8-bit DCT-based process shall not use a 16-bit precision quantization table." Since this patch is defining UAPI I think it might be good to build in some additional information, eg. number of tables, element size. Maybe this can all be inferred from the selected pixel format? If so then it would need documented that the above structure only applies to baseline. For quantization coefficients, I can only see two tables: one for luma one for chroma. Huffman coefficients are a different story and we are not really adding them here. I was looking at the definition of Tqi in the frame header in B.2.2 which seems to allow up to four (sets of?) quantization tables. Rereading it, it seems these are per component. Table B.2 implies that this applies to Baseline Sequential too. In the DQT marker description there's a Tq field to specify the destination for the new table. I think this means that an encoder can use up to four (sets of) tables and a decoder should be able to store four from the stream. This may well not be relevant to the encoder under discussion, but if it's not allowed for in UAPI it's almost a given that it'll need to be added later. Hm, I think it's not really relevant for us, either on the encoding or decoding side. Let me explain how I read the spec. First of all, keep in mind it seems to be written with streams in mind, which explains different
Give retouching for your images
Hi, I would like to take the chance to speak with the person who handle your images in your company? Our ability of imaging editing. Cutting out for your images Clipping path for your images Masking for your images Retouching for your images Retouching for the Portraits images We have 17 photo editors in house and daily basis 700 images can be done. We can give testing for your photos if you send us one or two to start working. Thanks, Jason Jones
Give retouching for your images
Hi, I would like to take the chance to speak with the person who handle your images in your company? Our ability of imaging editing. Cutting out for your images Clipping path for your images Masking for your images Retouching for your images Retouching for the Portraits images We have 17 photo editors in house and daily basis 700 images can be done. We can give testing for your photos if you send us one or two to start working. Thanks, Jason Jones
Re: [PATCH v4 5/6] media: Add controls for JPEG quantization tables
On Mon, 2018-09-03 at 16:51 +0100, Ian Arkver wrote: > Hi Hans, Ezequiel, > > On 03/09/2018 16:33, Hans Verkuil wrote: > > On 09/03/2018 05:27 PM, Ezequiel Garcia wrote: > > > Hi Ian, Hans: > > > > > > On Mon, 2018-09-03 at 14:29 +0100, Ian Arkver wrote: > > > > Hi, > > > > > > > > On 03/09/2018 10:50, Hans Verkuil wrote: > > > > > On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: > > > > > > From: Shunqian Zheng > > > > > > > > > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > > > > > configure the JPEG quantization tables. > > > > > > > > > > > > Signed-off-by: Shunqian Zheng > > > > > > Signed-off-by: Ezequiel Garcia > > > > > > --- > > > > > >.../media/uapi/v4l/extended-controls.rst | 23 > > > > > > +++ > > > > > >.../media/videodev2.h.rst.exceptions | 1 + > > > > > >drivers/media/v4l2-core/v4l2-ctrls.c | 10 > > > > > >include/uapi/linux/v4l2-controls.h| 5 > > > > > >include/uapi/linux/videodev2.h| 1 + > > > > > >5 files changed, 40 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > > > > > b/Documentation/media/uapi/v4l/extended-controls.rst > > > > > > index 9f7312bf3365..e0dd03e452de 100644 > > > > > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > > > > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > > > > > @@ -3354,7 +3354,30 @@ JPEG Control IDs > > > > > >Specify which JPEG markers are included in compressed > > > > > > stream. This > > > > > >control is valid only for encoders. > > > > > > > > > > > > +.. _jpeg-quant-tables-control: > > > > > > > > > > > > +``V4L2_CID_JPEG_QUANTIZATION (struct)`` > > > > > > +Specifies the luma and chroma quantization matrices for > > > > > > encoding > > > > > > +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The two > > > > > > matrices > > > > > > +must be set in JPEG zigzag order, as per the JPEG > > > > > > specification. > > > > > > > > > > Can you change "JPEG specification" to a reference to the JPEG spec > > > > > entry > > > > > in bibio.rst? > > > > > > > > > > > + > > > > > > + > > > > > > +.. c:type:: struct v4l2_ctrl_jpeg_quantization > > > > > > + > > > > > > +.. cssclass:: longtable > > > > > > + > > > > > > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization > > > > > > +:header-rows: 0 > > > > > > +:stub-columns: 0 > > > > > > +:widths: 1 1 2 > > > > > > + > > > > > > +* - __u8 > > > > > > + - ``luma_quantization_matrix[64]`` > > > > > > + - Sets the luma quantization table. > > > > > > + > > > > > > +* - __u8 > > > > > > + - ``chroma_quantization_matrix[64]`` > > > > > > + - Sets the chroma quantization table. > > > > > > > > > > Just checking: the JPEG standard specifies this as unsigned 8-bit > > > > > values as well? > > > > > > I thought this was already discussed, but I think the only thing I've > > > added > > > is this comment in one of the driver's headers: > > > > > > JPEG encoder > > > > > > The VPU JPEG encoder produces JPEG baseline sequential format. > > > The quantization coefficients are 8-bit values, complying with > > > the baseline specification. Therefore, it requires application-defined > > > luma and chroma quantization tables. The hardware does entrophy > > > encoding using internal Huffman tables, as specified in the JPEG > > > specification. > > > > > > Certainly controls should be specified better. > > > > > > > As far as I can see ISO/IEC 10918-1 does not specify the precision or > > > > signedness of the quantisation value Qvu. The default tables for 8-bit > > > > baseline JPEG all fit into __u8 though. > > > > > > > > > > Paragraph 4.7 of that spec, indicates the "sample" precision: > > > 8-bit for baseline; 8-bit or 12-bit for extended. > > > > > > For the quantization coefficients, the DQT segment contains a bit > > > that indicates if the quantization coefficients are 8-bit or 16-bit. > > > See B.2.4.1 for details. > > See below (and Tq which follows the Pq field) > > > > > > > > However there can be four sets of tables in non-baseline JPEG and it's > > > > > > You lost me here, which four sets of tables are you refering to? > > > > > > > not clear (to me) whether 12-bit JPEG would need more precision (I'd > > > > guess it would). > > > > > > It seems it would. From B.2.4.1: > > > > > > "An 8-bit DCT-based process shall not use a 16-bit precision quantization > > > table." > > > > > > > Since this patch is defining UAPI I think it might be > > > > good to build in some additional information, eg. number of tables, > > > > element size. Maybe this can all be inferred from the selected pixel > > > > format? If so then it would need documented that the above structure > > > > only applies to baseline. > > > > > > > > > > For quantization
[GIT PULL FOR v4.20] uvcvideo changes
Hi Mauro, The following changes since commit d842a7cf938b6e0f8a1aa9f1aec0476c9a599310: media: adv7842: enable reduced fps detection (2018-08-31 10:03:51 -0400) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/uvc-next-20180903 for you to fetch changes up to 8cefb491d85d35e9a2279a98f2545c10718524d7: media: uvcvideo: Add a D4M camera description (2018-09-03 19:00:47 +0300) UVC changes for v4.20 Colin Ian King (1): media: uvcvideo: Fix spelling mistake: "entites" -> "entities" Guennadi Liakhovetski (2): media: uvcvideo: Rename UVC_QUIRK_INFO to UVC_INFO_QUIRK media: uvcvideo: Add a D4M camera description Gustavo A. R. Silva (1): media: uvcvideo: Remove unnecessary NULL check before debugfs_remove_recursive Joe Perches (1): media: uvcvideo: Make some structs const Laurent Pinchart (2): media: uvcvideo: Make uvc_control_mapping menu_info field const media: uvcvideo: Store device information pointer in struct uvc_device Nadav Amit (1): media: uvcvideo: Fix uvc_alloc_entity() allocation alignment Documentation/media/uapi/v4l/meta-formats.rst | 1 + Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst | 210 + drivers/media/usb/uvc/uvc_ctrl.c | 14 +- drivers/media/usb/uvc/uvc_debugfs.c | 6 +- drivers/media/usb/uvc/uvc_driver.c| 53 +++--- drivers/media/usb/uvc/uvc_metadata.c | 7 +- drivers/media/usb/uvc/uvcvideo.h | 10 +- include/uapi/linux/videodev2.h| 1 + 8 files changed, 261 insertions(+), 41 deletions(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst -- Regards, Laurent Pinchart
Re: [PATCH v4 5/6] media: Add controls for JPEG quantization tables
Hi Hans, Ezequiel, On 03/09/2018 16:33, Hans Verkuil wrote: On 09/03/2018 05:27 PM, Ezequiel Garcia wrote: Hi Ian, Hans: On Mon, 2018-09-03 at 14:29 +0100, Ian Arkver wrote: Hi, On 03/09/2018 10:50, Hans Verkuil wrote: On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: From: Shunqian Zheng Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace configure the JPEG quantization tables. Signed-off-by: Shunqian Zheng Signed-off-by: Ezequiel Garcia --- .../media/uapi/v4l/extended-controls.rst | 23 +++ .../media/videodev2.h.rst.exceptions | 1 + drivers/media/v4l2-core/v4l2-ctrls.c | 10 include/uapi/linux/v4l2-controls.h| 5 include/uapi/linux/videodev2.h| 1 + 5 files changed, 40 insertions(+) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index 9f7312bf3365..e0dd03e452de 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -3354,7 +3354,30 @@ JPEG Control IDs Specify which JPEG markers are included in compressed stream. This control is valid only for encoders. +.. _jpeg-quant-tables-control: +``V4L2_CID_JPEG_QUANTIZATION (struct)`` +Specifies the luma and chroma quantization matrices for encoding +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The two matrices +must be set in JPEG zigzag order, as per the JPEG specification. Can you change "JPEG specification" to a reference to the JPEG spec entry in bibio.rst? + + +.. c:type:: struct v4l2_ctrl_jpeg_quantization + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_jpeg_quantization +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - __u8 + - ``luma_quantization_matrix[64]`` + - Sets the luma quantization table. + +* - __u8 + - ``chroma_quantization_matrix[64]`` + - Sets the chroma quantization table. Just checking: the JPEG standard specifies this as unsigned 8-bit values as well? I thought this was already discussed, but I think the only thing I've added is this comment in one of the driver's headers: JPEG encoder The VPU JPEG encoder produces JPEG baseline sequential format. The quantization coefficients are 8-bit values, complying with the baseline specification. Therefore, it requires application-defined luma and chroma quantization tables. The hardware does entrophy encoding using internal Huffman tables, as specified in the JPEG specification. Certainly controls should be specified better. As far as I can see ISO/IEC 10918-1 does not specify the precision or signedness of the quantisation value Qvu. The default tables for 8-bit baseline JPEG all fit into __u8 though. Paragraph 4.7 of that spec, indicates the "sample" precision: 8-bit for baseline; 8-bit or 12-bit for extended. For the quantization coefficients, the DQT segment contains a bit that indicates if the quantization coefficients are 8-bit or 16-bit. See B.2.4.1 for details. See below (and Tq which follows the Pq field) However there can be four sets of tables in non-baseline JPEG and it's You lost me here, which four sets of tables are you refering to? not clear (to me) whether 12-bit JPEG would need more precision (I'd guess it would). It seems it would. From B.2.4.1: "An 8-bit DCT-based process shall not use a 16-bit precision quantization table." Since this patch is defining UAPI I think it might be good to build in some additional information, eg. number of tables, element size. Maybe this can all be inferred from the selected pixel format? If so then it would need documented that the above structure only applies to baseline. For quantization coefficients, I can only see two tables: one for luma one for chroma. Huffman coefficients are a different story and we are not really adding them here. I was looking at the definition of Tqi in the frame header in B.2.2 which seems to allow up to four (sets of?) quantization tables. Rereading it, it seems these are per component. Table B.2 implies that this applies to Baseline Sequential too. In the DQT marker description there's a Tq field to specify the destination for the new table. I think this means that an encoder can use up to four (sets of) tables and a decoder should be able to store four from the stream. This may well not be relevant to the encoder under discussion, but if it's not allowed for in UAPI it's almost a given that it'll need to be added later. BTW, my copy of the spec is dated 1993(E). Maybe it's out of date? Since (if I understand this correctly) we would need u16 for extended precision JPEG, shouldn't we use u16 instead of u8? That makes the control more generic. This seems like a safer option to me. Regards, Ian BTW, are the coefficients always unsigned? I think so, but I never
Re: [PATCH v4 5/6] media: Add controls for JPEG quantization tables
On 09/03/2018 05:27 PM, Ezequiel Garcia wrote: > Hi Ian, Hans: > > On Mon, 2018-09-03 at 14:29 +0100, Ian Arkver wrote: >> Hi, >> >> On 03/09/2018 10:50, Hans Verkuil wrote: >>> On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: From: Shunqian Zheng Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace configure the JPEG quantization tables. Signed-off-by: Shunqian Zheng Signed-off-by: Ezequiel Garcia --- .../media/uapi/v4l/extended-controls.rst | 23 +++ .../media/videodev2.h.rst.exceptions | 1 + drivers/media/v4l2-core/v4l2-ctrls.c | 10 include/uapi/linux/v4l2-controls.h| 5 include/uapi/linux/videodev2.h| 1 + 5 files changed, 40 insertions(+) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index 9f7312bf3365..e0dd03e452de 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -3354,7 +3354,30 @@ JPEG Control IDs Specify which JPEG markers are included in compressed stream. This control is valid only for encoders. +.. _jpeg-quant-tables-control: +``V4L2_CID_JPEG_QUANTIZATION (struct)`` +Specifies the luma and chroma quantization matrices for encoding +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The two matrices +must be set in JPEG zigzag order, as per the JPEG specification. >>> >>> Can you change "JPEG specification" to a reference to the JPEG spec entry >>> in bibio.rst? >>> + + +.. c:type:: struct v4l2_ctrl_jpeg_quantization + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_jpeg_quantization +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - __u8 + - ``luma_quantization_matrix[64]`` + - Sets the luma quantization table. + +* - __u8 + - ``chroma_quantization_matrix[64]`` + - Sets the chroma quantization table. >>> >>> Just checking: the JPEG standard specifies this as unsigned 8-bit values as >>> well? >> > > I thought this was already discussed, but I think the only thing I've added > is this comment in one of the driver's headers: > > JPEG encoder > > The VPU JPEG encoder produces JPEG baseline sequential format. > The quantization coefficients are 8-bit values, complying with > the baseline specification. Therefore, it requires application-defined > luma and chroma quantization tables. The hardware does entrophy > encoding using internal Huffman tables, as specified in the JPEG > specification. > > Certainly controls should be specified better. > >> As far as I can see ISO/IEC 10918-1 does not specify the precision or >> signedness of the quantisation value Qvu. The default tables for 8-bit >> baseline JPEG all fit into __u8 though. >> > > Paragraph 4.7 of that spec, indicates the "sample" precision: > 8-bit for baseline; 8-bit or 12-bit for extended. > > For the quantization coefficients, the DQT segment contains a bit > that indicates if the quantization coefficients are 8-bit or 16-bit. > See B.2.4.1 for details. > >> However there can be four sets of tables in non-baseline JPEG and it's > > You lost me here, which four sets of tables are you refering to? > >> not clear (to me) whether 12-bit JPEG would need more precision (I'd >> guess it would). > > It seems it would. From B.2.4.1: > > "An 8-bit DCT-based process shall not use a 16-bit precision quantization > table." > >> Since this patch is defining UAPI I think it might be >> good to build in some additional information, eg. number of tables, >> element size. Maybe this can all be inferred from the selected pixel >> format? If so then it would need documented that the above structure >> only applies to baseline. >> > > For quantization coefficients, I can only see two tables: one for luma > one for chroma. Huffman coefficients are a different story and we are > not really adding them here. Since (if I understand this correctly) we would need u16 for extended precision JPEG, shouldn't we use u16 instead of u8? That makes the control more generic. BTW, are the coefficients always unsigned? I think so, but I never read the JPEG spec. Regards, Hans > > Thanks, > Eze >
Re: [PATCH v4 5/6] media: Add controls for JPEG quantization tables
Hi Ian, Hans: On Mon, 2018-09-03 at 14:29 +0100, Ian Arkver wrote: > Hi, > > On 03/09/2018 10:50, Hans Verkuil wrote: > > On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: > > > From: Shunqian Zheng > > > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > > configure the JPEG quantization tables. > > > > > > Signed-off-by: Shunqian Zheng > > > Signed-off-by: Ezequiel Garcia > > > --- > > > .../media/uapi/v4l/extended-controls.rst | 23 +++ > > > .../media/videodev2.h.rst.exceptions | 1 + > > > drivers/media/v4l2-core/v4l2-ctrls.c | 10 > > > include/uapi/linux/v4l2-controls.h| 5 > > > include/uapi/linux/videodev2.h| 1 + > > > 5 files changed, 40 insertions(+) > > > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > > b/Documentation/media/uapi/v4l/extended-controls.rst > > > index 9f7312bf3365..e0dd03e452de 100644 > > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > > @@ -3354,7 +3354,30 @@ JPEG Control IDs > > > Specify which JPEG markers are included in compressed stream. This > > > control is valid only for encoders. > > > > > > +.. _jpeg-quant-tables-control: > > > > > > +``V4L2_CID_JPEG_QUANTIZATION (struct)`` > > > +Specifies the luma and chroma quantization matrices for encoding > > > +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The two matrices > > > +must be set in JPEG zigzag order, as per the JPEG specification. > > > > Can you change "JPEG specification" to a reference to the JPEG spec entry > > in bibio.rst? > > > > > + > > > + > > > +.. c:type:: struct v4l2_ctrl_jpeg_quantization > > > + > > > +.. cssclass:: longtable > > > + > > > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization > > > +:header-rows: 0 > > > +:stub-columns: 0 > > > +:widths: 1 1 2 > > > + > > > +* - __u8 > > > + - ``luma_quantization_matrix[64]`` > > > + - Sets the luma quantization table. > > > + > > > +* - __u8 > > > + - ``chroma_quantization_matrix[64]`` > > > + - Sets the chroma quantization table. > > > > Just checking: the JPEG standard specifies this as unsigned 8-bit values as > > well? > I thought this was already discussed, but I think the only thing I've added is this comment in one of the driver's headers: JPEG encoder The VPU JPEG encoder produces JPEG baseline sequential format. The quantization coefficients are 8-bit values, complying with the baseline specification. Therefore, it requires application-defined luma and chroma quantization tables. The hardware does entrophy encoding using internal Huffman tables, as specified in the JPEG specification. Certainly controls should be specified better. > As far as I can see ISO/IEC 10918-1 does not specify the precision or > signedness of the quantisation value Qvu. The default tables for 8-bit > baseline JPEG all fit into __u8 though. > Paragraph 4.7 of that spec, indicates the "sample" precision: 8-bit for baseline; 8-bit or 12-bit for extended. For the quantization coefficients, the DQT segment contains a bit that indicates if the quantization coefficients are 8-bit or 16-bit. See B.2.4.1 for details. > However there can be four sets of tables in non-baseline JPEG and it's You lost me here, which four sets of tables are you refering to? > not clear (to me) whether 12-bit JPEG would need more precision (I'd > guess it would). It seems it would. From B.2.4.1: "An 8-bit DCT-based process shall not use a 16-bit precision quantization table." > Since this patch is defining UAPI I think it might be > good to build in some additional information, eg. number of tables, > element size. Maybe this can all be inferred from the selected pixel > format? If so then it would need documented that the above structure > only applies to baseline. > For quantization coefficients, I can only see two tables: one for luma one for chroma. Huffman coefficients are a different story and we are not really adding them here. Thanks, Eze
Re: [PATCH v4 6/6] media: add Rockchip VPU JPEG encoder driver
Hi Hans, Thanks for the feedback. On Mon, 2018-09-03 at 12:34 +0200, Hans Verkuil wrote: > On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: > > Add a mem2mem driver for the VPU available on Rockchip SoCs. > > Currently only JPEG encoding is supported, for RK3399 and RK3288 > > platforms. > > > > Signed-off-by: Ezequiel Garcia > > --- > > MAINTAINERS | 7 + > > drivers/media/platform/Kconfig| 13 + > > drivers/media/platform/Makefile | 1 + > > drivers/media/platform/rockchip/vpu/Makefile | 9 + > > .../platform/rockchip/vpu/rk3288_vpu_hw.c | 123 > > .../rockchip/vpu/rk3288_vpu_hw_jpege.c| 126 > > .../platform/rockchip/vpu/rk3288_vpu_regs.h | 442 + > > .../platform/rockchip/vpu/rk3399_vpu_hw.c | 124 > > .../rockchip/vpu/rk3399_vpu_hw_jpege.c| 154 + > > .../platform/rockchip/vpu/rk3399_vpu_regs.h | 601 + > > .../platform/rockchip/vpu/rockchip_vpu.h | 362 +++ > > .../rockchip/vpu/rockchip_vpu_common.h| 37 ++ > > .../platform/rockchip/vpu/rockchip_vpu_drv.c | 545 > > .../platform/rockchip/vpu/rockchip_vpu_enc.c | 607 ++ > > .../platform/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ > > 15 files changed, 3216 insertions(+) > > create mode 100644 drivers/media/platform/rockchip/vpu/Makefile > > create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c > > create mode 100644 > > drivers/media/platform/rockchip/vpu/rk3288_vpu_hw_jpege.c > > create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_regs.h > > create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_hw.c > > create mode 100644 > > drivers/media/platform/rockchip/vpu/rk3399_vpu_hw_jpege.c > > create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_regs.h > > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu.h > > create mode 100644 > > drivers/media/platform/rockchip/vpu/rockchip_vpu_common.h > > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_drv.c > > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_enc.c > > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_hw.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index da68e6da9981..e99b49c8dcf2 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -12272,6 +12272,13 @@ S: Maintained > > F: drivers/media/platform/rockchip/rga/ > > F: Documentation/devicetree/bindings/media/rockchip-rga.txt > > > > +ROCKCHIP VPU CODEC DRIVER > > +M: Ezequiel Garcia > > +L: linux-media@vger.kernel.org > > +S: Maintained > > +F: drivers/media/platform/rockchip/vpu/ > > +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt > > + > > ROCKER DRIVER > > M: Jiri Pirko > > L: net...@vger.kernel.org > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > > index b25c8d3c1c31..87eb854cf7cb 100644 > > --- a/drivers/media/platform/Kconfig > > +++ b/drivers/media/platform/Kconfig > > @@ -448,6 +448,19 @@ config VIDEO_ROCKCHIP_RGA > > > > To compile this driver as a module choose m here. > > > > +config VIDEO_ROCKCHIP_VPU > > + tristate "Rockchip VPU driver" > > + depends on ARCH_ROCKCHIP || COMPILE_TEST > > + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER > > + select VIDEOBUF2_DMA_CONTIG > > + select V4L2_MEM2MEM_DEV > > + default n > > + help > > + Support for the Video Processing Unit present on Rockchip SoC, > > + which accelerates video and image encoding and decoding. > > + To compile this driver as a module, choose M here: the module > > + will be called rockchip-vpu. > > + > > config VIDEO_TI_VPE > > tristate "TI VPE (Video Processing Engine) driver" > > depends on VIDEO_DEV && VIDEO_V4L2 > > diff --git a/drivers/media/platform/Makefile > > b/drivers/media/platform/Makefile > > index 08640ba87fc2..9b93f6a6b6e2 100644 > > --- a/drivers/media/platform/Makefile > > +++ b/drivers/media/platform/Makefile > > @@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o > > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/ > > > > obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip/rga/ > > +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU)+= rockchip/vpu/ > > > > obj-y += omap/ > > > > diff --git a/drivers/media/platform/rockchip/vpu/Makefile > > b/drivers/media/platform/rockchip/vpu/Makefile > > new file mode 100644 > > index ..f717dfda1d42 > > --- /dev/null > > +++ b/drivers/media/platform/rockchip/vpu/Makefile > > @@ -0,0 +1,9 @@ > > +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip-vpu.o > > + > > +rockchip-vpu-y += \ > > + rockchip_vpu_drv.o \ > > + rockchip_vpu_enc.o \ > > + rk3288_vpu_hw.o \ > > + rk3288_vpu_hw_jpege.o \ > > + rk3399_vpu_hw.o \ > > + rk3399_vpu_hw_jpege.o > > diff --git
Re: [PATCH 2/3] ARM: dts: imx6ull: add pxp support
On Mon, 2018-08-27 at 14:59 +0800, Shawn Guo wrote:
> On Fri, Aug 10, 2018 at 05:18:21PM +0200, Philipp Zabel wrote:
> > Add the device node for the i.MX6ULL Pixel Pipeline (PXP).
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > arch/arm/boot/dts/imx6ul.dtsi | 8
> > arch/arm/boot/dts/imx6ull.dtsi | 6 ++
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
> > index 47a3453a4211..e80a660c14f2 100644
> > --- a/arch/arm/boot/dts/imx6ul.dtsi
> > +++ b/arch/arm/boot/dts/imx6ul.dtsi
> > @@ -928,6 +928,14 @@
> > };
> > };
> >
> > + pxp: pxp@21cc000 {
> > + compatible = "fsl,imx6ul-pxp";
> > + reg = <0x021cc000 0x4000>;
> > + interrupts = ;
> > + clock-names = "axi";
> > + clocks = < IMX6UL_CLK_PXP>;
> > + };
> > +
> > lcdif: lcdif@21c8000 {
>
> In order of unit-address, pxp@21cc000 should go after lcdif@21c8000.
Thank you, I'll fix this in v2.
regards
Philipp
Re: [PATCH 3/3] media: imx-pxp: add i.MX Pixel Pipeline driver
Hi Hans,
On Mon, 2018-09-03 at 14:55 +0200, Hans Verkuil wrote:
> Hi Philipp,
>
> Apologies for the delay, but the Request API took most of my time.
Understandable. Also, I expect I'll profit from that work when adding
CODA960 JPEG support. So I have no reason to complain.
> But I finally got around to it:
>
> On 08/10/2018 05:18 PM, Philipp Zabel wrote:
> > Add a V4L2 mem-to-mem scaler/CSC driver for the Pixel Pipeline (PXP)
> > version found on i.MX6ULL SoCs. A similar variant is used on i.MX7D.
> >
> > Since this driver only uses the legacy pipeline, it should be reasonably
> > easy to extend it to work with the older PXP versions found on i.MX6UL,
> > i.MX6SX, i.MX6SL, i.MX28, and i.MX23.
> >
> > The driver supports scaling and colorspace conversion. There is
> > currently no support for rotation, alpha-blending, and the LUTs.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > drivers/media/platform/Kconfig |9 +
> > drivers/media/platform/Makefile |2 +
> > drivers/media/platform/imx-pxp.c | 1455 ++
> > drivers/media/platform/imx-pxp.h | 1685 ++
>
> Missing MAINTAINERS entry.
I'll add one for v2.
[...]
> > +static void pxp_setup_csc(struct pxp_ctx *ctx)
> > +{
> > + struct pxp_dev *dev = ctx->dev;
> > +
> > + if (pxp_v4l2_pix_fmt_is_yuv(ctx->q_data[V4L2_M2M_SRC].fmt->fourcc) &&
> > + !pxp_v4l2_pix_fmt_is_yuv(ctx->q_data[V4L2_M2M_DST].fmt->fourcc)) {
[...]
> > + if (ctx->ycbcr_enc == V4L2_YCBCR_ENC_601 &&
> > + ctx->quant == V4L2_QUANTIZATION_FULL_RANGE)
> > + csc1_coef = csc1_coef_bt601_full;
> > + else
> > + csc1_coef = csc1_coef_bt601_lim;
>
> This is weird: setting ycbcr_enc to V4L2_YCBCR_ENC_709 would result in
> limited range BT601.
>
> > +
> > + writel(csc1_coef[0], dev->mmio + HW_PXP_CSC1_COEF0);
> > + writel(csc1_coef[1], dev->mmio + HW_PXP_CSC1_COEF1);
> > + writel(csc1_coef[2], dev->mmio + HW_PXP_CSC1_COEF2);
>
> No support for Rec. 709?
Will add coefficients for Rec. 709.
> > + } else {
> > + writel(BM_PXP_CSC1_COEF0_BYPASS, dev->mmio + HW_PXP_CSC1_COEF0);
> > + }
> > +
> > + if (!pxp_v4l2_pix_fmt_is_yuv(ctx->q_data[V4L2_M2M_SRC].fmt->fourcc) &&
> > + pxp_v4l2_pix_fmt_is_yuv(ctx->q_data[V4L2_M2M_DST].fmt->fourcc)) {
[...]
> > + if (ctx->ycbcr_enc == V4L2_YCBCR_ENC_601 &&
> > + ctx->quant == V4L2_QUANTIZATION_FULL_RANGE) {
>
> This makes no sense. ctx->ycbcr_enc and ctx->quant refer to the output queue,
> i.e. the RGB side. ycbcr_enc is ignored for RGB and quant is in practice
> always
> full range. While you can have limited range RGB as well, that's not however
> what you are trying to implement here.
>
> The problem is that you cannot at the moment specify what ycbcr_enc etc.
> format you want for the capture queue. See below for a link to an RFC to add
> support for this.
Right. I'll split ycbcr_enc and quantization into per-queue settings for
v2 and revive your RFC to allow configuring capture queue colorimetry.
[...]
> > +/*
> > + * video ioctls
> > + */
> > +static int vidioc_querycap(struct file *file, void *priv,
> > + struct v4l2_capability *cap)
> > +{
> > + strncpy(cap->driver, MEM2MEM_NAME, sizeof(cap->driver) - 1);
> > + strncpy(cap->card, MEM2MEM_NAME, sizeof(cap->card) - 1);
>
> Use strlcpy.
Ok.
> > + snprintf(cap->bus_info, sizeof(cap->bus_info),
> > + "platform:%s", MEM2MEM_NAME);
> > + cap->device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING;
> > + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>
> Please set the device_caps field of video_device, and then you can drop
> these two lines since the core will fill this in for you.
Ok.
[...]
> > +static int vidioc_g_fmt(struct pxp_ctx *ctx, struct v4l2_format *f)
> > +{
> > + struct vb2_queue *vq;
> > + struct pxp_q_data *q_data;
> > +
> > + vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
> > + if (!vq)
> > + return -EINVAL;
> > +
> > + q_data = get_q_data(ctx, f->type);
> > +
> > + f->fmt.pix.width= q_data->width;
> > + f->fmt.pix.height = q_data->height;
> > + f->fmt.pix.field= V4L2_FIELD_NONE;
> > + f->fmt.pix.pixelformat = q_data->fmt->fourcc;
> > + f->fmt.pix.bytesperline = q_data->bytesperline;
> > + f->fmt.pix.sizeimage= q_data->sizeimage;
> > + f->fmt.pix.colorspace = ctx->colorspace;
> > + f->fmt.pix.xfer_func= ctx->xfer_func;
> > + f->fmt.pix.ycbcr_enc= ctx->ycbcr_enc;
> > + f->fmt.pix.quantization = ctx->quant;
>
> Since you do colorspace conversion, these can't be the same for
> both output and capture.
>
> colorspace and xfer_func will be the same (those are not converted),
> but ycbcr_enc should be set to 0 for RGB and quantization range
> will be different as well (either set to 0 for capture, or set
> to FULL for RGB capture and
Re: [PATCH v4 5/6] media: Add controls for JPEG quantization tables
Hi, On 03/09/2018 10:50, Hans Verkuil wrote: On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: From: Shunqian Zheng Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace configure the JPEG quantization tables. Signed-off-by: Shunqian Zheng Signed-off-by: Ezequiel Garcia --- .../media/uapi/v4l/extended-controls.rst | 23 +++ .../media/videodev2.h.rst.exceptions | 1 + drivers/media/v4l2-core/v4l2-ctrls.c | 10 include/uapi/linux/v4l2-controls.h| 5 include/uapi/linux/videodev2.h| 1 + 5 files changed, 40 insertions(+) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index 9f7312bf3365..e0dd03e452de 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -3354,7 +3354,30 @@ JPEG Control IDs Specify which JPEG markers are included in compressed stream. This control is valid only for encoders. +.. _jpeg-quant-tables-control: +``V4L2_CID_JPEG_QUANTIZATION (struct)`` +Specifies the luma and chroma quantization matrices for encoding +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The two matrices +must be set in JPEG zigzag order, as per the JPEG specification. Can you change "JPEG specification" to a reference to the JPEG spec entry in bibio.rst? + + +.. c:type:: struct v4l2_ctrl_jpeg_quantization + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_jpeg_quantization +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - __u8 + - ``luma_quantization_matrix[64]`` + - Sets the luma quantization table. + +* - __u8 + - ``chroma_quantization_matrix[64]`` + - Sets the chroma quantization table. Just checking: the JPEG standard specifies this as unsigned 8-bit values as well? As far as I can see ISO/IEC 10918-1 does not specify the precision or signedness of the quantisation value Qvu. The default tables for 8-bit baseline JPEG all fit into __u8 though. However there can be four sets of tables in non-baseline JPEG and it's not clear (to me) whether 12-bit JPEG would need more precision (I'd guess it would). Since this patch is defining UAPI I think it might be good to build in some additional information, eg. number of tables, element size. Maybe this can all be inferred from the selected pixel format? If so then it would need documented that the above structure only applies to baseline. Regards, Ian .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions index ca9f0edc579e..a0a38e92bf38 100644 --- a/Documentation/media/videodev2.h.rst.exceptions +++ b/Documentation/media/videodev2.h.rst.exceptions @@ -129,6 +129,7 @@ replace symbol V4L2_CTRL_TYPE_STRING :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type` # V4L2 capability defines replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index 599c1cbff3b9..305bd7a9b7f1 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -999,6 +999,7 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval"; case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality"; case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers"; + case V4L2_CID_JPEG_QUANTIZATION:return "JPEG Quantization Tables"; /* Image source controls */ /* Keep the order of the 'case's the same as in v4l2-controls.h! */ @@ -1286,6 +1287,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type, case V4L2_CID_DETECT_MD_REGION_GRID: *type = V4L2_CTRL_TYPE_U8; break; + case V4L2_CID_JPEG_QUANTIZATION: + *type = V4L2_CTRL_TYPE_JPEG_QUANTIZATION; + break; case V4L2_CID_DETECT_MD_THRESHOLD_GRID: *type = V4L2_CTRL_TYPE_U16; break; @@ -1612,6 +1616,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 idx, return -ERANGE; return 0; + case V4L2_CTRL_TYPE_JPEG_QUANTIZATION: + return 0; + default: return -EINVAL; } @@ -2133,6 +2140,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl, case V4L2_CTRL_TYPE_U32: elem_size = sizeof(u32); break; + case V4L2_CTRL_TYPE_JPEG_QUANTIZATION: +
Re: [PATCH 00/14] staging: media: tegra-vdea: Add Tegra124 support
On Mon, Sep 03, 2018 at 02:18:15PM +0200, Hans Verkuil wrote: > Hi Thierry, Dmitry, > > Dmitry found some issues, so I'll wait for a v2. > > Anyway, this driver is in staging with this TODO: > > - Implement V4L2 API once it gains support for stateless decoders. > > I just wanted to mention that the Request API is expected to be merged > for 4.20. A topic branch is here: > > https://git.linuxtv.org/media_tree.git/log/?h=request_api > > This patch series is expected to be added to the topic branch once > everyone agrees: > > https://www.spinics.net/lists/linux-media/msg139713.html > > The first Allwinner driver that will be using this API is here: > > https://lwn.net/Articles/763589/ > > It's expected to be merged for 4.20 as well. > > Preliminary H264 work for the Allwinner driver is here: > > https://lkml.org/lkml/2018/6/13/399 > > But this needs more work. > > HEVC support, on the other hand, is almost ready: > > https://lkml.org/lkml/2018/8/28/229 > > I hope these links give a good overview of the current status. Thanks for those links. I was aware of the ongoing efforts and was eagerly waiting for the various pieces to settle a bit. I will hopefully get around to porting the tegra-vde driver to this new infrastructure in the next couple of weeks. Thierry signature.asc Description: PGP signature
Re: [PATCH 3/3] media: imx-pxp: add i.MX Pixel Pipeline driver
Hi Philipp,
Apologies for the delay, but the Request API took most of my time.
But I finally got around to it:
On 08/10/2018 05:18 PM, Philipp Zabel wrote:
> Add a V4L2 mem-to-mem scaler/CSC driver for the Pixel Pipeline (PXP)
> version found on i.MX6ULL SoCs. A similar variant is used on i.MX7D.
>
> Since this driver only uses the legacy pipeline, it should be reasonably
> easy to extend it to work with the older PXP versions found on i.MX6UL,
> i.MX6SX, i.MX6SL, i.MX28, and i.MX23.
>
> The driver supports scaling and colorspace conversion. There is
> currently no support for rotation, alpha-blending, and the LUTs.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/Kconfig |9 +
> drivers/media/platform/Makefile |2 +
> drivers/media/platform/imx-pxp.c | 1455 ++
> drivers/media/platform/imx-pxp.h | 1685 ++
Missing MAINTAINERS entry.
> 4 files changed, 3151 insertions(+)
> create mode 100644 drivers/media/platform/imx-pxp.c
> create mode 100644 drivers/media/platform/imx-pxp.h
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index b25c8d3c1c31..ae1c025c14de 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -181,6 +181,15 @@ config VIDEO_CODA
> config VIDEO_IMX_VDOA
> def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
>
> +config VIDEO_IMX_PXP
> + tristate "i.MX Pixel Pipeline (PXP)"
> + depends on VIDEO_DEV && VIDEO_V4L2 && (ARCH_MXC || COMPILE_TEST)
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + help
> + The i.MX Pixel Pipeline is a memory-to-memory engine for scaling,
> + color space conversion, and rotation.
> +
> config VIDEO_MEDIATEK_JPEG
> tristate "Mediatek JPEG Codec driver"
> depends on MTK_IOMMU_V1 || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 08640ba87fc2..0c2714c2bb05 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -25,6 +25,8 @@ obj-$(CONFIG_VIDEO_TI_CAL) += ti-vpe/
> obj-$(CONFIG_VIDEO_MX2_EMMAPRP) += mx2_emmaprp.o
> obj-$(CONFIG_VIDEO_CODA) += coda/
>
> +obj-$(CONFIG_VIDEO_IMX_PXP) += imx-pxp.o
> +
> obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
>
> obj-$(CONFIG_CEC_GPIO) += cec-gpio/
> diff --git a/drivers/media/platform/imx-pxp.c
> b/drivers/media/platform/imx-pxp.c
> new file mode 100644
> index ..c9e3ef0f92b4
> --- /dev/null
> +++ b/drivers/media/platform/imx-pxp.c
> @@ -0,0 +1,1455 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * i.MX Pixel Pipeline (PXP) mem-to-mem scaler/CSC/rotator driver
> + *
> + * Copyright (c) 2018 Pengutronix, Philipp Zabel
> + *
> + * based on vim2m
> + *
> + * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
> + * Pawel Osciak,
> + * Marek Szyprowski,
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "imx-pxp.h"
> +
> +static unsigned int debug;
> +module_param(debug, uint, 0644);
> +MODULE_PARM_DESC(debug, "activates debug info");
> +
> +#define MIN_W 8
> +#define MIN_H 8
> +#define MAX_W 4096
> +#define MAX_H 4096
> +#define ALIGN_W 3 /* 8x8 pixel blocks */
> +#define ALIGN_H 3
> +
> +/* Flags that indicate a format can be used for capture/output */
> +#define MEM2MEM_CAPTURE (1 << 0)
> +#define MEM2MEM_OUTPUT (1 << 1)
> +
> +#define MEM2MEM_NAME "pxp"
> +
> +/* Per queue */
> +#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
> +/* In bytes, per queue */
> +#define MEM2MEM_VID_MEM_LIMIT(16 * 1024 * 1024)
> +
> +/* Flags that indicate processing mode */
> +#define MEM2MEM_HFLIP(1 << 0)
> +#define MEM2MEM_VFLIP(1 << 1)
> +
> +#define dprintk(dev, fmt, arg...) \
> + v4l2_dbg(1, debug, >v4l2_dev, "%s: " fmt, __func__, ## arg)
> +
> +struct pxp_fmt {
> + u32 fourcc;
> + int depth;
> + /* Types the format can be used for */
> + u32 types;
> +};
> +
> +static struct pxp_fmt formats[] = {
> + {
> + .fourcc = V4L2_PIX_FMT_XBGR32,
> + .depth = 32,
> + /* Both capture and output format */
> + .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
> + }, {
> + .fourcc = V4L2_PIX_FMT_ABGR32,
> + .depth = 32,
> + /* Capture-only format */
> + .types = MEM2MEM_CAPTURE,
> + }, {
> + .fourcc = V4L2_PIX_FMT_BGR24,
> + .depth = 24,
> + .types = MEM2MEM_CAPTURE,
> + }, {
> + .fourcc = V4L2_PIX_FMT_RGB565,
> + .depth = 16,
> + .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
> + }, {
> + .fourcc
Re: [PATCH 00/14] staging: media: tegra-vdea: Add Tegra124 support
Hi Thierry, Dmitry, Dmitry found some issues, so I'll wait for a v2. Anyway, this driver is in staging with this TODO: - Implement V4L2 API once it gains support for stateless decoders. I just wanted to mention that the Request API is expected to be merged for 4.20. A topic branch is here: https://git.linuxtv.org/media_tree.git/log/?h=request_api This patch series is expected to be added to the topic branch once everyone agrees: https://www.spinics.net/lists/linux-media/msg139713.html The first Allwinner driver that will be using this API is here: https://lwn.net/Articles/763589/ It's expected to be merged for 4.20 as well. Preliminary H264 work for the Allwinner driver is here: https://lkml.org/lkml/2018/6/13/399 But this needs more work. HEVC support, on the other hand, is almost ready: https://lkml.org/lkml/2018/8/28/229 I hope these links give a good overview of the current status. Regards, Hans On 08/13/2018 04:50 PM, Thierry Reding wrote: > From: Thierry Reding > > Hi, > > this set of patches perform a bit of cleanup and extend support to the > VDE implementation found on Tegra114 and Tegra124. This requires adding > handling for a clock and a reset for the BSEV block that is separate > from the main VDE block. The new VDE revision also supports reference > picture marking, which requires that the BSEV writes out some related > data to a memory location. Since the supported tiling layouts have been > changed in Tegra124, which supports only block-linear and no pitch- > linear layouts, a new way is added to request a specific layout for the > decoded frames. Both of the above changes require breaking the ABI to > accomodate for the new data in the custom IOCTL. > > Finally this set also adds support for dealing with an IOMMU, which > makes it more convenient to deal with imported buffers since they no > longer need to be physically contiguous. > > Userspace changes for the updated ABI are available here: > > https://cgit.freedesktop.org/~tagr/libvdpau-tegra/commit/ > > Mauro, I'm sending the device tree changes as part of the series for > completeness, but I expect to pick those up into the Tegra tree once > this has been reviewed and you've applied the driver changes. > > Thanks, > Thierry > > Thierry Reding (14): > staging: media: tegra-vde: Support BSEV clock and reset > staging: media: tegra-vde: Support reference picture marking > staging: media: tegra-vde: Prepare for interlacing support > staging: media: tegra-vde: Use DRM/KMS framebuffer modifiers > staging: media: tegra-vde: Properly mark invalid entries > staging: media: tegra-vde: Print out invalid FD > staging: media: tegra-vde: Add some clarifying comments > staging: media: tegra-vde: Track struct device * > staging: media: tegra-vde: Add IOMMU support > staging: media: tegra-vde: Keep VDE in reset when unused > ARM: tegra: Enable VDE on Tegra124 > ARM: tegra: Add BSEV clock and reset for VDE on Tegra20 > ARM: tegra: Add BSEV clock and reset for VDE on Tegra30 > ARM: tegra: Enable SMMU for VDE on Tegra124 > > arch/arm/boot/dts/tegra124.dtsi | 42 ++ > arch/arm/boot/dts/tegra20.dtsi | 10 +- > arch/arm/boot/dts/tegra30.dtsi | 10 +- > drivers/staging/media/tegra-vde/tegra-vde.c | 528 +--- > drivers/staging/media/tegra-vde/uapi.h | 6 +- > 5 files changed, 511 insertions(+), 85 deletions(-) >
Re: [PATCH v4 6/6] media: add Rockchip VPU JPEG encoder driver
On 08/31/2018 05:52 PM, Ezequiel Garcia wrote: > Add a mem2mem driver for the VPU available on Rockchip SoCs. > Currently only JPEG encoding is supported, for RK3399 and RK3288 > platforms. > > Signed-off-by: Ezequiel Garcia > --- > MAINTAINERS | 7 + > drivers/media/platform/Kconfig| 13 + > drivers/media/platform/Makefile | 1 + > drivers/media/platform/rockchip/vpu/Makefile | 9 + > .../platform/rockchip/vpu/rk3288_vpu_hw.c | 123 > .../rockchip/vpu/rk3288_vpu_hw_jpege.c| 126 > .../platform/rockchip/vpu/rk3288_vpu_regs.h | 442 + > .../platform/rockchip/vpu/rk3399_vpu_hw.c | 124 > .../rockchip/vpu/rk3399_vpu_hw_jpege.c| 154 + > .../platform/rockchip/vpu/rk3399_vpu_regs.h | 601 + > .../platform/rockchip/vpu/rockchip_vpu.h | 362 +++ > .../rockchip/vpu/rockchip_vpu_common.h| 37 ++ > .../platform/rockchip/vpu/rockchip_vpu_drv.c | 545 > .../platform/rockchip/vpu/rockchip_vpu_enc.c | 607 ++ > .../platform/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ > 15 files changed, 3216 insertions(+) > create mode 100644 drivers/media/platform/rockchip/vpu/Makefile > create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c > create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_hw_jpege.c > create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_regs.h > create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_hw.c > create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_hw_jpege.c > create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_regs.h > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu.h > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_common.h > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_drv.c > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_enc.c > create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_hw.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index da68e6da9981..e99b49c8dcf2 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -12272,6 +12272,13 @@ S: Maintained > F: drivers/media/platform/rockchip/rga/ > F: Documentation/devicetree/bindings/media/rockchip-rga.txt > > +ROCKCHIP VPU CODEC DRIVER > +M: Ezequiel Garcia > +L: linux-media@vger.kernel.org > +S: Maintained > +F: drivers/media/platform/rockchip/vpu/ > +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt > + > ROCKER DRIVER > M: Jiri Pirko > L: net...@vger.kernel.org > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index b25c8d3c1c31..87eb854cf7cb 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -448,6 +448,19 @@ config VIDEO_ROCKCHIP_RGA > > To compile this driver as a module choose m here. > > +config VIDEO_ROCKCHIP_VPU > + tristate "Rockchip VPU driver" > + depends on ARCH_ROCKCHIP || COMPILE_TEST > + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER > + select VIDEOBUF2_DMA_CONTIG > + select V4L2_MEM2MEM_DEV > + default n > + help > + Support for the Video Processing Unit present on Rockchip SoC, > + which accelerates video and image encoding and decoding. > + To compile this driver as a module, choose M here: the module > + will be called rockchip-vpu. > + > config VIDEO_TI_VPE > tristate "TI VPE (Video Processing Engine) driver" > depends on VIDEO_DEV && VIDEO_V4L2 > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index 08640ba87fc2..9b93f6a6b6e2 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/ > > obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip/rga/ > +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU)+= rockchip/vpu/ > > obj-y+= omap/ > > diff --git a/drivers/media/platform/rockchip/vpu/Makefile > b/drivers/media/platform/rockchip/vpu/Makefile > new file mode 100644 > index ..f717dfda1d42 > --- /dev/null > +++ b/drivers/media/platform/rockchip/vpu/Makefile > @@ -0,0 +1,9 @@ > +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip-vpu.o > + > +rockchip-vpu-y += \ > + rockchip_vpu_drv.o \ > + rockchip_vpu_enc.o \ > + rk3288_vpu_hw.o \ > + rk3288_vpu_hw_jpege.o \ > + rk3399_vpu_hw.o \ > + rk3399_vpu_hw_jpege.o > diff --git a/drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c > b/drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c > new file mode 100644 > index ..474e1ec758df > --- /dev/null > +++ b/drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c > @@ -0,0 +1,123 @@ > +//
Re: [PATCH v4 5/6] media: Add controls for JPEG quantization tables
On 08/31/2018 05:52 PM, Ezequiel Garcia wrote:
> From: Shunqian Zheng
>
> Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace
> configure the JPEG quantization tables.
>
> Signed-off-by: Shunqian Zheng
> Signed-off-by: Ezequiel Garcia
> ---
> .../media/uapi/v4l/extended-controls.rst | 23 +++
> .../media/videodev2.h.rst.exceptions | 1 +
> drivers/media/v4l2-core/v4l2-ctrls.c | 10
> include/uapi/linux/v4l2-controls.h| 5
> include/uapi/linux/videodev2.h| 1 +
> 5 files changed, 40 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index 9f7312bf3365..e0dd03e452de 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -3354,7 +3354,30 @@ JPEG Control IDs
> Specify which JPEG markers are included in compressed stream. This
> control is valid only for encoders.
>
> +.. _jpeg-quant-tables-control:
>
> +``V4L2_CID_JPEG_QUANTIZATION (struct)``
> +Specifies the luma and chroma quantization matrices for encoding
> +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The two matrices
> +must be set in JPEG zigzag order, as per the JPEG specification.
Can you change "JPEG specification" to a reference to the JPEG spec entry
in bibio.rst?
> +
> +
> +.. c:type:: struct v4l2_ctrl_jpeg_quantization
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_jpeg_quantization
> +:header-rows: 0
> +:stub-columns: 0
> +:widths: 1 1 2
> +
> +* - __u8
> + - ``luma_quantization_matrix[64]``
> + - Sets the luma quantization table.
> +
> +* - __u8
> + - ``chroma_quantization_matrix[64]``
> + - Sets the chroma quantization table.
Just checking: the JPEG standard specifies this as unsigned 8-bit values as
well?
>
> .. flat-table::
> :header-rows: 0
> diff --git a/Documentation/media/videodev2.h.rst.exceptions
> b/Documentation/media/videodev2.h.rst.exceptions
> index ca9f0edc579e..a0a38e92bf38 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -129,6 +129,7 @@ replace symbol V4L2_CTRL_TYPE_STRING
> :c:type:`v4l2_ctrl_type`
> replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type`
> replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type`
> replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type`
> +replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type`
>
> # V4L2 capability defines
> replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 599c1cbff3b9..305bd7a9b7f1 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -999,6 +999,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval";
> case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
> case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers";
> + case V4L2_CID_JPEG_QUANTIZATION:return "JPEG Quantization
> Tables";
>
> /* Image source controls */
> /* Keep the order of the 'case's the same as in v4l2-controls.h! */
> @@ -1286,6 +1287,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> case V4L2_CID_DETECT_MD_REGION_GRID:
> *type = V4L2_CTRL_TYPE_U8;
> break;
> + case V4L2_CID_JPEG_QUANTIZATION:
> + *type = V4L2_CTRL_TYPE_JPEG_QUANTIZATION;
> + break;
> case V4L2_CID_DETECT_MD_THRESHOLD_GRID:
> *type = V4L2_CTRL_TYPE_U16;
> break;
> @@ -1612,6 +1616,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl,
> u32 idx,
> return -ERANGE;
> return 0;
>
> + case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
> + return 0;
> +
> default:
> return -EINVAL;
> }
> @@ -2133,6 +2140,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
> case V4L2_CTRL_TYPE_U32:
> elem_size = sizeof(u32);
> break;
> + case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
> + elem_size = sizeof(struct v4l2_ctrl_jpeg_quantization);
> + break;
> default:
> if (type < V4L2_CTRL_COMPOUND_TYPES)
> elem_size = sizeof(s32);
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index e4ee10ee917d..fcb288bb05c7 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -987,6 +987,11 @@ enum v4l2_jpeg_chroma_subsampling {
> #define V4L2_JPEG_ACTIVE_MARKER_DQT (1 << 17)
> #define
not able to build libv4lconvert on Ubuntu 16.04
Hi there ! I've tried to build libv4lconvert (ubuntu 16.04, 64bits) cloning the git. After removing the first line of the Makefile in the libv4lconvert directory (that was set to arm architecture), the problem was that it didn't find "linux/videodev.h". I tried: sudo ln -s /usr/include/linux/videodev2.h /usr/include/linux/videodev.h but that was the same. I tried: sudo ln -s /usr/include/libv4l1-videodev.h /usr/include/linux/videodev.h and then it told me a lot things (that i don't understand): In file included from /usr/include/x86_64-linux-gnu/asm/ioctl.h:1:0, from /usr/include/linux/ioctl.h:4, from ../libv4lconvert/libv4lsyscall-priv.h:41, from log.c:21: log.c:42:11: error: ‘VIDIOCKEY’ undeclared here (not in a function) [_IOC_NR(VIDIOCKEY)] = "VIDIOCKEY", ... Here's the complete log: bobby@bobby-E202SA:~/Bureau/libv4lconvert$ git clone https://github.com/ashwing920/libv4lconvert.git Clonage dans 'libv4lconvert'... remote: Counting objects: 113, done. remote: Total 113 (delta 0), reused 0 (delta 0), pack-reused 113 Réception d'objets: 100% (113/113), 522.41 KiB | 687.00 KiB/s, fait. Résolution des deltas: 100% (24/24), fait. Vérification de la connectivité... fait. bobby@bobby-E202SA:~/Bureau/libv4lconvert$ make make: *** Pas de cible spécifiée et aucun makefile n'a été trouvé. Arrêt. bobby@bobby-E202SA:~/Bureau/libv4lconvert$ cd li* bobby@bobby-E202SA:~/Bureau/libv4lconvert/libv4lconvert$ make make -C libv4lconvert V4L2_LIB_VERSION=0.6.2-test all make[1] : on entre dans le répertoire « /home/bobby/Bureau/libv4lconvert/libv4lconvert/libv4lconvert » cc -Wp,-MMD,"libv4lconvert.d",-MQ,"libv4lconvert.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o libv4lconvert.o libv4lconvert.c cc -Wp,-MMD,"sn9c10x.d",-MQ,"sn9c10x.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o sn9c10x.o sn9c10x.c cc -Wp,-MMD,"pac207.d",-MQ,"pac207.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o pac207.o pac207.c cc -Wp,-MMD,"mr97310a.d",-MQ,"mr97310a.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o mr97310a.o mr97310a.c cc -Wp,-MMD,"flip.d",-MQ,"flip.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o flip.o flip.c cc -Wp,-MMD,"crop.d",-MQ,"crop.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o crop.o crop.c cc -Wp,-MMD,"jidctflt.d",-MQ,"jidctflt.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o jidctflt.o jidctflt.c cc -Wp,-MMD,"rgbyuv.d",-MQ,"rgbyuv.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o rgbyuv.o rgbyuv.c cc -Wp,-MMD,"sn9c2028-decomp.d",-MQ,"sn9c2028-decomp.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o sn9c2028-decomp.o sn9c2028-decomp.c cc -Wp,-MMD,"bayer.d",-MQ,"bayer.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o bayer.o bayer.c cc -Wp,-MMD,"hm12.d",-MQ,"hm12.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o hm12.o hm12.c cc -Wp,-MMD,"control/libv4lcontrol.d",-MQ,"control/libv4lcontrol.o",-MP -c -I../include -I../../../include -fvisibility=hidden -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o control/libv4lcontrol.o control/libv4lcontrol.c control/libv4lcontrol.c: In function ‘v4lcontrol_create’: control/libv4lcontrol.c:449:5: warning: ignoring return value of ‘ftruncate’, declared with attribute warn_unused_result [-Wunused-result] ftruncate(shm_fd,
Re: cron job: media_tree daily build: ERRORS
On 09/02/2018 09:45 PM, Jasmin J. wrote: > Hi! > > This was really hard to fix and I am still not ready. > But it should now compile for 4.19, 4.18 and 4.17. > > Compiling is one thing, but functional is another. I added some inline > functions to compat.h (ida_alloc_min, ...) in 7283154cd56d to support them for > older Kernels. If someone is using an older Kernel, I would be happy to get a > feedback if my implementation works. Unfortunately my build server in the Netherlands crashed, and since I am in Norway for three weeks I have no way of rebooting it. I'll try to set up a daily build on my server in Norway, hopefully it should be up and running by the end of today. Regards, Hans > > BR, >Jasmin > > * > > On 09/01/2018 06:55 AM, Hans Verkuil wrote: >> This message is generated daily by a cron job that builds media_tree for >> the kernels and architectures in the list below. >> >> Results of the daily build of media_tree: >> >> date:Sat Sep 1 05:00:11 CEST 2018 >> media-tree git hash: d842a7cf938b6e0f8a1aa9f1aec0476c9a599310 >> media_build git hash:27f99df152c7e5ae155c6e7888e12234eaa0fc25 >> v4l-utils git hash: f44f00e8b4ac6e9aa05bac8953e3fcc89e1fe198 >> edid-decode git hash:b2da1516df3cc2756bfe8d1fa06d7bf2562ba1f4 >> gcc version: i686-linux-gcc (GCC) 8.1.0 >> sparse version: 0.5.2 >> smatch version: 0.5.1 >> host hardware: x86_64 >> host os: 4.18.5-marune >> >> linux-git-arm-at91: OK >> linux-git-arm-davinci: OK >> linux-git-arm-multi: OK >> linux-git-arm-pxa: OK >> linux-git-arm-stm32: OK >> linux-git-arm64: OK >> linux-git-i686: OK >> linux-git-mips: OK >> linux-git-powerpc64: OK >> linux-git-sh: WARNINGS >> linux-git-x86_64: OK >> Check COMPILE_TEST: OK >> linux-2.6.36.4-i686: ERRORS >> linux-2.6.36.4-x86_64: ERRORS >> linux-2.6.37.6-i686: ERRORS >> linux-2.6.37.6-x86_64: ERRORS >> linux-2.6.38.8-i686: ERRORS >> linux-2.6.38.8-x86_64: ERRORS >> linux-2.6.39.4-i686: ERRORS >> linux-2.6.39.4-x86_64: ERRORS >> linux-3.0.101-i686: ERRORS >> linux-3.0.101-x86_64: ERRORS >> linux-3.1.10-i686: ERRORS >> linux-3.1.10-x86_64: ERRORS >> linux-3.2.102-i686: ERRORS >> linux-3.2.102-x86_64: ERRORS >> linux-3.3.8-i686: ERRORS >> linux-3.3.8-x86_64: ERRORS >> linux-3.4.113-i686: ERRORS >> linux-3.4.113-x86_64: ERRORS >> linux-3.5.7-i686: ERRORS >> linux-3.5.7-x86_64: ERRORS >> linux-3.6.11-i686: ERRORS >> linux-3.6.11-x86_64: ERRORS >> linux-3.7.10-i686: ERRORS >> linux-3.7.10-x86_64: ERRORS >> linux-3.8.13-i686: ERRORS >> linux-3.8.13-x86_64: ERRORS >> linux-3.9.11-i686: ERRORS >> linux-3.9.11-x86_64: ERRORS >> linux-3.10.108-i686: ERRORS >> linux-3.10.108-x86_64: ERRORS >> linux-3.11.10-i686: ERRORS >> linux-3.11.10/arch/x86/include/asm/msr.h:131, >> linux-3.11.10-x86_64: ERRORS >> linux-3.12.74-i686: ERRORS >> linux-3.12.74-x86_64: ERRORS >> linux-3.13.11-i686: ERRORS >> linux-3.13.11-x86_64: ERRORS >> linux-3.14.79-i686: ERRORS >> linux-3.14.79-x86_64: ERRORS >> linux-3.15.10-i686: ERRORS >> linux-3.15.10-x86_64: ERRORS >> linux-3.16.57-i686: ERRORS >> linux-3.16.57-x86_64: ERRORS >> linux-3.17.8-i686: ERRORS >> linux-3.17.8-x86_64: ERRORS >> linux-3.18.119-i686: ERRORS >> linux-3.18.119-x86_64: ERRORS >> linux-3.19.8-i686: ERRORS >> linux-3.19.8-x86_64: ERRORS >> linux-4.0.9-i686: ERRORS >> linux-4.0.9-x86_64: ERRORS >> linux-4.1.52-i686: ERRORS >> linux-4.1.52-x86_64: ERRORS >> linux-4.2.8-i686: ERRORS >> linux-4.2.8-x86_64: ERRORS >> linux-4.3.6-i686: ERRORS >> linux-4.3.6-x86_64: ERRORS >> linux-4.4.152-i686: ERRORS >> linux-4.4.152-x86_64: ERRORS >> linux-4.5.7-i686: ERRORS >> linux-4.5.7-x86_64: ERRORS >> linux-4.6.7-i686: ERRORS >> linux-4.6.7-x86_64: ERRORS >> linux-4.7.10-i686: ERRORS >> linux-4.7.10-x86_64: ERRORS >> linux-4.8.17-i686: ERRORS >> linux-4.8.17-x86_64: ERRORS >> linux-4.9.124-i686: ERRORS >> linux-4.9.124-x86_64: ERRORS >> linux-4.10.17-i686: ERRORS >> linux-4.10.17-x86_64: ERRORS >> linux-4.11.12-i686: ERRORS >> linux-4.11.12-x86_64: ERRORS >> linux-4.12.14-i686: ERRORS >> linux-4.12.14-x86_64: ERRORS >> linux-4.13.16-i686: ERRORS >> linux-4.13.16-x86_64: ERRORS >> linux-4.14.67-i686: ERRORS >> linux-4.14.67-x86_64: ERRORS >> linux-4.15.18-i686: ERRORS >> linux-4.15.18-x86_64: ERRORS >> linux-4.16.18-i686: ERRORS >> linux-4.16.18-x86_64: ERRORS >> linux-4.17.19-i686: ERRORS >> linux-4.17.19-x86_64: ERRORS >> linux-4.18.5-i686: ERRORS >> linux-4.18.5-x86_64: ERRORS >> linux-4.19-rc1-i686: OK >> linux-4.19-rc1-x86_64: OK >> apps: OK >> specified for parameter 'printk_address' >> specified for parameter 'printk_address' >> specified for parameter 'socket_seq_show' >> specified for parameter 'probe_kernel_write' >> specified for parameter '__bitmap_intersects' >> specified for parameter '__bitmap_intersects' >> specified for parameter 'numa_set_node' >> specified for parameter 'do_splice_direct'
Re: [PATCH] vicodec: change codec license to LGPL
On 09/03/2018 03:17 AM, Mauro Carvalho Chehab wrote: > Em Sun, 2 Sep 2018 12:37:04 +0200 > Hans Verkuil escreveu: > >> The FWHT codec can also be used by userspace utilities and libraries, but >> since the current license is GPL and not LGPL it is not possible to include >> it in e.g. gstreamer, since LGPL is required for that. >> >> Change the license of these four files to LGPL. >> >> Signed-off-by: Hans Verkuil >> --- >> Tom, if you agree to this, can you give your 'Signed-off-by' line? I cannot >> make this change for the codec-fwht.c/h files without it. I think this change >> makes sense. >> >> Regards, >> >> Hans >> --- >> diff --git a/drivers/media/platform/vicodec/codec-fwht.c >> b/drivers/media/platform/vicodec/codec-fwht.c >> index 47939160560e..36656031b295 100644 >> --- a/drivers/media/platform/vicodec/codec-fwht.c >> +++ b/drivers/media/platform/vicodec/codec-fwht.c >> @@ -1,4 +1,4 @@ >> -// SPDX-License-Identifier: GPL-2.0+ >> +// SPDX-License-Identifier: LGPL-2.1+ > > There aren't much C files under LGPL at the Kernel. Yeah, I know it > is compatible with GPL-2.0+, but I would prefer it the tag would > be, instead: > > // SPDX-License-Identifier: GPL-2.0+ OR LGPL-2.1+ > > as this makes easier if one uses some software to parse the Kernel > tree. > > (same applies to the other files). I don't see the point. Grepping for this shows nobody else doing that. LGPL is one of the preferred licenses (LICENSES/preferred/), so I don't see what you gain by supporting both. I don't see why this would make it easier parsing the kernel, since that's what the SPDX tag is for. Regards, Hans > > Regards, > Mauro > >> /* >> * Copyright 2016 Tom aan de Wiel >> * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights >> reserved. >> diff --git a/drivers/media/platform/vicodec/codec-fwht.h >> b/drivers/media/platform/vicodec/codec-fwht.h >> index 1f9e47331197..3e9391fec5fe 100644 >> --- a/drivers/media/platform/vicodec/codec-fwht.h >> +++ b/drivers/media/platform/vicodec/codec-fwht.h >> @@ -1,4 +1,4 @@ >> -/* SPDX-License-Identifier: GPL-2.0+ */ >> +/* SPDX-License-Identifier: LGPL-2.1+ */ >> /* >> * Copyright 2016 Tom aan de Wiel >> * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights >> reserved. >> diff --git a/drivers/media/platform/vicodec/codec-v4l2-fwht.c >> b/drivers/media/platform/vicodec/codec-v4l2-fwht.c >> index cfcf84b8574d..6b06aa382cbb 100644 >> --- a/drivers/media/platform/vicodec/codec-v4l2-fwht.c >> +++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.c >> @@ -1,4 +1,4 @@ >> -// SPDX-License-Identifier: GPL-2.0 >> +// SPDX-License-Identifier: LGPL-2.1 >> /* >> * A V4L2 frontend for the FWHT codec >> * >> diff --git a/drivers/media/platform/vicodec/codec-v4l2-fwht.h >> b/drivers/media/platform/vicodec/codec-v4l2-fwht.h >> index 7794c186d905..95d1756556db 100644 >> --- a/drivers/media/platform/vicodec/codec-v4l2-fwht.h >> +++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.h >> @@ -1,4 +1,4 @@ >> -/* SPDX-License-Identifier: GPL-2.0 */ >> +/* SPDX-License-Identifier: LGPL-2.1 */ >> /* >> * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights >> reserved. >> */ > > > > Thanks, > Mauro >
