| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Ygj+XYUy4zYQZMWt@pendragon.ideasonboard.com>
Date: Sun, 13 Feb 2022 14:49:33 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Stefan Wahren <stefan.wahren@...e.com>
Cc: Jean-Michel Hautbois <jeanmichel.hautbois@...asonboard.com>,
dave.stevenson@...pberrypi.com, devicetree@...r.kernel.org,
kernel-list@...pberrypi.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
linux-rpi-kernel@...ts.infradead.org, lukasz@...y.st,
mchehab@...nel.org, naush@...pberrypi.com, robh@...nel.org,
tomi.valkeinen@...asonboard.com,
bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH v5 04/11] media: bcm2835-unicam: Add support for
CCP2/CSI2 camera interface
Hi Stefan,
On Sun, Feb 13, 2022 at 12:17:25PM +0100, Stefan Wahren wrote:
> Am 08.02.22 um 16:50 schrieb Jean-Michel Hautbois:
> > Add driver for the Unicam camera receiver block on BCM283x processors.
> > It is represented as two video device nodes: unicam-image and
> > unicam-embedded which are connected to an internal subdev (named
> > unicam-subdev) in order to manage streams routing.
> >
> > Signed-off-by: Dave Stevenson <dave.stevenson@...pberrypi.com>
> > Signed-off-by: Naushir Patuck <naush@...pberrypi.com>
> > Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@...asonboard.com>
> >
> > ---
> > v4:
> > - Add the vendor prefox for DT name
> > - Use the reg-names in DT parsing
> > - Remove MAINTAINERS entry
> >
> > v3 main changes:
> > - Change code organization
> > - Remove unused variables
> > - Correct the fmt_meta functions
> > - Rewrite the start/stop streaming
> > - You can now start the image node alone, but not the metadata one
> > - The buffers are allocated per-node
> > - only the required stream is started, if the route exists and is
> > enabled
> > - Prefix the macros with UNICAM_ to not have too generic names
> > - Drop colorspace support
> > -> This is causing issues in the try-fmt v4l2-compliance test
> > test VIDIOC_G_FMT: OK
> > fail: v4l2-test-formats.cpp(363): colorspace >= 0xff
> > fail: v4l2-test-formats.cpp(465): testColorspace(!node->is_io_mc, pix.pixelformat, pix.colorspace, pix.ycbcr_enc, pix.quantization)
> > test VIDIOC_TRY_FMT: FAIL
> > fail: v4l2-test-formats.cpp(363): colorspace >= 0xff
> > fail: v4l2-test-formats.cpp(465): testColorspace(!node->is_io_mc, pix.pixelformat, pix.colorspace, pix.ycbcr_enc, pix.quantization)
> > test VIDIOC_S_FMT: FAIL
> >
> > v2: Remove the unicam_{info,debug,error} macros and use
> > dev_dbg/dev_err instead.
> > ---
> > drivers/media/platform/Kconfig | 1 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/bcm2835/Kconfig | 21 +
> > drivers/media/platform/bcm2835/Makefile | 3 +
> > .../platform/bcm2835/bcm2835-unicam-regs.h | 253 ++
> > .../media/platform/bcm2835/bcm2835-unicam.c | 2570 +++++++++++++++++
> > 6 files changed, 2850 insertions(+)
> > create mode 100644 drivers/media/platform/bcm2835/Kconfig
> > create mode 100644 drivers/media/platform/bcm2835/Makefile
> > create mode 100644 drivers/media/platform/bcm2835/bcm2835-unicam-regs.h
> > create mode 100644 drivers/media/platform/bcm2835/bcm2835-unicam.c
> >
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 9fbdba0fd1e7..033b0358fbb8 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -170,6 +170,7 @@ source "drivers/media/platform/am437x/Kconfig"
> > source "drivers/media/platform/xilinx/Kconfig"
> > source "drivers/media/platform/rcar-vin/Kconfig"
> > source "drivers/media/platform/atmel/Kconfig"
> > +source "drivers/media/platform/bcm2835/Kconfig"
> > source "drivers/media/platform/sunxi/Kconfig"
> >
> > config VIDEO_TI_CAL
> > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> > index 28eb4aadbf45..18894fc586aa 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -86,6 +86,8 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) += qcom/camss/
> >
> > obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
> >
> > +obj-$(CONFIG_VIDEO_BCM2835_UNICAM) += bcm2835/
> > +
> > obj-y += sunxi/
> >
> > obj-$(CONFIG_VIDEO_MESON_GE2D) += meson/ge2d/
> > diff --git a/drivers/media/platform/bcm2835/Kconfig b/drivers/media/platform/bcm2835/Kconfig
> > new file mode 100644
> > index 000000000000..1691541da905
> > --- /dev/null
> > +++ b/drivers/media/platform/bcm2835/Kconfig
> > @@ -0,0 +1,21 @@
> > +# Broadcom VideoCore4 V4L2 camera support
> > +
> > +config VIDEO_BCM2835_UNICAM
> > + tristate "Broadcom BCM283x/BCM271x Unicam video capture driver"
> > + depends on ARCH_BCM2835 || COMPILE_TEST
> > + depends on VIDEO_V4L2
> > + select MEDIA_CONTROLLER
> > + select VIDEO_V4L2_SUBDEV_API
> > + select V4L2_FWNODE
> > + select VIDEOBUF2_DMA_CONTIG
> > + help
> > + Say Y here to enable support for the BCM283x/BCM271x CSI-2 receiver.
> > + This is a V4L2 driver that controls the CSI-2 receiver directly,
> > + independently from the VC4 firmware.
> > + This driver is mutually exclusive with the use of bcm2835-camera. The
> > + firmware will disable all access to the peripheral from within the
> > + firmware if it finds a DT node using it, and bcm2835-camera will
> > + therefore fail to probe.
>
> would be nice to know, what is the exact condition for the firmware. The
> compatible and must its status be enabled?
>
> > +
> > + To compile this driver as a module, choose M here. The module will be
> > + called bcm2835-unicam.
[snip]
> > diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c b/drivers/media/platform/bcm2835/bcm2835-unicam.c
> > new file mode 100644
> > index 000000000000..470e691637c7
> > --- /dev/null
> > +++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
> > @@ -0,0 +1,2570 @@
[snip]
> > +static inline bool unicam_sd_pad_is_sink(u32 pad)
> > +{
> > + /* Camera RX has 1 sink pad, and N source pads */
> > + return pad == 0;
> > +}
>
> s/0/UNICAM_SD_PAD_SINK ?
Good idea.
> > +
> > +static inline bool unicam_sd_pad_is_source(u32 pad)
> > +{
> > + /* Camera RX has 1 sink pad, and N source pads */
> > + return pad != UNICAM_SD_PAD_SINK;
> > +}
> > +
> > +enum unicam_node_type {
> > + UNICAM_IMAGE_NODE,
> > + UNICAM_METADATA_NODE,
> > + UNICAM_MAX_NODES
> > +};
> > +
> > +/* -----------------------------------------------------------------------------
> > + * Structure definitions
> > + */
>
> please drop
I really favour splitting code in sections, it makes it more readable.
At the end of the day I think this is a personal decision for the
author, if no specific policy is enforced at the subsystem level.
[snip]
> > +/*
> > + * unicam_isr : ISR handler for unicam capture
> > + * @irq: irq number
> > + * @dev_id: dev_id ptr
>
> these kernel-doc doesn't match with the definition. dev seems to be the
> unicam instance?
I'd drop the comment as it doesn't really contain much useful information.
> > + *
> > + * It changes status of the captured buffer, takes next buffer from the queue
> > + * and sets its address in unicam registers
> > + */
> > +static irqreturn_t unicam_isr(int irq, void *dev)
[snip]
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists