* [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-22 9:32 ` Yong Deng
0 siblings, 0 replies; 27+ messages in thread
From: Yong Deng @ 2017-12-22 9:32 UTC (permalink / raw)
To: "Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
David S. Miller, Greg Kroah-Hartman, Randy Dunlap, Hans Verkuil,
Stanimir Varbanov, Hugues Fruchet, Yannick Fertre, Philipp Zabel,
Arnd Bergmann, Benjamin Gaignard, Ramesh Shanmugasundaram,
Sakari Ailus, Rick Chang, linux-media, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi, Yong Deng
This patchset add initial support for Allwinner V3s CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.
This patchset implement a v4l2 framework driver and add a binding
documentation for it.
Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
- ISP
- MIPI-CSI2
- Master clock for camera sensor
- Power regulator for the front end IC
Thanks for Ondřej Jirman's help.
Changes in v4:
* Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ondřej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
* Fix: using a wrong mbus_code when getting the supported formats
* Change all fourcc to pixformat
* Change some function names
Changes in v3:
* Get rid of struct sun6i_csi_ops
* Move sun6i-csi to new directory drivers/media/platform/sunxi
* Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
* Use generic fwnode endpoints parser
* Only support a single subdev to make things simple
* Many complaintion fix
Changes in v2:
* Change sunxi-csi to sun6i-csi
* Rebase to media_tree master branch
Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:
# ./v4l2-compliance -s -f
v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
Driver Info:
Driver name : sun6i-video
Card type : sun6i-csi
Bus info : platform:csi
Driver version: 4.15.0
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video 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
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 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)
Test input 0:
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 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 (Not Supported)
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 MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Stream using all formats:
test MMAP for Format HM12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV21, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YU12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV16, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format NV61, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format 422P, Frame Size 1280x720:
Stride 2560, Field None: OK
Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
Yong Deng (2):
dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
media: V3s: Add support for Allwinner CSI.
.../devicetree/bindings/media/sun6i-csi.txt | 51 ++
MAINTAINERS | 8 +
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
.../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
11 files changed, 2114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
--
1.8.3.1
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-22 9:32 ` Yong Deng
0 siblings, 0 replies; 27+ messages in thread
From: Yong Deng @ 2017-12-22 9:32 UTC (permalink / raw)
To: "Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
David S. Miller, Greg Kroah-Hartman, Randy Dunlap, Hans Verkuil,
Stanimir Varbanov, Hugues Fruchet, Yannick Fertre, Philipp Zabel,
Arnd Bergmann, Benjamin Gaignard, Ramesh Shanmugasundaram,
Sakari Ailus, Rick Chang, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Yong
This patchset add initial support for Allwinner V3s CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.
This patchset implement a v4l2 framework driver and add a binding
documentation for it.
Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
- ISP
- MIPI-CSI2
- Master clock for camera sensor
- Power regulator for the front end IC
Thanks for Ondřej Jirman's help.
Changes in v4:
* Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ondřej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
* Fix: using a wrong mbus_code when getting the supported formats
* Change all fourcc to pixformat
* Change some function names
Changes in v3:
* Get rid of struct sun6i_csi_ops
* Move sun6i-csi to new directory drivers/media/platform/sunxi
* Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
* Use generic fwnode endpoints parser
* Only support a single subdev to make things simple
* Many complaintion fix
Changes in v2:
* Change sunxi-csi to sun6i-csi
* Rebase to media_tree master branch
Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:
# ./v4l2-compliance -s -f
v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
Driver Info:
Driver name : sun6i-video
Card type : sun6i-csi
Bus info : platform:csi
Driver version: 4.15.0
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video 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
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 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)
Test input 0:
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 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 (Not Supported)
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 MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Stream using all formats:
test MMAP for Format HM12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV21, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YU12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV16, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format NV61, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format 422P, Frame Size 1280x720:
Stride 2560, Field None: OK
Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
Yong Deng (2):
dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
media: V3s: Add support for Allwinner CSI.
.../devicetree/bindings/media/sun6i-csi.txt | 51 ++
MAINTAINERS | 8 +
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
.../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
11 files changed, 2114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
--
1.8.3.1
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-22 9:32 ` Yong Deng
0 siblings, 0 replies; 27+ messages in thread
From: Yong Deng @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
This patchset add initial support for Allwinner V3s CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.
This patchset implement a v4l2 framework driver and add a binding
documentation for it.
Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
- ISP
- MIPI-CSI2
- Master clock for camera sensor
- Power regulator for the front end IC
Thanks for Ond?ej Jirman's help.
Changes in v4:
* Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ond?ej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
* Fix: using a wrong mbus_code when getting the supported formats
* Change all fourcc to pixformat
* Change some function names
Changes in v3:
* Get rid of struct sun6i_csi_ops
* Move sun6i-csi to new directory drivers/media/platform/sunxi
* Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
* Use generic fwnode endpoints parser
* Only support a single subdev to make things simple
* Many complaintion fix
Changes in v2:
* Change sunxi-csi to sun6i-csi
* Rebase to media_tree master branch
Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:
# ./v4l2-compliance -s -f
v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
Driver Info:
Driver name : sun6i-video
Card type : sun6i-csi
Bus info : platform:csi
Driver version: 4.15.0
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video 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
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 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)
Test input 0:
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 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 (Not Supported)
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 MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Stream using all formats:
test MMAP for Format HM12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV21, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YU12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV16, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format NV61, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format 422P, Frame Size 1280x720:
Stride 2560, Field None: OK
Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
Yong Deng (2):
dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
media: V3s: Add support for Allwinner CSI.
.../devicetree/bindings/media/sun6i-csi.txt | 51 ++
MAINTAINERS | 8 +
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
.../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
11 files changed, 2114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
--
1.8.3.1
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-22 13:46 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: Ondřej Jirman @ 2017-12-22 13:46 UTC (permalink / raw)
To: yong.deng, "Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
David S. Miller, Greg Kroah-Hartman, Randy Dunlap, Hans Verkuil,
Stanimir Varbanov, Hugues Fruchet, Yannick Fertre, Philipp Zabel,
Arnd Bergmann, Benjamin Gaignard, Ramesh Shanmugasundaram,
Sakari Ailus, Rick Chang, linux-media, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 9601 bytes --]
Hello,
Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> This patchset add initial support for Allwinner V3s CSI.
>
> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
>
> This patchset implement a v4l2 framework driver and add a binding
> documentation for it.
>
> Currently, the driver only support the parallel interface. And has been
> tested with a BT1120 signal which generating from FPGA. The following
> fetures are not support with this patchset:
> - ISP
> - MIPI-CSI2
> - Master clock for camera sensor
> - Power regulator for the front end IC
>
> Thanks for Ondřej Jirman's help.
>
> Changes in v4:
> * Deal with the CSI 'INNER QUEUE'.
> CSI will lookup the next dma buffer for next frame before the
> the current frame done IRQ triggered. This is not documented
> but reported by Ondřej Jirman.
> The BSP code has workaround for this too. It skip to mark the
> first buffer as frame done for VB2 and pass the second buffer
> to CSI in the first frame done ISR call. Then in second frame
> done ISR call, it mark the first buffer as frame done for VB2
> and pass the third buffer to CSI. And so on. The bad thing is
> that the first buffer will be written twice and the first frame
> is dropped even the queued buffer is sufficient.
> So, I make some improvement here. Pass the next buffer to CSI
> just follow starting the CSI. In this case, the first frame
> will be stored in first buffer, second frame in second buffer.
> This mothed is used to avoid dropping the first frame, it
> would also drop frame when lacking of queued buffer.
> * Fix: using a wrong mbus_code when getting the supported formats
> * Change all fourcc to pixformat
> * Change some function names
>
> Changes in v3:
> * Get rid of struct sun6i_csi_ops
> * Move sun6i-csi to new directory drivers/media/platform/sunxi
> * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> * Use generic fwnode endpoints parser
> * Only support a single subdev to make things simple
> * Many complaintion fix
>
> Changes in v2:
> * Change sunxi-csi to sun6i-csi
> * Rebase to media_tree master branch
>
> Following is the 'v4l2-compliance -s -f' output, I have test this
> with both interlaced and progressive signal:
>
> # ./v4l2-compliance -s -f
> v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
>
> Driver Info:
> Driver name : sun6i-video
> Card type : sun6i-csi
> Bus info : platform:csi
> Driver version: 4.15.0
> Capabilities : 0x84200001
> Video Capture
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x04200001
> Video Capture
> Streaming
> Extended Pix Format
>
> Compliance test for device /dev/video0 (not using libv4l2):
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
>
> Allow for multiple opens:
> test second video 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
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 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)
>
> Test input 0:
>
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0
I'm not sure if your driver passes control queries to the subdev. It
did not originally, and I'm not sure you picked up the change from my
version of the driver. "Not supported" here seems to indicate that it
does not.
I'd be interested what's the recommended practice here. It sure helps
with some apps that expect to be able to modify various input controls
directly on the /dev/video# device. These are then supported out of the
box.
It's a one-line change. See:
https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
heriting-controls
> 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 (Not Supported)
>
> 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 MMAP: OK
> test USERPTR: OK (Not Supported)
> test DMABUF: Cannot test, specify --expbuf-device
>
> Stream using all formats:
> test MMAP for Format HM12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV21, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format YU12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format YV12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV16, Frame Size 1280x720:
> Stride 2560, Field None: OK
> test MMAP for Format NV61, Frame Size 1280x720:
> Stride 2560, Field None: OK
> test MMAP for Format 422P, Frame Size 1280x720:
> Stride 2560, Field None: OK
>
> Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
>
> Yong Deng (2):
> dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
> media: V3s: Add support for Allwinner CSI.
>
> .../devicetree/bindings/media/sun6i-csi.txt | 51 ++
> MAINTAINERS | 8 +
> drivers/media/platform/Kconfig | 1 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
> drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
> .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
> .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
> .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
> 11 files changed, 2114 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
>
> --
> 1.8.3.1
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-22 13:46 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: 'Ondřej Jirman' via linux-sunxi @ 2017-12-22 13:46 UTC (permalink / raw)
To: yong.deng-+3dxTMOEIRNWk0Htik3J/w, "Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
David S. Miller, Greg Kroah-Hartman, Randy Dunlap, Hans Verkuil,
Stanimir Varbanov, Hugues Fruchet, Yannick Fertre, Philipp Zabel,
Arnd Bergmann, Benjamin Gaignard, Ramesh Shanmugasundaram,
Sakari Ailus, Rick Chang, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 9925 bytes --]
Hello,
Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> This patchset add initial support for Allwinner V3s CSI.
>
> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
>
> This patchset implement a v4l2 framework driver and add a binding
> documentation for it.
>
> Currently, the driver only support the parallel interface. And has been
> tested with a BT1120 signal which generating from FPGA. The following
> fetures are not support with this patchset:
> - ISP
> - MIPI-CSI2
> - Master clock for camera sensor
> - Power regulator for the front end IC
>
> Thanks for Ondřej Jirman's help.
>
> Changes in v4:
> * Deal with the CSI 'INNER QUEUE'.
> CSI will lookup the next dma buffer for next frame before the
> the current frame done IRQ triggered. This is not documented
> but reported by Ondřej Jirman.
> The BSP code has workaround for this too. It skip to mark the
> first buffer as frame done for VB2 and pass the second buffer
> to CSI in the first frame done ISR call. Then in second frame
> done ISR call, it mark the first buffer as frame done for VB2
> and pass the third buffer to CSI. And so on. The bad thing is
> that the first buffer will be written twice and the first frame
> is dropped even the queued buffer is sufficient.
> So, I make some improvement here. Pass the next buffer to CSI
> just follow starting the CSI. In this case, the first frame
> will be stored in first buffer, second frame in second buffer.
> This mothed is used to avoid dropping the first frame, it
> would also drop frame when lacking of queued buffer.
> * Fix: using a wrong mbus_code when getting the supported formats
> * Change all fourcc to pixformat
> * Change some function names
>
> Changes in v3:
> * Get rid of struct sun6i_csi_ops
> * Move sun6i-csi to new directory drivers/media/platform/sunxi
> * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> * Use generic fwnode endpoints parser
> * Only support a single subdev to make things simple
> * Many complaintion fix
>
> Changes in v2:
> * Change sunxi-csi to sun6i-csi
> * Rebase to media_tree master branch
>
> Following is the 'v4l2-compliance -s -f' output, I have test this
> with both interlaced and progressive signal:
>
> # ./v4l2-compliance -s -f
> v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
>
> Driver Info:
> Driver name : sun6i-video
> Card type : sun6i-csi
> Bus info : platform:csi
> Driver version: 4.15.0
> Capabilities : 0x84200001
> Video Capture
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x04200001
> Video Capture
> Streaming
> Extended Pix Format
>
> Compliance test for device /dev/video0 (not using libv4l2):
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
>
> Allow for multiple opens:
> test second video 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
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 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)
>
> Test input 0:
>
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0
I'm not sure if your driver passes control queries to the subdev. It
did not originally, and I'm not sure you picked up the change from my
version of the driver. "Not supported" here seems to indicate that it
does not.
I'd be interested what's the recommended practice here. It sure helps
with some apps that expect to be able to modify various input controls
directly on the /dev/video# device. These are then supported out of the
box.
It's a one-line change. See:
https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
heriting-controls
> 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 (Not Supported)
>
> 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 MMAP: OK
> test USERPTR: OK (Not Supported)
> test DMABUF: Cannot test, specify --expbuf-device
>
> Stream using all formats:
> test MMAP for Format HM12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV21, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format YU12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format YV12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV16, Frame Size 1280x720:
> Stride 2560, Field None: OK
> test MMAP for Format NV61, Frame Size 1280x720:
> Stride 2560, Field None: OK
> test MMAP for Format 422P, Frame Size 1280x720:
> Stride 2560, Field None: OK
>
> Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
>
> Yong Deng (2):
> dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
> media: V3s: Add support for Allwinner CSI.
>
> .../devicetree/bindings/media/sun6i-csi.txt | 51 ++
> MAINTAINERS | 8 +
> drivers/media/platform/Kconfig | 1 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
> drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
> .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
> .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
> .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
> 11 files changed, 2114 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
>
> --
> 1.8.3.1
>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-22 13:46 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: Ondřej Jirman @ 2017-12-22 13:46 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> This patchset add initial support for Allwinner V3s CSI.
>
> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
>
> This patchset implement a v4l2 framework driver and add a binding
> documentation for it.
>
> Currently, the driver only support the parallel interface. And has been
> tested with a BT1120 signal which generating from FPGA. The following
> fetures are not support with this patchset:
> - ISP
> - MIPI-CSI2
> - Master clock for camera sensor
> - Power regulator for the front end IC
>
> Thanks for Ond?ej Jirman's help.
>
> Changes in v4:
> * Deal with the CSI 'INNER QUEUE'.
> CSI will lookup the next dma buffer for next frame before the
> the current frame done IRQ triggered. This is not documented
> but reported by Ond?ej Jirman.
> The BSP code has workaround for this too. It skip to mark the
> first buffer as frame done for VB2 and pass the second buffer
> to CSI in the first frame done ISR call. Then in second frame
> done ISR call, it mark the first buffer as frame done for VB2
> and pass the third buffer to CSI. And so on. The bad thing is
> that the first buffer will be written twice and the first frame
> is dropped even the queued buffer is sufficient.
> So, I make some improvement here. Pass the next buffer to CSI
> just follow starting the CSI. In this case, the first frame
> will be stored in first buffer, second frame in second buffer.
> This mothed is used to avoid dropping the first frame, it
> would also drop frame when lacking of queued buffer.
> * Fix: using a wrong mbus_code when getting the supported formats
> * Change all fourcc to pixformat
> * Change some function names
>
> Changes in v3:
> * Get rid of struct sun6i_csi_ops
> * Move sun6i-csi to new directory drivers/media/platform/sunxi
> * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> * Use generic fwnode endpoints parser
> * Only support a single subdev to make things simple
> * Many complaintion fix
>
> Changes in v2:
> * Change sunxi-csi to sun6i-csi
> * Rebase to media_tree master branch
>
> Following is the 'v4l2-compliance -s -f' output, I have test this
> with both interlaced and progressive signal:
>
> # ./v4l2-compliance -s -f
> v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
>
> Driver Info:
> Driver name : sun6i-video
> Card type : sun6i-csi
> Bus info : platform:csi
> Driver version: 4.15.0
> Capabilities : 0x84200001
> Video Capture
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x04200001
> Video Capture
> Streaming
> Extended Pix Format
>
> Compliance test for device /dev/video0 (not using libv4l2):
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
>
> Allow for multiple opens:
> test second video 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
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 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)
>
> Test input 0:
>
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0
I'm not sure if your driver passes control queries to the subdev. It
did not originally, and I'm not sure you picked up the change from my
version of the driver. "Not supported" here seems to indicate that it
does not.
I'd be interested what's the recommended practice here. It sure helps
with some apps that expect to be able to modify various input controls
directly on the /dev/video# device. These are then supported out of the
box.
It's a one-line change. See:
https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
heriting-controls
> 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 (Not Supported)
>
> 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 MMAP: OK
> test USERPTR: OK (Not Supported)
> test DMABUF: Cannot test, specify --expbuf-device
>
> Stream using all formats:
> test MMAP for Format HM12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV21, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format YU12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format YV12, Frame Size 1280x720:
> Stride 1920, Field None: OK
> test MMAP for Format NV16, Frame Size 1280x720:
> Stride 2560, Field None: OK
> test MMAP for Format NV61, Frame Size 1280x720:
> Stride 2560, Field None: OK
> test MMAP for Format 422P, Frame Size 1280x720:
> Stride 2560, Field None: OK
>
> Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
>
> Yong Deng (2):
> dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
> media: V3s: Add support for Allwinner CSI.
>
> .../devicetree/bindings/media/sun6i-csi.txt | 51 ++
> MAINTAINERS | 8 +
> drivers/media/platform/Kconfig | 1 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
> drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
> .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
> .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
> .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
> 11 files changed, 2114 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
>
> --
> 1.8.3.1
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171222/b8debf28/attachment-0001.sig>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-25 3:15 ` Yong
0 siblings, 0 replies; 27+ messages in thread
From: Yong @ 2017-12-25 3:15 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Maxime Ripard, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang, linux-media,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
Hi,
On Fri, 22 Dec 2017 14:46:48 +0100
Ondřej Jirman <megous@megous.com> wrote:
> Hello,
>
> Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > This patchset add initial support for Allwinner V3s CSI.
> >
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> >
> > This patchset implement a v4l2 framework driver and add a binding
> > documentation for it.
> >
> > Currently, the driver only support the parallel interface. And has been
> > tested with a BT1120 signal which generating from FPGA. The following
> > fetures are not support with this patchset:
> > - ISP
> > - MIPI-CSI2
> > - Master clock for camera sensor
> > - Power regulator for the front end IC
> >
> > Thanks for Ondřej Jirman's help.
> >
> > Changes in v4:
> > * Deal with the CSI 'INNER QUEUE'.
> > CSI will lookup the next dma buffer for next frame before the
> > the current frame done IRQ triggered. This is not documented
> > but reported by Ondřej Jirman.
> > The BSP code has workaround for this too. It skip to mark the
> > first buffer as frame done for VB2 and pass the second buffer
> > to CSI in the first frame done ISR call. Then in second frame
> > done ISR call, it mark the first buffer as frame done for VB2
> > and pass the third buffer to CSI. And so on. The bad thing is
> > that the first buffer will be written twice and the first frame
> > is dropped even the queued buffer is sufficient.
> > So, I make some improvement here. Pass the next buffer to CSI
> > just follow starting the CSI. In this case, the first frame
> > will be stored in first buffer, second frame in second buffer.
> > This mothed is used to avoid dropping the first frame, it
> > would also drop frame when lacking of queued buffer.
> > * Fix: using a wrong mbus_code when getting the supported formats
> > * Change all fourcc to pixformat
> > * Change some function names
> >
> > Changes in v3:
> > * Get rid of struct sun6i_csi_ops
> > * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > * Use generic fwnode endpoints parser
> > * Only support a single subdev to make things simple
> > * Many complaintion fix
> >
> > Changes in v2:
> > * Change sunxi-csi to sun6i-csi
> > * Rebase to media_tree master branch
> >
> > Following is the 'v4l2-compliance -s -f' output, I have test this
> > with both interlaced and progressive signal:
> >
> > # ./v4l2-compliance -s -f
> > v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> >
> > Driver Info:
> > Driver name : sun6i-video
> > Card type : sun6i-csi
> > Bus info : platform:csi
> > Driver version: 4.15.0
> > Capabilities : 0x84200001
> > Video Capture
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04200001
> > Video Capture
> > Streaming
> > Extended Pix Format
> >
> > Compliance test for device /dev/video0 (not using libv4l2):
> >
> > Required ioctls:
> > test VIDIOC_QUERYCAP: OK
> >
> > Allow for multiple opens:
> > test second video 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
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 1 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)
> >
> > Test input 0:
> >
> > Control ioctls:
> > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > Standard Controls: 0 Private Controls: 0
>
> I'm not sure if your driver passes control queries to the subdev. It
> did not originally, and I'm not sure you picked up the change from my
> version of the driver. "Not supported" here seems to indicate that it
> does not.
>
> I'd be interested what's the recommended practice here. It sure helps
> with some apps that expect to be able to modify various input controls
> directly on the /dev/video# device. These are then supported out of the
> box.
>
> It's a one-line change. See:
>
> https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> heriting-controls
I think this is a feature and not affect the driver's main function.
I just focused on making the CSI main function to work properly in
the initial version. Is this feature mandatory or most commonly used?
>
> > 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 (Not Supported)
> >
> > 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 MMAP: OK
> > test USERPTR: OK (Not Supported)
> > test DMABUF: Cannot test, specify --expbuf-device
> >
> > Stream using all formats:
> > test MMAP for Format HM12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV21, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format YU12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format YV12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV16, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> > test MMAP for Format NV61, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> > test MMAP for Format 422P, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> >
> > Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
> >
> > Yong Deng (2):
> > dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
> > media: V3s: Add support for Allwinner CSI.
> >
> > .../devicetree/bindings/media/sun6i-csi.txt | 51 ++
> > MAINTAINERS | 8 +
> > drivers/media/platform/Kconfig | 1 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
> > drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
> > 11 files changed, 2114 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
> >
> > --
> > 1.8.3.1
> >
Thanks,
Yong
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-25 3:15 ` Yong
0 siblings, 0 replies; 27+ messages in thread
From: Yong @ 2017-12-25 3:15 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Maxime Ripard, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TasMV2rI37PzA
Hi,
On Fri, 22 Dec 2017 14:46:48 +0100
Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> Hello,
>
> Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > This patchset add initial support for Allwinner V3s CSI.
> >
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> >
> > This patchset implement a v4l2 framework driver and add a binding
> > documentation for it.
> >
> > Currently, the driver only support the parallel interface. And has been
> > tested with a BT1120 signal which generating from FPGA. The following
> > fetures are not support with this patchset:
> > - ISP
> > - MIPI-CSI2
> > - Master clock for camera sensor
> > - Power regulator for the front end IC
> >
> > Thanks for Ondřej Jirman's help.
> >
> > Changes in v4:
> > * Deal with the CSI 'INNER QUEUE'.
> > CSI will lookup the next dma buffer for next frame before the
> > the current frame done IRQ triggered. This is not documented
> > but reported by Ondřej Jirman.
> > The BSP code has workaround for this too. It skip to mark the
> > first buffer as frame done for VB2 and pass the second buffer
> > to CSI in the first frame done ISR call. Then in second frame
> > done ISR call, it mark the first buffer as frame done for VB2
> > and pass the third buffer to CSI. And so on. The bad thing is
> > that the first buffer will be written twice and the first frame
> > is dropped even the queued buffer is sufficient.
> > So, I make some improvement here. Pass the next buffer to CSI
> > just follow starting the CSI. In this case, the first frame
> > will be stored in first buffer, second frame in second buffer.
> > This mothed is used to avoid dropping the first frame, it
> > would also drop frame when lacking of queued buffer.
> > * Fix: using a wrong mbus_code when getting the supported formats
> > * Change all fourcc to pixformat
> > * Change some function names
> >
> > Changes in v3:
> > * Get rid of struct sun6i_csi_ops
> > * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > * Use generic fwnode endpoints parser
> > * Only support a single subdev to make things simple
> > * Many complaintion fix
> >
> > Changes in v2:
> > * Change sunxi-csi to sun6i-csi
> > * Rebase to media_tree master branch
> >
> > Following is the 'v4l2-compliance -s -f' output, I have test this
> > with both interlaced and progressive signal:
> >
> > # ./v4l2-compliance -s -f
> > v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> >
> > Driver Info:
> > Driver name : sun6i-video
> > Card type : sun6i-csi
> > Bus info : platform:csi
> > Driver version: 4.15.0
> > Capabilities : 0x84200001
> > Video Capture
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04200001
> > Video Capture
> > Streaming
> > Extended Pix Format
> >
> > Compliance test for device /dev/video0 (not using libv4l2):
> >
> > Required ioctls:
> > test VIDIOC_QUERYCAP: OK
> >
> > Allow for multiple opens:
> > test second video 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
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 1 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)
> >
> > Test input 0:
> >
> > Control ioctls:
> > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > Standard Controls: 0 Private Controls: 0
>
> I'm not sure if your driver passes control queries to the subdev. It
> did not originally, and I'm not sure you picked up the change from my
> version of the driver. "Not supported" here seems to indicate that it
> does not.
>
> I'd be interested what's the recommended practice here. It sure helps
> with some apps that expect to be able to modify various input controls
> directly on the /dev/video# device. These are then supported out of the
> box.
>
> It's a one-line change. See:
>
> https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> heriting-controls
I think this is a feature and not affect the driver's main function.
I just focused on making the CSI main function to work properly in
the initial version. Is this feature mandatory or most commonly used?
>
> > 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 (Not Supported)
> >
> > 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 MMAP: OK
> > test USERPTR: OK (Not Supported)
> > test DMABUF: Cannot test, specify --expbuf-device
> >
> > Stream using all formats:
> > test MMAP for Format HM12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV21, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format YU12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format YV12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV16, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> > test MMAP for Format NV61, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> > test MMAP for Format 422P, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> >
> > Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
> >
> > Yong Deng (2):
> > dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
> > media: V3s: Add support for Allwinner CSI.
> >
> > .../devicetree/bindings/media/sun6i-csi.txt | 51 ++
> > MAINTAINERS | 8 +
> > drivers/media/platform/Kconfig | 1 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
> > drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
> > 11 files changed, 2114 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
> >
> > --
> > 1.8.3.1
> >
Thanks,
Yong
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-25 3:15 ` Yong
0 siblings, 0 replies; 27+ messages in thread
From: Yong @ 2017-12-25 3:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, 22 Dec 2017 14:46:48 +0100
Ond?ej Jirman <megous@megous.com> wrote:
> Hello,
>
> Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > This patchset add initial support for Allwinner V3s CSI.
> >
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> >
> > This patchset implement a v4l2 framework driver and add a binding
> > documentation for it.
> >
> > Currently, the driver only support the parallel interface. And has been
> > tested with a BT1120 signal which generating from FPGA. The following
> > fetures are not support with this patchset:
> > - ISP
> > - MIPI-CSI2
> > - Master clock for camera sensor
> > - Power regulator for the front end IC
> >
> > Thanks for Ond?ej Jirman's help.
> >
> > Changes in v4:
> > * Deal with the CSI 'INNER QUEUE'.
> > CSI will lookup the next dma buffer for next frame before the
> > the current frame done IRQ triggered. This is not documented
> > but reported by Ond?ej Jirman.
> > The BSP code has workaround for this too. It skip to mark the
> > first buffer as frame done for VB2 and pass the second buffer
> > to CSI in the first frame done ISR call. Then in second frame
> > done ISR call, it mark the first buffer as frame done for VB2
> > and pass the third buffer to CSI. And so on. The bad thing is
> > that the first buffer will be written twice and the first frame
> > is dropped even the queued buffer is sufficient.
> > So, I make some improvement here. Pass the next buffer to CSI
> > just follow starting the CSI. In this case, the first frame
> > will be stored in first buffer, second frame in second buffer.
> > This mothed is used to avoid dropping the first frame, it
> > would also drop frame when lacking of queued buffer.
> > * Fix: using a wrong mbus_code when getting the supported formats
> > * Change all fourcc to pixformat
> > * Change some function names
> >
> > Changes in v3:
> > * Get rid of struct sun6i_csi_ops
> > * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > * Use generic fwnode endpoints parser
> > * Only support a single subdev to make things simple
> > * Many complaintion fix
> >
> > Changes in v2:
> > * Change sunxi-csi to sun6i-csi
> > * Rebase to media_tree master branch
> >
> > Following is the 'v4l2-compliance -s -f' output, I have test this
> > with both interlaced and progressive signal:
> >
> > # ./v4l2-compliance -s -f
> > v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> >
> > Driver Info:
> > Driver name : sun6i-video
> > Card type : sun6i-csi
> > Bus info : platform:csi
> > Driver version: 4.15.0
> > Capabilities : 0x84200001
> > Video Capture
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04200001
> > Video Capture
> > Streaming
> > Extended Pix Format
> >
> > Compliance test for device /dev/video0 (not using libv4l2):
> >
> > Required ioctls:
> > test VIDIOC_QUERYCAP: OK
> >
> > Allow for multiple opens:
> > test second video 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
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 1 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)
> >
> > Test input 0:
> >
> > Control ioctls:
> > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > Standard Controls: 0 Private Controls: 0
>
> I'm not sure if your driver passes control queries to the subdev. It
> did not originally, and I'm not sure you picked up the change from my
> version of the driver. "Not supported" here seems to indicate that it
> does not.
>
> I'd be interested what's the recommended practice here. It sure helps
> with some apps that expect to be able to modify various input controls
> directly on the /dev/video# device. These are then supported out of the
> box.
>
> It's a one-line change. See:
>
> https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> heriting-controls
I think this is a feature and not affect the driver's main function.
I just focused on making the CSI main function to work properly in
the initial version. Is this feature mandatory or most commonly used?
>
> > 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 (Not Supported)
> >
> > 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 MMAP: OK
> > test USERPTR: OK (Not Supported)
> > test DMABUF: Cannot test, specify --expbuf-device
> >
> > Stream using all formats:
> > test MMAP for Format HM12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV21, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format YU12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format YV12, Frame Size 1280x720:
> > Stride 1920, Field None: OK
> > test MMAP for Format NV16, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> > test MMAP for Format NV61, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> > test MMAP for Format 422P, Frame Size 1280x720:
> > Stride 2560, Field None: OK
> >
> > Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
> >
> > Yong Deng (2):
> > dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
> > media: V3s: Add support for Allwinner CSI.
> >
> > .../devicetree/bindings/media/sun6i-csi.txt | 51 ++
> > MAINTAINERS | 8 +
> > drivers/media/platform/Kconfig | 1 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
> > drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
> > 11 files changed, 2114 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
> >
> > --
> > 1.8.3.1
> >
Thanks,
Yong
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-25 8:58 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: Ondřej Jirman @ 2017-12-25 8:58 UTC (permalink / raw)
To: Yong
Cc: Maxime Ripard, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang, linux-media,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]
Hello,
On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
>
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ondřej Jirman <megous@megous.com> wrote:
>
> > Hello,
> >
> > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > >
> > > Test input 0:
> > >
> > > Control ioctls:
> > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > Standard Controls: 0 Private Controls: 0
> >
> > I'm not sure if your driver passes control queries to the subdev. It
> > did not originally, and I'm not sure you picked up the change from my
> > version of the driver. "Not supported" here seems to indicate that it
> > does not.
> >
> > I'd be interested what's the recommended practice here. It sure helps
> > with some apps that expect to be able to modify various input controls
> > directly on the /dev/video# device. These are then supported out of the
> > box.
> >
> > It's a one-line change. See:
> >
> > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > heriting-controls
>
> I think this is a feature and not affect the driver's main function.
> I just focused on making the CSI main function to work properly in
> the initial version. Is this feature mandatory or most commonly used?
I grepped the platform/ code and it seems, that inheriting controls
from subdevs is pretty common for input drivers. (there are varying
approaches though, some inherit by hand in the link function, some
just register and empty ctrl_handler on the v4l2_dev and leave the
rest to the core).
Practically, I haven't found a common app that would allow me to enter
both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
themselves, but it would be better if current controls were available
at the /dev/video0 device automatically.
It's much simpler for the userspace apps than the alternative, which
is trying to identify the correct subdev that is currently
associated with the CSI driver at runtime, which is not exactly
straightforward and requires much more code, than a few lines in
the kernel, that are required to inherit controls:
ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 0);
if (ret) {
dev_err(csi->dev,
"V4L2 controls handler init failed (%d)\n",
ret);
goto handle_error;
}
csi->v4l2_dev.ctrl_handler = &csi->ctrl_handler;
See: https://github.com/megous/linux/blob/linux-tbs/drivers/media/platform/sun6i-csi/sun6i_csi.c#L1005
regards,
o.j.
> Thanks,
> Yong
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-25 8:58 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: 'Ondřej Jirman' via linux-sunxi @ 2017-12-25 8:58 UTC (permalink / raw)
To: Yong
Cc: Maxime Ripard, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY
[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]
Hello,
On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
>
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
>
> > Hello,
> >
> > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > >
> > > Test input 0:
> > >
> > > Control ioctls:
> > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > Standard Controls: 0 Private Controls: 0
> >
> > I'm not sure if your driver passes control queries to the subdev. It
> > did not originally, and I'm not sure you picked up the change from my
> > version of the driver. "Not supported" here seems to indicate that it
> > does not.
> >
> > I'd be interested what's the recommended practice here. It sure helps
> > with some apps that expect to be able to modify various input controls
> > directly on the /dev/video# device. These are then supported out of the
> > box.
> >
> > It's a one-line change. See:
> >
> > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > heriting-controls
>
> I think this is a feature and not affect the driver's main function.
> I just focused on making the CSI main function to work properly in
> the initial version. Is this feature mandatory or most commonly used?
I grepped the platform/ code and it seems, that inheriting controls
from subdevs is pretty common for input drivers. (there are varying
approaches though, some inherit by hand in the link function, some
just register and empty ctrl_handler on the v4l2_dev and leave the
rest to the core).
Practically, I haven't found a common app that would allow me to enter
both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
themselves, but it would be better if current controls were available
at the /dev/video0 device automatically.
It's much simpler for the userspace apps than the alternative, which
is trying to identify the correct subdev that is currently
associated with the CSI driver at runtime, which is not exactly
straightforward and requires much more code, than a few lines in
the kernel, that are required to inherit controls:
ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 0);
if (ret) {
dev_err(csi->dev,
"V4L2 controls handler init failed (%d)\n",
ret);
goto handle_error;
}
csi->v4l2_dev.ctrl_handler = &csi->ctrl_handler;
See: https://github.com/megous/linux/blob/linux-tbs/drivers/media/platform/sun6i-csi/sun6i_csi.c#L1005
regards,
o.j.
> Thanks,
> Yong
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-25 8:58 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: Ondřej Jirman @ 2017-12-25 8:58 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
>
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ond?ej Jirman <megous@megous.com> wrote:
>
> > Hello,
> >
> > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > >
> > > Test input 0:
> > >
> > > Control ioctls:
> > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > Standard Controls: 0 Private Controls: 0
> >
> > I'm not sure if your driver passes control queries to the subdev. It
> > did not originally, and I'm not sure you picked up the change from my
> > version of the driver. "Not supported" here seems to indicate that it
> > does not.
> >
> > I'd be interested what's the recommended practice here. It sure helps
> > with some apps that expect to be able to modify various input controls
> > directly on the /dev/video# device. These are then supported out of the
> > box.
> >
> > It's a one-line change. See:
> >
> > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > heriting-controls
>
> I think this is a feature and not affect the driver's main function.
> I just focused on making the CSI main function to work properly in
> the initial version. Is this feature mandatory or most commonly used?
I grepped the platform/ code and it seems, that inheriting controls
from subdevs is pretty common for input drivers. (there are varying
approaches though, some inherit by hand in the link function, some
just register and empty ctrl_handler on the v4l2_dev and leave the
rest to the core).
Practically, I haven't found a common app that would allow me to enter
both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
themselves, but it would be better if current controls were available
at the /dev/video0 device automatically.
It's much simpler for the userspace apps than the alternative, which
is trying to identify the correct subdev that is currently
associated with the CSI driver at runtime, which is not exactly
straightforward and requires much more code, than a few lines in
the kernel, that are required to inherit controls:
ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 0);
if (ret) {
dev_err(csi->dev,
"V4L2 controls handler init failed (%d)\n",
ret);
goto handle_error;
}
csi->v4l2_dev.ctrl_handler = &csi->ctrl_handler;
See: https://github.com/megous/linux/blob/linux-tbs/drivers/media/platform/sun6i-csi/sun6i_csi.c#L1005
regards,
o.j.
> Thanks,
> Yong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171225/7b9c0415/attachment.sig>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-26 0:56 ` Yong
0 siblings, 0 replies; 27+ messages in thread
From: Yong @ 2017-12-26 0:56 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Maxime Ripard, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang, linux-media,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
On Mon, 25 Dec 2017 09:58:02 +0100
Ondřej Jirman <megous@megous.com> wrote:
> Hello,
>
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> >
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ondřej Jirman <megous@megous.com> wrote:
> >
> > > Hello,
> > >
> > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > >
> > > > Test input 0:
> > > >
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > >
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > >
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > >
> > > It's a one-line change. See:
> > >
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> >
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in
> > the initial version. Is this feature mandatory or most commonly used?
>
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
>
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
>
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:
>
>
> ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 0);
> if (ret) {
> dev_err(csi->dev,
> "V4L2 controls handler init failed (%d)\n",
> ret);
> goto handle_error;
> }
>
> csi->v4l2_dev.ctrl_handler = &csi->ctrl_handler;
>
> See: https://github.com/megous/linux/blob/linux-tbs/drivers/media/platform/sun6i-csi/sun6i_csi.c#L1005
Ok, I will add this. Thanks for your explication.
>
> regards,
> o.j.
>
> > Thanks,
> > Yong
Thanks,
Yong
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-26 0:56 ` Yong
0 siblings, 0 replies; 27+ messages in thread
From: Yong @ 2017-12-26 0:56 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Maxime Ripard, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TaqPxH82wqD4g
On Mon, 25 Dec 2017 09:58:02 +0100
Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> Hello,
>
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> >
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> >
> > > Hello,
> > >
> > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > >
> > > > Test input 0:
> > > >
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > >
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > >
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > >
> > > It's a one-line change. See:
> > >
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> >
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in
> > the initial version. Is this feature mandatory or most commonly used?
>
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
>
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
>
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:
>
>
> ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 0);
> if (ret) {
> dev_err(csi->dev,
> "V4L2 controls handler init failed (%d)\n",
> ret);
> goto handle_error;
> }
>
> csi->v4l2_dev.ctrl_handler = &csi->ctrl_handler;
>
> See: https://github.com/megous/linux/blob/linux-tbs/drivers/media/platform/sun6i-csi/sun6i_csi.c#L1005
Ok, I will add this. Thanks for your explication.
>
> regards,
> o.j.
>
> > Thanks,
> > Yong
Thanks,
Yong
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2017-12-26 0:56 ` Yong
0 siblings, 0 replies; 27+ messages in thread
From: Yong @ 2017-12-26 0:56 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 25 Dec 2017 09:58:02 +0100
Ond?ej Jirman <megous@megous.com> wrote:
> Hello,
>
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> >
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ond?ej Jirman <megous@megous.com> wrote:
> >
> > > Hello,
> > >
> > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > >
> > > > Test input 0:
> > > >
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > >
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > >
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > >
> > > It's a one-line change. See:
> > >
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> >
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in
> > the initial version. Is this feature mandatory or most commonly used?
>
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
>
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
>
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:
>
>
> ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 0);
> if (ret) {
> dev_err(csi->dev,
> "V4L2 controls handler init failed (%d)\n",
> ret);
> goto handle_error;
> }
>
> csi->v4l2_dev.ctrl_handler = &csi->ctrl_handler;
>
> See: https://github.com/megous/linux/blob/linux-tbs/drivers/media/platform/sun6i-csi/sun6i_csi.c#L1005
Ok, I will add this. Thanks for your explication.
>
> regards,
> o.j.
>
> > Thanks,
> > Yong
Thanks,
Yong
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 14:05 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-04 14:05 UTC (permalink / raw)
To: Yong
Cc: Ondřej Jirman, Mauro Carvalho Chehab, Rob Herring,
Mark Rutland, Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman,
Randy Dunlap, Hans Verkuil, Stanimir Varbanov, Hugues Fruchet,
Yannick Fertre, Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang, linux-media,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 6923 bytes --]
On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
>
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ondřej Jirman <megous@megous.com> wrote:
>
> > Hello,
> >
> > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > This patchset add initial support for Allwinner V3s CSI.
> > >
> > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > and CSI1 is used for parallel interface. This is not documented in
> > > datasheet but by testing and guess.
> > >
> > > This patchset implement a v4l2 framework driver and add a binding
> > > documentation for it.
> > >
> > > Currently, the driver only support the parallel interface. And has been
> > > tested with a BT1120 signal which generating from FPGA. The following
> > > fetures are not support with this patchset:
> > > - ISP
> > > - MIPI-CSI2
> > > - Master clock for camera sensor
> > > - Power regulator for the front end IC
> > >
> > > Thanks for Ondřej Jirman's help.
> > >
> > > Changes in v4:
> > > * Deal with the CSI 'INNER QUEUE'.
> > > CSI will lookup the next dma buffer for next frame before the
> > > the current frame done IRQ triggered. This is not documented
> > > but reported by Ondřej Jirman.
> > > The BSP code has workaround for this too. It skip to mark the
> > > first buffer as frame done for VB2 and pass the second buffer
> > > to CSI in the first frame done ISR call. Then in second frame
> > > done ISR call, it mark the first buffer as frame done for VB2
> > > and pass the third buffer to CSI. And so on. The bad thing is
> > > that the first buffer will be written twice and the first frame
> > > is dropped even the queued buffer is sufficient.
> > > So, I make some improvement here. Pass the next buffer to CSI
> > > just follow starting the CSI. In this case, the first frame
> > > will be stored in first buffer, second frame in second buffer.
> > > This mothed is used to avoid dropping the first frame, it
> > > would also drop frame when lacking of queued buffer.
> > > * Fix: using a wrong mbus_code when getting the supported formats
> > > * Change all fourcc to pixformat
> > > * Change some function names
> > >
> > > Changes in v3:
> > > * Get rid of struct sun6i_csi_ops
> > > * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > > * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > > * Use generic fwnode endpoints parser
> > > * Only support a single subdev to make things simple
> > > * Many complaintion fix
> > >
> > > Changes in v2:
> > > * Change sunxi-csi to sun6i-csi
> > > * Rebase to media_tree master branch
> > >
> > > Following is the 'v4l2-compliance -s -f' output, I have test this
> > > with both interlaced and progressive signal:
> > >
> > > # ./v4l2-compliance -s -f
> > > v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> > >
> > > Driver Info:
> > > Driver name : sun6i-video
> > > Card type : sun6i-csi
> > > Bus info : platform:csi
> > > Driver version: 4.15.0
> > > Capabilities : 0x84200001
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > > Device Capabilities
> > > Device Caps : 0x04200001
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > >
> > > Compliance test for device /dev/video0 (not using libv4l2):
> > >
> > > Required ioctls:
> > > test VIDIOC_QUERYCAP: OK
> > >
> > > Allow for multiple opens:
> > > test second video 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
> > > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > > Inputs: 1 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)
> > >
> > > Test input 0:
> > >
> > > Control ioctls:
> > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > Standard Controls: 0 Private Controls: 0
> >
> > I'm not sure if your driver passes control queries to the subdev. It
> > did not originally, and I'm not sure you picked up the change from my
> > version of the driver. "Not supported" here seems to indicate that it
> > does not.
> >
> > I'd be interested what's the recommended practice here. It sure helps
> > with some apps that expect to be able to modify various input controls
> > directly on the /dev/video# device. These are then supported out of the
> > box.
> >
> > It's a one-line change. See:
> >
> > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > heriting-controls
>
> I think this is a feature and not affect the driver's main function.
> I just focused on making the CSI main function to work properly in
> the initial version. Is this feature mandatory or most commonly used?
I agree here. Adding more and more features along the iterations is
just the best way to never get something merged.
Let's focus on a good basis that this driver provides, merge that, and
then build on top of it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 14:05 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-04 14:05 UTC (permalink / raw)
To: Yong
Cc: Ondřej Jirman, Mauro Carvalho Chehab, Rob Herring,
Mark Rutland, Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman,
Randy Dunlap, Hans Verkuil, Stanimir Varbanov, Hugues Fruchet,
Yannick Fertre, Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 7274 bytes --]
On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
>
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
>
> > Hello,
> >
> > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > This patchset add initial support for Allwinner V3s CSI.
> > >
> > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > and CSI1 is used for parallel interface. This is not documented in
> > > datasheet but by testing and guess.
> > >
> > > This patchset implement a v4l2 framework driver and add a binding
> > > documentation for it.
> > >
> > > Currently, the driver only support the parallel interface. And has been
> > > tested with a BT1120 signal which generating from FPGA. The following
> > > fetures are not support with this patchset:
> > > - ISP
> > > - MIPI-CSI2
> > > - Master clock for camera sensor
> > > - Power regulator for the front end IC
> > >
> > > Thanks for Ondřej Jirman's help.
> > >
> > > Changes in v4:
> > > * Deal with the CSI 'INNER QUEUE'.
> > > CSI will lookup the next dma buffer for next frame before the
> > > the current frame done IRQ triggered. This is not documented
> > > but reported by Ondřej Jirman.
> > > The BSP code has workaround for this too. It skip to mark the
> > > first buffer as frame done for VB2 and pass the second buffer
> > > to CSI in the first frame done ISR call. Then in second frame
> > > done ISR call, it mark the first buffer as frame done for VB2
> > > and pass the third buffer to CSI. And so on. The bad thing is
> > > that the first buffer will be written twice and the first frame
> > > is dropped even the queued buffer is sufficient.
> > > So, I make some improvement here. Pass the next buffer to CSI
> > > just follow starting the CSI. In this case, the first frame
> > > will be stored in first buffer, second frame in second buffer.
> > > This mothed is used to avoid dropping the first frame, it
> > > would also drop frame when lacking of queued buffer.
> > > * Fix: using a wrong mbus_code when getting the supported formats
> > > * Change all fourcc to pixformat
> > > * Change some function names
> > >
> > > Changes in v3:
> > > * Get rid of struct sun6i_csi_ops
> > > * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > > * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > > * Use generic fwnode endpoints parser
> > > * Only support a single subdev to make things simple
> > > * Many complaintion fix
> > >
> > > Changes in v2:
> > > * Change sunxi-csi to sun6i-csi
> > > * Rebase to media_tree master branch
> > >
> > > Following is the 'v4l2-compliance -s -f' output, I have test this
> > > with both interlaced and progressive signal:
> > >
> > > # ./v4l2-compliance -s -f
> > > v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> > >
> > > Driver Info:
> > > Driver name : sun6i-video
> > > Card type : sun6i-csi
> > > Bus info : platform:csi
> > > Driver version: 4.15.0
> > > Capabilities : 0x84200001
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > > Device Capabilities
> > > Device Caps : 0x04200001
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > >
> > > Compliance test for device /dev/video0 (not using libv4l2):
> > >
> > > Required ioctls:
> > > test VIDIOC_QUERYCAP: OK
> > >
> > > Allow for multiple opens:
> > > test second video 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
> > > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > > Inputs: 1 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)
> > >
> > > Test input 0:
> > >
> > > Control ioctls:
> > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > Standard Controls: 0 Private Controls: 0
> >
> > I'm not sure if your driver passes control queries to the subdev. It
> > did not originally, and I'm not sure you picked up the change from my
> > version of the driver. "Not supported" here seems to indicate that it
> > does not.
> >
> > I'd be interested what's the recommended practice here. It sure helps
> > with some apps that expect to be able to modify various input controls
> > directly on the /dev/video# device. These are then supported out of the
> > box.
> >
> > It's a one-line change. See:
> >
> > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > heriting-controls
>
> I think this is a feature and not affect the driver's main function.
> I just focused on making the CSI main function to work properly in
> the initial version. Is this feature mandatory or most commonly used?
I agree here. Adding more and more features along the iterations is
just the best way to never get something merged.
Let's focus on a good basis that this driver provides, merge that, and
then build on top of it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 14:05 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-04 14:05 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
>
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ond?ej Jirman <megous@megous.com> wrote:
>
> > Hello,
> >
> > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > This patchset add initial support for Allwinner V3s CSI.
> > >
> > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > and CSI1 is used for parallel interface. This is not documented in
> > > datasheet but by testing and guess.
> > >
> > > This patchset implement a v4l2 framework driver and add a binding
> > > documentation for it.
> > >
> > > Currently, the driver only support the parallel interface. And has been
> > > tested with a BT1120 signal which generating from FPGA. The following
> > > fetures are not support with this patchset:
> > > - ISP
> > > - MIPI-CSI2
> > > - Master clock for camera sensor
> > > - Power regulator for the front end IC
> > >
> > > Thanks for Ond?ej Jirman's help.
> > >
> > > Changes in v4:
> > > * Deal with the CSI 'INNER QUEUE'.
> > > CSI will lookup the next dma buffer for next frame before the
> > > the current frame done IRQ triggered. This is not documented
> > > but reported by Ond?ej Jirman.
> > > The BSP code has workaround for this too. It skip to mark the
> > > first buffer as frame done for VB2 and pass the second buffer
> > > to CSI in the first frame done ISR call. Then in second frame
> > > done ISR call, it mark the first buffer as frame done for VB2
> > > and pass the third buffer to CSI. And so on. The bad thing is
> > > that the first buffer will be written twice and the first frame
> > > is dropped even the queued buffer is sufficient.
> > > So, I make some improvement here. Pass the next buffer to CSI
> > > just follow starting the CSI. In this case, the first frame
> > > will be stored in first buffer, second frame in second buffer.
> > > This mothed is used to avoid dropping the first frame, it
> > > would also drop frame when lacking of queued buffer.
> > > * Fix: using a wrong mbus_code when getting the supported formats
> > > * Change all fourcc to pixformat
> > > * Change some function names
> > >
> > > Changes in v3:
> > > * Get rid of struct sun6i_csi_ops
> > > * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > > * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > > * Use generic fwnode endpoints parser
> > > * Only support a single subdev to make things simple
> > > * Many complaintion fix
> > >
> > > Changes in v2:
> > > * Change sunxi-csi to sun6i-csi
> > > * Rebase to media_tree master branch
> > >
> > > Following is the 'v4l2-compliance -s -f' output, I have test this
> > > with both interlaced and progressive signal:
> > >
> > > # ./v4l2-compliance -s -f
> > > v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> > >
> > > Driver Info:
> > > Driver name : sun6i-video
> > > Card type : sun6i-csi
> > > Bus info : platform:csi
> > > Driver version: 4.15.0
> > > Capabilities : 0x84200001
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > > Device Capabilities
> > > Device Caps : 0x04200001
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > >
> > > Compliance test for device /dev/video0 (not using libv4l2):
> > >
> > > Required ioctls:
> > > test VIDIOC_QUERYCAP: OK
> > >
> > > Allow for multiple opens:
> > > test second video 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
> > > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > > Inputs: 1 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)
> > >
> > > Test input 0:
> > >
> > > Control ioctls:
> > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > Standard Controls: 0 Private Controls: 0
> >
> > I'm not sure if your driver passes control queries to the subdev. It
> > did not originally, and I'm not sure you picked up the change from my
> > version of the driver. "Not supported" here seems to indicate that it
> > does not.
> >
> > I'd be interested what's the recommended practice here. It sure helps
> > with some apps that expect to be able to modify various input controls
> > directly on the /dev/video# device. These are then supported out of the
> > box.
> >
> > It's a one-line change. See:
> >
> > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > heriting-controls
>
> I think this is a feature and not affect the driver's main function.
> I just focused on making the CSI main function to work properly in
> the initial version. Is this feature mandatory or most commonly used?
I agree here. Adding more and more features along the iterations is
just the best way to never get something merged.
Let's focus on a good basis that this driver provides, merge that, and
then build on top of it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/25330596/attachment.sig>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 14:06 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-04 14:06 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Yong, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang, linux-media,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> Hello,
>
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> >
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ondřej Jirman <megous@megous.com> wrote:
> >
> > > Hello,
> > >
> > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > >
> > > > Test input 0:
> > > >
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > >
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > >
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > >
> > > It's a one-line change. See:
> > >
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> >
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in
> > the initial version. Is this feature mandatory or most commonly used?
>
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
>
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
>
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:
And it becomes much more complicated once you have the same controls
on the v4l2 device and subdevice, which is not that uncommon.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 14:06 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-04 14:06 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Yong, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sunx
[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]
On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> Hello,
>
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> >
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> >
> > > Hello,
> > >
> > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > >
> > > > Test input 0:
> > > >
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > >
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > >
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > >
> > > It's a one-line change. See:
> > >
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> >
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in
> > the initial version. Is this feature mandatory or most commonly used?
>
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
>
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
>
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:
And it becomes much more complicated once you have the same controls
on the v4l2 device and subdevice, which is not that uncommon.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 14:06 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-04 14:06 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ond?ej Jirman wrote:
> Hello,
>
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> >
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ond?ej Jirman <megous@megous.com> wrote:
> >
> > > Hello,
> > >
> > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > >
> > > > Test input 0:
> > > >
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > >
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > >
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > >
> > > It's a one-line change. See:
> > >
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> >
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in
> > the initial version. Is this feature mandatory or most commonly used?
>
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
>
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
>
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:
And it becomes much more complicated once you have the same controls
on the v4l2 device and subdevice, which is not that uncommon.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/6715e4cd/attachment-0001.sig>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 15:27 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: Ondřej Jirman @ 2018-01-04 15:27 UTC (permalink / raw)
To: Maxime Ripard
Cc: Yong, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang, linux-media,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> > Hello,
> >
> > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > Hi,
> > >
> > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > Ondřej Jirman <megous@megous.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > >
> > > > > Test input 0:
> > > > >
> > > > > Control ioctls:
> > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > Standard Controls: 0 Private Controls: 0
> > > >
> > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > did not originally, and I'm not sure you picked up the change from my
> > > > version of the driver. "Not supported" here seems to indicate that it
> > > > does not.
> > > >
> > > > I'd be interested what's the recommended practice here. It sure helps
> > > > with some apps that expect to be able to modify various input controls
> > > > directly on the /dev/video# device. These are then supported out of the
> > > > box.
> > > >
> > > > It's a one-line change. See:
> > > >
> > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > heriting-controls
> > >
> > > I think this is a feature and not affect the driver's main function.
> > > I just focused on making the CSI main function to work properly in
> > > the initial version. Is this feature mandatory or most commonly used?
> >
> > I grepped the platform/ code and it seems, that inheriting controls
> > from subdevs is pretty common for input drivers. (there are varying
> > approaches though, some inherit by hand in the link function, some
> > just register and empty ctrl_handler on the v4l2_dev and leave the
> > rest to the core).
> >
> > Practically, I haven't found a common app that would allow me to enter
> > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > themselves, but it would be better if current controls were available
> > at the /dev/video0 device automatically.
> >
> > It's much simpler for the userspace apps than the alternative, which
> > is trying to identify the correct subdev that is currently
> > associated with the CSI driver at runtime, which is not exactly
> > straightforward and requires much more code, than a few lines in
> > the kernel, that are required to inherit controls:
>
> And it becomes much more complicated once you have the same controls
> on the v4l2 device and subdevice, which is not that uncommon.
Hi Maxime,
I don't think you understand the issue. In your hypothetical situation, if the
CSI device will have any controls in the future, the merging of controls from
subdev will be done automatically anyway, it's not some optional feature.
Also userspace will not get any more complicated than without my proposed change
to the driver. It will be at most the same as without the change if any subdev
controls are masked by the CSI device controls.
This CSI driver has no controls anyway. All my change does is create an empty
handler for future controls of the CSI driver, so that apps can depend on this
merging behavior right now, and not wait until someone adds the first control
to the CSI driver.
regards,
o.j.
>
> Maxime
>
>
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 15:27 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: 'Ondřej Jirman' via linux-sunxi @ 2018-01-04 15:27 UTC (permalink / raw)
To: Maxime Ripard
Cc: Yong, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sunx
On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> > Hello,
> >
> > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > Hi,
> > >
> > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> > >
> > > > Hello,
> > > >
> > > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > >
> > > > > Test input 0:
> > > > >
> > > > > Control ioctls:
> > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > Standard Controls: 0 Private Controls: 0
> > > >
> > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > did not originally, and I'm not sure you picked up the change from my
> > > > version of the driver. "Not supported" here seems to indicate that it
> > > > does not.
> > > >
> > > > I'd be interested what's the recommended practice here. It sure helps
> > > > with some apps that expect to be able to modify various input controls
> > > > directly on the /dev/video# device. These are then supported out of the
> > > > box.
> > > >
> > > > It's a one-line change. See:
> > > >
> > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > heriting-controls
> > >
> > > I think this is a feature and not affect the driver's main function.
> > > I just focused on making the CSI main function to work properly in
> > > the initial version. Is this feature mandatory or most commonly used?
> >
> > I grepped the platform/ code and it seems, that inheriting controls
> > from subdevs is pretty common for input drivers. (there are varying
> > approaches though, some inherit by hand in the link function, some
> > just register and empty ctrl_handler on the v4l2_dev and leave the
> > rest to the core).
> >
> > Practically, I haven't found a common app that would allow me to enter
> > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > themselves, but it would be better if current controls were available
> > at the /dev/video0 device automatically.
> >
> > It's much simpler for the userspace apps than the alternative, which
> > is trying to identify the correct subdev that is currently
> > associated with the CSI driver at runtime, which is not exactly
> > straightforward and requires much more code, than a few lines in
> > the kernel, that are required to inherit controls:
>
> And it becomes much more complicated once you have the same controls
> on the v4l2 device and subdevice, which is not that uncommon.
Hi Maxime,
I don't think you understand the issue. In your hypothetical situation, if the
CSI device will have any controls in the future, the merging of controls from
subdev will be done automatically anyway, it's not some optional feature.
Also userspace will not get any more complicated than without my proposed change
to the driver. It will be at most the same as without the change if any subdev
controls are masked by the CSI device controls.
This CSI driver has no controls anyway. All my change does is create an empty
handler for future controls of the CSI driver, so that apps can depend on this
merging behavior right now, and not wait until someone adds the first control
to the CSI driver.
regards,
o.j.
>
> Maxime
>
>
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-04 15:27 ` 'Ondřej Jirman' via linux-sunxi
0 siblings, 0 replies; 27+ messages in thread
From: Ondřej Jirman @ 2018-01-04 15:27 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ond?ej Jirman wrote:
> > Hello,
> >
> > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > Hi,
> > >
> > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > Ond?ej Jirman <megous@megous.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > > >
> > > > > Test input 0:
> > > > >
> > > > > Control ioctls:
> > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > Standard Controls: 0 Private Controls: 0
> > > >
> > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > did not originally, and I'm not sure you picked up the change from my
> > > > version of the driver. "Not supported" here seems to indicate that it
> > > > does not.
> > > >
> > > > I'd be interested what's the recommended practice here. It sure helps
> > > > with some apps that expect to be able to modify various input controls
> > > > directly on the /dev/video# device. These are then supported out of the
> > > > box.
> > > >
> > > > It's a one-line change. See:
> > > >
> > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > heriting-controls
> > >
> > > I think this is a feature and not affect the driver's main function.
> > > I just focused on making the CSI main function to work properly in
> > > the initial version. Is this feature mandatory or most commonly used?
> >
> > I grepped the platform/ code and it seems, that inheriting controls
> > from subdevs is pretty common for input drivers. (there are varying
> > approaches though, some inherit by hand in the link function, some
> > just register and empty ctrl_handler on the v4l2_dev and leave the
> > rest to the core).
> >
> > Practically, I haven't found a common app that would allow me to enter
> > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > themselves, but it would be better if current controls were available
> > at the /dev/video0 device automatically.
> >
> > It's much simpler for the userspace apps than the alternative, which
> > is trying to identify the correct subdev that is currently
> > associated with the CSI driver at runtime, which is not exactly
> > straightforward and requires much more code, than a few lines in
> > the kernel, that are required to inherit controls:
>
> And it becomes much more complicated once you have the same controls
> on the v4l2 device and subdevice, which is not that uncommon.
Hi Maxime,
I don't think you understand the issue. In your hypothetical situation, if the
CSI device will have any controls in the future, the merging of controls from
subdev will be done automatically anyway, it's not some optional feature.
Also userspace will not get any more complicated than without my proposed change
to the driver. It will be at most the same as without the change if any subdev
controls are masked by the CSI device controls.
This CSI driver has no controls anyway. All my change does is create an empty
handler for future controls of the CSI driver, so that apps can depend on this
merging behavior right now, and not wait until someone adds the first control
to the CSI driver.
regards,
o.j.
>
> Maxime
>
>
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-08 10:21 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-08 10:21 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Yong, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang, linux-media,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]
Hi,
On Thu, Jan 04, 2018 at 04:27:41PM +0100, Ondřej Jirman wrote:
> On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> > On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> > > Hello,
> > >
> > > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > > Hi,
> > > >
> > > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > > Ondřej Jirman <megous@megous.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > > >
> > > > > > Test input 0:
> > > > > >
> > > > > > Control ioctls:
> > > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > > Standard Controls: 0 Private Controls: 0
> > > > >
> > > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > > did not originally, and I'm not sure you picked up the change from my
> > > > > version of the driver. "Not supported" here seems to indicate that it
> > > > > does not.
> > > > >
> > > > > I'd be interested what's the recommended practice here. It sure helps
> > > > > with some apps that expect to be able to modify various input controls
> > > > > directly on the /dev/video# device. These are then supported out of the
> > > > > box.
> > > > >
> > > > > It's a one-line change. See:
> > > > >
> > > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > > heriting-controls
> > > >
> > > > I think this is a feature and not affect the driver's main function.
> > > > I just focused on making the CSI main function to work properly in
> > > > the initial version. Is this feature mandatory or most commonly used?
> > >
> > > I grepped the platform/ code and it seems, that inheriting controls
> > > from subdevs is pretty common for input drivers. (there are varying
> > > approaches though, some inherit by hand in the link function, some
> > > just register and empty ctrl_handler on the v4l2_dev and leave the
> > > rest to the core).
> > >
> > > Practically, I haven't found a common app that would allow me to enter
> > > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > > themselves, but it would be better if current controls were available
> > > at the /dev/video0 device automatically.
> > >
> > > It's much simpler for the userspace apps than the alternative, which
> > > is trying to identify the correct subdev that is currently
> > > associated with the CSI driver at runtime, which is not exactly
> > > straightforward and requires much more code, than a few lines in
> > > the kernel, that are required to inherit controls:
> >
> > And it becomes much more complicated once you have the same controls
> > on the v4l2 device and subdevice, which is not that uncommon.
>
> I don't think you understand the issue. In your hypothetical situation, if the
> CSI device will have any controls in the future, the merging of controls from
> subdev will be done automatically anyway, it's not some optional feature.
>
> Also userspace will not get any more complicated than without my proposed change
> to the driver. It will be at most the same as without the change if any subdev
> controls are masked by the CSI device controls.
>
> This CSI driver has no controls anyway. All my change does is create an empty
> handler for future controls of the CSI driver, so that apps can depend on this
> merging behavior right now, and not wait until someone adds the first control
> to the CSI driver.
My point is slightly different though. In more complex pipelines like
we have (which is even more complicated due to the fact that the ISP
is largely unknown), you cannot just have an application that rely on
the controls exposed on the v4l2 device, but they should take the
subdevices into account as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-08 10:21 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-08 10:21 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Yong, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sunx
[-- Attachment #1: Type: text/plain, Size: 4742 bytes --]
Hi,
On Thu, Jan 04, 2018 at 04:27:41PM +0100, Ondřej Jirman wrote:
> On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> > On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> > > Hello,
> > >
> > > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > > Hi,
> > > >
> > > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > > Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > > >
> > > > > > Test input 0:
> > > > > >
> > > > > > Control ioctls:
> > > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > > Standard Controls: 0 Private Controls: 0
> > > > >
> > > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > > did not originally, and I'm not sure you picked up the change from my
> > > > > version of the driver. "Not supported" here seems to indicate that it
> > > > > does not.
> > > > >
> > > > > I'd be interested what's the recommended practice here. It sure helps
> > > > > with some apps that expect to be able to modify various input controls
> > > > > directly on the /dev/video# device. These are then supported out of the
> > > > > box.
> > > > >
> > > > > It's a one-line change. See:
> > > > >
> > > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > > heriting-controls
> > > >
> > > > I think this is a feature and not affect the driver's main function.
> > > > I just focused on making the CSI main function to work properly in
> > > > the initial version. Is this feature mandatory or most commonly used?
> > >
> > > I grepped the platform/ code and it seems, that inheriting controls
> > > from subdevs is pretty common for input drivers. (there are varying
> > > approaches though, some inherit by hand in the link function, some
> > > just register and empty ctrl_handler on the v4l2_dev and leave the
> > > rest to the core).
> > >
> > > Practically, I haven't found a common app that would allow me to enter
> > > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > > themselves, but it would be better if current controls were available
> > > at the /dev/video0 device automatically.
> > >
> > > It's much simpler for the userspace apps than the alternative, which
> > > is trying to identify the correct subdev that is currently
> > > associated with the CSI driver at runtime, which is not exactly
> > > straightforward and requires much more code, than a few lines in
> > > the kernel, that are required to inherit controls:
> >
> > And it becomes much more complicated once you have the same controls
> > on the v4l2 device and subdevice, which is not that uncommon.
>
> I don't think you understand the issue. In your hypothetical situation, if the
> CSI device will have any controls in the future, the merging of controls from
> subdev will be done automatically anyway, it's not some optional feature.
>
> Also userspace will not get any more complicated than without my proposed change
> to the driver. It will be at most the same as without the change if any subdev
> controls are masked by the CSI device controls.
>
> This CSI driver has no controls anyway. All my change does is create an empty
> handler for future controls of the CSI driver, so that apps can depend on this
> merging behavior right now, and not wait until someone adds the first control
> to the CSI driver.
My point is slightly different though. In more complex pipelines like
we have (which is even more complicated due to the fact that the ISP
is largely unknown), you cannot just have an application that rely on
the controls exposed on the v4l2 device, but they should take the
subdevices into account as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
@ 2018-01-08 10:21 ` Maxime Ripard
0 siblings, 0 replies; 27+ messages in thread
From: Maxime Ripard @ 2018-01-08 10:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thu, Jan 04, 2018 at 04:27:41PM +0100, Ond?ej Jirman wrote:
> On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> > On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ond?ej Jirman wrote:
> > > Hello,
> > >
> > > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > > Hi,
> > > >
> > > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > > Ond?ej Jirman <megous@megous.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > > > >
> > > > > > Test input 0:
> > > > > >
> > > > > > Control ioctls:
> > > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > > Standard Controls: 0 Private Controls: 0
> > > > >
> > > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > > did not originally, and I'm not sure you picked up the change from my
> > > > > version of the driver. "Not supported" here seems to indicate that it
> > > > > does not.
> > > > >
> > > > > I'd be interested what's the recommended practice here. It sure helps
> > > > > with some apps that expect to be able to modify various input controls
> > > > > directly on the /dev/video# device. These are then supported out of the
> > > > > box.
> > > > >
> > > > > It's a one-line change. See:
> > > > >
> > > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > > heriting-controls
> > > >
> > > > I think this is a feature and not affect the driver's main function.
> > > > I just focused on making the CSI main function to work properly in
> > > > the initial version. Is this feature mandatory or most commonly used?
> > >
> > > I grepped the platform/ code and it seems, that inheriting controls
> > > from subdevs is pretty common for input drivers. (there are varying
> > > approaches though, some inherit by hand in the link function, some
> > > just register and empty ctrl_handler on the v4l2_dev and leave the
> > > rest to the core).
> > >
> > > Practically, I haven't found a common app that would allow me to enter
> > > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > > themselves, but it would be better if current controls were available
> > > at the /dev/video0 device automatically.
> > >
> > > It's much simpler for the userspace apps than the alternative, which
> > > is trying to identify the correct subdev that is currently
> > > associated with the CSI driver at runtime, which is not exactly
> > > straightforward and requires much more code, than a few lines in
> > > the kernel, that are required to inherit controls:
> >
> > And it becomes much more complicated once you have the same controls
> > on the v4l2 device and subdevice, which is not that uncommon.
>
> I don't think you understand the issue. In your hypothetical situation, if the
> CSI device will have any controls in the future, the merging of controls from
> subdev will be done automatically anyway, it's not some optional feature.
>
> Also userspace will not get any more complicated than without my proposed change
> to the driver. It will be at most the same as without the change if any subdev
> controls are masked by the CSI device controls.
>
> This CSI driver has no controls anyway. All my change does is create an empty
> handler for future controls of the CSI driver, so that apps can depend on this
> merging behavior right now, and not wait until someone adds the first control
> to the CSI driver.
My point is slightly different though. In more complex pipelines like
we have (which is even more complicated due to the fact that the ISP
is largely unknown), you cannot just have an application that rely on
the controls exposed on the v4l2 device, but they should take the
subdevices into account as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180108/bdd92851/attachment.sig>
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2018-01-08 10:21 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-22 9:32 [PATCH v4 0/2] Initial Allwinner V3s CSI Support Yong Deng
2017-12-22 9:32 ` Yong Deng
2017-12-22 9:32 ` Yong Deng
2017-12-22 13:46 ` [linux-sunxi] " Ondřej Jirman
2017-12-22 13:46 ` Ondřej Jirman
2017-12-22 13:46 ` 'Ondřej Jirman' via linux-sunxi
2017-12-25 3:15 ` [linux-sunxi] " Yong
2017-12-25 3:15 ` Yong
2017-12-25 3:15 ` Yong
2017-12-25 8:58 ` [linux-sunxi] " Ondřej Jirman
2017-12-25 8:58 ` Ondřej Jirman
2017-12-25 8:58 ` 'Ondřej Jirman' via linux-sunxi
2017-12-26 0:56 ` [linux-sunxi] " Yong
2017-12-26 0:56 ` Yong
2017-12-26 0:56 ` Yong
2018-01-04 14:06 ` [linux-sunxi] " Maxime Ripard
2018-01-04 14:06 ` Maxime Ripard
2018-01-04 14:06 ` Maxime Ripard
2018-01-04 15:27 ` [linux-sunxi] " Ondřej Jirman
2018-01-04 15:27 ` Ondřej Jirman
2018-01-04 15:27 ` 'Ondřej Jirman' via linux-sunxi
2018-01-08 10:21 ` [linux-sunxi] " Maxime Ripard
2018-01-08 10:21 ` Maxime Ripard
2018-01-08 10:21 ` Maxime Ripard
2018-01-04 14:05 ` [linux-sunxi] " Maxime Ripard
2018-01-04 14:05 ` Maxime Ripard
2018-01-04 14:05 ` Maxime Ripard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.