mirror of
https://github.com/Dasharo/linux.git
synced 2026-03-06 15:25:10 -08:00
Merge tag 'media/v6.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - New sensor drivers: gc05a2, gc08a3 and imx283 - New serializer/deserializer drivers: max96714 and max96717 - New JPEG encoder driver: e5010 - Support for Raspberry Pi PiSP Backend (BE) ISP driver - Old documentation for av7110 driver removed, as a new version was added as Documentation/userspace-api/media/dvb/legacy*.rst - atompisp: Linux firmwares are now available, so drop firmware-related task from TODO and update firmware logic - The imx258 driver has gained several improvements - wave5 driver has gained support for HEVC decoding - em28xx gained support for MyGica UTV3 - av7110 budget-patch driver removed - Lots of other cleanups, improvements and fixes * tag 'media/v6.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (301 commits) media: raspberrypi: Switch to remove_new media: uapi: pisp_be_config: Add extra config fields media: uapi: pisp_be_config: Re-sort pisp_be_tiles_config media: uapi: pisp_common: Capitalize all macros media: uapi: pisp_common: Add 32 bpp format test media: uapi: pisp_be_config: Drop BIT() from uAPI media: stm32: dcmipp: correct error handling in dcmipp_create_subdevs media: atomisp: Fix spelling mistakes in sh_css_sp.c media: atomisp: Fix spelling mistake in ia_css_debug.c media: atomisp: Fix spelling mistake in hmm_bo.c media: atomisp: Fix spelling mistake in ia_css_eed1_8.host.c media: atomisp: Fix spelling mistake in sh_css_internal.h media: atomisp: Fix spelling mistake "pipline" -> "pipeline" media: atomisp: Remove unused GPIO related defines and APIs media: atomisp: Replace COMPILATION_ERROR_IF() by static_assert() media: atomisp: Clean up unused macros from math_support.h media: atomisp: csi2-bridge: Add DMI quirk for OV5693 on Xiaomi Mipad2 media: atomisp: Update TODO media: atomisp: Prefix firmware paths with "intel/ipu/" media: atomisp: Remove firmware_name module parameter ...
This commit is contained in:
Linus Torvalds
@@ -438,3 +438,11 @@ EM28xx cards list
|
||||
- MyGica iGrabber
|
||||
- em2860
|
||||
- 1f4d:1abe
|
||||
* - 106
|
||||
- Hauppauge USB QuadHD ATSC
|
||||
- em28274
|
||||
- 2040:846d
|
||||
* - 107
|
||||
- MyGica UTV3 Analog USB2.0 TV Box
|
||||
- em2860
|
||||
- eb1a:2860
|
||||
|
||||
@@ -135,16 +135,16 @@ sensor ov2740 on Lenovo X1 Yoga laptop.
|
||||
.. code-block:: none
|
||||
|
||||
media-ctl -l "\"ov2740 14-0036\":0 -> \"Intel IPU6 CSI2 1\":0[1]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":1 -> \"Intel IPU6 ISYS Capture 0\":0[5]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":2 -> \"Intel IPU6 ISYS Capture 1\":0[5]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":1 -> \"Intel IPU6 ISYS Capture 0\":0[1]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":2 -> \"Intel IPU6 ISYS Capture 1\":0[1]"
|
||||
|
||||
# set routing
|
||||
media-ctl -v -R "\"Intel IPU6 CSI2 1\" [0/0->1/0[1],0/1->2/1[1]]"
|
||||
media-ctl -R "\"Intel IPU6 CSI2 1\" [0/0->1/0[1],0/1->2/1[1]]"
|
||||
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":0/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":0/1 [fmt:GENERIC_8/97x1]"
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":1/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":2/1 [fmt:GENERIC_8/97x1]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":0/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":0/1 [fmt:GENERIC_8/97x1]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":1/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":2/1 [fmt:GENERIC_8/97x1]"
|
||||
|
||||
CAPTURE_DEV=$(media-ctl -e "Intel IPU6 ISYS Capture 0")
|
||||
./yavta --data-prefix -c100 -n5 -I -s1932x1092 --file=/tmp/frame-#.bin \
|
||||
|
||||
20
Documentation/admin-guide/media/raspberrypi-pisp-be.dot
Normal file
20
Documentation/admin-guide/media/raspberrypi-pisp-be.dot
Normal file
@@ -0,0 +1,20 @@
|
||||
digraph board {
|
||||
rankdir=TB
|
||||
n00000001 [label="{{<port0> 0 | <port1> 1 | <port2> 2 | <port7> 7} | pispbe\n | {<port3> 3 | <port4> 4 | <port5> 5 | <port6> 6}}", shape=Mrecord, style=filled, fillcolor=green]
|
||||
n00000001:port3 -> n0000001c [style=bold]
|
||||
n00000001:port4 -> n00000022 [style=bold]
|
||||
n00000001:port5 -> n00000028 [style=bold]
|
||||
n00000001:port6 -> n0000002e [style=bold]
|
||||
n0000000a [label="pispbe-input\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
|
||||
n0000000a -> n00000001:port0 [style=bold]
|
||||
n00000010 [label="pispbe-tdn_input\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000010 -> n00000001:port1 [style=bold]
|
||||
n00000016 [label="pispbe-stitch_input\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000016 -> n00000001:port2 [style=bold]
|
||||
n0000001c [label="pispbe-output0\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000022 [label="pispbe-output1\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000028 [label="pispbe-tdn_output\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
|
||||
n0000002e [label="pispbe-stitch_output\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000034 [label="pispbe-config\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000034 -> n00000001:port7 [style=bold]
|
||||
}
|
||||
109
Documentation/admin-guide/media/raspberrypi-pisp-be.rst
Normal file
109
Documentation/admin-guide/media/raspberrypi-pisp-be.rst
Normal file
@@ -0,0 +1,109 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========================================================
|
||||
Raspberry Pi PiSP Back End Memory-to-Memory ISP (pisp-be)
|
||||
=========================================================
|
||||
|
||||
The PiSP Back End
|
||||
=================
|
||||
|
||||
The PiSP Back End is a memory-to-memory Image Signal Processor (ISP) which reads
|
||||
image data from DRAM memory and performs image processing as specified by the
|
||||
application through the parameters in a configuration buffer, before writing
|
||||
pixel data back to memory through two distinct output channels.
|
||||
|
||||
The ISP registers and programming model are documented in the `Raspberry Pi
|
||||
Image Signal Processor (PiSP) Specification document`_
|
||||
|
||||
The PiSP Back End ISP processes images in tiles. The handling of image
|
||||
tessellation and the computation of low-level configuration parameters is
|
||||
realized by a free software library called `libpisp
|
||||
<https://github.com/raspberrypi/libpisp>`_.
|
||||
|
||||
The full image processing pipeline, which involves capturing RAW Bayer data from
|
||||
an image sensor through a MIPI CSI-2 compatible capture interface, storing them
|
||||
in DRAM memory and processing them in the PiSP Back End to obtain images usable
|
||||
by an application is implemented in `libcamera <https://libcamera.org>`_ as
|
||||
part of the Raspberry Pi platform support.
|
||||
|
||||
The pisp-be driver
|
||||
==================
|
||||
|
||||
The Raspberry Pi PiSP Back End (pisp-be) driver is located under
|
||||
drivers/media/platform/raspberrypi/pisp-be. It uses the `V4L2 API` to register
|
||||
a number of video capture and output devices, the `V4L2 subdev API` to register
|
||||
a subdevice for the ISP that connects the video devices in a single media graph
|
||||
realized using the `Media Controller (MC) API`.
|
||||
|
||||
The media topology registered by the `pisp-be` driver is represented below:
|
||||
|
||||
.. _pips-be-topology:
|
||||
|
||||
.. kernel-figure:: raspberrypi-pisp-be.dot
|
||||
:alt: Diagram of the default media pipeline topology
|
||||
:align: center
|
||||
|
||||
|
||||
The media graph registers the following video device nodes:
|
||||
|
||||
- pispbe-input: output device for images to be submitted to the ISP for
|
||||
processing.
|
||||
- pispbe-tdn_input: output device for temporal denoise.
|
||||
- pispbe-stitch_input: output device for image stitching (HDR).
|
||||
- pispbe-output0: first capture device for processed images.
|
||||
- pispbe-output1: second capture device for processed images.
|
||||
- pispbe-tdn_output: capture device for temporal denoise.
|
||||
- pispbe-stitch_output: capture device for image stitching (HDR).
|
||||
- pispbe-config: output device for ISP configuration parameters.
|
||||
|
||||
pispbe-input
|
||||
------------
|
||||
|
||||
Images to be processed by the ISP are queued to the `pispbe-input` output device
|
||||
node. For a list of image formats supported as input to the ISP refer to the
|
||||
`Raspberry Pi Image Signal Processor (PiSP) Specification document`_.
|
||||
|
||||
pispbe-tdn_input, pispbe-tdn_output
|
||||
-----------------------------------
|
||||
|
||||
The `pispbe-tdn_input` output video device receives images to be processed by
|
||||
the temporal denoise block which are captured from the `pispbe-tdn_output`
|
||||
capture video device. Userspace is responsible for maintaining queues on both
|
||||
devices, and ensuring that buffers completed on the output are queued to the
|
||||
input.
|
||||
|
||||
pispbe-stitch_input, pispbe-stitch_output
|
||||
-----------------------------------------
|
||||
|
||||
To realize HDR (high dynamic range) image processing the image stitching and
|
||||
tonemapping blocks are used. The `pispbe-stitch_output` writes images to memory
|
||||
and the `pispbe-stitch_input` receives the previously written frame to process
|
||||
it along with the current input image. Userspace is responsible for maintaining
|
||||
queues on both devices, and ensuring that buffers completed on the output are
|
||||
queued to the input.
|
||||
|
||||
pispbe-output0, pispbe-output1
|
||||
------------------------------
|
||||
|
||||
The two capture devices write to memory the pixel data as processed by the ISP.
|
||||
|
||||
pispbe-config
|
||||
-------------
|
||||
|
||||
The `pispbe-config` output video devices receives a buffer of configuration
|
||||
parameters that define the desired image processing to be performed by the ISP.
|
||||
|
||||
The format of the ISP configuration parameter is defined by
|
||||
:c:type:`pisp_be_tiles_config` C structure and the meaning of each parameter is
|
||||
described in the `Raspberry Pi Image Signal Processor (PiSP) Specification
|
||||
document`_.
|
||||
|
||||
ISP configuration
|
||||
=================
|
||||
|
||||
The ISP configuration is described solely by the content of the parameters
|
||||
buffer. The only parameter that userspace needs to configure using the V4L2 API
|
||||
is the image format on the output and capture video devices for validation of
|
||||
the content of the parameters buffer.
|
||||
|
||||
.. _Raspberry Pi Image Signal Processor (PiSP) Specification document: https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
|
||||
@@ -97,4 +97,6 @@ Tuner number Card name
|
||||
89 Sony BTF-PG472Z PAL/SECAM
|
||||
90 Sony BTF-PK467Z NTSC-M-JP
|
||||
91 Sony BTF-PB463Z NTSC-M
|
||||
92 Silicon Labs Si2157 tuner
|
||||
93 Tena TNF931D-DFDR1
|
||||
============ =====================================================
|
||||
|
||||
@@ -23,6 +23,7 @@ Video4Linux (V4L) driver-specific documentation
|
||||
omap4_camera
|
||||
philips
|
||||
qcom_camss
|
||||
raspberrypi-pisp-be
|
||||
rcar-fdp1
|
||||
rkisp1
|
||||
saa7134
|
||||
|
||||
@@ -302,6 +302,15 @@ all configurable using the following module options:
|
||||
- 0: forbid hints
|
||||
- 1: allow hints
|
||||
|
||||
- supports_requests:
|
||||
|
||||
specifies if the device should support the Request API. There are
|
||||
three possible values, default is 1:
|
||||
|
||||
- 0: no request
|
||||
- 1: supports requests
|
||||
- 2: requires requests
|
||||
|
||||
Taken together, all these module options allow you to precisely customize
|
||||
the driver behavior and test your application with all sorts of permutations.
|
||||
It is also very suitable to emulate hardware that is not yet available, e.g.
|
||||
@@ -313,10 +322,10 @@ Video Capture
|
||||
|
||||
This is probably the most frequently used feature. The video capture device
|
||||
can be configured by using the module options num_inputs, input_types and
|
||||
ccs_cap_mode (see section 1 for more detailed information), but by default
|
||||
four inputs are configured: a webcam, a TV tuner, an S-Video and an HDMI
|
||||
input, one input for each input type. Those are described in more detail
|
||||
below.
|
||||
ccs_cap_mode (see "Configuring the driver" for more detailed information),
|
||||
but by default four inputs are configured: a webcam, a TV tuner, an S-Video
|
||||
and an HDMI input, one input for each input type. Those are described in more
|
||||
detail below.
|
||||
|
||||
Special attention has been given to the rate at which new frames become
|
||||
available. The jitter will be around 1 jiffie (that depends on the HZ
|
||||
@@ -434,10 +443,10 @@ Video Output
|
||||
------------
|
||||
|
||||
The video output device can be configured by using the module options
|
||||
num_outputs, output_types and ccs_out_mode (see section 1 for more detailed
|
||||
information), but by default two outputs are configured: an S-Video and an
|
||||
HDMI input, one output for each output type. Those are described in more detail
|
||||
below.
|
||||
num_outputs, output_types and ccs_out_mode (see "Configuring the driver"
|
||||
for more detailed information), but by default two outputs are configured:
|
||||
an S-Video and an HDMI input, one output for each output type. Those are
|
||||
described in more detail below.
|
||||
|
||||
Like with video capture the framerate is also exact in the long term.
|
||||
|
||||
@@ -1011,11 +1020,6 @@ Digital Video Controls
|
||||
affects the reported colorspace since DVI_D outputs will always use
|
||||
sRGB.
|
||||
|
||||
- Display Present:
|
||||
|
||||
sets the presence of a "display" on the HDMI output. This affects
|
||||
the tx_edid_present, tx_hotplug and tx_rxsense controls.
|
||||
|
||||
|
||||
FM Radio Receiver Controls
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@@ -1130,35 +1134,34 @@ Metadata Capture Controls
|
||||
|
||||
if set, then the generated metadata stream contains Source Clock information.
|
||||
|
||||
Video, VBI and RDS Looping
|
||||
--------------------------
|
||||
|
||||
The vivid driver supports looping of video output to video input, VBI output
|
||||
to VBI input and RDS output to RDS input. For video/VBI looping this emulates
|
||||
as if a cable was hooked up between the output and input connector. So video
|
||||
and VBI looping is only supported between S-Video and HDMI inputs and outputs.
|
||||
VBI is only valid for S-Video as it makes no sense for HDMI.
|
||||
Video, Sliced VBI and HDMI CEC Looping
|
||||
--------------------------------------
|
||||
|
||||
Since radio is wireless this looping always happens if the radio receiver
|
||||
frequency is close to the radio transmitter frequency. In that case the radio
|
||||
transmitter will 'override' the emulated radio stations.
|
||||
Video Looping functionality is supported for devices created by the same
|
||||
vivid driver instance, as well as across multiple instances of the vivid driver.
|
||||
The vivid driver supports looping of video and Sliced VBI data between an S-Video output
|
||||
and an S-Video input. It also supports looping of video and HDMI CEC data between an
|
||||
HDMI output and an HDMI input.
|
||||
|
||||
Looping is currently supported only between devices created by the same
|
||||
vivid driver instance.
|
||||
To enable looping, set the 'HDMI/S-Video XXX-N Is Connected To' control(s) to select
|
||||
whether an input uses the Test Pattern Generator, or is disconnected, or is connected
|
||||
to an output. An input can be connected to an output from any vivid instance.
|
||||
The inputs and outputs are numbered XXX-N where XXX is the vivid instance number
|
||||
(see module option n_devs). If there is only one vivid instance (the default), then
|
||||
XXX will be 000. And N is the Nth S-Video/HDMI input or output of that instance.
|
||||
If vivid is loaded without module options, then you can connect the S-Video 000-0 input
|
||||
to the S-Video 000-0 output, or the HDMI 000-0 input to the HDMI 000-0 output.
|
||||
This is the equivalent of connecting or disconnecting a cable between an input and an
|
||||
output in a physical device.
|
||||
|
||||
If an 'HDMI/S-Video XXX-N Is Connected To' control selected an output, then the video
|
||||
output will be looped to the video input provided that:
|
||||
|
||||
Video and Sliced VBI looping
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
- the currently selected input matches the input indicated by the control name.
|
||||
|
||||
The way to enable video/VBI looping is currently fairly crude. A 'Loop Video'
|
||||
control is available in the "Vivid" control class of the video
|
||||
capture and VBI capture devices. When checked the video looping will be enabled.
|
||||
Once enabled any video S-Video or HDMI input will show a static test pattern
|
||||
until the video output has started. At that time the video output will be
|
||||
looped to the video input provided that:
|
||||
|
||||
- the input type matches the output type. So the HDMI input cannot receive
|
||||
video from the S-Video output.
|
||||
- in the vivid instance of the output connector, the currently selected output matches
|
||||
the output indicated by the control's value.
|
||||
|
||||
- the video resolution of the video input must match that of the video output.
|
||||
So it is not possible to loop a 50 Hz (720x576) S-Video output to a 60 Hz
|
||||
@@ -1185,6 +1188,8 @@ looped to the video input provided that:
|
||||
"DV Timings Signal Mode" for the HDMI input should be configured so that a
|
||||
valid signal is passed to the video input.
|
||||
|
||||
If any condition is not valid, then the 'Noise' test pattern is shown.
|
||||
|
||||
The framerates do not have to match, although this might change in the future.
|
||||
|
||||
By default you will see the OSD text superimposed on top of the looped video.
|
||||
@@ -1198,17 +1203,26 @@ and WSS (50 Hz formats) VBI data is looped. Teletext VBI data is not looped.
|
||||
|
||||
|
||||
Radio & RDS Looping
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
-------------------
|
||||
|
||||
As mentioned in section 6 the radio receiver emulates stations are regular
|
||||
frequency intervals. Depending on the frequency of the radio receiver a
|
||||
signal strength value is calculated (this is returned by VIDIOC_G_TUNER).
|
||||
However, it will also look at the frequency set by the radio transmitter and
|
||||
if that results in a higher signal strength than the settings of the radio
|
||||
transmitter will be used as if it was a valid station. This also includes
|
||||
the RDS data (if any) that the transmitter 'transmits'. This is received
|
||||
faithfully on the receiver side. Note that when the driver is loaded the
|
||||
frequencies of the radio receiver and transmitter are not identical, so
|
||||
The vivid driver supports looping of RDS output to RDS input.
|
||||
|
||||
Since radio is wireless this looping always happens if the radio receiver
|
||||
frequency is close to the radio transmitter frequency. In that case the radio
|
||||
transmitter will 'override' the emulated radio stations.
|
||||
|
||||
RDS looping is currently supported only between devices created by the same
|
||||
vivid driver instance.
|
||||
|
||||
As mentioned in the "Radio Receiver" section, the radio receiver emulates
|
||||
stations at regular frequency intervals. Depending on the frequency of the
|
||||
radio receiver a signal strength value is calculated (this is returned by
|
||||
VIDIOC_G_TUNER). However, it will also look at the frequency set by the radio
|
||||
transmitter and if that results in a higher signal strength than the settings
|
||||
of the radio transmitter will be used as if it was a valid station. This also
|
||||
includes the RDS data (if any) that the transmitter 'transmits'. This is
|
||||
received faithfully on the receiver side. Note that when the driver is loaded
|
||||
the frequencies of the radio receiver and transmitter are not identical, so
|
||||
initially no looping takes place.
|
||||
|
||||
|
||||
@@ -1218,8 +1232,8 @@ Cropping, Composing, Scaling
|
||||
This driver supports cropping, composing and scaling in any combination. Normally
|
||||
which features are supported can be selected through the Vivid controls,
|
||||
but it is also possible to hardcode it when the module is loaded through the
|
||||
ccs_cap_mode and ccs_out_mode module options. See section 1 on the details of
|
||||
these module options.
|
||||
ccs_cap_mode and ccs_out_mode module options. See "Configuring the driver" on
|
||||
the details of these module options.
|
||||
|
||||
This allows you to test your application for all these variations.
|
||||
|
||||
@@ -1260,7 +1274,8 @@ is set, then the alpha component is only used for the color red and set to
|
||||
|
||||
The driver has to be configured to support the multiplanar formats. By default
|
||||
the driver instances are single-planar. This can be changed by setting the
|
||||
multiplanar module option, see section 1 for more details on that option.
|
||||
multiplanar module option, see "Configuring the driver" for more details on that
|
||||
option.
|
||||
|
||||
If the driver instance is using the multiplanar formats/API, then the first
|
||||
single planar format (YUYV) and the multiplanar NV16M and NV61M formats the
|
||||
@@ -1270,74 +1285,6 @@ data_offset to be non-zero, so this is a useful feature for testing applications
|
||||
Video output will also honor any data_offset that the application set.
|
||||
|
||||
|
||||
Capture Overlay
|
||||
---------------
|
||||
|
||||
Note: capture overlay support is implemented primarily to test the existing
|
||||
V4L2 capture overlay API. In practice few if any GPUs support such overlays
|
||||
anymore, and neither are they generally needed anymore since modern hardware
|
||||
is so much more capable. By setting flag 0x10000 in the node_types module
|
||||
option the vivid driver will create a simple framebuffer device that can be
|
||||
used for testing this API. Whether this API should be used for new drivers is
|
||||
questionable.
|
||||
|
||||
This driver has support for a destructive capture overlay with bitmap clipping
|
||||
and list clipping (up to 16 rectangles) capabilities. Overlays are not
|
||||
supported for multiplanar formats. It also honors the struct v4l2_window field
|
||||
setting: if it is set to FIELD_TOP or FIELD_BOTTOM and the capture setting is
|
||||
FIELD_ALTERNATE, then only the top or bottom fields will be copied to the overlay.
|
||||
|
||||
The overlay only works if you are also capturing at that same time. This is a
|
||||
vivid limitation since it copies from a buffer to the overlay instead of
|
||||
filling the overlay directly. And if you are not capturing, then no buffers
|
||||
are available to fill.
|
||||
|
||||
In addition, the pixelformat of the capture format and that of the framebuffer
|
||||
must be the same for the overlay to work. Otherwise VIDIOC_OVERLAY will return
|
||||
an error.
|
||||
|
||||
In order to really see what it going on you will need to create two vivid
|
||||
instances: the first with a framebuffer enabled. You configure the capture
|
||||
overlay of the second instance to use the framebuffer of the first, then
|
||||
you start capturing in the second instance. For the first instance you setup
|
||||
the output overlay for the video output, turn on video looping and capture
|
||||
to see the blended framebuffer overlay that's being written to by the second
|
||||
instance. This setup would require the following commands:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1
|
||||
$ v4l2-ctl -d1 --find-fb
|
||||
/dev/fb1 is the framebuffer associated with base address 0x12800000
|
||||
$ sudo v4l2-ctl -d2 --set-fbuf fb=1
|
||||
$ v4l2-ctl -d1 --set-fbuf fb=1
|
||||
$ v4l2-ctl -d0 --set-fmt-video=pixelformat='AR15'
|
||||
$ v4l2-ctl -d1 --set-fmt-video-out=pixelformat='AR15'
|
||||
$ v4l2-ctl -d2 --set-fmt-video=pixelformat='AR15'
|
||||
$ v4l2-ctl -d0 -i2
|
||||
$ v4l2-ctl -d2 -i2
|
||||
$ v4l2-ctl -d2 -c horizontal_movement=4
|
||||
$ v4l2-ctl -d1 --overlay=1
|
||||
$ v4l2-ctl -d0 -c loop_video=1
|
||||
$ v4l2-ctl -d2 --stream-mmap --overlay=1
|
||||
|
||||
And from another console:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ v4l2-ctl -d1 --stream-out-mmap
|
||||
|
||||
And yet another console:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ qv4l2
|
||||
|
||||
and start streaming.
|
||||
|
||||
As you can see, this is not for the faint of heart...
|
||||
|
||||
|
||||
Output Overlay
|
||||
--------------
|
||||
|
||||
@@ -1405,8 +1352,6 @@ Just as a reminder and in no particular order:
|
||||
- Add ARGB888 overlay support: better testing of the alpha channel
|
||||
- Improve pixel aspect support in the tpg code by passing a real v4l2_fract
|
||||
- Use per-queue locks and/or per-device locks to improve throughput
|
||||
- Add support to loop from a specific output to a specific input across
|
||||
vivid instances
|
||||
- The SDR radio should use the same 'frequencies' for stations as the normal
|
||||
radio receiver, and give back noise if the frequency doesn't match up with
|
||||
a station frequency
|
||||
|
||||
@@ -0,0 +1,112 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
# Copyright (c) 2023 MediaTek Inc.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc05a2.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: GalaxyCore gc05a2 1/5" 5M Pixel MIPI CSI-2 sensor
|
||||
|
||||
maintainers:
|
||||
- Zhi Mao <zhi.mao@mediatek.com>
|
||||
|
||||
description:
|
||||
The gc05a2 is a raw image sensor with an MIPI CSI-2 image data
|
||||
interface and CCI (I2C compatible) control bus. The output format
|
||||
is raw Bayer.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: galaxycore,gc05a2
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
dovdd-supply: true
|
||||
|
||||
avdd-supply: true
|
||||
|
||||
dvdd-supply: true
|
||||
|
||||
reset-gpios:
|
||||
description: Reference to the GPIO connected to the RESETB pin.
|
||||
maxItems: 1
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
additionalProperties: false
|
||||
description:
|
||||
Output port node, single endpoint describing the CSI-2 transmitter.
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
- items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
|
||||
link-frequencies: true
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
- link-frequencies
|
||||
|
||||
required:
|
||||
- endpoint
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- dovdd-supply
|
||||
- avdd-supply
|
||||
- dvdd-supply
|
||||
- reset-gpios
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@37 {
|
||||
compatible = "galaxycore,gc05a2";
|
||||
reg = <0x37>;
|
||||
|
||||
clocks = <&gc05a2_clk>;
|
||||
|
||||
reset-gpios = <&pio 21 GPIO_ACTIVE_LOW>;
|
||||
|
||||
avdd-supply = <&gc05a2_avdd>;
|
||||
dovdd-supply = <&gc05a2_dovdd>;
|
||||
dvdd-supply = <&gc05a2_dvdd>;
|
||||
|
||||
port {
|
||||
sensor_out: endpoint {
|
||||
data-lanes = <1 2>;
|
||||
link-frequencies = /bits/ 64 <448000000 224000000>;
|
||||
remote-endpoint = <&seninf_csi_port_1_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@@ -0,0 +1,112 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
# Copyright (c) 2023 MediaTek Inc.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc08a3.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: GalaxyCore gc08a3 1/4" 8M Pixel MIPI CSI-2 sensor
|
||||
|
||||
maintainers:
|
||||
- Zhi Mao <zhi.mao@mediatek.com>
|
||||
|
||||
description:
|
||||
The gc08a3 is a raw image sensor with an MIPI CSI-2 image data
|
||||
interface and CCI (I2C compatible) control bus. The output format
|
||||
is raw Bayer.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: galaxycore,gc08a3
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
dovdd-supply: true
|
||||
|
||||
avdd-supply: true
|
||||
|
||||
dvdd-supply: true
|
||||
|
||||
reset-gpios:
|
||||
description: Reference to the GPIO connected to the RESETB pin.
|
||||
maxItems: 1
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
additionalProperties: false
|
||||
description:
|
||||
Output port node, single endpoint describing the CSI-2 transmitter.
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
- items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
|
||||
link-frequencies: true
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
- link-frequencies
|
||||
|
||||
required:
|
||||
- endpoint
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- dovdd-supply
|
||||
- avdd-supply
|
||||
- dvdd-supply
|
||||
- reset-gpios
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@31 {
|
||||
compatible = "galaxycore,gc08a3";
|
||||
reg = <0x31>;
|
||||
|
||||
clocks = <&gc08a3_clk>;
|
||||
|
||||
reset-gpios = <&pio 19 GPIO_ACTIVE_LOW>;
|
||||
|
||||
avdd-supply = <&gc08a3_avdd>;
|
||||
dovdd-supply = <&gc08a3_dovdd>;
|
||||
dvdd-supply = <&gc08a3_dvdd>;
|
||||
|
||||
port {
|
||||
sensor_out: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
link-frequencies = /bits/ 64 <336000000 207000000>;
|
||||
remote-endpoint = <&seninf_csi_port_0_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
174
Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml
Normal file
174
Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml
Normal file
@@ -0,0 +1,174 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2024 Collabora Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/maxim,max96714.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Maxim MAX96714 GMSL2 to CSI-2 Deserializer
|
||||
|
||||
maintainers:
|
||||
- Julien Massot <julien.massot@collabora.com>
|
||||
|
||||
description:
|
||||
The MAX96714 deserializer converts GMSL2 serial inputs into MIPI
|
||||
CSI-2 D-PHY formatted output. The device allows the GMSL2 link to
|
||||
simultaneously transmit bidirectional control-channel data while forward
|
||||
video transmissions are in progress. The MAX96714 can connect to one
|
||||
remotely located serializer using industry-standard coax or STP
|
||||
interconnects. The device cans operate in pixel or tunnel mode. In pixel mode
|
||||
the MAX96714 can select individual video stream, while the tunnel mode forward all
|
||||
the MIPI data received by the serializer.
|
||||
|
||||
The GMSL2 serial link operates at a fixed rate of 3Gbps or 6Gbps in the
|
||||
forward direction and 187.5Mbps in the reverse direction.
|
||||
MAX96714F only supports a fixed rate of 3Gbps in the forward direction.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: maxim,max96714f
|
||||
- items:
|
||||
- enum:
|
||||
- maxim,max96714
|
||||
- const: maxim,max96714f
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
powerdown-gpios:
|
||||
maxItems: 1
|
||||
description:
|
||||
Specifier for the GPIO connected to the PWDNB pin.
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
unevaluatedProperties: false
|
||||
description: GMSL Input
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Endpoint for GMSL2-Link port.
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
unevaluatedProperties: false
|
||||
description: CSI-2 Output port
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
lane-polarities:
|
||||
minItems: 1
|
||||
maxItems: 5
|
||||
|
||||
link-frequencies:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
|
||||
required:
|
||||
- port@1
|
||||
|
||||
i2c-gate:
|
||||
$ref: /schemas/i2c/i2c-gate.yaml
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
The MAX96714 will pass through and forward the I2C requests from the
|
||||
incoming I2C bus over the GMSL2 link. Therefore it supports an i2c-gate
|
||||
subnode to configure a serializer.
|
||||
|
||||
port0-poc-supply:
|
||||
description: Regulator providing Power over Coax for the GMSL port
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- ports
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/media/video-interfaces.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
deserializer@28 {
|
||||
compatible = "maxim,max96714f";
|
||||
reg = <0x28>;
|
||||
powerdown-gpios = <&main_gpio0 37 GPIO_ACTIVE_LOW>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
max96714_gmsl_in: endpoint {
|
||||
remote-endpoint = <&max96917f_gmsl_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
max96714_csi_out: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
link-frequencies = /bits/ 64 <400000000>;
|
||||
remote-endpoint = <&csi_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c-gate {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
serializer@40 {
|
||||
compatible = "maxim,max96717f";
|
||||
reg = <0x40>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
#clock-cells = <0>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
max96717f_csi_in: endpoint {
|
||||
data-lanes = <1 2>;
|
||||
lane-polarities = <1 0 1>;
|
||||
remote-endpoint = <&sensor_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
max96917f_gmsl_out: endpoint {
|
||||
remote-endpoint = <&max96714_gmsl_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
157
Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml
Normal file
157
Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml
Normal file
@@ -0,0 +1,157 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2024 Collabora Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/maxim,max96717.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MAX96717 CSI-2 to GMSL2 Serializer
|
||||
|
||||
maintainers:
|
||||
- Julien Massot <julien.massot@collabora.com>
|
||||
|
||||
description:
|
||||
The MAX96717 serializer converts MIPI CSI-2 D-PHY formatted input
|
||||
into GMSL2 serial outputs. The device allows the GMSL2 link to
|
||||
simultaneously transmit bidirectional control-channel data while forward
|
||||
video transmissions are in progress. The MAX96717 can connect to one
|
||||
remotely located deserializer using industry-standard coax or STP
|
||||
interconnects. The device cans operate in pixel or tunnel mode. In pixel mode
|
||||
the MAX96717 can select the MIPI datatype, while the tunnel mode forward all the MIPI
|
||||
data received by the serializer.
|
||||
The MAX96717 supports Reference Over Reverse (channel),
|
||||
to generate a clock output for the sensor from the GMSL reverse channel.
|
||||
|
||||
The GMSL2 serial link operates at a fixed rate of 3Gbps or 6Gbps in the
|
||||
forward direction and 187.5Mbps in the reverse direction.
|
||||
MAX96717F only supports a fixed rate of 3Gbps in the forward direction.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: maxim,max96717f
|
||||
- items:
|
||||
- enum:
|
||||
- maxim,max96717
|
||||
- const: maxim,max96717f
|
||||
|
||||
'#gpio-cells':
|
||||
const: 2
|
||||
description:
|
||||
First cell is the GPIO pin number, second cell is the flags. The GPIO pin
|
||||
number must be in range of [0, 10].
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
'#clock-cells':
|
||||
const: 0
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
unevaluatedProperties: false
|
||||
description: CSI-2 Input port
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
lane-polarities:
|
||||
minItems: 1
|
||||
maxItems: 5
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
unevaluatedProperties: false
|
||||
description: GMSL Output port
|
||||
|
||||
required:
|
||||
- port@1
|
||||
|
||||
i2c-gate:
|
||||
$ref: /schemas/i2c/i2c-gate.yaml
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
The MAX96717 will forward the I2C requests from the
|
||||
incoming GMSL2 link. Therefore, it supports an i2c-gate
|
||||
subnode to configure a sensor.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- ports
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/media/video-interfaces.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
serializer: serializer@40 {
|
||||
compatible = "maxim,max96717f";
|
||||
reg = <0x40>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
#clock-cells = <0>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
max96717f_csi_in: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
remote-endpoint = <&sensor_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
max96917f_gmsl_out: endpoint {
|
||||
remote-endpoint = <&deser_gmsl_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c-gate {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
sensor@10 {
|
||||
compatible = "st,st-vgxy61";
|
||||
reg = <0x10>;
|
||||
reset-gpios = <&serializer 0 GPIO_ACTIVE_LOW>;
|
||||
clocks = <&serializer>;
|
||||
VCORE-supply = <&v1v2>;
|
||||
VDDIO-supply = <&v1v8>;
|
||||
VANA-supply = <&v2v8>;
|
||||
port {
|
||||
sensor_out: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
remote-endpoint = <&max96717f_csi_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/imx258.yaml#
|
||||
$id: http://devicetree.org/schemas/media/i2c/sony,imx258.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Sony IMX258 13 Mpixel CMOS Digital Image Sensor
|
||||
@@ -13,11 +13,16 @@ description: |-
|
||||
IMX258 is a diagonal 5.867mm (Type 1/3.06) 13 Mega-pixel CMOS active pixel
|
||||
type stacked image sensor with a square pixel array of size 4208 x 3120. It
|
||||
is programmable through I2C interface. Image data is sent through MIPI
|
||||
CSI-2.
|
||||
CSI-2. The sensor exists in two different models, a standard variant
|
||||
(IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
|
||||
The camera module does not expose the model through registers, so the
|
||||
exact model needs to be specified.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: sony,imx258
|
||||
enum:
|
||||
- sony,imx258
|
||||
- sony,imx258-pdaf
|
||||
|
||||
assigned-clocks: true
|
||||
assigned-clock-parents: true
|
||||
107
Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml
Normal file
107
Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml
Normal file
@@ -0,0 +1,107 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2024 Ideas on Board Oy
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/sony,imx283.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Sony IMX283 Sensor
|
||||
|
||||
maintainers:
|
||||
- Kieran Bingham <kieran.bingham@ideasonboard.com>
|
||||
- Umang Jain <umang.jain@ideasonboard.com>
|
||||
|
||||
description:
|
||||
IMX283 sensor is a Sony CMOS active pixel digital image sensor with an active
|
||||
array size of 5472H x 3648V. It is programmable through I2C interface. The
|
||||
I2C client address is fixed to 0x1a as per sensor data sheet. Image data is
|
||||
sent through MIPI CSI-2.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: sony,imx283
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
description: Clock frequency from 6 to 24 MHz.
|
||||
maxItems: 1
|
||||
|
||||
vadd-supply:
|
||||
description: Analog power supply (2.9V)
|
||||
|
||||
vdd1-supply:
|
||||
description: Interface power supply (1.8V)
|
||||
|
||||
vdd2-supply:
|
||||
description: Digital power supply (1.2V)
|
||||
|
||||
reset-gpios:
|
||||
description: Sensor reset (XCLR) GPIO
|
||||
maxItems: 1
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
anyOf:
|
||||
- items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
|
||||
link-frequencies: true
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
- link-frequencies
|
||||
|
||||
required:
|
||||
- endpoint
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
camera@1a {
|
||||
compatible = "sony,imx283";
|
||||
reg = <0x1a>;
|
||||
clocks = <&imx283_clk>;
|
||||
|
||||
assigned-clocks = <&imx283_clk>;
|
||||
assigned-clock-parents = <&imx283_clk_parent>;
|
||||
assigned-clock-rates = <12000000>;
|
||||
|
||||
vadd-supply = <&camera_vadd_2v9>;
|
||||
vdd1-supply = <&camera_vdd1_1v8>;
|
||||
vdd2-supply = <&camera_vdd2_1v2>;
|
||||
|
||||
port {
|
||||
imx283: endpoint {
|
||||
remote-endpoint = <&cam>;
|
||||
data-lanes = <1 2 3 4>;
|
||||
link-frequencies = /bits/ 64 <360000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@@ -0,0 +1,75 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/img,e5010-jpeg-enc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Imagination E5010 JPEG Encoder
|
||||
|
||||
maintainers:
|
||||
- Devarsh Thakkar <devarsht@ti.com>
|
||||
|
||||
description: |
|
||||
The E5010 is a JPEG encoder from Imagination Technologies implemented on
|
||||
TI's AM62A SoC. It is capable of real time encoding of YUV420 and YUV422
|
||||
inputs to JPEG and M-JPEG. It supports baseline JPEG Encoding up to
|
||||
8Kx8K resolution.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: ti,am62a-jpeg-enc
|
||||
- const: img,e5010-jpeg-enc
|
||||
- const: img,e5010-jpeg-enc
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: The E5010 core register region
|
||||
- description: The E5010 mmu register region
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: core
|
||||
- const: mmu
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- interrupts
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/soc/ti,sci_pm_domain.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
soc {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
jpeg-encoder@fd20000 {
|
||||
compatible = "img,e5010-jpeg-enc";
|
||||
reg = <0x00 0xfd20000 0x00 0x100>,
|
||||
<0x00 0xfd20200 0x00 0x200>;
|
||||
reg-names = "core", "mmu";
|
||||
clocks = <&k3_clks 201 0>;
|
||||
power-domains = <&k3_pds 201 TI_SCI_PD_EXCLUSIVE>;
|
||||
interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
};
|
||||
@@ -23,6 +23,7 @@ properties:
|
||||
oneOf:
|
||||
- enum:
|
||||
- mediatek,mt8183-mdp3-rdma
|
||||
- mediatek,mt8188-mdp3-rdma
|
||||
- mediatek,mt8195-mdp3-rdma
|
||||
- mediatek,mt8195-vdo1-rdma
|
||||
- items:
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Consumer Infrared Receiver on-SoC Controller
|
||||
|
||||
maintainers:
|
||||
- Sean Wang <sean.wang@mediatek.com>
|
||||
|
||||
allOf:
|
||||
- $ref: rc.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- mediatek,mt7622-cir
|
||||
- mediatek,mt7623-cir
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: clk
|
||||
- const: bus
|
||||
|
||||
required:
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/mt2701-clk.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
ir@10013000 {
|
||||
compatible = "mediatek,mt7623-cir";
|
||||
reg = <0x10013000 0x1000>;
|
||||
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
|
||||
clocks = <&infracfg CLK_INFRA_IRRX>, <&topckgen CLK_TOP_AXI_SEL>;
|
||||
clock-names = "clk", "bus";
|
||||
linux,rc-map-name = "rc-rc6-mce";
|
||||
};
|
||||
@@ -1,28 +0,0 @@
|
||||
Device-Tree bindings for Mediatek consumer IR controller
|
||||
found in Mediatek SoC family
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be
|
||||
"mediatek,mt7623-cir": for MT7623 SoC
|
||||
"mediatek,mt7622-cir": for MT7622 SoC
|
||||
- clocks : list of clock specifiers, corresponding to
|
||||
entries in clock-names property;
|
||||
- clock-names : should contain
|
||||
- "clk" entries: for MT7623 SoC
|
||||
- "clk", "bus" entries: for MT7622 SoC
|
||||
- interrupts : should contain IR IRQ number;
|
||||
- reg : should contain IO map address for IR.
|
||||
|
||||
Optional properties:
|
||||
- linux,rc-map-name : see rc.txt file in the same directory.
|
||||
|
||||
Example:
|
||||
|
||||
cir: cir@10013000 {
|
||||
compatible = "mediatek,mt7623-cir";
|
||||
reg = <0 0x10013000 0 0x1000>;
|
||||
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
|
||||
clocks = <&infracfg CLK_INFRA_IRRX>;
|
||||
clock-names = "clk";
|
||||
linux,rc-map-name = "rc-rc6-mce";
|
||||
};
|
||||
@@ -18,7 +18,9 @@ allOf:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,msm8996-venus
|
||||
enum:
|
||||
- qcom,msm8996-venus
|
||||
- qcom,msm8998-venus
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
@@ -0,0 +1,63 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/raspberrypi,pispbe.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Raspberry Pi PiSP Image Signal Processor (ISP) Back End
|
||||
|
||||
maintainers:
|
||||
- Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
|
||||
- Jacopo Mondi <jacopo.mondi@ideasonboard.com>
|
||||
|
||||
description: |
|
||||
The Raspberry Pi PiSP Image Signal Processor (ISP) Back End is an image
|
||||
processor that fetches images in Bayer or Grayscale format from DRAM memory
|
||||
in tiles and produces images consumable by applications.
|
||||
|
||||
The full ISP documentation is available at
|
||||
https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm2712-pispbe
|
||||
- const: raspberrypi,pispbe
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
soc {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
isp@880000 {
|
||||
compatible = "brcm,bcm2712-pispbe", "raspberrypi,pispbe";
|
||||
reg = <0x10 0x00880000 0x0 0x4000>;
|
||||
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&firmware_clocks 7>;
|
||||
iommus = <&iommu2>;
|
||||
};
|
||||
};
|
||||
@@ -103,6 +103,7 @@ properties:
|
||||
- rc-msi-digivox-iii
|
||||
- rc-msi-tvanywhere
|
||||
- rc-msi-tvanywhere-plus
|
||||
- rc-mygica-utv3
|
||||
- rc-nebula
|
||||
- rc-nec-terratec-cinergy-xs
|
||||
- rc-norwood
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user