[PATCH] hantro: Format IOCTLs compliance fixes
Clear the reserved fields. Fixes: fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not zeroed test VIDIOC_TRY_FMT: FAIL fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not zeroed test VIDIOC_S_FMT: FAIL Signed-off-by: Ricardo Ribalda --- drivers/staging/media/hantro/hantro_v4l2.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c index b668a82d40ad..9b384fbffc93 100644 --- a/drivers/staging/media/hantro/hantro_v4l2.c +++ b/drivers/staging/media/hantro/hantro_v4l2.c @@ -239,6 +239,7 @@ static int hantro_try_fmt(const struct hantro_ctx *ctx, const struct hantro_fmt *fmt, *vpu_fmt; bool capture = V4L2_TYPE_IS_CAPTURE(type); bool coded; + int i; coded = capture == ctx->is_encoder; @@ -293,6 +294,10 @@ static int hantro_try_fmt(const struct hantro_ctx *ctx, pix_mp->width * pix_mp->height * fmt->max_depth; } + for (i = 0; i < pix_mp->num_planes; i++) + memset(pix_mp->plane_fmt[i].reserved, 0, + sizeof(pix_mp->plane_fmt[i].reserved)); + return 0; } -- 2.30.0.284.gd98b1dd5eaa7-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hantro: Format IOCTLs compliance fixes
Hi Ricardo, On Mon, 2021-01-11 at 12:35 +0100, Ricardo Ribalda wrote: > Clear the reserved fields. > > Fixes: > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not zeroed > test VIDIOC_TRY_FMT: FAIL > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not zeroed > test VIDIOC_S_FMT: FAIL > > Signed-off-by: Ricardo Ribalda > --- > drivers/staging/media/hantro/hantro_v4l2.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c > b/drivers/staging/media/hantro/hantro_v4l2.c > index b668a82d40ad..9b384fbffc93 100644 > --- a/drivers/staging/media/hantro/hantro_v4l2.c > +++ b/drivers/staging/media/hantro/hantro_v4l2.c > @@ -239,6 +239,7 @@ static int hantro_try_fmt(const struct hantro_ctx *ctx, > const struct hantro_fmt *fmt, *vpu_fmt; > bool capture = V4L2_TYPE_IS_CAPTURE(type); > bool coded; > + int i; > > coded = capture == ctx->is_encoder; > > @@ -293,6 +294,10 @@ static int hantro_try_fmt(const struct hantro_ctx *ctx, > pix_mp->width * pix_mp->height * fmt->max_depth; > } > > + for (i = 0; i < pix_mp->num_planes; i++) > + memset(pix_mp->plane_fmt[i].reserved, 0, > + sizeof(pix_mp->plane_fmt[i].reserved)); > + This looks like something that should be handled at the core, probably in drivers/media/v4l2-core/v4l2-ioctl.c::v4l_try_fmt(). Thanks, Ezequiel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hantro: Format IOCTLs compliance fixes
Hi Ezequiel On Mon, Jan 11, 2021 at 12:48 PM Ezequiel Garcia wrote: > > Hi Ricardo, > > On Mon, 2021-01-11 at 12:35 +0100, Ricardo Ribalda wrote: > > Clear the reserved fields. > > > > Fixes: > > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not zeroed > > test VIDIOC_TRY_FMT: FAIL > > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not zeroed > > test VIDIOC_S_FMT: FAIL > > > > Signed-off-by: Ricardo Ribalda > > --- > > drivers/staging/media/hantro/hantro_v4l2.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c > > b/drivers/staging/media/hantro/hantro_v4l2.c > > index b668a82d40ad..9b384fbffc93 100644 > > --- a/drivers/staging/media/hantro/hantro_v4l2.c > > +++ b/drivers/staging/media/hantro/hantro_v4l2.c > > @@ -239,6 +239,7 @@ static int hantro_try_fmt(const struct hantro_ctx *ctx, > > const struct hantro_fmt *fmt, *vpu_fmt; > > bool capture = V4L2_TYPE_IS_CAPTURE(type); > > bool coded; > > + int i; > > > > coded = capture == ctx->is_encoder; > > > > @@ -293,6 +294,10 @@ static int hantro_try_fmt(const struct hantro_ctx *ctx, > > pix_mp->width * pix_mp->height * fmt->max_depth; > > } > > > > + for (i = 0; i < pix_mp->num_planes; i++) > > + memset(pix_mp->plane_fmt[i].reserved, 0, > > + sizeof(pix_mp->plane_fmt[i].reserved)); > > + > > This looks like something that should be handled at the core, > probably in drivers/media/v4l2-core/v4l2-ioctl.c::v4l_try_fmt(). The core does clear the reserved field from v4l2_pix_format_mplane, but not the reserved field for every plane. I can try to add it to the core as well. At least these drivers have code duplication: git grep reserved | grep memset | grep plane_fmt drivers/media/pci/intel/ipu3/ipu3-cio2.c: memset(mpix->plane_fmt[0].reserved, 0, drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: memset(pix_mp->plane_fmt[i].reserved, 0, drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: memset(&(pix_fmt_mp->plane_fmt[i].reserved[0]), 0x0, drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c: memset(&(pix_fmt_mp->plane_fmt[i].reserved[0]), 0x0, drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c: memset(&(pix->plane_fmt[i].reserved[0]), 0x0, drivers/media/platform/rcar_fdp1.c: memset(pix->plane_fmt[i].reserved, 0, drivers/media/platform/rcar_fdp1.c: memset(pix->plane_fmt[2].reserved, 0, drivers/media/platform/rcar_jpu.c: memset(pix->plane_fmt[0].reserved, 0, drivers/media/platform/rcar_jpu.c: memset(pix->plane_fmt[i].reserved, 0, drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c: memset(pix->plane_fmt[i].reserved, 0, drivers/media/platform/ti-vpe/vpe.c: memset(plane_fmt->reserved, 0, sizeof(plane_fmt->reserved)); drivers/media/test-drivers/vicodec/vicodec-core.c: memset(pix_mp->plane_fmt[0].reserved, 0, drivers/staging/media/hantro/hantro_v4l2.c: memset(pix_mp->plane_fmt[i].reserved, 0, drivers/staging/media/ipu3/ipu3-v4l2.c: memset(pixm->plane_fmt[0].reserved, 0, > > Thanks, > Ezequiel > -- Ricardo Ribalda ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hantro: Format IOCTLs compliance fixes
Hi Ezequiel On Mon, Jan 11, 2021 at 12:55 PM Ricardo Ribalda wrote: > > Hi Ezequiel > > On Mon, Jan 11, 2021 at 12:48 PM Ezequiel Garcia > wrote: > > > > Hi Ricardo, > > > > On Mon, 2021-01-11 at 12:35 +0100, Ricardo Ribalda wrote: > > > Clear the reserved fields. > > > > > > Fixes: > > > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not > > > zeroed > > > test VIDIOC_TRY_FMT: FAIL > > > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not > > > zeroed > > > test VIDIOC_S_FMT: FAIL > > > > > > Signed-off-by: Ricardo Ribalda > > > --- > > > drivers/staging/media/hantro/hantro_v4l2.c | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c > > > b/drivers/staging/media/hantro/hantro_v4l2.c > > > index b668a82d40ad..9b384fbffc93 100644 > > > --- a/drivers/staging/media/hantro/hantro_v4l2.c > > > +++ b/drivers/staging/media/hantro/hantro_v4l2.c > > > @@ -239,6 +239,7 @@ static int hantro_try_fmt(const struct hantro_ctx > > > *ctx, > > > const struct hantro_fmt *fmt, *vpu_fmt; > > > bool capture = V4L2_TYPE_IS_CAPTURE(type); > > > bool coded; > > > + int i; > > > > > > coded = capture == ctx->is_encoder; > > > > > > @@ -293,6 +294,10 @@ static int hantro_try_fmt(const struct hantro_ctx > > > *ctx, > > > pix_mp->width * pix_mp->height * fmt->max_depth; > > > } > > > > > > + for (i = 0; i < pix_mp->num_planes; i++) > > > + memset(pix_mp->plane_fmt[i].reserved, 0, > > > + sizeof(pix_mp->plane_fmt[i].reserved)); > > > + > > > > This looks like something that should be handled at the core, > > probably in drivers/media/v4l2-core/v4l2-ioctl.c::v4l_try_fmt(). > > The core does clear the reserved field from v4l2_pix_format_mplane, My bad, It is also clearing the per plane reserved field. I was testing in an old kernel. The grep it is still valid though. We can remove all the memsets in the drivers. > but not the reserved field for every plane. I can try to add it to the > core as well. At least these drivers have code duplication: > > git grep reserved | grep memset | grep plane_fmt > drivers/media/pci/intel/ipu3/ipu3-cio2.c: > memset(mpix->plane_fmt[0].reserved, 0, > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: > memset(pix_mp->plane_fmt[i].reserved, 0, > drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: > memset(&(pix_fmt_mp->plane_fmt[i].reserved[0]), 0x0, > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c: > memset(&(pix_fmt_mp->plane_fmt[i].reserved[0]), 0x0, > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c: > memset(&(pix->plane_fmt[i].reserved[0]), 0x0, > drivers/media/platform/rcar_fdp1.c: > memset(pix->plane_fmt[i].reserved, 0, > drivers/media/platform/rcar_fdp1.c: > memset(pix->plane_fmt[2].reserved, 0, > drivers/media/platform/rcar_jpu.c: > memset(pix->plane_fmt[0].reserved, 0, > drivers/media/platform/rcar_jpu.c: > memset(pix->plane_fmt[i].reserved, 0, > drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c: > memset(pix->plane_fmt[i].reserved, 0, > drivers/media/platform/ti-vpe/vpe.c: > memset(plane_fmt->reserved, 0, sizeof(plane_fmt->reserved)); > drivers/media/test-drivers/vicodec/vicodec-core.c: > memset(pix_mp->plane_fmt[0].reserved, 0, > drivers/staging/media/hantro/hantro_v4l2.c: > memset(pix_mp->plane_fmt[i].reserved, 0, > drivers/staging/media/ipu3/ipu3-v4l2.c: memset(pixm->plane_fmt[0].reserved, 0, > > > > > Thanks, > > Ezequiel > > > > > -- > Ricardo Ribalda -- Ricardo Ribalda ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hantro: Format IOCTLs compliance fixes
On Mon, 2021-01-11 at 13:22 +0100, Ricardo Ribalda wrote: > Hi Ezequiel > > On Mon, Jan 11, 2021 at 12:55 PM Ricardo Ribalda wrote: > > > > Hi Ezequiel > > > > On Mon, Jan 11, 2021 at 12:48 PM Ezequiel Garcia > > wrote: > > > > > > Hi Ricardo, > > > > > > On Mon, 2021-01-11 at 12:35 +0100, Ricardo Ribalda wrote: > > > > Clear the reserved fields. > > > > > > > > Fixes: > > > > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not > > > > zeroed > > > > test VIDIOC_TRY_FMT: FAIL > > > > fail: v4l2-test-formats.cpp(482): pix_mp.plane_fmt[0].reserved not > > > > zeroed > > > > test VIDIOC_S_FMT: FAIL > > > > > > > > Signed-off-by: Ricardo Ribalda > > > > --- > > > > drivers/staging/media/hantro/hantro_v4l2.c | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c > > > > b/drivers/staging/media/hantro/hantro_v4l2.c > > > > index b668a82d40ad..9b384fbffc93 100644 > > > > --- a/drivers/staging/media/hantro/hantro_v4l2.c > > > > +++ b/drivers/staging/media/hantro/hantro_v4l2.c > > > > @@ -239,6 +239,7 @@ static int hantro_try_fmt(const struct hantro_ctx > > > > *ctx, > > > > const struct hantro_fmt *fmt, *vpu_fmt; > > > > bool capture = V4L2_TYPE_IS_CAPTURE(type); > > > > bool coded; > > > > + int i; > > > > > > > > coded = capture == ctx->is_encoder; > > > > > > > > @@ -293,6 +294,10 @@ static int hantro_try_fmt(const struct hantro_ctx > > > > *ctx, > > > > pix_mp->width * pix_mp->height * fmt->max_depth; > > > > } > > > > > > > > + for (i = 0; i < pix_mp->num_planes; i++) > > > > + memset(pix_mp->plane_fmt[i].reserved, 0, > > > > + sizeof(pix_mp->plane_fmt[i].reserved)); > > > > + > > > > > > This looks like something that should be handled at the core, > > > probably in drivers/media/v4l2-core/v4l2-ioctl.c::v4l_try_fmt(). > > > > The core does clear the reserved field from v4l2_pix_format_mplane, > > My bad, It is also clearing the per plane reserved field. I was > testing in an old kernel. > OK, cool. > The grep it is still valid though. We can remove all the memsets in the > drivers. > That would be very nice indeed. Thanks, Ezequiel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] A trio of vchiq bulk transfer fixes
On Tue, 2021-01-05 at 16:20 +, Phil Elwell wrote: > The recent batch of vchiq improvements broke bulk transfers in two ways: > > 1. The userdata associated with a transfer was lost in the case that a > non-blocking mode was used. > > 2. The 64-bit ioctl compatibility shim for a bulk transfer used the > wrong ioctl command. > > This patch set fixes both of those bugs, and adds a security-related > note to the TODO file. > > Changes in v2: > - Expand the commit message on patch 1 to clarify the impact of the > bug, and add Tested-by. > - Add commit 3 with an additional TODO item. > - Change the name of the patch set to be numerically accurate. > > Phil Elwell (3): > staging: vchiq: Fix bulk userdata handling > staging: vchiq: Fix bulk transfers on 64-bit builds > staging: vc04_services: Add a note to the TODO > > drivers/staging/vc04_services/interface/TODO| 4 > .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 -- > 2 files changed, 8 insertions(+), 2 deletions(-) > Reviewed-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller
Hi Samuel,
On Sat 09 Jan 21, 16:24, Samuel Holland wrote:
> On 12/31/20 8:29 AM, Paul Kocialkowski wrote:
> > The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> > found on Allwinner SoCs such as the A31 and V3/V3s.
> >
> > It is a standalone block, connected to the CSI controller on one side
> > and to the MIPI D-PHY block on the other. It has a dedicated address
> > space, interrupt line and clock.
> >
> > It is represented as a V4L2 subdev to the CSI controller and takes a
> > MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> > media controller API.
> >
> > Only 8-bit and 10-bit Bayer formats are currently supported.
> > While up to 4 internal channels to the CSI controller exist, only one
> > is currently supported by this implementation.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/media/platform/sunxi/Kconfig | 1 +
> > drivers/media/platform/sunxi/Makefile | 1 +
> > .../platform/sunxi/sun6i-mipi-csi2/Kconfig| 12 +
> > .../platform/sunxi/sun6i-mipi-csi2/Makefile | 4 +
> > .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c | 590 ++
> > .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h | 117
> > 6 files changed, 725 insertions(+)
> > create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> > create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> > create mode 100644
> > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> > create mode 100644
> > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
> >
> > diff --git a/drivers/media/platform/sunxi/Kconfig
> > b/drivers/media/platform/sunxi/Kconfig
> > index 7151cc249afa..9684e07454ad 100644
> > --- a/drivers/media/platform/sunxi/Kconfig
> > +++ b/drivers/media/platform/sunxi/Kconfig
> > @@ -2,3 +2,4 @@
> >
> > source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
> > source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> > +source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
> > diff --git a/drivers/media/platform/sunxi/Makefile
> > b/drivers/media/platform/sunxi/Makefile
> > index fc537c9f5ca9..887a7cae8fca 100644
> > --- a/drivers/media/platform/sunxi/Makefile
> > +++ b/drivers/media/platform/sunxi/Makefile
> > @@ -2,5 +2,6 @@
> >
> > obj-y += sun4i-csi/
> > obj-y += sun6i-csi/
> > +obj-y += sun6i-mipi-csi2/
> > obj-y += sun8i-di/
> > obj-y += sun8i-rotate/
> > diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> > b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> > new file mode 100644
> > index ..47f1bb0779a8
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> > @@ -0,0 +1,12 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +config VIDEO_SUN6I_MIPI_CSI2
> > + tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
> > + depends on ARCH_SUNXI || COMPILE_TEST
> > + depends on PM && COMMON_CLK && VIDEO_V4L2
> > + select REGMAP_MMIO
> > + select PHY_SUN6I_MIPI_DPHY
> > + select MEDIA_CONTROLLER
> > + select VIDEO_V4L2_SUBDEV_API
> > + select V4L2_FWNODE
> > + help
> > + Support for the Allwinner A31 MIPI CSI-2 Controller.
> > diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> > b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> > new file mode 100644
> > index ..14e4e03818b5
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
> > +
> > +obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
> > diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> > b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> > new file mode 100644
> > index ..87307beda4cf
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> > @@ -0,0 +1,590 @@
> [...]
> > +/* Base Driver */
> > +
> > +static int sun6i_mipi_csi2_suspend(struct device *dev)
> > +{
> > + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> > +
> > + clk_disable_unprepare(cdev->clk_mod);
> > + clk_disable_unprepare(cdev->clk_bus);
> > + reset_control_assert(cdev->reset);
> > +
> > + return 0;
> > +}
> > +
> > +static int sun6i_mipi_csi2_resume(struct device *dev)
> > +{
> > + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + ret = reset_control_deassert(cdev->reset);
> > + if (ret) {
> > + dev_err(cdev->dev, "failed to deassert reset\n");
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(cdev->clk_bus);
> > + if (ret) {
> > + dev_err(cdev->dev, "failed to enable bus clock\n");
> > + goto error_reset;
> > + }
> > +
> > + ret = clk_prepare_enable(cdev->clk_mod);
> > + if (ret) {
> > +
Re: [linux-sunxi] [PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller
Salut Paul,
Just a minor comment about the v4l2 async API.
On Thu, 31 Dec 2020 at 11:30, Paul Kocialkowski
wrote:
>
> The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> found on Allwinner SoCs such as the A31 and V3/V3s.
>
> It is a standalone block, connected to the CSI controller on one side
> and to the MIPI D-PHY block on the other. It has a dedicated address
> space, interrupt line and clock.
>
> It is represented as a V4L2 subdev to the CSI controller and takes a
> MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> media controller API.
>
> Only 8-bit and 10-bit Bayer formats are currently supported.
> While up to 4 internal channels to the CSI controller exist, only one
> is currently supported by this implementation.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/media/platform/sunxi/Kconfig | 1 +
> drivers/media/platform/sunxi/Makefile | 1 +
> .../platform/sunxi/sun6i-mipi-csi2/Kconfig| 12 +
> .../platform/sunxi/sun6i-mipi-csi2/Makefile | 4 +
> .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c | 590 ++
> .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h | 117
> 6 files changed, 725 insertions(+)
> create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> create mode 100644
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> create mode 100644
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
>
[..]
> +static int sun6i_mipi_csi2_v4l2_setup(struct sun6i_mipi_csi2_dev *cdev)
> +{
> + struct sun6i_mipi_csi2_video *video = &cdev->video;
> + struct v4l2_subdev *subdev = &video->subdev;
> + struct v4l2_async_notifier *notifier = &video->notifier;
> + struct fwnode_handle *handle;
> + struct v4l2_fwnode_endpoint *endpoint;
> + struct v4l2_async_subdev *subdev_async;
> + int ret;
> +
> + /* Subdev */
> +
> + v4l2_subdev_init(subdev, &sun6i_mipi_csi2_subdev_ops);
> + subdev->dev = cdev->dev;
> + subdev->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> + strscpy(subdev->name, MODULE_NAME, sizeof(subdev->name));
> + v4l2_set_subdevdata(subdev, cdev);
> +
> + /* Entity */
> +
> + subdev->entity.function = MEDIA_ENT_F_VID_IF_BRIDGE;
> + subdev->entity.ops = &sun6i_mipi_csi2_entity_ops;
> +
> + /* Pads */
> +
> + video->pads[0].flags = MEDIA_PAD_FL_SINK;
> + video->pads[1].flags = MEDIA_PAD_FL_SOURCE;
> +
> + ret = media_entity_pads_init(&subdev->entity, 2, video->pads);
> + if (ret)
> + return ret;
> +
> + /* Endpoint */
> +
> + handle = fwnode_graph_get_endpoint_by_id(dev_fwnode(cdev->dev), 0, 0,
> +FWNODE_GRAPH_ENDPOINT_NEXT);
> + if (!handle) {
> + ret = -ENODEV;
> + goto error_media_entity;
> + }
> +
> + endpoint = &video->endpoint;
> + endpoint->bus_type = V4L2_MBUS_CSI2_DPHY;
> +
> + ret = v4l2_fwnode_endpoint_parse(handle, endpoint);
> + fwnode_handle_put(handle);
I think the _put should be...
> + if (ret)
> + goto error_media_entity;
> +
> + /* Notifier */
> +
> + v4l2_async_notifier_init(notifier);
> +
> + subdev_async = &video->subdev_async;
> + ret = v4l2_async_notifier_add_fwnode_remote_subdev(notifier, handle,
> + subdev_async);
... here. See for instance drivers/media/platform/rcar-vin/rcar-csi2.c.
(Unless I've missed something, of course).
Cheers,
Ezequiel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-next] BUILD SUCCESS 3dba1da360da5071d013fd0fb8839124104390fa
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-next branch HEAD: 3dba1da360da5071d013fd0fb8839124104390fa Merge 5.11-rc3 into staging-next elapsed time: 722m configs tested: 105 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig nios2allyesconfig powerpc mpc8560_ads_defconfig shdreamcast_defconfig powerpc makalu_defconfig powerpc allnoconfig powerpc maple_defconfig powerpc powernv_defconfig armshmobile_defconfig mips pic32mzda_defconfig mips bmips_be_defconfig mips decstation_64_defconfig h8300 edosk2674_defconfig um i386_defconfig archsdk_defconfig powerpc tqm8540_defconfig mips maltaaprp_defconfig sh polaris_defconfig arc haps_hs_smp_defconfig arm mxs_defconfig pariscgeneric-32bit_defconfig xtensa common_defconfig mips fuloong2e_defconfig arm h3600_defconfig sparc64 alldefconfig mipsvocore2_defconfig powerpc mpc836x_mds_defconfig armvt8500_v6_v7_defconfig sh se7705_defconfig mips malta_kvm_defconfig powerpc acadia_defconfig powerpc mpc85xx_cds_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig cskydefconfig alpha defconfig alphaallyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig i386 randconfig-a002-20210111 i386 randconfig-a005-20210111 i386 randconfig-a006-20210111 i386 randconfig-a001-20210111 i386 randconfig-a003-20210111 i386 randconfig-a004-20210111 i386 randconfig-a012-20210111 i386 randconfig-a011-20210111 i386 randconfig-a016-20210111 i386 randconfig-a015-20210111 i386 randconfig-a013-20210111 i386 randconfig-a014-20210111 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a004-20210110 x86_64 randconfig-a006-20210110 x86_64 randconfig-a001-20210110 x86_64 randconfig-a003-20210110 x86_64 randconfig-a005-20210110 x86_64 randconfig-a002-20210110 x86_64 randconfig-a012-20210111 x86_64
Re: [PATCH v6 00/11] Raspberry Pi PoE HAT fan support
On Fri, 2020-12-11 at 17:47 +0100, Nicolas Saenz Julienne wrote: > The aim of this series is to add support to the fan found on RPi's PoE > HAT. Some commentary on the design can be found below. But the imporant > part to the people CC'd here not involved with PWM is that, in order to > achieve this properly, we also have to fix the firmware interface the > driver uses to communicate with the PWM bus (and many other low level > functions). Specifically, we have to make sure the firmware interface > isn't unbound while consumers are still up. So, patch #1 & #2 introduce > reference counting in the firwmware interface driver and patches #3 to > #8 update all firmware users. Patches #9 to #11 introduce the new PWM > driver. > > I sent everything as a single series as the final version of the PWM > drivers depends on the firwmare fixes, but I'll be happy to split this > into two separate series if you think it's better. > > --- Original cover letter below --- > > This series aims at adding support to RPi's official PoE HAT fan[1]. > > The HW setup is the following: > > > Raspberry Pi | PoE HAT| > arm core -> Mailbox -> RPi co-processor -> I2C -> Atmel MCU -> PWM -> FAN > > The arm cores have only access to the mailbox interface, as i2c0, even if > physically accessible, is to be used solely by the co-processor > (VideoCore 4/6). > > This series implements a PWM bus, and has pwm-fan sitting on top of it as per > this discussion: https://lkml.org/lkml/2018/9/2/486. Although this design has > a > series of shortcomings: > > - It depends on a DT binding: it's not flexible if a new hat shows up with new > functionality, we're not 100% sure we'll be able to expand it without > breaking backwards compatibility. But without it we can't make use of DT > thermal-zones, which IMO is overkill. > > - We're using pwm-fan, writing a hwmon driver would, again, give us more > flexibility, but it's not really needed at the moment. > > I personally think that it's not worth the effort, it's unlikely we'll get > things right in advance. And ultimately, if the RPi people come up with > something new, we can always write a new driver/bindings from scratch (as in > not reusing previous code). > > That said, I'm more than happy to change things if there is a consensus that > another design will do the trick. > > [1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/ > > --- I'd say at this point the series is pretty clean and, AFAIK, there aren't any objections. I'm not so sure who should take it, given that it covers numerous subsystems. Any suggestions on how to handle it? Regards, Nicolas > Changes since v5: > - Small cleanups > - Add extra code comments > > Changes since v4: > - Cleanup devm calls > - Rename compatible string so it's unique to the PoE HAT > > Changes since v3: > - Split first patch, #1 introduces refcount, then #2 the devm function > - Fix touchscreen function > - Use kref > > Changes since v2: > - Introduce devm_rpi_firmware_get() > - Small cleanups in PWM driver > > Changes since v1: > - Address PWM driver changes > - Fix binding, now with 2 cells > > Nicolas Saenz Julienne (11): > firmware: raspberrypi: Keep count of all consumers > firmware: raspberrypi: Introduce devm_rpi_firmware_get() > clk: bcm: rpi: Release firmware handle on unbind > gpio: raspberrypi-exp: Release firmware handle on unbind > reset: raspberrypi: Release firmware handle on unbind > soc: bcm: raspberrypi-power: Release firmware handle on unbind > staging: vchiq: Release firmware handle on unbind > input: raspberrypi-ts: Release firmware handle when not needed > dt-bindings: pwm: Add binding for RPi firmware PWM bus > DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support > pwm: Add Raspberry Pi Firmware based PWM bus > > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 ++ > arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 + > drivers/clk/bcm/clk-raspberrypi.c | 2 +- > drivers/firmware/raspberrypi.c| 69 +- > drivers/gpio/gpio-raspberrypi-exp.c | 2 +- > drivers/input/touchscreen/raspberrypi-ts.c| 2 +- > drivers/pwm/Kconfig | 9 + > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-raspberrypi-poe.c | 216 ++ > drivers/reset/reset-raspberrypi.c | 2 +- > drivers/soc/bcm/raspberrypi-power.c | 2 +- > .../interface/vchiq_arm/vchiq_arm.c | 2 +- > .../pwm/raspberrypi,firmware-poe-pwm.h| 13 ++ > include/soc/bcm2835/raspberrypi-firmware.h| 10 + > 14 files changed, 395 insertions(+), 9 deletions(-) > create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c > create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h > signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 08/15] dt-bindings: media: Add A31 MIPI CSI-2 bindings documentation
On Thu, 31 Dec 2020 15:29:41 +0100, Paul Kocialkowski wrote: > This introduces YAML bindings documentation for the A31 MIPI CSI-2 > controller. > > Signed-off-by: Paul Kocialkowski > --- > .../media/allwinner,sun6i-a31-mipi-csi2.yaml | 149 ++ > 1 file changed, 149 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
