* [PATCH 02/15] drm/vc4: hdmi: Move hdmi reset to bind
From: Maxime Ripard @ 2020-12-10 13:46 UTC (permalink / raw)
To: Eric Anholt, Maarten Lankhorst, Thomas Zimmermann, Maxime Ripard,
Daniel Vetter, David Airlie
Cc: Jason Cooper, bcm-kernel-feedback-list, linux-arm-kernel,
Marc Zyngier, linux-media, Hans Verkuil, linux-kernel,
Mauro Carvalho Chehab, Thomas Gleixner, Dave Stevenson,
linux-rpi-kernel, dri-devel, Dom Cobley
In-Reply-To: <20201210134648.272857-1-maxime@cerno.tech>
From: Dom Cobley <popcornmix@gmail.com>
The hdmi reset got moved to a later point in the commit 9045e91a476b
("drm/vc4: hdmi: Add reset callback").
However, the reset now occurs after vc4_hdmi_cec_init and so tramples
the setup of registers like HDMI_CEC_CNTRL_1
This only affects pi0-3 as on pi4 the cec registers are in a separate
block
Fixes: 9045e91a476b ("drm/vc4: hdmi: Add reset callback")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 8006bddc8fbb..3df1747dd917 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -773,9 +773,6 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
return;
}
- if (vc4_hdmi->variant->reset)
- vc4_hdmi->variant->reset(vc4_hdmi);
-
if (vc4_hdmi->variant->phy_init)
vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
@@ -1865,6 +1862,9 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
vc4_hdmi->disable_wifi_frequencies =
of_property_read_bool(dev->of_node, "wifi-2.4ghz-coexistence");
+ if (vc4_hdmi->variant->reset)
+ vc4_hdmi->variant->reset(vc4_hdmi);
+
pm_runtime_enable(dev);
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
--
2.28.0
^ permalink raw reply related
* [PATCH 01/15] irqchip: Allow to compile bcmstb on other platforms
From: Maxime Ripard @ 2020-12-10 13:46 UTC (permalink / raw)
To: Eric Anholt, Maarten Lankhorst, Thomas Zimmermann, Maxime Ripard,
Daniel Vetter, David Airlie
Cc: Jason Cooper, bcm-kernel-feedback-list, linux-arm-kernel,
Marc Zyngier, linux-media, Hans Verkuil, linux-kernel,
Mauro Carvalho Chehab, Thomas Gleixner, Dave Stevenson,
linux-rpi-kernel, dri-devel
In-Reply-To: <20201210134648.272857-1-maxime@cerno.tech>
The BCM2711 uses a number of instances of the bcmstb-l2 controller in its
display engine. Let's allow the driver to be enabled through KConfig.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
drivers/irqchip/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index c6098eee0c7c..f1e58de117dc 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -131,7 +131,7 @@ config BCM7120_L2_IRQ
select IRQ_DOMAIN
config BRCMSTB_L2_IRQ
- bool
+ bool "Broadcom STB L2 Interrupt Controller"
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
--
2.28.0
^ permalink raw reply related
* Re: [PATCH v5 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
From: Andy Shevchenko @ 2020-12-10 14:08 UTC (permalink / raw)
To: Sakari Ailus
Cc: Petr Mladek, Linux Kernel Mailing List, Linux Media Mailing List,
Dave Stevenson, dri-devel, Hans Verkuil, Laurent Pinchart,
Mauro Carvalho Chehab, Sergey Senozhatsky, Steven Rostedt,
Joe Perches, Jani Nikula, Rasmus Villemoes
In-Reply-To: <20201210135526.GH25763@paasikivi.fi.intel.com>
On Thu, Dec 10, 2020 at 03:55:27PM +0200, Sakari Ailus wrote:
> On Thu, Dec 10, 2020 at 03:05:02PM +0200, Andy Shevchenko wrote:
> > On Thu, Dec 10, 2020 at 2:16 PM Petr Mladek <pmladek@suse.com> wrote:
> > > On Fri 2020-11-13 12:54:41, Sakari Ailus wrote:
> > > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > > > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > > > so the same implementation can be used.
> > > >
> > > > Suggested-by: Mauro Carvalho Chehab <mchehab@kernel.org>
> > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > >
> > > Andy, Rasmus,
> > >
> > > the last version looks fine to me. I am going to push it.
> > > Please, speak up if you are against it.
> >
> > My concerns are:
> > - not so standard format of representation (why not to use
> > string_escape_mem() helper?) or is it?
>
> The format string may contain spaces that are not meant to be printed.
> Other unprintable chacaters should not be present (at least not in V4L2
> pixelformats). The hexadecimal representation is there to convey the
> numerical value and that originally came from DRM, not V4L2.
Yes, but I mean that we usually anticipate the escaped characters in a form of
'\xNN' (hex) or '\NNN' (octal). The format '(NN)' is quite unusual to me.
> > - no compatibility with generic 4cc
> > (I would rather have an additional specifier here for v4l2 cases.
>
> What do you mean by "generic 4cc"? There are two users of 4cc codes in the
> kernel that I know of: V4L2 and DRM. Something that does not refer to
> in-memory pixel formats?
Of course. Everything else. 4cc is a generic term to describe something which
is of 4 characters long [1]. It's not limited by media file formats. And
moreover some (chip) vendors are using it as well (Synopsys).
Microsoft uses 4cc in CSRT ACPI table for vendor field and so on...
[1]: https://en.wikipedia.org/wiki/FourCC
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 01/13] docs: conf.py: fix sphinx version detection for margin set
From: Jonathan Corbet @ 2020-12-10 14:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, linuxarm, mauro.chehab, linux-doc,
linux-kernel
In-Reply-To: <0e610cbb57e85864b23d2b8fffa65c6b137daaac.1607597287.git.mchehab+huawei@kernel.org>
On Thu, 10 Dec 2020 11:55:40 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> The PDF generator has a logic to detect the proper way to
> setup the page margins. By default, the page has about
> 14.8 cm, which is too short to display some tables and literal
> blocks. So, previous patches changed it to be around 17.5 cm,
> but the logic only works with Sphinx version 1.x.x.
>
> Fix it.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Feel free to route this one with the rest of the set.
Someday it might be nice to isolate all of the latex stuff into
conf-latex.py or some such so most of us don't have to look at it..:)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 4/4] dma-heap: Devicetree binding for chunk heap
From: Minchan Kim @ 2020-12-10 16:06 UTC (permalink / raw)
To: John Stultz
Cc: Hyesoo Yu, Andrew Morton, LKML, linux-mm, Matthew Wilcox, david,
iamjoonsoo.kim, vbabka, Suren Baghdasaryan, KyongHo Cho,
John Dias, Hridya Valsaraju, Sumit Semwal, Brian Starkey,
linux-media,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Christian Koenig,
moderated list:DMA BUFFER SHARING FRAMEWORK, Kunihiko Hayashi
In-Reply-To: <CALAqxLWthd8bEDRMWmuOf8dOCW8=cFao9HBawKGuRhQZkdgXXw@mail.gmail.com>
On Thu, Dec 10, 2020 at 12:15:15AM -0800, John Stultz wrote:
> On Wed, Dec 9, 2020 at 3:53 PM Minchan Kim <minchan@kernel.org> wrote:
> > On Wed, Nov 18, 2020 at 07:19:07PM -0800, John Stultz wrote:
> > > The CMA heap currently only registers the default CMA heap, as we
> > > didn't want to expose all CMA regions and there's otherwise no way to
> > > pick and choose.
> >
> > Yub.
> >
> > dma-buf really need a way to make exclusive CMA area. Otherwise, default
> > CMA would be shared among drivers and introduce fragmentation easily
> > since we couldn't control other drivers. In such aspect, I don't think
> > current cma-heap works if userspace needs big memory chunk.
>
> Yes, the default CMA region is not always optimal.
>
> That's why I was hopeful for Kunihiko Hayashi's patch to allow for
> exposing specific cma regions:
> https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunihiko@socionext.com/
>
> I think it would be a good solution, but all we need is *some* driver
> which can be considered the primary user/owner of the cma region which
> would then explicitly export it via the dmabuf heaps.
>
> > Here, the problem is there is no in-kernel user to bind the specific
> > CMA area because the owner will be random in userspace via dma-buf
> > interface.
>
> Well, while I agree that conceptually the dmabuf heaps allow for
> allocations for multi-device pipelines, and thus are not tied to
> specific devices. I do think that the memory types exposed are likely
> to have specific devices/drivers in the pipeline that it matters most
> to. So I don't see a big issue with the in-kernel driver registering a
> specific CMA region as a dmabuf heap.
Then, I am worry about that we spread out dma_heap_add_cma to too many
drivers since kernel doesn't how userspace will use it.
For example, system 1 could have device A-B-C pipeline so they added
it A driver. After that, system 2 could have device B-C-D pipeline
so they add dma_heap_add_cma into B device.
>
> > > > Is there a reason to use dma-heap framework to add cma-area for specific device ?
> > > >
> > > > Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices.
> > > > For exclusive access, I guess, the device don't need to register dma-heap for cma area.
> > > >
> > >
> > > It's not really about exclusive access. More just that if you want to
> > > bind a memory reservation/region (cma or otherwise), at least for DTS,
> > > it needs to bind with some device in DT.
> > >
> > > Then the device driver can register that region with a heap driver.
> > > This avoids adding new Linux-specific software bindings to DT. It
> > > becomes a driver implementation detail instead. The primary user of
> > > the heap type would probably be a practical pick (ie the display or
> > > isp driver).
> >
> > If it's the only solution, we could create some dummy driver which has
> > only module_init and bind it from there but I don't think it's a good
> > idea.
>
> Yea, an un-upstreamable dummy driver is maybe what it devolves to in
> the worst case. But I suspect it would be cleaner for a display or ISP
> driver that benefits most from the heap type to add the reserved
> memory reference to their DT node, and on init for them to register
> the region with the dmabuf heap code.
As I mentioned above, it could be a display at this moment but it could
be different driver next time. If I miss your point, let me know.
Thanks for the review, John.
>
>
> > > The other potential solution Rob has suggested is that we create some
> > > tag for the memory reservation (ie: like we do with cma: "reusable"),
> > > which can be used to register the region to a heap. But this has the
> > > problem that each tag has to be well defined and map to a known heap.
> >
> > Do you think that's the only solution to make progress for this feature?
> > Then, could you elaborate it a bit more or any other ideas from dma-buf
> > folks?
>
> I'm skeptical of that DT tag approach working out, as we'd need a new
> DT binding for the new tag name, and we'd have to do so for each new
> heap type that needs this (so non-default cma, your chunk heap,
> whatever other similar heap types that use reserved regions folks come
> up with). Having *some* driver take ownership for the reserved region
> and register it with the appropriate heap type seems much
> cleaner/flexible and avoids mucking with the DT ABI.
>
> thanks
> -john
^ permalink raw reply
* Re: [PATCH RFC] docs: experimental: build PDF with rst2pdf
From: Mauro Carvalho Chehab @ 2020-12-10 16:29 UTC (permalink / raw)
To: Jonathan Corbet, Linux Doc Mailing List
Cc: Masahiro Yamada, Mauro Carvalho Chehab, Michal Marek,
linux-kbuild, linux-kernel, linux-media
In-Reply-To: <a29b97f95cae490cb83da28410fade13d880f365.1607616056.git.mchehab+huawei@kernel.org>
Em Thu, 10 Dec 2020 17:01:19 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
> Add an experimental PDF builder using rst2pdf
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
I opened an issue at:
https://github.com/rst2pdf/rst2pdf/issues/958
Let's hope someone at rst2pdf could help fixing this ;-)
Regards,
Mauro
> ---
> Documentation/Makefile | 5 +++++
> Documentation/conf.py | 21 +++++++++++++++------
> Documentation/userspace-api/media/Makefile | 1 +
> Makefile | 4 ++--
> 4 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 61a7310b49e0..c3c8fb10f94e 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -115,6 +115,10 @@ pdfdocs: latexdocs
>
> endif # HAVE_PDFLATEX
>
> +rst2pdf:
> + @$(srctree)/scripts/sphinx-pre-install --version-check
> + @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,pdf,$(var),pdf,$(var)))
> +
> epubdocs:
> @$(srctree)/scripts/sphinx-pre-install --version-check
> @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,epub,$(var),epub,$(var)))
> @@ -140,6 +144,7 @@ dochelp:
> @echo ' htmldocs - HTML'
> @echo ' latexdocs - LaTeX'
> @echo ' pdfdocs - PDF'
> + @echo ' rst2pdf - PDF, using experimental rst2pdf support'
> @echo ' epubdocs - EPUB'
> @echo ' xmldocs - XML'
> @echo ' linkcheckdocs - check for broken external links'
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 66e121df59cd..6f2788aac81e 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -123,6 +123,12 @@ if (major == 1 and minor > 3) or (major > 1):
> else:
> extensions.append("sphinx.ext.pngmath")
>
> +# Enable experimental rst2pdf, if available
> +try:
> + extensions.append("rst2pdf.pdfbuilder")
> +except:
> + sys.stderr.write('rst2pdf extension not available.\n')
> +
> # Add any paths that contain templates here, relative to this directory.
> templates_path = ['_templates']
>
> @@ -614,12 +620,15 @@ epub_exclude_files = ['search.html']
> #
> # See the Sphinx chapter of https://ralsina.me/static/manual.pdf
> #
> -# FIXME: Do not add the index file here; the result will be too big. Adding
> -# multiple PDF files here actually tries to get the cross-referencing right
> -# *between* PDF files.
> -pdf_documents = [
> - ('kernel-documentation', u'Kernel', u'Kernel', u'J. Random Bozo'),
> -]
> +
> +# Add all LaTeX files to PDF documents as well
> +pdf_documents = []
> +for l in latex_documents:
> + doc = l[0]
> + fn = l[1].replace(".tex", "")
> + name = l[2]
> + authors = l[3]
> + pdf_documents.append((doc, fn, name, authors))
>
> # kernel-doc extension configuration for running Sphinx directly (e.g. by Read
> # the Docs). In a normal build, these are supplied from the Makefile via command
> diff --git a/Documentation/userspace-api/media/Makefile b/Documentation/userspace-api/media/Makefile
> index 81a4a1a53bce..8c6b3ac4ecb0 100644
> --- a/Documentation/userspace-api/media/Makefile
> +++ b/Documentation/userspace-api/media/Makefile
> @@ -59,6 +59,7 @@ all: $(IMGDOT) $(BUILDDIR) ${TARGETS}
> html: all
> epub: all
> xml: all
> +pdf: all
> latex: $(IMGPDF) all
> linkcheck:
>
> diff --git a/Makefile b/Makefile
> index 43ecedeb3f02..db4043578eec 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -264,7 +264,7 @@ no-dot-config-targets := $(clean-targets) \
> cscope gtags TAGS tags help% %docs check% coccicheck \
> $(version_h) headers headers_% archheaders archscripts \
> %asm-generic kernelversion %src-pkg dt_binding_check \
> - outputmakefile
> + outputmakefile rst2pdf
> no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease
> single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
>
> @@ -1654,7 +1654,7 @@ $(help-board-dirs): help-%:
>
> # Documentation targets
> # ---------------------------------------------------------------------------
> -DOC_TARGETS := xmldocs latexdocs pdfdocs htmldocs epubdocs cleandocs \
> +DOC_TARGETS := xmldocs latexdocs pdfdocs rst2pdf htmldocs epubdocs cleandocs \
> linkcheckdocs dochelp refcheckdocs
> PHONY += $(DOC_TARGETS)
> $(DOC_TARGETS):
Thanks,
Mauro
^ permalink raw reply
* Re: question: CSI on imx8mq with (any) CSI2 camera / experience with mx6s_capture?
From: Laurent Pinchart @ 2020-12-10 16:04 UTC (permalink / raw)
To: Martin Kepplinger
Cc: rogerio.silva@nxp.com, Philipp Zabel, slongerbeam@gmail.com,
Fabio Estevam, linux-arm-kernel@lists.infradead.org, linux-media,
NXP Linux Team, kernel@puri.sm, Pengutronix Kernel Team
In-Reply-To: <195b62c5-5238-a75e-3206-c54efc309e94@puri.sm>
Hi Martin,
On Thu, Dec 10, 2020 at 02:12:30PM +0100, Martin Kepplinger wrote:
> On 10.12.20 13:17, Laurent Pinchart wrote:
> > On Thu, Dec 10, 2020 at 11:24:00AM +0200, Laurent Pinchart wrote:
> >> On Thu, Dec 10, 2020 at 09:17:48AM +0100, Martin Kepplinger wrote:
> >>> hi,
> >>>
> >>> TL;DR: did you use the NXP "mx6s_capture" csi bridge driver with other
> >>> cameras?
> >>
> >> I've recently worked on camera support for i.MX8MM (whose camera IP
> >> cores are, if not identical, very similar to the i.MX8MQ's). The least I
> >> can say is that it was painful :-(
> >>
> >> I'm using an MT9M114 sensor, which can produce RAW8, RAW10 and YUV and
> >> has a CSI-2 interface. My first use case is to capture RAW10, which
> >> isn't supported by the mx6s_capture driver.
>
> so did you successfully use the NXP mx6s_capture driver with that sensor
> too?
I haven't tried. The mx6s_capture driver and the mainline driver share a
similar architecture, as they came from the same code base. They have
diverged, with the mainline driver receiving bug fixes and new
features, and my large no-yet-upstreamed patch series adds lots of fixes
that are required for the mt9m114 driver to work with the driver. For
that reason, I've considered that porting the mt9m114 driver to the NXP
mx6s_capture, and fixing the same issues in the mx6s_capture driver than
were present in the mainline driver, would require lots of time for
likely very little gain.
That being said, I've compared the two drivers, and I haven't seen
anything in mx6s_capture that would address the specific issues I'm
facing. I've ordered yesterday an i.MX8MM EVK with an OV5640 camera
module, and I will test those with the mainline driver. If they don't
work, and assuming the NXP kernel driver works on that platform, I'll
have two code bases to compare.
> >>> I try to use a CSI2 camera (hi846 I'm writing a driver for) on imx8mq:
> >>> Using NXP's CSI bridge driver
> >>> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/media/platform/mxc/capture/mx6s_capture.c?h=imx_5.4.0_8dxlphantom_er
> >>> as well as the CSI driver itself:
> >>> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/media/platform/imx8/mxc-mipi-csi2_yav.c?h=imx_5.4.0_8dxlphantom_er
> >>> works fine when using the ov5640 camera with this driver:
> >>> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/media/platform/mxc/capture/ov5640_mipi_v2.c?h=imx_5.4.0_8dxlphantom_er
> >>>
> >>> (I realize there is a CSI bridge driver in staging, but that need more
> >>> work to be actually used. Of course after this the goal is to fix and
> >>> use it; and mainline a CSI phy driver too.)
> >>
> >> I have lots of patches for this driver, which I've developed on i.MX7D
> >> for a separate project. I'd like to mainline them, but this is blocked
> >> by one last issue that I haven't been able to solve yet. In a nutshell,
> >> the CSI writes two consecutive frames in each buffer, overflowing the
> >> allocated memory. The registers that control the buffer size seem to be
> >> programmed correctly as far as I can tell. I've reported this issue to
> >> NXP but haven't received any feedback yet.
>
> that's different from where I am. So you don't get any interrupt (EOF or
> other) when only *one* frame is written into one buffer?
I don't get any FB1_DMA_DONE or FB2_DMA_DONE interrupt at least. I
haven't checked other interrupts. I thus get half of the frame rate. If
I configure the CSI_CSIIMAG_PARA register with half of the actual image
height, buffers then contain a single image and the frame rate goes to
the expected value. That gives me a workaround, but without
understanding the root cause, I'm worried that just halving the height
would introduce other breakages.
> >> I've also added support for i.MX8MM to this driver, but haven't been
> >> able to capture RAW8, RAW10 or YUV successfully. YUV produces the "best
> >> images", but seems to drop 3 out of 4 consecutive pixels. The sensor
> >> driver has been tested successfully on i.MX6 so I don't think it's the
> >> most likely cause of issues, but I can't rule out bugs on that side
> >> either. The i.MX8 reference manuals describe the MIPI_CSI and CSI IP
> >> cores but doesn't tell much about how the two are connected, so I have
> >> lots of unanswered questions about the register fields that control the
> >> interface between those IP cores. I'm pretty sure there are issues in
> >> that area of the drivers, but I've tested all combinations I could think
> >> of, without luck.
> >>
> >>> Now I use said NXP's CSI drivers on mainline without problems with the
> >>> ov5640. For the hi846 (as an example), I want to use a different
> >>> pixelformat and CSI media bus format. Describing, say,
> >>> MEDIA_BUS_FMT_SBGGR10_1X10 in the driver lets mx6s_capture find it; but
> >>> as soon as I try to add a different pixelformat than V4L2_PIX_FMT_UYVY in:
> >>> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/media/platform/mxc/capture/mx6s_capture.c?h=imx_5.4.0_8dxlphantom_er#n244
> >>> streaming won't start anymore: "not negotiated, -4" and the
> >>> "mx6s_vidioc_enum_framesizes" ioctl is not called anymore. Why so?
> >>
> >> That will likely be the easy part of the problem. The NXP driver doesn't
> >> support RAW10 at all, so you will have to add that, and I don't think it
> >> will be easy.
>
> the staging driver (imx7-media-csi) sets PIXEL_BIT (cr1) and
> BIT_MIPI_DATA_FORMAT_RAW10 (cr18) which I hoped to be enough for
> supporting RAW10. What else do you think is missing?
That I don't know, given that I haven't been able to get RAW10 to work
correctly with the staging driver yet :-)
> >> I'll push my development branch shortly if you're interested in trying
> >> the mainline driver.
> >
> > git://linuxtv.org/pinchartl/media.git imx/csi/imx8
> >
> > The topmost patches are random debugging tests.
>
> Thanks a lot. I'll definitely have a look and try running imx7-media-csi
> once more.
>
> >>> I didn't find much when comparing strace from "gst-launch-1.0 v4l2src !
> >>> video/x-raw,width=1280,height=720 ! videoconvert ! xvimagesink" (which
> >>> is how I test).
> >>>
> >>> When I simply use V4L2_PIX_FMT_UYVY I *do* get interrupts (in mx6s) but
> >>> only "FIELD0_INT" (and drawing at this point suggests that buffer 1 is
> >>> not yet full and "distorted" in a wrong format, which could explain why
> >>> DMA is never completed in order to create a full frame).
> >>>
> >>> Now this is details, but the hi846 camera uses a 10bit CSI format and
> >>> therefore I need to set PIXEL_BIT in cr1 too, but when I do that for
> >>> example, I don't get "FIELD0_INT" anymore (only SFF_OR_INT and of course
> >>> the "base address switching Change Err").
> >>>
> >>> Do you have experience with using this driver with other cameras and can
> >>> point me in a direction that might help me?
> >>>
> >>> If you want to look at the work-in-progress driver:
> >>> https://source.puri.sm/martin.kepplinger/linux-next/-/blob/hi846/drivers/media/i2c/hi846.c
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 01/13] docs: conf.py: fix sphinx version detection for margin set
From: Mauro Carvalho Chehab @ 2020-12-10 16:03 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Media Mailing List, linuxarm, mauro.chehab, linux-doc,
linux-kernel
In-Reply-To: <20201210074845.4eb67f22@lwn.net>
Em Thu, 10 Dec 2020 07:48:45 -0700
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Thu, 10 Dec 2020 11:55:40 +0100
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
> > The PDF generator has a logic to detect the proper way to
> > setup the page margins. By default, the page has about
> > 14.8 cm, which is too short to display some tables and literal
> > blocks. So, previous patches changed it to be around 17.5 cm,
> > but the logic only works with Sphinx version 1.x.x.
> >
> > Fix it.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>
> Acked-by: Jonathan Corbet <corbet@lwn.net>
>
> Feel free to route this one with the rest of the set.
>
> Someday it might be nice to isolate all of the latex stuff into
> conf-latex.py or some such so most of us don't have to look at it..:)
Yeah, makes sense.
Btw, just gave another trial of rst2pdf (sent the RFC patch
adding support for it)...
Still doesn't work: lots of documents are produced with
zero size :-(
Thanks,
Mauro
^ permalink raw reply
* [PATCH RFC] docs: experimental: build PDF with rst2pdf
From: Mauro Carvalho Chehab @ 2020-12-10 16:01 UTC (permalink / raw)
To: Jonathan Corbet, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Masahiro Yamada, Mauro Carvalho Chehab,
Michal Marek, linux-kbuild, linux-kernel, linux-media
In-Reply-To: <20201210074845.4eb67f22@lwn.net>
Add an experimental PDF builder using rst2pdf
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
Documentation/Makefile | 5 +++++
Documentation/conf.py | 21 +++++++++++++++------
Documentation/userspace-api/media/Makefile | 1 +
Makefile | 4 ++--
4 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 61a7310b49e0..c3c8fb10f94e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -115,6 +115,10 @@ pdfdocs: latexdocs
endif # HAVE_PDFLATEX
+rst2pdf:
+ @$(srctree)/scripts/sphinx-pre-install --version-check
+ @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,pdf,$(var),pdf,$(var)))
+
epubdocs:
@$(srctree)/scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,epub,$(var),epub,$(var)))
@@ -140,6 +144,7 @@ dochelp:
@echo ' htmldocs - HTML'
@echo ' latexdocs - LaTeX'
@echo ' pdfdocs - PDF'
+ @echo ' rst2pdf - PDF, using experimental rst2pdf support'
@echo ' epubdocs - EPUB'
@echo ' xmldocs - XML'
@echo ' linkcheckdocs - check for broken external links'
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 66e121df59cd..6f2788aac81e 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -123,6 +123,12 @@ if (major == 1 and minor > 3) or (major > 1):
else:
extensions.append("sphinx.ext.pngmath")
+# Enable experimental rst2pdf, if available
+try:
+ extensions.append("rst2pdf.pdfbuilder")
+except:
+ sys.stderr.write('rst2pdf extension not available.\n')
+
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
@@ -614,12 +620,15 @@ epub_exclude_files = ['search.html']
#
# See the Sphinx chapter of https://ralsina.me/static/manual.pdf
#
-# FIXME: Do not add the index file here; the result will be too big. Adding
-# multiple PDF files here actually tries to get the cross-referencing right
-# *between* PDF files.
-pdf_documents = [
- ('kernel-documentation', u'Kernel', u'Kernel', u'J. Random Bozo'),
-]
+
+# Add all LaTeX files to PDF documents as well
+pdf_documents = []
+for l in latex_documents:
+ doc = l[0]
+ fn = l[1].replace(".tex", "")
+ name = l[2]
+ authors = l[3]
+ pdf_documents.append((doc, fn, name, authors))
# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
# the Docs). In a normal build, these are supplied from the Makefile via command
diff --git a/Documentation/userspace-api/media/Makefile b/Documentation/userspace-api/media/Makefile
index 81a4a1a53bce..8c6b3ac4ecb0 100644
--- a/Documentation/userspace-api/media/Makefile
+++ b/Documentation/userspace-api/media/Makefile
@@ -59,6 +59,7 @@ all: $(IMGDOT) $(BUILDDIR) ${TARGETS}
html: all
epub: all
xml: all
+pdf: all
latex: $(IMGPDF) all
linkcheck:
diff --git a/Makefile b/Makefile
index 43ecedeb3f02..db4043578eec 100644
--- a/Makefile
+++ b/Makefile
@@ -264,7 +264,7 @@ no-dot-config-targets := $(clean-targets) \
cscope gtags TAGS tags help% %docs check% coccicheck \
$(version_h) headers headers_% archheaders archscripts \
%asm-generic kernelversion %src-pkg dt_binding_check \
- outputmakefile
+ outputmakefile rst2pdf
no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
@@ -1654,7 +1654,7 @@ $(help-board-dirs): help-%:
# Documentation targets
# ---------------------------------------------------------------------------
-DOC_TARGETS := xmldocs latexdocs pdfdocs htmldocs epubdocs cleandocs \
+DOC_TARGETS := xmldocs latexdocs pdfdocs rst2pdf htmldocs epubdocs cleandocs \
linkcheckdocs dochelp refcheckdocs
PHONY += $(DOC_TARGETS)
$(DOC_TARGETS):
--
2.29.2
^ permalink raw reply related
* Re: [PATCH 01/15] irqchip: Allow to compile bcmstb on other platforms
From: Florian Fainelli @ 2020-12-10 17:33 UTC (permalink / raw)
To: Maxime Ripard, Eric Anholt, Maarten Lankhorst, Thomas Zimmermann,
Daniel Vetter, David Airlie
Cc: Jason Cooper, bcm-kernel-feedback-list, linux-arm-kernel,
Marc Zyngier, linux-media, Hans Verkuil, linux-kernel,
Mauro Carvalho Chehab, Thomas Gleixner, Dave Stevenson,
linux-rpi-kernel, dri-devel
In-Reply-To: <20201210134648.272857-2-maxime@cerno.tech>
On 12/10/2020 5:46 AM, Maxime Ripard wrote:
> The BCM2711 uses a number of instances of the bcmstb-l2 controller in its
> display engine. Let's allow the driver to be enabled through KConfig.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 14/15] ARM: dts: bcm2711: Add the BSC interrupt controller
From: Florian Fainelli @ 2020-12-10 17:41 UTC (permalink / raw)
To: Maxime Ripard, Eric Anholt, Maarten Lankhorst, Thomas Zimmermann,
Daniel Vetter, David Airlie
Cc: Jason Cooper, bcm-kernel-feedback-list, linux-arm-kernel,
Marc Zyngier, linux-media, Hans Verkuil, linux-kernel,
Mauro Carvalho Chehab, Thomas Gleixner, Dave Stevenson,
linux-rpi-kernel, dri-devel
In-Reply-To: <20201210134648.272857-15-maxime@cerno.tech>
On 12/10/2020 5:46 AM, Maxime Ripard wrote:
> The BSC controllers used for the HDMI DDC have an interrupt controller
> shared between both instances. Let's add it to avoid polling.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 15/15] ARM: dts: bcm2711: Add the CEC interrupt controller
From: Florian Fainelli @ 2020-12-10 17:42 UTC (permalink / raw)
To: Maxime Ripard, Eric Anholt, Maarten Lankhorst, Thomas Zimmermann,
Daniel Vetter, David Airlie
Cc: Jason Cooper, bcm-kernel-feedback-list, linux-arm-kernel,
Marc Zyngier, linux-media, Hans Verkuil, linux-kernel,
Mauro Carvalho Chehab, Thomas Gleixner, Dave Stevenson,
linux-rpi-kernel, dri-devel
In-Reply-To: <20201210134648.272857-16-maxime@cerno.tech>
On 12/10/2020 5:46 AM, Maxime Ripard wrote:
> The CEC and hotplug interrupts go through an interrupt controller shared
> between the two HDMI controllers.
>
> Let's add that interrupt controller and the interrupts for both HDMI
> controllers
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 01/15] irqchip: Allow to compile bcmstb on other platforms
From: Marc Zyngier @ 2020-12-10 17:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Eric Anholt, Maarten Lankhorst, Thomas Zimmermann, Daniel Vetter,
David Airlie, bcm-kernel-feedback-list, linux-arm-kernel,
linux-media, Hans Verkuil, linux-kernel, Mauro Carvalho Chehab,
Thomas Gleixner, Dave Stevenson, linux-rpi-kernel, dri-devel
In-Reply-To: <20201210134648.272857-2-maxime@cerno.tech>
Hi Maxime,
On 2020-12-10 13:46, Maxime Ripard wrote:
> The BCM2711 uses a number of instances of the bcmstb-l2 controller in
> its
> display engine. Let's allow the driver to be enabled through KConfig.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/irqchip/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index c6098eee0c7c..f1e58de117dc 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -131,7 +131,7 @@ config BCM7120_L2_IRQ
> select IRQ_DOMAIN
>
> config BRCMSTB_L2_IRQ
> - bool
> + bool "Broadcom STB L2 Interrupt Controller"
> select GENERIC_IRQ_CHIP
> select IRQ_DOMAIN
I'm always sceptical of making interrupt controllers user-selectable.
Who is going to know that they need to pick that one?
I'd be much more in favour of directly selecting this symbol
from DRM_VC4_HDMI_CEC, since there is an obvious dependency.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [GIT PULL for v5.10] media fixes
From: pr-tracker-bot @ 2020-12-10 19:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linus Torvalds, Greg Kroah-Hartman, Andrew Morton,
Linux Media Mailing List, Linux Kernel Mailing List
In-Reply-To: <20201210121818.2d5c0353@coco.lan>
The pull request you sent on Thu, 10 Dec 2020 12:18:18 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.10-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/40201575b731db6bde55c2f0daa930bbd9cfcb13
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* KASAN: null-ptr-deref Read in ida_free
From: syzbot @ 2020-12-10 14:29 UTC (permalink / raw)
To: andreyknvl, laurent.pinchart, linux-kernel, linux-media,
linux-usb, mchehab, sakari.ailus, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 8010622c USB: UAS: introduce a quirk to set no_write_same
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=16dbc923500000
kernel config: https://syzkaller.appspot.com/x/.config?x=d24ee9ecd7ce968e
dashboard link: https://syzkaller.appspot.com/bug?extid=930c00d27e58b0d77fb9
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+930c00d27e58b0d77fb9@syzkaller.appspotmail.com
input: TeVii S662 as /devices/platform/dummy_hcd.3/usb4/4-1/rc/rc0/input610
dvb-usb: schedule remote query interval to 250 msecs.
dw2102: su3000_power_ctrl: 0, initialized 1
dvb-usb: TeVii S662 successfully initialized and connected.
usb 4-1: USB disconnect, device number 114
==================================================================
BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:71 [inline]
BUG: KASAN: null-ptr-deref in test_bit include/asm-generic/bitops/instrumented-non-atomic.h:134 [inline]
BUG: KASAN: null-ptr-deref in ida_free+0x186/0x2b0 lib/idr.c:510
Read of size 8 at addr 0000000000000018 by task kworker/1:0/4637
CPU: 1 PID: 4637 Comm: kworker/1:0 Not tainted 5.10.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:118
__kasan_report mm/kasan/report.c:549 [inline]
kasan_report.cold+0x5/0x37 mm/kasan/report.c:562
check_memory_region_inline mm/kasan/generic.c:186 [inline]
check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
instrument_atomic_read include/linux/instrumented.h:71 [inline]
test_bit include/asm-generic/bitops/instrumented-non-atomic.h:134 [inline]
ida_free+0x186/0x2b0 lib/idr.c:510
__media_device_unregister_entity+0x70/0x300 drivers/media/mc/mc-device.c:586
media_device_unregister_entity+0x49/0x70 drivers/media/mc/mc-device.c:689
dvb_media_device_free+0x1d5/0x620 drivers/media/dvb-core/dvbdev.c:226
dvb_remove_device.part.0+0x9c/0x260 drivers/media/dvb-core/dvbdev.c:561
dvb_remove_device drivers/media/dvb-core/dvbdev.c:554 [inline]
dvb_unregister_device+0x1b/0x60 drivers/media/dvb-core/dvbdev.c:583
dvb_dmxdev_release+0x1a0/0x640 drivers/media/dvb-core/dmxdev.c:1459
dvb_usb_adapter_dvb_exit+0x93/0x230 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:224
dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:114 [inline]
dvb_usb_exit.isra.0+0xb4/0x310 drivers/media/usb/dvb-usb/dvb-usb-init.c:129
dvb_usb_device_exit+0x111/0x1a0 drivers/media/usb/dvb-usb/dvb-usb-init.c:306
usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458
__device_release_driver+0x3bd/0x6f0 drivers/base/dd.c:1154
device_release_driver_internal drivers/base/dd.c:1185 [inline]
device_release_driver+0x26/0x40 drivers/base/dd.c:1208
bus_remove_device+0x2eb/0x5a0 drivers/base/bus.c:533
device_del+0x502/0xec0 drivers/base/core.c:3115
usb_disable_device+0x35b/0x7b0 drivers/usb/core/message.c:1413
usb_disconnect.cold+0x27d/0x780 drivers/usb/core/hub.c:2218
hub_port_connect drivers/usb/core/hub.c:5074 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
port_event drivers/usb/core/hub.c:5509 [inline]
hub_event+0x1c8a/0x42d0 drivers/usb/core/hub.c:5591
process_one_work+0x933/0x1520 kernel/workqueue.c:2272
process_scheduled_works kernel/workqueue.c:2334 [inline]
worker_thread+0x82b/0x1120 kernel/workqueue.c:2420
kthread+0x38c/0x460 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
From: Hridya Valsaraju @ 2020-12-10 20:05 UTC (permalink / raw)
To: Christian König
Cc: Sumit Semwal, LKML, linux-media, dri-devel, linaro-mm-sig,
Android Kernel Team, Greg Kroah-Hartman, Suren Baghdasaryan,
John Stultz
In-Reply-To: <b5adfe46-8615-5821-d092-2b93feed5b79@amd.com>
Thank you for the reviews Greg, Christian and Daniel!
On Thu, Dec 10, 2020 at 1:59 AM Christian König
<christian.koenig@amd.com> wrote:
>
> In general a good idea, but I have a few concern/comments here.
>
> Am 10.12.20 um 05:43 schrieb Hridya Valsaraju:
> > This patch allows statistics to be enabled for each DMA-BUF in
> > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS.
> >
> > The following stats will be exposed by the interface:
> >
> > /sys/kernel/dmabuf/<inode_number>/exporter_name
> > /sys/kernel/dmabuf/<inode_number>/size
> > /sys/kernel/dmabuf/<inode_number>/dev_map_info
> >
> > The inode_number is unique for each DMA-BUF and was added earlier [1]
> > in order to allow userspace to track DMA-BUF usage across different
> > processes.
> >
> > Currently, this information is exposed in
> > /sys/kernel/debug/dma_buf/bufinfo.
> > However, since debugfs is considered unsafe to be mounted in production,
> > it is being duplicated in sysfs.
>
> Mhm, this makes it part of the UAPI. What is the justification for this?
>
> In other words do we really need those debug information in a production
> environment?
Yes, we currently collect this information on production devices as well.
>
> >
> > This information is intended to help with root-causing
> > low-memory kills and the debugging/analysis of other memory-related issues.
> >
> > It will also be used to derive DMA-BUF
> > per-exporter stats and per-device usage stats for Android Bug reports.
> >
> > [1]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1088791%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C30a0e015502b4d20e18208d89cc63f1a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637431722574983797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RdGMvj5VsFUwJcVOuSPaLuAr4eI3CR1YOaznupmpTqg%3D&reserved=0
> >
> > Signed-off-by: Hridya Valsaraju <hridya@google.com>
> > ---
> > Documentation/ABI/testing/sysfs-kernel-dmabuf | 32 ++++
> > drivers/dma-buf/Kconfig | 11 ++
> > drivers/dma-buf/Makefile | 1 +
> > drivers/dma-buf/dma-buf-sysfs-stats.c | 162 ++++++++++++++++++
> > drivers/dma-buf/dma-buf-sysfs-stats.h | 37 ++++
> > drivers/dma-buf/dma-buf.c | 29 ++++
> > include/linux/dma-buf.h | 13 ++
> > 7 files changed, 285 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf
> > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c
> > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h
> >
> > diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf b/Documentation/ABI/testing/sysfs-kernel-dmabuf
> > new file mode 100644
> > index 000000000000..02d407d57aaa
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf
> > @@ -0,0 +1,32 @@
> > +What: /sys/kernel/dmabuf
> > +Date: November 2020
> > +KernelVersion: v5.11
> > +Contact: Hridya Valsaraju <hridya@google.com>
> > +Description: The /sys/kernel/dmabuf directory contains a
> > + snapshot of the internal state of every DMA-BUF.
> > + /sys/kernel/dmabuf/<inode_number> will contain the
> > + statistics for the DMA-BUF with the unique inode number
> > + <inode_number>
> > +Users: kernel memory tuning/debugging tools
> > +
> > +What: /sys/kernel/dmabuf/<inode_number>/exporter_name
> > +Date: November 2020
> > +KernelVersion: v5.11
> > +Contact: Hridya Valsaraju <hridya@google.com>
> > +Description: This file is read-only and contains the name of the exporter of
> > + the DMA-BUF.
> > +
> > +What: /sys/kernel/dmabuf/<inode_number>/size
> > +Dat: November 2020
> > +KernelVersion: v5.11
> > +Contact: Hridya Valsaraju <hridya@google.com>
> > +Description: This file is read-only and specifies the size of the DMA-BUF in
> > + bytes.
> > +
> > +What: /sys/kernel/dmabuf/<inode_number>/dev_map_info
> > +Dat: November 2020
> > +KernelVersion: v5.11
> > +Contact: Hridya Valsaraju <hridya@google.com>
> > +Description: This file is read-only and lists the name of devices currently
> > + mapping the DMA-BUF in a space-separated format.
> > +
> > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> > index 4f8224a6ac95..2fed26f14548 100644
> > --- a/drivers/dma-buf/Kconfig
> > +++ b/drivers/dma-buf/Kconfig
> > @@ -64,6 +64,17 @@ menuconfig DMABUF_HEAPS
> > allows userspace to allocate dma-bufs that can be shared
> > between drivers.
> >
> > +menuconfig DMABUF_SYSFS_STATS
> > + bool "DMA-BUF sysfs statistics"
> > + select DMA_SHARED_BUFFER
> > + help
> > + Choose this option to enable DMA-BUF sysfs statistics
> > + in location /sys/kernel/dmabuf.
> > +
> > + /sys/kernel/dmabuf/<inode_number> will contain
> > + statistics for the DMA-BUF with the unique inode number
> > + <inode_number>.
> > +
> > source "drivers/dma-buf/heaps/Kconfig"
> >
> > endmenu
> > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> > index 995e05f609ff..40d81f23cacf 100644
> > --- a/drivers/dma-buf/Makefile
> > +++ b/drivers/dma-buf/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_DMABUF_HEAPS) += heaps/
> > obj-$(CONFIG_SYNC_FILE) += sync_file.o
> > obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
> > obj-$(CONFIG_UDMABUF) += udmabuf.o
> > +obj-$(CONFIG_DMABUF_SYSFS_STATS) += dma-buf-sysfs-stats.o
> >
> > dmabuf_selftests-y := \
> > selftest.o \
> > diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c
> > new file mode 100644
> > index 000000000000..bcbef81e0a5f
> > --- /dev/null
> > +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
> > @@ -0,0 +1,162 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +
> > +#include <linux/dma-buf.h>
> > +#include <linux/dma-resv.h>
> > +#include <linux/kobject.h>
> > +#include <linux/printk.h>
> > +#include <linux/slab.h>
> > +#include <linux/sysfs.h>
> > +
> > +#define to_dma_buf_entry_from_kobj(x) container_of(x, struct dma_buf_sysfs_entry, kobj)
> > +
> > +struct dma_buf_stats_attribute {
> > + struct attribute attr;
> > + ssize_t (*show)(struct dma_buf *dmabuf,
> > + struct dma_buf_stats_attribute *attr, char *buf);
> > +};
> > +#define to_dma_buf_stats_attr(x) container_of(x, struct dma_buf_stats_attribute, attr)
> > +
> > +static ssize_t dma_buf_stats_attribute_show(struct kobject *kobj,
> > + struct attribute *attr,
> > + char *buf)
> > +{
> > + struct dma_buf_stats_attribute *attribute;
> > + struct dma_buf_sysfs_entry *sysfs_entry;
> > + struct dma_buf *dmabuf;
> > +
> > + attribute = to_dma_buf_stats_attr(attr);
> > + sysfs_entry = to_dma_buf_entry_from_kobj(kobj);
> > + dmabuf = sysfs_entry->dmabuf;
> > +
> > + if (!dmabuf || !attribute->show)
> > + return -EIO;
> > +
> > + return attribute->show(dmabuf, attribute, buf);
> > +}
> > +
> > +static const struct sysfs_ops dma_buf_stats_sysfs_ops = {
> > + .show = dma_buf_stats_attribute_show,
> > +};
> > +
> > +static ssize_t exporter_name_show(struct dma_buf *dmabuf,
> > + struct dma_buf_stats_attribute *attr,
> > + char *buf)
> > +{
> > + return sysfs_emit(buf, "%s\n", dmabuf->exp_name);
> > +}
> > +
> > +static ssize_t size_show(struct dma_buf *dmabuf,
> > + struct dma_buf_stats_attribute *attr,
> > + char *buf)
> > +{
> > + return sysfs_emit(buf, "%zu\n", dmabuf->size);
> > +}
> > +
> > +static ssize_t dev_map_info_show(struct dma_buf *dmabuf,
> > + struct dma_buf_stats_attribute *attr,
> > + char *buf)
> > +{
> > + ssize_t ret;
> > + struct dma_buf_attachment *attachment;
> > +
> > + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL);
> > + if (ret)
> > + return ret;
> > +
> > + list_for_each_entry(attachment, &dmabuf->attachments, node) {
> > + if (attachment->map_counter) {
> > + ret += sysfs_emit_at(buf, ret, "%s ",
> > + dev_name(attachment->dev));
> > + }
>
> Why do you emit this only when there is a mapping? It is perfectly valid
> and current practice that importers map things only on first use.
I did it this way since I thought that it would be more accurate to
eliminate the attachments without mappings :) Since it appears that it
was an incorrect assumption, I will change it in the next version to
only represent the attachments instead and drop the map_counter member
from struct dma_buf_attachment.
>
> The number of mapping is in general rather interesting, but I would just
> print that together with the importer name.
>
> And BTW I would rename the dev_map_info to something like "attachments".
I will make this change in the next version of the patch!
Thanks,
Hridya
>
> Regards,
> Christian.
>
> > + }
> > + dma_resv_unlock(dmabuf->resv);
> > +
> > + ret += sysfs_emit_at(buf, ret, "\n");
> > + return ret;
> > +}
> > +
> > +static struct dma_buf_stats_attribute exporter_name_attribute =
> > + __ATTR_RO(exporter_name);
> > +static struct dma_buf_stats_attribute size_attribute = __ATTR_RO(size);
> > +static struct dma_buf_stats_attribute dev_map_info_attribute =
> > + __ATTR_RO(dev_map_info);
> > +
> > +static struct attribute *dma_buf_stats_default_attrs[] = {
> > + &exporter_name_attribute.attr,
> > + &size_attribute.attr,
> > + &dev_map_info_attribute.attr,
> > + NULL,
> > +};
> > +ATTRIBUTE_GROUPS(dma_buf_stats_default);
> > +
> > +static void dma_buf_sysfs_release(struct kobject *kobj)
> > +{
> > + struct dma_buf_sysfs_entry *sysfs_entry;
> > +
> > + sysfs_entry = to_dma_buf_entry_from_kobj(kobj);
> > + kfree(sysfs_entry);
> > +}
> > +
> > +static struct kobj_type dma_buf_ktype = {
> > + .sysfs_ops = &dma_buf_stats_sysfs_ops,
> > + .release = dma_buf_sysfs_release,
> > + .default_groups = dma_buf_stats_default_groups,
> > +};
> > +
> > +void dma_buf_sysfs_free(struct dma_buf *dmabuf)
> > +{
> > + struct dma_buf_sysfs_entry *sysfs_entry;
> > +
> > + sysfs_entry = dmabuf->sysfs_entry;
> > + if (!sysfs_entry)
> > + return;
> > +
> > + kobject_del(&sysfs_entry->kobj);
> > + kobject_put(&sysfs_entry->kobj);
> > +}
> > +
> > +static struct kset *dma_buf_stats_kset;
> > +int dma_buf_init_sysfs_statistics(void)
> > +{
> > + dma_buf_stats_kset = kset_create_and_add("dmabuf", NULL, kernel_kobj);
> > + if (!dma_buf_stats_kset)
> > + return -ENOMEM;
> > +
> > + return 0;
> > +}
> > +
> > +void dma_buf_uninit_sysfs_statistics(void)
> > +{
> > + kset_unregister(dma_buf_stats_kset);
> > +}
> > +
> > +int dma_buf_init_stats_kobj(struct dma_buf *dmabuf)
> > +{
> > + struct dma_buf_sysfs_entry *sysfs_entry;
> > + int ret;
> > +
> > + if (!dmabuf || !dmabuf->file)
> > + return -EINVAL;
> > +
> > + if (!dmabuf->exp_name) {
> > + pr_err("exporter name must not be empty if stats needed\n");
> > + return -EINVAL;
> > + }
> > +
> > + sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL);
> > + if (!sysfs_entry)
> > + return -ENOMEM;
> > +
> > + sysfs_entry->kobj.kset = dma_buf_stats_kset;
> > + sysfs_entry->dmabuf = dmabuf;
> > +
> > + dmabuf->sysfs_entry = sysfs_entry;
> > +
> > + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL,
> > + "%lu", file_inode(dmabuf->file)->i_ino);
> > + if (ret)
> > + kobject_put(&sysfs_entry->kobj);
> > +
> > + return ret;
> > +}
> > diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-buf-sysfs-stats.h
> > new file mode 100644
> > index 000000000000..42fae7d1b11f
> > --- /dev/null
> > +++ b/drivers/dma-buf/dma-buf-sysfs-stats.h
> > @@ -0,0 +1,37 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +#ifndef _DMA_BUF_SYSFS_STATS_H
> > +#define _DMA_BUF_SYSFS_STATS_H
> > +
> > +#ifdef CONFIG_DMABUF_SYSFS_STATS
> > +
> > +int dma_buf_init_sysfs_statistics(void);
> > +void dma_buf_uninit_sysfs_statistics(void);
> > +
> > +int dma_buf_init_stats_kobj(struct dma_buf *dmabuf);
> > +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach,
> > + int delta)
> > +{
> > + attach->map_counter += delta;
> > +}
> > +void dma_buf_sysfs_free(struct dma_buf *dmabuf);
> > +
> > +#else
> > +
> > +static inline int dma_buf_init_sysfs_statistics(void)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline void dma_buf_uninit_sysfs_statistics(void) {}
> > +
> > +static inline int dma_buf_init_stats_kobj(struct dma_buf *dmabuf)
> > +{
> > + return 0;
> > +}
> > +static inline void dma_buf_sysfs_free(struct dma_buf *dmabuf) {}
> > +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach,
> > + int delta) {}
> > +
> > +#endif
> > +#endif // _DMA_BUF_SYSFS_STATS_H
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index e63684d4cd90..e93df0069bf8 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -29,6 +29,8 @@
> > #include <uapi/linux/dma-buf.h>
> > #include <uapi/linux/magic.h>
> >
> > +#include "dma-buf-sysfs-stats.h"
> > +
> > static inline int is_dma_buf_file(struct file *);
> >
> > struct dma_buf_list {
> > @@ -83,6 +85,7 @@ static void dma_buf_release(struct dentry *dentry)
> > if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
> > dma_resv_fini(dmabuf->resv);
> >
> > + dma_buf_sysfs_free(dmabuf);
> > module_put(dmabuf->owner);
> > kfree(dmabuf->name);
> > kfree(dmabuf);
> > @@ -566,6 +569,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
> > file->f_mode |= FMODE_LSEEK;
> > dmabuf->file = file;
> >
> > + ret = dma_buf_init_stats_kobj(dmabuf);
> > + if (ret)
> > + goto err_sysfs;
> > +
> > mutex_init(&dmabuf->lock);
> > INIT_LIST_HEAD(&dmabuf->attachments);
> >
> > @@ -575,6 +582,14 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
> >
> > return dmabuf;
> >
> > +err_sysfs:
> > + /*
> > + * Set file->f_path.dentry->d_fsdata to NULL so that when
> > + * dma_buf_release() gets invoked by dentry_ops, it exits
> > + * early before calling the release() dma_buf op.
> > + */
> > + file->f_path.dentry->d_fsdata = NULL;
> > + fput(file);
> > err_dmabuf:
> > kfree(dmabuf);
> > err_module:
> > @@ -732,6 +747,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> > dma_resv_unlock(attach->dmabuf->resv);
> > attach->sgt = sgt;
> > attach->dir = DMA_BIDIRECTIONAL;
> > + dma_buf_update_attachment_map_count(attach, 1 /* delta */);
> > }
> >
> > return attach;
> > @@ -786,6 +802,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
> > dma_resv_lock(attach->dmabuf->resv, NULL);
> >
> > dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
> > + dma_buf_update_attachment_map_count(attach, -1 /* delta */);
> >
> > if (dma_buf_is_dynamic(attach->dmabuf)) {
> > dma_buf_unpin(attach);
> > @@ -925,6 +942,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> > }
> > #endif /* CONFIG_DMA_API_DEBUG */
> >
> > + if (!IS_ERR(sg_table))
> > + dma_buf_update_attachment_map_count(attach, 1 /* delta */);
> > +
> > return sg_table;
> > }
> > EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
> > @@ -962,6 +982,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
> > if (dma_buf_is_dynamic(attach->dmabuf) &&
> > !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
> > dma_buf_unpin(attach);
> > +
> > + dma_buf_update_attachment_map_count(attach, -1 /* delta */);
> > }
> > EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> >
> > @@ -1399,6 +1421,12 @@ static inline void dma_buf_uninit_debugfs(void)
> >
> > static int __init dma_buf_init(void)
> > {
> > + int ret;
> > +
> > + ret = dma_buf_init_sysfs_statistics();
> > + if (ret)
> > + return ret;
> > +
> > dma_buf_mnt = kern_mount(&dma_buf_fs_type);
> > if (IS_ERR(dma_buf_mnt))
> > return PTR_ERR(dma_buf_mnt);
> > @@ -1414,5 +1442,6 @@ static void __exit dma_buf_deinit(void)
> > {
> > dma_buf_uninit_debugfs();
> > kern_unmount(dma_buf_mnt);
> > + dma_buf_uninit_sysfs_statistics();
> > }
> > __exitcall(dma_buf_deinit);
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index cf72699cb2bc..f5cab13afdfc 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -294,6 +294,7 @@ struct dma_buf_ops {
> > * @poll: for userspace poll support
> > * @cb_excl: for userspace poll support
> > * @cb_shared: for userspace poll support
> > + * @sysfs_entry: for exposing information about this buffer in sysfs
> > *
> > * This represents a shared buffer, created by calling dma_buf_export(). The
> > * userspace representation is a normal file descriptor, which can be created by
> > @@ -329,6 +330,13 @@ struct dma_buf {
> >
> > __poll_t active;
> > } cb_excl, cb_shared;
> > +#ifdef CONFIG_DMABUF_SYSFS_STATS
> > + /* for sysfs stats */
> > + struct dma_buf_sysfs_entry {
> > + struct kobject kobj;
> > + struct dma_buf *dmabuf;
> > + } *sysfs_entry;
> > +#endif
> > };
> >
> > /**
> > @@ -378,6 +386,8 @@ struct dma_buf_attach_ops {
> > * @importer_ops: importer operations for this attachment, if provided
> > * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held.
> > * @importer_priv: importer specific attachment data.
> > + * @map_counter: Number of times the buffer has been mapped through this
> > + * dma_buf_map_attachment.
> > *
> > * This structure holds the attachment information between the dma_buf buffer
> > * and its user device(s). The list contains one attachment struct per device
> > @@ -398,6 +408,9 @@ struct dma_buf_attachment {
> > const struct dma_buf_attach_ops *importer_ops;
> > void *importer_priv;
> > void *priv;
> > +#ifdef CONFIG_DMABUF_SYSFS_STATS
> > + unsigned int map_counter;
> > +#endif
> > };
> >
> > /**
>
^ permalink raw reply
* Re: How to get last frames in encode sequence returned by v4l2 encoder driver without V4L2_ENC_CMD_STOP
From: Nicolas Dufresne @ 2020-12-10 20:27 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hirokazu Honda, Alexandre Courbot, Linux Media Mailing List,
Fritz Koenig, J Kardatzke
In-Reply-To: <CAAFQd5AraF6sf79=q848VO1tWTWj6VaeG5sa38u_k4avkTPBGA@mail.gmail.com>
Le jeudi 10 décembre 2020 à 13:20 +0900, Tomasz Figa a écrit :
> On Thu, Dec 10, 2020 at 1:59 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
> >
> > Le mercredi 09 décembre 2020 à 18:51 +0900, Tomasz Figa a écrit :
> > > On Wed, Dec 9, 2020 at 1:43 AM Nicolas Dufresne <nicolas@ndufresne.ca>
> > > wrote:
> > > >
> > > > Le vendredi 27 novembre 2020 à 03:13 +0900, Hirokazu Honda a écrit :
> > > > > HI Alexandre,
> > > > >
> > > > > On Tue, Nov 24, 2020 at 7:17 PM Alexandre Courbot <
> > > > > acourbot@chromium.org>
> > > > > wrote:
> > > > > >
> > > > > > Hi Hiro,
> > > > > >
> > > > > > On Fri, Nov 13, 2020 at 6:04 PM Hirokazu Honda <hiroh@chromium.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > According to the official v4l2 encoder driver usage description
> > > > > > > [1],
> > > > > > > v4l2 steatful encoder driver doesn't have a guarantee when frames
> > > > > > > fed
> > > > > > > to a driver will be returned.
> > > > > > > To make sure all pending frames are output by the driver, an app
> > > > > > > must
> > > > > > > call VIDIOC_ENCODER_CMD with cmd=V4L2_ENC_CMD_STOP.
> > > > > > > However, it is not mandatory to support the command in the current
> > > > > > > v4l2 stateful encoder API specification.
> > > > > > > An app can check it by VIDIOC_TRY_ENCODER_CMD beforehand.
> > > > > > > My question is when an app has to get all the frames of an encoder
> > > > > > > sequence, how we can achieve this without V4L2_ENC_CMD_STOP
> > > > > > > support.
> > > > > > > This demand is natural and in fact WebCodecs [2] requires this.
> > > > > > >
> > > > > > > I think there are two options,
> > > > > > > 1.) Ensure that a driver will eventually output frames if it
> > > > > > > doesn't
> > > > > > > support V4L2_ENC_CMD_STOP.
> > > > > > > 2.) Change V4L2_ENC_CMD_STOP support to be mandatory
> > > > > >
> > > > > > Unless I am missing the part of the spec that says the contrary,
> > > > > > V4L2_ENC_CMD_STOP is part of the encoder specification, and thus is
> > > > > > mandatory. Some older drivers might not have support for it, in such
> > > > > > cases the correct course of action would be to fix them.
> > > > > >
> > > > >
> > > > > I researched the API documents.
> > > > > The statement that the support is mandatory to stateful encoders is
> > > > > added from the latest document v5.9 [1],
> > > > > It states optional in the API document of v4.19 and v5.8.
> > > > > Hence my question is obsolete.
> > > > >
> > > > > [1]
> > > > > https://www.kernel.org/doc/html/v5.9/userspace-api/media/v4l/vidioc-encoder-cmd.html
> > > > > [2]
> > > > > https://www.kernel.org/doc/html/v4.19/media/uapi/v4l/vidioc-encoder-cmd.html
> > > > > [3]
> > > > > https://www.kernel.org/doc/html/v5.8/userspace-api/media/v4l/vidioc-encoder-cmd.html?highlight=v4l2_enc_cmd_stop
> > > >
> > > > In historical drivers (Samsung MFC and perhaps Venus ?) an empty payload
> > > > buffer
> > > > was used to signal draining. This approach was never documented and had
> > > > issues.
> > > > It is still supported by MFC driver so that older Chromium / Android
> > > > code
> > > > don't
> > > > fail on it (even though I doubt it has ever been retested since).
> > > >
> > >
> > > FWIW, Chromium has not been relying on this for a long time already.
> > >
> > > That said, I think the question here is about a different class of
> > > devices. I can imagine some encoders just simply always consuming the
> > > input buffers as they come and produce corresponding bitstream buffers
> > > as soon as possible, in a 1:1 relationship. In that case, there would
> > > be no need for any explicit drain, because one can track which buffers
> > > came already and infer whether the encoding completed for the source
> > > buffer of interest.
> >
> > I believe we decided to make this mantory to all stateless decoder (it makes
> > userspace life easier). But JPEG decoders predates the spec, so I suspect a
> > JPEG
> > decoding userspace should behave as you describe to actually work with
> > existing
> > drivers. I would rather encourage having CMD_STOP in all stateless decoder,
> > even
> > JPEG.
> >
>
> Note that this thread is about encoders.
Sorry about that, but does it makes any difference ? The encoders for H.264 and
HEVC needs to reorder from display to encoded order. That means it will hold on
bitstream buffers. Also, it's an M2M V4L2 device, so it has queues, and you'd
have to do more work in userspace if you had two code path to drain the
asynchronous queues.
>
> > >
> > > Best regards,
> > > Tomasz
> > >
> > > > >
> > > > > Best Regards,
> > > > > -Hiro
> > > > > > >
> > > > > > > Any comments are appreciated.
> > > > > > > Thanks so much in advance.
> > > > > > >
> > > > > > > [1]
> > > > > > > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-encoder.html#drain
> > > > > > > [2] https://web.dev/webcodecs/
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > -Hiro
> > > >
> > > >
> >
> >
^ permalink raw reply
* Re: [PATCH v2 1/3] media: i2c: imx219: add support for specifying clock-frequencies
From: Michael Srba @ 2020-12-10 20:51 UTC (permalink / raw)
To: Sascha Hauer
Cc: Dave Stevenson, Mauro Carvalho Chehab, Rob Herring, Shawn Guo,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Geert Uytterhoeven, Magnus Damm, linux-media, devicetree,
linux-arm-kernel, linux-renesas-soc
In-Reply-To: <20201207055952.GB14307@pengutronix.de>
Hi,
sorry for late reply.
I copied this approach from looking at other camera sensor drivers,
and it seemed less "ugly" to me than using assigned-rates (I will be
upstreaming required dts changes for Samsung Galaxy A3 (2015), so the
dts feeling "proper" is important to me).
I however am not qualified to make that decision, so if you believe
that the assigned-rates approach is cleaner and more suitable for mainline,
I will try to adjust my internal filter for what is "more proper" :)
As for rounding, the issue is that it seems to like to round up, instead
of trying to find the closest possible value. I *guess* trying to set
the lower barrier might work out in practice, but it seems kind of ugly.
All in all, what I did seemed like the cleanest option to me, and it was
an approach that other drivers also use. But if you believe there is
a cleaner approach, I will be more than happy to do something else,
though I would appreciate an explanation of why it is cleaner so that
I can make better decisions in the future.
Best regards,
Michael
On 07. 12. 20 6:59, Sascha Hauer wrote:
> Hi Michael,
>
> On Sun, Dec 06, 2020 at 06:27:18PM +0100, michael.srba@seznam.cz wrote:
>> From: Michael Srba <Michael.Srba@seznam.cz>
>>
>> This patch adds 1% tolerance on input clock, similar to other camera sensor
>> drivers. It also allows for specifying the actual clock in the device tree,
>> instead of relying on it being already set to the right frequency (which is
>> often not the case).
>>
>> Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
>>
>> ---
>>
>> changes since v1: default to exactly 24MHz when `clock-frequency` is not present
>>
>> ---
>> drivers/media/i2c/imx219.c | 19 +++++++++++++++++--
>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c
>> index f64c0ef7a897..b6500e2ab19e 100644
>> --- a/drivers/media/i2c/imx219.c
>> +++ b/drivers/media/i2c/imx219.c
>> @@ -1443,13 +1443,28 @@ static int imx219_probe(struct i2c_client *client)
>> return PTR_ERR(imx219->xclk);
>> }
>>
>> - imx219->xclk_freq = clk_get_rate(imx219->xclk);
>> - if (imx219->xclk_freq != IMX219_XCLK_FREQ) {
>> + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency", &imx219->xclk_freq);
>> + if (ret) {
>> + dev_warn(dev, "could not get xclk frequency\n");
>> +
>> + /* default to 24MHz */
>> + imx219->xclk_freq = 24000000;
>> + }
>> +
>> + /* this driver currently expects 24MHz; allow 1% tolerance */
>> + if (imx219->xclk_freq < 23760000 || imx219->xclk_freq > 24240000) {
>> dev_err(dev, "xclk frequency not supported: %d Hz\n",
>> imx219->xclk_freq);
>> return -EINVAL;
>> }
>>
>> + ret = clk_set_rate(imx219->xclk, imx219->xclk_freq);
>> + if (ret) {
>> + dev_err(dev, "could not set xclk frequency\n");
>> + return ret;
>> + }
> clk_set_rate() returns successfully when the rate change has succeeded.
> It tells you nothing about the actual rate that has been set. The rate
> could be very different from what you want to get, depending on what the
> hardware is able to archieve. There's clk_round_rate() that tells you
> which rate you'll get when you call clk_set_rate() with that value.
> You would have to call clk_round_rate() first and see if you are happy
> with the result, afterwards set the rate. From that view it doesn't make
> much sense to check the device tree if a number between 23760000 and
> 24240000 is specified there, the clk api will do rounding anyway.
>
> Also there's the assigned-clocks device tree binding, see
> Documentation/devicetree/bindings/clock/clock-bindings.txt. This allows
> you to set the desired clock rate directly in the device tree. All
> that's left to do in the driver is to replace the check for the exact
> rate with a check which allows a certain tolerance.
>
> Sascha
>
^ permalink raw reply
* [PATCH v2 0/2] dt-bindings: media: Convert video-interfaces.txt to schemas
From: Rob Herring @ 2020-12-10 21:16 UTC (permalink / raw)
To: Guennadi Liakhovetski, Sakari Ailus, Maxime Ripard,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media
This series converts video-interfaces.txt to DT schema which in turn is
based on converting the graph binding to a schema. All the media users
are converted to use the graph and video-interfaces schemas.
Based on media tree commit a3f132df0e5f. This is dependent on dt-schema
changes not yet committed[1]. Please review those too.
Rob
[1] https://github.com/devicetree-org/dt-schema/tree/of-graph
Rob Herring (2):
media: dt-bindings: Convert video-interfaces.txt properties to schemas
dt-bindings: media: Use graph and video-interfaces schemas
.../media/allwinner,sun4i-a10-csi.yaml | 11 +-
.../media/allwinner,sun6i-a31-csi.yaml | 12 +-
.../bindings/media/i2c/adv7180.yaml | 35 +-
.../bindings/media/i2c/adv7604.yaml | 37 +-
.../bindings/media/i2c/aptina,mt9v111.yaml | 4 +-
.../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 +-
.../devicetree/bindings/media/i2c/imx219.yaml | 21 +-
.../bindings/media/i2c/maxim,max9286.yaml | 101 +--
.../devicetree/bindings/media/i2c/ov5647.yaml | 20 +-
.../devicetree/bindings/media/i2c/ov8856.yaml | 21 +-
.../bindings/media/i2c/ovti,ov2680.yaml | 6 +-
.../bindings/media/i2c/ovti,ov772x.yaml | 9 +-
.../bindings/media/i2c/sony,imx214.yaml | 25 +-
.../bindings/media/i2c/sony,imx274.yaml | 3 +-
.../bindings/media/marvell,mmp2-ccic.yaml | 15 +-
.../bindings/media/nxp,imx7-csi.yaml | 5 +-
.../bindings/media/nxp,imx7-mipi-csi2.yaml | 32 +-
.../bindings/media/renesas,ceu.yaml | 17 +-
.../bindings/media/renesas,csi2.yaml | 54 +-
.../bindings/media/renesas,vin.yaml | 113 +---
.../bindings/media/rockchip-isp1.yaml | 40 +-
.../bindings/media/st,stm32-dcmi.yaml | 18 +-
.../devicetree/bindings/media/ti,cal.yaml | 55 +-
.../media/video-interface-devices.yaml | 405 +++++++++++
.../bindings/media/video-interfaces.txt | 640 +-----------------
.../bindings/media/video-interfaces.yaml | 344 ++++++++++
.../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +-
27 files changed, 901 insertions(+), 1211 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/video-interface-devices.yaml
create mode 100644 Documentation/devicetree/bindings/media/video-interfaces.yaml
--
2.25.1
^ permalink raw reply
* [PATCH v2 2/2] dt-bindings: media: Use graph and video-interfaces schemas
From: Rob Herring @ 2020-12-10 21:16 UTC (permalink / raw)
To: Guennadi Liakhovetski, Sakari Ailus, Maxime Ripard,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media
In-Reply-To: <20201210211625.3070388-1-robh@kernel.org>
Now that we have graph and video-interfaces schemas, rework the media
related schemas to use them.
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Jacopo Mondi <jacopo@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
v2:
- Update based on graph schema changes and addition of video-interfaces
schemas
.../media/allwinner,sun4i-a10-csi.yaml | 11 +-
.../media/allwinner,sun6i-a31-csi.yaml | 12 +-
.../bindings/media/i2c/adv7180.yaml | 35 ++----
.../bindings/media/i2c/adv7604.yaml | 37 ++----
.../bindings/media/i2c/aptina,mt9v111.yaml | 4 +-
.../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 +----
.../devicetree/bindings/media/i2c/imx219.yaml | 21 ++--
.../bindings/media/i2c/maxim,max9286.yaml | 101 ++++------------
.../devicetree/bindings/media/i2c/ov5647.yaml | 20 +---
.../devicetree/bindings/media/i2c/ov8856.yaml | 21 +---
.../bindings/media/i2c/ovti,ov2680.yaml | 6 +-
.../bindings/media/i2c/ovti,ov772x.yaml | 9 +-
.../bindings/media/i2c/sony,imx214.yaml | 25 ++--
.../bindings/media/i2c/sony,imx274.yaml | 3 +-
.../bindings/media/marvell,mmp2-ccic.yaml | 15 +--
.../bindings/media/nxp,imx7-csi.yaml | 5 +-
.../bindings/media/nxp,imx7-mipi-csi2.yaml | 32 +----
.../bindings/media/renesas,ceu.yaml | 17 +--
.../bindings/media/renesas,csi2.yaml | 54 ++-------
.../bindings/media/renesas,vin.yaml | 113 +++---------------
.../bindings/media/rockchip-isp1.yaml | 40 +------
.../bindings/media/st,stm32-dcmi.yaml | 18 +--
.../devicetree/bindings/media/ti,cal.yaml | 55 ++-------
.../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +-----
24 files changed, 151 insertions(+), 572 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
index 09318830db47..6ced94064215 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
@@ -67,14 +67,14 @@ properties:
interconnect-names:
const: dma-mem
- # See ./video-interfaces.txt for details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-width:
@@ -83,7 +83,6 @@ properties:
data-active: true
hsync-active: true
pclk-sample: true
- remote-endpoint: true
vsync-active: true
required:
@@ -91,12 +90,8 @@ properties:
- data-active
- hsync-active
- pclk-sample
- - remote-endpoint
- vsync-active
- required:
- - endpoint
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..8b568072a069 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -40,17 +40,15 @@ properties:
resets:
maxItems: 1
- # See ./video-interfaces.txt for details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint: true
-
bus-width:
enum: [ 8, 10, 12, 16 ]
@@ -60,10 +58,6 @@ properties:
required:
- bus-width
- - remote-endpoint
-
- required:
- - endpoint
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
index d8c54f9d9506..b729de679eb8 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
@@ -36,17 +36,9 @@ properties:
maxItems: 1
port:
- type: object
- description:
- A node containing a single endpoint as doucmented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
- ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/port
+
+ ports: true
additionalProperties: false
@@ -80,25 +72,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@3:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-2]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@3
- additionalProperties: false
-
required:
- ports
@@ -110,25 +97,21 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@6:
type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-5]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@6
- additionalProperties: false
-
required:
- ports
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
index 407baddfaa1d..df634b0c1f8c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
@@ -64,16 +64,12 @@ properties:
description:
Select which input is selected after reset.
- ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ ports: true
required:
- compatible
- reg
+ - ports
additionalProperties: false
@@ -86,26 +82,19 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
+
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
required:
- port@1
- additionalProperties: false
-
- required:
- - ports
-
- if:
properties:
compatible:
@@ -114,28 +103,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@2:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-1]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@2
- additionalProperties: false
-
- required:
- - ports
-
examples:
- |
#include <dt-bindings/gpio/gpio.h>
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
index ff9546e95d05..e53b8d65f381 100644
--- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
@@ -41,9 +41,9 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: |
- Output video port. See ../video-interfaces.txt.
+ Output video port.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
index 3dc06c628e64..e57575c44930 100644
--- a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
@@ -86,33 +86,9 @@ properties:
maxItems: 3
port:
- type: object
- additionalProperties: false
- description: -|
- Connection to the remote GMSL endpoint are modelled using the OF graph
- bindings in accordance with the video interface bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
- The device node contains a single "port" child node with a single
- "endpoint" sub-device.
-
- properties:
- endpoint:
- type: object
- additionalProperties: false
-
- properties:
- remote-endpoint:
- description: -|
- phandle to the remote GMSL endpoint sub-node in the remote node
- port.
- maxItems: 1
-
- required:
- - remote-endpoint
-
- required:
- - endpoint
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Connection to the remote GMSL endpoint.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
index dfc4d29a4f04..012c0565d8ae 100644
--- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
@@ -44,12 +44,15 @@ properties:
Reference to the GPIO connected to the xclr pin, if any.
Must be released (set high) after all supplies are applied.
- # See ../video-interfaces.txt for more details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
properties:
data-lanes:
description: |-
@@ -60,16 +63,8 @@ properties:
- const: 1
- const: 2
- clock-noncontinuous:
- type: boolean
- description: |-
- MIPI CSI-2 clock is non-continuous if this property is present,
- otherwise it's continuous.
-
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description:
- Allowed data bus frequencies.
+ clock-noncontinuous: true
+ link-frequencies: true
required:
- link-frequencies
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 9ea827092fdd..3a52dc81eabd 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -52,81 +52,41 @@ properties:
const: 2
ports:
- type: object
- description: |
- The connections to the MAX9286 GMSL and its endpoint nodes are modelled
- using the OF graph bindings in accordance with the video interface
- bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
- The following table lists the port number corresponding to each device
- port.
-
- Port Description
- ----------------------------------------
- Port 0 GMSL Input 0
- Port 1 GMSL Input 1
- Port 2 GMSL Input 2
- Port 3 GMSL Input 3
- Port 4 CSI-2 Output
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- port@[0-3]:
- type: object
- properties:
- reg:
- enum: [ 0, 1, 2, 3 ]
-
- endpoint:
- type: object
-
- properties:
- remote-endpoint:
- description: |
- phandle to the remote GMSL source endpoint subnode in the
- remote node port.
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 0
- required:
- - remote-endpoint
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 1
- required:
- - reg
- - endpoint
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 2
- additionalProperties: false
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 3
port@4:
- type: object
- properties:
- reg:
- const: 4
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output
+ properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint:
- description: phandle to the remote CSI-2 sink endpoint.
-
- data-lanes:
- description: array of physical CSI-2 data lane indexes.
+ data-lanes: true
required:
- - remote-endpoint
- data-lanes
- required:
- - reg
- - endpoint
-
- additionalProperties: false
-
required:
- port@4
@@ -184,25 +144,8 @@ properties:
requirements of the currently connected remote device.
port:
- type: object
-
- properties:
- endpoint:
- type: object
-
- properties:
- remote-endpoint:
- description: phandle to the MAX9286 sink endpoint.
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- required:
- - endpoint
-
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connection to the MAX9286 sink.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.yaml b/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
index 280c62afae13..3b1ea9da437a 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
@@ -31,27 +31,15 @@ properties:
maxItems: 1
port:
- type: object
- description: |-
- Should contain one endpoint sub-node used to model connection to the
- video receiver according to the specification defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ $ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint:
- description: |-
- phandle to the video receiver input port.
-
- clock-noncontinuous:
- type: boolean
- description: |-
- Set to true to allow MIPI CSI-2 non-continuous clock operations.
-
- additionalProperties: false
+ clock-noncontinuous: true
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
index cde85553fd01..c29b057ae922 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
@@ -57,16 +57,13 @@ properties:
active low.
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
- description:
- A node containing an output port node with an endpoint definition
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
@@ -79,18 +76,13 @@ properties:
- const: 4
link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description:
- Allowed data bus frequencies. 360000000, 180000000 Hz or both
- are supported by the driver.
-
+ maxItems: 2
+ items:
+ enum: [ 360000000, 180000000 ]
required:
- link-frequencies
- required:
- - endpoint
-
required:
- compatible
- reg
@@ -139,4 +131,3 @@ examples:
};
};
...
-
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
index 43bf749807e1..cf456f8d9ddc 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
@@ -50,11 +50,9 @@ properties:
Definition of the regulator used as digital power supply.
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
- A node containing an output port node with an endpoint definition
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ A node containing an output port node.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
index 6866c2cdac50..44529425ce3a 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
@@ -37,13 +37,14 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
- Video output port. See ../video-interfaces.txt.
+ Video output port.
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-type:
@@ -91,8 +92,6 @@ properties:
required:
- bus-type
- unevaluatedProperties: false
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
index 1a3590dd0e98..1b69b6342978 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
@@ -15,6 +15,9 @@ description: |
interface. Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a
maximum throughput of 1.2Gbps/lane.
+allOf:
+ - $ref: ../video-interface-devices.yaml#
+
properties:
compatible:
const: sony,imx214
@@ -47,25 +50,21 @@ properties:
description: Chip digital core regulator (1.12V).
maxItems: 1
- flash-leds:
- description: See ../video-interfaces.txt
-
- lens-focus:
- description: See ../video-interfaces.txt
+ flash-leds: true
+ lens-focus: true
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
- Video output port. See ../video-interfaces.txt.
+ Video output port.
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: See ../video-interfaces.txt
anyOf:
- items:
- const: 1
@@ -76,16 +75,12 @@ properties:
- const: 3
- const: 4
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description: See ../video-interfaces.txt
+ link-frequencies: true
required:
- data-lanes
- link-frequencies
- unevaluatedProperties: false
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
index f697e1a20beb..90828020e42a 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
@@ -44,8 +44,7 @@ properties:
maxItems: 1
port:
- type: object
- description: Output video port. See ../video-interfaces.txt.
+ $ref: /schemas/graph.yaml#/properties/port
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
index 49bff738aca5..9e85c70d1a1f 100644
--- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
+++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
@@ -24,29 +24,20 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
- # Properties described in
- # Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
- remote-endpoint: true
hsync-active: true
vsync-active: true
pclk-sample: true
bus-type: true
- required:
- - remote-endpoint
-
- required:
- - endpoint
-
clocks:
minItems: 1
maxItems: 3
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
index 4e81a47e60ac..d91575b8ebb9 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
@@ -33,10 +33,7 @@ properties:
- const: mclk
port:
- type: object
- description:
- A node containing input port nodes with endpoint definitions as documented
- in Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/port
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
index 0668332959e7..be47a7b62ca9 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
@@ -58,35 +58,22 @@ properties:
Differential receiver (HS-RX) settle time
ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: See ../video-interfaces.txt
oneOf:
- items:
- const: 1
@@ -94,18 +81,11 @@ properties:
- const: 1
- const: 2
- remote-endpoint: true
-
required:
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Output port node
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.yaml b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
index c7e1e4fe67e6..50e0740af15a 100644
--- a/Documentation/devicetree/bindings/media/renesas,ceu.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
@@ -34,18 +34,15 @@ properties:
maxItems: 1
port:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
- # Properties described in
- # Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
- remote-endpoint: true
hsync-active: true
vsync-active: true
field-even-active: false
@@ -53,12 +50,6 @@ properties:
enum: [8, 16]
default: 8
- required:
- - remote-endpoint
-
- required:
- - endpoint
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
index 533c2f181db7..20396f1be999 100644
--- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
@@ -46,24 +46,19 @@ properties:
maxItems: 1
ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -72,50 +67,19 @@ properties:
data-lanes:
maxItems: 1
- remote-endpoint: true
-
required:
- clock-lanes
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Output port node, multiple endpoints describing all the R-Car VIN
modules connected the CSI-2 receiver.
- properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- reg:
- const: 1
-
- patternProperties:
- "^endpoint@[0-9a-f]$":
- type: object
-
- properties:
- reg:
- maxItems: 1
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
+ required:
+ - port@0
+ - port@1
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml
index ad2fe660364b..fe7c4cbfe4ba 100644
--- a/Documentation/devicetree/bindings/media/renesas,vin.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml
@@ -69,15 +69,15 @@ properties:
#The per-board settings for Gen2 and RZ/G1 platforms:
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
- A node containing a parallel input with a single endpoint definitions as
- documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ A node containing a parallel input
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
hsync-active:
@@ -106,15 +106,6 @@ properties:
data-active: true
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
-
#The per-board settings for Gen3 and RZ/G2 platforms:
renesas,id:
description: VIN channel number
@@ -123,23 +114,18 @@ properties:
maximum: 15
ports:
- type: object
- description:
- A node containing input nodes with endpoint definitions as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Input port node, single endpoint describing a parallel input source.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
hsync-active:
@@ -168,98 +154,29 @@ properties:
data-active: true
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- required:
- - endpoint
-
- additionalProperties: false
-
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Input port node, multiple endpoints describing all the R-Car CSI-2
modules connected the VIN.
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- reg:
- const: 1
-
endpoint@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI20.
- properties:
- reg:
- const: 0
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI21.
- properties:
- reg:
- const: 1
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@2:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI40.
- properties:
- reg:
- const: 2
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@3:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI41.
- properties:
- reg:
- const: 3
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
anyOf:
- required:
- endpoint@0
@@ -270,8 +187,6 @@ properties:
- required:
- endpoint@3
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
index 2004c054ed1a..a6b1eff879ed 100644
--- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
@@ -56,56 +56,26 @@ properties:
power-domains:
maxItems: 1
- # See ./video-interfaces.txt for details
ports:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description: connection point for sensors at MIPI-DPHY RX0
- additionalProperties: false
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
- reg:
- const: 0
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- reg:
- maxItems: 1
-
data-lanes:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
- - "#address-cells"
- - "#size-cells"
-
required:
- - "#address-cells"
- - "#size-cells"
- port@0
required:
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index c18574bb3e81..41e1d0cd80e5 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -37,16 +37,15 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
- DCMI supports a single port node with parallel bus. It should contain
- one 'port' child node with child 'endpoint' node. Please refer to the
- bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ DCMI supports a single port node with parallel bus.
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-type:
@@ -57,8 +56,6 @@ properties:
enum: [8, 10, 12, 14]
default: 8
- remote-endpoint: true
-
allOf:
- if:
properties:
@@ -73,14 +70,9 @@ properties:
enum: [8]
required:
- - remote-endpoint
- bus-type
- pclk-sample
- unevaluatedProperties: false
-
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml
index 5e066629287d..65177cd69514 100644
--- a/Documentation/devicetree/bindings/media/ti,cal.yaml
+++ b/Documentation/devicetree/bindings/media/ti,cal.yaml
@@ -15,10 +15,7 @@ description: |-
processing capability to connect CSI2 image-sensor modules to the
DRA72x device.
- CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
- should contain a 'port' child node with child 'endpoint' node. Please
- refer to the bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ CAL supports 2 camera port nodes on MIPI bus.
properties:
compatible:
@@ -67,31 +64,19 @@ properties:
Documentation/devicetree/bindings/power/power_domain.txt
maxItems: 1
- # See ./video-interfaces.txt for details
ports:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
port@0:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI2 Port #0
properties:
- reg:
- const: 0
- description: CSI2 Port #0
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -101,24 +86,15 @@ properties:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
-
port@1:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI2 Port #1
properties:
- reg:
- const: 1
- description: CSI2 Port #1
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -128,14 +104,7 @@ properties:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
-
required:
- - "#address-cells"
- - "#size-cells"
- port@0
required:
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
index 2961a5b6872f..7d77823dbb7a 100644
--- a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
@@ -97,24 +97,21 @@ properties:
maxItems: 1
ports:
- type: object
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
Input / sink port node, single endpoint describing the
CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
-
data-lanes:
description: |
This is required only in the sink port 0 endpoint which
@@ -130,41 +127,17 @@ properties:
- const: 3
- const: 4
- remote-endpoint: true
-
required:
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
- additionalProperties: false
+ unevaluatedProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: |
Output / source port node, endpoint describing modules
connected the CSI-2 receiver.
- properties:
-
- reg:
- const: 1
-
- endpoint:
- type: object
-
- properties:
-
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
-
required:
- compatible
- reg
--
2.25.1
^ permalink raw reply related
* [PATCH v3 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas
From: Rob Herring @ 2020-12-10 21:16 UTC (permalink / raw)
To: Guennadi Liakhovetski, Sakari Ailus, Maxime Ripard,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media
In-Reply-To: <20201210211625.3070388-1-robh@kernel.org>
Convert video-interfaces.txt to DT schema. As it contains a mixture of
device level and endpoint properties, split it up into 2 schemas.
Binding schemas will need to reference both the graph.yaml and
video-interfaces.yaml schemas. The exact schema depends on how many
ports and endpoints for the binding. A single port with a single
endpoint looks similar to this:
port:
$ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
bus-width:
enum: [ 8, 10, 12, 16 ]
pclk-sample: true
hsync-active: true
vsync-active: true
required:
- bus-width
additionalProperties: false
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
I need acks for dual licensing from the listed maintainers.
v3:
- Support up to 9 physical lanes
- Set lane-polarities array bounds
---
.../media/video-interface-devices.yaml | 406 +++++++++++
.../bindings/media/video-interfaces.txt | 640 +-----------------
.../bindings/media/video-interfaces.yaml | 346 ++++++++++
3 files changed, 753 insertions(+), 639 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/video-interface-devices.yaml
create mode 100644 Documentation/devicetree/bindings/media/video-interfaces.yaml
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
new file mode 100644
index 000000000000..4527f56a5a6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -0,0 +1,406 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/video-interface-devices.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for video receiver and transmitter devices
+
+maintainers:
+ - Jacopo Mondi <jacopo@jmondi.org>
+ - Sakari Ailus <sakari.ailus@linux.intel.com>
+
+properties:
+ flash-leds:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ An array of phandles, each referring to a flash LED, a sub-node of the LED
+ driver device node.
+
+ lens-focus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle to the node of the focus lens controller.
+
+ rotation:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 90, 180, 270 ]
+ description: |
+ The camera rotation is expressed as the angular difference in degrees
+ between two reference systems, one relative to the camera module, and one
+ defined on the external world scene to be captured when projected on the
+ image sensor pixel array.
+
+ A camera sensor has a 2-dimensional reference system 'Rc' defined by its
+ pixel array read-out order. The origin is set to the first pixel being
+ read out, the X-axis points along the column read-out direction towards
+ the last columns, and the Y-axis along the row read-out direction towards
+ the last row.
+
+ A typical example for a sensor with a 2592x1944 pixel array matrix
+ observed from the front is:
+
+ 2591 X-axis 0
+ <------------------------+ 0
+ .......... ... ..........!
+ .......... ... ..........! Y-axis
+ ... !
+ .......... ... ..........!
+ .......... ... ..........! 1943
+ V
+
+ The external world scene reference system 'Rs' is a 2-dimensional
+ reference system on the focal plane of the camera module. The origin is
+ placed on the top-left corner of the visible scene, the X-axis points
+ towards the right, and the Y-axis points towards the bottom of the scene.
+ The top, bottom, left and right directions are intentionally not defined
+ and depend on the environment in which the camera is used.
+
+ A typical example of a (very common) picture of a shark swimming from left
+ to right, as seen from the camera, is:
+
+ 0 X-axis
+ 0 +------------------------------------->
+ !
+ !
+ !
+ ! |\____)\___
+ ! ) _____ __`<
+ ! |/ )/
+ !
+ !
+ !
+ V
+ Y-axis
+
+ with the reference system 'Rs' placed on the camera focal plane:
+
+ ¸.·˙!
+ ¸.·˙ !
+ _ ¸.·˙ !
+ +-/ \-+¸.·˙ !
+ | (o) | ! Camera focal plane
+ +-----+˙·.¸ !
+ ˙·.¸ !
+ ˙·.¸ !
+ ˙·.¸!
+
+ When projected on the sensor's pixel array, the image and the associated
+ reference system 'Rs' are typically (but not always) inverted, due to the
+ camera module's lens optical inversion effect.
+
+ Assuming the above represented scene of the swimming shark, the lens
+ inversion projects the scene and its reference system onto the sensor
+ pixel array, seen from the front of the camera sensor, as follows:
+
+ Y-axis
+ ^
+ !
+ !
+ !
+ ! |\_____)\__
+ ! ) ____ ___.<
+ ! |/ )/
+ !
+ !
+ !
+ 0 +------------------------------------->
+ 0 X-axis
+
+ Note the shark being upside-down.
+
+ The resulting projected reference system is named 'Rp'.
+
+ The camera rotation property is then defined as the angular difference in
+ the counter-clockwise direction between the camera reference system 'Rc'
+ and the projected scene reference system 'Rp'. It is expressed in degrees
+ as a number in the range [0, 360[.
+
+ Examples
+
+ 0 degrees camera rotation:
+
+
+ Y-Rp
+ ^
+ Y-Rc !
+ ^ !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ 0 +------------------------------------->
+ 0 X-Rc
+
+
+ X-Rc 0
+ <------------------------------------+ 0
+ X-Rp 0 !
+ <------------------------------------+ 0 !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ V
+ Y-Rp
+
+ 90 degrees camera rotation:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! Y-Rp
+ ! ^
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+ 180 degrees camera rotation:
+
+ 0
+ <------------------------------------+ 0
+ X-Rc !
+ Y-Rp !
+ ^ !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ 0 +------------------------------------->
+ 0 X-Rp
+
+ 270 degrees camera rotation:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! 0
+ ! <-----------------------------------+ 0
+ ! X-Rp !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+
+ Example one - Webcam
+
+ A camera module installed on the user facing part of a laptop screen
+ casing used for video calls. The captured images are meant to be displayed
+ in landscape mode (width > height) on the laptop screen.
+
+ The camera is typically mounted upside-down to compensate the lens optical
+ inversion effect:
+
+ Y-Rp
+ Y-Rc ^
+ ^ !
+ ! !
+ ! ! |\_____)\__
+ ! ! ) ____ ___.<
+ ! ! |/ )/
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ 0 +------------------------------------->
+ 0 X-Rc
+
+ The two reference systems are aligned, the resulting camera rotation is
+ 0 degrees, no rotation correction needs to be applied to the resulting
+ image once captured to memory buffers to correctly display it to users:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! |\____)\___ !
+ ! ) _____ __`< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ If the camera sensor is not mounted upside-down to compensate for the lens
+ optical inversion, the two reference systems will not be aligned, with
+ 'Rp' being rotated 180 degrees relatively to 'Rc':
+
+
+ X-Rc 0
+ <------------------------------------+ 0
+ !
+ Y-Rp !
+ ^ !
+ ! !
+ ! |\_____)\__ !
+ ! ) ____ ___.< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ 0 +------------------------------------->
+ 0 X-Rp
+
+ The image once captured to memory will then be rotated by 180 degrees:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! __/(_____/| !
+ ! >.___ ____ ( !
+ ! \( \| !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ A software rotation correction of 180 degrees should be applied to
+ correctly display the image:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! |\____)\___ !
+ ! ) _____ __`< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ Example two - Phone camera
+
+ A camera installed on the back side of a mobile device facing away from
+ the user. The captured images are meant to be displayed in portrait mode
+ (height > width) to match the device screen orientation and the device
+ usage orientation used when taking the picture.
+
+ The camera sensor is typically mounted with its pixel array longer side
+ aligned to the device longer side, upside-down mounted to compensate for
+ the lens optical inversion effect:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! Y-Rp
+ ! ^
+ ! !
+ ! !
+ ! !
+ ! ! |\_____)\__
+ ! ! ) ____ ___.<
+ ! ! |/ )/
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+ The two reference systems are not aligned and the 'Rp' reference system is
+ rotated by 90 degrees in the counter-clockwise direction relatively to the
+ 'Rc' reference system.
+
+ The image once captured to memory will be rotated:
+
+ +-------------------------------------+
+ | _ _ |
+ | \ / |
+ | | | |
+ | | | |
+ | | > |
+ | < | |
+ | | | |
+ | . |
+ | V |
+ +-------------------------------------+
+
+ A correction of 90 degrees in counter-clockwise direction has to be
+ applied to correctly display the image in portrait mode on the device
+ screen:
+
+ +--------------------+
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |\____)\___ |
+ | ) _____ __`< |
+ | |/ )/ |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +--------------------+
+
+ orientation:
+ description:
+ The orientation of a device (typically an image sensor or a flash LED)
+ describing its mounting position relative to the usage orientation of the
+ system where the device is installed on.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ # Front. The device is mounted on the front facing side of the system. For
+ # mobile devices such as smartphones, tablets and laptops the front side
+ # is the user facing side.
+ - 0
+ # Back. The device is mounted on the back side of the system, which is
+ # defined as the opposite side of the front facing one.
+ - 1
+ # External. The device is not attached directly to the system but is
+ # attached in a way that allows it to move freely.
+ - 2
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 3920f25a9123..8fcf5f52bf5b 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -1,639 +1 @@
-Common bindings for video receiver and transmitter interfaces
-
-General concept
----------------
-
-Video data pipelines usually consist of external devices, e.g. camera sensors,
-controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
-video DMA engines and video data processors.
-
-SoC internal blocks are described by DT nodes, placed similarly to other SoC
-blocks. External devices are represented as child nodes of their respective
-bus controller nodes, e.g. I2C.
-
-Data interfaces on all video devices are described by their child 'port' nodes.
-Configuration of a port depends on other devices participating in the data
-transfer and is described by 'endpoint' subnodes.
-
-device {
- ...
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- ...
- endpoint@0 { ... };
- endpoint@1 { ... };
- };
- port@1 { ... };
- };
-};
-
-If a port can be configured to work with more than one remote device on the same
-bus, an 'endpoint' child node must be provided for each of them. If more than
-one port is present in a device node or there is more than one endpoint at a
-port, or port node needs to be associated with a selected hardware interface,
-a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
-used.
-
-All 'port' nodes can be grouped under optional 'ports' node, which allows to
-specify #address-cells, #size-cells properties independently for the 'port'
-and 'endpoint' nodes and any child device nodes a device might have.
-
-Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
-phandles. An endpoint subnode of a device contains all properties needed for
-configuration of this device for data exchange with other device. In most
-cases properties at the peer 'endpoint' nodes will be identical, however they
-might need to be different when there is any signal modifications on the bus
-between two devices, e.g. there are logic signal inverters on the lines.
-
-It is allowed for multiple endpoints at a port to be active simultaneously,
-where supported by a device. For example, in case where a data interface of
-a device is partitioned into multiple data busses, e.g. 16-bit input port
-divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
-and data-shift properties can be used to assign physical data lines to each
-endpoint node (logical bus).
-
-Documenting bindings for devices
---------------------------------
-
-All required and optional bindings the device supports shall be explicitly
-documented in device DT binding documentation. This also includes port and
-endpoint nodes for the device, including unit-addresses and reg properties where
-relevant.
-
-Please also see Documentation/devicetree/bindings/graph.txt .
-
-Required properties
--------------------
-
-If there is more than one 'port' or more than one 'endpoint' node or 'reg'
-property is present in port and/or endpoint nodes the following properties
-are required in a relevant parent node:
-
- - #address-cells : number of cells required to define port/endpoint
- identifier, should be 1.
- - #size-cells : should be zero.
-
-
-Optional properties
--------------------
-
-- flash-leds: An array of phandles, each referring to a flash LED, a sub-node
- of the LED driver device node.
-
-- lens-focus: A phandle to the node of the focus lens controller.
-
-- rotation: The camera rotation is expressed as the angular difference in
- degrees between two reference systems, one relative to the camera module, and
- one defined on the external world scene to be captured when projected on the
- image sensor pixel array.
-
- A camera sensor has a 2-dimensional reference system 'Rc' defined by
- its pixel array read-out order. The origin is set to the first pixel
- being read out, the X-axis points along the column read-out direction
- towards the last columns, and the Y-axis along the row read-out
- direction towards the last row.
-
- A typical example for a sensor with a 2592x1944 pixel array matrix
- observed from the front is:
-
- 2591 X-axis 0
- <------------------------+ 0
- .......... ... ..........!
- .......... ... ..........! Y-axis
- ... !
- .......... ... ..........!
- .......... ... ..........! 1943
- V
-
- The external world scene reference system 'Rs' is a 2-dimensional
- reference system on the focal plane of the camera module. The origin is
- placed on the top-left corner of the visible scene, the X-axis points
- towards the right, and the Y-axis points towards the bottom of the
- scene. The top, bottom, left and right directions are intentionally not
- defined and depend on the environment in which the camera is used.
-
- A typical example of a (very common) picture of a shark swimming from
- left to right, as seen from the camera, is:
-
- 0 X-axis
- 0 +------------------------------------->
- !
- !
- !
- ! |\____)\___
- ! ) _____ __`<
- ! |/ )/
- !
- !
- !
- V
- Y-axis
-
- with the reference system 'Rs' placed on the camera focal plane:
-
- ¸.·˙!
- ¸.·˙ !
- _ ¸.·˙ !
- +-/ \-+¸.·˙ !
- | (o) | ! Camera focal plane
- +-----+˙·.¸ !
- ˙·.¸ !
- ˙·.¸ !
- ˙·.¸!
-
- When projected on the sensor's pixel array, the image and the associated
- reference system 'Rs' are typically (but not always) inverted, due to
- the camera module's lens optical inversion effect.
-
- Assuming the above represented scene of the swimming shark, the lens
- inversion projects the scene and its reference system onto the sensor
- pixel array, seen from the front of the camera sensor, as follows:
-
- Y-axis
- ^
- !
- !
- !
- ! |\_____)\__
- ! ) ____ ___.<
- ! |/ )/
- !
- !
- !
- 0 +------------------------------------->
- 0 X-axis
-
- Note the shark being upside-down.
-
- The resulting projected reference system is named 'Rp'.
-
- The camera rotation property is then defined as the angular difference
- in the counter-clockwise direction between the camera reference system
- 'Rc' and the projected scene reference system 'Rp'. It is expressed in
- degrees as a number in the range [0, 360[.
-
- Examples
-
- 0 degrees camera rotation:
-
-
- Y-Rp
- ^
- Y-Rc !
- ^ !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- 0 +------------------------------------->
- 0 X-Rc
-
-
- X-Rc 0
- <------------------------------------+ 0
- X-Rp 0 !
- <------------------------------------+ 0 !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rc
- V
- Y-Rp
-
- 90 degrees camera rotation:
-
- 0 Y-Rc
- 0 +-------------------->
- ! Y-Rp
- ! ^
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- !
- !
- !
- !
- V
- X-Rc
-
- 180 degrees camera rotation:
-
- 0
- <------------------------------------+ 0
- X-Rc !
- Y-Rp !
- ^ !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rc
- 0 +------------------------------------->
- 0 X-Rp
-
- 270 degrees camera rotation:
-
- 0 Y-Rc
- 0 +-------------------->
- ! 0
- ! <-----------------------------------+ 0
- ! X-Rp !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rp
- !
- !
- !
- !
- V
- X-Rc
-
-
- Example one - Webcam
-
- A camera module installed on the user facing part of a laptop screen
- casing used for video calls. The captured images are meant to be
- displayed in landscape mode (width > height) on the laptop screen.
-
- The camera is typically mounted upside-down to compensate the lens
- optical inversion effect:
-
- Y-Rp
- Y-Rc ^
- ^ !
- ! !
- ! ! |\_____)\__
- ! ! ) ____ ___.<
- ! ! |/ )/
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- 0 +------------------------------------->
- 0 X-Rc
-
- The two reference systems are aligned, the resulting camera rotation is
- 0 degrees, no rotation correction needs to be applied to the resulting
- image once captured to memory buffers to correctly display it to users:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! |\____)\___ !
- ! ) _____ __`< !
- ! |/ )/ !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- If the camera sensor is not mounted upside-down to compensate for the
- lens optical inversion, the two reference systems will not be aligned,
- with 'Rp' being rotated 180 degrees relatively to 'Rc':
-
-
- X-Rc 0
- <------------------------------------+ 0
- !
- Y-Rp !
- ^ !
- ! !
- ! |\_____)\__ !
- ! ) ____ ___.< !
- ! |/ )/ !
- ! !
- ! !
- ! V
- ! Y-Rc
- 0 +------------------------------------->
- 0 X-Rp
-
- The image once captured to memory will then be rotated by 180 degrees:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! __/(_____/| !
- ! >.___ ____ ( !
- ! \( \| !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- A software rotation correction of 180 degrees should be applied to
- correctly display the image:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! |\____)\___ !
- ! ) _____ __`< !
- ! |/ )/ !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- Example two - Phone camera
-
- A camera installed on the back side of a mobile device facing away from
- the user. The captured images are meant to be displayed in portrait mode
- (height > width) to match the device screen orientation and the device
- usage orientation used when taking the picture.
-
- The camera sensor is typically mounted with its pixel array longer side
- aligned to the device longer side, upside-down mounted to compensate for
- the lens optical inversion effect:
-
- 0 Y-Rc
- 0 +-------------------->
- ! Y-Rp
- ! ^
- ! !
- ! !
- ! !
- ! ! |\_____)\__
- ! ! ) ____ ___.<
- ! ! |/ )/
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- !
- !
- !
- !
- V
- X-Rc
-
- The two reference systems are not aligned and the 'Rp' reference
- system is rotated by 90 degrees in the counter-clockwise direction
- relatively to the 'Rc' reference system.
-
- The image once captured to memory will be rotated:
-
- +-------------------------------------+
- | _ _ |
- | \ / |
- | | | |
- | | | |
- | | > |
- | < | |
- | | | |
- | . |
- | V |
- +-------------------------------------+
-
- A correction of 90 degrees in counter-clockwise direction has to be
- applied to correctly display the image in portrait mode on the device
- screen:
-
- +--------------------+
- | |
- | |
- | |
- | |
- | |
- | |
- | |\____)\___ |
- | ) _____ __`< |
- | |/ )/ |
- | |
- | |
- | |
- | |
- | |
- +--------------------+
-
-- orientation: The orientation of a device (typically an image sensor or a flash
- LED) describing its mounting position relative to the usage orientation of the
- system where the device is installed on.
- Possible values are:
- 0 - Front. The device is mounted on the front facing side of the system.
- For mobile devices such as smartphones, tablets and laptops the front side is
- the user facing side.
- 1 - Back. The device is mounted on the back side of the system, which is
- defined as the opposite side of the front facing one.
- 2 - External. The device is not attached directly to the system but is
- attached in a way that allows it to move freely.
-
-Optional endpoint properties
-----------------------------
-
-- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
-- slave-mode: a boolean property indicating that the link is run in slave mode.
- The default when this property is not specified is master mode. In the slave
- mode horizontal and vertical synchronization signals are provided to the
- slave device (data source) by the master device (data sink). In the master
- mode the data source device is also the source of the synchronization signals.
-- bus-type: data bus type. Possible values are:
- 1 - MIPI CSI-2 C-PHY
- 2 - MIPI CSI1
- 3 - CCP2
- 4 - MIPI CSI-2 D-PHY
- 5 - Parallel
- 6 - Bt.656
-- bus-width: number of data lines actively used, valid for the parallel busses.
-- data-shift: on the parallel data busses, if bus-width is used to specify the
- number of data lines, data-shift can be used to specify which data lines are
- used, e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
-- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
-- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
- Note, that if HSYNC and VSYNC polarities are not specified, embedded
- synchronization may be required, where supported.
-- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
-- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
- signal polarity.
-- field-even-active: field signal level during the even field data transmission.
-- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
- signal.
-- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for
- LOW/HIGH respectively.
-- data-lanes: an array of physical data lane indexes. Position of an entry
- determines the logical lane number, while the value of an entry indicates
- physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
- "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
- If the hardware does not support lane reordering, monotonically
- incremented values shall be used from 0 or 1 onwards, depending on
- whether or not there is also a clock lane. This property is valid for
- serial busses only (e.g. MIPI CSI-2).
-- clock-lanes: an array of physical clock lane indexes. Position of an entry
- determines the logical lane number, while the value of an entry indicates
- physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
- which places the clock lane on hardware lane 0. This property is valid for
- serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
- array contains only one entry.
-- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
- clock mode.
-- link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for
- instance, this is the actual frequency of the bus, not bits per clock per
- lane value. An array of 64-bit unsigned integers.
-- lane-polarities: an array of polarities of the lanes starting from the clock
- lane and followed by the data lanes in the same order as in data-lanes.
- Valid values are 0 (normal) and 1 (inverted). The length of the array
- should be the combined length of data-lanes and clock-lanes properties.
- If the lane-polarities property is omitted, the value must be interpreted
- as 0 (normal). This property is valid for serial busses only.
-- strobe: Whether the clock signal is used as clock (0) or strobe (1). Used
- with CCP2, for instance.
-
-Example
--------
-
-The example snippet below describes two data pipelines. ov772x and imx074 are
-camera sensors with a parallel and serial (MIPI CSI-2) video bus respectively.
-Both sensors are on the I2C control bus corresponding to the i2c0 controller
-node. ov772x sensor is linked directly to the ceu0 video host interface.
-imx074 is linked to ceu0 through the MIPI CSI-2 receiver (csi2). ceu0 has a
-(single) DMA engine writing captured data to memory. ceu0 node has a single
-'port' node which may indicate that at any time only one of the following data
-pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
-
- ceu0: ceu@fe910000 {
- compatible = "renesas,sh-mobile-ceu";
- reg = <0xfe910000 0xa0>;
- interrupts = <0x880>;
-
- mclk: master_clock {
- compatible = "renesas,ceu-clock";
- #clock-cells = <1>;
- clock-frequency = <50000000>; /* Max clock frequency */
- clock-output-names = "mclk";
- };
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* Parallel bus endpoint */
- ceu0_1: endpoint@1 {
- reg = <1>; /* Local endpoint # */
- remote = <&ov772x_1_1>; /* Remote phandle */
- bus-width = <8>; /* Used data lines */
- data-shift = <2>; /* Lines 9:2 are used */
-
- /* If hsync-active/vsync-active are missing,
- embedded BT.656 sync is used */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- data-active = <1>; /* Active high */
- pclk-sample = <1>; /* Rising */
- };
-
- /* MIPI CSI-2 bus endpoint */
- ceu0_0: endpoint@0 {
- reg = <0>;
- remote = <&csi2_2>;
- };
- };
- };
-
- i2c0: i2c@fff20000 {
- ...
- ov772x_1: camera@21 {
- compatible = "ovti,ov772x";
- reg = <0x21>;
- vddio-supply = <®ulator1>;
- vddcore-supply = <®ulator2>;
-
- clock-frequency = <20000000>;
- clocks = <&mclk 0>;
- clock-names = "xclk";
-
- port {
- /* With 1 endpoint per port no need for addresses. */
- ov772x_1_1: endpoint {
- bus-width = <8>;
- remote-endpoint = <&ceu0_1>;
- hsync-active = <1>;
- vsync-active = <0>; /* Who came up with an
- inverter here ?... */
- data-active = <1>;
- pclk-sample = <1>;
- };
- };
- };
-
- imx074: camera@1a {
- compatible = "sony,imx074";
- reg = <0x1a>;
- vddio-supply = <®ulator1>;
- vddcore-supply = <®ulator2>;
-
- clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
- clocks = <&mclk 0>;
- clock-names = "sysclk"; /* Assuming this is the
- name in the datasheet */
- port {
- imx074_1: endpoint {
- clock-lanes = <0>;
- data-lanes = <1 2>;
- remote-endpoint = <&csi2_1>;
- };
- };
- };
- };
-
- csi2: csi2@ffc90000 {
- compatible = "renesas,sh-mobile-csi2";
- reg = <0xffc90000 0x1000>;
- interrupts = <0x17a0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
- reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
- PHY_M has port address 0,
- is unused. */
- csi2_1: endpoint {
- clock-lanes = <0>;
- data-lanes = <2 1>;
- remote-endpoint = <&imx074_1>;
- };
- };
- port@2 {
- reg = <2>; /* port 2: link to the CEU */
-
- csi2_2: endpoint {
- remote-endpoint = <&ceu0_0>;
- };
- };
- };
+This file has moved to video-interfaces.yaml and video-interface-devices.yaml.
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml
new file mode 100644
index 000000000000..fefca7d98718
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml
@@ -0,0 +1,346 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/video-interfaces.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for video receiver and transmitter interface endpoints
+
+maintainers:
+ - Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+ - Sakari Ailus <sakari.ailus@linux.intel.com>
+
+description: |
+ Video data pipelines usually consist of external devices, e.g. camera sensors,
+ controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
+ video DMA engines and video data processors.
+
+ SoC internal blocks are described by DT nodes, placed similarly to other SoC
+ blocks. External devices are represented as child nodes of their respective
+ bus controller nodes, e.g. I2C.
+
+ Data interfaces on all video devices are described by their child 'port' nodes.
+ Configuration of a port depends on other devices participating in the data
+ transfer and is described by 'endpoint' subnodes.
+
+ device {
+ ...
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ ...
+ endpoint@0 { ... };
+ endpoint@1 { ... };
+ };
+ port@1 { ... };
+ };
+ };
+
+ If a port can be configured to work with more than one remote device on the same
+ bus, an 'endpoint' child node must be provided for each of them. If more than
+ one port is present in a device node or there is more than one endpoint at a
+ port, or port node needs to be associated with a selected hardware interface,
+ a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
+ used.
+
+ All 'port' nodes can be grouped under optional 'ports' node, which allows to
+ specify #address-cells, #size-cells properties independently for the 'port'
+ and 'endpoint' nodes and any child device nodes a device might have.
+
+ Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
+ phandles. An endpoint subnode of a device contains all properties needed for
+ configuration of this device for data exchange with other device. In most
+ cases properties at the peer 'endpoint' nodes will be identical, however they
+ might need to be different when there is any signal modifications on the bus
+ between two devices, e.g. there are logic signal inverters on the lines.
+
+ It is allowed for multiple endpoints at a port to be active simultaneously,
+ where supported by a device. For example, in case where a data interface of
+ a device is partitioned into multiple data busses, e.g. 16-bit input port
+ divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
+ and data-shift properties can be used to assign physical data lines to each
+ endpoint node (logical bus).
+
+ Documenting bindings for devices
+ --------------------------------
+
+ All required and optional bindings the device supports shall be explicitly
+ documented in device DT binding documentation. This also includes port and
+ endpoint nodes for the device, including unit-addresses and reg properties
+ where relevant.
+
+ Please also see Documentation/devicetree/bindings/graph.txt .
+
+allOf:
+ - $ref: /schemas/graph.yaml#/$defs/endpoint-base
+
+properties:
+ slave-mode:
+ type: boolean
+ description:
+ Indicates that the link is run in slave mode. The default when this
+ property is not specified is master mode. In the slave mode horizontal and
+ vertical synchronization signals are provided to the slave device (data
+ source) by the master device (data sink). In the master mode the data
+ source device is also the source of the synchronization signals.
+
+ bus-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 1 # MIPI CSI-2 C-PHY
+ - 2 # MIPI CSI1
+ - 3 # CCP2
+ - 4 # MIPI CSI-2 D-PHY
+ - 5 # Parallel
+ - 6 # Bt.656
+ description:
+ Data bus type.
+
+ bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 64
+ description:
+ Number of data lines actively used, valid for the parallel busses.
+
+ data-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 64
+ description:
+ On the parallel data busses, if bus-width is used to specify the number of
+ data lines, data-shift can be used to specify which data lines are used,
+ e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
+
+ hsync-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
+
+ vsync-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. Note,
+ that if HSYNC and VSYNC polarities are not specified, embedded
+ synchronization may be required, where supported.
+
+ data-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Similar to HSYNC and VSYNC, specifies data line polarity.
+
+ data-enable-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Similar to HSYNC and VSYNC, specifies the data enable signal polarity.
+
+ field-even-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Field signal level during the even field data transmission.
+
+ pclk-sample:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Sample data on rising (1) or falling (0) edge of the pixel clock signal.
+
+ sync-on-green-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively.
+
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ items:
+ # Assume up to 9 physical lane indices
+ maximum: 8
+ description:
+ An array of physical data lane indexes. Position of an entry determines
+ the logical lane number, while the value of an entry indicates physical
+ lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;",
+ assuming the clock lane is on hardware lane 0. If the hardware does not
+ support lane reordering, monotonically incremented values shall be used
+ from 0 or 1 onwards, depending on whether or not there is also a clock
+ lane. This property is valid for serial busses only (e.g. MIPI CSI-2).
+
+ clock-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ # Assume up to 9 physical lane indices
+ maximum: 8
+ description:
+ Physical clock lane index. Position of an entry determines
+ the logical lane number, while the value of an entry indicates physical
+ lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;", which
+ places the clock lane on hardware lane 0. This property is valid for
+ serial busses only (e.g. MIPI CSI-2).
+
+ clock-noncontinuous:
+ type: boolean
+ description:
+ Allow MIPI CSI-2 non-continuous clock mode.
+
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ description:
+ Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the
+ actual frequency of the bus, not bits per clock per lane value. An array
+ of 64-bit unsigned integers.
+
+ lane-polarities:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 9
+ items:
+ enum: [ 0, 1 ]
+ description:
+ An array of polarities of the lanes starting from the clock lane and
+ followed by the data lanes in the same order as in data-lanes. Valid
+ values are 0 (normal) and 1 (inverted). The length of the array should be
+ the combined length of data-lanes and clock-lanes properties. If the
+ lane-polarities property is omitted, the value must be interpreted as 0
+ (normal). This property is valid for serial busses only.
+
+ strobe:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Whether the clock signal is used as clock (0) or strobe (1). Used with
+ CCP2, for instance.
+
+additionalProperties: true
+
+examples:
+ # The example snippet below describes two data pipelines. ov772x and imx074
+ # are camera sensors with a parallel and serial (MIPI CSI-2) video bus
+ # respectively. Both sensors are on the I2C control bus corresponding to the
+ # i2c0 controller node. ov772x sensor is linked directly to the ceu0 video
+ # host interface. imx074 is linked to ceu0 through the MIPI CSI-2 receiver
+ # (csi2). ceu0 has a (single) DMA engine writing captured data to memory.
+ # ceu0 node has a single 'port' node which may indicate that at any time
+ # only one of the following data pipelines can be active:
+ # ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
+ - |
+ ceu@fe910000 {
+ compatible = "renesas,sh-mobile-ceu";
+ reg = <0xfe910000 0xa0>;
+ interrupts = <0x880>;
+
+ mclk: master_clock {
+ compatible = "renesas,ceu-clock";
+ #clock-cells = <1>;
+ clock-frequency = <50000000>; /* Max clock frequency */
+ clock-output-names = "mclk";
+ };
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ ceu0_1: endpoint@1 {
+ reg = <1>; /* Local endpoint # */
+ remote-endpoint = <&ov772x_1_1>; /* Remote phandle */
+ bus-width = <8>; /* Used data lines */
+ data-shift = <2>; /* Lines 9:2 are used */
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+
+ /* MIPI CSI-2 bus endpoint */
+ ceu0_0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&csi2_2>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@21 {
+ compatible = "ovti,ov772x";
+ reg = <0x21>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <20000000>;
+ clocks = <&mclk 0>;
+ clock-names = "xclk";
+
+ port {
+ /* With 1 endpoint per port no need for addresses. */
+ ov772x_1_1: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&ceu0_1>;
+ hsync-active = <1>;
+ vsync-active = <0>; /* Who came up with an
+ inverter here ?... */
+ data-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
+ camera@1a {
+ compatible = "sony,imx074";
+ reg = <0x1a>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
+ clocks = <&mclk 0>;
+ clock-names = "sysclk"; /* Assuming this is the
+ name in the datasheet */
+ port {
+ imx074_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&csi2_1>;
+ };
+ };
+ };
+ };
+
+ csi2: csi2@ffc90000 {
+ compatible = "renesas,sh-mobile-csi2";
+ reg = <0xffc90000 0x1000>;
+ interrupts = <0x17a0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
+ reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
+ PHY_M has port address 0,
+ is unused. */
+ csi2_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <2 1>;
+ remote-endpoint = <&imx074_1>;
+ };
+ };
+ port@2 {
+ reg = <2>; /* port 2: link to the CEU */
+
+ csi2_2: endpoint {
+ remote-endpoint = <&ceu0_0>;
+ };
+ };
+ };
+
+...
--
2.25.1
^ permalink raw reply related
* [PATCH v3 2/2] dt-bindings: media: Use graph and video-interfaces schemas
From: Rob Herring @ 2020-12-10 21:16 UTC (permalink / raw)
To: Guennadi Liakhovetski, Sakari Ailus, Maxime Ripard,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media
In-Reply-To: <20201210211625.3070388-1-robh@kernel.org>
Now that we have graph and video-interfaces schemas, rework the media
related schemas to use them.
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Jacopo Mondi <jacopo@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3:
- Add mipi-ccs.yaml, ovti,ov02a10.yaml
v2:
- Update based on graph schema changes and addition of video-interfaces
schemas
---
.../media/allwinner,sun4i-a10-csi.yaml | 11 +-
.../media/allwinner,sun6i-a31-csi.yaml | 12 +-
.../bindings/media/i2c/adv7180.yaml | 36 ++----
.../bindings/media/i2c/adv7604.yaml | 37 ++----
.../bindings/media/i2c/aptina,mt9v111.yaml | 4 +-
.../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 +----
.../devicetree/bindings/media/i2c/imx219.yaml | 21 ++--
.../bindings/media/i2c/maxim,max9286.yaml | 101 ++++------------
.../bindings/media/i2c/mipi-ccs.yaml | 15 +--
.../devicetree/bindings/media/i2c/ov5647.yaml | 20 +---
.../devicetree/bindings/media/i2c/ov8856.yaml | 21 +---
.../bindings/media/i2c/ovti,ov02a10.yaml | 30 ++---
.../bindings/media/i2c/ovti,ov2680.yaml | 6 +-
.../bindings/media/i2c/ovti,ov772x.yaml | 9 +-
.../bindings/media/i2c/sony,imx214.yaml | 25 ++--
.../bindings/media/i2c/sony,imx274.yaml | 3 +-
.../bindings/media/marvell,mmp2-ccic.yaml | 15 +--
.../bindings/media/nxp,imx7-csi.yaml | 5 +-
.../bindings/media/nxp,imx7-mipi-csi2.yaml | 32 +----
.../bindings/media/renesas,ceu.yaml | 17 +--
.../bindings/media/renesas,csi2.yaml | 54 ++-------
.../bindings/media/renesas,vin.yaml | 113 +++---------------
.../bindings/media/rockchip-isp1.yaml | 40 +------
.../bindings/media/st,stm32-dcmi.yaml | 18 +--
.../devicetree/bindings/media/ti,cal.yaml | 55 ++-------
.../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +-----
26 files changed, 169 insertions(+), 600 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
index 09318830db47..6ced94064215 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
@@ -67,14 +67,14 @@ properties:
interconnect-names:
const: dma-mem
- # See ./video-interfaces.txt for details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-width:
@@ -83,7 +83,6 @@ properties:
data-active: true
hsync-active: true
pclk-sample: true
- remote-endpoint: true
vsync-active: true
required:
@@ -91,12 +90,8 @@ properties:
- data-active
- hsync-active
- pclk-sample
- - remote-endpoint
- vsync-active
- required:
- - endpoint
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..8b568072a069 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -40,17 +40,15 @@ properties:
resets:
maxItems: 1
- # See ./video-interfaces.txt for details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint: true
-
bus-width:
enum: [ 8, 10, 12, 16 ]
@@ -60,10 +58,6 @@ properties:
required:
- bus-width
- - remote-endpoint
-
- required:
- - endpoint
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
index d8c54f9d9506..bcfd93739b4f 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
@@ -36,17 +36,9 @@ properties:
maxItems: 1
port:
- type: object
- description:
- A node containing a single endpoint as doucmented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
- ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/port
+
+ ports: true
additionalProperties: false
@@ -80,25 +72,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@3:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-2]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@3
- additionalProperties: false
-
required:
- ports
@@ -110,25 +97,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@6:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-5]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@6
- additionalProperties: false
-
required:
- ports
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
index 407baddfaa1d..df634b0c1f8c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
@@ -64,16 +64,12 @@ properties:
description:
Select which input is selected after reset.
- ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ ports: true
required:
- compatible
- reg
+ - ports
additionalProperties: false
@@ -86,26 +82,19 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
+
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
required:
- port@1
- additionalProperties: false
-
- required:
- - ports
-
- if:
properties:
compatible:
@@ -114,28 +103,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@2:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-1]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@2
- additionalProperties: false
-
- required:
- - ports
-
examples:
- |
#include <dt-bindings/gpio/gpio.h>
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
index ff9546e95d05..e53b8d65f381 100644
--- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
@@ -41,9 +41,9 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: |
- Output video port. See ../video-interfaces.txt.
+ Output video port.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
index 3dc06c628e64..e57575c44930 100644
--- a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
@@ -86,33 +86,9 @@ properties:
maxItems: 3
port:
- type: object
- additionalProperties: false
- description: -|
- Connection to the remote GMSL endpoint are modelled using the OF graph
- bindings in accordance with the video interface bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
- The device node contains a single "port" child node with a single
- "endpoint" sub-device.
-
- properties:
- endpoint:
- type: object
- additionalProperties: false
-
- properties:
- remote-endpoint:
- description: -|
- phandle to the remote GMSL endpoint sub-node in the remote node
- port.
- maxItems: 1
-
- required:
- - remote-endpoint
-
- required:
- - endpoint
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Connection to the remote GMSL endpoint.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
index dfc4d29a4f04..012c0565d8ae 100644
--- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
@@ -44,12 +44,15 @@ properties:
Reference to the GPIO connected to the xclr pin, if any.
Must be released (set high) after all supplies are applied.
- # See ../video-interfaces.txt for more details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
properties:
data-lanes:
description: |-
@@ -60,16 +63,8 @@ properties:
- const: 1
- const: 2
- clock-noncontinuous:
- type: boolean
- description: |-
- MIPI CSI-2 clock is non-continuous if this property is present,
- otherwise it's continuous.
-
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description:
- Allowed data bus frequencies.
+ clock-noncontinuous: true
+ link-frequencies: true
required:
- link-frequencies
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 9ea827092fdd..3a52dc81eabd 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -52,81 +52,41 @@ properties:
const: 2
ports:
- type: object
- description: |
- The connections to the MAX9286 GMSL and its endpoint nodes are modelled
- using the OF graph bindings in accordance with the video interface
- bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
- The following table lists the port number corresponding to each device
- port.
-
- Port Description
- ----------------------------------------
- Port 0 GMSL Input 0
- Port 1 GMSL Input 1
- Port 2 GMSL Input 2
- Port 3 GMSL Input 3
- Port 4 CSI-2 Output
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- port@[0-3]:
- type: object
- properties:
- reg:
- enum: [ 0, 1, 2, 3 ]
-
- endpoint:
- type: object
-
- properties:
- remote-endpoint:
- description: |
- phandle to the remote GMSL source endpoint subnode in the
- remote node port.
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 0
- required:
- - remote-endpoint
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 1
- required:
- - reg
- - endpoint
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 2
- additionalProperties: false
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 3
port@4:
- type: object
- properties:
- reg:
- const: 4
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output
+ properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint:
- description: phandle to the remote CSI-2 sink endpoint.
-
- data-lanes:
- description: array of physical CSI-2 data lane indexes.
+ data-lanes: true
required:
- - remote-endpoint
- data-lanes
- required:
- - reg
- - endpoint
-
- additionalProperties: false
-
required:
- port@4
@@ -184,25 +144,8 @@ properties:
requirements of the currently connected remote device.
port:
- type: object
-
- properties:
- endpoint:
- type: object
-
- properties:
- remote-endpoint:
- description: phandle to the MAX9286 sink endpoint.
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- required:
- - endpoint
-
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connection to the MAX9286 sink.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
index d94bd67ccea1..3657f2f41098 100644
--- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
@@ -73,19 +73,16 @@ properties:
enum: [ 0, 180 ]
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
properties:
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description: List of allowed data link frequencies.
- data-lanes:
- minItems: 1
- maxItems: 8
bus-type:
- description: The type of the data bus.
oneOf:
- const: 1 # CSI-2 C-PHY
- const: 3 # CCP2
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.yaml b/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
index 280c62afae13..3b1ea9da437a 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
@@ -31,27 +31,15 @@ properties:
maxItems: 1
port:
- type: object
- description: |-
- Should contain one endpoint sub-node used to model connection to the
- video receiver according to the specification defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ $ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint:
- description: |-
- phandle to the video receiver input port.
-
- clock-noncontinuous:
- type: boolean
- description: |-
- Set to true to allow MIPI CSI-2 non-continuous clock operations.
-
- additionalProperties: false
+ clock-noncontinuous: true
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
index cde85553fd01..c29b057ae922 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
@@ -57,16 +57,13 @@ properties:
active low.
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
- description:
- A node containing an output port node with an endpoint definition
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
@@ -79,18 +76,13 @@ properties:
- const: 4
link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description:
- Allowed data bus frequencies. 360000000, 180000000 Hz or both
- are supported by the driver.
-
+ maxItems: 2
+ items:
+ enum: [ 360000000, 180000000 ]
required:
- link-frequencies
- required:
- - endpoint
-
required:
- compatible
- reg
@@ -139,4 +131,3 @@ examples:
};
};
...
-
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
index 1c3879ec4122..aaf541cd3833 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -17,6 +17,9 @@ description: |-
@ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
sensor output is available via CSI-2 serial data output.
+allOf:
+ - $ref: /schemas/media/video-interface-device.yaml#
+
properties:
compatible:
const: ovti,ov02a10
@@ -66,42 +69,33 @@ properties:
maxItems: 1
rotation:
- description:
- Definition of the sensor's placement.
- allOf:
- - $ref: "/schemas/types.yaml#/definitions/uint32"
- - enum:
- - 0 # Sensor Mounted Upright
- - 180 # Sensor Mounted Upside Down
- default: 0
-
- # See ../video-interfaces.txt for details
+ enum:
+ - 0 # Sensor Mounted Upright
+ - 180 # Sensor Mounted Upside Down
+ default: 0
+
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
description:
Output port node, single endpoint describing the CSI-2 transmitter.
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- link-frequencies: true
ovti,mipi-clock-voltage:
- allOf:
- - $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: "/schemas/types.yaml#/definitions/uint32"
description:
Definition of MIPI clock voltage unit. This entry corresponds to
the link speed defined by the 'link-frequencies' property.
If present, the value shall be in the range of 0-4.
default: 4
- remote-endpoint: true
required:
- link-frequencies
- - remote-endpoint
required:
- endpoint
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
index 43bf749807e1..cf456f8d9ddc 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
@@ -50,11 +50,9 @@ properties:
Definition of the regulator used as digital power supply.
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
- A node containing an output port node with an endpoint definition
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ A node containing an output port node.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
index 6866c2cdac50..44529425ce3a 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
@@ -37,13 +37,14 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
- Video output port. See ../video-interfaces.txt.
+ Video output port.
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-type:
@@ -91,8 +92,6 @@ properties:
required:
- bus-type
- unevaluatedProperties: false
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
index 1a3590dd0e98..1b69b6342978 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
@@ -15,6 +15,9 @@ description: |
interface. Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a
maximum throughput of 1.2Gbps/lane.
+allOf:
+ - $ref: ../video-interface-devices.yaml#
+
properties:
compatible:
const: sony,imx214
@@ -47,25 +50,21 @@ properties:
description: Chip digital core regulator (1.12V).
maxItems: 1
- flash-leds:
- description: See ../video-interfaces.txt
-
- lens-focus:
- description: See ../video-interfaces.txt
+ flash-leds: true
+ lens-focus: true
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
- Video output port. See ../video-interfaces.txt.
+ Video output port.
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: See ../video-interfaces.txt
anyOf:
- items:
- const: 1
@@ -76,16 +75,12 @@ properties:
- const: 3
- const: 4
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description: See ../video-interfaces.txt
+ link-frequencies: true
required:
- data-lanes
- link-frequencies
- unevaluatedProperties: false
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
index f697e1a20beb..90828020e42a 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
@@ -44,8 +44,7 @@ properties:
maxItems: 1
port:
- type: object
- description: Output video port. See ../video-interfaces.txt.
+ $ref: /schemas/graph.yaml#/properties/port
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
index 49bff738aca5..9e85c70d1a1f 100644
--- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
+++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
@@ -24,29 +24,20 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
- # Properties described in
- # Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
- remote-endpoint: true
hsync-active: true
vsync-active: true
pclk-sample: true
bus-type: true
- required:
- - remote-endpoint
-
- required:
- - endpoint
-
clocks:
minItems: 1
maxItems: 3
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
index 4e81a47e60ac..d91575b8ebb9 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
@@ -33,10 +33,7 @@ properties:
- const: mclk
port:
- type: object
- description:
- A node containing input port nodes with endpoint definitions as documented
- in Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/port
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
index 0668332959e7..be47a7b62ca9 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
@@ -58,35 +58,22 @@ properties:
Differential receiver (HS-RX) settle time
ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: See ../video-interfaces.txt
oneOf:
- items:
- const: 1
@@ -94,18 +81,11 @@ properties:
- const: 1
- const: 2
- remote-endpoint: true
-
required:
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Output port node
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.yaml b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
index c7e1e4fe67e6..50e0740af15a 100644
--- a/Documentation/devicetree/bindings/media/renesas,ceu.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
@@ -34,18 +34,15 @@ properties:
maxItems: 1
port:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
- # Properties described in
- # Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
- remote-endpoint: true
hsync-active: true
vsync-active: true
field-even-active: false
@@ -53,12 +50,6 @@ properties:
enum: [8, 16]
default: 8
- required:
- - remote-endpoint
-
- required:
- - endpoint
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
index 533c2f181db7..20396f1be999 100644
--- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
@@ -46,24 +46,19 @@ properties:
maxItems: 1
ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -72,50 +67,19 @@ properties:
data-lanes:
maxItems: 1
- remote-endpoint: true
-
required:
- clock-lanes
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Output port node, multiple endpoints describing all the R-Car VIN
modules connected the CSI-2 receiver.
- properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- reg:
- const: 1
-
- patternProperties:
- "^endpoint@[0-9a-f]$":
- type: object
-
- properties:
- reg:
- maxItems: 1
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
+ required:
+ - port@0
+ - port@1
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml
index ad2fe660364b..fe7c4cbfe4ba 100644
--- a/Documentation/devicetree/bindings/media/renesas,vin.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml
@@ -69,15 +69,15 @@ properties:
#The per-board settings for Gen2 and RZ/G1 platforms:
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
- A node containing a parallel input with a single endpoint definitions as
- documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ A node containing a parallel input
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
hsync-active:
@@ -106,15 +106,6 @@ properties:
data-active: true
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
-
#The per-board settings for Gen3 and RZ/G2 platforms:
renesas,id:
description: VIN channel number
@@ -123,23 +114,18 @@ properties:
maximum: 15
ports:
- type: object
- description:
- A node containing input nodes with endpoint definitions as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Input port node, single endpoint describing a parallel input source.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
hsync-active:
@@ -168,98 +154,29 @@ properties:
data-active: true
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- required:
- - endpoint
-
- additionalProperties: false
-
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Input port node, multiple endpoints describing all the R-Car CSI-2
modules connected the VIN.
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- reg:
- const: 1
-
endpoint@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI20.
- properties:
- reg:
- const: 0
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI21.
- properties:
- reg:
- const: 1
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@2:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI40.
- properties:
- reg:
- const: 2
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@3:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI41.
- properties:
- reg:
- const: 3
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
anyOf:
- required:
- endpoint@0
@@ -270,8 +187,6 @@ properties:
- required:
- endpoint@3
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
index 2004c054ed1a..a6b1eff879ed 100644
--- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
@@ -56,56 +56,26 @@ properties:
power-domains:
maxItems: 1
- # See ./video-interfaces.txt for details
ports:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description: connection point for sensors at MIPI-DPHY RX0
- additionalProperties: false
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
- reg:
- const: 0
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- reg:
- maxItems: 1
-
data-lanes:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
- - "#address-cells"
- - "#size-cells"
-
required:
- - "#address-cells"
- - "#size-cells"
- port@0
required:
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index c18574bb3e81..41e1d0cd80e5 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -37,16 +37,15 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
- DCMI supports a single port node with parallel bus. It should contain
- one 'port' child node with child 'endpoint' node. Please refer to the
- bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ DCMI supports a single port node with parallel bus.
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-type:
@@ -57,8 +56,6 @@ properties:
enum: [8, 10, 12, 14]
default: 8
- remote-endpoint: true
-
allOf:
- if:
properties:
@@ -73,14 +70,9 @@ properties:
enum: [8]
required:
- - remote-endpoint
- bus-type
- pclk-sample
- unevaluatedProperties: false
-
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml
index 5e066629287d..65177cd69514 100644
--- a/Documentation/devicetree/bindings/media/ti,cal.yaml
+++ b/Documentation/devicetree/bindings/media/ti,cal.yaml
@@ -15,10 +15,7 @@ description: |-
processing capability to connect CSI2 image-sensor modules to the
DRA72x device.
- CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
- should contain a 'port' child node with child 'endpoint' node. Please
- refer to the bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ CAL supports 2 camera port nodes on MIPI bus.
properties:
compatible:
@@ -67,31 +64,19 @@ properties:
Documentation/devicetree/bindings/power/power_domain.txt
maxItems: 1
- # See ./video-interfaces.txt for details
ports:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
port@0:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI2 Port #0
properties:
- reg:
- const: 0
- description: CSI2 Port #0
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -101,24 +86,15 @@ properties:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
-
port@1:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI2 Port #1
properties:
- reg:
- const: 1
- description: CSI2 Port #1
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -128,14 +104,7 @@ properties:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
-
required:
- - "#address-cells"
- - "#size-cells"
- port@0
required:
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
index 2961a5b6872f..7d77823dbb7a 100644
--- a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
@@ -97,24 +97,21 @@ properties:
maxItems: 1
ports:
- type: object
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
Input / sink port node, single endpoint describing the
CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
-
data-lanes:
description: |
This is required only in the sink port 0 endpoint which
@@ -130,41 +127,17 @@ properties:
- const: 3
- const: 4
- remote-endpoint: true
-
required:
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
- additionalProperties: false
+ unevaluatedProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: |
Output / source port node, endpoint describing modules
connected the CSI-2 receiver.
- properties:
-
- reg:
- const: 1
-
- endpoint:
- type: object
-
- properties:
-
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
-
required:
- compatible
- reg
--
2.25.1
^ permalink raw reply related
* [PATCH v2 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas
From: Rob Herring @ 2020-12-10 21:16 UTC (permalink / raw)
To: Guennadi Liakhovetski, Sakari Ailus, Maxime Ripard,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media
In-Reply-To: <20201210211625.3070388-1-robh@kernel.org>
Convert video-interfaces.txt to DT schema. As it contains a mixture of
device level and endpoint properties, split it up into 2 schemas.
Binding schemas will need to reference both the graph.yaml and
video-interfaces.yaml schemas. The exact schema depends on how many
ports and endpoints for the binding. A single port with a single
endpoint looks similar to this:
port:
$ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
bus-width:
enum: [ 8, 10, 12, 16 ]
pclk-sample: true
hsync-active: true
vsync-active: true
required:
- bus-width
additionalProperties: false
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
I need acks for dual licensing from the listed maintainers.
---
.../media/video-interface-devices.yaml | 405 +++++++++++
.../bindings/media/video-interfaces.txt | 640 +-----------------
.../bindings/media/video-interfaces.yaml | 344 ++++++++++
3 files changed, 750 insertions(+), 639 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/video-interface-devices.yaml
create mode 100644 Documentation/devicetree/bindings/media/video-interfaces.yaml
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
new file mode 100644
index 000000000000..037b93d62651
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -0,0 +1,405 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/video-interface-devices.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for video receiver and transmitter devices
+
+maintainers:
+ - Jacopo Mondi <jacopo@jmondi.org>
+
+properties:
+ flash-leds:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ An array of phandles, each referring to a flash LED, a sub-node of the LED
+ driver device node.
+
+ lens-focus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle to the node of the focus lens controller.
+
+ rotation:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 90, 180, 270 ]
+ description: |
+ The camera rotation is expressed as the angular difference in degrees
+ between two reference systems, one relative to the camera module, and one
+ defined on the external world scene to be captured when projected on the
+ image sensor pixel array.
+
+ A camera sensor has a 2-dimensional reference system 'Rc' defined by its
+ pixel array read-out order. The origin is set to the first pixel being
+ read out, the X-axis points along the column read-out direction towards
+ the last columns, and the Y-axis along the row read-out direction towards
+ the last row.
+
+ A typical example for a sensor with a 2592x1944 pixel array matrix
+ observed from the front is:
+
+ 2591 X-axis 0
+ <------------------------+ 0
+ .......... ... ..........!
+ .......... ... ..........! Y-axis
+ ... !
+ .......... ... ..........!
+ .......... ... ..........! 1943
+ V
+
+ The external world scene reference system 'Rs' is a 2-dimensional
+ reference system on the focal plane of the camera module. The origin is
+ placed on the top-left corner of the visible scene, the X-axis points
+ towards the right, and the Y-axis points towards the bottom of the scene.
+ The top, bottom, left and right directions are intentionally not defined
+ and depend on the environment in which the camera is used.
+
+ A typical example of a (very common) picture of a shark swimming from left
+ to right, as seen from the camera, is:
+
+ 0 X-axis
+ 0 +------------------------------------->
+ !
+ !
+ !
+ ! |\____)\___
+ ! ) _____ __`<
+ ! |/ )/
+ !
+ !
+ !
+ V
+ Y-axis
+
+ with the reference system 'Rs' placed on the camera focal plane:
+
+ ¸.·˙!
+ ¸.·˙ !
+ _ ¸.·˙ !
+ +-/ \-+¸.·˙ !
+ | (o) | ! Camera focal plane
+ +-----+˙·.¸ !
+ ˙·.¸ !
+ ˙·.¸ !
+ ˙·.¸!
+
+ When projected on the sensor's pixel array, the image and the associated
+ reference system 'Rs' are typically (but not always) inverted, due to the
+ camera module's lens optical inversion effect.
+
+ Assuming the above represented scene of the swimming shark, the lens
+ inversion projects the scene and its reference system onto the sensor
+ pixel array, seen from the front of the camera sensor, as follows:
+
+ Y-axis
+ ^
+ !
+ !
+ !
+ ! |\_____)\__
+ ! ) ____ ___.<
+ ! |/ )/
+ !
+ !
+ !
+ 0 +------------------------------------->
+ 0 X-axis
+
+ Note the shark being upside-down.
+
+ The resulting projected reference system is named 'Rp'.
+
+ The camera rotation property is then defined as the angular difference in
+ the counter-clockwise direction between the camera reference system 'Rc'
+ and the projected scene reference system 'Rp'. It is expressed in degrees
+ as a number in the range [0, 360[.
+
+ Examples
+
+ 0 degrees camera rotation:
+
+
+ Y-Rp
+ ^
+ Y-Rc !
+ ^ !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ 0 +------------------------------------->
+ 0 X-Rc
+
+
+ X-Rc 0
+ <------------------------------------+ 0
+ X-Rp 0 !
+ <------------------------------------+ 0 !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ V
+ Y-Rp
+
+ 90 degrees camera rotation:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! Y-Rp
+ ! ^
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+ 180 degrees camera rotation:
+
+ 0
+ <------------------------------------+ 0
+ X-Rc !
+ Y-Rp !
+ ^ !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ 0 +------------------------------------->
+ 0 X-Rp
+
+ 270 degrees camera rotation:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! 0
+ ! <-----------------------------------+ 0
+ ! X-Rp !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+
+ Example one - Webcam
+
+ A camera module installed on the user facing part of a laptop screen
+ casing used for video calls. The captured images are meant to be displayed
+ in landscape mode (width > height) on the laptop screen.
+
+ The camera is typically mounted upside-down to compensate the lens optical
+ inversion effect:
+
+ Y-Rp
+ Y-Rc ^
+ ^ !
+ ! !
+ ! ! |\_____)\__
+ ! ! ) ____ ___.<
+ ! ! |/ )/
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ 0 +------------------------------------->
+ 0 X-Rc
+
+ The two reference systems are aligned, the resulting camera rotation is
+ 0 degrees, no rotation correction needs to be applied to the resulting
+ image once captured to memory buffers to correctly display it to users:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! |\____)\___ !
+ ! ) _____ __`< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ If the camera sensor is not mounted upside-down to compensate for the lens
+ optical inversion, the two reference systems will not be aligned, with
+ 'Rp' being rotated 180 degrees relatively to 'Rc':
+
+
+ X-Rc 0
+ <------------------------------------+ 0
+ !
+ Y-Rp !
+ ^ !
+ ! !
+ ! |\_____)\__ !
+ ! ) ____ ___.< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ 0 +------------------------------------->
+ 0 X-Rp
+
+ The image once captured to memory will then be rotated by 180 degrees:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! __/(_____/| !
+ ! >.___ ____ ( !
+ ! \( \| !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ A software rotation correction of 180 degrees should be applied to
+ correctly display the image:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! |\____)\___ !
+ ! ) _____ __`< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ Example two - Phone camera
+
+ A camera installed on the back side of a mobile device facing away from
+ the user. The captured images are meant to be displayed in portrait mode
+ (height > width) to match the device screen orientation and the device
+ usage orientation used when taking the picture.
+
+ The camera sensor is typically mounted with its pixel array longer side
+ aligned to the device longer side, upside-down mounted to compensate for
+ the lens optical inversion effect:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! Y-Rp
+ ! ^
+ ! !
+ ! !
+ ! !
+ ! ! |\_____)\__
+ ! ! ) ____ ___.<
+ ! ! |/ )/
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+ The two reference systems are not aligned and the 'Rp' reference system is
+ rotated by 90 degrees in the counter-clockwise direction relatively to the
+ 'Rc' reference system.
+
+ The image once captured to memory will be rotated:
+
+ +-------------------------------------+
+ | _ _ |
+ | \ / |
+ | | | |
+ | | | |
+ | | > |
+ | < | |
+ | | | |
+ | . |
+ | V |
+ +-------------------------------------+
+
+ A correction of 90 degrees in counter-clockwise direction has to be
+ applied to correctly display the image in portrait mode on the device
+ screen:
+
+ +--------------------+
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |\____)\___ |
+ | ) _____ __`< |
+ | |/ )/ |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +--------------------+
+
+ orientation:
+ description:
+ The orientation of a device (typically an image sensor or a flash LED)
+ describing its mounting position relative to the usage orientation of the
+ system where the device is installed on.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ # Front. The device is mounted on the front facing side of the system. For
+ # mobile devices such as smartphones, tablets and laptops the front side
+ # is the user facing side.
+ - 0
+ # Back. The device is mounted on the back side of the system, which is
+ # defined as the opposite side of the front facing one.
+ - 1
+ # External. The device is not attached directly to the system but is
+ # attached in a way that allows it to move freely.
+ - 2
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 3920f25a9123..8fcf5f52bf5b 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -1,639 +1 @@
-Common bindings for video receiver and transmitter interfaces
-
-General concept
----------------
-
-Video data pipelines usually consist of external devices, e.g. camera sensors,
-controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
-video DMA engines and video data processors.
-
-SoC internal blocks are described by DT nodes, placed similarly to other SoC
-blocks. External devices are represented as child nodes of their respective
-bus controller nodes, e.g. I2C.
-
-Data interfaces on all video devices are described by their child 'port' nodes.
-Configuration of a port depends on other devices participating in the data
-transfer and is described by 'endpoint' subnodes.
-
-device {
- ...
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- ...
- endpoint@0 { ... };
- endpoint@1 { ... };
- };
- port@1 { ... };
- };
-};
-
-If a port can be configured to work with more than one remote device on the same
-bus, an 'endpoint' child node must be provided for each of them. If more than
-one port is present in a device node or there is more than one endpoint at a
-port, or port node needs to be associated with a selected hardware interface,
-a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
-used.
-
-All 'port' nodes can be grouped under optional 'ports' node, which allows to
-specify #address-cells, #size-cells properties independently for the 'port'
-and 'endpoint' nodes and any child device nodes a device might have.
-
-Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
-phandles. An endpoint subnode of a device contains all properties needed for
-configuration of this device for data exchange with other device. In most
-cases properties at the peer 'endpoint' nodes will be identical, however they
-might need to be different when there is any signal modifications on the bus
-between two devices, e.g. there are logic signal inverters on the lines.
-
-It is allowed for multiple endpoints at a port to be active simultaneously,
-where supported by a device. For example, in case where a data interface of
-a device is partitioned into multiple data busses, e.g. 16-bit input port
-divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
-and data-shift properties can be used to assign physical data lines to each
-endpoint node (logical bus).
-
-Documenting bindings for devices
---------------------------------
-
-All required and optional bindings the device supports shall be explicitly
-documented in device DT binding documentation. This also includes port and
-endpoint nodes for the device, including unit-addresses and reg properties where
-relevant.
-
-Please also see Documentation/devicetree/bindings/graph.txt .
-
-Required properties
--------------------
-
-If there is more than one 'port' or more than one 'endpoint' node or 'reg'
-property is present in port and/or endpoint nodes the following properties
-are required in a relevant parent node:
-
- - #address-cells : number of cells required to define port/endpoint
- identifier, should be 1.
- - #size-cells : should be zero.
-
-
-Optional properties
--------------------
-
-- flash-leds: An array of phandles, each referring to a flash LED, a sub-node
- of the LED driver device node.
-
-- lens-focus: A phandle to the node of the focus lens controller.
-
-- rotation: The camera rotation is expressed as the angular difference in
- degrees between two reference systems, one relative to the camera module, and
- one defined on the external world scene to be captured when projected on the
- image sensor pixel array.
-
- A camera sensor has a 2-dimensional reference system 'Rc' defined by
- its pixel array read-out order. The origin is set to the first pixel
- being read out, the X-axis points along the column read-out direction
- towards the last columns, and the Y-axis along the row read-out
- direction towards the last row.
-
- A typical example for a sensor with a 2592x1944 pixel array matrix
- observed from the front is:
-
- 2591 X-axis 0
- <------------------------+ 0
- .......... ... ..........!
- .......... ... ..........! Y-axis
- ... !
- .......... ... ..........!
- .......... ... ..........! 1943
- V
-
- The external world scene reference system 'Rs' is a 2-dimensional
- reference system on the focal plane of the camera module. The origin is
- placed on the top-left corner of the visible scene, the X-axis points
- towards the right, and the Y-axis points towards the bottom of the
- scene. The top, bottom, left and right directions are intentionally not
- defined and depend on the environment in which the camera is used.
-
- A typical example of a (very common) picture of a shark swimming from
- left to right, as seen from the camera, is:
-
- 0 X-axis
- 0 +------------------------------------->
- !
- !
- !
- ! |\____)\___
- ! ) _____ __`<
- ! |/ )/
- !
- !
- !
- V
- Y-axis
-
- with the reference system 'Rs' placed on the camera focal plane:
-
- ¸.·˙!
- ¸.·˙ !
- _ ¸.·˙ !
- +-/ \-+¸.·˙ !
- | (o) | ! Camera focal plane
- +-----+˙·.¸ !
- ˙·.¸ !
- ˙·.¸ !
- ˙·.¸!
-
- When projected on the sensor's pixel array, the image and the associated
- reference system 'Rs' are typically (but not always) inverted, due to
- the camera module's lens optical inversion effect.
-
- Assuming the above represented scene of the swimming shark, the lens
- inversion projects the scene and its reference system onto the sensor
- pixel array, seen from the front of the camera sensor, as follows:
-
- Y-axis
- ^
- !
- !
- !
- ! |\_____)\__
- ! ) ____ ___.<
- ! |/ )/
- !
- !
- !
- 0 +------------------------------------->
- 0 X-axis
-
- Note the shark being upside-down.
-
- The resulting projected reference system is named 'Rp'.
-
- The camera rotation property is then defined as the angular difference
- in the counter-clockwise direction between the camera reference system
- 'Rc' and the projected scene reference system 'Rp'. It is expressed in
- degrees as a number in the range [0, 360[.
-
- Examples
-
- 0 degrees camera rotation:
-
-
- Y-Rp
- ^
- Y-Rc !
- ^ !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- 0 +------------------------------------->
- 0 X-Rc
-
-
- X-Rc 0
- <------------------------------------+ 0
- X-Rp 0 !
- <------------------------------------+ 0 !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rc
- V
- Y-Rp
-
- 90 degrees camera rotation:
-
- 0 Y-Rc
- 0 +-------------------->
- ! Y-Rp
- ! ^
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- !
- !
- !
- !
- V
- X-Rc
-
- 180 degrees camera rotation:
-
- 0
- <------------------------------------+ 0
- X-Rc !
- Y-Rp !
- ^ !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rc
- 0 +------------------------------------->
- 0 X-Rp
-
- 270 degrees camera rotation:
-
- 0 Y-Rc
- 0 +-------------------->
- ! 0
- ! <-----------------------------------+ 0
- ! X-Rp !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rp
- !
- !
- !
- !
- V
- X-Rc
-
-
- Example one - Webcam
-
- A camera module installed on the user facing part of a laptop screen
- casing used for video calls. The captured images are meant to be
- displayed in landscape mode (width > height) on the laptop screen.
-
- The camera is typically mounted upside-down to compensate the lens
- optical inversion effect:
-
- Y-Rp
- Y-Rc ^
- ^ !
- ! !
- ! ! |\_____)\__
- ! ! ) ____ ___.<
- ! ! |/ )/
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- 0 +------------------------------------->
- 0 X-Rc
-
- The two reference systems are aligned, the resulting camera rotation is
- 0 degrees, no rotation correction needs to be applied to the resulting
- image once captured to memory buffers to correctly display it to users:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! |\____)\___ !
- ! ) _____ __`< !
- ! |/ )/ !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- If the camera sensor is not mounted upside-down to compensate for the
- lens optical inversion, the two reference systems will not be aligned,
- with 'Rp' being rotated 180 degrees relatively to 'Rc':
-
-
- X-Rc 0
- <------------------------------------+ 0
- !
- Y-Rp !
- ^ !
- ! !
- ! |\_____)\__ !
- ! ) ____ ___.< !
- ! |/ )/ !
- ! !
- ! !
- ! V
- ! Y-Rc
- 0 +------------------------------------->
- 0 X-Rp
-
- The image once captured to memory will then be rotated by 180 degrees:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! __/(_____/| !
- ! >.___ ____ ( !
- ! \( \| !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- A software rotation correction of 180 degrees should be applied to
- correctly display the image:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! |\____)\___ !
- ! ) _____ __`< !
- ! |/ )/ !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- Example two - Phone camera
-
- A camera installed on the back side of a mobile device facing away from
- the user. The captured images are meant to be displayed in portrait mode
- (height > width) to match the device screen orientation and the device
- usage orientation used when taking the picture.
-
- The camera sensor is typically mounted with its pixel array longer side
- aligned to the device longer side, upside-down mounted to compensate for
- the lens optical inversion effect:
-
- 0 Y-Rc
- 0 +-------------------->
- ! Y-Rp
- ! ^
- ! !
- ! !
- ! !
- ! ! |\_____)\__
- ! ! ) ____ ___.<
- ! ! |/ )/
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- !
- !
- !
- !
- V
- X-Rc
-
- The two reference systems are not aligned and the 'Rp' reference
- system is rotated by 90 degrees in the counter-clockwise direction
- relatively to the 'Rc' reference system.
-
- The image once captured to memory will be rotated:
-
- +-------------------------------------+
- | _ _ |
- | \ / |
- | | | |
- | | | |
- | | > |
- | < | |
- | | | |
- | . |
- | V |
- +-------------------------------------+
-
- A correction of 90 degrees in counter-clockwise direction has to be
- applied to correctly display the image in portrait mode on the device
- screen:
-
- +--------------------+
- | |
- | |
- | |
- | |
- | |
- | |
- | |\____)\___ |
- | ) _____ __`< |
- | |/ )/ |
- | |
- | |
- | |
- | |
- | |
- +--------------------+
-
-- orientation: The orientation of a device (typically an image sensor or a flash
- LED) describing its mounting position relative to the usage orientation of the
- system where the device is installed on.
- Possible values are:
- 0 - Front. The device is mounted on the front facing side of the system.
- For mobile devices such as smartphones, tablets and laptops the front side is
- the user facing side.
- 1 - Back. The device is mounted on the back side of the system, which is
- defined as the opposite side of the front facing one.
- 2 - External. The device is not attached directly to the system but is
- attached in a way that allows it to move freely.
-
-Optional endpoint properties
-----------------------------
-
-- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
-- slave-mode: a boolean property indicating that the link is run in slave mode.
- The default when this property is not specified is master mode. In the slave
- mode horizontal and vertical synchronization signals are provided to the
- slave device (data source) by the master device (data sink). In the master
- mode the data source device is also the source of the synchronization signals.
-- bus-type: data bus type. Possible values are:
- 1 - MIPI CSI-2 C-PHY
- 2 - MIPI CSI1
- 3 - CCP2
- 4 - MIPI CSI-2 D-PHY
- 5 - Parallel
- 6 - Bt.656
-- bus-width: number of data lines actively used, valid for the parallel busses.
-- data-shift: on the parallel data busses, if bus-width is used to specify the
- number of data lines, data-shift can be used to specify which data lines are
- used, e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
-- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
-- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
- Note, that if HSYNC and VSYNC polarities are not specified, embedded
- synchronization may be required, where supported.
-- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
-- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
- signal polarity.
-- field-even-active: field signal level during the even field data transmission.
-- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
- signal.
-- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for
- LOW/HIGH respectively.
-- data-lanes: an array of physical data lane indexes. Position of an entry
- determines the logical lane number, while the value of an entry indicates
- physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
- "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
- If the hardware does not support lane reordering, monotonically
- incremented values shall be used from 0 or 1 onwards, depending on
- whether or not there is also a clock lane. This property is valid for
- serial busses only (e.g. MIPI CSI-2).
-- clock-lanes: an array of physical clock lane indexes. Position of an entry
- determines the logical lane number, while the value of an entry indicates
- physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
- which places the clock lane on hardware lane 0. This property is valid for
- serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
- array contains only one entry.
-- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
- clock mode.
-- link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for
- instance, this is the actual frequency of the bus, not bits per clock per
- lane value. An array of 64-bit unsigned integers.
-- lane-polarities: an array of polarities of the lanes starting from the clock
- lane and followed by the data lanes in the same order as in data-lanes.
- Valid values are 0 (normal) and 1 (inverted). The length of the array
- should be the combined length of data-lanes and clock-lanes properties.
- If the lane-polarities property is omitted, the value must be interpreted
- as 0 (normal). This property is valid for serial busses only.
-- strobe: Whether the clock signal is used as clock (0) or strobe (1). Used
- with CCP2, for instance.
-
-Example
--------
-
-The example snippet below describes two data pipelines. ov772x and imx074 are
-camera sensors with a parallel and serial (MIPI CSI-2) video bus respectively.
-Both sensors are on the I2C control bus corresponding to the i2c0 controller
-node. ov772x sensor is linked directly to the ceu0 video host interface.
-imx074 is linked to ceu0 through the MIPI CSI-2 receiver (csi2). ceu0 has a
-(single) DMA engine writing captured data to memory. ceu0 node has a single
-'port' node which may indicate that at any time only one of the following data
-pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
-
- ceu0: ceu@fe910000 {
- compatible = "renesas,sh-mobile-ceu";
- reg = <0xfe910000 0xa0>;
- interrupts = <0x880>;
-
- mclk: master_clock {
- compatible = "renesas,ceu-clock";
- #clock-cells = <1>;
- clock-frequency = <50000000>; /* Max clock frequency */
- clock-output-names = "mclk";
- };
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* Parallel bus endpoint */
- ceu0_1: endpoint@1 {
- reg = <1>; /* Local endpoint # */
- remote = <&ov772x_1_1>; /* Remote phandle */
- bus-width = <8>; /* Used data lines */
- data-shift = <2>; /* Lines 9:2 are used */
-
- /* If hsync-active/vsync-active are missing,
- embedded BT.656 sync is used */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- data-active = <1>; /* Active high */
- pclk-sample = <1>; /* Rising */
- };
-
- /* MIPI CSI-2 bus endpoint */
- ceu0_0: endpoint@0 {
- reg = <0>;
- remote = <&csi2_2>;
- };
- };
- };
-
- i2c0: i2c@fff20000 {
- ...
- ov772x_1: camera@21 {
- compatible = "ovti,ov772x";
- reg = <0x21>;
- vddio-supply = <®ulator1>;
- vddcore-supply = <®ulator2>;
-
- clock-frequency = <20000000>;
- clocks = <&mclk 0>;
- clock-names = "xclk";
-
- port {
- /* With 1 endpoint per port no need for addresses. */
- ov772x_1_1: endpoint {
- bus-width = <8>;
- remote-endpoint = <&ceu0_1>;
- hsync-active = <1>;
- vsync-active = <0>; /* Who came up with an
- inverter here ?... */
- data-active = <1>;
- pclk-sample = <1>;
- };
- };
- };
-
- imx074: camera@1a {
- compatible = "sony,imx074";
- reg = <0x1a>;
- vddio-supply = <®ulator1>;
- vddcore-supply = <®ulator2>;
-
- clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
- clocks = <&mclk 0>;
- clock-names = "sysclk"; /* Assuming this is the
- name in the datasheet */
- port {
- imx074_1: endpoint {
- clock-lanes = <0>;
- data-lanes = <1 2>;
- remote-endpoint = <&csi2_1>;
- };
- };
- };
- };
-
- csi2: csi2@ffc90000 {
- compatible = "renesas,sh-mobile-csi2";
- reg = <0xffc90000 0x1000>;
- interrupts = <0x17a0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
- reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
- PHY_M has port address 0,
- is unused. */
- csi2_1: endpoint {
- clock-lanes = <0>;
- data-lanes = <2 1>;
- remote-endpoint = <&imx074_1>;
- };
- };
- port@2 {
- reg = <2>; /* port 2: link to the CEU */
-
- csi2_2: endpoint {
- remote-endpoint = <&ceu0_0>;
- };
- };
- };
+This file has moved to video-interfaces.yaml and video-interface-devices.yaml.
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml
new file mode 100644
index 000000000000..7415a4df1576
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml
@@ -0,0 +1,344 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/video-interfaces.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for video receiver and transmitter interface endpoints
+
+maintainers:
+ - Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+ - Sakari Ailus <sakari.ailus@linux.intel.com>
+
+description: |
+ Video data pipelines usually consist of external devices, e.g. camera sensors,
+ controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
+ video DMA engines and video data processors.
+
+ SoC internal blocks are described by DT nodes, placed similarly to other SoC
+ blocks. External devices are represented as child nodes of their respective
+ bus controller nodes, e.g. I2C.
+
+ Data interfaces on all video devices are described by their child 'port' nodes.
+ Configuration of a port depends on other devices participating in the data
+ transfer and is described by 'endpoint' subnodes.
+
+ device {
+ ...
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ ...
+ endpoint@0 { ... };
+ endpoint@1 { ... };
+ };
+ port@1 { ... };
+ };
+ };
+
+ If a port can be configured to work with more than one remote device on the same
+ bus, an 'endpoint' child node must be provided for each of them. If more than
+ one port is present in a device node or there is more than one endpoint at a
+ port, or port node needs to be associated with a selected hardware interface,
+ a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
+ used.
+
+ All 'port' nodes can be grouped under optional 'ports' node, which allows to
+ specify #address-cells, #size-cells properties independently for the 'port'
+ and 'endpoint' nodes and any child device nodes a device might have.
+
+ Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
+ phandles. An endpoint subnode of a device contains all properties needed for
+ configuration of this device for data exchange with other device. In most
+ cases properties at the peer 'endpoint' nodes will be identical, however they
+ might need to be different when there is any signal modifications on the bus
+ between two devices, e.g. there are logic signal inverters on the lines.
+
+ It is allowed for multiple endpoints at a port to be active simultaneously,
+ where supported by a device. For example, in case where a data interface of
+ a device is partitioned into multiple data busses, e.g. 16-bit input port
+ divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
+ and data-shift properties can be used to assign physical data lines to each
+ endpoint node (logical bus).
+
+ Documenting bindings for devices
+ --------------------------------
+
+ All required and optional bindings the device supports shall be explicitly
+ documented in device DT binding documentation. This also includes port and
+ endpoint nodes for the device, including unit-addresses and reg properties
+ where relevant.
+
+ Please also see Documentation/devicetree/bindings/graph.txt .
+
+allOf:
+ - $ref: /schemas/graph.yaml#/$defs/endpoint-base
+
+properties:
+ slave-mode:
+ type: boolean
+ description:
+ Indicates that the link is run in slave mode. The default when this
+ property is not specified is master mode. In the slave mode horizontal and
+ vertical synchronization signals are provided to the slave device (data
+ source) by the master device (data sink). In the master mode the data
+ source device is also the source of the synchronization signals.
+
+ bus-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 1 # MIPI CSI-2 C-PHY
+ - 2 # MIPI CSI1
+ - 3 # CCP2
+ - 4 # MIPI CSI-2 D-PHY
+ - 5 # Parallel
+ - 6 # Bt.656
+ description:
+ Data bus type.
+
+ bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 64
+ description:
+ Number of data lines actively used, valid for the parallel busses.
+
+ data-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 64
+ description:
+ On the parallel data busses, if bus-width is used to specify the number of
+ data lines, data-shift can be used to specify which data lines are used,
+ e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
+
+ hsync-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
+
+ vsync-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. Note,
+ that if HSYNC and VSYNC polarities are not specified, embedded
+ synchronization may be required, where supported.
+
+ data-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Similar to HSYNC and VSYNC, specifies data line polarity.
+
+ data-enable-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Similar to HSYNC and VSYNC, specifies the data enable signal polarity.
+
+ field-even-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Field signal level during the even field data transmission.
+
+ pclk-sample:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Sample data on rising (1) or falling (0) edge of the pixel clock signal.
+
+ sync-on-green-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively.
+
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ items:
+ # Assume up to 4 data and 1 clock lane
+ maximum: 4
+ description:
+ An array of physical data lane indexes. Position of an entry determines
+ the logical lane number, while the value of an entry indicates physical
+ lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;",
+ assuming the clock lane is on hardware lane 0. If the hardware does not
+ support lane reordering, monotonically incremented values shall be used
+ from 0 or 1 onwards, depending on whether or not there is also a clock
+ lane. This property is valid for serial busses only (e.g. MIPI CSI-2).
+
+ clock-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ # Assume up to 4 data and 1 clock lane
+ maximum: 4
+ description:
+ Physical clock lane index. Position of an entry determines
+ the logical lane number, while the value of an entry indicates physical
+ lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;", which
+ places the clock lane on hardware lane 0. This property is valid for
+ serial busses only (e.g. MIPI CSI-2).
+
+ clock-noncontinuous:
+ type: boolean
+ description:
+ Allow MIPI CSI-2 non-continuous clock mode.
+
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ description:
+ Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the
+ actual frequency of the bus, not bits per clock per lane value. An array
+ of 64-bit unsigned integers.
+
+ lane-polarities:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ enum: [ 0, 1 ]
+ description:
+ An array of polarities of the lanes starting from the clock lane and
+ followed by the data lanes in the same order as in data-lanes. Valid
+ values are 0 (normal) and 1 (inverted). The length of the array should be
+ the combined length of data-lanes and clock-lanes properties. If the
+ lane-polarities property is omitted, the value must be interpreted as 0
+ (normal). This property is valid for serial busses only.
+
+ strobe:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Whether the clock signal is used as clock (0) or strobe (1). Used with
+ CCP2, for instance.
+
+additionalProperties: true
+
+examples:
+ # The example snippet below describes two data pipelines. ov772x and imx074
+ # are camera sensors with a parallel and serial (MIPI CSI-2) video bus
+ # respectively. Both sensors are on the I2C control bus corresponding to the
+ # i2c0 controller node. ov772x sensor is linked directly to the ceu0 video
+ # host interface. imx074 is linked to ceu0 through the MIPI CSI-2 receiver
+ # (csi2). ceu0 has a (single) DMA engine writing captured data to memory.
+ # ceu0 node has a single 'port' node which may indicate that at any time
+ # only one of the following data pipelines can be active:
+ # ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
+ - |
+ ceu@fe910000 {
+ compatible = "renesas,sh-mobile-ceu";
+ reg = <0xfe910000 0xa0>;
+ interrupts = <0x880>;
+
+ mclk: master_clock {
+ compatible = "renesas,ceu-clock";
+ #clock-cells = <1>;
+ clock-frequency = <50000000>; /* Max clock frequency */
+ clock-output-names = "mclk";
+ };
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ ceu0_1: endpoint@1 {
+ reg = <1>; /* Local endpoint # */
+ remote-endpoint = <&ov772x_1_1>; /* Remote phandle */
+ bus-width = <8>; /* Used data lines */
+ data-shift = <2>; /* Lines 9:2 are used */
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+
+ /* MIPI CSI-2 bus endpoint */
+ ceu0_0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&csi2_2>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@21 {
+ compatible = "ovti,ov772x";
+ reg = <0x21>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <20000000>;
+ clocks = <&mclk 0>;
+ clock-names = "xclk";
+
+ port {
+ /* With 1 endpoint per port no need for addresses. */
+ ov772x_1_1: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&ceu0_1>;
+ hsync-active = <1>;
+ vsync-active = <0>; /* Who came up with an
+ inverter here ?... */
+ data-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
+ camera@1a {
+ compatible = "sony,imx074";
+ reg = <0x1a>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
+ clocks = <&mclk 0>;
+ clock-names = "sysclk"; /* Assuming this is the
+ name in the datasheet */
+ port {
+ imx074_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&csi2_1>;
+ };
+ };
+ };
+ };
+
+ csi2: csi2@ffc90000 {
+ compatible = "renesas,sh-mobile-csi2";
+ reg = <0xffc90000 0x1000>;
+ interrupts = <0x17a0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
+ reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
+ PHY_M has port address 0,
+ is unused. */
+ csi2_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <2 1>;
+ remote-endpoint = <&imx074_1>;
+ };
+ };
+ port@2 {
+ reg = <2>; /* port 2: link to the CEU */
+
+ csi2_2: endpoint {
+ remote-endpoint = <&ceu0_0>;
+ };
+ };
+ };
+
+...
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/2] dt-bindings: media: Convert video-interfaces.txt to schemas
From: Rob Herring @ 2020-12-10 21:16 UTC (permalink / raw)
To: Guennadi Liakhovetski, Sakari Ailus, Maxime Ripard,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart,
Guennadi Liakhovetski
Cc: devicetree, linux-kernel, linux-media
In-Reply-To: <20201210211625.3070388-1-robh@kernel.org>
This series converts video-interfaces.txt to DT schema which in turn is
based on converting the graph binding to a schema. All the media users
are converted to use the graph and video-interfaces schemas.
Based on media tree commit 7ea4d2329330. This is dependent on dt-schema
changes not yet committed[1]. Please review those too.
Rob
[1] https://github.com/devicetree-org/dt-schema/tree/of-graph
Rob Herring (2):
media: dt-bindings: Convert video-interfaces.txt properties to schemas
dt-bindings: media: Use graph and video-interfaces schemas
.../media/allwinner,sun4i-a10-csi.yaml | 11 +-
.../media/allwinner,sun6i-a31-csi.yaml | 12 +-
.../bindings/media/i2c/adv7180.yaml | 36 +-
.../bindings/media/i2c/adv7604.yaml | 37 +-
.../bindings/media/i2c/aptina,mt9v111.yaml | 4 +-
.../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 +-
.../devicetree/bindings/media/i2c/imx219.yaml | 21 +-
.../bindings/media/i2c/maxim,max9286.yaml | 101 +--
.../bindings/media/i2c/mipi-ccs.yaml | 15 +-
.../devicetree/bindings/media/i2c/ov5647.yaml | 20 +-
.../devicetree/bindings/media/i2c/ov8856.yaml | 21 +-
.../bindings/media/i2c/ovti,ov02a10.yaml | 30 +-
.../bindings/media/i2c/ovti,ov2680.yaml | 6 +-
.../bindings/media/i2c/ovti,ov772x.yaml | 9 +-
.../bindings/media/i2c/sony,imx214.yaml | 25 +-
.../bindings/media/i2c/sony,imx274.yaml | 3 +-
.../bindings/media/marvell,mmp2-ccic.yaml | 15 +-
.../bindings/media/nxp,imx7-csi.yaml | 5 +-
.../bindings/media/nxp,imx7-mipi-csi2.yaml | 32 +-
.../bindings/media/renesas,ceu.yaml | 17 +-
.../bindings/media/renesas,csi2.yaml | 54 +-
.../bindings/media/renesas,vin.yaml | 113 +---
.../bindings/media/rockchip-isp1.yaml | 40 +-
.../bindings/media/st,stm32-dcmi.yaml | 18 +-
.../devicetree/bindings/media/ti,cal.yaml | 55 +-
.../media/video-interface-devices.yaml | 406 +++++++++++
.../bindings/media/video-interfaces.txt | 640 +-----------------
.../bindings/media/video-interfaces.yaml | 346 ++++++++++
.../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +-
29 files changed, 922 insertions(+), 1239 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/video-interface-devices.yaml
create mode 100644 Documentation/devicetree/bindings/media/video-interfaces.yaml
--
2.25.1
^ permalink raw reply
* Re: [PATCH 4/4] dma-heap: Devicetree binding for chunk heap
From: John Stultz @ 2020-12-10 22:40 UTC (permalink / raw)
To: Minchan Kim
Cc: Hyesoo Yu, Andrew Morton, LKML, linux-mm, Matthew Wilcox, david,
iamjoonsoo.kim, vbabka, Suren Baghdasaryan, KyongHo Cho,
John Dias, Hridya Valsaraju, Sumit Semwal, Brian Starkey,
linux-media,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Christian Koenig,
moderated list:DMA BUFFER SHARING FRAMEWORK, Kunihiko Hayashi
In-Reply-To: <X9JHjPTdxv6Z7lCW@google.com>
On Thu, Dec 10, 2020 at 8:06 AM Minchan Kim <minchan@kernel.org> wrote:
> On Thu, Dec 10, 2020 at 12:15:15AM -0800, John Stultz wrote:
> > Well, while I agree that conceptually the dmabuf heaps allow for
> > allocations for multi-device pipelines, and thus are not tied to
> > specific devices. I do think that the memory types exposed are likely
> > to have specific devices/drivers in the pipeline that it matters most
> > to. So I don't see a big issue with the in-kernel driver registering a
> > specific CMA region as a dmabuf heap.
>
> Then, I am worry about that we spread out dma_heap_add_cma to too many
> drivers since kernel doesn't how userspace will use it.
> For example, system 1 could have device A-B-C pipeline so they added
> it A driver. After that, system 2 could have device B-C-D pipeline
> so they add dma_heap_add_cma into B device.
I'm not sure I see this as a major issue? If the drivers add it based
on the dt memory reference, those will be configured to not add
duplicate heaps (and even so the heap driver can also ensure we don't
try to add a heap twice).
> > Yea, an un-upstreamable dummy driver is maybe what it devolves to in
> > the worst case. But I suspect it would be cleaner for a display or ISP
> > driver that benefits most from the heap type to add the reserved
> > memory reference to their DT node, and on init for them to register
> > the region with the dmabuf heap code.
>
> As I mentioned above, it could be a display at this moment but it could
> be different driver next time. If I miss your point, let me know.
>
I guess I just don't see potentially having the registration calls
added to multiple drivers as a big problem.
Ideally, yes, I'd probably rather see a DT node that would allow the
heap driver to register specified regions, but that's been NACKed
multiple times. Given that, having hooks in device drivers to export
the region seems to me like the next best approach, as it avoids DT
ABI ( if ends up its a bad approach, its not something we have to
keep).
The bigger problem right now is not that there are too many places the
registration call would be made from, but that there aren't upstream
drivers which I'm aware of where it would currently make sense to add
specific dma_heap_add_cma() registration hooks to. We need an
upstream user of Kunihiko Hayashi's patch.
thanks
-john
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox