it://git.ideasonboard.com/renesas/kms-tests.git discom
Laurent Pinchart (8):
v4l: vsp1: Use SPDX license headers
v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code
v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper
v4l: vsp1: Document the vsp1_du_atomic_con
entity. As
the DISCOM is only present in R-Car Gen3 VSP-D and VSP-DL instances it
is not exposed to userspace through V4L2 but controlled through the DU
driver. We can thus change this model later if needed without fear of
affecting userspace.
Signed-off-by: Laurent Pinchart
---
Changes since v1
of scope for this patch.
While at it fix the file descriptions to match file names where copy and
paste error occurred.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1.h| 6 +-
drivers/media/platform/vsp1/vsp1_brx.c| 6 +-
drivers/media/platform/vsp1
Implement CRC computation configuration and reporting through the DRM
debugfs-based CRC API. The CRC source can be configured to any input
plane or the pipeline output.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Format the source names using plane IDs instead of plane indices
t the
moment and could be implemented by extending the API between the VSP1
and DU drivers if needed.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 115 -
drivers/media/platform/vsp1/vsp1_drm.h | 12
2 files changed, 124 inser
Add a parameter (in the form of a structure to ease future API
extensions) to the VSP atomic flush handler to pass CRC source
configuration, and pass the CRC value to the completion callback.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 6 --
drivers/media
().
Resetting the crop and compose rectangles for entities that don't
support crop and compose has no adverse effect as the rectangles are
ignored anyway.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_entity.c | 16 +
drivers/media/platform/vsp1/vsp1_histo.c
The structure is used in the API that the VSP1 driver exposes to the DU
driver. Documenting it is thus important.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Fixed typo
---
include/media/vsp1.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/media/vsp1.h b
Hi Geert,
On Monday, 23 April 2018 10:58:13 EEST Geert Uytterhoeven wrote:
> On Sun, Apr 22, 2018 at 12:28 PM, Laurent Pinchart wrote:
> > Commit 1d3897143815 ("[media] v4l: rcar_fdp1: add FCP dependency") fixed
> > a compilation breakage when the optional VIDEO_
Hi Kieran,
On Monday, 23 April 2018 11:59:04 EEST Kieran Bingham wrote:
> On 21/04/18 13:44, Laurent Pinchart wrote:
> > The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> > include both horizontal and vertical blanking. Both the AFE and HDMI
> >
Hi Mita-san,
On Sunday, 22 April 2018 18:56:07 EEST Akinobu Mita wrote:
> This adds a device tree binding documentation for OV7720/OV7725 sensor.
>
> Cc: Jacopo Mondi
> Cc: Laurent Pinchart
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Mauro Carvalho Chehab
> Cc: Ro
no way
specific to the ov772x driver, I'd prefer implementing the fallback in the I2C
core instead.
> Cc: Jacopo Mondi
> Cc: Laurent Pinchart
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Akinobu Mita
> ---
> * v3
> - Remove I
play_mode *adjusted_mode);
> void drm_bridge_pre_enable(struct drm_bridge *bridge);
> void drm_bridge_enable(struct drm_bridge *bridge);
> +int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32 *fmts,
> +unsigned int num_fmts);
>
> #ifdef CONFIG_DRM_PANEL_BRIDGE
> struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
--
Regards,
Laurent Pinchart
e level of the MAP pin should be then software-controlled, not set
through DT.
> >> Optional properties:
> >> - powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
> >>
> >> @@ -36,6 +38,7 @@ Example:
> >>vcc-supply = <®_lvds_vcc>;
> >>powerdown-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> >> + thine,map = <1>;
> >>
> >>ports {
> >>#address-cells = <1>;
--
Regards,
Laurent Pinchart
uld write it as
- thine,map: level of the MAP pin that selects the LVDS mapping mode. Shall be
<0> for low level (mapping mode 2) or <1> for high level (mapping mode 1).
Apart from that this patch looks good to me.
Reviewed-by: Laurent Pinchart
> Optional properties:
> -
onal(thc63->dev, "oe", GPIOD_OUT_LOW);
> @@ -166,6 +203,10 @@ static int thc63_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = thc63_set_bus_fmt(thc63);
> + if (ret)
> + return ret;
> +
Or you could move the code to thc63_parse_dt() as you're parsing DT.
> thc63->bridge.driver_private = thc63;
> thc63->bridge.of_node = pdev->dev.of_node;
> thc63->bridge.funcs = &thc63_bridge_func;
--
Regards,
Laurent Pinchart
width' one
> to find that out probably.
Yes, but that could also be left for later, when the need to support those
formats arise, especially given that include/uapi/linux/media-bus-format.h has
no 1x7x5 formats yet.
> >> + break;
> >> + default:
> >> + dev_err(thc63->dev,
> >> + "Invalid value for property \"thine,map\": %u\n", map);
> >> + return -EINVAL;
> >> + }
> >> +
> >> + drm_bridge_set_bus_formats(&thc63->bridge, &bus_fmt, 1);
> >> +
> >> + return 0;
> >> +}
--
Regards,
Laurent Pinchart
case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE:
> >>>> +lvds->mode |= RCAR_LVDS_MODE_MIRROR;
> >>>>
> >>>> case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> >>>>
> >>>> case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> >>>> -mode = RCAR_LVDS_MODE_JEIDA;
> >>>> +lvds->mode = RCAR_LVDS_MODE_JEIDA;
> >>>
> >>> This is b0rken, first the mirror bit is ORed into some unknown
> >>> preexisting value, then the code falls through (without any fall
> >>> through comment, btw) and forcibly sets the mode, thus discarding the
> >>> mirror bit which was carefully ORed in.
> >>
> >> You are correct, the second assignment should have been an |= and not
> >> a plain assignment. The variable is 0ed though, as 'struct rcar_lvds
> >> *lvds' is kzalloc-ed in probe function.
> >
> > The code would be clearer if you explicitly zeroed the mode in this
> > function. Or do you rely on this function to not clobber other bits?
> > In that case apply some bit-mask.
> >
> >>>> break;
> >>>> +
> >>>> +case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE:
> >>>> +lvds->mode |= RCAR_LVDS_MODE_MIRROR;
> >>>>
> >>>> case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> >>>> -mode = RCAR_LVDS_MODE_VESA;
> >>>> +lvds->mode = RCAR_LVDS_MODE_VESA;
> >>>
> >>> Dito.
> >>>
> >>>> break;
> >>>>
> >>>> default:
> >>>> dev_err(lvds->dev, "unsupported LVDS bus format
> >>>> 0x%04x\n",
> >>>> -info->bus_formats[0]);
> >>>> -return;
> >>>> +bus_fmt);
> >>>> }
> >>>> -
> >>>> -if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
> >>>> -mode |= RCAR_LVDS_MODE_MIRROR;
> >>>> -
> >>>> -lvds->mode = mode;
> >>>> }
> >>>>
> >>>> static void rcar_lvds_mode_set(struct drm_bridge *bridge,
--
Regards,
Laurent Pinchart
_PADHI_LE0x1002
> @@ -49,13 +49,16 @@
> #define MEDIA_BUS_FMT_RBG888_1X240x100e
> #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI 0x1015
> #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG 0x1010
> +#define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE 0x101b
> #define MEDIA_BUS_FMT_BGR888_1X240x1013
> #define MEDIA_BUS_FMT_GBR888_1X240x1014
> #define MEDIA_BUS_FMT_RGB888_1X240x100a
> #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b
> #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c
> #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG 0x1011
> +#define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE 0x101c
> #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012
> +#define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE 0x101d
> #define MEDIA_BUS_FMT_ARGB_1X32 0x100d
> #define MEDIA_BUS_FMT_RGB888_1X32_PADHI 0x100f
> #define MEDIA_BUS_FMT_RGB101010_1X30 0x1018
--
Regards,
Laurent Pinchart
Hi Jacopo,
Thank you for the patch.
On Thursday, 19 April 2018 12:31:05 EEST Jacopo Mondi wrote:
> Add LVDS map mode description property to THC63LVD1024 LVDS decoder in
> R-Car V3M-Eagle board device tree.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> --
Hi Mita-san,
(CC'ing Wolfram Sang)
On Monday, 23 April 2018 18:55:20 EEST Akinobu Mita wrote:
> 2018-04-23 18:18 GMT+09:00 Laurent Pinchart:
> > On Sunday, 22 April 2018 18:56:08 EEST Akinobu Mita wrote:
> >> The ov772x driver only works when
t;OMAP2+ frame buffer support"
>depends on FB
> depends on (DRM_OMAP = n) || COMPILE_TEST
>
> would be enough to allow to build both on ARM.
I don't think it's worth it renaming the common symbols. They will change over
time as omapdrm is under heavy rework, and it's painful enough without having
to handle cross-tree changes. Let's just live with the fact that both drivers
can't be compiled at the same time, given that omapfb is deprecated.
> > I need some more time to think about this..
--
Regards,
Laurent Pinchart
t an implementation in the I2C subsystem would be better.
Furthermore, as SCCB is really a slightly mangled version of I2C, I think the
I2C subsystem would be a natural location for the implementation. It shouldn't
be too much work, it's just a matter of deciding what the call stacks should
be for the native vs. emulated cases.
--
Regards,
Laurent Pinchart
On Monday, 23 April 2018 23:09:55 EEST Mauro Carvalho Chehab wrote:
> Laurent Pinchart escreveu:
> > On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:
> > > Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:
> > > > On Mond
r (even though most SCCB
devices generate an ack, so we could likely ignore this), and write-read
sequences shouldn't use a repeated start. Apart from that register reads and
register writes are identical to SMBus, which prompted the reuse (or abuse) of
the SMBus API. If we end up implementing SCCB helpers, they will likely look
very, very similar to the SMBus implementation, including the SMBus emulated
transfer helper.
--
Regards,
Laurent Pinchart
(1<<5)
>
> /**
>* @bus_flags: Additional information (like pixel signal polarity) for
--
Regards,
Laurent Pinchart
gt;
> :-)
>
> On 2018-04-04 18:15:16 +0300, Laurent Pinchart wrote:
>
> [snip]
>
> > > +static int rcar_csi2_start(struct rcar_csi2 *priv)
> > > +{
> > > + const struct rcar_csi2_format *format;
> > > + u32 phycnt, phypll, vcdt = 0, vcdt2
reat, thanks! That seems to fix my problem.
> >
> > Fantastic. I'm glad it helped.
> >
> > - Can I call that a Tested-by: ? :-D
>
> Now you officially can - I replied to the patch.
Thank you. I've picked the tag and sent a pull request to Mauro.
--
Regards,
Laurent Pinchart
/media/usb/uvc/uvc_ctrl.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
--
Regards,
Laurent Pinchart
em is that it supports old devices which are not supported by
> omapdrm. But both omapfb and omapdrm support many of the same devices.
Could we trim down omapfb to remove support for the devices supported by
omapdrm ?
--
Regards,
Laurent Pinchart
Hi Tomi,
On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> On 25/04/18 12:03, Laurent Pinchart wrote:
> > Could we trim down omapfb to remove support for the devices supported by
> > omapdrm ?
>
> I was thinking about just that. But, of course, it's n
Hi Tomi,
On Wednesday, 25 April 2018 13:10:43 EEST Tomi Valkeinen wrote:
> On 25/04/18 13:02, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> >> On 25/04/18 12:03, Laurent Pinchart wrote:
> >>> Could we trim down om
Hi Mita-san,
On Wednesday, 25 April 2018 19:19:11 EEST Akinobu Mita wrote:
> 2018-04-24 0:54 GMT+09:00 Akinobu Mita :
> > 2018-04-23 18:17 GMT+09:00 Laurent Pinchart:
> >> On Sunday, 22 April 2018 18:56:07 EEST Akinobu Mita wrote:
> >>> This adds a device tree bi
7;t there a guarantee that new_buf won't be NULL ? The new_buf pointer comes
from the parg variable in video_usercopy(), which should always point to a
valid buffer given that the ioctl number specifies a non-zero size.
--
Regards,
Laurent Pinchart
Hi Jacopo,
On Thursday, 26 April 2018 21:40:56 EEST jacopo mondi wrote:
> On Mon, Apr 23, 2018 at 12:27:39PM +0300, Laurent Pinchart wrote:
> > On Thursday, 19 April 2018 12:31:02 EEST Jacopo Mondi wrote:
> >> Add support for storing image format information in DRM bridges wi
When debugging issues that involve more than one video queue, messages
related to multiple queues get interleaved without any easy way to tell
which queue they relate to. Fix this by printing the queue pointer for
all debug messages in the vb2 core and V4L2 layers.
Signed-off-by: Laurent Pinchart
the video grabbers (VIN).
>
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Hans Verkuil
> Reviewed-by: Maxime Ripard
> Reviewed-by: Laurent Pinchart
>
> ---
>
> * Changes since v13
> -
Hi Mita-san,
On Thursday, 26 April 2018 19:17:55 EEST Akinobu Mita wrote:
> 2018-04-26 7:40 GMT+09:00 Laurent Pinchart:
> > On Wednesday, 25 April 2018 19:19:11 EEST Akinobu Mita wrote:
> >> 2018-04-24 0:54 GMT+09:00 Akinobu Mita :
> >> > 2018-04-23 18:17 GMT+09:0
oC specific knowledge in the driver to function.
> Remove it before it is added to any device tree descriptions.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 1 -
> 1 file changed, 1 deletion(-)
Hi Niklas,
Thank you for the patch.
On Wednesday, 25 April 2018 02:46:07 EEST Niklas Söderlund wrote:
> By setting VNMC_YCAL rcar-vin can support input video in
> MEDIA_BUS_FMT_UYVY8_1X16 format.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
&
ave
> already been written outside the allocated capture buffer.
>
> With this change the capture in the situation described above results in
> garbage frames but that is far better then writing outside the capture
s/then/than/
> buffer.
>
> Signed-off-by: Niklas Söderlu
k is set to
free running, and at stream off time to "Gate clock lane when no packet to
transmit". Couldn't we always enable clock gating ?
Do you have any insight on this ? Have you modified the MIPI CSI-2
configuration to get the CSI-2 output working ?
--
Regards,
Laurent Pinchart
klas Söderlund
Cc: Wolfram Sang
Signed-off-by: Laurent Pinchart
---
Iwamatsu-san, Kieran, Sergei, Niklas, Wolfram,
While working on the VSP1 driver I noticed that all source files are
licensed under the GPLv2+ except for vsp1_regs.h which is licensed under
GPLv2. I'd like to fix this inconsis
Hi Kieran,
On Saturday, 28 April 2018 00:25:51 EEST Kieran Bingham wrote:
> Hi Laurent,
>
> Thank you for the patch, and going through the whole driver for this update.
> On 22/04/18 23:34, Laurent Pinchart wrote:
> > Adopt the SPDX license identifier headers to ease
Hi Niklas,
On Friday, 27 April 2018 02:28:32 EEST Niklas Söderlund wrote:
> On 2018-04-27 00:30:25 +0300, Laurent Pinchart wrote:
> > On Thursday, 26 April 2018 23:21:21 EEST Niklas Söderlund wrote:
> >> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> >&
Hi Jacopo,
On Saturday, 28 April 2018 12:50:48 EEST jacopo mondi wrote:
> Hi Laurent,
>very minor comments below
>
> On Mon, Apr 23, 2018 at 01:34:24AM +0300, Laurent Pinchart wrote:
> > The implementation of the set_fmt pad operation is identical in the
> > thr
Hi Jacopo,
On Saturday, 28 April 2018 13:03:16 EEST jacopo mondi wrote:
> Hi Laurent,
>just one minor comment below
>
> On Mon, Apr 23, 2018 at 01:34:27AM +0300, Laurent Pinchart wrote:
> > Add a parameter (in the form of a structure to ease future API
> > extensions)
Hi Jacopo,
On Saturday, 28 April 2018 13:40:02 EEST jacopo mondi wrote:
> HI Laurent,
>a few comments, mostly minor ones...
>
> On Mon, Apr 23, 2018 at 01:34:28AM +0300, Laurent Pinchart wrote:
> > The DISCOM calculates a CRC on a configurable window of the frame. It
>
Hi Jacopo,
On Saturday, 28 April 2018 14:00:26 EEST jacopo mondi wrote:
> On Mon, Apr 23, 2018 at 01:34:29AM +0300, Laurent Pinchart wrote:
> > The DISCOM is used to compute CRCs on display frames. Integrate it in
> > the display pipeline at the output of the blending unit to pro
Hi Kieran,
On Saturday, 28 April 2018 20:16:11 EEST Kieran Bingham wrote:
> On 22/04/18 23:34, Laurent Pinchart wrote:
> > The implementation of the set_fmt pad operation is identical in the
> > three modules. Move it to a generic helper function.
> >
> > Sign
Hi again,
On Saturday, 28 April 2018 20:25:44 EEST Laurent Pinchart wrote:
> On Saturday, 28 April 2018 20:16:11 EEST Kieran Bingham wrote:
> > On 22/04/18 23:34, Laurent Pinchart wrote:
> > > The implementation of the set_fmt pad operation is identical in the
> > >
Hi Kieran,
On Saturday, 28 April 2018 21:58:53 EEST Kieran Bingham wrote:
> On 22/04/18 23:34, Laurent Pinchart wrote:
> > The DISCOM is used to compute CRCs on display frames. Integrate it in
> > the display pipeline at the output of the blending unit to process
&g
Hi Kieran,
On Saturday, 28 April 2018 22:16:48 EEST Kieran Bingham wrote:
> On 22/04/18 23:34, Laurent Pinchart wrote:
> > Implement CRC computation configuration and reporting through the DRM
> > debugfs-based CRC API. The CRC source can be configured to any input
> >
Add a parameter (in the form of a structure to ease future API
extensions) to the VSP atomic flush handler to pass CRC source
configuration, and pass the CRC value to the completion callback.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v2:
- Name the CRC
Implement CRC computation configuration and reporting through the DRM
debugfs-based CRC API. The CRC source can be configured to any input
plane or the pipeline output.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v2:
- Use vsp1_du_crc_config structure in
t the
moment and could be implemented by extending the API between the VSP1
and DU drivers if needed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v2:
- Reduce indentation in vsp1_du_insert_uif()
- Use vsp1_du_crc_config structure in vsp1_drm_pipeline
---
drivers/
The structure is used in the API that the VSP1 driver exposes to the DU
driver. Documenting it is thus important.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v2:
- Fixed typo
---
include/media/vsp1.h | 10 ++
1 file changed, 10 insertions(+)
diff
The implementation of the set_fmt pad operation is identical in the
three modules. Move it to a generic helper function.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v2:
- Use entity->source_pad instead of hardcoding pad numbers
---
drivers/media/platform/v
entity. As
the DISCOM is only present in R-Car Gen3 VSP-D and VSP-DL instances it
is not exposed to userspace through V4L2 but controlled through the DU
driver. We can thus change this model later if needed without fear of
affecting userspace.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo
en tested through the kms-test-crc.py script part of the DU
test suite available at
git://git.ideasonboard.com/renesas/kms-tests.git discom
Laurent Pinchart (8):
v4l: vsp1: Use SPDX license headers
v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code
v4l: vsp1: Reset the crop
().
Resetting the crop and compose rectangles for entities that don't
support crop and compose has no adverse effect as the rectangles are
ignored anyway.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_entity.c
of scope for this patch.
While at it fix the file descriptions to match file names where copy and
paste error occurred.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1.h| 6 +-
drivers/media/platform/vsp1/vsp1_brx.c| 6
re - and instead
> ensure that the requried DL is passed through.
I agree with you, that makes sense.
> Unless there's a better way to get the cmd object ?
There's none that immediately occurs to me.
> > + } else {
> > + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_Y, mem.addr[0]);
> > + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C0, mem.addr[1]);
> > + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C1, mem.addr[2]);
> > + }
> > }
> > +
> > static void rpf_partition(struct vsp1_entity *entity,
> > struct vsp1_pipeline *pipe,
> > struct vsp1_partition *partition,
> > diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h
> > b/drivers/media/platform/vsp1/vsp1_rwpf.h index
> > 70742ecf766f..8d6e42f27908 100644
> > --- a/drivers/media/platform/vsp1/vsp1_rwpf.h
> > +++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
> > @@ -42,6 +42,7 @@ struct vsp1_rwpf {
> > struct v4l2_pix_format_mplane format;
> > const struct vsp1_format_info *fmtinfo;
> > unsigned int brx_input;
> > + bool interlaced;
kerneldoc might be nice :-)
> >
> > unsigned int alpha;
> >
[snip]
> > diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> > index 678c24de1ac6..c10883f30980 100644
> > --- a/include/media/vsp1.h
> > +++ b/include/media/vsp1.h
> > @@ -50,6 +50,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
> > pipe_index,>
> > * @dst: destination rectangle on the display (integer coordinates)
> > * @alpha: alpha value (0: fully transparent, 255: fully opaque)
> > * @zpos: Z position of the plane (from 0 to number of planes minus 1)
> > + * @interlaced: true for interlaced pipelines
Maybe "true if the pipeline outputs an interlaced stream" ?
> > */
> > struct vsp1_du_atomic_config {
> > u32 pixelformat;
> >
--
Regards,
Laurent Pinchart
Hi Dave,
Ping ?
On Saturday, 28 April 2018 23:50:19 EEST Laurent Pinchart wrote:
> Hello,
>
> (Dave, there's a request for you below)
>
> This patch series adds support for CRC calculation to the rcar-du-drm
> driver.
>
> CRC calculation is supported starting a
Hi Niklas,
On Saturday, 5 May 2018 01:58:10 EEST Niklas Söderlund wrote:
> On 2018-04-25 01:36:42 +0200, Niklas Söderlund wrote:
> > On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> >> The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> >>
Hi Mauro,
On Saturday, 5 May 2018 13:35:38 EEST Mauro Carvalho Chehab wrote:
> Em Wed, 25 Apr 2018 03:37:00 +0300 Laurent Pinchart escreveu:
> > Hi Mauro,
> >
> > The following changes since commit
60cc43fc888428bb2f18f08997432d426a243338:
> > Linux 4.17-rc1
/dri-devel/msg175198.html
[2] https://www.spinics.net/lists/dri-devel/msg175259.html
--------
Laurent Pinchart (8):
v4l: vsp1: Use SPDX license headers
v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code
v4l: vsp1:
Hi Daniel,
(CC'ing Mauro)
On Thursday, 3 May 2018 16:45:36 EEST Daniel Vetter wrote:
> On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart wrote:
> > Hi Dave,
> >
> > Ping ?
>
> Not aware of any crc core work going on in drm, so has my ack.
Thank you.
>
Hi Mauro,
On Saturday, 5 May 2018 18:05:13 EEST Mauro Carvalho Chehab wrote:
> Em Sat, 05 May 2018 17:06:50 +0300 Laurent Pinchart escreveu:
> > On Thursday, 3 May 2018 16:45:36 EEST Daniel Vetter wrote:
> >> On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart wrote:
> >>&
rvin_write(vin, ALIGN(vin->format.width, 0x20), VNIS_REG);
> - else
> - rvin_write(vin, ALIGN(vin->format.width, 0x10), VNIS_REG);
> + fmt = rvin_format_from_pixel(vin, vin->format.pixelformat);
You may want as an optimisation to cache the active rv
> which,
> done:
> v4l2_subdev_free_pad_config(pad_cfg);
>
> - return 0;
> + return ret;
If the v4l2_subdev_call() call above returns -ENOIOCTLCMD, which you
don't consider as an error, you will end up returning that error value
here. You should set ret to 0 before the d
Hi Niklas,
Thank you for the patch.
On Thu, Aug 08, 2019 at 03:18:46AM +0200, Niklas Söderlund wrote:
> The V4L2_FIELD_IS_INTERLACED() can be used to make the code more
> readable, use it.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> drivers/m
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -176,7 +176,7 @@ struct rvin_info {
> *
> * @crop:active cropping
> * @compose: active composing
> - * @source: active size of the video sourc
int rvin_s_fmt_vid_cap(struct file *file, void
> *priv,
> return ret;
>
> vin->format = f->fmt.pix;
> - vin->crop = crop;
> - vin->compose = compose;
> + v4l2_rect_map_inside(&vin->crop, &crop);
> + v4l2_rect_map_inside(&vin->compose, &compose);
> vin->src_rect = crop;
>
> return 0;
--
Regards,
Laurent Pinchart
Hi Sakari,
Thank you for the patch.
On Mon, Aug 12, 2019 at 11:32:26AM +0300, Sakari Ailus wrote:
> The omap3isp driver registered subdevs without the dev field being set. Do
> that now.
>
> Signed-off-by: Sakari Ailus
The change looks fine, so
Reviewed-by: Laurent Pinchart
tream sub-devices.
>
> Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/om
s that we won't have material to have a media summit this year.
> > >> So, let's cancel the media summit this year.
> > >
> > > Loosely related, but are there people planning to go to ELCE on
> > > 10/28-30? Tomasz and I may attend if there is a chance to discuss
> > > libcamera/V4L2 codecs.
> >
> > I'll be there and if there is enough interest in setting up a meeting
> > to discuss this, then I can ask the LF to set a room aside for us for,
> > say, half a day or so.
--
Regards,
Laurent Pinchart
This helps identifying the IP core version, for debugging purpose only
for now.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Use devm_platform_ioremap_resource()
---
drivers/media/platform/rcar-fcp.c | 41 +++
1 file changed, 41 insertions(+)
diff --git
: Register a v4l2_device")
Reported-by: syzbot+c86454eb3af9e8a4d...@syzkaller.appspotmail.com
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_driver.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driv
Colin Ian King (1):
media: vsp1: fix memory leak of dl on error return path
drivers/media/platform/vsp1/vsp1_dl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
Regards,
Laurent Pinchart
Hi Marco,
On Fri, Aug 09, 2019 at 07:58:09AM +0200, Marco Felsch wrote:
> On 19-05-16 19:27, Laurent Pinchart wrote:
> > On Mon, Apr 15, 2019 at 02:44:01PM +0200, Marco Felsch wrote:
> > > Some connectors no matter if in- or output supports only a limited
> > > ra
Hi Marco,
On Fri, Aug 09, 2019 at 09:55:36AM +0200, Marco Felsch wrote:
> On 19-05-16 19:36, Laurent Pinchart wrote:
> > On Mon, Apr 15, 2019 at 02:44:02PM +0200, Marco Felsch wrote:
> > > Currently every driver needs to parse the connector endpoints by it self.
> &g
Hi Marco,
On Fri, Aug 09, 2019 at 02:16:06PM +0200, Marco Felsch wrote:
> On 19-05-16 19:51, Laurent Pinchart wrote:
> > On Tue, May 14, 2019 at 03:20:04PM -0300, Mauro Carvalho Chehab wrote:
> >> Em Mon, 6 May 2019 12:10:41 +0200 Hans Verkuil escreveu:
> >>> On
On Tue, Aug 13, 2019 at 10:54:29AM +0200, Marco Felsch wrote:
> Hi Laurent,
>
> On 19-05-16 21:03, Laurent Pinchart wrote:
> > Hello Marco,
> >
> > Thank you for the patch.
> >
> > On Tue, May 14, 2019 at 03:25:45PM -0300, Mauro Carvalho Chehab wrote:
&
Hi Marco,
On Tue, Aug 13, 2019 at 11:10:30AM +0200, Marco Felsch wrote:
> On 19-05-16 21:07, Laurent Pinchart wrote:
> > On Mon, Apr 15, 2019 at 02:44:12PM +0200, Marco Felsch wrote:
> > > The tvp5150 accepts NTSC(M,J,4.43), PAL (B,D,G,H,I,M,N) and SECAM video
> > &g
Hi Marco,
On Thu, Aug 15, 2019 at 02:50:02PM +0200, Marco Felsch wrote:
> On 19-08-15 15:33, Laurent Pinchart wrote:
> > On Fri, Aug 09, 2019 at 07:58:09AM +0200, Marco Felsch wrote:
> >> On 19-05-16 19:27, Laurent Pinchart wrote:
> >>> On Mon, Apr 15, 2019 at 02:44:
Hi Marco,
On Thu, Aug 15, 2019 at 03:04:37PM +0200, Marco Felsch wrote:
> On 19-08-15 15:38, Laurent Pinchart wrote:
> > On Fri, Aug 09, 2019 at 09:55:36AM +0200, Marco Felsch wrote:
> >> On 19-05-16 19:36, Laurent Pinchart wrote:
> >>> On Mon, Apr 15, 2019 at 02:44:
Hi Sakari,
On Thu, Aug 15, 2019 at 04:08:49PM +0300, Sakari Ailus wrote:
> On Thu, Aug 15, 2019 at 03:59:38PM +0300, Laurent Pinchart wrote:
> > On Thu, Aug 15, 2019 at 10:00:25AM +0300, Sakari Ailus wrote:
> > > On Wed, Aug 14, 2019 at 10:28:12PM +0200, Jacopo Mondi
H Marco,
On Thu, Aug 15, 2019 at 03:22:51PM +0200, Marco Felsch wrote:
> On 19-08-15 15:51, Laurent Pinchart wrote:
> > On Tue, Aug 13, 2019 at 10:54:29AM +0200, Marco Felsch wrote:
> >> On 19-05-16 21:03, Laurent Pinchart wrote:
> >>> On Tue, May 14, 2019 at 03
Hi Kieran,
On Fri, Aug 16, 2019 at 09:07:14AM +0100, Kieran Bingham wrote:
> On 14/08/2019 15:54, Laurent Pinchart wrote:
> > This helps identifying the IP core version, for debugging purpose only
> > for now.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
>
Hi Geert,
On Fri, Aug 16, 2019 at 10:21:42AM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 14, 2019 at 4:55 PM Laurent Pinchart wrote:
> > This helps identifying the IP core version, for debugging purpose only
> > for now.
> >
> > Signed-off-by: Laurent Pinchart
ase let me know.
> > >
> > > I do need to know how many people I can expect. I have the following
> > > confirmed attendees (and please reply if you are not listed!):
> > >
> > > Alexandre Courbot
> > > Tomasz Figa
> > > Jacopo Mondi
Hi Eugen,
On Mon, Aug 19, 2019 at 03:24:26PM +, eugen.hris...@microchip.com wrote:
> On 19.08.2019 18:04, Laurent Pinchart wrote:
> > On Mon, Aug 19, 2019 at 11:43:56AM -0300, Ezequiel Garcia wrote:
> >> On Mon, 2019-08-19 at 09:44 +0200, Hans Verkuil wrote:
> >>
Hi Mauro,
Thank you for the patch.
On Thu, Aug 22, 2019 at 04:39:32PM -0300, Mauro Carvalho Chehab wrote:
> As warned by cppcheck:
>
> [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed
> 32-bit value by 31 bits is undefined behaviour
> [drivers/media/pci/bt8xx/btt
-#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK (1<<6)
> +#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK BIT(6)
>
> #define ISPCCDC_LSC_INITIAL_X_MASK 0x3F
> #define ISPCCDC_LSC_INITIAL_X_SHIFT 0
[snip]
With this small issue addressed,
For omap3isp, vsp1, xilinx, wl128x and ipu3,
Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
y...
>
> > > + csi20vin4: endpoint {
> > > + remote-endpoint = <&vin4csi20>;
> > > + };
> > > + };
> > > + };
> > > +};
> > > +
> > > +vin4: video@e6ef4000 {
> > > + compatible = "renesas,vin-r8a7795";
> > > + reg = <0 0xe6ef4000 0 0x1000>;
> > > + interrupts = ;
> > > + clocks = <&cpg CPG_MOD 807>;
> > > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > > + resets = <&cpg 807>;
> > > + renesas,id = <4>;
> >
> > Same comment as above, is all properties needed in the example?
> > Specially renesas,id can be confusing as it's a driver specific binding
> > needed to workaround a fun hardware design.
>
> I agree, but I'm debated.. one looks at the example and it doesn't
> match the actual VIN bindings, and then might be even more confused.
> I'm find dropping all of this. Maybe we can add a line in the intro
> that says the example is fictional and does not report all the
> required properties for a device to work.
>
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + /* Parallel input port: HDMI decoder */
> > > + port@0 {
> > > + reg = <0>;
> > > +
> > > + vin4_digital_in: endpoint {
> > > + bus-type = 5;
> > > + bus-width = <8>;/* Used data lines */
> > > + data-shift = <2>; /* Lines 9:2 are used */
> > > + data-active = <1>; /* Active high */
> > > + pclk-sample = <0>; /* Falling */
> > > + /* If hsync-active/vsync-active are missing,
> > > + * embedded BT.656 sync is used */
> >
> > I feel if this comment is to be kept it should be expanded.
>
> I copied it from the existing example. How would you expand it?
>
> > > + hsync-active = <0>;
> > > + vsync-active = <0>;
> > > + remote-endpoint = <&adv7612_out>;
> > > + };
> > > + };
> > > +
> > > +
> > > + /* Data path to the MIPI CSI-2 receiver. */
> > > + port@1 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + reg =<1>;
> > > +
> > > + /* Need endpoint numbers when multiple endpoints are
> > > +present. */
> >
> > I think this can be dropped.
>
> Ok
>
> Thanks for review
>
> > > + vin4csi20: endpoint@0 {
> > > + reg = <0>;
> > > + remote-endpoint = <&csi20vin4>;
> > > + };
> > > +
> > > + /* Not connected in this example. */
> > > + vin4csi41: endpoint@3 {
> > > + reg = <3>;
> > > + remote-endpoint = <&csi41vin4>;
> > > };
> > > };
> > > };
> > > +};
--
Regards,
Laurent Pinchart
he device position.
It could be something else than cables (wireless possibly ?). I would
phrase this along the lines of "The device is not attached directly to
the [device], or is attached in a way that allows it to move to
different locations."
>
> Optional endpoint properties
>
--
Regards,
Laurent Pinchart
mera sensor is located on the back side of the device.
> +* - ``V4L2_LOCATION_EXTERNAL``
> + - The camera sensor is connected by extension cables to the device and
> +it's freely movable.
s/it's/is/
> +
> +
> +
> .. [#f1]
> This control may be changed to a menu control in the future, if more
> options are required.
--
Regards,
Laurent Pinchart
driver.
> +
> .. [#f1]
> This control may be changed to a menu control in the future, if more
> options are required.
--
Regards,
Laurent Pinchart
(V4L2_CID_CAMERA_CLASS_BASE+33)
>
> +#define V4L2_CID_CAMERA_SENSOR_LOCATION
> (V4L2_CID_CAMERA_CLASS_BASE+34)
> +#define V4L2_LOCATION_FRONT 0
> +#define V4L2_LOCATION_BACK 1
> +#define V4L2_LOCATION_EXTERNAL 2
> +
> /* FM Modulator class control IDs */
>
> #define V4L2_CID_FM_TX_CLASS_BASE(V4L2_CTRL_CLASS_FM_TX | 0x900)
--
Regards,
Laurent Pinchart
801 - 900 of 8133 matches
Mail list logo
