On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote:
>
> On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> > Hi,
> >
> > > My take on this (for a decoder) would be to allocate memory for output
> > > buffers from a secure ION heap, import in the v4l2 driver, and then t
Hi Mauro,
We have a new keymap, new usb IDs, some minor cleanups and the DVB fixes
you wrote.
Thanks,
Sean
The following changes since commit 3ff3a712a9eabb3d7bf52c263dd1ece054345df4:
media: ti-vpe: vpe: don't rely on colorspace member for conversion
(2019-10-10 13:54:22 -0300)
are availab
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59470/
Build log: https://builder.linuxtv.org/job/patchwork/20509/
Build time: 00:12:40
Link: https://lore.kernel.org/linux-media/20191015085903.ga11...@gofer.mess.org
gpg: Signature made Tue 15 Oct 2019 08:53:26 AM UTC
g
This patch adds metadata support in vivid driver.
Metadata capture supports UVCH format V4L2_META_FMT_UVC as it is widely used in
webcams.
https://hverkuil.home.xs4all.nl/spec/uapi/v4l/pixfmt-meta-uvc.html
For Metadata output a new format V4L2_META_FMT_VIVID is added,
which is used to set brightne
Support metadata output in vivid driver.
Metadata output is used to set brightness, contrast, saturation
and hue.
Adds new files for metadata output.
Signed-off-by: Vandana BN
---
drivers/media/platform/vivid/Makefile | 2 +-
drivers/media/platform/vivid/vivid-core.c | 98
This patch adds meatadata capture support in vivid driver.
Adds new files for metadata capture.
Adds vivid controls to generate PTS and SCR for metadata stream.
also fixes v4l2-compliance issues seen on metadata device.
Signed-off-by: Vandana BN
---
drivers/media/platform/vivid/Makefile
Add new metadata format to support metadata output in vivid.
Signed-off-by: Vandana BN
---
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-i
Add the compatible string for RZ/G2N (R8A774B1) to the list of supported
SoCs.
Signed-off-by: Biju Das
---
Documentation/devicetree/bindings/media/renesas,csi2.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.txt
b/Documentation/device
Document support for the VIN module in the Renesas RZ/G2N (R8A774B1) SoC.
Signed-off-by: Biju Das
---
Documentation/devicetree/bindings/media/renesas,vin.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/renesas,vin.txt
b/Documentation/devicetree/bi
This patch series add VIN/CSI-2 driver support for RZ/G2N SoC.
Biju Das (4):
media: dt-bindings: rcar-vin: Add R8A774B1 support
media: dt-bindings: rcar-csi2: Add R8A774B1 support
media: rcar-vin: Enable support for R8A774B1
media: rcar-csi2: Enable support for R8A774B1
Documentation/dev
Add the SoC specific information for RZ/G2N(R8A774B1) SoC.
The VIN module of RZ/G2N is similar to R-Car M3-N.
Signed-off-by: Biju Das
---
drivers/media/platform/rcar-vin/rcar-core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/med
Add the MIPI CSI-2 driver support for RZ/G2N(R8A774B1) SoC.
The CSI-2 module of RZ/G2N is similar to R-Car M3-N.
Signed-off-by: Biju Das
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
b/drivers/
Adds support to test metadata output format V4L2_META_FMT_VIVID.
Signed-off-by: Vandana BN
---
Changes in V3:
simplified meta_fillbuffer(), also ensure the brightness and
contrast values are in range 64-255.
---
contrib/freebsd/include/linux/videodev2.h | 1 +
include/linux/videodev2.h
Hello Gerd,
On Dienstag, 15. Oktober 2019 09:54:22 CEST Gerd Hoffmann wrote:
> On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote:
> > On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > My take on this (for a decoder) would be to allocate memory
Hi Steve,
On Mon, Oct 14, 2019 at 2:20 PM Steve Longerbeam wrote:
> should be "'adv7180 4-0021:0".
Will fix it.
> should be "'ipu1_csi0_mux':5".
Will fix it.
> > + media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x576]"
> > + media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x576 field:none]"
> > +
Add a video device capability flag to indicate that its inputs and/or
outputs are controlled by the Media Controller instead of the V4L2 API.
When this flag is set, ioctls for get, set and enum inputs and outputs
are automatically enabled and programmed to call helper function
Signed-off-by: Helen
Set the V4L2_CAP_IO_MC capability flag and remove the driver specific
enum, get and set input callbacks for the media controller enabled mode
of the driver.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-v4l2.c | 17 +
1 file changed, 1 insertion(+), 16
Hi,
First of this series is based on work done by Helen in 2017 [1], I have
synced with her that it's OK for me to takeover the work.
This series aims to reduce the amount of boiler plate code in video
device drivers who's inputs and/or outputs are controlled by the Media
Controller instead of
Set the V4L2_CAP_IO_MC capability flag and remove the driver specific
enum, get and set input callbacks.
Signed-off-by: Niklas Söderlund
---
drivers/staging/media/ipu3/ipu3-v4l2.c | 60 +-
1 file changed, 2 insertions(+), 58 deletions(-)
diff --git a/drivers/staging/medi
On Tue, Oct 15, 2019 at 11:27 AM Fabio Estevam wrote:
> Yes, I can add it.
>
> What is the video device node for "ipu1_ic_prpvf capture" on the imx6q
> sabreauto?
I managed to get access to a imx6q-sabreauto and it's /dev/video2.
Will send a new patch series soon.
Thanks
On Sat, Oct 12, 2019 at 2:19 PM Fabio Estevam wrote:
>
> Hi Steve,
>
> On Sat, Oct 12, 2019 at 5:24 PM Steve Longerbeam
> wrote:
>
> > Ah, now I remember. You are using the imx6dl sabreauto, it's IPU-CSI
>
> Yes, correct. I am using the imx6dl-sabreauto.
>
> > video muxes have five input pads fo
Hi Tim,
On Tue, Oct 15, 2019 at 12:49 PM Tim Harvey wrote:
> Fabio,
>
> I assume your seeing the same rolling video issue on capture unless
> you discard the first few 'corrupt' frames? I'm still wondering how we
> can address this properly upstream.
On i.MX53 I still get the rolling video even
Dne petek, 11. oktober 2019 ob 11:32:39 CEST je Hans Verkuil napisal(a):
> This series adds support for decoding multi-slice H264 frames along with
> support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF.
>
> This has only been compile-tested. Jernej, can you test with ffmpeg?
Tes
Improve the documentation by specifying that the instructions
are related to the i.MX6Q sabreauto variant.
This avoids confusion if someone follows these steps on a i.MX6DL
sabreauto, which has different numbering on the I2C bus and
I2C muxes.
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerb
In the i.MX6Q sabreauto pipeline example, it is better to provide
a real example for the output format, so do it just like in the
previous lines for consistency.
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerbeam
---
Changes since v2:
- None
Documentation/media/v4l-drivers/imx.rst | 4 +--
Pass the v4l2-ctl configuration for the imx6q-sabreauto PAL
example for completeness and consistency.
Suggested-by: Steve Longerbeam
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Newly introduced patch
Documentation/media/v4l-drivers/imx.rst | 7 ---
1 file changed, 4 insertions(+)
The i.MX6DL sabreauto has different numbering on the I2C bus and
I2C muxes compared to the i.MX6Q as shown in the kernel log below:
[5.159423] imx-media: ipu1_csi0_mux:5 -> ipu1_csi0:0
[5.164618] imx-media: ipu1_csi1_mux:5 -> ipu1_csi1:0
[5.169953] imx-media: adv7180 4-0021:0 -> ipu1_c
On Tue, Oct 15, 2019 at 8:53 AM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Tue, Oct 15, 2019 at 12:49 PM Tim Harvey wrote:
>
> > Fabio,
> >
> > I assume your seeing the same rolling video issue on capture unless
> > you discard the first few 'corrupt' frames? I'm still wondering how we
> > can addre
Hi Tim,
On Tue, Oct 15, 2019 at 1:07 PM Tim Harvey wrote:
>
> Right, I understand there is something else going on with the i.MX53
> but what about the i.MX6 testing related to these patches?
I tested it on a imx6 sabreauto board with 5.3.x kernel plus Steve's
patch that discard the 10 initial c
On Tue, Oct 15, 2019 at 9:16 AM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Tue, Oct 15, 2019 at 1:07 PM Tim Harvey wrote:
> >
> > Right, I understand there is something else going on with the i.MX53
> > but what about the i.MX6 testing related to these patches?
>
> I tested it on a imx6 sabreauto bo
On Tue, Oct 15, 2019 at 1:33 PM Tim Harvey wrote:
> Right, because this re-creates the initial issue. Upon any signal lock
> you would need to throw away the first few frames. I wish I knew the
> proper way to deal with this.
I thought this was handled by drivers/staging/media/imx/imx-media-fim.
On 10/15/19 9:42 AM, Fabio Estevam wrote:
On Tue, Oct 15, 2019 at 1:33 PM Tim Harvey wrote:
Right, because this re-creates the initial issue. Upon any signal lock
you would need to throw away the first few frames. I wish I knew the
proper way to deal with this.
I thought this was handled b
On 10/15/19 9:00 AM, Fabio Estevam wrote:
The i.MX6DL sabreauto has different numbering on the I2C bus and
I2C muxes compared to the i.MX6Q as shown in the kernel log below:
[5.159423] imx-media: ipu1_csi0_mux:5 -> ipu1_csi0:0
[5.164618] imx-media: ipu1_csi1_mux:5 -> ipu1_csi1:0
[
On 10/15/19 9:00 AM, Fabio Estevam wrote:
Pass the v4l2-ctl configuration for the imx6q-sabreauto PAL
example for completeness and consistency.
Suggested-by: Steve Longerbeam
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerbeam
---
Changes since v2:
- Newly introduced patch
Docume
Hi Steve,
On Tue, Oct 15, 2019 at 3:19 PM Steve Longerbeam wrote:
> I submitted the ICAP driver patch quite a while ago, it was ~2 yrs ago I
> think. Can't seem to find the link unfortunately.
>
> I'll work on updating the driver and retesting, and try resubmitting again.
>
> Most of the hooks a
--
Get fast and emergency loan today at 2% rate. Reply for details.
On Mon, Oct 14, 2019 at 10:40:18AM +0200, Hans Verkuil wrote:
> This supersedes
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg150027.html
> based on feedback from Laurent:
>
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg150117.html
>
> and Sakari:
>
> https://www
Fix "alignment should mactch open parenthesis" check.
Issue detected by checkpatch tool
Signed-off-by: Jules Irenge
---
drivers/staging/media/meson/vdec/codec_mpeg12.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/meson/vdec/codec_mpeg12.c
b/drivers/s
On 10/15/19 12:11 PM, Fabio Estevam wrote:
Hi Steve,
On Tue, Oct 15, 2019 at 3:19 PM Steve Longerbeam wrote:
I submitted the ICAP driver patch quite a while ago, it was ~2 yrs ago I
think. Can't seem to find the link unfortunately.
I'll work on updating the driver and retesting, and try r
Hi Steve,
On Tue, Oct 15, 2019 at 10:18 PM Steve Longerbeam wrote:
> Here's a quick example that uses the end-of-frame method to measure fi's
> (all other FIM controls are left at the default values):
Excellent! That was what I was looking for. Will test it soon.
> v4l2-ctl -d0 --wait-for-even
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Wed Oct 16 05:00:10 CEST 2019
media-tree git hash:3ff3a712a9eabb3d7bf52c263dd1ece054345df4
media_build gi
41 matches
Mail list logo
