date:20181004

Re: s5p_mfc and H.264 frame cropping question

2018-10-04 Thread Hans Verkuil

On 10/05/2018 05:12 AM, Tomasz Figa wrote:
> Hi Hans,
> 
> On Fri, Oct 5, 2018 at 5:02 AM Hans Verkuil  wrote:
>>
>> Hi all,
>>
>> I'm looking at removing the last users of vidioc_g/s_crop from the driver and
>> I came across vidioc_g_crop in drivers/media/platform/s5p-mfc/s5p_mfc_dec.c.
>>
>> What this really does AFAICS is return the H.264 frame crop as read from the
>> bitstream. This has nothing to do with regular cropping/composing but it 
>> might be
>> something that could be implemented as a new selection target.
> 
> It has a lot to do, because the output frame buffer may contain (and
> on the hardware I worked with, s5p-mfc and mtk-vcodec, indeed does)
> the whole encoded stream and the frame crop from the bitstream
> specifies the rectangle within it that corresponds to the part that
> should be displayed.

Yes, but is that part actually cropped? Or is the full uncropped image DMAed
to the capture buffer?

To take a practical example: a H.264 stream with a 1920x1088 image and a frame
crop rectangle of 1920x1080. What is the G_FMT width/height for the decoder
capture stream: 1920x1088 or 1920x1080?

If it is 1920x1088, then you have a compose rectangle. If it is 1920x1080 then
you have a crop rectangle.

As far as I can tell from this driver it actually has a compose rectangle
and the use of g_crop is wrong and is there due to historical reasons (the
driver predates the selection API).

> 
>>
>> I'm not really sure what to do with the existing code since it is an abuse of
>> the crop API, but I guess the first step is to decide how this should be 
>> handled
>> properly.
>>
>> Are there other decoders that can retrieve this information? Should this be
>> mentioned in the stateful codec API?
> 
> coda [1], mtk-vcodec [2] and venus [3] expose this using the
> V4L2_SEL_TGT_COMPOSE selection target. v1 of the specification defines
> the selection targets in a way, which is compatible with that:
> V4L2_SEL_TGT_COMPOSE defaults to V4L2_SEL_TGT_COMPOSE_DEFAULT, which
> equals to V4L2_SEL_TGT_CROP, which defaults to
> V4L2_SEL_TGT_CROP_DEFAULT, which is defined as follows:
> 
> +  ``V4L2_SEL_TGT_CROP_DEFAULT``
> +  a rectangle covering the part of the frame buffer that contains
> +  meaningful picture data (visible area); width and height will be
> +  equal to visible resolution of the stream

Where do you get that from? That's the crop definition for an output stream,
not a capture stream (assuming we have a codec).

I kind of lost you with "which equals to V4L2_SEL_TGT_CROP".

In any case, this particular driver should implement g_selection for
CAPTURE and implement the COMPOSE targets. That makes sense.

Regards,

Hans

> 
> AFAIR s5p-mfc was added before the selection API went into active use,
> so there is some user space that relies on the crop API. We should
> make the driver expose proper selection targets and add a comment next
> to the crop API implementation explaining the historical reasons. The
> specification should mention only the selection API.
> 
> [1] 
> https://elixir.bootlin.com/linux/v4.19-rc6/source/drivers/media/platform/coda/coda-common.c#L892
> [2] 
> https://elixir.bootlin.com/linux/v4.19-rc6/source/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c#L740
> [3] 
> https://elixir.bootlin.com/linux/v4.19-rc6/source/drivers/media/platform/qcom/venus/vdec.c#L300
> 
> Best regards,
> Tomasz
>

GODA NYHETER

2018-10-04 Thread Mrs. Ursula Zachary

Min kära stödmottagare,

Jag är säker på att detta mail kommer att komma till dig som en överraskning 
eftersom vi aldrig har träffat förut och du skulle också fråga varför jag har 
bestämt mig för att välja dig bland de många internetanvändarna i världen. 
Exakt kan jag inte säga varför jag har valt dig, men var inte orolig för att 
jag såg din profil på Internet, vilket har gjort att jag utför min begäran. Må 
den allsmäktige guden välsigna och se dig igenom med detta uppdrag om du noga 
kan läsa och smälta meddelandet nedan.

Innan jag går vidare, tillåt mig att ge dig lite av min biografi, jag är mor 
Ursula Zachary, 72 år gammal kvinna och fru Senon Danon Zacharys maka som dog 
efter en lång sjukdom måndagen den 7 september 1998 GMT 14: 22 Storbritannien.

Efter min mans död blev jag chef för hans investering och nu när jag är gammal 
och svag har jag bestämt mig för att spendera resten av mitt liv med min familj 
och mina kära som jag aldrig haft tid för under mitt affärsliv , men före min 
mans död hade vi en plan att använda de sista dagarna i våra liv för att donera 
hälften av det vi har arbetat för till de mindre privilegierna och 
välgörenhetshemmen och den andra hälften för oss själva, familjemedlemmar och 
nära vänner, och Det är så olyckligt att min man inte lever i dag för att göra 
det här med mig och jag är väldigt svag och gammal nu, därför har jag bestämt 
mig för att göra detta filantropiska arbete på uppdrag av min sena make och jag.

För närvarande har jag testat ut nästan hälften av våra tillgångar till flera 
välgörenhetshem och till några av de mindre privilegierade i olika länder. 
Trots överenskommelsen mellan min sena man och jag att ge stöd till de fattiga, 
kom vi också överens om att ge stöd till en person som vi inte har träffat 
tidigare i livet på grund av det faktum att vi fortfarande var unga i livet får 
vi en anonym hjälp från en individ vi inte visste och som vi inte har kunnat 
veta till datum, gjorde den effekt vi fick av en sådan gest det att vi gjorde 
detsamma.

Jag är ledsen att informera dig om att du aldrig kommer att få chansen att 
känna mig, för jag har just avslutat det uppdrag som min man och jag har kommit 
överens om före hans plötsliga död och du råkade vara mottagaren av vår sista 
vilja, oavsett din tidigare finansiell status, därför behöver jag dig att göra 
mig en tjänst genom att acceptera vårt erbjudande som kommer att kosta dig 
ingenting.

Jag har för närvarande deponerat en check i summan av $ 5.800.000,00 USA-dollar 
med ING Bank NV att överföra till dig. Vad du måste göra nu är att kontakta ING 
Bank NV så snart som möjligt för att veta när de kommer att överföra dina 
pengar till dig eftersom av utgångsdatum.

Jag gjorde bara insättningen med din E-postadress och Depositionskod 
(20357478492) eftersom jag inte känner till ditt bankkontonummer som du vill få 
pengarna med. Jag kunde inte hitta dem på nätet medan du surfar på din profil 
om inte jag skulle ha gett det till banken för omedelbar överföring.

För din information har jag betalat för försäkringspremien och 
överföringsavgiften för kontanter som visar att det inte är en drogpenning 
eller som är avsedd att sponsra terrorism i ditt land.

Låt mig upprepa igen, du ska inte betala för försäkringspremien och 
checkavgiften för banköverföring eftersom jag redan har betalat för dem, det 
enda pengar du förväntas betala är $ 85 amerikanska dollar för kontoaktivering 
för att aktivera Överför beloppet till ditt lokala konto utan att du betalar 
några ytterligare avgifter för överföring. Jag skulle ha betalat avgiften men 
banken insisterade på att jag inte borde, eftersom de inte vet när du kommer 
att kontakta dem och för att undvika demurrage eller ytterligare kostnader. Var 
vänlig min kära om du vet att du inte hjälper mig med $ 85 amerikanska dollar. 
Var snäll och kontakta mig eller ING Bank, snälla, jag behöver någon som 
hjälper mig.

Du måste kontakta banken nu för överföring av checken med den här informationen 
nedan.

Bankens namn: ING Bank N.V
Kontaktperson: Dr Steven C.B
Tel: +447452059980
E-post: ste...@ingbankuk.com

Du måste bekräfta informationen nedan för att undvika fel vid överföring.
Postadress;
Fullständiga namn:
Direkt telefonnummer;

Nedan finns avkastningskoden (20357478492) i utkastet, du ska också presentera 
dem för verifiering före överföring.

Obs: Vänligen vill jag inte att du ska tacka mig eller min man allt jag behöver 
dig att göra är att investera klokt med det och göra samma gott för någons liv 
en dag eftersom det här är det enda sättet att världen skulle bli en bättre 
gemenskap om vi göra osjälviska tjänster till varandra.

Med vänliga hälsningar,
Fru Ursula Zachary

[PATCH v7 6/6] media: add Rockchip VPU JPEG encoder driver

2018-10-04 Thread Ezequiel Garcia

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/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/rockchip/vpu/Kconfig|  13 +
 drivers/staging/media/rockchip/vpu/Makefile   |   9 +
 drivers/staging/media/rockchip/vpu/TODO   |   9 +
 .../media/rockchip/vpu/rk3288_vpu_hw.c| 125 
 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 127 
 .../media/rockchip/vpu/rk3288_vpu_regs.h  | 442 +
 .../media/rockchip/vpu/rk3399_vpu_hw.c| 125 
 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 155 +
 .../media/rockchip/vpu/rk3399_vpu_regs.h  | 600 +
 .../staging/media/rockchip/vpu/rockchip_vpu.h | 278 
 .../media/rockchip/vpu/rockchip_vpu_common.h  |  31 +
 .../media/rockchip/vpu/rockchip_vpu_drv.c | 527 +++
 .../media/rockchip/vpu/rockchip_vpu_enc.c | 606 ++
 .../media/rockchip/vpu/rockchip_vpu_hw.h  |  65 ++
 17 files changed, 3122 insertions(+)
 create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
 create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
 create mode 100644 drivers/staging/media/rockchip/vpu/TODO
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 6d69f3ad1aa9..f0dc5dfcfae4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12459,6 +12459,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/staging/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/staging/media/Kconfig b/drivers/staging/media/Kconfig
index b3620a8f2d9f..c6f3404dea43 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
 
 source "drivers/staging/media/omap4iss/Kconfig"
 
+source "drivers/staging/media/rockchip/vpu/Kconfig"
+
 source "drivers/staging/media/sunxi/Kconfig"
 
 source "drivers/staging/media/tegra-vde/Kconfig"
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index 42948f805548..43c7bee1fc8c 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4)   += omap4iss/
 obj-$(CONFIG_VIDEO_SUNXI)  += sunxi/
 obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
 obj-$(CONFIG_VIDEO_ZORAN)  += zoran/
+obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/
diff --git a/drivers/staging/media/rockchip/vpu/Kconfig 
b/drivers/staging/media/rockchip/vpu/Kconfig
new file mode 100644
index ..12bb79fd69f9
--- /dev/null
+++ b/drivers/staging/media/rockchip/vpu/Kconfig
@@ -0,0 +1,13 @@
+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.
+
diff --git a/drivers/staging/media/rockchip/vpu/Makefile 
b/drivers/staging/media/rockchip/vpu/Makefile
new file mode 100644
index ..2fb99adfbdb9
--- /dev/null
+++ b/drivers/staging/media/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_jpeg_enc.o \
+   rk3399_vpu_hw.o \
+   rk3399_vpu_hw_jpeg_enc.o
d

[PATCH v7 4/6] media: Add JPEG_RAW format

2018-10-04 Thread Ezequiel Garcia

From: Shunqian Zheng 

Add V4L2_PIX_FMT_JPEG_RAW format that does not contain
JPEG header in the output frame.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Ezequiel Garcia 
---
 Documentation/media/uapi/v4l/pixfmt-compressed.rst | 9 +
 drivers/media/v4l2-core/v4l2-ioctl.c   | 1 +
 include/uapi/linux/videodev2.h | 1 +
 3 files changed, 11 insertions(+)

diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst 
b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
index ba0f6c49d9bf..ad73076276ec 100644
--- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
@@ -23,6 +23,15 @@ Compressed Formats
   - 'JPEG'
   - TBD. See also :ref:`VIDIOC_G_JPEGCOMP `,
:ref:`VIDIOC_S_JPEGCOMP `.
+* .. _V4L2-PIX-FMT-JPEG-RAW:
+
+  - ``V4L2_PIX_FMT_JPEG_RAW``
+  - 'Raw JPEG'
+  - Raw JPEG bitstream, containing a compressed payload. This format
+contains an image scan, i.e. without any metadata or headers.
+The user is expected to set the needed metadata such as
+quantization and entropy encoding tables, via ``V4L2_CID_JPEG``
+controls, see :ref:`jpeg-control-id`.
 * .. _V4L2-PIX-FMT-MPEG:
 
   - ``V4L2_PIX_FMT_MPEG``
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index c148c44caffb..5eab42277f47 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1301,6 +1301,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
/* Max description length mask: descr = 
"0123456789012345678901234567890" */
case V4L2_PIX_FMT_MJPEG:descr = "Motion-JPEG"; break;
case V4L2_PIX_FMT_JPEG: descr = "JFIF JPEG"; break;
+   case V4L2_PIX_FMT_JPEG_RAW: descr = "Raw JPEG"; break;
case V4L2_PIX_FMT_DV:   descr = "1394"; break;
case V4L2_PIX_FMT_MPEG: descr = "MPEG-1/2/4"; break;
case V4L2_PIX_FMT_H264: descr = "H.264"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 7412a255d9ce..1c7b5df4eb83 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -627,6 +627,7 @@ struct v4l2_pix_format {
 /* compressed formats */
 #define V4L2_PIX_FMT_MJPEGv4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG   
*/
 #define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG 
*/
+#define V4L2_PIX_FMT_JPEG_RAW v4l2_fourcc('J', 'P', 'G', 'R') /* JFIF JPEG RAW 
without headers */
 #define V4L2_PIX_FMT_DV   v4l2_fourcc('d', 'v', 's', 'd') /* 1394  
*/
 #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 
Multiplexed */
 #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with 
start codes */
-- 
2.19.0.rc2

[PATCH v7 2/6] ARM: dts: rockchip: add VPU device node for RK3288

2018-10-04 Thread Ezequiel Garcia

Add the Video Processing Unit node for RK3288 SoC.

Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/boot/dts/rk3288.dtsi | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
 
+   vpu: video-codec@ff9a {
+   compatible = "rockchip,rk3288-vpu";
+   reg = <0x0 0xff9a 0x0 0x800>;
+   interrupts = ,
+;
+   interrupt-names = "vepu", "vdpu";
+   clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+   clock-names = "aclk", "hclk";
+   power-domains = <&power RK3288_PD_VIDEO>;
+   iommus = <&vpu_mmu>;
+   };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
clock-names = "aclk", "iface";
+   power-domains = <&power RK3288_PD_VIDEO>;
#iommu-cells = <0>;
-   status = "disabled";
};
 
