[PATCH v5 04/11] media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Sun Jul 2 15:01:38 PDT 2023
Hi Sakari,
On Sun, Jul 02, 2023 at 09:56:11PM +0000, Sakari Ailus wrote:
> On Mon, Jul 03, 2023 at 12:47:11AM +0300, Laurent Pinchart wrote:
> > On Mon, Jul 03, 2023 at 12:45:07AM +0300, Laurent Pinchart wrote:
> > > On Sun, Jul 02, 2023 at 06:18:21PM +0000, Sakari Ailus wrote:
> > > > On Sun, Jul 02, 2023 at 06:23:56PM +0300, Laurent Pinchart wrote:
> > > > > On Fri, Feb 25, 2022 at 11:29:18AM +0200, Sakari Ailus wrote:
> > > > > > On Tue, Feb 08, 2022 at 04:50:20PM +0100, Jean-Michel Hautbois wrote:
> > > > > > > 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 at raspberrypi.com>
> > > > > > > Signed-off-by: Naushir Patuck <naush at raspberrypi.com>
> > > > > > > Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois at ideasonboard.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
> > > > >
> > > > > [snip]
> > > > >
> > > > > > > diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam-regs.h b/drivers/media/platform/bcm2835/bcm2835-unicam-regs.h
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..b8d297076a02
> > > > > > > --- /dev/null
> > > > > > > +++ b/drivers/media/platform/bcm2835/bcm2835-unicam-regs.h
> > > > >
> > > > > [snip]
> > > > >
> > > > > > > +static int unicam_connect_of_subdevs(struct unicam_device *unicam)
> > > > > > > +{
> > > > > > > + struct v4l2_fwnode_endpoint ep = { };
> > > > > > > + struct fwnode_handle *ep_handle;
> > > > > > > + struct v4l2_async_subdev *asd;
> > > > > > > + unsigned int lane;
> > > > > > > + int ret = -EINVAL;
> > > > > > > +
> > > > > > > + if (of_property_read_u32(unicam->dev->of_node, "brcm,num-data-lanes",
> > > > > > > + &unicam->max_data_lanes) < 0) {
> > > > > >
> > > > > > As you're already using fwnode API below, you could use
> > > > > > device_property_read_u32() here.
> > > > > >
> > > > > > You can then replace of_device.h by mod_devicetable.h. Up to you.
> > > > > >
> > > > > > > + dev_err(unicam->dev, "DT property %s not set\n",
> > > > > > > + "brcm,num-data-lanes");
> > > > > > > + return -EINVAL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + /* Get the local endpoint and remote device. */
> > > > > > > + ep_handle = fwnode_graph_get_endpoint_by_id(dev_fwnode(unicam->dev),
> > > > > > > + 0, 0,
> > > > > > > + FWNODE_GRAPH_ENDPOINT_NEXT);
> > > > > > > + if (!ep_handle) {
> > > > > > > + dev_err(unicam->dev, "No endpoint\n");
> > > > > > > + return -ENODEV;
> > > > > > > + }
> > > > > > > +
> > > > > > > + /* Parse the local endpoint and validate its configuration. */
> > > > > > > + if (v4l2_fwnode_endpoint_alloc_parse(ep_handle, &ep)) {
> > > > > >
> > > > > > As you don't need link-frequencies property parsing, you should use
> > > > > > v4l2_fwnode_endpoint_parse(). That avoids having to call
> > > > > > v4l2_fwnode_endpoint_free().
> > > > > >
> > > > > > > + dev_err(unicam->dev, "could not parse endpoint\n");
> > > > > > > + goto cleanup_exit;
> > > > > > > + }
> > > > > > > +
> > > > > > > + dev_dbg(unicam->dev, "parsed local endpoint, bus_type %u\n",
> > > > > > > + ep.bus_type);
> > > > > > > +
> > > > > > > + unicam->bus_type = ep.bus_type;
> > > > > > > +
> > > > > > > + switch (ep.bus_type) {
> > > > > > > + case V4L2_MBUS_CSI2_DPHY:
> > > > > > > + switch (ep.bus.mipi_csi2.num_data_lanes) {
> > > > > > > + case 1:
> > > > > > > + case 2:
> > > > > > > + case 4:
> > > > > > > + break;
> > > > > > > +
> > > > > > > + default:
> > > > > > > + dev_err(unicam->dev, "%u data lanes not supported\n",
> > > > > > > + ep.bus.mipi_csi2.num_data_lanes);
> > > > > > > + goto cleanup_exit;
> > > > > > > + }
> > > > > > > +
> > > > > > > + for (lane = 0; lane < ep.bus.mipi_csi2.num_data_lanes; lane++) {
> > > > > > > + if (ep.bus.mipi_csi2.data_lanes[lane] != lane + 1) {
> > > > > > > + dev_err(unicam->dev, "data lanes reordering not supported\n");
> > > > > > > + goto cleanup_exit;
> > > > > > > + }
> > > > > > > + }
> > > > > > > +
> > > > > > > + if (ep.bus.mipi_csi2.num_data_lanes > unicam->max_data_lanes) {
> > > > > > > + dev_err(unicam->dev, "endpoint requires %u data lanes when %u are supported\n",
> > > > > > > + ep.bus.mipi_csi2.num_data_lanes,
> > > > > > > + unicam->max_data_lanes);
> > > > > > > + }
> > > > > > > +
> > > > > > > + unicam->active_data_lanes = ep.bus.mipi_csi2.num_data_lanes;
> > > > > > > + unicam->bus_flags = ep.bus.mipi_csi2.flags;
> > > > > > > +
> > > > > > > + break;
> > > > > > > +
> > > > > > > + case V4L2_MBUS_CCP2:
> > > > > > > + if (ep.bus.mipi_csi1.clock_lane != 0 ||
> > > > > > > + ep.bus.mipi_csi1.data_lane != 1) {
> > > > > > > + dev_err(unicam->dev, "unsupported lanes configuration\n");
> > > > > >
> > > > > > If the hardware doesn't support lane remapping for CCP2, then that should
> > > > > > be reflected in DT bindings, i.e. data-lanes isn't relevant. There's no
> > > > > > need to check that here.
> > > > >
> > > > > Should the above check for CSI-2 be dropped as well then ?
> > > >
> > > > Same for CSI-2, too: if there's nothing to configure there (lane remapping)
> > > > there's no need to validate that part of the DT either.
> > >
> > > OK, I'll drop that.
> >
> > Actually, I'm wondering if it would make sense to tell the parsing
> > functions whether lane reordering is supported or not. The checks could
> > then be moved to the framework. What do you think ?
>
> I'm not sure how useful this check would be in the first place: if you have
> hardware that can reorder the lanes, the framework doesn't know what to
> check there (if anything) and otherwise there's little point in the
> entire check.
Isn't it good to tell users that something is wrong instead of accepting
the invalid configuration and let them wonder why the device isn't
working ? Users in this case would be system integrators, not end
users, but we have lots of debugging information in the kernel aimed for
them already.
--
Regards,
Laurent Pinchart
More information about the linux-arm-kernel
mailing list