linux_dsm_epyc7002/drivers/media/platform/vimc/vimc-debayer.c

536 lines
14 KiB
C
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-27 13:55:06 +07:00
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* vimc-debayer.c Virtual Media Controller Driver
*
* Copyright (C) 2015-2017 Helen Koike <helen.fornazier@gmail.com>
*/
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
#include <linux/moduleparam.h>
#include <linux/platform_device.h>
#include <linux/vmalloc.h>
#include <linux/v4l2-mediabus.h>
#include <media/v4l2-subdev.h>
#include "vimc-common.h"
static unsigned int deb_mean_win_size = 3;
module_param(deb_mean_win_size, uint, 0000);
MODULE_PARM_DESC(deb_mean_win_size, " the window size to calculate the mean.\n"
"NOTE: the window size needs to be an odd number, as the main pixel "
"stays in the center of the window, otherwise the next odd number "
"is considered");
enum vimc_deb_rgb_colors {
VIMC_DEB_RED = 0,
VIMC_DEB_GREEN = 1,
VIMC_DEB_BLUE = 2,
};
struct vimc_deb_pix_map {
u32 code;
enum vimc_deb_rgb_colors order[2][2];
};
struct vimc_deb_device {
struct vimc_ent_device ved;
struct v4l2_subdev sd;
struct device *dev;
/* The active format */
struct v4l2_mbus_framefmt sink_fmt;
u32 src_code;
void (*set_rgb_src)(struct vimc_deb_device *vdeb, unsigned int lin,
unsigned int col, unsigned int rgb[3]);
/* Values calculated when the stream starts */
u8 *src_frame;
const struct vimc_deb_pix_map *sink_pix_map;
unsigned int sink_bpp;
};
static const struct v4l2_mbus_framefmt sink_fmt_default = {
.width = 640,
.height = 480,
.code = MEDIA_BUS_FMT_SRGGB8_1X8,
.field = V4L2_FIELD_NONE,
.colorspace = V4L2_COLORSPACE_DEFAULT,
};
static const struct vimc_deb_pix_map vimc_deb_pix_map_list[] = {
{
.code = MEDIA_BUS_FMT_SBGGR8_1X8,
.order = { { VIMC_DEB_BLUE, VIMC_DEB_GREEN },
{ VIMC_DEB_GREEN, VIMC_DEB_RED } }
},
{
.code = MEDIA_BUS_FMT_SGBRG8_1X8,
.order = { { VIMC_DEB_GREEN, VIMC_DEB_BLUE },
{ VIMC_DEB_RED, VIMC_DEB_GREEN } }
},
{
.code = MEDIA_BUS_FMT_SGRBG8_1X8,
.order = { { VIMC_DEB_GREEN, VIMC_DEB_RED },
{ VIMC_DEB_BLUE, VIMC_DEB_GREEN } }
},
{
.code = MEDIA_BUS_FMT_SRGGB8_1X8,
.order = { { VIMC_DEB_RED, VIMC_DEB_GREEN },
{ VIMC_DEB_GREEN, VIMC_DEB_BLUE } }
},
{
.code = MEDIA_BUS_FMT_SBGGR10_1X10,
.order = { { VIMC_DEB_BLUE, VIMC_DEB_GREEN },
{ VIMC_DEB_GREEN, VIMC_DEB_RED } }
},
{
.code = MEDIA_BUS_FMT_SGBRG10_1X10,
.order = { { VIMC_DEB_GREEN, VIMC_DEB_BLUE },
{ VIMC_DEB_RED, VIMC_DEB_GREEN } }
},
{
.code = MEDIA_BUS_FMT_SGRBG10_1X10,
.order = { { VIMC_DEB_GREEN, VIMC_DEB_RED },
{ VIMC_DEB_BLUE, VIMC_DEB_GREEN } }
},
{
.code = MEDIA_BUS_FMT_SRGGB10_1X10,
.order = { { VIMC_DEB_RED, VIMC_DEB_GREEN },
{ VIMC_DEB_GREEN, VIMC_DEB_BLUE } }
},
{
.code = MEDIA_BUS_FMT_SBGGR12_1X12,
.order = { { VIMC_DEB_BLUE, VIMC_DEB_GREEN },
{ VIMC_DEB_GREEN, VIMC_DEB_RED } }
},
{
.code = MEDIA_BUS_FMT_SGBRG12_1X12,
.order = { { VIMC_DEB_GREEN, VIMC_DEB_BLUE },
{ VIMC_DEB_RED, VIMC_DEB_GREEN } }
},
{
.code = MEDIA_BUS_FMT_SGRBG12_1X12,
.order = { { VIMC_DEB_GREEN, VIMC_DEB_RED },
{ VIMC_DEB_BLUE, VIMC_DEB_GREEN } }
},
{
.code = MEDIA_BUS_FMT_SRGGB12_1X12,
.order = { { VIMC_DEB_RED, VIMC_DEB_GREEN },
{ VIMC_DEB_GREEN, VIMC_DEB_BLUE } }
},
};
static const struct vimc_deb_pix_map *vimc_deb_pix_map_by_code(u32 code)
{
unsigned int i;
for (i = 0; i < ARRAY_SIZE(vimc_deb_pix_map_list); i++)
if (vimc_deb_pix_map_list[i].code == code)
return &vimc_deb_pix_map_list[i];
return NULL;
}
static int vimc_deb_init_cfg(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg)
{
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
struct v4l2_mbus_framefmt *mf;
unsigned int i;
mf = v4l2_subdev_get_try_format(sd, cfg, 0);
*mf = sink_fmt_default;
for (i = 1; i < sd->entity.num_pads; i++) {
mf = v4l2_subdev_get_try_format(sd, cfg, i);
*mf = sink_fmt_default;
mf->code = vdeb->src_code;
}
return 0;
}
static int vimc_deb_enum_mbus_code(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code)
{
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
/* We only support one format for source pads */
if (VIMC_IS_SRC(code->pad)) {
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
if (code->index)
return -EINVAL;
code->code = vdeb->src_code;
} else {
if (code->index >= ARRAY_SIZE(vimc_deb_pix_map_list))
return -EINVAL;
code->code = vimc_deb_pix_map_list[code->index].code;
}
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
return 0;
}
static int vimc_deb_enum_frame_size(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_frame_size_enum *fse)
{
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
if (fse->index)
return -EINVAL;
if (VIMC_IS_SINK(fse->pad)) {
const struct vimc_deb_pix_map *vpix =
vimc_deb_pix_map_by_code(fse->code);
if (!vpix)
return -EINVAL;
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
} else if (fse->code != vdeb->src_code) {
return -EINVAL;
}
fse->min_width = VIMC_FRAME_MIN_WIDTH;
fse->max_width = VIMC_FRAME_MAX_WIDTH;
fse->min_height = VIMC_FRAME_MIN_HEIGHT;
fse->max_height = VIMC_FRAME_MAX_HEIGHT;
return 0;
}
static int vimc_deb_get_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *fmt)
{
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
/* Get the current sink format */
fmt->format = fmt->which == V4L2_SUBDEV_FORMAT_TRY ?
*v4l2_subdev_get_try_format(sd, cfg, 0) :
vdeb->sink_fmt;
/* Set the right code for the source pad */
if (VIMC_IS_SRC(fmt->pad))
fmt->format.code = vdeb->src_code;
return 0;
}
static void vimc_deb_adjust_sink_fmt(struct v4l2_mbus_framefmt *fmt)
{
const struct vimc_deb_pix_map *vpix;
/* Don't accept a code that is not on the debayer table */
vpix = vimc_deb_pix_map_by_code(fmt->code);
if (!vpix)
fmt->code = sink_fmt_default.code;
fmt->width = clamp_t(u32, fmt->width, VIMC_FRAME_MIN_WIDTH,
VIMC_FRAME_MAX_WIDTH) & ~1;
fmt->height = clamp_t(u32, fmt->height, VIMC_FRAME_MIN_HEIGHT,
VIMC_FRAME_MAX_HEIGHT) & ~1;
if (fmt->field == V4L2_FIELD_ANY)
fmt->field = sink_fmt_default.field;
vimc_colorimetry_clamp(fmt);
}
static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *fmt)
{
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
struct v4l2_mbus_framefmt *sink_fmt;
if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
/* Do not change the format while stream is on */
if (vdeb->src_frame)
return -EBUSY;
sink_fmt = &vdeb->sink_fmt;
} else {
sink_fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
}
/*
* Do not change the format of the source pad,
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
* it is propagated from the sink
*/
if (VIMC_IS_SRC(fmt->pad)) {
fmt->format = *sink_fmt;
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
/* TODO: Add support for other formats */
fmt->format.code = vdeb->src_code;
} else {
/* Set the new format in the sink pad */
vimc_deb_adjust_sink_fmt(&fmt->format);
dev_dbg(vdeb->dev, "%s: sink format update: "
"old:%dx%d (0x%x, %d, %d, %d, %d) "
"new:%dx%d (0x%x, %d, %d, %d, %d)\n", vdeb->sd.name,
/* old */
sink_fmt->width, sink_fmt->height, sink_fmt->code,
sink_fmt->colorspace, sink_fmt->quantization,
sink_fmt->xfer_func, sink_fmt->ycbcr_enc,
/* new */
fmt->format.width, fmt->format.height, fmt->format.code,
fmt->format.colorspace, fmt->format.quantization,
fmt->format.xfer_func, fmt->format.ycbcr_enc);
*sink_fmt = fmt->format;
}
return 0;
}
static const struct v4l2_subdev_pad_ops vimc_deb_pad_ops = {
.init_cfg = vimc_deb_init_cfg,
.enum_mbus_code = vimc_deb_enum_mbus_code,
.enum_frame_size = vimc_deb_enum_frame_size,
.get_fmt = vimc_deb_get_fmt,
.set_fmt = vimc_deb_set_fmt,
};
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
static void vimc_deb_set_rgb_mbus_fmt_rgb888_1x24(struct vimc_deb_device *vdeb,
unsigned int lin,
unsigned int col,
unsigned int rgb[3])
{
unsigned int i, index;
index = VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 3);
for (i = 0; i < 3; i++)
vdeb->src_frame[index + i] = rgb[i];
}
static int vimc_deb_s_stream(struct v4l2_subdev *sd, int enable)
{
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
if (enable) {
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
const struct vimc_pix_map *vpix;
unsigned int frame_size;
if (vdeb->src_frame)
return 0;
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
/* Calculate the frame size of the source pad */
vpix = vimc_pix_map_by_code(vdeb->src_code);
frame_size = vdeb->sink_fmt.width * vdeb->sink_fmt.height *
vpix->bpp;
/* Save the bytes per pixel of the sink */
vpix = vimc_pix_map_by_code(vdeb->sink_fmt.code);
vdeb->sink_bpp = vpix->bpp;
/* Get the corresponding pixel map from the table */
vdeb->sink_pix_map =
vimc_deb_pix_map_by_code(vdeb->sink_fmt.code);
/*
* Allocate the frame buffer. Use vmalloc to be able to
* allocate a large amount of memory
*/
vdeb->src_frame = vmalloc(frame_size);
if (!vdeb->src_frame)
return -ENOMEM;
} else {
if (!vdeb->src_frame)
return 0;
vfree(vdeb->src_frame);
vdeb->src_frame = NULL;
}
return 0;
}
static const struct v4l2_subdev_video_ops vimc_deb_video_ops = {
.s_stream = vimc_deb_s_stream,
};
static const struct v4l2_subdev_ops vimc_deb_ops = {
.pad = &vimc_deb_pad_ops,
.video = &vimc_deb_video_ops,
};
static unsigned int vimc_deb_get_val(const u8 *bytes,
const unsigned int n_bytes)
{
unsigned int i;
unsigned int acc = 0;
for (i = 0; i < n_bytes; i++)
acc = acc + (bytes[i] << (8 * i));
return acc;
}
static void vimc_deb_calc_rgb_sink(struct vimc_deb_device *vdeb,
const u8 *frame,
const unsigned int lin,
const unsigned int col,
unsigned int rgb[3])
{
unsigned int i, seek, wlin, wcol;
unsigned int n_rgb[3] = {0, 0, 0};
for (i = 0; i < 3; i++)
rgb[i] = 0;
/*
* Calculate how many we need to subtract to get to the pixel in
* the top left corner of the mean window (considering the current
* pixel as the center)
*/
seek = deb_mean_win_size / 2;
/* Sum the values of the colors in the mean window */
dev_dbg(vdeb->dev,
"deb: %s: --- Calc pixel %dx%d, window mean %d, seek %d ---\n",
vdeb->sd.name, lin, col, vdeb->sink_fmt.height, seek);
/*
* Iterate through all the lines in the mean window, start
* with zero if the pixel is outside the frame and don't pass
* the height when the pixel is in the bottom border of the
* frame
*/
for (wlin = seek > lin ? 0 : lin - seek;
wlin < lin + seek + 1 && wlin < vdeb->sink_fmt.height;
wlin++) {
/*
* Iterate through all the columns in the mean window, start
* with zero if the pixel is outside the frame and don't pass
* the width when the pixel is in the right border of the
* frame
*/
for (wcol = seek > col ? 0 : col - seek;
wcol < col + seek + 1 && wcol < vdeb->sink_fmt.width;
wcol++) {
enum vimc_deb_rgb_colors color;
unsigned int index;
/* Check which color this pixel is */
color = vdeb->sink_pix_map->order[wlin % 2][wcol % 2];
index = VIMC_FRAME_INDEX(wlin, wcol,
vdeb->sink_fmt.width,
vdeb->sink_bpp);
dev_dbg(vdeb->dev,
"deb: %s: RGB CALC: frame index %d, win pos %dx%d, color %d\n",
vdeb->sd.name, index, wlin, wcol, color);
/* Get its value */
rgb[color] = rgb[color] +
vimc_deb_get_val(&frame[index], vdeb->sink_bpp);
/* Save how many values we already added */
n_rgb[color]++;
dev_dbg(vdeb->dev, "deb: %s: RGB CALC: val %d, n %d\n",
vdeb->sd.name, rgb[color], n_rgb[color]);
}
}
/* Calculate the mean */
for (i = 0; i < 3; i++) {
dev_dbg(vdeb->dev,
"deb: %s: PRE CALC: %dx%d Color %d, val %d, n %d\n",
vdeb->sd.name, lin, col, i, rgb[i], n_rgb[i]);
if (n_rgb[i])
rgb[i] = rgb[i] / n_rgb[i];
dev_dbg(vdeb->dev,
"deb: %s: FINAL CALC: %dx%d Color %d, val %d\n",
vdeb->sd.name, lin, col, i, rgb[i]);
}
}
static void *vimc_deb_process_frame(struct vimc_ent_device *ved,
const void *sink_frame)
{
struct vimc_deb_device *vdeb = container_of(ved, struct vimc_deb_device,
ved);
unsigned int rgb[3];
unsigned int i, j;
/* If the stream in this node is not active, just return */
if (!vdeb->src_frame)
return ERR_PTR(-EINVAL);
for (i = 0; i < vdeb->sink_fmt.height; i++)
for (j = 0; j < vdeb->sink_fmt.width; j++) {
vimc_deb_calc_rgb_sink(vdeb, sink_frame, i, j, rgb);
vdeb->set_rgb_src(vdeb, i, j, rgb);
}
return vdeb->src_frame;
}
static void vimc_deb_release(struct v4l2_subdev *sd)
{
struct vimc_deb_device *vdeb =
container_of(sd, struct vimc_deb_device, sd);
media: vimc: Fix gpf in rmmod path when stream is active If vimc module is removed while streaming is in progress, sensor subdev unregister runs into general protection fault when it tries to unregister media entities. This is a common subdev problem related to releasing pads from v4l2_device_unregister_subdev() before calling unregister. Unregister references pads during unregistering subdev. The sd release handler is the right place for releasing all sd resources including pads. The release handlers currently release all resources except the pads. Fix v4l2_device_unregister_subdev() not release pads and release pads from the sd_int_op release handlers. kernel: [ 4136.715839] general protection fault: 0000 [#1] SMP PTI kernel: [ 4136.715847] CPU: 2 PID: 1972 Comm: bash Not tainted 5.3.0-rc2+ #4 kernel: [ 4136.715850] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013 kernel: [ 4136.715858] RIP: 0010:media_gobj_destroy.part.16+0x1f/0x60 kernel: [ 4136.715863] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 fe 48 89 e5 53 48 89 fb 48 c7 c7 00 7f cf b0 e8 24 fa ff ff 48 8b 03 <48> 83 80 a0 00 00 00 01 48 8b 43 18 48 8b 53 10 48 89 42 08 48 89 kernel: [ 4136.715866] RSP: 0018:ffff9b2248fe3cb0 EFLAGS: 00010246 kernel: [ 4136.715870] RAX: bcf2bfbfa0d63c2f RBX: ffff88c3eb37e9c0 RCX: 00000000802a0018 kernel: [ 4136.715873] RDX: ffff88c3e4f6a078 RSI: ffff88c3eb37e9c0 RDI: ffffffffb0cf7f00 kernel: [ 4136.715876] RBP: ffff9b2248fe3cb8 R08: 0000000001000002 R09: ffffffffb0492b00 kernel: [ 4136.715879] R10: ffff9b2248fe3c28 R11: 0000000000000001 R12: 0000000000000038 kernel: [ 4136.715881] R13: ffffffffc09a1628 R14: ffff88c3e4f6a028 R15: fffffffffffffff2 kernel: [ 4136.715885] FS: 00007f8389647740(0000) GS:ffff88c465500000(0000) knlGS:0000000000000000 kernel: [ 4136.715888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: [ 4136.715891] CR2: 000055d008f80fd8 CR3: 00000001996ec005 CR4: 00000000000606e0 kernel: [ 4136.715894] Call Trace: kernel: [ 4136.715903] media_gobj_destroy+0x14/0x20 kernel: [ 4136.715908] __media_device_unregister_entity+0xb3/0xe0 kernel: [ 4136.715915] media_device_unregister_entity+0x30/0x40 kernel: [ 4136.715920] v4l2_device_unregister_subdev+0xa8/0xe0 kernel: [ 4136.715928] vimc_ent_sd_unregister+0x1e/0x30 [vimc] kernel: [ 4136.715933] vimc_sen_rm+0x16/0x20 [vimc] kernel: [ 4136.715938] vimc_remove+0x3e/0xa0 [vimc] kernel: [ 4136.715945] platform_drv_remove+0x25/0x50 kernel: [ 4136.715951] device_release_driver_internal+0xe0/0x1b0 kernel: [ 4136.715956] device_driver_detach+0x14/0x20 kernel: [ 4136.715960] unbind_store+0xd1/0x130 kernel: [ 4136.715965] drv_attr_store+0x27/0x40 kernel: [ 4136.715971] sysfs_kf_write+0x48/0x60 kernel: [ 4136.715976] kernfs_fop_write+0x128/0x1b0 kernel: [ 4136.715982] __vfs_write+0x1b/0x40 kernel: [ 4136.715987] vfs_write+0xc3/0x1d0 kernel: [ 4136.715993] ksys_write+0xaa/0xe0 kernel: [ 4136.715999] __x64_sys_write+0x1a/0x20 kernel: [ 4136.716005] do_syscall_64+0x5a/0x130 kernel: [ 4136.716010] entry_SYSCALL_64_after_hwframe+0x4 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:09 +07:00
vimc_pads_cleanup(vdeb->ved.pads);
kfree(vdeb);
}
static const struct v4l2_subdev_internal_ops vimc_deb_int_ops = {
.release = vimc_deb_release,
};
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
void vimc_deb_rm(struct vimc_device *vimc, struct vimc_ent_device *ved)
{
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
struct vimc_deb_device *vdeb;
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
vdeb = container_of(ved, struct vimc_deb_device, ved);
vimc_ent_sd_unregister(ved, &vdeb->sd);
}
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
struct vimc_ent_device *vimc_deb_add(struct vimc_device *vimc,
const char *vcfg_name)
{
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
struct v4l2_device *v4l2_dev = &vimc->v4l2_dev;
struct vimc_deb_device *vdeb;
int ret;
/* Allocate the vdeb struct */
vdeb = kzalloc(sizeof(*vdeb), GFP_KERNEL);
if (!vdeb)
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
return NULL;
/* Initialize ved and sd */
ret = vimc_ent_sd_register(&vdeb->ved, &vdeb->sd, v4l2_dev,
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
vcfg_name,
MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV, 2,
(const unsigned long[2]) {MEDIA_PAD_FL_SINK,
MEDIA_PAD_FL_SOURCE},
&vimc_deb_int_ops, &vimc_deb_ops);
if (ret) {
kfree(vdeb);
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
return NULL;
}
vdeb->ved.process_frame = vimc_deb_process_frame;
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
vdeb->dev = &vimc->pdev.dev;
/* Initialize the frame format */
vdeb->sink_fmt = sink_fmt_default;
/*
* TODO: Add support for more output formats, we only support
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
* RGB888 for now
* NOTE: the src format is always the same as the sink, except
* for the code
*/
media: Revert "media: vimc: propagate pixel format in the stream" This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-09 07:27:41 +07:00
vdeb->src_code = MEDIA_BUS_FMT_RGB888_1X24;
vdeb->set_rgb_src = vimc_deb_set_rgb_mbus_fmt_rgb888_1x24;
media: vimc: Collapse component structure into a single monolithic driver vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. Collapse it into a single monolithic driver removing the Component API. This patch removes the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_device and vimc_ent_config global by moving them to vimc-common.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - Add a new field to vimc_device structure for saving the pointers to struct vimc_ent_device(s) subdevs create in their "add" hooks. These get used to create links and removing the subdevs. vimc-core allocates this array which sized to number of entries in the topology defined in the vimc_pipeline_config structure. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. Each "add" hook returns pointer to its struct vimc_ent_device. This is saved in the vimc_device ent_devs array. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding vimc_ent_device saved in the ent_devs. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-09-17 23:35:08 +07:00
return &vdeb->ved;
}