hevc_mmu: iommu@ff9c0440 {
-- 
2.19.0.rc2

[PATCH v7 5/6] media: Add controls for JPEG quantization tables

2018-10-04 Thread Ezequiel Garcia

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  | 25 +++
 .../media/videodev2.h.rst.exceptions  |  1 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  8 ++
 include/uapi/linux/v4l2-controls.h| 10 
 include/uapi/linux/videodev2.h|  1 +
 5 files changed, 45 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 65a1d873196b..6effae175be1 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3530,7 +3530,32 @@ 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.
+This control supports 8-bit quantization coefficients, for
+the baseline profile, as specified by :ref:`itu-t81`.
+Coefficients must be set in JPEG zigzag scan order.
+
+
+.. 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.
 
 .. flat-table::
 :header-rows:  0
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index 30ba0d6f546f..bd210f7d0afc 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -131,6 +131,7 @@ 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_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
 replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTIZATION :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 65e3cf838ac7..a8612ad42010 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1001,6 +1001,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! */
@@ -1288,6 +1289,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;
@@ -1667,6 +1671,7 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 
idx,
return 0;
 
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
+   case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
return 0;
 
default:
@@ -2249,6 +2254,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
elem_size = sizeof(struct v4l2_ctrl_mpeg2_quantization);
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 51b095898f4b..5a8bdb732cfe 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -990,6 +990,16 @@ enum v4l2_jpeg_chroma_subsampling {
 #defineV4L2_JPEG_ACTIVE_MARKER_DQT (1 << 17)
 #defineV4L2_JPEG_ACTIVE_MARKER_DHT (1 << 18)
 
+#define V4L2_CID_JPEG_QUANTIZATION (V4L2_CID_JPEG_CLASS_BASE + 5)
+struct v4l2_ctrl_jpeg_quantization {
+   /* ITU-T.81 specifies two quantization coefficient precisions:
+* 8-bit

[PATCH v7 0/6] Add Rockchip VPU JPEG encoder

2018-10-04 Thread Ezequiel Garcia

This series adds support for JPEG encoding via the VPU block
present in Rockchip platforms. Currently, support for RK3288
and RK3399 is included.

Please, see the previous versions of this cover letter for
more information.

This series should apply cleanly on top of

  git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.

If everyone is happy with this series, I'd like to route the devicetree
changes through the rockchip tree, and the rest via the media subsystem.

Compliance
==

(Same results as v3)

v4l2-compliance SHA: d0f4ea7ddab6d0244c4fe1e960bb2aaeefb911b9, 64 bits

Compliance test for device /dev/video0:

Driver Info:
Driver name  : rockchip-vpu
Card type: rockchip,rk3399-vpu-enc
Bus info : platform: rockchip-vpu
Driver version   : 4.18.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps  : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name  : rockchip-vpu
Model: rockchip-vpu
Serial   : 
Bus info : 
Media version: 4.18.0
Hardware revision: 0x (0)
Driver version   : 4.18.0
Interface Info:
ID   : 0x030c
Type : V4L Video
Entity Info:
ID   : 0x0001 (1)
Name : rockchip,rk3399-vpu-enc-source
Function : V4L2 I/O
Pad 0x0102   : Source
  Link 0x0208: to remote pad 0x105 of entity 
'rockchip,rk3399-vpu-enc-proc': Data, Enabled, Immutable

Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second /dev/video0 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 2 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:

Streaming ioctls:
test read/write: OK (Not Supported)
test blocking wait: OK
test MMAP: OK 
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device

Total: 48, Succeeded: 48, Failed: 0, Warnings: 0

v7:
  - Fix checkpatch --strict issues.
  - Fix extra blank line in binding doc.

v6:
  - As agreed with Hans change the quantization control
to support only strict baseline JPEGs, with 8-bit
coefficients.
v5:
  - Make coefficients 2-byte wide, to support 8-bit and 16-bit
precision coefficient. Also, add a 'precision' field, to
allow the user to specifiy the coefficient precision.
  - Minor style changes a

[PATCH v7 1/6] dt-bindings: Document the Rockchip VPU bindings

2018-10-04 Thread Ezequiel Garcia

Add devicetree binding documentation for Rockchip Video Processing
Unit IP.

Reviewed-by: Rob Herring 
Signed-off-by: Ezequiel Garcia 
---
 .../bindings/media/rockchip-vpu.txt   | 29 +++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt

diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt 
b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
new file mode 100644
index ..35dc464ad7c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
@@ -0,0 +1,29 @@
+device-tree bindings for rockchip VPU codec
+
+Rockchip (Video Processing Unit) present in various Rockchip platforms,
+such as RK3288 and RK3399.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-vpu";
+   "rockchip,rk3399-vpu";
+- interrupts: encoding and decoding interrupt specifiers
+- interrupt-names: should be "vepu" and "vdpu"
+- clocks: phandle to VPU aclk, hclk clocks
+- clock-names: should be "aclk" and "hclk"
+- power-domains: phandle to power domain node
+- iommus: phandle to a iommu node
+
+Example:
+SoC-specific DT entry:
+   vpu: video-codec@ff9a {
+   compatible = "rockchip,rk3288-vpu";
+   reg = <0x0 0xff9a 0x0 0x800>;
+   interrupts = ,
+;
+   interrupt-names = "vepu", "vdpu";
+   clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+   clock-names = "aclk", "hclk";
+   power-domains = <&power RK3288_PD_VIDEO>;
+   iommus = <&vpu_mmu>;
+   };
-- 
2.19.0.rc2

[PATCH v7 3/6] arm64: dts: rockchip: add VPU device node for RK3399

2018-10-04 Thread Ezequiel Garcia

Add the Video Processing Unit node for the RK3399 SoC.

Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index c88e603396f6..5efb124e5c3a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1198,6 +1198,18 @@
status = "disabled";
};
 
+   vpu: video-codec@ff65 {
+   compatible = "rockchip,rk3399-vpu";
+   reg = <0x0 0xff65 0x0 0x800>;
+   interrupts = ,
+;
+   interrupt-names = "vepu", "vdpu";
+   clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+   clock-names = "aclk", "hclk";
+   power-domains = <&power RK3399_PD_VCODEC>;
+   iommus = <&vpu_mmu>;
+   };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1205,8 +1217,8 @@
interrupt-names = "vpu_mmu";
clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
clock-names = "aclk", "iface";
+   power-domains = <&power RK3399_PD_VCODEC>;
#iommu-cells = <0>;
-   status = "disabled";
};
 
vdec_mmu: iommu@ff660480 {
-- 
2.19.0.rc2

Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder

2018-10-04 Thread Ezequiel Garcia

On Mon, 2018-10-01 at 14:54 -0300, Ezequiel Garcia wrote:
> On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:
> > On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > > This series adds support for JPEG encoding via the VPU block
> > > present in Rockchip platforms. Currently, support for RK3288
> > > and RK3399 is included.
> > > 
> > > Please, see the previous versions of this cover letter for
> > > more information.
> > > 
> > > Compared to v5, the only change is in the V4L2_CID_JPEG_QUANTIZATION
> > > control. We've decided to support only baseline profile,
> > > and only add 8-bit luma and chroma tables.
> > > 
> > > struct v4l2_ctrl_jpeg_quantization {
> > >__u8luma_quantization_matrix[64];
> > >__u8chroma_quantization_matrix[64];
> > > };
> > > 
> > > By doing this, it's clear that we don't currently support anything
> > > but baseline.
> > > 
> > > This series should apply cleanly on top of
> > > 
> > >   git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> > > 
> > > If everyone is happy with this series, I'd like to route the devicetree
> > > changes through the rockchip tree, and the rest via the media subsystem.
> > 
> > OK, so I have what is no doubt an annoying question: do we really need
> > a JPEG_RAW format?
> > 
> 
> Not annoying, as it helps clarify a few things :-)
> I think we do need the JPEG_RAW format. The way I see it, using
> JPEG opens a can of worms...
> 
> > The JPEG header is really easy to parse for a decoder and really easy to
> > prepend to the compressed image for the encoder.
> > 
> > The only reason I can see for a JPEG_RAW is if the image must start at
> > some specific address alignment. Although even then you can just pad the
> > JPEG header that you will add according to the alignment requirements.
> > 
> > I know I am very late with this question, but I never looked all that
> > closely at what a JPEG header looks like. But this helped:
> > 
> > https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
> > 
> > and it doesn't seem difficult at all to parse or create the header.
> > 
> > 
> 
> ... I think that having JPEG_RAW as the compressed format
> is much more clear for userspace, as it explicitly specifies
> what is expected.
> 
> This way, for a stateless encoder, applications are required
> to set quantization and/or entropy tables, and are then in
> charge of using the compressed JPEG_RAW payload in whatever form
> they want. Stupid simple.
> 
> On the other side, if the stateless encoder driver supports
> JPEG (creating headers in-kernel), it means that:
> 
> *) applications should pass a quality control, if supported,
> and the driver will use hardcoded tables or...
> 
> *) applications pass quantization control and, if supported,
> entropy control. The kernel uses them to create the JPEG frame.
> But also, some drivers (e.g. Rockchip), use default entropy
> tables, which should now be in the kernel.
> 
> So the application would have to query controls to find out
> what to do. Not exactly hard, but I think having the JPEG_RAW
> is much simpler and more clear.
> 
> Now, for stateless decoders, supporting JPEG_RAW means
> the application has to pass quantization and entropy
> controls, probably using the Request API.
> Given the application has parsed the JPEG,
> it knows the width and height and can request
> buffers accordingly.
> 
> The hardware is stateless, and so is the driver.
> 
> On the other hand, supporting JPEG would mean that
> drivers will have to parse the image, extracting
> the quantization and entropy tables.
> 
> Format negotiation is now more complex,
> either we follow the stateful spec, introducing a little
> state machine in the driver... or we use the Request API,
> but that means parsing on both sides kernel and application.
> 
> Either way, using JPEG_RAW is just waaay simpler and puts
> things where they belong. 
> 

As discussed on IRC, I'm sending a v7 for this series,
fixing only the checkpatch issues and the extra line in the
binding document.

We've agreed to move forward with JPEG_RAW, for the reasons
stated above.

Plus, we've agreed to keep this in staging until the userspace
support for JPEG_RAW format is clear.

Regards,
Ezequiel

Re: [PATCH 2/2] media: rc: self test for IR encoders and decoders

2018-10-04 Thread Sean Young

Hi Shuah,

On Thu, Oct 04, 2018 at 02:13:51PM -0600, Shuah Khan wrote:
> Hi Sean,
> 
> Thanks for the patch. I just happened to see this when Mauro sent it to me.
> Doesn't look like linux-ksefltest and I weren't on the patch?

This is true, and that is an oversight on my behalf.

Thank you for your review -- I agree with all your points and thanks for the
helpful tips as well. I will fix for v2.

Thanks again,

Sean

> 
> On 07/17/2018 03:33 PM, Sean Young (by way of Mauro Carvalho Chehab 
> ) wrote:
> > ir-loopback can transmit IR on one rc device and check the correct
> > scancode and protocol is decoded on a different rc device. This can be
> > used to check IR transmission between two rc devices. Using rc-loopback,
> > we use it to check the IR encoders and decoders themselves.
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  tools/testing/selftests/Makefile  |   1 +
> >  tools/testing/selftests/ir/.gitignore |   1 +
> >  tools/testing/selftests/ir/Makefile   |  19 ++
> >  tools/testing/selftests/ir/config |  12 ++
> >  tools/testing/selftests/ir/ir-loopback.c  | 209 ++
> >  tools/testing/selftests/ir/ir-loopback.sh |  28 +++
> >  6 files changed, 270 insertions(+)
> >  create mode 100644 tools/testing/selftests/ir/.gitignore
> >  create mode 100644 tools/testing/selftests/ir/Makefile
> >  create mode 100644 tools/testing/selftests/ir/config
> >  create mode 100644 tools/testing/selftests/ir/ir-loopback.c
> >  create mode 100755 tools/testing/selftests/ir/ir-loopback.sh
> 
> Why not add to the existing media directory? ../selftests/media_tests?
> 
> > 
> > diff --git a/tools/testing/selftests/Makefile 
> > b/tools/testing/selftests/Makefile
> > index f1fe492c8e17..995034ea5546 100644
> > --- a/tools/testing/selftests/Makefile
> > +++ b/tools/testing/selftests/Makefile
> > @@ -15,6 +15,7 @@ TARGETS += futex
> >  TARGETS += gpio
> >  TARGETS += intel_pstate
> >  TARGETS += ipc
> > +TARGETS += ir
> 
> Does this test depend on any hardware being present in the system?
> 
> >  TARGETS += kcmp
> >  TARGETS += kvm
> >  TARGETS += lib
> > diff --git a/tools/testing/selftests/ir/.gitignore 
> > b/tools/testing/selftests/ir/.gitignore
> > new file mode 100644
> > index ..87bf2989b678
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/.gitignore
> > @@ -0,0 +1 @@
> > +ir-loopback
> > diff --git a/tools/testing/selftests/ir/Makefile 
> > b/tools/testing/selftests/ir/Makefile
> > new file mode 100644
> > index ..501b464e56b5
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/Makefile
> > @@ -0,0 +1,19 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +uname_M := $(shell uname -m 2>/dev/null || echo not)
> > +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
> > +ifeq ($(ARCH),i386)
> > +ARCH := x86
> > +   CFLAGS := -DCONFIG_X86_32 -D__i386__
> > +endif
> > +ifeq ($(ARCH),x86_64)
> > +   ARCH := x86
> > +   CFLAGS := -DCONFIG_X86_64 -D__x86_64__
> > +endif
> > +
> > +CFLAGS += -I../../../../usr/include/
> > +
> > +TEST_PROGS := ir-loopback.sh
> > +
> > +TEST_GEN_PROGS := ir-loopback
> 
> Looks like ir-loopback get run from ir-loopback.sh. TEST_GEN_PROGS_EXTENDED
> is the right variable to use in this case.
> 
> TEST_GEN_PROGS_EXTENDED := ir-loopback
> 
> > +
> > +include ../lib.mk
> > diff --git a/tools/testing/selftests/ir/config 
> > b/tools/testing/selftests/ir/config
> > new file mode 100644
> > index ..78e041e9319e
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/config
> > @@ -0,0 +1,12 @@
> > +CONFIG_RC_CORE=y
> > +CONFIG_RC_LOOPBACK=y
> > +CONFIG_IR_NEC_DECODER=m
> > +CONFIG_IR_RC5_DECODER=m
> > +CONFIG_IR_RC6_DECODER=m
> > +CONFIG_IR_JVC_DECODER=m
> > +CONFIG_IR_SONY_DECODER=m
> > +CONFIG_IR_SANYO_DECODER=m
> > +CONFIG_IR_SHARP_DECODER=m
> > +CONFIG_IR_MCE_KBD_DECODER=m
> > +CONFIG_IR_XMP_DECODER=m
> > +CONFIG_IR_IMON_DECODER=m
> > diff --git a/tools/testing/selftests/ir/ir-loopback.c 
> > b/tools/testing/selftests/ir/ir-loopback.c
> > new file mode 100644
> > index ..95b6f0f2f1f5
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/ir-loopback.c
> > @@ -0,0 +1,209 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// test ir decoder
> > +//
> > +// Copyright (C) 2018 Sean Young 
> > +
> > +// When sending LIRC_MODE_SCANCODE, the IR will be encoded. rc-loopback
> > +// will send this IR to the receiver side, where we try to read the decoded
> > +// IR. Decoding happens in a separate kernel thread, so we will need to
> > +// wait until that is scheduled, hence we use poll to check for read
> > +// readiness.
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define TEST_SCANCODES 10
> > +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> > +
> > +static const struct {
> > +   enum rc_proto proto;
> > +   co

Re: [PATCH v6 1/6] dt-bindings: Document the Rockchip VPU bindings

2018-10-04 Thread Ezequiel Garcia

On Fri, 2018-09-28 at 13:53 +0200, Hans Verkuil wrote:
> On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > Add devicetree binding documentation for Rockchip Video Processing
> > Unit IP.
> > 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  .../bindings/media/rockchip-vpu.txt   | 30 +++
> >  1 file changed, 30 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt 
> > b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
> > new file mode 100644
> > index ..5e0d421301ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
> > @@ -0,0 +1,30 @@
> > +device-tree bindings for rockchip VPU codec
> > +
> > +Rockchip (Video Processing Unit) present in various Rockchip platforms,
> > +such as RK3288 and RK3399.
> > +
> > +Required properties:
> > +- compatible: value should be one of the following
> > +   "rockchip,rk3288-vpu";
> > +   "rockchip,rk3399-vpu";
> > +- interrupts: encoding and decoding interrupt specifiers
> > +- interrupt-names: should be "vepu" and "vdpu"
> > +- clocks: phandle to VPU aclk, hclk clocks
> > +- clock-names: should be "aclk" and "hclk"
> > +- power-domains: phandle to power domain node
> > +- iommus: phandle to a iommu node
> > +
> > +Example:
> > +SoC-specific DT entry:
> > +   vpu: video-codec@ff9a {
> > +   compatible = "rockchip,rk3288-vpu";
> > +   reg = <0x0 0xff9a 0x0 0x800>;
> > +   interrupts = ,
> > +;
> > +   interrupt-names = "vepu", "vdpu";
> > +   clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
> > +   clock-names = "aclk", "hclk";
> > +   power-domains = <&power RK3288_PD_VIDEO>;
> > +   iommus = <&vpu_mmu>;
> > +   };
> > +
> > 
> 
> Please remove this empty last line to avoid this warning:
> 
> .git/rebase-apply/patch:41: new blank line at EOF.
> 
> 

Will fix.

Thanks,
Eze

[PATCH] media: cec: name for RC passthrough device does not need 'RC for'

2018-10-04 Thread Sean Young

An RC device is does not need to be called 'RC for'. Simply the name
will suffice.

Signed-off-by: Sean Young 
---
 drivers/media/cec/cec-core.c | 6 ++
 include/media/cec.h  | 2 --
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 74596f089ec9..e4edc930d4ed 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -307,12 +307,10 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
return ERR_PTR(-ENOMEM);
}
 
-   snprintf(adap->device_name, sizeof(adap->device_name),
-"RC for %s", name);
snprintf(adap->input_phys, sizeof(adap->input_phys),
-"%s/input0", name);
+"%s/input0", adap->name);
 
-   adap->rc->device_name = adap->device_name;
+   adap->rc->device_name = adap->name;
adap->rc->input_phys = adap->input_phys;
adap->rc->input_id.bustype = BUS_CEC;
adap->rc->input_id.vendor = 0;
diff --git a/include/media/cec.h b/include/media/cec.h
index 9f382f0c2970..73ed28b076ce 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -198,9 +198,7 @@ struct cec_adapter {
u16 phys_addrs[15];
u32 sequence;
 
-   char device_name[32];
char input_phys[32];
-   char input_drv[32];
 };
 
 static inline void *cec_get_drvdata(const struct cec_adapter *adap)
-- 
2.17.1

[PATCH 2/3] media: v4l2-fwnode: cleanup functions that parse endpoints

2018-10-04 Thread Mauro Carvalho Chehab

There is already a typedef for the parse endpoint function.
However, instead of using it, it is redefined at the C file
(and on one of the function headers).

Replace them by the function typedef, in order to cleanup
several related coding style warnings.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 64 ---
 include/media/v4l2-fwnode.h   | 19 
 2 files changed, 37 insertions(+), 46 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 4e518d5fddd8..a7c2487154a4 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -596,12 +596,10 @@ EXPORT_SYMBOL_GPL(v4l2_fwnode_put_link);
 
 static int
 v4l2_async_notifier_fwnode_parse_endpoint(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   struct fwnode_handle *endpoint,
-   unsigned int asd_struct_size,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+ struct v4l2_async_notifier *notifier,
+ struct fwnode_handle *endpoint,
+ unsigned int asd_struct_size,
+ parse_endpoint_func parse_endpoint)
 {
struct v4l2_fwnode_endpoint vep = { .bus_type = 0 };
struct v4l2_async_subdev *asd;
@@ -657,13 +655,12 @@ v4l2_async_notifier_fwnode_parse_endpoint(struct device 
*dev,
 }
 
 static int
-__v4l2_async_notifier_parse_fwnode_endpoints(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   size_t asd_struct_size,
-   unsigned int port, bool has_port,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+__v4l2_async_notifier_parse_fwnode_ep(struct device *dev,
+ struct v4l2_async_notifier *notifier,
+ size_t asd_struct_size,
+ unsigned int port,
+ bool has_port,
+ parse_endpoint_func parse_endpoint)
 {
struct fwnode_handle *fwnode;
int ret = 0;
@@ -708,31 +705,27 @@ __v4l2_async_notifier_parse_fwnode_endpoints(struct 
device *dev,
 
 int
 v4l2_async_notifier_parse_fwnode_endpoints(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   size_t asd_struct_size,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+  struct v4l2_async_notifier *notifier,
+  size_t asd_struct_size,
+  parse_endpoint_func parse_endpoint)
 {
-   return __v4l2_async_notifier_parse_fwnode_endpoints(dev, notifier,
-   asd_struct_size, 0,
-   false,
-   parse_endpoint);
+   return __v4l2_async_notifier_parse_fwnode_ep(dev, notifier,
+asd_struct_size, 0,
+false, parse_endpoint);
 }
 EXPORT_SYMBOL_GPL(v4l2_async_notifier_parse_fwnode_endpoints);
 
 int
 v4l2_async_notifier_parse_fwnode_endpoints_by_port(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   size_t asd_struct_size, unsigned int port,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+  struct v4l2_async_notifier 
*notifier,
+  size_t asd_struct_size,
+  unsigned int port,
+  parse_endpoint_func 
parse_endpoint)
 {
-   return __v4l2_async_notifier_parse_fwnode_endpoints(dev, notifier,
-   asd_struct_size,
-   port, true,
-   parse_endpoint);
+   return __v4l2_async_notifier_parse_fwnode_ep(dev, notifier,
+

[PATCH 1/3] media: v4l2-core: cleanup coding style at V4L2 async/fwnode

2018-10-04 Thread Mauro Carvalho Chehab

There are several coding style issues at those definitions,
and the previous patchset added even more.

Address the trivial ones by first calling:

./scripts/checkpatch.pl --strict --fix-inline 
include/media/v4l2-async.h include/media/v4l2-fwnode.h 
include/media/v4l2-mediabus.h drivers/media/v4l2-core/v4l2-async.c 
drivers/media/v4l2-core/v4l2-fwnode.c

and then manually adjusting the style where needed.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-async.c  |  45 ---
 drivers/media/v4l2-core/v4l2-fwnode.c | 185 +++---
 include/media/v4l2-async.h|  12 +-
 include/media/v4l2-fwnode.h   |  46 ---
 include/media/v4l2-mediabus.h |  32 +++--
 5 files changed, 179 insertions(+), 141 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 70adbd9a01a2..6fdda745a1da 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -57,6 +57,7 @@ static bool match_i2c(struct v4l2_subdev *sd, struct 
v4l2_async_subdev *asd)
 {
 #if IS_ENABLED(CONFIG_I2C)
struct i2c_client *client = i2c_verify_client(sd->dev);
+
return client &&
asd->match.i2c.adapter_id == client->adapter->nr &&
asd->match.i2c.address == client->addr;
@@ -89,10 +90,11 @@ static LIST_HEAD(subdev_list);
 static LIST_HEAD(notifier_list);
 static DEFINE_MUTEX(list_lock);
 
-static struct v4l2_async_subdev *v4l2_async_find_match(
-   struct v4l2_async_notifier *notifier, struct v4l2_subdev *sd)
+static struct
+v4l2_async_subdev *v4l2_async_find_match(struct v4l2_async_notifier *notifier,
+struct v4l2_subdev *sd)
 {
-   bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
+   bool (*match)(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd);
struct v4l2_async_subdev *asd;
 
list_for_each_entry(asd, ¬ifier->waiting, list) {
@@ -150,8 +152,8 @@ static bool asd_equal(struct v4l2_async_subdev *asd_x,
 }
 
 /* Find the sub-device notifier registered by a sub-device driver. */
-static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
-   struct v4l2_subdev *sd)
+static struct v4l2_async_notifier *
+v4l2_async_find_subdev_notifier(struct v4l2_subdev *sd)
 {
struct v4l2_async_notifier *n;
 
@@ -163,8 +165,8 @@ static struct v4l2_async_notifier 
*v4l2_async_find_subdev_notifier(
 }
 
 /* Get v4l2_device related to the notifier if one can be found. */
-static struct v4l2_device *v4l2_async_notifier_find_v4l2_dev(
-   struct v4l2_async_notifier *notifier)
+static struct v4l2_device *
+v4l2_async_notifier_find_v4l2_dev(struct v4l2_async_notifier *notifier)
 {
while (notifier->parent)
notifier = notifier->parent;
@@ -175,8 +177,8 @@ static struct v4l2_device 
*v4l2_async_notifier_find_v4l2_dev(
 /*
  * Return true if all child sub-device notifiers are complete, false otherwise.
  */
-static bool v4l2_async_notifier_can_complete(
-   struct v4l2_async_notifier *notifier)
+static bool
+v4l2_async_notifier_can_complete(struct v4l2_async_notifier *notifier)
 {
struct v4l2_subdev *sd;
 
@@ -199,8 +201,8 @@ static bool v4l2_async_notifier_can_complete(
  * Complete the master notifier if possible. This is done when all async
  * sub-devices have been bound; v4l2_device is also available then.
  */
-static int v4l2_async_notifier_try_complete(
-   struct v4l2_async_notifier *notifier)
+static int
+v4l2_async_notifier_try_complete(struct v4l2_async_notifier *notifier)
 {
/* Quick check whether there are still more sub-devices here. */
if (!list_empty(¬ifier->waiting))
@@ -221,8 +223,8 @@ static int v4l2_async_notifier_try_complete(
return v4l2_async_notifier_call_complete(notifier);
 }
 
-static int v4l2_async_notifier_try_all_subdevs(
-   struct v4l2_async_notifier *notifier);
+static int
+v4l2_async_notifier_try_all_subdevs(struct v4l2_async_notifier *notifier);
 
 static int v4l2_async_match_notify(struct v4l2_async_notifier *notifier,
   struct v4l2_device *v4l2_dev,
@@ -268,8 +270,8 @@ static int v4l2_async_match_notify(struct 
v4l2_async_notifier *notifier,
 }
 
 /* Test all async sub-devices in a notifier for a match. */
-static int v4l2_async_notifier_try_all_subdevs(
-   struct v4l2_async_notifier *notifier)
+static int
+v4l2_async_notifier_try_all_subdevs(struct v4l2_async_notifier *notifier)
 {
struct v4l2_device *v4l2_dev =
v4l2_async_notifier_find_v4l2_dev(notifier);
@@ -306,14 +308,17 @@ static int v4l2_async_notifier_try_all_subdevs(
 static void v4l2_async_cleanup(struct v4l2_subdev *sd)
 {
v4l2_device_unregister_subdev(sd);
-   /* Subdevice driver will reprobe and put the subdev back onto the list 
*/
+   /*
+* Subdevice driver will reprobe and put the subdev back
+* onto t

[PATCH 3/3] media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props() call

2018-10-04 Thread Mauro Carvalho Chehab

The v4l2_fwnode_reference_parse_int_props() has a big name, causing
it to cause coding style warnings. Also, it depends on a const
struct embedded indide a function.

Rearrange the logic in order to move the struct declaration out
of such function and use it inside this function.

That cleans up some coding style issues.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index a7c2487154a4..e0cd119d6f5c 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -1006,6 +1006,12 @@ v4l2_fwnode_reference_get_int_prop(struct fwnode_handle 
*fwnode,
return fwnode;
 }
 
+struct v4l2_fwnode_int_props {
+   const char *name;
+   const char * const *props;
+   unsigned int nprops;
+};
+
 /*
  * v4l2_fwnode_reference_parse_int_props - parse references for async
  *sub-devices
@@ -1032,13 +1038,14 @@ v4l2_fwnode_reference_get_int_prop(struct fwnode_handle 
*fwnode,
 static int
 v4l2_fwnode_reference_parse_int_props(struct device *dev,
  struct v4l2_async_notifier *notifier,
- const char *prop,
- const char * const *props,
- unsigned int nprops)
+ const struct v4l2_fwnode_int_props *p)
 {
struct fwnode_handle *fwnode;
unsigned int index;
int ret;
+   const char *prop = p->name;
+   const char * const *props = p->props;
+   unsigned int nprops = p->nprops;
 
index = 0;
do {
@@ -1092,16 +1099,12 @@ v4l2_fwnode_reference_parse_int_props(struct device 
*dev,
 int v4l2_async_notifier_parse_fwnode_sensor_common(struct device *dev,
   struct v4l2_async_notifier 
*notifier)
 {
+   unsigned int i;
static const char * const led_props[] = { "led" };
-   static const struct {
-   const char *name;
-   const char * const *props;
-   unsigned int nprops;
-   } props[] = {
+   static const struct v4l2_fwnode_int_props props[] = {
{ "flash-leds", led_props, ARRAY_SIZE(led_props) },
{ "lens-focus", NULL, 0 },
};
-   unsigned int i;
 
for (i = 0; i < ARRAY_SIZE(props); i++) {
int ret;
@@ -1109,9 +1112,7 @@ int v4l2_async_notifier_parse_fwnode_sensor_common(struct 
device *dev,
if (props[i].props && is_acpi_node(dev_fwnode(dev)))
ret = v4l2_fwnode_reference_parse_int_props(dev,
notifier,
-   
props[i].name,
-   
props[i].props,
-   
props[i].nprops);
+   &props[i]);
else
ret = v4l2_fwnode_reference_parse(dev, notifier,
  props[i].name);
-- 
2.17.1

[PATCH 0/3] Coding style cleanups after the fwnode patchset

2018-10-04 Thread Mauro Carvalho Chehab

The fwnode patchset added a several new warnings, as identified by
checkpatch.pl --strict.

Those are at the core stuff, and makes harder to review patches there.

The most irritating stuff there are functions like:

some_very_long_function_that_has_a_very_comprehensive_name(
...);

Functions ending with a "(" without arguments doesn't follow the
right coding style, and it is an heritage of the usage of "indent".

Ok, it sounds that the patches were actually trying to follow an existing
coding style inside it.

As we're about to close the media merge window, and the fwnode patches
already changed a lot of code there, before that becomes an habit to
follow its weird style, let's fix it.

After this series, all we have is the lack of SPDX inside the sources,
and some long lines (with is inevitable without renaming those kAPI
functions).

Btw, I was tempted to rename them, renaming functions like:

v4l2_async_notifier_parse_fwnode_endpoints_by_port

to something like:
v4l2_async_parse_fwnode_ep_by_port

or even:
v4l2_parse_fwnode_ep_by_port

with is probably good enough, but, as this is part of the kAPI, I
opted to keep it as-is - for now.

Mauro Carvalho Chehab (3):
  media: v4l2-core: cleanup coding style at V4L2 async/fwnode
  media: v4l2-fwnode: cleanup functions that parse endpoints
  media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props()
call

 drivers/media/v4l2-core/v4l2-async.c  |  45 +++---
 drivers/media/v4l2-core/v4l2-fwnode.c | 190 ++
 include/media/v4l2-async.h|  12 +-
 include/media/v4l2-fwnode.h   |  45 +++---
 include/media/v4l2-mediabus.h |  32 +++--
 5 files changed, 177 insertions(+), 147 deletions(-)

-- 
2.17.1

Your images 22

2018-10-04 Thread Joanna


Have photos for cutting out or retouching?

We are one image team and we do editing for your the e-commerce photos,
industry photos or portrait photo.

If you need test editing then let me know.
Waiting for your reply and the photo work.

Thanks,
Joanna

Your images 22

2018-10-04 Thread Joanna


Have photos for cutting out or retouching?

We are one image team and we do editing for your the e-commerce photos,
industry photos or portrait photo.

If you need test editing then let me know.
Waiting for your reply and the photo work.

Thanks,
Joanna

Your images 24

2018-10-04 Thread Joanna


Have photos for cutting out or retouching?

We are one image team and we do editing for your the e-commerce photos,
industry photos or portrait photo.

If you need test editing then let me know.
Waiting for your reply and the photo work.

Thanks,
Joanna

Re: [PATCH v4 00/11] imx-media: Fixes for interlaced capture

2018-10-04 Thread Steve Longerbeam





On 10/04/2018 12:34 PM, Hans Verkuil wrote:

On 10/04/2018 08:53 PM, Steve Longerbeam wrote:

A set of patches that fixes some bugs with capturing from an
interlaced source, and incompatibilites between IDMAC interlace
interweaving and 4:2:0 data write reduction.

History:
v4:
- rebased to latest media-tree master branch.
- Make patch author and SoB email addresses the same.

v3:
- add support for/fix interweaved scan with YUV planar output.
- fix bug in 4:2:0 U/V offset macros.
- add patch that generalizes behavior of field swap in
   ipu_csi_init_interface().
- add support for interweaved scan with field order swap.
   Suggested by Philipp Zabel.
- in v2, inteweave scan was determined using field types of
   CSI (and PRPENCVF) at the sink and source pads. In v3, this
   has been moved one hop downstream: interweave is now determined
   using field type at source pad, and field type selected at
   capture interface. Suggested by Philipp.
- make sure to double CSI crop target height when input field
   type in alternate.
- more updates to media driver doc to reflect above.

v2:
- update media driver doc.
- enable idmac interweave only if input field is sequential/alternate,
   and output field is 'interlaced*'.
- move field try logic out of *try_fmt and into separate function.
- fix bug with resetting crop/compose rectangles.
- add a patch that fixes a field order bug in VDIC indirect mode.
- remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro
   Suggested-by: Nicolas Dufresne .
- add macro V4L2_FIELD_IS_INTERLACED().


Steve Longerbeam (11):
   media: videodev2.h: Add more field helper macros
   gpu: ipu-csi: Swap fields according to input/output field types
   gpu: ipu-v3: Add planar support to interlaced scan

What should I do with these patches? Do they go through us? Or the drm
subsystem (or whoever handles this)?

If it goes through another subsystem, then I can Ack them.


Hi Hans, sorry you are right. Philipp Zabel needs to merge these
to his imx-drm/fixes tree. Then we need to wait for them to filter
over to media-tree. Same old slow process, I wish this were faster,
but that is the drawback of changes that span subsystems.

I will submit the above patches to dri-devel ML. And resubmit this
series once they hit media-tree.

Steve





   media: imx: Fix field negotiation
   media: imx-csi: Double crop height for alternate fields at sink
   media: imx: interweave and odd-chroma-row skip are incompatible
   media: imx-csi: Allow skipping odd chroma rows for YVU420
   media: imx: vdic: rely on VDIC for correct field order
   media: imx-csi: Move crop/compose reset after filling default mbus
 fields
   media: imx: Allow interweave with top/bottom lines swapped
   media: imx.rst: Update doc to reflect fixes to interlaced capture

  Documentation/media/v4l-drivers/imx.rst   |  93 ++
  drivers/gpu/ipu-v3/ipu-cpmem.c|  26 ++-
  drivers/gpu/ipu-v3/ipu-csi.c  | 132 ++
  drivers/staging/media/imx/imx-ic-prpencvf.c   |  48 +++--
  drivers/staging/media/imx/imx-media-capture.c |  14 ++
  drivers/staging/media/imx/imx-media-csi.c | 166 --
  drivers/staging/media/imx/imx-media-vdic.c|  12 +-
  include/uapi/linux/videodev2.h|   7 +
  include/video/imx-ipu-v3.h|   6 +-
  9 files changed, 359 insertions(+), 145 deletions(-)

Re: [PATCH 2/2] media: rc: self test for IR encoders and decoders

2018-10-04 Thread Shuah Khan

Hi Sean,

Thanks for the patch. I just happened to see this when Mauro sent it to me.
Doesn't look like linux-ksefltest and I weren't on the patch?

On 07/17/2018 03:33 PM, Sean Young (by way of Mauro Carvalho Chehab 
) wrote:
> ir-loopback can transmit IR on one rc device and check the correct
> scancode and protocol is decoded on a different rc device. This can be
> used to check IR transmission between two rc devices. Using rc-loopback,
> we use it to check the IR encoders and decoders themselves.
> 
> Signed-off-by: Sean Young 
> ---
>  tools/testing/selftests/Makefile  |   1 +
>  tools/testing/selftests/ir/.gitignore |   1 +
>  tools/testing/selftests/ir/Makefile   |  19 ++
>  tools/testing/selftests/ir/config |  12 ++
>  tools/testing/selftests/ir/ir-loopback.c  | 209 ++
>  tools/testing/selftests/ir/ir-loopback.sh |  28 +++
>  6 files changed, 270 insertions(+)
>  create mode 100644 tools/testing/selftests/ir/.gitignore
>  create mode 100644 tools/testing/selftests/ir/Makefile
>  create mode 100644 tools/testing/selftests/ir/config
>  create mode 100644 tools/testing/selftests/ir/ir-loopback.c
>  create mode 100755 tools/testing/selftests/ir/ir-loopback.sh

Why not add to the existing media directory? ../selftests/media_tests?

> 
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index f1fe492c8e17..995034ea5546 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -15,6 +15,7 @@ TARGETS += futex
>  TARGETS += gpio
>  TARGETS += intel_pstate
>  TARGETS += ipc
> +TARGETS += ir

Does this test depend on any hardware being present in the system?

>  TARGETS += kcmp
>  TARGETS += kvm
>  TARGETS += lib
> diff --git a/tools/testing/selftests/ir/.gitignore 
> b/tools/testing/selftests/ir/.gitignore
> new file mode 100644
> index ..87bf2989b678
> --- /dev/null
> +++ b/tools/testing/selftests/ir/.gitignore
> @@ -0,0 +1 @@
> +ir-loopback
> diff --git a/tools/testing/selftests/ir/Makefile 
> b/tools/testing/selftests/ir/Makefile
> new file mode 100644
> index ..501b464e56b5
> --- /dev/null
> +++ b/tools/testing/selftests/ir/Makefile
> @@ -0,0 +1,19 @@
> +# SPDX-License-Identifier: GPL-2.0
> +uname_M := $(shell uname -m 2>/dev/null || echo not)
> +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
> +ifeq ($(ARCH),i386)
> +ARCH := x86
> + CFLAGS := -DCONFIG_X86_32 -D__i386__
> +endif
> +ifeq ($(ARCH),x86_64)
> + ARCH := x86
> + CFLAGS := -DCONFIG_X86_64 -D__x86_64__
> +endif
> +
> +CFLAGS += -I../../../../usr/include/
> +
> +TEST_PROGS := ir-loopback.sh
> +
> +TEST_GEN_PROGS := ir-loopback

Looks like ir-loopback get run from ir-loopback.sh. TEST_GEN_PROGS_EXTENDED
is the right variable to use in this case.

TEST_GEN_PROGS_EXTENDED := ir-loopback

> +
> +include ../lib.mk
> diff --git a/tools/testing/selftests/ir/config 
> b/tools/testing/selftests/ir/config
> new file mode 100644
> index ..78e041e9319e
> --- /dev/null
> +++ b/tools/testing/selftests/ir/config
> @@ -0,0 +1,12 @@
> +CONFIG_RC_CORE=y
> +CONFIG_RC_LOOPBACK=y
> +CONFIG_IR_NEC_DECODER=m
> +CONFIG_IR_RC5_DECODER=m
> +CONFIG_IR_RC6_DECODER=m
> +CONFIG_IR_JVC_DECODER=m
> +CONFIG_IR_SONY_DECODER=m
> +CONFIG_IR_SANYO_DECODER=m
> +CONFIG_IR_SHARP_DECODER=m
> +CONFIG_IR_MCE_KBD_DECODER=m
> +CONFIG_IR_XMP_DECODER=m
> +CONFIG_IR_IMON_DECODER=m
> diff --git a/tools/testing/selftests/ir/ir-loopback.c 
> b/tools/testing/selftests/ir/ir-loopback.c
> new file mode 100644
> index ..95b6f0f2f1f5
> --- /dev/null
> +++ b/tools/testing/selftests/ir/ir-loopback.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// test ir decoder
> +//
> +// Copyright (C) 2018 Sean Young 
> +
> +// When sending LIRC_MODE_SCANCODE, the IR will be encoded. rc-loopback
> +// will send this IR to the receiver side, where we try to read the decoded
> +// IR. Decoding happens in a separate kernel thread, so we will need to
> +// wait until that is scheduled, hence we use poll to check for read
> +// readiness.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TEST_SCANCODES   10
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +
> +static const struct {
> + enum rc_proto proto;
> + const char *name;
> + unsigned int mask;
> + const char *decoder;
> +} protocols[] = {
> + { RC_PROTO_RC5, "rc-5", 0x1f7f, "rc-5" },
> + { RC_PROTO_RC5X_20, "rc-5x-20", 0x1f7f3f, "rc-5" },
> + { RC_PROTO_RC5_SZ, "rc-5-sz", 0x2fff, "rc-5-sz" },
> + { RC_PROTO_JVC, "jvc", 0x, "jvc" },
> + { RC_PROTO_SONY12, "sony-12", 0x1f007f, "sony" },
> + { RC_PROTO_SONY15, "sony-15", 0xff007f, "sony" },
> + { RC_PROTO_SONY20, "sony-20", 0x1fff7f, "sony" },
> + { RC_PROTO_NEC, "nec", 0x, "nec" },
> + {

[PATCH v2 3/3] rcar-vin: declare which VINs can use a Up Down Scaler (UDS)

2018-10-04 Thread Niklas Söderlund

Add information about which VINs on which SoC have access to a UDS
scaler.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 01e418c2d4c6792e..337ae8bbe1e0b14c 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -919,12 +919,21 @@ static const struct rvin_group_route 
rcar_info_r8a7795_routes[] = {
{ /* Sentinel */ }
 };
 
+static const struct rvin_group_scaler rcar_info_h3_m3w_m3n_scalers[] = {
+   { .vin = 0, .companion = 1 },
+   { .vin = 1, .companion = 0 },
+   { .vin = 4, .companion = 5 },
+   { .vin = 5, .companion = 4 },
+   { /* Sentinel */ }
+};
+
 static const struct rvin_info rcar_info_r8a7795 = {
.model = RCAR_GEN3,
.use_mc = true,
.max_width = 4096,
.max_height = 4096,
.routes = rcar_info_r8a7795_routes,
+   .scalers = rcar_info_h3_m3w_m3n_scalers,
 };
 
 static const struct rvin_group_route rcar_info_r8a7795es1_routes[] = {
@@ -979,6 +988,7 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
.max_width = 4096,
.max_height = 4096,
.routes = rcar_info_r8a7795es1_routes,
+   .scalers = rcar_info_h3_m3w_m3n_scalers,
 };
 
 static const struct rvin_group_route rcar_info_r8a7796_routes[] = {
@@ -1019,6 +1029,7 @@ static const struct rvin_info rcar_info_r8a7796 = {
.max_width = 4096,
.max_height = 4096,
.routes = rcar_info_r8a7796_routes,
+   .scalers = rcar_info_h3_m3w_m3n_scalers,
 };
 
 static const struct rvin_group_route rcar_info_r8a77965_routes[] = {
@@ -1063,6 +1074,7 @@ static const struct rvin_info rcar_info_r8a77965 = {
.max_width = 4096,
.max_height = 4096,
.routes = rcar_info_r8a77965_routes,
+   .scalers = rcar_info_h3_m3w_m3n_scalers,
 };
 
 static const struct rvin_group_route rcar_info_r8a77970_routes[] = {
@@ -1088,12 +1100,18 @@ static const struct rvin_group_route 
rcar_info_r8a77995_routes[] = {
{ /* Sentinel */ }
 };
 
+static const struct rvin_group_scaler rcar_info_r8a77995_scalers[] = {
+   { .vin = 4, .companion = -1 },
+   { /* Sentinel */ }
+};
+
 static const struct rvin_info rcar_info_r8a77995 = {
.model = RCAR_GEN3,
.use_mc = true,
.max_width = 4096,
.max_height = 4096,
.routes = rcar_info_r8a77995_routes,
+   .scalers = rcar_info_r8a77995_scalers,
 };
 
 static const struct of_device_id rvin_of_id_table[] = {
-- 
2.19.0

Re: [PATCH] MAINTAINERS: Remove stale file entry for the Atmel ISI driver

2018-10-04 Thread Laurent Pinchart

Hi Mauro,

On Thursday, 4 October 2018 21:45:05 EEST Mauro Carvalho Chehab wrote:
> Em Tue, 2 Oct 2018 08:35:47 +0200 Ludovic Desroches escreveu:
> > On Mon, Oct 01, 2018 at 01:51:01PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Sun, 30 Sep 2018 02:40:35 -0700 Joe Perches escreveu:
> > > > On Sun, 2018-09-30 at 06:30 -0300, Mauro Carvalho Chehab wrote:
> > > > > Em Sun, 30 Sep 2018 09:54:48 +0300 Laurent Pinchart escreveu:
> > > > > > include/media/atmel-isi got removed three years ago without the
> > > > > > MAINTAINERS file being updated. Remove the stale entry.
> > > > > > 
> > > > > > Fixes: 40a78f36fc92 ("[media] v4l: atmel-isi: Remove support for
> > > > > > platform data") Reported-by: Joe Perches 
> > > > > > Signed-off-by: Laurent Pinchart
> > > > > > 
> > > > > > ---
> > > > > > 
> > > > > >  MAINTAINERS | 1 -
> > > > > >  1 file changed, 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > 
> > > > []
> > > > 
> > > > > > @@ -2497,7 +2497,6 @@ M:Ludovic Desroches
> > > > > > > > > > > 
> > > > > >  L: linux-media@vger.kernel.org
> > > > > >  S: Supported
> > > > > >  F: drivers/media/platform/atmel/atmel-isi.c
> > > > > > 
> > > > > > -F: include/media/atmel-isi.h
> > > > > 
> > > > > I guess the right fix would be to replace it by:
> > > > > 
> > > > > F: drivers/media/platform/atmel/atmel-isi.h
> > > > 
> > > > Or replace both F entries with:
> > > > 
> > > > F:  drivers/media/platform/atmel/atmel-isi.*
> > > > 
> > > > Or combine the 2 MICROCHIP sections into one
> > > > 
> > > > MICROCHIP ISC DRIVER
> > > > M:  Eugen Hristev 
> > > > L:  linux-media@vger.kernel.org
> > > > S:  Supported
> > > > F:  drivers/media/platform/atmel/atmel-isc.c
> > > > F:  drivers/media/platform/atmel/atmel-isc-regs.h
> > > > F:  devicetree/bindings/media/atmel-isc.txt
> > > > 
> > > > MICROCHIP ISI DRIVER
> > > > M:  Eugen Hristev 
> > > > L:  linux-media@vger.kernel.org
> > > > S:  Supported
> > > > F:  drivers/media/platform/atmel/atmel-isi.c
> > > > F:  include/media/atmel-isi.h
> > > > 
> > > > and maybe use something like:
> > > > 
> > > > MICROCHIP MEDIA DRIVERS
> > > > M:  Eugen Hristev 
> > > > L:
> > > > linux-media@vger.kernel.org
> > > > S:  Supported
> > > > F:  drivers/media/platform/atmel/
> > > > F:  devicetree/bindings/media/atmel-isc.txt
> > > 
> > > Yeah, combining both of them seems a good alternative to me.
> > > 
> > > Eugen/Ludovic/Josh,
> > > 
> > > Comments?
> > 
> > I have no strong opinion about it. The devices are different but usually
> > there is one person per topic so combining them makes sense.
> 
> Hmm... At media tree, currently, MAINTAINERS entry is different:
> 
> MICROCHIP / ATMEL ISC DRIVER
> M:Songjun Wu 
> L:linux-media@vger.kernel.org
> S:  Supported
> F:  drivers/media/platform/atmel/atmel-isc.c
> F:  drivers/media/platform/atmel/atmel-isc-regs.h
> F:devicetree/bindings/media/atmel-isc.txt
> 
> ATMEL ISI DRIVER
> M:Ludovic Desroches 
> L:linux-media@vger.kernel.org
> S:  Supported
> F:  drivers/media/platform/atmel/atmel-isi.c
> F:  include/media/atmel-isi.h
> 
> Maybe some patch upstream did some recent changes on it via another
> tree.
> 
> So, in order to avoid conflicts upstream, for now I would just correct
> the location for the ISI file.
> 
> After the merge window, we may revisit and join both entries,
> if the maintainers are the same.

Fine with me.

> -
> 
> MAINTAINERS: fix location for atmel-isi.h file
> 
> The location of this file got changed by changeset 40a78f36fc92
> ("[media] v4l: atmel-isi: Remove support for platform data"), but
> MAINTAINERS was not updated accordingly.
> 
> Fixes: 40a78f36fc92 ("[media] v4l: atmel-isi: Remove support for platform
> data") Reported-by: Joe Perches 
> Signed-off-by: Mauro Carvalho Chehab 

I don't care about patch count statistics, but the usual practice is to retain 
the authorship of the original submitter. This is especially important with 
patches submitted by new or less frequent contributors, as recognition of 
their work is sometimes the only thing they get (and it doesn't hurt with 
regular contributors either).

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9989925f658d..385ebe9ca0a2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2496,8 +2496,7 @@ ATMEL ISI DRIVER
>  M:   Ludovic Desroches 
>  L:   linux-media@vger.kernel.org
>  S:   Supported
> -F:   drivers/media/platform/atmel/atmel-isi.c
> -F:   include/media/atmel-isi.h
> +F:   drivers/media/platform/atmel/atmel-isi.*
> 
>  ATMEL LCDFB DRIVER
>  M:   Nicolas Ferre 

-- 
Regards,

Laurent Pinchart

s5p_mfc and H.264 frame cropping question

2018-10-04 Thread Hans Verkuil

Hi all,

I'm looking at removing the last users of vidioc_g/s_crop from the driver and
I came across vidioc_g_crop in drivers/media/platform/s5p-mfc/s5p_mfc_dec.c.

What this really does AFAICS is return the H.264 frame crop as read from the
bitstream. This has nothing to do with regular cropping/composing but it might 
be
something that could be implemented as a new selection target.

I'm not really sure what to do with the existing code since it is an abuse of
the crop API, but I guess the first step is to decide how this should be handled
properly.

Are there other decoders that can retrieve this information? Should this be
mentioned in the stateful codec API?

Regards,

Hans

Re: [PATCH v4 00/11] imx-media: Fixes for interlaced capture

2018-10-04 Thread Hans Verkuil

On 10/04/2018 08:53 PM, Steve Longerbeam wrote:
> A set of patches that fixes some bugs with capturing from an
> interlaced source, and incompatibilites between IDMAC interlace
> interweaving and 4:2:0 data write reduction.
> 
> History:
> v4:
> - rebased to latest media-tree master branch.
> - Make patch author and SoB email addresses the same.
> 
> v3:
> - add support for/fix interweaved scan with YUV planar output.
> - fix bug in 4:2:0 U/V offset macros.
> - add patch that generalizes behavior of field swap in
>   ipu_csi_init_interface().
> - add support for interweaved scan with field order swap.
>   Suggested by Philipp Zabel.
> - in v2, inteweave scan was determined using field types of
>   CSI (and PRPENCVF) at the sink and source pads. In v3, this
>   has been moved one hop downstream: interweave is now determined
>   using field type at source pad, and field type selected at
>   capture interface. Suggested by Philipp.
> - make sure to double CSI crop target height when input field
>   type in alternate.
> - more updates to media driver doc to reflect above.
> 
> v2:
> - update media driver doc.
> - enable idmac interweave only if input field is sequential/alternate,
>   and output field is 'interlaced*'.
> - move field try logic out of *try_fmt and into separate function.
> - fix bug with resetting crop/compose rectangles.
> - add a patch that fixes a field order bug in VDIC indirect mode.
> - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro
>   Suggested-by: Nicolas Dufresne .
> - add macro V4L2_FIELD_IS_INTERLACED().
> 
> 
> Steve Longerbeam (11):
>   media: videodev2.h: Add more field helper macros
>   gpu: ipu-csi: Swap fields according to input/output field types
>   gpu: ipu-v3: Add planar support to interlaced scan

What should I do with these patches? Do they go through us? Or the drm
subsystem (or whoever handles this)?

If it goes through another subsystem, then I can Ack them.

Regards,

Hans

>   media: imx: Fix field negotiation
>   media: imx-csi: Double crop height for alternate fields at sink
>   media: imx: interweave and odd-chroma-row skip are incompatible
>   media: imx-csi: Allow skipping odd chroma rows for YVU420
>   media: imx: vdic: rely on VDIC for correct field order
>   media: imx-csi: Move crop/compose reset after filling default mbus
> fields
>   media: imx: Allow interweave with top/bottom lines swapped
>   media: imx.rst: Update doc to reflect fixes to interlaced capture
> 
>  Documentation/media/v4l-drivers/imx.rst   |  93 ++
>  drivers/gpu/ipu-v3/ipu-cpmem.c|  26 ++-
>  drivers/gpu/ipu-v3/ipu-csi.c  | 132 ++
>  drivers/staging/media/imx/imx-ic-prpencvf.c   |  48 +++--
>  drivers/staging/media/imx/imx-media-capture.c |  14 ++
>  drivers/staging/media/imx/imx-media-csi.c | 166 --
>  drivers/staging/media/imx/imx-media-vdic.c|  12 +-
>  include/uapi/linux/videodev2.h|   7 +
>  include/video/imx-ipu-v3.h|   6 +-
>  9 files changed, 359 insertions(+), 145 deletions(-)
>

[PATCH v4 00/11] imx-media: Fixes for interlaced capture

2018-10-04 Thread Steve Longerbeam

A set of patches that fixes some bugs with capturing from an
interlaced source, and incompatibilites between IDMAC interlace
interweaving and 4:2:0 data write reduction.

History:
v4:
- rebased to latest media-tree master branch.
- Make patch author and SoB email addresses the same.

v3:
- add support for/fix interweaved scan with YUV planar output.
- fix bug in 4:2:0 U/V offset macros.
- add patch that generalizes behavior of field swap in
  ipu_csi_init_interface().
- add support for interweaved scan with field order swap.
  Suggested by Philipp Zabel.
- in v2, inteweave scan was determined using field types of
  CSI (and PRPENCVF) at the sink and source pads. In v3, this
  has been moved one hop downstream: interweave is now determined
  using field type at source pad, and field type selected at
  capture interface. Suggested by Philipp.
- make sure to double CSI crop target height when input field
  type in alternate.
- more updates to media driver doc to reflect above.

v2:
- update media driver doc.
- enable idmac interweave only if input field is sequential/alternate,
  and output field is 'interlaced*'.
- move field try logic out of *try_fmt and into separate function.
- fix bug with resetting crop/compose rectangles.
- add a patch that fixes a field order bug in VDIC indirect mode.
- remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro
  Suggested-by: Nicolas Dufresne .
- add macro V4L2_FIELD_IS_INTERLACED().


Steve Longerbeam (11):
  media: videodev2.h: Add more field helper macros
  gpu: ipu-csi: Swap fields according to input/output field types
  gpu: ipu-v3: Add planar support to interlaced scan
  media: imx: Fix field negotiation
  media: imx-csi: Double crop height for alternate fields at sink
  media: imx: interweave and odd-chroma-row skip are incompatible
  media: imx-csi: Allow skipping odd chroma rows for YVU420
  media: imx: vdic: rely on VDIC for correct field order
  media: imx-csi: Move crop/compose reset after filling default mbus
fields
  media: imx: Allow interweave with top/bottom lines swapped
  media: imx.rst: Update doc to reflect fixes to interlaced capture

 Documentation/media/v4l-drivers/imx.rst   |  93 ++
 drivers/gpu/ipu-v3/ipu-cpmem.c|  26 ++-
 drivers/gpu/ipu-v3/ipu-csi.c  | 132 ++
 drivers/staging/media/imx/imx-ic-prpencvf.c   |  48 +++--
 drivers/staging/media/imx/imx-media-capture.c |  14 ++
 drivers/staging/media/imx/imx-media-csi.c | 166 --
 drivers/staging/media/imx/imx-media-vdic.c|  12 +-
 include/uapi/linux/videodev2.h|   7 +
 include/video/imx-ipu-v3.h|   6 +-
 9 files changed, 359 insertions(+), 145 deletions(-)

-- 
2.17.1

Re: [GIT PULL FOR v4.20] Various fixes

2018-10-04 Thread Mauro Carvalho Chehab

Em Mon, 1 Oct 2018 11:56:22 +0200
Hans Verkuil  escreveu:

> The following changes since commit 4158757395b300b6eb308fc20b96d1d231484413:
> 
>   media: davinci: Fix implicit enum conversion warning (2018-09-24 09:43:13 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git tags/tag-v4.20d
> 
> for you to fetch changes up to f7a1170fcc19617647c78262a79abdec7b0a08cd:
> 
>   media: i2c: adv748x: fix typo in comment for TXB CSI-2 transmitter power 
> down (2018-10-01 11:09:09 +0200)
> 
> 
> Tag branch
> 
> 
> Arnd Bergmann (1):
>   media: imx-pxp: include linux/interrupt.h
> 
> Benjamin Gaignard (1):
>   MAINTAINERS: fix reference to STI CEC driver
> 
> Colin Ian King (1):
>   media: zoran: fix spelling mistake "queing" -> "queuing"
> 
> Dan Carpenter (1):
>   VPU: mediatek: don't pass an unused parameter
> 
> Hans Verkuil (1):
>   vidioc-dqevent.rst: clarify V4L2_EVENT_SRC_CH_RESOLUTION
> 
> Hugues Fruchet (1):
>   media: stm32-dcmi: only enable IT frame on JPEG capture
> 
> Jacopo Mondi (4):
>   media: i2c: adv748x: Support probing a single output
>   media: i2c: adv748x: Handle TX[A|B] power management
>   media: i2c: adv748x: Conditionally enable only CSI-2 outputs
>   media: i2c: adv748x: Register only enabled inputs
> 
> Laurent Pinchart (1):
>   MAINTAINERS: Remove stale file entry for the Atmel ISI driver

Dropped this patch, as it is not right: the file was just moved to
a different place. Posted a replacement patch for it at the ML.

Applied the remaining ones.

Regards,
Mauro

Re: [PATCH] MAINTAINERS: Remove stale file entry for the Atmel ISI driver

2018-10-04 Thread Mauro Carvalho Chehab

Em Tue, 2 Oct 2018 08:35:47 +0200
Ludovic Desroches  escreveu:

> On Mon, Oct 01, 2018 at 01:51:01PM -0300, Mauro Carvalho Chehab wrote:
> > Em Sun, 30 Sep 2018 02:40:35 -0700
> > Joe Perches  escreveu:
> >   
> > > On Sun, 2018-09-30 at 06:30 -0300, Mauro Carvalho Chehab wrote:  
> > > > Em Sun, 30 Sep 2018 09:54:48 +0300
> > > > Laurent Pinchart  escreveu:
> > > > 
> > > > > include/media/atmel-isi got removed three years ago without the
> > > > > MAINTAINERS file being updated. Remove the stale entry.
> > > > > 
> > > > > Fixes: 40a78f36fc92 ("[media] v4l: atmel-isi: Remove support for 
> > > > > platform data")
> > > > > Reported-by: Joe Perches 
> > > > > Signed-off-by: Laurent Pinchart 
> > > > > ---
> > > > >  MAINTAINERS | 1 -
> > > > >  1 file changed, 1 deletion(-)
> > > > > 
> > > > > 
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > []  
> > > > > @@ -2497,7 +2497,6 @@ M:  Ludovic Desroches 
> > > > > 
> > > > >  L:   linux-media@vger.kernel.org
> > > > >  S:   Supported
> > > > >  F:   drivers/media/platform/atmel/atmel-isi.c
> > > > > -F:   include/media/atmel-isi.h
> > > > 
> > > > I guess the right fix would be to replace it by:
> > > > 
> > > > F: drivers/media/platform/atmel/atmel-isi.h
> > > 
> > > Or replace both F entries with:
> > > 
> > > F:drivers/media/platform/atmel/atmel-isi.*
> > > 
> > > Or combine the 2 MICROCHIP sections into one
> > > 
> > > MICROCHIP ISC DRIVER
> > > M:Eugen Hristev 
> > > L:linux-media@vger.kernel.org
> > > S:Supported
> > > F:drivers/media/platform/atmel/atmel-isc.c
> > > F:drivers/media/platform/atmel/atmel-isc-regs.h
> > > F:devicetree/bindings/media/atmel-isc.txt
> > > 
> > > MICROCHIP ISI DRIVER
> > > M:Eugen Hristev 
> > > L:linux-media@vger.kernel.org
> > > S:Supported
> > > F:drivers/media/platform/atmel/atmel-isi.c
> > > F:include/media/atmel-isi.h
> > > 
> > > and maybe use something like:
> > > 
> > > MICROCHIP MEDIA DRIVERS
> > > M:Eugen Hristev 
> > > L:
> > > linux-media@vger.kernel.org
> > > S:Supported
> > > F:drivers/media/platform/atmel/
> > > F:devicetree/bindings/media/atmel-isc.txt  
> > 
> > Yeah, combining both of them seems a good alternative to me.
> > 
> > Eugen/Ludovic/Josh,
> > 
> > Comments?  
> 
> I have no strong opinion about it. The devices are different but usually
> there is one person per topic so combining them makes sense.

Hmm... At media tree, currently, MAINTAINERS entry is different:

MICROCHIP / ATMEL ISC DRIVER
M:  Songjun Wu 
L:  linux-media@vger.kernel.org
S:  Supported
F:  drivers/media/platform/atmel/atmel-isc.c
F:  drivers/media/platform/atmel/atmel-isc-regs.h
F:  devicetree/bindings/media/atmel-isc.txt

ATMEL ISI DRIVER
M:  Ludovic Desroches 
L:  linux-media@vger.kernel.org
S:  Supported
F:  drivers/media/platform/atmel/atmel-isi.c
F:  include/media/atmel-isi.h

Maybe some patch upstream did some recent changes on it via another
tree.

So, in order to avoid conflicts upstream, for now I would just correct
the location for the ISI file.

After the merge window, we may revisit and join both entries, 
if the maintainers are the same.

Regards,
Mauro

-

MAINTAINERS: fix location for atmel-isi.h file

The location of this file got changed by changeset 40a78f36fc92
("[media] v4l: atmel-isi: Remove support for platform data"), but
MAINTAINERS was not updated accordingly.

Fixes: 40a78f36fc92 ("[media] v4l: atmel-isi: Remove support for platform data")
Reported-by: Joe Perches 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/MAINTAINERS b/MAINTAINERS
index 9989925f658d..385ebe9ca0a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2496,8 +2496,7 @@ ATMEL ISI DRIVER
 M: Ludovic Desroches 
 L: linux-media@vger.kernel.org
 S: Supported
-F: drivers/media/platform/atmel/atmel-isi.c
-F: include/media/atmel-isi.h
+F: drivers/media/platform/atmel/atmel-isi.*
 
 ATMEL LCDFB DRIVER
 M: Nicolas Ferre

Re: [PATCH v3 00/14] imx-media: Fixes for interlaced capture

2018-10-04 Thread Steve Longerbeam





On 10/04/2018 06:41 AM, Hans Verkuil wrote:

On 10/04/18 01:21, Steve Longerbeam wrote:

Hi Hans,


On 10/01/2018 03:07 AM, Hans Verkuil wrote:

Hi Steve,

On 08/01/2018 09:12 PM, Steve Longerbeam wrote:

A set of patches that fixes some bugs with capturing from an
interlaced source, and incompatibilites between IDMAC interlace
interweaving and 4:2:0 data write reduction.

I reviewed this series and it looks fine to me.

Cool.


It appears that the ipu* patches are already merged, so can you rebase and
repost?

Done. There are still two ipu* patches that still need a merge:

gpu: ipu-csi: Swap fields according to input/output field types
gpu: ipu-v3: Add planar support to interlaced scan

so those will still be included in the v4 submission.


I would also like to see the 'v4l2-compliance -f' for an interlaced source,
if at all possible.

Sure, I've run 'v4l2-compliance -f' on two configured pipelines: unprocessed
capture (no scaling, CSC, rotation using ipu), and a VDIC de-interlace
pipeline.

I have the text output, the output is huge but here is the abbreviated
results:

Unprocessed pipeline:

root@mx6q:/home/fu# v4l2-compliance -d4 -f
v4l2-compliance SHA   : 2d35de61ac90b030fe15439809b807014e9751fe

test VIDIOC_G/S/ENUMINPUT: FAIL

test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL

This looks like something that should work. Not relevant for this patch
series, but something you should look into.


Yes, I've been meaning to implement (UN)SUBSCRIBE_EVENT/DQEVENT
at the capture interface. I'll send a patch soon.






Total: 715, Succeeded: 713, Failed: 2, Warnings: 0


VDIC de-interlace pipeline:

root@mx6q:/home/fu# v4l2-compliance -d1 -f
v4l2-compliance SHA   : 2d35de61ac90b030fe15439809b807014e9751fe

test VIDIOC_G/S/ENUMINPUT: FAIL

test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL

test VIDIOC_G/S_PARM: FAIL

Same here: this appears to be an actual bug. But also not related to this
patch series.


It's because the capture interface passes vidioc_[gs]_parm down to its
connected source subdevice as [gs]_frame_interval, which in this case
is PRPVF, which just accepts whatever frame interval is requested. Not
sure why v4l2-compliance reports an error, but perhaps [gs]_frame_interval
should be chained, until it reaches a subdevice that actually cares about
frame intervals (in this case CSI and VDIC), similar to how [gs]_stream is
chained. Anyway something else to look at later.

Steve

[GIT PULL FOR v4.20] Additional RC fixes

2018-10-04 Thread Sean Young

Hi Mauro,

Here are some additional fixes for v4.20. By enabling the rel/keys bits
when the RC input device is registered, we can re-use the same input
device for imon/mce_kbd protocol mouse movements and keys.

Note that all these patches depend on each other; the second depends on the
first, and the third depends on the first two.

Tested with real imon and mce keyboard.

Thanks,

Sean

The following changes since commit 5f108da55c6a928d0305163731bca2ac94ab233b:

  media: smiapp: Remove unused loop (2018-10-03 11:59:10 -0400)

are available in the Git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.20b

for you to fetch changes up to a810925a2795daa204f1ff2e659e026acc4459b5:

  media: rc: mce_kbd: input events via rc-core's input device (2018-10-04 
15:05:37 +0100)


Sean Young (3):
  media: rc: some events are dropped by userspace
  media: rc: imon: report mouse events using rc-core's input device
  media: rc: mce_kbd: input events via rc-core's input device

 drivers/media/rc/ir-imon-decoder.c| 62 ++--
 drivers/media/rc/ir-mce_kbd-decoder.c | 77 +++
 drivers/media/rc/rc-core-priv.h   |  5 ---
 drivers/media/rc/rc-main.c| 20 -
 4 files changed, 26 insertions(+), 138 deletions(-)

Re: [PATCH v5] media: imx208: Add imx208 camera sensor driver

2018-10-04 Thread Sakari Ailus

Hi Ping-chung,

On Thu, Sep 27, 2018 at 03:19:07AM +, Chen, Ping-chung wrote:
> Hi,
> 
> >-Original Message-
> >From: Yeh, Andy 
> >Sent: Wednesday, September 26, 2018 11:19 PM
> >To: Sakari Ailus ; Chen, Ping-chung 
> >
> 
> >Hi Sakari, PC,
> 
> >sensors that do need >digital gain applied, too --- assuming it'd be 
> >combined with the TRY_EXT_CTRLS rounding flags.
> >>
> >> There might be many kinds of discrete DG formats. For imx208, DG=2^n, 
> >> but for other sensors, DG could be 2*n, 5*n, or other styles. If HAL 
> >> needs to
> >
> >I guess the most common is multiplication and a bit shift (by e.g. 8), e.g.
> >multiplying the value by a 16-bit number with a 8-bit fractional part. 
> >The
> >imx208 apparently lacks the multiplication and only has the bit shift.
> >
> >Usually there's some sort of technical reason for the choice of the 
> >digital gain implementation and therefore I expect at least the vast 
> >majority of the implementations to be either of the two.
> 
> >We shall ensure the expansibility of this architecture to include other kind 
> >of styles in the future. Is this API design architecture-wise ok?
> 
> Indeed. Seems it is hard to cover all rules and HAL needs complex flow to
> judge the DG value. Hi Sakari, could you provide an example that how HAL
> uses the modified interface to set available digital gain?

It'll require more user space code no matter how you'd implement this.

Thinking this again, I don't think you'd be doing harm by resorting to an
integer menu here. It'll take some more time to get a decent API to provide
information on the units etc. to the user space.

> >> cover all cases, kernel will have to update more information to this 
> >> control. Another problem is should HAL take over the SMIA calculation?
> >> If so, kernel will also need to update SMIA parameters to user space 
> >> (or create an addition filed for SMIA in the configuration XML file).
> >
> >The parameters for the analogue gain model should come from the driver, yes.
> >We do not have controls for that purpose but they can (and should) be added.
> >
> 
> >How about still follow PC's proposal to implement in XML? It was in IQ 
> >tuning file before which is in userspace. Even I proposed to PC to study 
> >with ICG SW team whether this info could be retrieved from 3A algorithm.
> 
> Hi Andy, because we has to use total gain instead of AG in 3A for the WA, our 
> tuning data of imx208 will not include SMIA of AG anymore. 
> So HAL has no way to retrieve correct SMIA parameters of AG from 3A.

Ideally the driver would be able to provide enough information here to the
user space to work with it. This needs improvement going forward, but in a
way that is generic enough.

-- 
Kind regards.

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

2018-10-04 Thread Hugues FRUCHET

Hi Maxime,

On 10/04/2018 05:04 PM, Maxime Ripard wrote:
> Hi!
> 
> On Mon, Oct 01, 2018 at 02:12:31PM +, Hugues FRUCHET wrote:
 This is working perfectly fine on my parallel setup and allows me to
 well support VGA@30fps (instead 27) and also support XGA(1024x768)@15fps
 that I never seen working before.
 So at least for the parallel setup, this serie is working fine for all
 the discrete resolutions and framerate exposed by the driver for the 
 moment:
 * QCIF 176x144 15/30fps
 * QVGA 320x240 15/30fps
 * VGA 640x480 15/30fps
 * 480p 720x480 15/30fps
 * XGA 1024x768 15/30fps
 * 720p 1280x720 15/30fps
 * 1080p 1920x1080 15/30fps
 * 5Mp 2592x1944 15fps
>>>
>>> I'm glad this is working for you as well. I guess I'll resubmit these
>>> patches, but this time making sure someone with a CSI setup tests
>>> before merging. I crtainly don't want to repeat the previous disaster.
>>>
>>> Do you have those patches rebased somewhere? I'm not quite sure how to
>>> fix the conflict with the v4l2_find_nearest_size addition.
>>>
 Moreover I'm not clear on relationship between rate and pixel clock
 frequency.
 I've understood that to DVP_PCLK_DIVIDER (0x3824) register
 and VFIFO_CTRL0C (0x460c) affects the effective pixel clock frequency.
 All the resolutions up to 720x576 are forcing a manual value of 2 for
 divider (0x460c=0x22), but including 720p and more, the divider value is
 controlled by "auto-mode" (0x460c=0x20)... from what I measured and
 understood, for those resolutions, the divider must be set to 1 in order
 that your rate computation match the effective pixel clock on output,
 see [2].

 So I wonder if this PCLK divider register should be included
 or not into your rate computation, what do you think ?
>>>
>>> Have you tried change the PCLK divider while in auto-mode? IIRC, I did
>>> that and it was affecting the PCLK rate on my scope, but I wouldn't be
>>> definitive about it.
>>
>> I have tested to change PCLK divider while in auto mode but no effect.
>>
>>> Can we always set the mode to auto and divider to 1, even for the
>>> lower resolutions?
>>
>> This is breaking 176x144@30fps on my side, because of pixel clock too
>> high (112MHz vs 70 MHz max).
> 
> Ok.
> 
>> Instead of using auto mode, my proposal was the inverse: use manual mode
>> with the proper divider to fit the max pixel clock constraint.
> 
> Oh. That would work for me too yeah. How do you want to deal with it?
> Should I send your rebased patches, and you add that change as a
> subsequent patch?

Yes, this is the best option, and we can then ask people having CSI 
setup to check for non-regression after having applied this important 
clock serie patch.
Hoping that this will also work on their setup so that we can move 
forward on next OV5640 improvements.

> 
> Thanks!
> Maxime
> 

BR,
Hugues.

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

2018-10-04 Thread Maxime Ripard

Hi!

On Mon, Oct 01, 2018 at 02:12:31PM +, Hugues FRUCHET wrote:
> >> This is working perfectly fine on my parallel setup and allows me to
> >> well support VGA@30fps (instead 27) and also support XGA(1024x768)@15fps
> >> that I never seen working before.
> >> So at least for the parallel setup, this serie is working fine for all
> >> the discrete resolutions and framerate exposed by the driver for the 
> >> moment:
> >> * QCIF 176x144 15/30fps
> >> * QVGA 320x240 15/30fps
> >> * VGA 640x480 15/30fps
> >> * 480p 720x480 15/30fps
> >> * XGA 1024x768 15/30fps
> >> * 720p 1280x720 15/30fps
> >> * 1080p 1920x1080 15/30fps
> >> * 5Mp 2592x1944 15fps
> > 
> > I'm glad this is working for you as well. I guess I'll resubmit these
> > patches, but this time making sure someone with a CSI setup tests
> > before merging. I crtainly don't want to repeat the previous disaster.
> > 
> > Do you have those patches rebased somewhere? I'm not quite sure how to
> > fix the conflict with the v4l2_find_nearest_size addition.
> > 
> >> Moreover I'm not clear on relationship between rate and pixel clock
> >> frequency.
> >> I've understood that to DVP_PCLK_DIVIDER (0x3824) register
> >> and VFIFO_CTRL0C (0x460c) affects the effective pixel clock frequency.
> >> All the resolutions up to 720x576 are forcing a manual value of 2 for
> >> divider (0x460c=0x22), but including 720p and more, the divider value is
> >> controlled by "auto-mode" (0x460c=0x20)... from what I measured and
> >> understood, for those resolutions, the divider must be set to 1 in order
> >> that your rate computation match the effective pixel clock on output,
> >> see [2].
> >>
> >> So I wonder if this PCLK divider register should be included
> >> or not into your rate computation, what do you think ?
> > 
> > Have you tried change the PCLK divider while in auto-mode? IIRC, I did
> > that and it was affecting the PCLK rate on my scope, but I wouldn't be
> > definitive about it.
> 
> I have tested to change PCLK divider while in auto mode but no effect.
> 
> > Can we always set the mode to auto and divider to 1, even for the
> > lower resolutions?
>
> This is breaking 176x144@30fps on my side, because of pixel clock too 
> high (112MHz vs 70 MHz max).

Ok.

> Instead of using auto mode, my proposal was the inverse: use manual mode 
> with the proper divider to fit the max pixel clock constraint.

Oh. That would work for me too yeah. How do you want to deal with it?
Should I send your rebased patches, and you add that change as a
subsequent patch?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH v5] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Mauro Carvalho Chehab

From: Mauro Carvalho Chehab 

Add a glossary of terms used within the media userspace API
documentation, as several concepts are complex enough to cause
misunderstandings.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/media_uapi.rst|   3 +
 Documentation/media/uapi/glossary.rst | 185 ++
 2 files changed, 188 insertions(+)
 create mode 100644 Documentation/media/uapi/glossary.rst

diff --git a/Documentation/media/media_uapi.rst 
b/Documentation/media/media_uapi.rst
index 28eb35a1f965..41f091a26003 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -2,6 +2,8 @@
 
 .. include:: 
 
+.. _media_uapi:
+
 
 Linux Media Infrastructure userspace API
 
@@ -31,3 +33,4 @@ License".
 uapi/cec/cec-api
 uapi/gen-errors
 uapi/fdl-appendix
+uapi/glossary
diff --git a/Documentation/media/uapi/glossary.rst 
b/Documentation/media/uapi/glossary.rst
new file mode 100644
index ..1dce36707509
--- /dev/null
+++ b/Documentation/media/uapi/glossary.rst
@@ -0,0 +1,185 @@
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later
+
+.. For GPL-2.0, see LICENSES/preferred/GPL-2.0
+..
+.. For GFDL-1.1-or-later, see:
+..
+.. Permission is granted to copy, distribute and/or modify this document
+.. under the terms of the GNU Free Documentation License, Version 1.1 or
+.. any later version published by the Free Software Foundation, with no
+.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
+.. A copy of the license is included at
+.. Documentation/media/uapi/fdl-appendix.rst.
+
+
+Glossary
+
+
+.. note::
+
+   This goal of this section is to standardize the terms used within the media
+   userspace API documentation. It is written incrementally as they are
+   standardized in the media documentation.
+
+   So, it is a Work In Progress.
+
+.. Please keep the glossary entries in alphabetical order
+
+.. glossary::
+
+Bridge Driver
+   A :term:`device driver` that implements the main logic to talk with
+   media hardware.
+
+CEC API
+   **Consumer Electronics Control API**
+
+   An API designed to receive and transmit data via an HDMI
+   CEC interface.
+
+   See :ref:`cec`.
+
+Device Driver
+   Part of the Linux Kernel that implements support for a hardware
+   component.
+
+Device Node
+   A character device node in the file system used to control and
+   ransfer data in and out of a Kernel driver.
+
+Digital TV API
+   **Previously known as DVB API**
+
+   An API designed to control a subset of the :term:`Media Hardware`
+   that implements digital TV.
+
+   See :ref:`dvbapi`.
+
+DSP
+**Digital Signal Processor**
+
+   A specialized :term:`Microprocessor`, with its architecture
+   optimized for the operational needs of digital signal processing.
+
+FPGA
+   **Field-programmable Gate Array**
+
+   An :term:`IC` circuit designed to be configured by a customer or
+   a designer after manufacturing.
+
+   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
+
+I²C
+   **Inter-Integrated Circuit**
+
+   A  multi-master, multi-slave, packet switched, single-ended,
+   serial computer bus used to control some hardware components
+   like sub-device hardware components.
+
+   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
+
+IC
+   **Integrated circuit**
+
+   A set of electronic circuits on one small flat piece of
+   semiconductor material, normally silicon.
+
+   Also known as chip.
+
+IP Block
+   **Intellectual property core**
+
+   In electronic design a semiconductor intellectual property core,
+   is a reusable unit of logic, cell, or integrated circuit layout
+   design that is the intellectual property of one party.
+   IP Blocks may be licensed to another party or can be owned
+   and used by a single party alone.
+
+   See 
https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
+
+ISP
+   **Image Signal Processor**
+
+   A specialized processor that implements a set of algorithms for
+   processing image data. ISPs may implement algorithms for lens
+   shading correction, demosaicing, scaling and pixel format conversion
+   as well as produce statistics for the use of the control
+   algorithms (e.g. automatic exposure, white balance and focus).
+
+Media API
+   A set of userspace APIs used to control the media hardware. It is
+   composed by:
+
+ - :term:`CEC API`;
+ - :term:`Digital TV API`;
+ - :term:`MC API`;
+ - :term:`RC API`; and
+ - :term:`V4L2 API`.
+
+   See :ref:`media_uapi`.
+
+MC API
+   **Media Controller API**
+
+   An API designed to expose and control the relationships betwe

Re: [PATCH v3] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Mauro Carvalho Chehab

Em Thu, 4 Oct 2018 10:27:06 -0300
Mauro Carvalho Chehab  escreveu:


> > > + For V4L2 hardware, this is also known as V4L2 main driver.
> > 
> > Do we use the term V4L2 main driver in the V4L2 spec ?  
> 
> Right now, I don't think we use, but this is something that we'll
> need to, in order to define hardware controls.
> 
> Anyway, I'll remove the reference for a V4L2 hardware from this patch,
> moving to the one that talks about vdev-centric/mc-centric.

In time: I'll remove the reference for *V4L2 main driver*, with is
what you asked for


Thanks,
Mauro

Re: [PATCH v3 00/14] imx-media: Fixes for interlaced capture

2018-10-04 Thread Hans Verkuil

On 10/04/18 01:21, Steve Longerbeam wrote:
> Hi Hans,
> 
> 
> On 10/01/2018 03:07 AM, Hans Verkuil wrote:
>> Hi Steve,
>>
>> On 08/01/2018 09:12 PM, Steve Longerbeam wrote:
>>> A set of patches that fixes some bugs with capturing from an
>>> interlaced source, and incompatibilites between IDMAC interlace
>>> interweaving and 4:2:0 data write reduction.
>> I reviewed this series and it looks fine to me.
> 
> Cool.
> 
>>
>> It appears that the ipu* patches are already merged, so can you rebase and
>> repost?
> 
> Done. There are still two ipu* patches that still need a merge:
> 
> gpu: ipu-csi: Swap fields according to input/output field types
> gpu: ipu-v3: Add planar support to interlaced scan
> 
> so those will still be included in the v4 submission.
> 
>>
>> I would also like to see the 'v4l2-compliance -f' for an interlaced source,
>> if at all possible.
> 
> Sure, I've run 'v4l2-compliance -f' on two configured pipelines: unprocessed
> capture (no scaling, CSC, rotation using ipu), and a VDIC de-interlace 
> pipeline.
> 
> I have the text output, the output is huge but here is the abbreviated 
> results:
> 
> Unprocessed pipeline:
> 
> root@mx6q:/home/fu# v4l2-compliance -d4 -f
> v4l2-compliance SHA   : 2d35de61ac90b030fe15439809b807014e9751fe
> 
> test VIDIOC_G/S/ENUMINPUT: FAIL
> 
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL

This looks like something that should work. Not relevant for this patch
series, but something you should look into.

> 
> 
> Total: 715, Succeeded: 713, Failed: 2, Warnings: 0
> 
> 
> VDIC de-interlace pipeline:
> 
> root@mx6q:/home/fu# v4l2-compliance -d1 -f
> v4l2-compliance SHA   : 2d35de61ac90b030fe15439809b807014e9751fe
> 
> test VIDIOC_G/S/ENUMINPUT: FAIL
> 
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
> 
> test VIDIOC_G/S_PARM: FAIL

Same here: this appears to be an actual bug. But also not related to this
patch series.

Regards,

Hans

> 
> 
> Total: 50, Succeeded: 47, Failed: 3, Warnings: 1
> 
> I will send you the full output privately.
> 
> 
>>
>> For that matter, were you able to test all the field formats?
> 
> Yes. I've tested on imx6q SabreAuto with the ADV7180 alternate source,
> all of the following are tested and produce good video:
> 
> ntsc alternate -> interlaced-tb
> ntsc alternate -> interlaced-bt
> ntsc alternate -> none (VDIC pipeline)
> ntsc alternate -> none (VDIC pipeline)
> 
> pal alternate -> interlaced-tb
> pal alternate -> interlaced-bt
> pal alternate -> none (VDIC pipeline)
> pal alternate -> none (VDIC pipeline)
> 
> Steve
> 
> 
>>
>>> History:
>>> v3:
>>> - add support for/fix interweaved scan with YUV planar output.
>>> - fix bug in 4:2:0 U/V offset macros.
>>> - add patch that generalizes behavior of field swap in
>>>ipu_csi_init_interface().
>>> - add support for interweaved scan with field order swap.
>>>Suggested by Philipp Zabel.
>>> - in v2, inteweave scan was determined using field types of
>>>CSI (and PRPENCVF) at the sink and source pads. In v3, this
>>>has been moved one hop downstream: interweave is now determined
>>>using field type at source pad, and field type selected at
>>>capture interface. Suggested by Philipp.
>>> - make sure to double CSI crop target height when input field
>>>type in alternate.
>>> - more updates to media driver doc to reflect above.
>>>
>>> v2:
>>> - update media driver doc.
>>> - enable idmac interweave only if input field is sequential/alternate,
>>>and output field is 'interlaced*'.
>>> - move field try logic out of *try_fmt and into separate function.
>>> - fix bug with resetting crop/compose rectangles.
>>> - add a patch that fixes a field order bug in VDIC indirect mode.
>>> - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro
>>>Suggested-by: Nicolas Dufresne .
>>> - add macro V4L2_FIELD_IS_INTERLACED().
>>>
>>>
>>> Philipp Zabel (1):
>>>gpu: ipu-v3: Allow negative offsets for interlaced scanning
>>>
>>> Steve Longerbeam (13):
>>>media: videodev2.h: Add more field helper macros
>>>gpu: ipu-csi: Check for field type alternate
>>>gpu: ipu-csi: Swap fields according to input/output field types
>>>gpu: ipu-v3: Fix U/V offset macros for planar 4:2:0
>>>gpu: ipu-v3: Add planar support to interlaced scan
>>>media: imx: Fix field negotiation
>>>media: imx-csi: Double crop height for alternate fields at sink
>>>media: imx: interweave and odd-chroma-row skip are incompatible
>>>media: imx-csi: Allow skipping odd chroma rows for YVU420
>>>media: imx: vdic: rely on VDIC for correct field order
>>>media: imx-csi: Move crop/compose reset after filling default mbus
>>>  fields
>>>media: imx: Allow interweave with top/bottom lines swapped
>>>media: imx.rst: Update doc to reflect fixes to interlaced capture
>>>
>>>   Documentation/media/v4l-drivers/imx.rst   |  93 ++-
>>>   drivers/gpu/ipu-v3/ipu-cpmem.c|  45 ++-
>>>   drivers/gpu/ipu-v3/ipu-csi.c

Re: [PATCH v3] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Mauro Carvalho Chehab

Em Thu, 04 Oct 2018 14:41:30 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> (CC'ing Kieran)
> 
> Thank you for the patch.
> 
> On Tuesday, 25 September 2018 22:14:51 EEST Mauro Carvalho Chehab wrote:
> > From: Mauro Carvalho Chehab 
> > 
> > Add a glossary of terms used within the media userspace API
> > documentation, as several concepts are complex enough to cause
> > misunderstandings.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > 
> > v3:
> >   - Add SPDX header and dual-license the glossary
> >   - Make glossary generic enough to be used for all media uAPI
> > documentation; - Add a few new items to the glossary, to imply that it
> > covers not only V4L2; - Move it to the uAPI document as a hole.
> > 
> > v2: Did some changes based on Sakari's feedback.
> > 
> >  Documentation/media/media_uapi.rst|   3 +
> >  Documentation/media/uapi/glossary.rst | 162 ++
> >  2 files changed, 165 insertions(+)
> >  create mode 100644 Documentation/media/uapi/glossary.rst
> > 
> > diff --git a/Documentation/media/media_uapi.rst
> > b/Documentation/media/media_uapi.rst index 28eb35a1f965..41f091a26003
> > 100644
> > --- a/Documentation/media/media_uapi.rst
> > +++ b/Documentation/media/media_uapi.rst
> > @@ -2,6 +2,8 @@
> > 
> >  .. include:: 
> > 
> > +.. _media_uapi:
> > +
> >  
> >  Linux Media Infrastructure userspace API
> >  
> > @@ -31,3 +33,4 @@ License".
> >  uapi/cec/cec-api
> >  uapi/gen-errors
> >  uapi/fdl-appendix
> > +uapi/glossary  
> 
> Is there an easy way to cross-reference to the glossary when terms are used ?

According with Sphinx documentation, there is:
:term:`some glossary term`

But, on the tests I did here, it didn't really work with Sphinx 1.4.

It is actually on my TODO list to seek for a good way to address it
(and to find/replace occurrences of the terms at the documentation
to add cross-refs).

> 
> > diff --git a/Documentation/media/uapi/glossary.rst
> > b/Documentation/media/uapi/glossary.rst new file mode 100644
> > index ..9e2a2b29e8b2
> > --- /dev/null
> > +++ b/Documentation/media/uapi/glossary.rst
> > @@ -0,0 +1,162 @@
> > +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later
> > +
> > +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0
> > +..
> > +.. For GFDL-1.1-or-later, see:
> > +..
> > +.. Permission is granted to copy, distribute and/or modify this document
> > +.. under the terms of the GNU Free Documentation License, Version 1.1 or
> > +.. any later version published by the Free Software Foundation, with no
> > +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
> > +.. A copy of the license is included at
> > +.. Documentation/media/uapi/fdl-appendix.rst.
> > +
> > +
> > +Glossary
> > +
> > +
> > +.. note::
> > +
> > +   This goal of section is to standardize the terms used within the media
> > +   userspace API documentation. It is written incrementally as they are
> > +   standardized in the media documentation.
> > +
> > +   So, it is a Work In Progress.
> > +
> > +.. Please keep the glossary entries in alphabetical order
> > +
> > +.. glossary::
> > +
> > +Bridge driver  
> 
> Shouldn't all words start with a capital letter ?

I guess it is a matter of preference.

Right now, I'm capitalizing stuff only when they have acronyms
(like Digital Signal Processor - DSP), but I'm ok of doing it
to the other terms as well.

> 
> > +   A device driver that implements the main logic to talk with
> > +   a media hardware.  
> 
> Terms that are part of the glossary should also be capitalized (and cross-
> referenced within the glossary).

For now, it doesn't matter much. When we add cross references, it will use
either :ref: or :term:, so the actual text will be inserted by
Sphinx.

> 
> Hardware is still uncountable in English. I know we've discussed this 
> previously, but if we want to write a glossary, it should be in English. 
> Maybe 
> we need to involve a native English speaker here. Kieran ? :-)

I'll replace:

a media hardware -> media hardware

> 
> Additionally, I don't think the definition is correct. Bridges, as defined in 
> V4L2, are opposed to subdevs, while "media hardware" in your definition 
> includes everything. This needs to be clarified.

Please notice that the goal of this glossary is to be generic, and not
specific to V4L2. Extra care should be taken if we want to talk about
"subdevs" here, as such concept doesn't exist on DVB, CEC or RC (but
"main driver" does).

Also, I don't think that a subdev driver would fit into
"implements the main logic to talk with media hardware."

Anyway, if you have a better definition, feel free to suggest.


> 
> > +   For V4L2 hardware, this is also known as V4L2 main driver.  
> 
> Do we use the term V4L2 main driver in the V4L2 spec ?

Right now, I don't think we use, but this is something that we'll
need to, in or

[PATCHv2] media: rc: add driver for Xbox DVD Movie Playback Kit

2018-10-04 Thread Benjamin Valentin

The Xbox DVD Movie Playback Kit is a USB dongle with an IR remote for the
Original Xbox.

Historically it has been supported by the out-of-tree lirc_xbox driver,
but this one has fallen out of favour and was just dropped from popular
Kodi (formerly XBMC) distributions.

This driver is heaviely based on the ati_remote driver where all the
boilerplate was taken from - I was mostly just removing code.

Signed-off-by: Benjamin Valentin 
---
Changes since v1:

I discovered some more dead code leftover from the ati_remote driver.
I also removed the open_mutex which I think is not needed here since
this driver, unlike ati_remote, doesn't register both a rc and an input
device.
This also allowed me to collapse some functions.

 MAINTAINERS|   6 +
 drivers/media/rc/Kconfig   |  11 +
 drivers/media/rc/Makefile  |   1 +
 drivers/media/rc/keymaps/Makefile  |   1 +
 drivers/media/rc/keymaps/rc-xbox-dvd.c |  63 +
 drivers/media/rc/xbox_remote.c | 342 +
 include/media/rc-map.h |   1 +
 7 files changed, 425 insertions(+)
 create mode 100644 drivers/media/rc/keymaps/rc-xbox-dvd.c
 create mode 100644 drivers/media/rc/xbox_remote.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 22065048d89d..712a51a1a955 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15973,6 +15973,12 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso
 S: Maintained
 F: arch/x86/entry/vdso/
 
+XBOX DVD IR REMOTE
+M: Benjamin Valentin 
+S: Maintained
+F: drivers/media/rc/xbox_remote.c
+F: drivers/media/rc/keymaps/rc-xbox-dvd.c
+
 XC2028/3028 TUNER DRIVER
 M: Mauro Carvalho Chehab 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 1021c08a9ba4..05489294ebbc 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -493,6 +493,17 @@ config IR_TANGO
   The HW decoder supports NEC, RC-5, RC-6 IR protocols.
   When compiled as a module, look for tango-ir.
 
+config CONFIG_RC_XBOX_DVD
+   tristate "Xbox DVD Movie Playback Kit"
+   depends on RC_CORE
+   select USB
+   help
+  Say Y here if you want to use the Xbox DVD Movie Playback Kit.
+  These are IR remotes with USB receivers for the Original Xbox (2001).
+
+  To compile this driver as a module, choose M here: the module will be
+  called xbox_remote.
+
 config IR_ZX
tristate "ZTE ZX IR remote control"
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index e0340d043fe8..92c163816849 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -48,3 +48,4 @@ obj-$(CONFIG_IR_SIR) += sir_ir.o
 obj-$(CONFIG_IR_MTK) += mtk-cir.o
 obj-$(CONFIG_IR_ZX) += zx-irdec.o
 obj-$(CONFIG_IR_TANGO) += tango-ir.o
+obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o
diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index d6b913a3032d..5b1399af6b3a 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -116,4 +116,5 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-winfast.o \
rc-winfast-usbii-deluxe.o \
rc-su3000.o \
+   rc-xbox-dvd.o \
rc-zx-irdec.o
diff --git a/drivers/media/rc/keymaps/rc-xbox-dvd.c 
b/drivers/media/rc/keymaps/rc-xbox-dvd.c
new file mode 100644
index ..61da6706715c
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-xbox-dvd.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Keytable for Xbox DVD remote
+// Copyright (c) 2018 by Benjamin Valentin 
+
+#include 
+#include 
+
+/* based on lircd.conf.xbox */
+static struct rc_map_table xbox_dvd[] = {
+   {0x0b, KEY_OK},
+   {0xa6, KEY_UP},
+   {0xa7, KEY_DOWN},
+   {0xa8, KEY_RIGHT},
+   {0xa9, KEY_LEFT},
+   {0xc3, KEY_INFO},
+
+   {0xc6, KEY_9},
+   {0xc7, KEY_8},
+   {0xc8, KEY_7},
+   {0xc9, KEY_6},
+   {0xca, KEY_5},
+   {0xcb, KEY_4},
+   {0xcc, KEY_3},
+   {0xcd, KEY_2},
+   {0xce, KEY_1},
+   {0xcf, KEY_0},
+
+   {0xd5, KEY_ANGLE},
+   {0xd8, KEY_BACK},
+   {0xdd, KEY_PREVIOUSSONG},
+   {0xdf, KEY_NEXTSONG},
+   {0xe0, KEY_STOP},
+   {0xe2, KEY_REWIND},
+   {0xe3, KEY_FASTFORWARD},
+   {0xe5, KEY_TITLE},
+   {0xe6, KEY_PAUSE},
+   {0xea, KEY_PLAY},
+   {0xf7, KEY_MENU},
+};
+
+static struct rc_map_list xbox_dvd_map = {
+   .map = {
+   .scan = xbox_dvd,
+   .size = ARRAY_SIZE(xbox_dvd),
+   .rc_proto = RC_PROTO_UNKNOWN,
+   .name = RC_MAP_XBOX_DVD,
+   }
+};
+
+static int __init init_rc_map(void)
+{
+   return rc_map_register(&xbox_dvd_map);
+}
+
+static void __exit exit_rc_map(void)
+{
+   rc_map_unregister(&xbox_dvd_map

Re: [PATCH v3] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Laurent Pinchart

Hi Mauro,

(CC'ing Kieran)

Thank you for the patch.

On Tuesday, 25 September 2018 22:14:51 EEST Mauro Carvalho Chehab wrote:
> From: Mauro Carvalho Chehab 
> 
> Add a glossary of terms used within the media userspace API
> documentation, as several concepts are complex enough to cause
> misunderstandings.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> v3:
>   - Add SPDX header and dual-license the glossary
>   - Make glossary generic enough to be used for all media uAPI
> documentation; - Add a few new items to the glossary, to imply that it
> covers not only V4L2; - Move it to the uAPI document as a hole.
> 
> v2: Did some changes based on Sakari's feedback.
> 
>  Documentation/media/media_uapi.rst|   3 +
>  Documentation/media/uapi/glossary.rst | 162 ++
>  2 files changed, 165 insertions(+)
>  create mode 100644 Documentation/media/uapi/glossary.rst
> 
> diff --git a/Documentation/media/media_uapi.rst
> b/Documentation/media/media_uapi.rst index 28eb35a1f965..41f091a26003
> 100644
> --- a/Documentation/media/media_uapi.rst
> +++ b/Documentation/media/media_uapi.rst
> @@ -2,6 +2,8 @@
> 
>  .. include:: 
> 
> +.. _media_uapi:
> +
>  
>  Linux Media Infrastructure userspace API
>  
> @@ -31,3 +33,4 @@ License".
>  uapi/cec/cec-api
>  uapi/gen-errors
>  uapi/fdl-appendix
> +uapi/glossary

Is there an easy way to cross-reference to the glossary when terms are used ?

> diff --git a/Documentation/media/uapi/glossary.rst
> b/Documentation/media/uapi/glossary.rst new file mode 100644
> index ..9e2a2b29e8b2
> --- /dev/null
> +++ b/Documentation/media/uapi/glossary.rst
> @@ -0,0 +1,162 @@
> +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later
> +
> +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0
> +..
> +.. For GFDL-1.1-or-later, see:
> +..
> +.. Permission is granted to copy, distribute and/or modify this document
> +.. under the terms of the GNU Free Documentation License, Version 1.1 or
> +.. any later version published by the Free Software Foundation, with no
> +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
> +.. A copy of the license is included at
> +.. Documentation/media/uapi/fdl-appendix.rst.
> +
> +
> +Glossary
> +
> +
> +.. note::
> +
> +   This goal of section is to standardize the terms used within the media
> +   userspace API documentation. It is written incrementally as they are
> +   standardized in the media documentation.
> +
> +   So, it is a Work In Progress.
> +
> +.. Please keep the glossary entries in alphabetical order
> +
> +.. glossary::
> +
> +Bridge driver

Shouldn't all words start with a capital letter ?

> + A device driver that implements the main logic to talk with
> + a media hardware.

Terms that are part of the glossary should also be capitalized (and cross-
referenced within the glossary).

Hardware is still uncountable in English. I know we've discussed this 
previously, but if we want to write a glossary, it should be in English. Maybe 
we need to involve a native English speaker here. Kieran ? :-)

Additionally, I don't think the definition is correct. Bridges, as defined in 
V4L2, are opposed to subdevs, while "media hardware" in your definition 
includes everything. This needs to be clarified.

> + For V4L2 hardware, this is also known as V4L2 main driver.

Do we use the term V4L2 main driver in the V4L2 spec ?

> +Consumer Electronics Control API
> + An API designed to receive and transmit data via a HDMI
> + CEC interface.

So the definition of "Consumer Electronics Control" is CEC ? :-) It would be 
more useful to do it the other way around, define CEC as Consumer Electronics 
Control, and explain what it is.

> + See :ref:`cec`.
> +
> +Device Node
> + A character device node in the file system used to control and do
> + input/output data transfers from/to a Kernel driver.

Maybe "and transfer data in and out of a kernel driver" ?

> +
> +Digital TV API - DVB API

Is DVB the same as Digital TV ? The digital video API (https://linuxtv.org/
downloads/v4l-dvb-apis-new/uapi/v4l/dv-timings.html) is sometimes referred to 
digital TV too. How about standardizing on DVB and avoiding digital TV 
completely in the specification ?

> + An API designed to control the media device components related to
> + digital TV, including frontends, demuxes, streaming, conditional
> + access, etc.
> +
> + See :ref:`dvbapi`.
> +
> +Digital Signal Processor - DSP

Here and below I would put the abbreviation first. If someone looks up a term 
in the glossary because they don't know what it means, they're more likely to 
search for the abbreviation, not the full term.

> + A specialized microprocessor, with its architecture optimized for
> + the operational needs of digital signal processing.

Stupid question, do we need this entry in t

Re: [PATCH v4] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Mauro Carvalho Chehab

Em Thu, 4 Oct 2018 13:11:12 +0200
Hans Verkuil  escreveu:

> On 10/04/18 12:58, Mauro Carvalho Chehab wrote:
> > From: Mauro Carvalho Chehab 
> > 
> > Add a glossary of terms used within the media userspace API
> > documentation, as several concepts are complex enough to cause
> > misunderstandings.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  Documentation/media/media_uapi.rst|   3 +
> >  Documentation/media/uapi/glossary.rst | 162 ++
> >  2 files changed, 165 insertions(+)
> >  create mode 100644 Documentation/media/uapi/glossary.rst
> > 
> > diff --git a/Documentation/media/media_uapi.rst 
> > b/Documentation/media/media_uapi.rst
> > index 28eb35a1f965..41f091a26003 100644
> > --- a/Documentation/media/media_uapi.rst
> > +++ b/Documentation/media/media_uapi.rst
> > @@ -2,6 +2,8 @@
> >  
> >  .. include:: 
> >  
> > +.. _media_uapi:
> > +
> >  
> >  Linux Media Infrastructure userspace API
> >  
> > @@ -31,3 +33,4 @@ License".
> >  uapi/cec/cec-api
> >  uapi/gen-errors
> >  uapi/fdl-appendix
> > +uapi/glossary
> > diff --git a/Documentation/media/uapi/glossary.rst 
> > b/Documentation/media/uapi/glossary.rst
> > new file mode 100644
> > index ..4307decd345f
> > --- /dev/null
> > +++ b/Documentation/media/uapi/glossary.rst
> > @@ -0,0 +1,162 @@
> > +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later
> > +
> > +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0
> > +..
> > +.. For GFDL-1.1-or-later, see:
> > +..
> > +.. Permission is granted to copy, distribute and/or modify this document
> > +.. under the terms of the GNU Free Documentation License, Version 1.1 or
> > +.. any later version published by the Free Software Foundation, with no
> > +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
> > +.. A copy of the license is included at
> > +.. Documentation/media/uapi/fdl-appendix.rst.
> > +
> > +
> > +Glossary
> > +
> > +
> > +.. note::
> > +
> > +   This goal of section is to standardize the terms used within the media
> 
> The goal of this section
> 
> (Huh, was wrong in v3 as well, I completely read over this at the time!)
> 
> > +   userspace API documentation. It is written incrementally as they are
> > +   standardized in the media documentation.
> > +
> > +   So, it is a Work In Progress.
> > +
> > +.. Please keep the glossary entries in alphabetical order
> > +
> > +.. glossary::
> > +
> > +Bridge driver
> > +   A device driver that implements the main logic to talk with
> > +   media hardware.
> > +
> > +   For V4L2 hardware, this is also known as the V4L2 main driver.
> > +
> > +Consumer Electronics Control API
> > +   An API designed to receive and transmit data via a HDMI
> 
> a HDMI -> an HDMI
> 
> (when you pronounce it 'HDMI' starts with a vowel, hence the 'an')
> 
> > +   CEC interface.
> > +
> > +   See :ref:`cec`.
> > +
> > +Device Node
> > +   A character device node in the file system used to control and do
> > +   input/output data transfers from/to a Kernel driver.
> > +
> > +Digital TV API - DVB API
> > +   An API designed to control the media device components related to
> > +   digital TV, including frontends, demuxes, streaming, conditional
> > +   access, etc.
> > +
> > +   See :ref:`dvbapi`.
> > +
> > +Digital Signal Processor - DSP
> > +   A specialized microprocessor, with its architecture optimized for
> > +   the operational needs of digital signal processing.
> > +
> > +Driver
> > +   Part of the Linux Kernel that implements support for a hardware
> > +   component.
> > +
> > +Field-programmable Gate Array - FPGA
> > +   A field-programmable gate array (FPGA) is an integrated circuit
> > +   designed to be configured by a customer or a designer after
> > +   manufacturing.
> > +
> > +   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> > +
> > +Inter-Integrated Circuit - I²C
> > +   A  multi-master, multi-slave, packet switched, single-ended,
> > +   serial computer bus used to control some hardware components
> > +   like sub-device hardware components.
> > +
> > +   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> > +
> > +Integrated circuit - IC
> > +   A set of electronic circuits on one small flat piece of
> > +   semiconductor material, normally silicon.
> > +
> > +   Also known as chip.
> > +
> > +Intellectual property core - IP block
> > +   In electronic design a semiconductor intellectual property core,
> > +   is a reusable unit of logic, cell, or integrated circuit layout
> > +   design that is the intellectual property of one party.
> > +   IP cores may be licensed to another party or can be owned
> > +   and used by a single party alone.
> > +
> > +   See 
> > https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
> > +
> > +Image Signal Processor - ISP
> > +   A specialised processor t

[PATCH] media: ov5640: fix framerate update

2018-10-04 Thread Hugues Fruchet

Changing framerate right before streamon had no effect,
the new framerate value was taken into account only at
next streamon, fix this.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/i2c/ov5640.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 664ffac..8599e17 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2573,8 +2573,6 @@ static int ov5640_s_frame_interval(struct v4l2_subdev *sd,
if (frame_rate < 0)
frame_rate = OV5640_15_FPS;
 
-   sensor->current_fr = frame_rate;
-   sensor->frame_interval = fi->interval;
mode = ov5640_find_mode(sensor, frame_rate, mode->hact,
mode->vact, true);
if (!mode) {
@@ -2582,7 +2580,10 @@ static int ov5640_s_frame_interval(struct v4l2_subdev 
*sd,
goto out;
}
 
-   if (mode != sensor->current_mode) {
+   if (mode != sensor->current_mode ||
+   frame_rate != sensor->current_fr) {
+   sensor->current_fr = frame_rate;
+   sensor->frame_interval = fi->interval;
sensor->current_mode = mode;
sensor->pending_mode_change = true;
}
-- 
2.7.4

Re: [PATCH 2/2] media: vivid: Add 16-bit bayer to format list

2018-10-04 Thread Hans Verkuil

On 10/04/18 13:01, bwint...@cisco.com wrote:
> From: Bård Eirik Winther 
> 

Same here: missing commit message.

This patch looks good otherwise.

Regards,

Hans

> Signed-off-by: Bård Eirik Winther 
> ---
>  .../media/platform/vivid/vivid-vid-common.c   | 28 +++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/media/platform/vivid/vivid-vid-common.c 
> b/drivers/media/platform/vivid/vivid-vid-common.c
> index 27aa5973..9645a91b8782 100644
> --- a/drivers/media/platform/vivid/vivid-vid-common.c
> +++ b/drivers/media/platform/vivid/vivid-vid-common.c
> @@ -449,6 +449,34 @@ struct vivid_fmt vivid_formats[] = {
>   .planes   = 1,
>   .buffers = 1,
>   },
> + {
> + .fourcc   = V4L2_PIX_FMT_SBGGR16, /* Bayer BG/GR */
> + .vdownsampling = { 1 },
> + .bit_depth = { 16 },
> + .planes   = 1,
> + .buffers = 1,
> + },
> + {
> + .fourcc   = V4L2_PIX_FMT_SGBRG16, /* Bayer GB/RG */
> + .vdownsampling = { 1 },
> + .bit_depth = { 16 },
> + .planes   = 1,
> + .buffers = 1,
> + },
> + {
> + .fourcc   = V4L2_PIX_FMT_SGRBG16, /* Bayer GR/BG */
> + .vdownsampling = { 1 },
> + .bit_depth = { 16 },
> + .planes   = 1,
> + .buffers = 1,
> + },
> + {
> + .fourcc   = V4L2_PIX_FMT_SRGGB16, /* Bayer RG/GB */
> + .vdownsampling = { 1 },
> + .bit_depth = { 16 },
> + .planes   = 1,
> + .buffers = 1,
> + },
>   {
>   .fourcc   = V4L2_PIX_FMT_HSV24, /* HSV 24bits */
>   .color_enc = TGP_COLOR_ENC_HSV,
>

Re: [PATCH 1/2] media: v4l2-tpg-core: Add 16-bit bayer

2018-10-04 Thread Hans Verkuil

On 10/04/18 13:01, bwint...@cisco.com wrote:
> From: Bård Eirik Winther 
> 

Missing commit message.

Looks good otherwise.

Regards,

Hans

> Signed-off-by: Bård Eirik Winther 
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 28 +++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index f3d9c1140ffa..76b125ebee6d 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -202,6 +202,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   case V4L2_PIX_FMT_SGBRG12:
>   case V4L2_PIX_FMT_SGRBG12:
>   case V4L2_PIX_FMT_SRGGB12:
> + case V4L2_PIX_FMT_SBGGR16:
> + case V4L2_PIX_FMT_SGBRG16:
> + case V4L2_PIX_FMT_SGRBG16:
> + case V4L2_PIX_FMT_SRGGB16:
>   tpg->interleaved = true;
>   tpg->vdownsampling[1] = 1;
>   tpg->hdownsampling[1] = 1;
> @@ -394,6 +398,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   case V4L2_PIX_FMT_SGRBG12:
>   case V4L2_PIX_FMT_SGBRG12:
>   case V4L2_PIX_FMT_SBGGR12:
> + case V4L2_PIX_FMT_SRGGB16:
> + case V4L2_PIX_FMT_SGRBG16:
> + case V4L2_PIX_FMT_SGBRG16:
> + case V4L2_PIX_FMT_SBGGR16:
>   tpg->twopixelsize[0] = 4;
>   tpg->twopixelsize[1] = 4;
>   break;
> @@ -1358,6 +1366,22 @@ static void gen_twopix(struct tpg_data *tpg,
>   buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
>   buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
>   break;
> + case V4L2_PIX_FMT_SBGGR16:
> + buf[0][offset] = buf[0][offset + 1] = odd ? g_u_s : b_v;
> + buf[1][offset] = buf[1][offset + 1] = odd ? r_y_h : g_u_s;
> + break;
> + case V4L2_PIX_FMT_SGBRG16:
> + buf[0][offset] = buf[0][offset + 1] = odd ? b_v : g_u_s;
> + buf[1][offset] = buf[1][offset + 1] = odd ? g_u_s : r_y_h;
> + break;
> + case V4L2_PIX_FMT_SGRBG16:
> + buf[0][offset] = buf[0][offset + 1] = odd ? r_y_h : g_u_s;
> + buf[1][offset] = buf[1][offset + 1] = odd ? g_u_s : b_v;
> + break;
> + case V4L2_PIX_FMT_SRGGB16:
> + buf[0][offset] = buf[0][offset + 1] = odd ? g_u_s : r_y_h;
> + buf[1][offset] = buf[1][offset + 1] = odd ? b_v : g_u_s;
> + break;
>   }
>  }
>  
> @@ -1376,6 +1400,10 @@ unsigned tpg_g_interleaved_plane(const struct tpg_data 
> *tpg, unsigned buf_line)
>   case V4L2_PIX_FMT_SGBRG12:
>   case V4L2_PIX_FMT_SGRBG12:
>   case V4L2_PIX_FMT_SRGGB12:
> + case V4L2_PIX_FMT_SBGGR16:
> + case V4L2_PIX_FMT_SGBRG16:
> + case V4L2_PIX_FMT_SGRBG16:
> + case V4L2_PIX_FMT_SRGGB16:
>   return buf_line & 1;
>   default:
>   return 0;
>

Re: [PATCH v4] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Hans Verkuil

On 10/04/18 12:58, Mauro Carvalho Chehab wrote:
> From: Mauro Carvalho Chehab 
> 
> Add a glossary of terms used within the media userspace API
> documentation, as several concepts are complex enough to cause
> misunderstandings.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/media_uapi.rst|   3 +
>  Documentation/media/uapi/glossary.rst | 162 ++
>  2 files changed, 165 insertions(+)
>  create mode 100644 Documentation/media/uapi/glossary.rst
> 
> diff --git a/Documentation/media/media_uapi.rst 
> b/Documentation/media/media_uapi.rst
> index 28eb35a1f965..41f091a26003 100644
> --- a/Documentation/media/media_uapi.rst
> +++ b/Documentation/media/media_uapi.rst
> @@ -2,6 +2,8 @@
>  
>  .. include:: 
>  
> +.. _media_uapi:
> +
>  
>  Linux Media Infrastructure userspace API
>  
> @@ -31,3 +33,4 @@ License".
>  uapi/cec/cec-api
>  uapi/gen-errors
>  uapi/fdl-appendix
> +uapi/glossary
> diff --git a/Documentation/media/uapi/glossary.rst 
> b/Documentation/media/uapi/glossary.rst
> new file mode 100644
> index ..4307decd345f
> --- /dev/null
> +++ b/Documentation/media/uapi/glossary.rst
> @@ -0,0 +1,162 @@
> +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later
> +
> +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0
> +..
> +.. For GFDL-1.1-or-later, see:
> +..
> +.. Permission is granted to copy, distribute and/or modify this document
> +.. under the terms of the GNU Free Documentation License, Version 1.1 or
> +.. any later version published by the Free Software Foundation, with no
> +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
> +.. A copy of the license is included at
> +.. Documentation/media/uapi/fdl-appendix.rst.
> +
> +
> +Glossary
> +
> +
> +.. note::
> +
> +   This goal of section is to standardize the terms used within the media

The goal of this section

(Huh, was wrong in v3 as well, I completely read over this at the time!)

> +   userspace API documentation. It is written incrementally as they are
> +   standardized in the media documentation.
> +
> +   So, it is a Work In Progress.
> +
> +.. Please keep the glossary entries in alphabetical order
> +
> +.. glossary::
> +
> +Bridge driver
> + A device driver that implements the main logic to talk with
> + media hardware.
> +
> + For V4L2 hardware, this is also known as the V4L2 main driver.
> +
> +Consumer Electronics Control API
> + An API designed to receive and transmit data via a HDMI

a HDMI -> an HDMI

(when you pronounce it 'HDMI' starts with a vowel, hence the 'an')

> + CEC interface.
> +
> + See :ref:`cec`.
> +
> +Device Node
> + A character device node in the file system used to control and do
> + input/output data transfers from/to a Kernel driver.
> +
> +Digital TV API - DVB API
> + An API designed to control the media device components related to
> + digital TV, including frontends, demuxes, streaming, conditional
> + access, etc.
> +
> + See :ref:`dvbapi`.
> +
> +Digital Signal Processor - DSP
> + A specialized microprocessor, with its architecture optimized for
> + the operational needs of digital signal processing.
> +
> +Driver
> + Part of the Linux Kernel that implements support for a hardware
> + component.
> +
> +Field-programmable Gate Array - FPGA
> + A field-programmable gate array (FPGA) is an integrated circuit
> + designed to be configured by a customer or a designer after
> + manufacturing.
> +
> + See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> +
> +Inter-Integrated Circuit - I²C
> + A  multi-master, multi-slave, packet switched, single-ended,
> + serial computer bus used to control some hardware components
> + like sub-device hardware components.
> +
> + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> +
> +Integrated circuit - IC
> + A set of electronic circuits on one small flat piece of
> + semiconductor material, normally silicon.
> +
> + Also known as chip.
> +
> +Intellectual property core - IP block
> + In electronic design a semiconductor intellectual property core,
> + is a reusable unit of logic, cell, or integrated circuit layout
> + design that is the intellectual property of one party.
> + IP cores may be licensed to another party or can be owned
> + and used by a single party alone.
> +
> + See 
> https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
> +
> +Image Signal Processor - ISP
> + A specialised processor that implements a set of algorithms for
> + processing image data. ISPs may implement algorithms for lens
> + shading correction, demosaicing, scaling and pixel format conversion
> + as well as produce statistics for the use of the control
> + algorithms (e.g.

[PATCH 1/2] media: v4l2-tpg-core: Add 16-bit bayer

2018-10-04 Thread bwinther

From: Bård Eirik Winther 

Signed-off-by: Bård Eirik Winther 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 28 +++
 1 file changed, 28 insertions(+)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index f3d9c1140ffa..76b125ebee6d 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -202,6 +202,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_SGBRG12:
case V4L2_PIX_FMT_SGRBG12:
case V4L2_PIX_FMT_SRGGB12:
+   case V4L2_PIX_FMT_SBGGR16:
+   case V4L2_PIX_FMT_SGBRG16:
+   case V4L2_PIX_FMT_SGRBG16:
+   case V4L2_PIX_FMT_SRGGB16:
tpg->interleaved = true;
tpg->vdownsampling[1] = 1;
tpg->hdownsampling[1] = 1;
@@ -394,6 +398,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_SGRBG12:
case V4L2_PIX_FMT_SGBRG12:
case V4L2_PIX_FMT_SBGGR12:
+   case V4L2_PIX_FMT_SRGGB16:
+   case V4L2_PIX_FMT_SGRBG16:
+   case V4L2_PIX_FMT_SGBRG16:
+   case V4L2_PIX_FMT_SBGGR16:
tpg->twopixelsize[0] = 4;
tpg->twopixelsize[1] = 4;
break;
@@ -1358,6 +1366,22 @@ static void gen_twopix(struct tpg_data *tpg,
buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
break;
+   case V4L2_PIX_FMT_SBGGR16:
+   buf[0][offset] = buf[0][offset + 1] = odd ? g_u_s : b_v;
+   buf[1][offset] = buf[1][offset + 1] = odd ? r_y_h : g_u_s;
+   break;
+   case V4L2_PIX_FMT_SGBRG16:
+   buf[0][offset] = buf[0][offset + 1] = odd ? b_v : g_u_s;
+   buf[1][offset] = buf[1][offset + 1] = odd ? g_u_s : r_y_h;
+   break;
+   case V4L2_PIX_FMT_SGRBG16:
+   buf[0][offset] = buf[0][offset + 1] = odd ? r_y_h : g_u_s;
+   buf[1][offset] = buf[1][offset + 1] = odd ? g_u_s : b_v;
+   break;
+   case V4L2_PIX_FMT_SRGGB16:
+   buf[0][offset] = buf[0][offset + 1] = odd ? g_u_s : r_y_h;
+   buf[1][offset] = buf[1][offset + 1] = odd ? b_v : g_u_s;
+   break;
}
 }
 
@@ -1376,6 +1400,10 @@ unsigned tpg_g_interleaved_plane(const struct tpg_data 
*tpg, unsigned buf_line)
case V4L2_PIX_FMT_SGBRG12:
case V4L2_PIX_FMT_SGRBG12:
case V4L2_PIX_FMT_SRGGB12:
+   case V4L2_PIX_FMT_SBGGR16:
+   case V4L2_PIX_FMT_SGBRG16:
+   case V4L2_PIX_FMT_SGRBG16:
+   case V4L2_PIX_FMT_SRGGB16:
return buf_line & 1;
default:
return 0;
-- 
2.17.1

[PATCH 2/2] media: vivid: Add 16-bit bayer to format list

2018-10-04 Thread bwinther

From: Bård Eirik Winther 

Signed-off-by: Bård Eirik Winther 
---
 .../media/platform/vivid/vivid-vid-common.c   | 28 +++
 1 file changed, 28 insertions(+)

diff --git a/drivers/media/platform/vivid/vivid-vid-common.c 
b/drivers/media/platform/vivid/vivid-vid-common.c
index 27aa5973..9645a91b8782 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -449,6 +449,34 @@ struct vivid_fmt vivid_formats[] = {
.planes   = 1,
.buffers = 1,
},
+   {
+   .fourcc   = V4L2_PIX_FMT_SBGGR16, /* Bayer BG/GR */
+   .vdownsampling = { 1 },
+   .bit_depth = { 16 },
+   .planes   = 1,
+   .buffers = 1,
+   },
+   {
+   .fourcc   = V4L2_PIX_FMT_SGBRG16, /* Bayer GB/RG */
+   .vdownsampling = { 1 },
+   .bit_depth = { 16 },
+   .planes   = 1,
+   .buffers = 1,
+   },
+   {
+   .fourcc   = V4L2_PIX_FMT_SGRBG16, /* Bayer GR/BG */
+   .vdownsampling = { 1 },
+   .bit_depth = { 16 },
+   .planes   = 1,
+   .buffers = 1,
+   },
+   {
+   .fourcc   = V4L2_PIX_FMT_SRGGB16, /* Bayer RG/GB */
+   .vdownsampling = { 1 },
+   .bit_depth = { 16 },
+   .planes   = 1,
+   .buffers = 1,
+   },
{
.fourcc   = V4L2_PIX_FMT_HSV24, /* HSV 24bits */
.color_enc = TGP_COLOR_ENC_HSV,
-- 
2.17.1

[PATCH v4] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Mauro Carvalho Chehab

From: Mauro Carvalho Chehab 

Add a glossary of terms used within the media userspace API
documentation, as several concepts are complex enough to cause
misunderstandings.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/media_uapi.rst|   3 +
 Documentation/media/uapi/glossary.rst | 162 ++
 2 files changed, 165 insertions(+)
 create mode 100644 Documentation/media/uapi/glossary.rst

diff --git a/Documentation/media/media_uapi.rst 
b/Documentation/media/media_uapi.rst
index 28eb35a1f965..41f091a26003 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -2,6 +2,8 @@
 
 .. include:: 
 
+.. _media_uapi:
+
 
 Linux Media Infrastructure userspace API
 
@@ -31,3 +33,4 @@ License".
 uapi/cec/cec-api
 uapi/gen-errors
 uapi/fdl-appendix
+uapi/glossary
diff --git a/Documentation/media/uapi/glossary.rst 
b/Documentation/media/uapi/glossary.rst
new file mode 100644
index ..4307decd345f
--- /dev/null
+++ b/Documentation/media/uapi/glossary.rst
@@ -0,0 +1,162 @@
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later
+
+.. For GPL-2.0, see LICENSES/preferred/GPL-2.0
+..
+.. For GFDL-1.1-or-later, see:
+..
+.. Permission is granted to copy, distribute and/or modify this document
+.. under the terms of the GNU Free Documentation License, Version 1.1 or
+.. any later version published by the Free Software Foundation, with no
+.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
+.. A copy of the license is included at
+.. Documentation/media/uapi/fdl-appendix.rst.
+
+
+Glossary
+
+
+.. note::
+
+   This goal of section is to standardize the terms used within the media
+   userspace API documentation. It is written incrementally as they are
+   standardized in the media documentation.
+
+   So, it is a Work In Progress.
+
+.. Please keep the glossary entries in alphabetical order
+
+.. glossary::
+
+Bridge driver
+   A device driver that implements the main logic to talk with
+   media hardware.
+
+   For V4L2 hardware, this is also known as the V4L2 main driver.
+
+Consumer Electronics Control API
+   An API designed to receive and transmit data via a HDMI
+   CEC interface.
+
+   See :ref:`cec`.
+
+Device Node
+   A character device node in the file system used to control and do
+   input/output data transfers from/to a Kernel driver.
+
+Digital TV API - DVB API
+   An API designed to control the media device components related to
+   digital TV, including frontends, demuxes, streaming, conditional
+   access, etc.
+
+   See :ref:`dvbapi`.
+
+Digital Signal Processor - DSP
+   A specialized microprocessor, with its architecture optimized for
+   the operational needs of digital signal processing.
+
+Driver
+   Part of the Linux Kernel that implements support for a hardware
+   component.
+
+Field-programmable Gate Array - FPGA
+   A field-programmable gate array (FPGA) is an integrated circuit
+   designed to be configured by a customer or a designer after
+   manufacturing.
+
+   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
+
+Inter-Integrated Circuit - I²C
+   A  multi-master, multi-slave, packet switched, single-ended,
+   serial computer bus used to control some hardware components
+   like sub-device hardware components.
+
+   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
+
+Integrated circuit - IC
+   A set of electronic circuits on one small flat piece of
+   semiconductor material, normally silicon.
+
+   Also known as chip.
+
+Intellectual property core - IP block
+   In electronic design a semiconductor intellectual property core,
+   is a reusable unit of logic, cell, or integrated circuit layout
+   design that is the intellectual property of one party.
+   IP cores may be licensed to another party or can be owned
+   and used by a single party alone.
+
+   See 
https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
+
+Image Signal Processor - ISP
+   A specialised processor that implements a set of algorithms for
+   processing image data. ISPs may implement algorithms for lens
+   shading correction, demosaicing, scaling and pixel format conversion
+   as well as produce statistics for the use of the control
+   algorithms (e.g. automatic exposure, white balance and focus).
+
+Media API
+   A set of userspace APIs used to control a media hardware.
+
+   See :ref:`media_uapi`.
+
+Media Controller
+   An API designed to expose and control the relationships between
+   devices and sub-devices.
+
+   See :ref:`media_controller`.
+
+Media Hardware
+   Subset of the hardware that is supported by the Linux Media API.
+
+

Re: [PATCH v3] media: docs: add glossary.rst with common terms used at V4L2 spec

2018-10-04 Thread Mauro Carvalho Chehab

Em Mon, 1 Oct 2018 17:20:26 +0200
Hans Verkuil  escreveu:

> On 09/25/2018 09:14 PM, Mauro Carvalho Chehab wrote:
> > From: Mauro Carvalho Chehab 
> > 
> > Add a glossary of terms used within the media userspace API
> > documentation, as several concepts are complex enough to cause
> > misunderstandings.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > 
> > v3:
> >   - Add SPDX header and dual-license the glossary
> >   - Make glossary generic enough to be used for all media uAPI 
> > documentation;
> >   - Add a few new items to the glossary, to imply that it covers not only 
> > V4L2;
> >   - Move it to the uAPI document as a hole.
> > 
> > v2: Did some changes based on Sakari's feedback.
> > 
> >  Documentation/media/media_uapi.rst|   3 +
> >  Documentation/media/uapi/glossary.rst | 162 ++
> >  2 files changed, 165 insertions(+)
> >  create mode 100644 Documentation/media/uapi/glossary.rst
> > 
> > diff --git a/Documentation/media/media_uapi.rst 
> > b/Documentation/media/media_uapi.rst
> > index 28eb35a1f965..41f091a26003 100644
> > --- a/Documentation/media/media_uapi.rst
> > +++ b/Documentation/media/media_uapi.rst
> > @@ -2,6 +2,8 @@
> >  
> >  .. include:: 
> >  
> > +.. _media_uapi:
> > +
> >  
> >  Linux Media Infrastructure userspace API
> >  
> > @@ -31,3 +33,4 @@ License".
> >  uapi/cec/cec-api
> >  uapi/gen-errors
> >  uapi/fdl-appendix
> > +uapi/glossary
> > diff --git a/Documentation/media/uapi/glossary.rst 
> > b/Documentation/media/uapi/glossary.rst
> > new file mode 100644
> > index ..9e2a2b29e8b2
> > --- /dev/null
> > +++ b/Documentation/media/uapi/glossary.rst
> > @@ -0,0 +1,162 @@
> > +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later
> > +
> > +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0
> > +..
> > +.. For GFDL-1.1-or-later, see:
> > +..
> > +.. Permission is granted to copy, distribute and/or modify this document
> > +.. under the terms of the GNU Free Documentation License, Version 1.1 or
> > +.. any later version published by the Free Software Foundation, with no
> > +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
> > +.. A copy of the license is included at
> > +.. Documentation/media/uapi/fdl-appendix.rst.
> > +
> > +
> > +Glossary
> > +
> > +
> > +.. note::
> > +
> > +   This goal of section is to standardize the terms used within the media
> > +   userspace API documentation. It is written incrementally as they are
> > +   standardized in the media documentation.
> > +
> > +   So, it is a Work In Progress.
> > +
> > +.. Please keep the glossary entries in alphabetical order
> > +
> > +.. glossary::
> > +
> > +Bridge driver
> > +   A device driver that implements the main logic to talk with
> > +   a media hardware.  
> 
> s/a //
> 
> > +
> > +   For V4L2 hardware, this is also known as V4L2 main driver.  
> 
> s/as/as the/
> 
> > +
> > +Consumer Electronics Control API
> > +   An API designed to receive and transmit data via a HDMI
> > +   CEC interface.
> > +
> > +   See :ref:`cec`.
> > +
> > +Device Node
> > +   A character device node in the file system used to control and do
> > +   input/output data transfers from/to a Kernel driver.
> > +
> > +Digital TV API - DVB API
> > +   An API designed to control the media device components related to
> > +   digital TV, including frontends, demuxes, streaming, conditional
> > +   access, etc.  
> 
> To be added to this glossary in the future:
> 
> - Frontend
> - Demux
> - Conditional Access

Yeah. The idea here is just to place a boilerplate for it.

We should in the future add more terms to the glossary. After
having the glossary added, it should be reviewed along the other
documents. Then, I'll add digital TV specific terms.

> 
> > +
> > +   See :ref:`dvbapi`.
> > +
> > +Digital Signal Processor - DSP
> > +   A specialized microprocessor, with its architecture optimized for
> > +   the operational needs of digital signal processing.
> > +
> > +Driver
> > +   Part of the Linux Kernel that implements support for a hardware
> > +   component.
> > +
> > +Field-programmable Gate Array - FPGA
> > +   A field-programmable gate array (FPGA) is an integrated circuit
> > +   designed to be configured by a customer or a designer after
> > +   manufacturing.
> > +
> > +   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> > +
> > +Inter-Integrated Circuit - I²C
> > +   A  multi-master, multi-slave, packet switched, single-ended,
> > +   serial computer bus used to control some hardware components
> > +   like sub-device hardware components.
> > +
> > +   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> > +
> > +Integrated circuit - IC
> > +   A set of electronic circuits on one small flat piece of
> > +   semiconductor material, normally silicon.
> > +
> > +   Also known as chip.
> > +
> >

Re: [RFC PATCH] media: v4l2-ctrl: Add control for specific V4L2_EVENT_SRC_CH_RESOLUTION support

2018-10-04 Thread Tomasz Figa

On Wed, Oct 3, 2018 at 7:02 PM Maxime Jourdan  wrote:
>
> On Tue, Oct 2, 2018 at 1:43 PM Hans Verkuil  wrote:
> >
> > On 10/02/18 13:31, Maxime Jourdan wrote:
> > > For drivers that expose both an OUTPUT queue and
> > > V4L2_EVENT_SRC_CH_RESOLUTION such as video decoders, it is
> > > possible that support for this event is limited to a subset
> > > of the enumerated OUTPUT formats.
> > >
> > > This adds V4L2_CID_SUPPORTS_CH_RESOLUTION that allows such a driver to
> > > notify userspace of per-format support for this event.
> >
> > An alternative is a flag returned by ENUMFMT.
> >
> > I would definitely invert the flag/control since the default should be
> > that this event is supported for these types of devices. Instead you
> > want to signal the exception (not supported).
> >
> > I think a format flag is better since this is really tied to the format
> > for this particular driver.
> >
> > This is a limitation of this hardware/firmware, right? It is not a
> > limitation of the format itself?
> >
> > And basically the decoder hardware cannot report when the resolution
> > changes midstream? What happens if userspace does not take this into
> > account and just continue? DMA overflow? Hope not.
> >
>
> I tested it: yep, DMA overflow if you're not careful. A solution is to
> always allocate buffers that can hold the maximum decodable picture
> size.
>
> Upon further investigation, the firmwares for older codecs (MPEG2 &
> MPEG4) expose registers to fetch the parsed width/height.
> There is one issue however: the decoder starts decoding right away,
> and we can gather the width/height only on the first frame decoded,
> which is the first interrupt we get.
>
> So I can send out a V4L2_EVENT_SRC_CH_RESOLUTION, the last remaining
> problem is that these codecs don't support dynamically changing the
> capture buffers, so you can't do a streamoff/reqbufs/streamon on the
> capture queue without doing a full reset and losing the pending
> capture/output frames.

I believe that, if there was a resolution change, you need to do a
full reset anyway, before you can continue decoding. So it doesn't
sound like a problem. Or am I missing something?

>
> And then there's MJPEG where you just can't gather the width/height
> and must rely on userspace setting it. Also need to allocate max size
> capture buffers for that one.

I guess that could be a case for the JPEG_RAW format, which moves the
responsibility for parsing the headers and setting relevant parameters
(format, controls) to userspace.

>
> I end up needing two ENUMFMT flags:
>  - the format doesn't support V4L2_EVENT_SRC_CH_RESOLUTION
>  - the format doesn't support dynamically changing the capture buffers
> (but you can keep going with the original buffer set)
>
> Would this be okay ?

With my replies above, would you still need any of those?

Best regards,
Tomasz

>
> Regards,
> Maxime
>
> > Regards,
> >
> > Hans
> >
> > >
> > > RFC notes: This patch is motivated by the work I'm doing on the Amlogic
> > > video decoder where the firmwares allow me to support
> > > V4L2_EVENT_SRC_CH_RESOLUTION for newer formats (H.264, HEVC..) but
> > > can't support it for older ones (MPEG2, MPEG4, MJPEG..).
> > > For the latter formats, userspace is expected to set the resolution via
> > > S_FMT prior to decoding.
> > >
> > > Signed-off-by: Maxime Jourdan 
> > > ---
> > >  Documentation/media/uapi/v4l/control.rst | 7 +++
> > >  drivers/media/v4l2-core/v4l2-ctrls.c | 3 +++
> > >  include/uapi/linux/v4l2-controls.h   | 4 +++-
> > >  3 files changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/media/uapi/v4l/control.rst 
> > > b/Documentation/media/uapi/v4l/control.rst
> > > index c1e6adbe83d7..029a4e88bfd5 100644
> > > --- a/Documentation/media/uapi/v4l/control.rst
> > > +++ b/Documentation/media/uapi/v4l/control.rst
> > > @@ -297,6 +297,13 @@ Control IDs
> > >  set the alpha component value of all pixels for further processing
> > >  in the device.
> > >
> > > +``V4L2_CID_SUPPORTS_CH_RESOLUTION`` ``(boolean)``
> > > +This is a read-only control that can be read by the application when
> > > +the driver exposes an OUTPUT queue and event
> > > +``V4L2_EVENT_SRC_CH_RESOLUTION`` but doesn't support it for every
> > > +OUTPUT format. It returns true if the currently selected OUTPUT 
> > > format
> > > +supports this event.
> > > +
> > >  ``V4L2_CID_LASTP1``
> > >  End of the predefined control IDs (currently
> > >  ``V4L2_CID_ALPHA_COMPONENT`` + 1).
> > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > > index 599c1cbff3b9..a8037ff3935a 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > > @@ -739,6 +739,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > >   case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:   return "Min Number of 
> > > Output Buffers";
> > >   case V4L2_CID_ALPHA_COMPONENT:

Re: [PATCH v1 2/2] v4l: Document Intel IPU3 meta data uAPI

2018-10-04 Thread sakari.ai...@linux.intel.com

Hi Raj,

On Wed, Oct 03, 2018 at 10:56:19PM +, Mani, Rajmohan wrote:
...
> > From some comment you had later,
> > I guess you're meaning that only 3 or 7 are the valid values.
> > 
> > Yet, you're listing from 2^3 to 2^7, and that's confusing. Perhaps
> > you want to say, instead, that the valid values are at the 3..7 range?
> > If so, please use something like "values at the [3..7] range".
> > 
> 
> As Sakari pointed / preferred in the other thread, we will use the format
> [3, 7] to represent all integers between 3 and 7, including 3 and 7.

Feel free to add a reference to this in the format documentation:

https://en.wikipedia.org/wiki/Interval_(mathematics)>

I guess the right place would be the top parameter format ReST document.

...

> > > > + * All above has precision u0.4, range [0..0xF].
> > 
> > again, what do you mean by u0.4? 
> 
> unsigned integer with 0 bits used for representing whole number,
> with 4 least significant bits used to represent the fractional part.

You could refer to this:

https://en.wikipedia.org/wiki/Q_(number_format)>

The ux.y notation is more common in the context of software but I couldn't
find any decent document to refer to.

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

51 matches

Mail list logo