cron job: media_tree daily build: ERRORS
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: Thu Dec 6 05:00:13 CET 2018 media-tree git hash:3c28b91380dd1183347d32d87d820818031ebecf media_build git hash: 4b9237c73e29ea969f6a7b3d00030e14be50 v4l-utils git hash: 9f0354c3320f3cc62983f726bfed66e1d0c21f83 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.57-i686: ERRORS linux-3.16.57-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.123-i686: ERRORS linux-3.18.123-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.159-i686: ERRORS linux-4.4.159-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.131-i686: ERRORS linux-4.9.131-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: ERRORS linux-4.13.16-x86_64: ERRORS linux-4.14.74-i686: ERRORS linux-4.14.74-x86_64: ERRORS linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH v2] media: rockchip vpu: remove some unused vars
As complained by gcc:
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In
function 'rk3288_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In
function 'rk3399_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_queue_setup':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_buf_prepare':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 6 --
3 files changed, 16 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index e27c10855de5..5282236d1bb1 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
index 5f75e4d11d76..dbc86d95fe3b 100644
--- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
@@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
index 038a7136d5d1..ab0fb2053620 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
@@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
struct device *alloc_devs[])
{
struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
- const struct rockchip_vpu_fmt *vpu_fmt;
struct v4l2_pix_format_mplane *pixfmt;
int i;
switch (vq->type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
- vpu_fmt = ctx->vpu_dst_fmt;
pixfmt = >dst_fmt;
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
- vpu_fmt = ctx->vpu_src_fmt;
pixfmt = >src_fmt;
break;
default:
@@ -557,7 +554,6 @@ static int rockchip_vpu_buf_prepare(struct vb2_buffer *vb)
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
struct
[PATCH] media: rockchip vpu: remove some unused vars
As complained by gcc:
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In
function 'rk3288_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In
function 'rk3399_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_queue_setup':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_buf_prepare':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index e27c10855de5..5282236d1bb1 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
--
2.19.1
Re: [PATCH v5] media: imx: add mem2mem device
On 12/5/18 10:50 AM, Hans Verkuil wrote:
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
Hi Hans, Philipp,
One comment on my side...
On 12/3/18 7:21 AM, Hans Verkuil wrote:
+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+ struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+ struct video_device *vfd = priv->vdev.vfd;
+
+ mutex_lock(>mutex);
+
+ if (video_is_registered(vfd)) {
+ video_unregister_device(vfd);
+ media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.
Philipp, can you pick/squash the following from my media-tree github fork?
6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")
Steve
Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?
It is basically a stand-alone m2m driver, but it makes use of some
imx-media utility functions like imx_media_enum_format(). Also making it
a true stand-alone driver would require creating a second /dev/mediaN
device.
Steve
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Em Wed, 05 Dec 2018 17:02:46 -0300
Ezequiel Garcia escreveu:
> On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> > Em Wed, 5 Dec 2018 16:34:04 -0200
> > Mauro Carvalho Chehab escreveu:
> >
> > > Em Wed, 5 Dec 2018 17:29:38 +0100
> > > Hans Verkuil escreveu:
> > >
> > > > Note regarding the first 'Revert' patch: that is this patch:
> > > >
> > > > https://patchwork.linuxtv.org/patch/52869/
> > > >
> > > > It is currently pending for 4.20 as a fix, but since it is not merged
> > > > upstream
> > > > yet, our master branch still has those old bindings.
> > > >
> > > > I decided to first apply the Revert patch, then add the new patch on
> > > > top.
> > > >
> > > > Regards,
> > > >
> > > > Hans
> > > >
> > > > The following changes since commit
> > > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > > >
> > > > media: v4l2: async: remove locking when initializing async notifier
> > > > (2018-12-05 06:51:28 -0500)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > > >
> > > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > > >
> > > > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46
> > > > +0100)
> > > >
> > > >
> > > > Tag branch
> > > >
> > > >
> > > > Ezequiel Garcia (3):
> > > > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > > media: dt-bindings: Document the Rockchip VPU bindings
> > > > media: add Rockchip VPU JPEG encoder driver
> > >
> > > Checkpatch produces a few warnings:
> > >
> > > # CHECK: Alignment should match open parenthesis
> > > # #385: FILE:
> > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > > # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > #
> > > # CHECK: Alignment should match open parenthesis
> > > # #1124: FILE:
> > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > > # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > #
> > > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > > # + { .compatible = "rockchip,rk3399-vpu", .data =
> > > _vpu_variant, },
> > > #
> > > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > > # + { .compatible = "rockchip,rk3288-vpu", .data =
> > > _vpu_variant, },
> > > #
> > > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> > > RK_VPU_MODE_NONE'
> > > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > > # + if (bitstream == (formats[i].codec_mode !=
> > > RK_VPU_MODE_NONE))
> > > #
> > > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> > >
>
> Please note that this last one is a false positive,
> the code needs those parenthesis.
Yes, I know. that "Unnecessary parentheses" warning should always be
taken with caution.
I've seen several cases where it was right, but, for the sake of a
better code readability, it was better to preserve it.
Thanks,
Mauro
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Dec 2018 16:34:04 -0200
> Mauro Carvalho Chehab escreveu:
>
> > Em Wed, 5 Dec 2018 17:29:38 +0100
> > Hans Verkuil escreveu:
> >
> > > Note regarding the first 'Revert' patch: that is this patch:
> > >
> > > https://patchwork.linuxtv.org/patch/52869/
> > >
> > > It is currently pending for 4.20 as a fix, but since it is not merged
> > > upstream
> > > yet, our master branch still has those old bindings.
> > >
> > > I decided to first apply the Revert patch, then add the new patch on top.
> > >
> > > Regards,
> > >
> > > Hans
> > >
> > > The following changes since commit
> > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > >
> > > media: v4l2: async: remove locking when initializing async notifier
> > > (2018-12-05 06:51:28 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > >
> > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > >
> > > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> > >
> > >
> > > Tag branch
> > >
> > >
> > > Ezequiel Garcia (3):
> > > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > media: dt-bindings: Document the Rockchip VPU bindings
> > > media: add Rockchip VPU JPEG encoder driver
> >
> > Checkpatch produces a few warnings:
> >
> > # CHECK: Alignment should match open parenthesis
> > # #385: FILE:
> > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # CHECK: Alignment should match open parenthesis
> > # #1124: FILE:
> > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > # + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
> > #
> > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > # + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
> > #
> > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> > RK_VPU_MODE_NONE'
> > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > # + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
> > #
> > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> >
Please note that this last one is a false positive,
the code needs those parenthesis.
Thanks!
Ezequiel
Re: [PATCH] media: rockchip/vpu: fix a few alignments
Em Wed, 5 Dec 2018 19:48:25 +0100 Hans Verkuil escreveu: > On 12/05/2018 07:43 PM, Mauro Carvalho Chehab wrote: > > As reported by checkpatch.pl, some function calls have a wrong > > alignment. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++-- > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++-- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > index 8919151e1631..e27c10855de5 100644 > > --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx > > *ctx) > > rk3288_vpu_set_src_img_ctrl(vpu, ctx); > > rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > > rk3288_vpu_jpeg_enc_set_qtable(vpu, > > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 0), > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 1)); > > But now you get warnings because this is > 80 columns. > > I think the 'cure' is worse than the disease. > > I see this is already merged, but I don't think this patch improves > readability, > which is more important than a checkpatch warning IMHO. IMHO, it is a way more readable if things got aligned. Very very few people nowadays (if any) write patches directly at a 80 columns console. Btw, speaking about 80 cols, usually your commit messages are longer than that (the limit is actually 80 cols - 4). I keep fixing the corresponding checkpatch.pl warnings from your patches (when I have time) :-) > > Regards, > > Hans > > > > > reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16 > > | VEPU_REG_AXI_CTRL_INPUT_SWAP16 > > diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > index 8afa2162bf9f..5f75e4d11d76 100644 > > --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx > > *ctx) > > rk3399_vpu_set_src_img_ctrl(vpu, ctx); > > rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > > rk3399_vpu_jpeg_enc_set_qtable(vpu, > > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 0), > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 1)); > > > > reg = VEPU_REG_OUTPUT_SWAP32 > > | VEPU_REG_OUTPUT_SWAP16 > > > Thanks, Mauro
[PATCH v2 2/2] media: lmedm04: Move interrupt buffer to priv buffer.
Interrupt is always present throughout life time of driver and
there is no dma element move this buffer to private area of driver.
Signed-off-by: Malcolm Priestley
---
v2 removed the need for DMA transfer flags as per Sean
drivers/media/usb/dvb-usb-v2/lmedm04.c | 28 +-
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index cba782261a6f..602013cf3e69 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -134,7 +134,7 @@ struct lme2510_state {
u8 stream_on;
u8 pid_size;
u8 pid_off;
- void *buffer;
+ u8 int_buffer[128];
struct urb *lme_urb;
u8 usb_buffer[64];
/* Frontend original calls */
@@ -388,20 +388,14 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
if (lme_int->lme_urb == NULL)
return -ENOMEM;
- lme_int->buffer = usb_alloc_coherent(d->udev, 128, GFP_ATOMIC,
- _int->lme_urb->transfer_dma);
-
- if (lme_int->buffer == NULL)
- return -ENOMEM;
-
usb_fill_int_urb(lme_int->lme_urb,
- d->udev,
- usb_rcvintpipe(d->udev, 0xa),
- lme_int->buffer,
- 128,
- lme2510_int_response,
- adap,
- 8);
+d->udev,
+usb_rcvintpipe(d->udev, 0xa),
+lme_int->int_buffer,
+sizeof(lme_int->int_buffer),
+lme2510_int_response,
+adap,
+8);
/* Quirk of pipe reporting PIPE_BULK but behaves as interrupt */
ep = usb_pipe_endpoint(d->udev, lme_int->lme_urb->pipe);
@@ -409,8 +403,6 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
if (usb_endpoint_type(>desc) == USB_ENDPOINT_XFER_BULK)
lme_int->lme_urb->pipe = usb_rcvbulkpipe(d->udev, 0xa),
- lme_int->lme_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
-
usb_submit_urb(lme_int->lme_urb, GFP_ATOMIC);
info("INT Interrupt Service Started");
@@ -1225,10 +1217,8 @@ static void lme2510_exit(struct dvb_usb_device *d)
lme2510_kill_urb(>stream);
}
- if (st->lme_urb != NULL) {
+ if (st->lme_urb) {
usb_kill_urb(st->lme_urb);
- usb_free_coherent(d->udev, 128, st->buffer,
- st->lme_urb->transfer_dma);
usb_free_urb(st->lme_urb);
info("Interrupt Service Stopped");
}
--
2.19.1
[PATCH v2 1/2] media: lmedm04: Add missing usb_free_urb to free interrupt urb.
The interrupt urb is killed but never freed add the function
Signed-off-by: Malcolm Priestley
---
v2 avoiding stale pointer in usb_free_coherent as per sean
drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index e9b149a26ce5..cba782261a6f 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -1229,6 +1229,7 @@ static void lme2510_exit(struct dvb_usb_device *d)
usb_kill_urb(st->lme_urb);
usb_free_coherent(d->udev, 128, st->buffer,
st->lme_urb->transfer_dma);
+ usb_free_urb(st->lme_urb);
info("Interrupt Service Stopped");
}
}
--
2.19.1
Re: [PATCH 2/3] media: stkwebcam: Bugfix for not correctly initialized camera
Em Wed, 5 Dec 2018 16:56:39 -0200 Mauro Carvalho Chehab escreveu: > Em Fri, 30 Nov 2018 15:58:07 +0100 > Andreas Pape escreveu: > > > Hi Kieran, > > > > thanks for the review. > > > > On Mon, 26 Nov 2018 12:48:08 + > > Kieran Bingham wrote: > > > > > This one worries me a little... (but hopefully not too much) > > > > > > > As mentioned, I don't have any experience concerning video drivers;-). I > > found > > this patch more or less experimentally > > > > > > > > > Signed-off-by: Andreas Pape > > > > --- > > > > drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c > > > > b/drivers/media/usb/stkwebcam/stk-webcam.c > > > > index e61427e50525..c64928e36a5a 100644 > > > > --- a/drivers/media/usb/stkwebcam/stk-webcam.c > > > > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c > > > > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp, > > > > if (dev->sio_bufs == NULL) > > > > return -EINVAL; > > > > dev->sequence = 0; > > > > + stk_initialise(dev); > > > > + stk_setup_format(dev); > > > > > > Glancing through the code base - this seems to imply to me that s_fmt > > > was not set/called (presumably by cheese) as stk_setup_format() is > > > called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume(). > > > > > > Is this an issue? > > > > > > I presume that this means the camera will just operate in a default > > > configuration until cheese chooses something more specific. > > > > > > > Could be. I had a video but colours, sensitivity and possibly other things > > were crap or at least very "psychedelic". Therefore the idea came up that > > some kind of initialisation was missing here. > > > > > Actually - looking further this seems to be the case, as the mode is > > > simply stored in dev->vsettings.mode, and so this last setup stage will > > > just ensure the configuration of the hardware matches the driver. > > > > > > So it seems reasonable to me - but should it be set any earlier? > > > Perhaps not. > > > > > > > > > Are there any complaints when running v4l2-compliance on this device node? > > > > > > > Here is the output of v4l2-compliance: > > > > v4l2-compliance SHA : not available > > > > Driver Info: > > Driver name : stk > > Card type : stk > > Bus info : usb-:00:1d.7-5 > > Driver version: 4.15.18 > > Capabilities : 0x8521 > > Video Capture > > Read/Write > > Streaming > > Extended Pix Format > > Device Capabilities > > Device Caps : 0x0521 > > Video Capture > > Read/Write > > Streaming > > Extended Pix Format > > > > Compliance test for device /dev/video0 (not using libv4l2): > > > > Required ioctls: > > test VIDIOC_QUERYCAP: OK > > > > Allow for multiple opens: > > test second video open: OK > > test VIDIOC_QUERYCAP: OK > > test VIDIOC_G/S_PRIORITY: OK > > test for unlimited opens: OK > > > > Debug ioctls: > > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > > test VIDIOC_LOG_STATUS: OK > > > > Input ioctls: > > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > > test VIDIOC_ENUMAUDIO: OK (Not Supported) > > test VIDIOC_G/S/ENUMINPUT: OK > > test VIDIOC_G/S_AUDIO: OK (Not Supported) > > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > > > Output ioctls: > > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > > > Input/Output configuration ioctls: > > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > > test VIDIOC_G/S_EDID: OK (Not Supported) > > > > Test input 0: > > > > Control ioctls: > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > > test VIDIOC_QUERYCTRL: OK > > test VIDIOC_G/S_CTRL: OK > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > > Standard Controls: 4 Private Controls: 0 > > > > Format ioctls: > > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > > test VIDIOC_G/S_PARM: OK > > test VIDIOC_G_FBUF: OK (Not Supported) > > test VIDIOC_G_FMT: OK > > warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an > > invalid
Re: [PATCH 2/3] media: stkwebcam: Bugfix for not correctly initialized camera
Em Fri, 30 Nov 2018 15:58:07 +0100 Andreas Pape escreveu: > Hi Kieran, > > thanks for the review. > > On Mon, 26 Nov 2018 12:48:08 + > Kieran Bingham wrote: > > > This one worries me a little... (but hopefully not too much) > > > > As mentioned, I don't have any experience concerning video drivers;-). I found > this patch more or less experimentally > > > > > > Signed-off-by: Andreas Pape > > > --- > > > drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c > > > b/drivers/media/usb/stkwebcam/stk-webcam.c > > > index e61427e50525..c64928e36a5a 100644 > > > --- a/drivers/media/usb/stkwebcam/stk-webcam.c > > > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c > > > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp, > > > if (dev->sio_bufs == NULL) > > > return -EINVAL; > > > dev->sequence = 0; > > > + stk_initialise(dev); > > > + stk_setup_format(dev); > > > > Glancing through the code base - this seems to imply to me that s_fmt > > was not set/called (presumably by cheese) as stk_setup_format() is > > called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume(). > > > > Is this an issue? > > > > I presume that this means the camera will just operate in a default > > configuration until cheese chooses something more specific. > > > > Could be. I had a video but colours, sensitivity and possibly other things > were crap or at least very "psychedelic". Therefore the idea came up that > some kind of initialisation was missing here. > > > Actually - looking further this seems to be the case, as the mode is > > simply stored in dev->vsettings.mode, and so this last setup stage will > > just ensure the configuration of the hardware matches the driver. > > > > So it seems reasonable to me - but should it be set any earlier? > > Perhaps not. > > > > > > Are there any complaints when running v4l2-compliance on this device node? > > > > Here is the output of v4l2-compliance: > > v4l2-compliance SHA : not available > > Driver Info: > Driver name : stk > Card type : stk > Bus info : usb-:00:1d.7-5 > Driver version: 4.15.18 > Capabilities : 0x8521 > Video Capture > Read/Write > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0521 > Video Capture > Read/Write > Streaming > Extended Pix Format > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > test for unlimited opens: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Test input 0: > > Control ioctls: > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 4 Private Controls: 0 > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an > invalid pixelformat. > warn: v4l2-test-formats.cpp(733): This may or may not be a > problem. For more information see: > warn: v4l2-test-formats.cpp(734): > http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html > test
Re: [PATCH v5] media: imx: add mem2mem device
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
> Hi Hans, Philipp,
>
> One comment on my side...
>
> On 12/3/18 7:21 AM, Hans Verkuil wrote:
>>
>>> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
>>> +{
>>> + struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
>>> + struct video_device *vfd = priv->vdev.vfd;
>>> +
>>> + mutex_lock(>mutex);
>>> +
>>> + if (video_is_registered(vfd)) {
>>> + video_unregister_device(vfd);
>>> + media_entity_cleanup(>entity);
>> Is this needed?
>>
>> If this is to be part of the media controller, then I expect to see a call
>> to v4l2_m2m_register_media_controller() somewhere.
>>
>
> Yes, I agree there should be a call to
> v4l2_m2m_register_media_controller(). This driver does not connect with
> any of the imx-media entities, but calling it will at least make the
> mem2mem output/capture device entities (and processing entity) visible
> in the media graph.
>
> Philipp, can you pick/squash the following from my media-tree github fork?
>
> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
> device")
> 6787a50cdc ("media: imx: mem2mem: Register with media control")
>
> Steve
>
Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?
Regards,
Hans
Re: [PATCH] media: rockchip/vpu: fix a few alignments
On 12/05/2018 07:43 PM, Mauro Carvalho Chehab wrote: > As reported by checkpatch.pl, some function calls have a wrong > alignment. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++-- > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > index 8919151e1631..e27c10855de5 100644 > --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx) > rk3288_vpu_set_src_img_ctrl(vpu, ctx); > rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > rk3288_vpu_jpeg_enc_set_qtable(vpu, > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > +rockchip_vpu_jpeg_get_qtable(_ctx, > 0), > +rockchip_vpu_jpeg_get_qtable(_ctx, > 1)); But now you get warnings because this is > 80 columns. I think the 'cure' is worse than the disease. I see this is already merged, but I don't think this patch improves readability, which is more important than a checkpatch warning IMHO. Regards, Hans > > reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16 > | VEPU_REG_AXI_CTRL_INPUT_SWAP16 > diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > index 8afa2162bf9f..5f75e4d11d76 100644 > --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx) > rk3399_vpu_set_src_img_ctrl(vpu, ctx); > rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > rk3399_vpu_jpeg_enc_set_qtable(vpu, > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > +rockchip_vpu_jpeg_get_qtable(_ctx, > 0), > +rockchip_vpu_jpeg_get_qtable(_ctx, > 1)); > > reg = VEPU_REG_OUTPUT_SWAP32 > | VEPU_REG_OUTPUT_SWAP16 >
[PATCH] media: rockchip/vpu: fix a few alignments
As reported by checkpatch.pl, some function calls have a wrong alignment. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++-- drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c index 8919151e1631..e27c10855de5 100644 --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx) rk3288_vpu_set_src_img_ctrl(vpu, ctx); rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); rk3288_vpu_jpeg_enc_set_qtable(vpu, - rockchip_vpu_jpeg_get_qtable(_ctx, 0), - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); + rockchip_vpu_jpeg_get_qtable(_ctx, 0), + rockchip_vpu_jpeg_get_qtable(_ctx, 1)); reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16 | VEPU_REG_AXI_CTRL_INPUT_SWAP16 diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c index 8afa2162bf9f..5f75e4d11d76 100644 --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx) rk3399_vpu_set_src_img_ctrl(vpu, ctx); rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); rk3399_vpu_jpeg_enc_set_qtable(vpu, - rockchip_vpu_jpeg_get_qtable(_ctx, 0), - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); + rockchip_vpu_jpeg_get_qtable(_ctx, 0), + rockchip_vpu_jpeg_get_qtable(_ctx, 1)); reg = VEPU_REG_OUTPUT_SWAP32 | VEPU_REG_OUTPUT_SWAP16 -- 2.19.1
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Em Wed, 5 Dec 2018 16:34:04 -0200
Mauro Carvalho Chehab escreveu:
> Em Wed, 5 Dec 2018 17:29:38 +0100
> Hans Verkuil escreveu:
>
> > Note regarding the first 'Revert' patch: that is this patch:
> >
> > https://patchwork.linuxtv.org/patch/52869/
> >
> > It is currently pending for 4.20 as a fix, but since it is not merged
> > upstream
> > yet, our master branch still has those old bindings.
> >
> > I decided to first apply the Revert patch, then add the new patch on top.
> >
> > Regards,
> >
> > Hans
> >
> > The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> >
> > media: v4l2: async: remove locking when initializing async notifier
> > (2018-12-05 06:51:28 -0500)
> >
> > are available in the Git repository at:
> >
> > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> >
> > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> >
> > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> >
> >
> > Tag branch
> >
> >
> > Ezequiel Garcia (3):
> > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > media: dt-bindings: Document the Rockchip VPU bindings
> > media: add Rockchip VPU JPEG encoder driver
>
> Checkpatch produces a few warnings:
>
> # CHECK: Alignment should match open parenthesis
> # #385: FILE: drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> #
> # CHECK: Alignment should match open parenthesis
> # #1124: FILE:
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> #
> # WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented
> -- check ./Documentation/devicetree/bindings/
> # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> # + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
> #
> # WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented
> -- check ./Documentation/devicetree/bindings/
> # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> # + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
> #
> # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> RK_VPU_MODE_NONE'
> # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> # + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
> #
> # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
>
> The more weird ones are the ones related to the DT bindings.
Hmm... those were my fault.
/me needs caffeine
>
> Regards,
> Mauro
>
> Thanks,
> Mauro
Thanks,
Mauro
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Em Wed, 5 Dec 2018 17:29:38 +0100
Hans Verkuil escreveu:
> Note regarding the first 'Revert' patch: that is this patch:
>
> https://patchwork.linuxtv.org/patch/52869/
>
> It is currently pending for 4.20 as a fix, but since it is not merged upstream
> yet, our master branch still has those old bindings.
>
> I decided to first apply the Revert patch, then add the new patch on top.
>
> Regards,
>
> Hans
>
> The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
>
> media: v4l2: async: remove locking when initializing async notifier
> (2018-12-05 06:51:28 -0500)
>
> are available in the Git repository at:
>
> git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
>
> for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
>
> media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
>
>
> Tag branch
>
>
> Ezequiel Garcia (3):
> Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> media: dt-bindings: Document the Rockchip VPU bindings
> media: add Rockchip VPU JPEG encoder driver
Checkpatch produces a few warnings:
# CHECK: Alignment should match open parenthesis
# #385: FILE: drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
# + rk3288_vpu_jpeg_enc_set_qtable(vpu,
# + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
#
# CHECK: Alignment should match open parenthesis
# #1124: FILE: drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
# + rk3399_vpu_jpeg_enc_set_qtable(vpu,
# + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
#
# WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented --
check ./Documentation/devicetree/bindings/
# #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
# + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
#
# WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented --
check ./Documentation/devicetree/bindings/
# #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
# + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
#
# CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
RK_VPU_MODE_NONE'
# #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
# + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
#
# total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
The more weird ones are the ones related to the DT bindings.
Regards,
Mauro
Thanks,
Mauro
Re: [PATCH v2 1/1] media: Add a Kconfig option for the Request API
Em Wed, 5 Dec 2018 19:23:54 +0200
Sakari Ailus escreveu:
> The Request API is now merged to the kernel but the confidence on the
> stability of that API is not great, especially regarding the interaction
> with V4L2.
>
> Add a Kconfig option for the API, with a scary-looking warning.
>
> The patch itself disables request creation as well as does not advertise
> them as buffer flags. The driver requiring requests (cedrus) now depends
> on the Kconfig option as well.
>
> Signed-off-by: Sakari Ailus
> Acked-by: Hans Verkuil
Looks good to me. I'll apply it.
> ---
> since v1:
>
> - Write out the #ifdef's in request creation
>
> - The option's functionality was reversed in request creation, fixed that
>
> drivers/media/Kconfig | 13 +
> drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
> drivers/media/media-device.c| 4
> drivers/staging/media/sunxi/cedrus/Kconfig | 1 +
> 4 files changed, 20 insertions(+)
>
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..102eb35fcf3f 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
>
> This is currently experimental.
>
> +config MEDIA_CONTROLLER_REQUEST_API
> + bool "Enable Media controller Request API (EXPERIMENTAL)"
> + depends on MEDIA_CONTROLLER && STAGING_MEDIA
> + default n
> + ---help---
> + DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
> +
> + This option enables the Request API for the Media controller and V4L2
> + interfaces. It is currently needed by a few stateless codec drivers.
> +
> + There is currently no intention to provide API or ABI stability for
> + this new API as of yet.
> +
> #
> # Video4Linux support
> #Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1244c246d0c4..83c3c0c49e56 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
> *caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
> if (q->io_modes & VB2_DMABUF)
> *caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (q->supports_requests)
> *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
> +#endif
> }
>
> int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index bed24372e61f..b8ec88612df7 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -381,10 +381,14 @@ static long media_device_get_topology(struct
> media_device *mdev, void *arg)
> static long media_device_request_alloc(struct media_device *mdev,
> int *alloc_fd)
> {
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> return -ENOTTY;
>
> return media_request_alloc(mdev, alloc_fd);
> +#else
> + return -ENOTTY;
> +#endif
> }
>
> static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int
> cmd)
> diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig
> b/drivers/staging/media/sunxi/cedrus/Kconfig
> index a7a34e89c42d..3252efa422f9 100644
> --- a/drivers/staging/media/sunxi/cedrus/Kconfig
> +++ b/drivers/staging/media/sunxi/cedrus/Kconfig
> @@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
> depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
> depends on HAS_DMA
> depends on OF
> + depends on MEDIA_CONTROLLER_REQUEST_API
> select SUNXI_SRAM
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
Thanks,
Mauro
[PATCH v2 1/1] media: Add a Kconfig option for the Request API
The Request API is now merged to the kernel but the confidence on the
stability of that API is not great, especially regarding the interaction
with V4L2.
Add a Kconfig option for the API, with a scary-looking warning.
The patch itself disables request creation as well as does not advertise
them as buffer flags. The driver requiring requests (cedrus) now depends
on the Kconfig option as well.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
since v1:
- Write out the #ifdef's in request creation
- The option's functionality was reversed in request creation, fixed that
drivers/media/Kconfig | 13 +
drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
drivers/media/media-device.c| 4
drivers/staging/media/sunxi/cedrus/Kconfig | 1 +
4 files changed, 20 insertions(+)
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 8add62a18293..102eb35fcf3f 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
This is currently experimental.
+config MEDIA_CONTROLLER_REQUEST_API
+ bool "Enable Media controller Request API (EXPERIMENTAL)"
+ depends on MEDIA_CONTROLLER && STAGING_MEDIA
+ default n
+ ---help---
+ DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
+
+ This option enables the Request API for the Media controller and V4L2
+ interfaces. It is currently needed by a few stateless codec drivers.
+
+ There is currently no intention to provide API or ABI stability for
+ this new API as of yet.
+
#
# Video4Linux support
# Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 1244c246d0c4..83c3c0c49e56 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
*caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
if (q->io_modes & VB2_DMABUF)
*caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
+#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
if (q->supports_requests)
*caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
+#endif
}
int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index bed24372e61f..b8ec88612df7 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -381,10 +381,14 @@ static long media_device_get_topology(struct media_device
*mdev, void *arg)
static long media_device_request_alloc(struct media_device *mdev,
int *alloc_fd)
{
+#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
return -ENOTTY;
return media_request_alloc(mdev, alloc_fd);
+#else
+ return -ENOTTY;
+#endif
}
static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int cmd)
diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig
b/drivers/staging/media/sunxi/cedrus/Kconfig
index a7a34e89c42d..3252efa422f9 100644
--- a/drivers/staging/media/sunxi/cedrus/Kconfig
+++ b/drivers/staging/media/sunxi/cedrus/Kconfig
@@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
depends on HAS_DMA
depends on OF
+ depends on MEDIA_CONTROLLER_REQUEST_API
select SUNXI_SRAM
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
--
2.11.0
[GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Note regarding the first 'Revert' patch: that is this patch: https://patchwork.linuxtv.org/patch/52869/ It is currently pending for 4.20 as a fix, but since it is not merged upstream yet, our master branch still has those old bindings. I decided to first apply the Revert patch, then add the new patch on top. Regards, Hans The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c: media: v4l2: async: remove locking when initializing async notifier (2018-12-05 06:51:28 -0500) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2 for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb: media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100) Tag branch Ezequiel Garcia (3): Revert "media: dt-bindings: Document the Rockchip VPU bindings" media: dt-bindings: Document the Rockchip VPU bindings media: add Rockchip VPU JPEG encoder driver MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile | 1 + drivers/staging/media/rockchip/vpu/Kconfig | 13 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 13 + drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c | 118 +++ drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h| 442 ++ drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c | 118 +++ drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 ++ drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h| 600 +++ drivers/staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++ drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h| 29 ++ drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 537 +++ drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 676 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h| 58 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c | 290 + drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h | 14 + 19 files changed, 3454 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h
[PATCH v3 1/2] media: tc358743: fix connected/active CSI-2 lane reporting
g_mbus_config was supposed to indicate all supported lane numbers, not
only the number of those currently in active use. Since the TC358743
can dynamically reduce the number of active lanes if the required
bandwidth allows for it, report all lane numbers up to the connected
number of lanes as supported in pdata mode.
In device tree mode, do not report lane count and clock mode at all, as
the receiver driver can determine these from the device tree.
To allow communicating the number of currently active lanes, add a new
bitfield to the v4l2_mbus_config flags. This is a temporary fix, to be
used only until a better solution is found.
Signed-off-by: Philipp Zabel
Tested-by: Dave Stevenson
---
Changes since v2 [1]:
- Rebased onto media/master
[1] https://patchwork.kernel.org/patch/9964141/
---
drivers/media/i2c/tc358743.c | 30 --
include/media/v4l2-mediabus.h | 9 +
2 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 00dc930e049f..b1e1ed4d9e0c 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -1606,28 +1606,29 @@ static int tc358743_g_mbus_config(struct v4l2_subdev
*sd,
struct v4l2_mbus_config *cfg)
{
struct tc358743_state *state = to_state(sd);
+ const u32 mask = V4L2_MBUS_CSI2_LANE_MASK;
+
+ if (state->csi_lanes_in_use > state->bus.num_data_lanes)
+ return -EINVAL;
cfg->type = V4L2_MBUS_CSI2_DPHY;
+ cfg->flags = (state->csi_lanes_in_use << __ffs(mask)) & mask;
- /* Support for non-continuous CSI-2 clock is missing in the driver */
- cfg->flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+ /* In DT mode, only report the number of active lanes */
+ if (sd->dev->of_node)
+ return 0;
- switch (state->csi_lanes_in_use) {
- case 1:
+ /* Support for non-continuous CSI-2 clock is missing in pdata mode */
+ cfg->flags |= V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+
+ if (state->bus.num_data_lanes > 0)
cfg->flags |= V4L2_MBUS_CSI2_1_LANE;
- break;
- case 2:
+ if (state->bus.num_data_lanes > 1)
cfg->flags |= V4L2_MBUS_CSI2_2_LANE;
- break;
- case 3:
+ if (state->bus.num_data_lanes > 2)
cfg->flags |= V4L2_MBUS_CSI2_3_LANE;
- break;
- case 4:
+ if (state->bus.num_data_lanes > 3)
cfg->flags |= V4L2_MBUS_CSI2_4_LANE;
- break;
- default:
- return -EINVAL;
- }
return 0;
}
@@ -2053,6 +2054,7 @@ static int tc358743_probe(struct i2c_client *client,
if (pdata) {
state->pdata = *pdata;
state->bus.flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+ state->bus.num_data_lanes = 4;
} else {
err = tc358743_probe_of(state);
if (err == -ENODEV)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 66cb746ceeb5..e127e3d1740e 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -71,6 +71,15 @@
V4L2_MBUS_CSI2_CHANNEL_2 | \
V4L2_MBUS_CSI2_CHANNEL_3)
+/*
+ * Number of lanes in use, 0 == use all available lanes (default)
+ *
+ * This is a temporary fix for devices that need to reduce the number of active
+ * lanes for certain modes, until g_mbus_config() can be replaced with a better
+ * solution.
+ */
+#define V4L2_MBUS_CSI2_LANE_MASK(0xf << 10)
+
/**
* enum v4l2_mbus_type - media bus type
* @V4L2_MBUS_UNKNOWN: unknown bus type, no V4L2 mediabus configuration
--
2.19.1
[PATCH v3 2/2] media: imx: ask source subdevice for number of active data lanes
Temporarily use g_mbus_config() to determine the number of active data
lanes used by the transmitter. If g_mbus_config is not supported or
does not return the number of active lines, default to using all
connected data lines.
Signed-off-by: Philipp Zabel
Acked-by: Steve Longerbeam
---
Changes since v2 [1]:
- Rebased onto media/master
[1] https://patchwork.kernel.org/patch/9964151/
---
drivers/staging/media/imx/imx6-mipi-csi2.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 6a1cee55a49b..ae91f0d138f3 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -135,10 +135,8 @@ static void csi2_enable(struct csi2_dev *csi2, bool enable)
}
}
-static void csi2_set_lanes(struct csi2_dev *csi2)
+static void csi2_set_lanes(struct csi2_dev *csi2, int lanes)
{
- int lanes = csi2->bus.num_data_lanes;
-
writel(lanes - 1, csi2->base + CSI2_N_LANES);
}
@@ -301,6 +299,9 @@ static void csi2ipu_gasket_init(struct csi2_dev *csi2)
static int csi2_start(struct csi2_dev *csi2)
{
+ const u32 mask = V4L2_MBUS_CSI2_LANE_MASK;
+ struct v4l2_mbus_config cfg;
+ int lanes = 0;
int ret;
ret = clk_prepare_enable(csi2->pix_clk);
@@ -316,7 +317,10 @@ static int csi2_start(struct csi2_dev *csi2)
goto err_disable_clk;
/* Step 4 */
- csi2_set_lanes(csi2);
+ ret = v4l2_subdev_call(csi2->src_sd, video, g_mbus_config, );
+ if (ret == 0)
+ lanes = (cfg.flags & mask) >> __ffs(mask);
+ csi2_set_lanes(csi2, lanes ?: csi2->bus.num_data_lanes);
csi2_enable(csi2, true);
/* Step 5 */
--
2.19.1
[PATCH v12] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- Changes from v11: * Fix buffer timecode * Add a comment explaining dma attributes * Fix wrong parenthesis * Remove unneeded error message MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 13 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 13 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 .../staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 537 ++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 676 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 14 + 19 files changed, 3454 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h diff --git a/MAINTAINERS b/MAINTAINERS index 2894fb9893a6..a86a0cd90514 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12748,6 +12748,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..9a6fc1378242 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,13 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. diff --git a/drivers/staging/media/rockchip/vpu/Makefile
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
Hi Hans,
On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote:
> On 11/30/18 18:34, Ezequiel Garcia wrote:
> > Add a mem2mem driver for the VPU available on Rockchip SoCs.
> > Currently only JPEG encoding is supported, for RK3399 and RK3288
> > platforms.
> >
> > Signed-off-by: Ezequiel Garcia
> > ---
>
>
>
[..]
>
>
> Unless something unexpected happens, then v12 should be the final
> version and I'll make a pull request for it. Note that it will
> probably won't make 4.20, unless you manage to do it within the next
> hour :-)
>
Thanks for the review. Here are the changes that will be on v12.
Besides your feedback, I found a missing parenthesis issue,
which seems to have sneaked into v11! Apparently, v11 had
last minute changes and I failed to run v4l2-compliance.
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
index f2752a0c71c0..962412c79b91 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
@@ -60,11 +60,13 @@ static void rockchip_vpu_job_finish(struct rockchip_vpu_dev
*vpu,
dst->sequence = ctx->sequence_cap++;
dst->field = src->field;
- if (dst->flags & V4L2_BUF_FLAG_TIMECODE)
+ if (src->flags & V4L2_BUF_FLAG_TIMECODE)
dst->timecode = src->timecode;
dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
- dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
- dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+ dst->flags &= ~(V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+ V4L2_BUF_FLAG_TIMECODE);
+ dst->flags |= src->flags & (V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+ V4L2_BUF_FLAG_TIMECODE);
avail_size = vb2_plane_size(>vb2_buf, 0) -
ctx->vpu_dst_fmt->header_size;
@@ -151,6 +153,12 @@ enc_queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *dst_vq)
src_vq->drv_priv = ctx;
src_vq->ops = _vpu_enc_queue_ops;
src_vq->mem_ops = _dma_contig_memops;
+
+ /*
+* Driver does mostly sequential access, so sacrifice TLB efficiency
+* for faster allocation. Also, no CPU access on the source queue,
+* so no kernel mapping needed.
+*/
src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES |
DMA_ATTR_NO_KERNEL_MAPPING;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
@@ -197,8 +205,6 @@ static int rockchip_vpu_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->jpeg_quality = ctrl->val;
break;
default:
- vpu_err("Invalid control id = %d, val = %d\n",
- ctrl->id, ctrl->val);
return -EINVAL;
}
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
index 6aadd194e999..3dbd15d5fabe 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
@@ -142,7 +142,7 @@ rockchip_vpu_get_default_fmt(struct rockchip_vpu_ctx *ctx,
bool bitstream)
formats = dev->variant->enc_fmts;
num_fmts = dev->variant->num_enc_fmts;
for (i = 0; i < num_fmts; i++) {
- if (bitstream == formats[i].codec_mode != RK_VPU_MODE_NONE)
+ if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
return [i];
}
return NULL;
[ragnatech:media-tree 198/228] arch/arm/include/asm/irq.h:35:50: error: unknown type name 'cpumask_t'
tree: git://git.ragnatech.se/linux media-tree head: da2c94c8f9739e4099ea3cfefc208fc721b22a9c commit: b6973637c4cc842c1aa7d6c848781b4bdeb4415b [198/228] media: ddbridge: remove another duplicate of io.h and sort includes config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout b6973637c4cc842c1aa7d6c848781b4bdeb4415b # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm All errors (new ones prefixed by >>): In file included from drivers/media/pci/ddbridge/ddbridge.h:22:0, from drivers/media/pci/ddbridge/ddbridge-hw.c:19: >> arch/arm/include/asm/irq.h:35:50: error: unknown type name 'cpumask_t' extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask, ^ >> arch/arm/include/asm/irq.h:36:9: error: unknown type name 'bool'; did you >> mean '_Bool'? bool exclude_self); ^~~~ _Bool vim +/cpumask_t +35 arch/arm/include/asm/irq.h 446616db Russell King 2008-09-06 33 96f0e003 Russell King 2014-09-03 34 #ifdef CONFIG_SMP 9a01c3ed Chris Metcalf 2016-10-07 @35 extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask, 9a01c3ed Chris Metcalf 2016-10-07 @36 bool exclude_self); 9a01c3ed Chris Metcalf 2016-10-07 37 #define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace 96f0e003 Russell King 2014-09-03 38 #endif 96f0e003 Russell King 2014-09-03 39 :: The code at line 35 was first introduced by commit :: 9a01c3ed5cdb35d9004eb92510ee6ea11b4a5f16 nmi_backtrace: add more trigger_*_cpu_backtrace() methods :: TO: Chris Metcalf :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote: > Unless something unexpected happens, then v12 should be the final > version and I'll make a pull request for it. Note that it will > probably won't make 4.20, unless you manage to do it within the next > hour :-) Challenge accepted!
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
On 11/30/18 18:34, Ezequiel Garcia wrote:
> Add a mem2mem driver for the VPU available on Rockchip SoCs.
> Currently only JPEG encoding is supported, for RK3399 and RK3288
> platforms.
>
> Signed-off-by: Ezequiel Garcia
> ---
> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> new file mode 100644
> index ..f2752a0c71c0
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> @@ -0,0 +1,531 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip VPU codec driver
> + *
> + * Copyright (C) 2018 Collabora, Ltd.
> + * Copyright 2018 Google LLC.
> + * Tomasz Figa
> + *
> + * Based on s5p-mfc driver by Samsung Electronics Co., Ltd.
> + * Copyright (C) 2011 Samsung Electronics Co., Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rockchip_vpu_common.h"
> +#include "rockchip_vpu.h"
> +#include "rockchip_vpu_hw.h"
> +
> +#define DRIVER_NAME "rockchip-vpu"
> +
> +int rockchip_vpu_debug;
> +module_param_named(debug, rockchip_vpu_debug, int, 0644);
> +MODULE_PARM_DESC(debug,
> + "Debug level - higher value produces more verbose messages");
> +
> +static void rockchip_vpu_job_finish(struct rockchip_vpu_dev *vpu,
> + struct rockchip_vpu_ctx *ctx,
> + unsigned int bytesused,
> + enum vb2_buffer_state result)
> +{
> + struct vb2_v4l2_buffer *src, *dst;
> + size_t avail_size;
> +
> + pm_runtime_mark_last_busy(vpu->dev);
> + pm_runtime_put_autosuspend(vpu->dev);
> + clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks);
> +
> + src = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + dst = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> +
> + if (WARN_ON(!src))
> + return;
> + if (WARN_ON(!dst))
> + return;
> +
> + src->sequence = ctx->sequence_out++;
> + dst->sequence = ctx->sequence_cap++;
> +
> + dst->field = src->field;
> + if (dst->flags & V4L2_BUF_FLAG_TIMECODE)
That should be src->flags
> + dst->timecode = src->timecode;
> + dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
> + dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
> + dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
And this should clear and copy V4L2_BUF_FLAG_TIMECODE as well.
> +
> + avail_size = vb2_plane_size(>vb2_buf, 0) -
> + ctx->vpu_dst_fmt->header_size;
> + if (bytesused <= avail_size) {
> + if (ctx->bounce_buf) {
> + memcpy(vb2_plane_vaddr(>vb2_buf, 0) +
> +ctx->vpu_dst_fmt->header_size,
> +ctx->bounce_buf, bytesused);
> + }
> + dst->vb2_buf.planes[0].bytesused =
> + ctx->vpu_dst_fmt->header_size + bytesused;
> + } else {
> + result = VB2_BUF_STATE_ERROR;
> + }
> +
> + v4l2_m2m_buf_done(src, result);
> + v4l2_m2m_buf_done(dst, result);
> +
> + v4l2_m2m_job_finish(vpu->m2m_dev, ctx->fh.m2m_ctx);
> +}
> +
> +void rockchip_vpu_irq_done(struct rockchip_vpu_dev *vpu,
> +unsigned int bytesused,
> +enum vb2_buffer_state result)
> +{
> + struct rockchip_vpu_ctx *ctx =
> + v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> +
> + /*
> + * If cancel_delayed_work returns false
> + * the timeout expired. The watchdog is running,
> + * and will take care of finishing the job.
> + */
> + if (cancel_delayed_work(>watchdog_work))
> + rockchip_vpu_job_finish(vpu, ctx, bytesused, result);
> +}
> +
> +void rockchip_vpu_watchdog(struct work_struct *work)
> +{
> + struct rockchip_vpu_dev *vpu;
> + struct rockchip_vpu_ctx *ctx;
> +
> + vpu = container_of(to_delayed_work(work),
> +struct rockchip_vpu_dev, watchdog_work);
> + ctx = v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> + if (ctx) {
> + vpu_err("frame processing timed out!\n");
> + ctx->codec_ops->reset(ctx);
> + rockchip_vpu_job_finish(vpu, ctx, 0, VB2_BUF_STATE_ERROR);
> + }
> +}
> +
> +static void device_run(void *priv)
> +{
> + struct rockchip_vpu_ctx *ctx = priv;
> + int ret;
> +
> + ret = clk_bulk_enable(ctx->dev->variant->num_clocks, ctx->dev->clocks);
> + if (ret)
> + goto err_cancel_job;
> + ret = pm_runtime_get_sync(ctx->dev->dev);
> + if (ret < 0)
> + goto err_cancel_job;
> +
> + ctx->codec_ops->run(ctx);
> + return;
> +
> +err_cancel_job:
> + rockchip_vpu_job_finish(ctx->dev, ctx, 0, VB2_BUF_STATE_ERROR);
> +}
> +
> +static struct v4l2_m2m_ops vpu_m2m_ops = {
> + .device_run = device_run,
Re: [PATCH 1/1] ipu3-cio2: Allow probe to succeed if there are no sensors connected
On Wed, Dec 05, 2018 at 04:15:17PM +0200, Sakari Ailus wrote: > The device won't be powered off on systems that have no sensors connected > unless it has a driver bound to it. Allow that to happen even if there are > no sensors connected to cio2. Thanks for sending this. It helps to put the pci device to suspend which otherwise remains active after the probe for cio2 fails. I have verified it on HP Elitebook that has BIOS/DSDT more suitable for Windows. > > Signed-off-by: Sakari Ailus Reviewed-and-tested-by: Rajneesh Bhardwaj > --- > drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c > b/drivers/media/pci/intel/ipu3/ipu3-cio2.c > index 447baaebca448..e281e55cdca4a 100644 > --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c > +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c > @@ -1810,7 +1810,8 @@ static int cio2_pci_probe(struct pci_dev *pci_dev, > > /* Register notifier for subdevices we care */ > r = cio2_notifier_init(cio2); > - if (r) > + /* Proceed without sensors connected to allow the device to suspend. */ > + if (r && r != -ENODEV) > goto fail_cio2_queue_exit; > > r = devm_request_irq(_dev->dev, pci_dev->irq, cio2_irq, > -- > 2.11.0 > -- Best Regards, Rajneesh
[PATCH 1/1] ipu3-cio2: Allow probe to succeed if there are no sensors connected
The device won't be powered off on systems that have no sensors connected unless it has a driver bound to it. Allow that to happen even if there are no sensors connected to cio2. Signed-off-by: Sakari Ailus --- drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c b/drivers/media/pci/intel/ipu3/ipu3-cio2.c index 447baaebca448..e281e55cdca4a 100644 --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c @@ -1810,7 +1810,8 @@ static int cio2_pci_probe(struct pci_dev *pci_dev, /* Register notifier for subdevices we care */ r = cio2_notifier_init(cio2); - if (r) + /* Proceed without sensors connected to allow the device to suspend. */ + if (r && r != -ENODEV) goto fail_cio2_queue_exit; r = devm_request_irq(_dev->dev, pci_dev->irq, cio2_irq, -- 2.11.0
[GIT FIXES FOR v4.20] cedrus: move control definitions to mpeg2-ctrls.h
This API is not stable enough yet to be exposed in the uAPI. Move it to a kAPI header. Regards, Hans The following changes since commit 708d75fe1c7c6e9abc5381b6fcc32b49830383d0: media: dvb-pll: don't re-validate tuner frequencies (2018-11-23 12:27:18 -0500) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21q2 for you to fetch changes up to f9a88dc4e8703bfa6a40229806fbb496e4111664: extended-controls.rst: add note to the MPEG2 state controls (2018-12-05 13:59:16 +0100) Tag branch Hans Verkuil (2): mpeg2-ctrls.h: move MPEG2 state controls to non-public header extended-controls.rst: add note to the MPEG2 state controls Documentation/media/uapi/v4l/extended-controls.rst | 10 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 4 +-- include/media/mpeg2-ctrls.h| 86 ++ include/media/v4l2-ctrls.h | 6 include/uapi/linux/v4l2-controls.h | 68 -- include/uapi/linux/videodev2.h | 4 --- 6 files changed, 104 insertions(+), 74 deletions(-) create mode 100644 include/media/mpeg2-ctrls.h
Re: [PATCH for v4.20 0/2] cedrus: move MPEG controls out of the uAPI
Hi, On Wed, 2018-12-05 at 13:09 +0100, hverkuil-ci...@xs4all.nl wrote: > From: Hans Verkuil > > The expectation was that the MPEG-2 state controls used by the staging > cedrus driver were stable, or would only require one final change. However, > it turns out that more changes are required, and that means that it is not > such a good idea to have these controls in the public kernel API. > > This patch series moves all the MPEG-2 state control data to a new > media/mpeg2-ctrls.h header. So none of this is available from the public > API. > > However, v4l2-ctrls.h includes it for now so the kAPI still knows about it > allowing the cedrus driver to use it without changes. > > The second patch adds a note to these two controls, mentioning that they > are likely to change. > > Moving forward, this allows us to take more time in getting the MPEG-2 > (and later H264/5) state controls right. Thanks a lot for this change, I'm glad we can take time to properly stabilize these controls! For the whole series: Reviewed-by: Paul Kocialkowski Cheers, Paul > Regards, > > Hans > > Hans Verkuil (2): > mpeg2-ctrls.h: move MPEG2 state controls to non-public header > extended-controls.rst: add note to the MPEG2 state controls > > .../media/uapi/v4l/extended-controls.rst | 10 +++ > drivers/media/v4l2-core/v4l2-ctrls.c | 4 +- > include/media/mpeg2-ctrls.h | 86 +++ > include/media/v4l2-ctrls.h| 6 ++ > include/uapi/linux/v4l2-controls.h| 68 --- > include/uapi/linux/videodev2.h| 4 - > 6 files changed, 104 insertions(+), 74 deletions(-) > create mode 100644 include/media/mpeg2-ctrls.h > -- Paul Kocialkowski, Bootlin (formerly Free Electrons) Embedded Linux and kernel engineering https://bootlin.com
Re: [PATCH 1/1] media: Add a Kconfig option for the Request API
On 12/05/18 13:24, Sakari Ailus wrote:
> The Request API is now merged to the kernel but the confidence on the
> stability of that API is not great, especially regarding the interaction
> with V4L2.
>
> Add a Kconfig option for the API, with a scary-looking warning.
>
> The patch itself disables request creation as well as does not advertise
> them as buffer flags. The driver requiring requests (cedrus) now depends
> on the Kconfig option as well.
>
> Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
> ---
> I hope this covers now everything... I was thinking how to make the option
> name itself more worrisome but I couldn't come up with a better language
> that would be compact enough. The "(EXPERIMENTAL)" notion is a bit too
> worn to be effective. :-I
>
> The patch can and should be reverted once we're entirely happy and
> confident with the API.
>
> drivers/media/Kconfig | 13 +
> drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
> drivers/media/media-device.c| 2 ++
> drivers/staging/media/sunxi/cedrus/Kconfig | 1 +
> 4 files changed, 18 insertions(+)
>
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..102eb35fcf3f 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
>
> This is currently experimental.
>
> +config MEDIA_CONTROLLER_REQUEST_API
> + bool "Enable Media controller Request API (EXPERIMENTAL)"
> + depends on MEDIA_CONTROLLER && STAGING_MEDIA
> + default n
> + ---help---
> + DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
> +
> + This option enables the Request API for the Media controller and V4L2
> + interfaces. It is currently needed by a few stateless codec drivers.
> +
> + There is currently no intention to provide API or ABI stability for
> + this new API as of yet.
> +
> #
> # Video4Linux support
> #Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1244c246d0c4..83c3c0c49e56 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
> *caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
> if (q->io_modes & VB2_DMABUF)
> *caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (q->supports_requests)
> *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
> +#endif
> }
>
> int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index bed24372e61f..2ef114ce38d0 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -381,7 +381,9 @@ static long media_device_get_topology(struct media_device
> *mdev, void *arg)
> static long media_device_request_alloc(struct media_device *mdev,
> int *alloc_fd)
> {
> +#ifndef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> +#endif
> return -ENOTTY;
>
> return media_request_alloc(mdev, alloc_fd);
> diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig
> b/drivers/staging/media/sunxi/cedrus/Kconfig
> index a7a34e89c42d..3252efa422f9 100644
> --- a/drivers/staging/media/sunxi/cedrus/Kconfig
> +++ b/drivers/staging/media/sunxi/cedrus/Kconfig
> @@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
> depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
> depends on HAS_DMA
> depends on OF
> + depends on MEDIA_CONTROLLER_REQUEST_API
> select SUNXI_SRAM
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
>
[PATCH 1/1] media: Add a Kconfig option for the Request API
The Request API is now merged to the kernel but the confidence on the
stability of that API is not great, especially regarding the interaction
with V4L2.
Add a Kconfig option for the API, with a scary-looking warning.
The patch itself disables request creation as well as does not advertise
them as buffer flags. The driver requiring requests (cedrus) now depends
on the Kconfig option as well.
Signed-off-by: Sakari Ailus
---
I hope this covers now everything... I was thinking how to make the option
name itself more worrisome but I couldn't come up with a better language
that would be compact enough. The "(EXPERIMENTAL)" notion is a bit too
worn to be effective. :-I
The patch can and should be reverted once we're entirely happy and
confident with the API.
drivers/media/Kconfig | 13 +
drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
drivers/media/media-device.c| 2 ++
drivers/staging/media/sunxi/cedrus/Kconfig | 1 +
4 files changed, 18 insertions(+)
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 8add62a18293..102eb35fcf3f 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
This is currently experimental.
+config MEDIA_CONTROLLER_REQUEST_API
+ bool "Enable Media controller Request API (EXPERIMENTAL)"
+ depends on MEDIA_CONTROLLER && STAGING_MEDIA
+ default n
+ ---help---
+ DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
+
+ This option enables the Request API for the Media controller and V4L2
+ interfaces. It is currently needed by a few stateless codec drivers.
+
+ There is currently no intention to provide API or ABI stability for
+ this new API as of yet.
+
#
# Video4Linux support
# Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 1244c246d0c4..83c3c0c49e56 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
*caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
if (q->io_modes & VB2_DMABUF)
*caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
+#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
if (q->supports_requests)
*caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
+#endif
}
int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index bed24372e61f..2ef114ce38d0 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -381,7 +381,9 @@ static long media_device_get_topology(struct media_device
*mdev, void *arg)
static long media_device_request_alloc(struct media_device *mdev,
int *alloc_fd)
{
+#ifndef CONFIG_MEDIA_CONTROLLER_REQUEST_API
if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
+#endif
return -ENOTTY;
return media_request_alloc(mdev, alloc_fd);
diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig
b/drivers/staging/media/sunxi/cedrus/Kconfig
index a7a34e89c42d..3252efa422f9 100644
--- a/drivers/staging/media/sunxi/cedrus/Kconfig
+++ b/drivers/staging/media/sunxi/cedrus/Kconfig
@@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
depends on HAS_DMA
depends on OF
+ depends on MEDIA_CONTROLLER_REQUEST_API
select SUNXI_SRAM
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
--
2.11.0
[PATCH for v4.20 2/2] extended-controls.rst: add note to the MPEG2 state controls
From: Hans Verkuil Add a note mentioning that these two controls are not part of the public API while they still stabilizing. Signed-off-by: Hans Verkuil --- Documentation/media/uapi/v4l/extended-controls.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index 65a1d873196b..027358b91082 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -1505,6 +1505,11 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - configuring a stateless hardware decoding pipeline for MPEG-2. The bitstream parameters are defined according to :ref:`mpeg2part2`. +.. note:: + + This compound control is not yet part of the public kernel API and + it is expected to change. + .. c:type:: v4l2_ctrl_mpeg2_slice_params .. cssclass:: longtable @@ -1625,6 +1630,11 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - Specifies quantization matrices (as extracted from the bitstream) for the associated MPEG-2 slice data. +.. note:: + + This compound control is not yet part of the public kernel API and + it is expected to change. + .. c:type:: v4l2_ctrl_mpeg2_quantization .. cssclass:: longtable -- 2.19.1
[PATCH for v4.20 0/2] cedrus: move MPEG controls out of the uAPI
From: Hans Verkuil The expectation was that the MPEG-2 state controls used by the staging cedrus driver were stable, or would only require one final change. However, it turns out that more changes are required, and that means that it is not such a good idea to have these controls in the public kernel API. This patch series moves all the MPEG-2 state control data to a new media/mpeg2-ctrls.h header. So none of this is available from the public API. However, v4l2-ctrls.h includes it for now so the kAPI still knows about it allowing the cedrus driver to use it without changes. The second patch adds a note to these two controls, mentioning that they are likely to change. Moving forward, this allows us to take more time in getting the MPEG-2 (and later H264/5) state controls right. Regards, Hans Hans Verkuil (2): mpeg2-ctrls.h: move MPEG2 state controls to non-public header extended-controls.rst: add note to the MPEG2 state controls .../media/uapi/v4l/extended-controls.rst | 10 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 4 +- include/media/mpeg2-ctrls.h | 86 +++ include/media/v4l2-ctrls.h| 6 ++ include/uapi/linux/v4l2-controls.h| 68 --- include/uapi/linux/videodev2.h| 4 - 6 files changed, 104 insertions(+), 74 deletions(-) create mode 100644 include/media/mpeg2-ctrls.h -- 2.19.1
[PATCH for v4.20 1/2] mpeg2-ctrls.h: move MPEG2 state controls to non-public header
From: Hans Verkuil
The MPEG2 state controls for the cedrus stateless MPEG2 driver are
not yet stable. Move them out of the public headers into media/mpeg2-ctrls.h.
Eventually, once this has stabilized, they will be moved back to the
public headers.
Unfortunately I had to cast the control type to a u32 in two switch
statements to prevent a compiler warning about a control type define
not being part of the enum.
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-ctrls.c | 4 +-
include/media/mpeg2-ctrls.h | 86
include/media/v4l2-ctrls.h | 6 ++
include/uapi/linux/v4l2-controls.h | 68 --
include/uapi/linux/videodev2.h | 4 --
5 files changed, 94 insertions(+), 74 deletions(-)
create mode 100644 include/media/mpeg2-ctrls.h
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5f2b033a7a42..10b8d94edbef 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1563,7 +1563,7 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32
idx,
u64 offset;
s64 val;
- switch (ctrl->type) {
+ switch ((u32)ctrl->type) {
case V4L2_CTRL_TYPE_INTEGER:
return ROUND_TO_RANGE(ptr.p_s32[idx], u32, ctrl);
case V4L2_CTRL_TYPE_INTEGER64:
@@ -2232,7 +2232,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
is_array = nr_of_dims > 0;
/* Prefill elem_size for all types handled by std_type_ops */
- switch (type) {
+ switch ((u32)type) {
case V4L2_CTRL_TYPE_INTEGER64:
elem_size = sizeof(s64);
break;
diff --git a/include/media/mpeg2-ctrls.h b/include/media/mpeg2-ctrls.h
new file mode 100644
index ..d21f40edc09e
--- /dev/null
+++ b/include/media/mpeg2-ctrls.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * These are the MPEG2 state controls for use with stateless MPEG-2
+ * codec drivers.
+ *
+ * It turns out that these structs are not stable yet and will undergo
+ * more changes. So keep them private until they are stable and ready to
+ * become part of the official public API.
+ */
+
+#ifndef _MPEG2_CTRLS_H_
+#define _MPEG2_CTRLS_H_
+
+#define V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (V4L2_CID_MPEG_BASE+250)
+#define V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION (V4L2_CID_MPEG_BASE+251)
+
+/* enum v4l2_ctrl_type type values */
+#define V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS 0x0103
+#defineV4L2_CTRL_TYPE_MPEG2_QUANTIZATION 0x0104
+
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_I 1
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_P 2
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_B 3
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_D 4
+
+struct v4l2_mpeg2_sequence {
+ /* ISO/IEC 13818-2, ITU-T Rec. H.262: Sequence header */
+ __u16 horizontal_size;
+ __u16 vertical_size;
+ __u32 vbv_buffer_size;
+
+ /* ISO/IEC 13818-2, ITU-T Rec. H.262: Sequence extension */
+ __u8profile_and_level_indication;
+ __u8progressive_sequence;
+ __u8chroma_format;
+ __u8pad;
+};
+
+struct v4l2_mpeg2_picture {
+ /* ISO/IEC 13818-2, ITU-T Rec. H.262: Picture header */
+ __u8picture_coding_type;
+
+ /* ISO/IEC 13818-2, ITU-T Rec. H.262: Picture coding extension */
+ __u8f_code[2][2];
+ __u8intra_dc_precision;
+ __u8picture_structure;
+ __u8top_field_first;
+ __u8frame_pred_frame_dct;
+ __u8concealment_motion_vectors;
+ __u8q_scale_type;
+ __u8intra_vlc_format;
+ __u8alternate_scan;
+ __u8repeat_first_field;
+ __u8progressive_frame;
+ __u8pad;
+};
+
+struct v4l2_ctrl_mpeg2_slice_params {
+ __u32 bit_size;
+ __u32 data_bit_offset;
+
+ struct v4l2_mpeg2_sequence sequence;
+ struct v4l2_mpeg2_picture picture;
+
+ /* ISO/IEC 13818-2, ITU-T Rec. H.262: Slice */
+ __u8quantiser_scale_code;
+
+ __u8backward_ref_index;
+ __u8forward_ref_index;
+ __u8pad;
+};
+
+struct v4l2_ctrl_mpeg2_quantization {
+ /* ISO/IEC 13818-2, ITU-T Rec. H.262: Quant matrix extension */
+ __u8load_intra_quantiser_matrix;
+ __u8load_non_intra_quantiser_matrix;
+ __u8load_chroma_intra_quantiser_matrix;
+ __u8load_chroma_non_intra_quantiser_matrix;
+
+ __u8intra_quantiser_matrix[64];
+ __u8non_intra_quantiser_matrix[64];
+ __u8chroma_intra_quantiser_matrix[64];
+ __u8chroma_non_intra_quantiser_matrix[64];
+};
+
+#endif
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 83ce0593b275..d63cf227b0ab 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -22,6 +22,12 @@
#include
#include
+/*
+ * Include the mpeg2
[GIT PULL FOR v4.21] vicodec cleanup
The following changes since commit b2e9a4eda11fd2cb1e6714e9ad3f455c402568ff:
media: firewire: Fix app_info parameter type in avc_ca{,_app}_info
(2018-12-05 05:34:33 -0500)
are available in the Git repository at:
git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21h
for you to fetch changes up to a1e9f0504e413d4ae9f7e8879be59253f676f429:
media: vicodec: Change variable names (2018-12-05 12:44:42 +0100)
Tag branch
Dafna Hirschfeld (1):
media: vicodec: Change variable names
drivers/media/platform/vicodec/vicodec-core.c | 94
---
1 file changed, 48 insertions(+), 46 deletions(-)
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Sun, 21 Oct 2018 15:45:39 +0200
Markus Dobel escreveu:
> The original commit (the one reverted in this patch) introduced a
> regression,
> making a previously flawless adapter unresponsive after running a few
> hours
> to days. Since I never experienced the problems that the original commit
> is
> supposed to fix, I propose to revert the change until a regression-free
> variant is found.
>
> Before submitting this, I've been running a system 24x7 with this revert
> for
> several weeks now, and it's running stable again.
>
> It's not a pure revert, as the original commit does not revert cleanly
> anymore due to other changes, but content-wise it is.
>
> Signed-off-by: Markus Dobel
> ---
> drivers/media/pci/cx23885/cx23885-core.c | 60
> drivers/media/pci/cx23885/cx23885-reg.h | 14 --
> 2 files changed, 74 deletions(-)
>
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 39804d830305..606f6fc0e68b 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -601,25 +601,6 @@ static void cx23885_risc_disasm(struct
> cx23885_tsport *port,
Patch was mangled by your e-mailer: it broke longer lines, causing
it to not apply.
Also, before just reverting the entire thing, could you please check
if the enclosed hack would solve it?
If so, it should be easy to add a quirk at drivers/pci/quirks.c
in order to detect the Ryzen models with a bad DMA engine that
require periodic resets, and then make cx23885 to use it.
We did similar tricks before with some broken DMA engines, at
the time we had overlay support on drivers and AMD controllers
didn't support PCI2PCI DMA transfers.
Brad,
Could you please address this issue?
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 39804d830305..8b012bee6b32 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -603,8 +603,14 @@ static void cx23885_risc_disasm(struct cx23885_tsport
*port,
static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
{
- uint32_t reg1_val = cx_read(TC_REQ); /* read-only */
- uint32_t reg2_val = cx_read(TC_REQ_SET);
+ uint32_t reg1_val, reg2_val;
+
+ /* TODO: check for Ryzen quirk */
+ if (1)
+ return;
+
+ reg1_val = cx_read(TC_REQ); /* read-only */
+ reg2_val = cx_read(TC_REQ_SET);
if (reg1_val && reg2_val) {
cx_write(TC_REQ, reg1_val);
Thanks,
Mauro
[GIT PULL for 4.21] More sensor driver patches
Hi Mauro,
Here are improvements for various sensor drivers for 4.21. There area few
trivial V4L2 fwnode and async framework changes as well, plus DT binding
documentation for mt9m111.
Please pull.
The following changes since commit 9b90dc85c718443a3e573a0ccf55900ff4fa73ae:
media: seco-cec: add missing header file to fix build (2018-12-03 15:11:00
-0500)
are available in the git repository at:
ssh://linuxtv.org/git/sailus/media_tree.git tags/for-4.21-4-sign
for you to fetch changes up to bf8da26398f03704bbf7bb10b9c847fd187f4260:
v4l2: async: remove locking when initializing async notifier (2018-12-05
12:10:24 +0200)
sensor driver patches and stuff for 4.21
Bingbu Cao (3):
media: imx319: fix wrong order in test pattern menus
media: imx355: fix wrong order in test pattern menus
media: unify some sony camera sensors pattern naming
Enrico Scholz (1):
media: mt9m111: allow to setup pixclk polarity
Fabio Estevam (1):
media: v4l2-fwnode: Demote warning to debug level
Jacopo Mondi (1):
media: ov5640: Fix set format regression
Luca Ceresoli (3):
media: imx274: fix stack corruption in imx274_read_reg
media: imx274: declare the correct number of controls
media: imx274: select REGMAP_I2C
Marco Felsch (3):
media: mt9m111: add s_stream callback
dt-bindings: media: mt9m111: adapt documentation to be more clear
dt-bindings: media: mt9m111: add pclk-sample property
Maxime Ripard (11):
media: ov5640: Adjust the clock based on the expected rate
media: ov5640: Remove the clocks registers initialization
media: ov5640: Remove redundant defines
media: ov5640: Remove redundant register setup
media: ov5640: Compute the clock rate at runtime
media: ov5640: Remove pixel clock rates
media: ov5640: Enhance FPS handling
media: ov5640: Make the return rate type more explicit
media: ov5640: Make the FPS clamping / rounding more extendable
media: ov5640: Add 60 fps support
media: ov5640: Remove duplicate auto-exposure setup
Michael Grzeschik (2):
media: mt9m111: add streaming check to set_fmt
media: mt9m111: add support to select formats and fps for {Q,SXGA}
Niklas Söderlund (1):
v4l2: async: remove locking when initializing async notifier
.../devicetree/bindings/media/i2c/mt9m111.txt | 13 +-
drivers/media/i2c/Kconfig | 2 +
drivers/media/i2c/imx258.c | 8 +-
drivers/media/i2c/imx274.c | 9 +-
drivers/media/i2c/imx319.c | 8 +-
drivers/media/i2c/imx355.c | 8 +-
drivers/media/i2c/mt9m111.c| 222 +-
drivers/media/i2c/ov5640.c | 764 -
drivers/media/v4l2-core/v4l2-async.c | 4 -
drivers/media/v4l2-core/v4l2-fwnode.c | 2 +-
10 files changed, 703 insertions(+), 337 deletions(-)
--
Regards,
Sakari Ailus
[PATCHv4 11/10] extended-controls.rst: update the mpeg2 compound controls
The layout of the compound controls has changed to fix 32/64 bit alignment issues and the use of tags instead of buffer indices to refer to buffers. Note that these controls are only used by the cedrus staging driver. Signed-off-by: Hans Verkuil --- .../media/uapi/v4l/extended-controls.rst | 24 ++- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index 65a1d873196b..b9e3af29a704 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -1528,17 +1528,19 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - - ``picture`` - Structure with MPEG-2 picture metadata, merging relevant fields from the picture header and picture coding extension parts of the bitstream. -* - __u8 +* - __u32 + - ``backward_ref_tag`` + - Tag for the V4L2 buffer to use as backward reference, used with + B-coded and P-coded frames. The tag refers to the ``tag`` field in + struct :c:type:`v4l2_buffer`. +* - __u32 + - ``forward_ref_tag`` + - Tag for the V4L2 buffer to use as forward reference, used with + B-coded frames. The tag refers to the ``tag`` field in + struct :c:type:`v4l2_buffer`. +* - __u32 - ``quantiser_scale_code`` - Code used to determine the quantization scale to use for the IDCT. -* - __u8 - - ``backward_ref_index`` - - Index for the V4L2 buffer to use as backward reference, used with - B-coded and P-coded frames. -* - __u8 - - ``forward_ref_index`` - - Index for the V4L2 buffer to use as forward reference, used with - B-coded frames. .. c:type:: v4l2_mpeg2_sequence @@ -1559,7 +1561,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - - ``vbv_buffer_size`` - Used to calculate the required size of the video buffering verifier, defined (in bits) as: 16 * 1024 * vbv_buffer_size. -* - __u8 +* - __u16 - ``profile_and_level_indication`` - The current profile and level indication as extracted from the bitstream. @@ -1617,7 +1619,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - * - __u8 - ``repeat_first_field`` - This flag affects the decoding process of progressive frames. -* - __u8 +* - __u16 - ``progressive_frame`` - Indicates whether the current frame is progressive. -- 2.19.1
[PATCHv4 05/10] buffer.rst: clean up timecode documentation
From: Hans Verkuil V4L2_BUF_FLAG_TIMECODE is not video capture specific, so drop that part. The 'Timecodes' section was a bit messy, so that's cleaned up. Signed-off-by: Hans Verkuil Reviewed-by: Paul Kocialkowski Reviewed-by: Alexandre Courbot --- Documentation/media/uapi/v4l/buffer.rst | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index f83ee00cb30b..359b131a212d 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -223,8 +223,7 @@ struct v4l2_buffer * - struct :c:type:`v4l2_timecode` - ``timecode`` - - - When ``type`` is ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` and the - ``V4L2_BUF_FLAG_TIMECODE`` flag is set in ``flags``, this + - When the ``V4L2_BUF_FLAG_TIMECODE`` flag is set in ``flags``, this structure contains a frame timecode. In :c:type:`V4L2_FIELD_ALTERNATE ` mode the top and bottom field contain the same timecode. Timecodes are intended to @@ -715,10 +714,10 @@ enum v4l2_memory Timecodes = -The struct :c:type:`v4l2_timecode` structure is designed to hold a -:ref:`smpte12m` or similar timecode. (struct -struct :c:type:`timeval` timestamps are stored in struct -:c:type:`v4l2_buffer` field ``timestamp``.) +The :c:type:`v4l2_buffer_timecode` structure is designed to hold a +:ref:`smpte12m` or similar timecode. +(struct :c:type:`timeval` timestamps are stored in the struct +:c:type:`v4l2_buffer` ``timestamp`` field.) .. c:type:: v4l2_timecode -- 2.19.1
[PATCHv4 02/10] vb2: add tag support
From: Hans Verkuil
Add support for tags to vb2. Besides just storing and setting
the tag this patch also adds the vb2_find_tag() function that
can be used to find a buffer with the given tag.
This function will only look at DEQUEUED and DONE buffers, i.e.
buffers that are already processed.
Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Reviewed-by: Alexandre Courbot
---
.../media/common/videobuf2/videobuf2-v4l2.c | 39 ---
include/media/videobuf2-v4l2.h| 21 +-
2 files changed, 53 insertions(+), 7 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 1244c246d0c4..e0e31e1c67c9 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -50,7 +50,8 @@ module_param(debug, int, 0644);
V4L2_BUF_FLAG_TIMESTAMP_MASK)
/* Output buffer flags that should be passed on to the driver */
#define V4L2_BUFFER_OUT_FLAGS (V4L2_BUF_FLAG_PFRAME | V4L2_BUF_FLAG_BFRAME | \
-V4L2_BUF_FLAG_KEYFRAME |
V4L2_BUF_FLAG_TIMECODE)
+V4L2_BUF_FLAG_KEYFRAME | \
+V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG)
/*
* __verify_planes_array() - verify that the planes array passed in struct
@@ -144,7 +145,10 @@ static void __copy_timestamp(struct vb2_buffer *vb, const
void *pb)
*/
if (q->copy_timestamp)
vb->timestamp = timeval_to_ns(>timestamp);
- vbuf->flags |= b->flags & V4L2_BUF_FLAG_TIMECODE;
+ vbuf->flags |= b->flags &
+ (V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG);
+ if (b->flags & V4L2_BUF_FLAG_TAG)
+ vbuf->tag = b->tag;
if (b->flags & V4L2_BUF_FLAG_TIMECODE)
vbuf->timecode = b->timecode;
}
@@ -194,6 +198,7 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b
}
vbuf->sequence = 0;
vbuf->request_fd = -1;
+ vbuf->tag = 0;
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
switch (b->memory) {
@@ -314,12 +319,12 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer
*vb, struct v4l2_buffer *b
if (V4L2_TYPE_IS_OUTPUT(b->type)) {
/*
-* For output buffers mask out the timecode flag:
-* this will be handled later in vb2_qbuf().
+* For output buffers mask out the timecode and tag flags:
+* these will be handled later in vb2_qbuf().
* The 'field' is valid metadata for this output buffer
* and so that needs to be copied here.
*/
- vbuf->flags &= ~V4L2_BUF_FLAG_TIMECODE;
+ vbuf->flags &= ~(V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG);
vbuf->field = b->field;
} else {
/* Zero any output buffer flags as this is a capture buffer */
@@ -460,7 +465,10 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void
*pb)
b->flags = vbuf->flags;
b->field = vbuf->field;
b->timestamp = ns_to_timeval(vb->timestamp);
- b->timecode = vbuf->timecode;
+ if (b->flags & V4L2_BUF_FLAG_TAG)
+ b->tag = vbuf->tag;
+ if (b->flags & V4L2_BUF_FLAG_TIMECODE)
+ b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
b->reserved2 = 0;
b->request_fd = 0;
@@ -586,6 +594,25 @@ static const struct vb2_buf_ops v4l2_buf_ops = {
.copy_timestamp = __copy_timestamp,
};
+int vb2_find_tag(const struct vb2_queue *q, u32 tag,
+unsigned int start_idx)
+{
+ unsigned int i;
+
+ for (i = start_idx; i < q->num_buffers; i++) {
+ struct vb2_buffer *vb = q->bufs[i];
+ struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+
+ if ((vb->state == VB2_BUF_STATE_DEQUEUED ||
+vb->state == VB2_BUF_STATE_DONE) &&
+ (vbuf->flags & V4L2_BUF_FLAG_TAG) &&
+ vbuf->tag == tag)
+ return i;
+ }
+ return -1;
+}
+EXPORT_SYMBOL_GPL(vb2_find_tag);
+
/*
* vb2_querybuf() - query video buffer information
* @q: videobuf queue
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 727855463838..c2a541af6b2c 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -31,8 +31,9 @@
* @field: field order of the image in the buffer, as defined by
* v4l2_field.
* @timecode: frame timecode.
+ * @tag: user specified buffer tag value.
* @sequence: sequence count of this frame.
- * @request_fd:the request_fd associated with this buffer
+ * @request_fd:
[PATCHv4 01/10] videodev2.h: add tag support
From: Hans Verkuil
Add support for 'tags' to struct v4l2_buffer. These can be used
by m2m devices so userspace can set a tag for an output buffer and
this value will then be copied to the capture buffer(s).
This tag can be used to refer to capture buffers, something that
is needed by stateless HW codecs.
The new V4L2_BUF_CAP_SUPPORTS_TAGS capability indicates whether
or not tags are supported.
Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Reviewed-by: Alexandre Courbot
---
include/uapi/linux/videodev2.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2db1635de956..9095d7abe10d 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -881,6 +881,7 @@ struct v4l2_requestbuffers {
#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
+#define V4L2_BUF_CAP_SUPPORTS_TAGS (1 << 5)
/**
* struct v4l2_plane - plane info for multi-planar buffers
@@ -940,6 +941,7 @@ struct v4l2_plane {
* @length:size in bytes of the buffer (NOT its payload) for single-plane
* buffers (when type != *_MPLANE); number of elements in the
* planes array for multi-plane buffers
+ * @tag: buffer tag
* @request_fd: fd of the request that this buffer should use
*
* Contains data exchanged by application and driver using one of the Streaming
@@ -964,7 +966,10 @@ struct v4l2_buffer {
__s32 fd;
} m;
__u32 length;
- __u32 reserved2;
+ union {
+ __u32 reserved2;
+ __u32 tag;
+ };
union {
__s32 request_fd;
__u32 reserved;
@@ -990,6 +995,8 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_IN_REQUEST 0x0080
/* timecode field is valid */
#define V4L2_BUF_FLAG_TIMECODE 0x0100
+/* tag field is valid */
+#define V4L2_BUF_FLAG_TAG 0x0200
/* Buffer is prepared for queuing */
#define V4L2_BUF_FLAG_PREPARED 0x0400
/* Cache handling flags */
--
2.19.1
[PATCHv4 08/10] vim2m: add tag support
From: Hans Verkuil
Copy tags in vim2m.
Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Reviewed-by: Alexandre Courbot
---
drivers/media/platform/vim2m.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index d01821a6906a..be328483a53a 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -241,17 +241,7 @@ static int device_process(struct vim2m_ctx *ctx,
out_vb->sequence =
get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE)->sequence++;
in_vb->sequence = q_data->sequence++;
- out_vb->vb2_buf.timestamp = in_vb->vb2_buf.timestamp;
-
- if (in_vb->flags & V4L2_BUF_FLAG_TIMECODE)
- out_vb->timecode = in_vb->timecode;
- out_vb->field = in_vb->field;
- out_vb->flags = in_vb->flags &
- (V4L2_BUF_FLAG_TIMECODE |
-V4L2_BUF_FLAG_KEYFRAME |
-V4L2_BUF_FLAG_PFRAME |
-V4L2_BUF_FLAG_BFRAME |
-V4L2_BUF_FLAG_TSTAMP_SRC_MASK);
+ v4l2_m2m_buf_copy_data(out_vb, in_vb, true);
switch (ctx->mode) {
case MEM2MEM_HFLIP | MEM2MEM_VFLIP:
@@ -855,6 +845,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *ds
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock = >dev->dev_mutex;
src_vq->supports_requests = true;
+ src_vq->supports_tags = true;
ret = vb2_queue_init(src_vq);
if (ret)
@@ -868,6 +859,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *ds
dst_vq->mem_ops = _vmalloc_memops;
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock = >dev->dev_mutex;
+ dst_vq->supports_tags = true;
return vb2_queue_init(dst_vq);
}
--
2.19.1
[PATCHv4 10/10] cedrus: add tag support
From: Hans Verkuil
Replace old reference frame indices by new tag method.
Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Reviewed-by: Alexandre Courbot
---
drivers/media/v4l2-core/v4l2-ctrls.c | 9
drivers/staging/media/sunxi/cedrus/cedrus.h | 9 +---
.../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
.../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 ---
.../staging/media/sunxi/cedrus/cedrus_video.c | 2 ++
include/uapi/linux/v4l2-controls.h| 14 +
6 files changed, 24 insertions(+), 33 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 129a986fa7e1..e859496e4e95 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1661,15 +1661,6 @@ static int std_validate(const struct v4l2_ctrl *ctrl,
u32 idx,
return -EINVAL;
}
- if (p_mpeg2_slice_params->backward_ref_index >= VIDEO_MAX_FRAME
||
- p_mpeg2_slice_params->forward_ref_index >= VIDEO_MAX_FRAME)
- return -EINVAL;
-
- if (p_mpeg2_slice_params->pad ||
- p_mpeg2_slice_params->picture.pad ||
- p_mpeg2_slice_params->sequence.pad)
- return -EINVAL;
-
return 0;
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 3f61248c57ac..781676b55a1b 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -142,11 +142,14 @@ static inline dma_addr_t cedrus_buf_addr(struct
vb2_buffer *buf,
}
static inline dma_addr_t cedrus_dst_buf_addr(struct cedrus_ctx *ctx,
-unsigned int index,
-unsigned int plane)
+int index, unsigned int plane)
{
- struct vb2_buffer *buf = ctx->dst_bufs[index];
+ struct vb2_buffer *buf;
+ if (index < 0)
+ return 0;
+
+ buf = ctx->dst_bufs[index];
return buf ? cedrus_buf_addr(buf, >dst_fmt, plane) : 0;
}
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..0cfd6036d0cd 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -53,6 +53,8 @@ void cedrus_device_run(void *priv)
break;
}
+ v4l2_m2m_buf_copy_data(run.src, run.dst, true);
+
dev->dec_ops[ctx->current_codec]->setup(ctx, );
spin_unlock_irqrestore(>dev->irq_lock, flags);
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
index 9abd39cae38c..fdde9a099153 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
@@ -82,7 +82,10 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
struct cedrus_run *run)
dma_addr_t fwd_luma_addr, fwd_chroma_addr;
dma_addr_t bwd_luma_addr, bwd_chroma_addr;
struct cedrus_dev *dev = ctx->dev;
+ struct vb2_queue *cap_q = >fh.m2m_ctx->cap_q_ctx.q;
const u8 *matrix;
+ int forward_idx;
+ int backward_idx;
unsigned int i;
u32 reg;
@@ -156,23 +159,17 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
struct cedrus_run *run)
cedrus_write(dev, VE_DEC_MPEG_PICBOUNDSIZE, reg);
/* Forward and backward prediction reference buffers. */
+ forward_idx = vb2_find_tag(cap_q, slice_params->forward_ref_tag, 0);
- fwd_luma_addr = cedrus_dst_buf_addr(ctx,
- slice_params->forward_ref_index,
- 0);
- fwd_chroma_addr = cedrus_dst_buf_addr(ctx,
- slice_params->forward_ref_index,
- 1);
+ fwd_luma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 0);
+ fwd_chroma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 1);
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_LUMA_ADDR, fwd_luma_addr);
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_CHROMA_ADDR, fwd_chroma_addr);
- bwd_luma_addr = cedrus_dst_buf_addr(ctx,
- slice_params->backward_ref_index,
- 0);
- bwd_chroma_addr = cedrus_dst_buf_addr(ctx,
- slice_params->backward_ref_index,
- 1);
+ backward_idx = vb2_find_tag(cap_q, slice_params->backward_ref_tag, 0);
+ bwd_luma_addr = cedrus_dst_buf_addr(ctx, backward_idx, 0);
+ bwd_chroma_addr =
[PATCHv4 00/10] As was discussed here (among other places):
From: Hans Verkuil https://lkml.org/lkml/2018/10/19/440 using capture queue buffer indices to refer to reference frames is not a good idea. A better idea is to use a 'tag' where the application can assign a u32 tag to an output buffer, which is then copied to the capture buffer(s) derived from the output buffer. It has been suggested that the timestamp can be used for this. But there are a number of reasons why this is a bad idea: 1) the struct timeval is converted to a u64 in vb2. So there can be all sorts of unexpected conversion issues. In particular, the output of ns_to_timeval(timeval_to_ns(tv)) does not necessarily match the input. 2) it gets worse with the y2038 code where userspace either deals with a 32 bit tv_sec value or a 64 bit value. In other words, using timestamp for this is not a good idea. This implementation adds a new tag field in a union with the reserved2 field. The interpretation of that union depends on the flags field, so it still can be used for other things as well. In addition, in the previous patches the tag was in a union with the timecode field (again determined by the flags field), so if we need to cram additional information in this struct we can always put it in a union with the timecode field as well. It worked for the tag, it should work for other things. But we really need to start looking at a struct v4l2_ext_buffer. The first three patches add core tag support, the next two patches document the tag support, then a new helper function is added to v4l2-mem2mem.c to easily copy data from a source to a destination buffer that drivers can use. Next a new supports_tags vb2_queue flag is added to indicate that the driver supports tags. Ideally this should not be necessary, but that would require that all m2m drivers are converted to using the new helper function introduced in the previous patch. That takes more time then I have now. Finally the vim2m, vicodec and cedrus drivers are converted to support tags. I also removed the 'pad' fields from the mpeg2 control structs (it should never been added in the first place) and aligned the structs to a u32 boundary. Note that this might change further (Paul suggested using bitfields). Also note that the cedrus code doesn't set the sequence counter, that's something that should still be added before this driver can be moved out of staging. Note: if no buffer is found for a certain tag, then the dma address is just set to 0. That happened before as well with invalid buffer indices. This should be checked in the driver! Regards, Hans Changes since v3: - use reserved2 for the tag - split the documentation in two: one documenting the tag, one cleaning up the timecode documentation. Changes since v2: - rebased - added Reviewed-by tags - fixed a few remaining references in the documentation to the old v4l2_buffer_tag struct that was used in early versions of this series. Changes since v1: - changed to a u32 tag. Using a 64 bit tag was overly complicated due to the bad layout of the v4l2_buffer struct, and there is no real need for it by applications. Main changes since the RFC: - Added new buffer capability flag - Added m2m helper to copy data between buffers - Added documentation - Added tag logging in v4l2-ioctl.c Hans Verkuil (10): videodev2.h: add tag support vb2: add tag support v4l2-ioctl.c: log v4l2_buffer tag buffer.rst: document the new buffer tag feature. buffer.rst: clean up timecode documentation v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function vb2: add new supports_tags queue flag vim2m: add tag support vicodec: add tag support cedrus: add tag support Documentation/media/uapi/v4l/buffer.rst | 28 + .../media/uapi/v4l/vidioc-reqbufs.rst | 4 ++ .../media/common/videobuf2/videobuf2-v4l2.c | 41 --- drivers/media/platform/vicodec/vicodec-core.c | 14 ++- drivers/media/platform/vim2m.c| 14 ++- drivers/media/v4l2-core/v4l2-ctrls.c | 9 drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++-- drivers/media/v4l2-core/v4l2-mem2mem.c| 23 +++ drivers/staging/media/sunxi/cedrus/cedrus.h | 9 ++-- .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 + .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 -- .../staging/media/sunxi/cedrus/cedrus_video.c | 2 + include/media/v4l2-mem2mem.h | 21 ++ include/media/videobuf2-core.h| 2 + include/media/videobuf2-v4l2.h| 21 +- include/uapi/linux/v4l2-controls.h| 14 +++ include/uapi/linux/videodev2.h| 9 +++- 17 files changed, 168 insertions(+), 75 deletions(-) -- 2.19.1
[PATCHv4 06/10] v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function
From: Hans Verkuil
Memory-to-memory devices should copy various parts of
struct v4l2_buffer from the output buffer to the capture buffer.
Add a helper function that does that to simplify the driver code.
Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Reviewed-by: Alexandre Courbot
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 23 +++
include/media/v4l2-mem2mem.h | 21 +
2 files changed, 44 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 5bbdec55b7d7..a9cb1ac33dc0 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -975,6 +975,29 @@ void v4l2_m2m_buf_queue(struct v4l2_m2m_ctx *m2m_ctx,
}
EXPORT_SYMBOL_GPL(v4l2_m2m_buf_queue);
+void v4l2_m2m_buf_copy_data(const struct vb2_v4l2_buffer *out_vb,
+ struct vb2_v4l2_buffer *cap_vb,
+ bool copy_frame_flags)
+{
+ u32 mask = V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG |
+ V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+
+ if (copy_frame_flags)
+ mask |= V4L2_BUF_FLAG_KEYFRAME | V4L2_BUF_FLAG_PFRAME |
+ V4L2_BUF_FLAG_BFRAME;
+
+ cap_vb->vb2_buf.timestamp = out_vb->vb2_buf.timestamp;
+
+ if (out_vb->flags & V4L2_BUF_FLAG_TAG)
+ cap_vb->tag = out_vb->tag;
+ if (out_vb->flags & V4L2_BUF_FLAG_TIMECODE)
+ cap_vb->timecode = out_vb->timecode;
+ cap_vb->field = out_vb->field;
+ cap_vb->flags &= ~mask;
+ cap_vb->flags |= out_vb->flags & mask;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_buf_copy_data);
+
void v4l2_m2m_request_queue(struct media_request *req)
{
struct media_request_object *obj, *obj_safe;
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 5467264771ec..bb4feb6969d2 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -622,6 +622,27 @@ v4l2_m2m_dst_buf_remove_by_idx(struct v4l2_m2m_ctx
*m2m_ctx, unsigned int idx)
return v4l2_m2m_buf_remove_by_idx(_ctx->cap_q_ctx, idx);
}
+/**
+ * v4l2_m2m_buf_copy_data() - copy buffer data from the output buffer to the
+ * capture buffer
+ *
+ * @out_vb: the output buffer that is the source of the data.
+ * @cap_vb: the capture buffer that will receive the data.
+ * @copy_frame_flags: copy the KEY/B/PFRAME flags as well.
+ *
+ * This helper function copies the timestamp, timecode (if the TIMECODE
+ * buffer flag was set), tag (if the TAG buffer flag was set), field
+ * and the TIMECODE, TAG, KEYFRAME, BFRAME, PFRAME and TSTAMP_SRC_MASK
+ * flags from @out_vb to @cap_vb.
+ *
+ * If @copy_frame_flags is false, then the KEYFRAME, BFRAME and PFRAME
+ * flags are not copied. This is typically needed for encoders that
+ * set this bits explicitly.
+ */
+void v4l2_m2m_buf_copy_data(const struct vb2_v4l2_buffer *out_vb,
+ struct vb2_v4l2_buffer *cap_vb,
+ bool copy_frame_flags);
+
/* v4l2 request helper */
void v4l2_m2m_request_queue(struct media_request *req);
--
2.19.1
[PATCHv4 03/10] v4l2-ioctl.c: log v4l2_buffer tag
From: Hans Verkuil When debugging is on, log the new tag field of struct v4l2_buffer as well. Signed-off-by: Hans Verkuil Reviewed-by: Paul Kocialkowski Reviewed-by: Alexandre Courbot --- drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index b9616b1f227b..07c6c939a23c 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -498,9 +498,12 @@ static void v4l_print_buffer(const void *arg, bool write_only) p->bytesused, p->m.userptr, p->length); } - printk(KERN_DEBUG "timecode=%02d:%02d:%02d type=%d, flags=0x%08x, frames=%d, userbits=0x%08x\n", - tc->hours, tc->minutes, tc->seconds, - tc->type, tc->flags, tc->frames, *(__u32 *)tc->userbits); + if (p->flags & V4L2_BUF_FLAG_TAG) + printk(KERN_DEBUG "tag=%x\n", p->tag); + if (p->flags & V4L2_BUF_FLAG_TIMECODE) + printk(KERN_DEBUG "timecode=%02d:%02d:%02d type=%d, flags=0x%08x, frames=%d, userbits=0x%08x\n", + tc->hours, tc->minutes, tc->seconds, + tc->type, tc->flags, tc->frames, *(__u32 *)tc->userbits); } static void v4l_print_exportbuffer(const void *arg, bool write_only) -- 2.19.1
[PATCHv4 07/10] vb2: add new supports_tags queue flag
From: Hans Verkuil
Add new flag to indicate that buffer tags are supported.
Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Reviewed-by: Alexandre Courbot
---
drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
include/media/videobuf2-core.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index e0e31e1c67c9..5aa5b1ea90a8 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -659,6 +659,8 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
*caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
if (q->supports_requests)
*caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
+ if (q->supports_tags)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_TAGS;
}
int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index e86981d615ae..81f2dbfd0094 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -473,6 +473,7 @@ struct vb2_buf_ops {
* has not been called. This is a vb1 idiom that has been adopted
* also by vb2.
* @supports_requests: this queue supports the Request API.
+ * @supports_tags: this queue supports tags in struct v4l2_buffer.
* @uses_qbuf: qbuf was used directly for this queue. Set to 1 the first
* time this is called. Set to 0 when the queue is canceled.
* If this is 1, then you cannot queue buffers from a request.
@@ -547,6 +548,7 @@ struct vb2_queue {
unsignedallow_zero_bytesused:1;
unsigned quirk_poll_must_check_waiting_for_buffers:1;
unsignedsupports_requests:1;
+ unsignedsupports_tags:1;
unsigneduses_qbuf:1;
unsigneduses_requests:1;
--
2.19.1
[PATCHv4 04/10] buffer.rst: document the new buffer tag feature.
From: Hans Verkuil Document V4L2_BUF_FLAG_TAG. Signed-off-by: Hans Verkuil Reviewed-by: Paul Kocialkowski Reviewed-by: Alexandre Courbot --- Documentation/media/uapi/v4l/buffer.rst | 17 ++--- Documentation/media/uapi/v4l/vidioc-reqbufs.rst | 4 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index 2e266d32470a..f83ee00cb30b 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -301,10 +301,13 @@ struct v4l2_buffer elements in the ``planes`` array. The driver will fill in the actual number of valid elements in that array. * - __u32 - - ``reserved2`` + - ``tag`` - - - A place holder for future extensions. Drivers and applications - must set this to 0. + - When the ``V4L2_BUF_FLAG_TAG`` flag is set in ``flags``, this + field contains a user-specified tag value. + + It is used by stateless codecs where this tag can be used to + refer to buffers that contain reference frames. * - __u32 - ``request_fd`` - @@ -567,6 +570,14 @@ Buffer Flags when the ``VIDIOC_DQBUF`` ioctl is called. Applications can set this bit and the corresponding ``timecode`` structure when ``type`` refers to an output stream. +* .. _`V4L2-BUF-FLAG-TAG`: + + - ``V4L2_BUF_FLAG_TAG`` + - 0x0200 + - The ``tag`` field is valid. Applications can set + this bit and the corresponding ``tag`` field. If tags are + supported then the ``V4L2_BUF_CAP_SUPPORTS_TAGS`` capability + is also set. * .. _`V4L2-BUF-FLAG-PREPARED`: - ``V4L2_BUF_FLAG_PREPARED`` diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst index e62a15782790..38a7d0aee483 100644 --- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst +++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst @@ -118,6 +118,7 @@ aborting or finishing any DMA in progress, an implicit .. _V4L2-BUF-CAP-SUPPORTS-DMABUF: .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS: .. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS: +.. _V4L2-BUF-CAP-SUPPORTS-TAGS: .. cssclass:: longtable @@ -143,6 +144,9 @@ aborting or finishing any DMA in progress, an implicit - The kernel allows calling :ref:`VIDIOC_REQBUFS` while buffers are still mapped or exported via DMABUF. These orphaned buffers will be freed when they are unmapped or when the exported DMABUF fds are closed. +* - ``V4L2_BUF_CAP_SUPPORTS_TAGS`` + - 0x0020 + - This buffer type supports ``V4L2_BUF_FLAG_TAG``. Return Value -- 2.19.1
[PATCHv4 09/10] vicodec: add tag support
From: Hans Verkuil Copy tags in vicodec. Signed-off-by: Hans Verkuil Reviewed-by: Paul Kocialkowski Reviewed-by: Alexandre Courbot --- drivers/media/platform/vicodec/vicodec-core.c | 14 +++--- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/media/platform/vicodec/vicodec-core.c b/drivers/media/platform/vicodec/vicodec-core.c index b7bdfe97215b..4d39ea033653 100644 --- a/drivers/media/platform/vicodec/vicodec-core.c +++ b/drivers/media/platform/vicodec/vicodec-core.c @@ -190,18 +190,8 @@ static int device_process(struct vicodec_ctx *ctx, } out_vb->sequence = q_cap->sequence++; - out_vb->vb2_buf.timestamp = in_vb->vb2_buf.timestamp; - - if (in_vb->flags & V4L2_BUF_FLAG_TIMECODE) - out_vb->timecode = in_vb->timecode; - out_vb->field = in_vb->field; out_vb->flags &= ~V4L2_BUF_FLAG_LAST; - out_vb->flags |= in_vb->flags & - (V4L2_BUF_FLAG_TIMECODE | -V4L2_BUF_FLAG_KEYFRAME | -V4L2_BUF_FLAG_PFRAME | -V4L2_BUF_FLAG_BFRAME | -V4L2_BUF_FLAG_TSTAMP_SRC_MASK); + v4l2_m2m_buf_copy_data(in_vb, out_vb, !ctx->is_enc); return 0; } @@ -1083,6 +1073,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; src_vq->lock = ctx->is_enc ? >dev->enc_mutex : >dev->dec_mutex; + src_vq->supports_tags = true; ret = vb2_queue_init(src_vq); if (ret) @@ -1098,6 +1089,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, dst_vq->mem_ops = _vmalloc_memops; dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; dst_vq->lock = src_vq->lock; + dst_vq->supports_tags = true; return vb2_queue_init(dst_vq); } -- 2.19.1
[PATCH] media: ddbridge: remove another duplicate of io.h and sort includes
The io.h was still included twice. Having a large number of
includes like that unsorted is likely the reason why we ended
by having 3 includes of io.h and two includes of interrupt.h
at the first place.
So, let's reorder the includes on alphabetic order. That would
make easier to maintain it.
Fixes: 12645e0655e4 ("media: ddbridge: remove some duplicated include file")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/ddbridge/ddbridge.h | 52 +--
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/media/pci/ddbridge/ddbridge.h
b/drivers/media/pci/ddbridge/ddbridge.h
index 27b46fe704cd..0be6ed216e65 100644
--- a/drivers/media/pci/ddbridge/ddbridge.h
+++ b/drivers/media/pci/ddbridge/ddbridge.h
@@ -18,45 +18,43 @@
#ifndef _DDBRIDGE_H_
#define _DDBRIDGE_H_
-#include
-#include
+#include
+#include
+
+#include
+#include
#include
-#include
-#include
-#include
-#include
+#include
+#include
+#include
#include
-#include
-#include
-#include
+#include
+#include
+#include
#include
+#include
+#include
+#include
#include
-#include
+#include
+#include
+#include
+#include
#include
-#include
-#include
-
+#include
+#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-
-#include
-#include
-#include
-#include
+#include
+#include
#include
-#include
+#include
#include
+#include
#include
-#include
-#include
#include
+#include
#define DDBRIDGE_VERSION "0.9.33-integrated"
--
2.19.1
Re: [PATCH v3 0/9] TVP5150 fixes and new features
Hi Marco,
Em Fri, 9 Nov 2018 14:46:24 +0100
Marco Felsch escreveu:
> Hi Mauro,
>
> I don't want to spam you. Can you give me some feedback? I know the
> merge window is a busy time, so maybe you have some time now.
Sorry for taking so long on looking into it... has been really busy
those days :-(
I applied patch 2/9. Patch 3 doesn't apply. Would you mind
rebasing it on the top of upstream? there are some non-trivial
conflicts (perhaps I just missed some other preparation patch?).
I suspect that it would be easier if you could rebase your tree
on the top of the latest upstream one, e. g.:
git://linuxtv.org/media_tree.git
(master branch)
Regards,
Mauro
>
> Regards,
> Marco
>
> On 18-10-29 19:41, Marco Felsch wrote:
> > Hi Mauro,
> >
> > just a reminder, Rob already added his ack/rev-by tags.
> >
> > Thanks,
> > Marco
> >
> > On 18-09-18 15:14, Marco Felsch wrote:
> > > Hi,
> > >
> > > this is my v3 with the integrated reviews from my v2 [1]. This serie
> > > applies to Mauro's experimental.git [2].
> > >
> > > @Mauro:
> > > Patch ("media: tvp5150: fix irq_request error path during probe") is new
> > > in this series. Maybe you can squash them with ("media: tvp5150: Add sync
> > > lock
> > > interrupt handling"), thanks.
> > >
> > > I've tested this series on a customer dt-based board. Unfortunately I
> > > haven't a device which use the em28xx driver. So other tester a welcome :)
> > >
> > > [1] https://www.spinics.net/lists/devicetree/msg244129.html
> > > [2] https://git.linuxtv.org/mchehab/experimental.git/log/?h=tvp5150-4
> > >
> > > Javier Martinez Canillas (1):
> > > partial revert of "[media] tvp5150: add HW input connectors support"
> > >
> > > Marco Felsch (7):
> > > media: tvp5150: fix irq_request error path during probe
> > > media: tvp5150: add input source selection of_graph support
> > > media: dt-bindings: tvp5150: Add input port connectors DT bindings
> > > media: v4l2-subdev: add stubs for v4l2_subdev_get_try_*
> > > media: v4l2-subdev: fix v4l2_subdev_get_try_* dependency
> > > media: tvp5150: add FORMAT_TRY support for get/set selection handlers
> > > media: tvp5150: add s_power callback
> > >
> > > Michael Tretter (1):
> > > media: tvp5150: initialize subdev before parsing device tree
> > >
> > > .../devicetree/bindings/media/i2c/tvp5150.txt | 92 ++-
> > > drivers/media/i2c/tvp5150.c | 657 +-
> > > include/dt-bindings/media/tvp5150.h | 2 -
> > > include/media/v4l2-subdev.h | 15 +-
> > > 4 files changed, 584 insertions(+), 182 deletions(-)
> > >
> > > --
> > > 2.19.0
> > >
> > >
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions | http://www.pengutronix.de/ |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
> >
> >
>
Thanks,
Mauro
Re: [PATCH v9 04/13] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7
Hi Sakari, Thanks for the review. On Mon 03 Dec 2018 at 12:10, Sakari Ailus wrote: Hi Rui, On Thu, Nov 22, 2018 at 03:18:25PM +, Rui Miguel Silva wrote: Adds MIPI CSI-2 subdev for i.MX7 to connect with sensors with a MIPI CSI-2 interface. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Makefile |1 + drivers/staging/media/imx/imx7-mipi-csis.c | 1135 2 files changed, 1136 insertions(+) create mode 100644 drivers/staging/media/imx/imx7-mipi-csis.c diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index 074f016d3519..d2d909a36239 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -14,3 +14,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o +obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-mipi-csis.o diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c new file mode 100644 index ..56963d0c2043 --- /dev/null +++ b/drivers/staging/media/imx/imx7-mipi-csis.c @@ -0,0 +1,1135 @@ +// SPDX-License-Identifier: GPL +/* + * Freescale i.MX7 SoC series MIPI-CSI V3.3 receiver driver + * + * Copyright (C) 2018 Linaro Ltd + * Copyright (C) 2015-2016 Freescale Semiconductor, Inc. All Rights Reserved. + * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "imx-media.h" + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "Debug level (0-2)"); Could you rely on dynamic debug instead? Yeah, I will maybe add some debugfs entry. + +#define CSIS_DRIVER_NAME "imx7-mipi-csis" +#define CSIS_SUBDEV_NAME CSIS_DRIVER_NAME + +#define CSIS_PAD_SINK 0 +#define CSIS_PAD_SOURCE1 +#define CSIS_PADS_NUM 2 + +#define MIPI_CSIS_DEF_PIX_WIDTH640 +#define MIPI_CSIS_DEF_PIX_HEIGHT 480 + +/* Register map definition */ + +/* CSIS common control */ +#define MIPI_CSIS_CMN_CTRL 0x04 +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW BIT(16) +#define MIPI_CSIS_CMN_CTRL_INTER_MODE BIT(10) +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW_CTRL BIT(2) +#define MIPI_CSIS_CMN_CTRL_RESET BIT(1) +#define MIPI_CSIS_CMN_CTRL_ENABLE BIT(0) + +#define MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET 8 +#define MIPI_CSIS_CMN_CTRL_LANE_NR_MASK(3 << 8) + +/* CSIS clock control */ +#define MIPI_CSIS_CLK_CTRL 0x08 +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH3(x) ((x) << 28) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH2(x) ((x) << 24) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH1(x) ((x) << 20) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH0(x) ((x) << 16) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_EN_MSK (0xf << 4) +#define MIPI_CSIS_CLK_CTRL_WCLK_SRCBIT(0) + +/* CSIS Interrupt mask */ +#define MIPI_CSIS_INTMSK 0x10 +#define MIPI_CSIS_INTMSK_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTMSK_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTMSK_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTMSK_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTMSK_FRAME_START BIT(24) +#define MIPI_CSIS_INTMSK_FRAME_END BIT(20) +#define MIPI_CSIS_INTMSK_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTMSK_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTMSK_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTMSK_ERR_OVER BIT(4) +#define MIPI_CSIS_INTMSK_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTMSK_ERR_ECC BIT(2) +#define MIPI_CSIS_INTMSK_ERR_CRC BIT(1) +#define MIPI_CSIS_INTMSK_ERR_UNKNOWN BIT(0) + +/* CSIS Interrupt source */ +#define MIPI_CSIS_INTSRC 0x14 +#define MIPI_CSIS_INTSRC_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTSRC_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTSRC_EVEN BIT(30) +#define MIPI_CSIS_INTSRC_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTSRC_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTSRC_ODD (0x3 << 28) +#define MIPI_CSIS_INTSRC_NON_IMAGE_DATA(0xf << 28) +#define MIPI_CSIS_INTSRC_FRAME_START BIT(24) +#define MIPI_CSIS_INTSRC_FRAME_END BIT(20) +#define MIPI_CSIS_INTSRC_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTSRC_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTSRC_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTSRC_ERR_OVER BIT(4) +#define MIPI_CSIS_INTSRC_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTSRC_ERR_ECC BIT(2) +#define MIPI_CSIS_INTSRC_ERR_CRC BIT(1) +#define MIPI_CSIS_INTSRC_ERR_UNKNOWN BIT(0) +#define MIPI_CSIS_INTSRC_ERRORS0xf + +/* D-PHY status control */ +#define MIPI_CSIS_DPHYSTATUS 0x20 +#define MIPI_CSIS_DPHYSTATUS_ULPS_DAT BIT(8) +#define
Re: [PATCH 1/4] libdvbv5: do not adjust DVB time daylight saving
Em Sat, 7 Jul 2018 13:20:54 +0200
André Roth escreveu:
> This makes dvb_time available outside of EIT parsing, and
> struct tm to reflect the actual values received from DVB.
>
> Signed-off-by: André Roth
> ---
> lib/include/libdvbv5/descriptors.h | 11 +++
> lib/include/libdvbv5/eit.h | 10 --
> lib/libdvbv5/descriptors.c | 37 +
> lib/libdvbv5/tables/eit.c | 28
> 4 files changed, 48 insertions(+), 38 deletions(-)
>
> diff --git a/lib/include/libdvbv5/descriptors.h
> b/lib/include/libdvbv5/descriptors.h
> index cb21470c..31f4c73f 100644
> --- a/lib/include/libdvbv5/descriptors.h
> +++ b/lib/include/libdvbv5/descriptors.h
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * @brief Maximum size of a table session to be parsed
> @@ -159,6 +160,16 @@ uint32_t dvb_bcd(uint32_t bcd);
> void dvb_hexdump(struct dvb_v5_fe_parms *parms, const char *prefix,
>const unsigned char *buf, int len);
>
> +/**
> + * @brief Converts a DVB formatted timestamp into struct tm
> + * @ingroup dvb_table
> + *
> + * @param data event on DVB time format
> + * @param tm pointer to struct tm where the converted timestamp will
> + * be stored.
> + */
> +void dvb_time(const uint8_t data[5], struct tm *tm);
> +
> /**
> * @brief parse MPEG-TS descriptors
> * @ingroup dvb_table
> diff --git a/lib/include/libdvbv5/eit.h b/lib/include/libdvbv5/eit.h
> index 9129861e..5af266b1 100644
> --- a/lib/include/libdvbv5/eit.h
> +++ b/lib/include/libdvbv5/eit.h
> @@ -209,16 +209,6 @@ void dvb_table_eit_free(struct dvb_table_eit *table);
> void dvb_table_eit_print(struct dvb_v5_fe_parms *parms,
>struct dvb_table_eit *table);
>
> -/**
> - * @brief Converts a DVB EIT formatted timestamp into struct tm
> - * @ingroup dvb_table
> - *
> - * @param data event on DVB EIT time format
> - * @param tm pointer to struct tm where the converted timestamp will
> - * be stored.
> - */
> -void dvb_time(const uint8_t data[5], struct tm *tm);
> -
This seems to break the existing ABI.
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/libdvbv5/descriptors.c b/lib/libdvbv5/descriptors.c
> index 0683dc1b..ccec503c 100644
> --- a/lib/libdvbv5/descriptors.c
> +++ b/lib/libdvbv5/descriptors.c
> @@ -56,6 +56,14 @@
> #include
> #include
>
> +#ifdef ENABLE_NLS
> +# include "gettext.h"
> +# include
> +# define _(string) dgettext(LIBDVBV5_DOMAIN, string)
> +#else
> +# define _(string) string
> +#endif
> +
> static void dvb_desc_init(uint8_t type, uint8_t length, struct dvb_desc
> *desc)
> {
> desc->type = type;
> @@ -1391,3 +1399,32 @@ void dvb_hexdump(struct dvb_v5_fe_parms *parms, const
> char *prefix, const unsign
> dvb_loginfo("%s%s %s %s", prefix, hex, spaces, ascii);
> }
> }
> +
> +void dvb_time(const uint8_t data[5], struct tm *tm)
> +{
> + /* ETSI EN 300 468 V1.4.1 */
> + int year, month, day, hour, min, sec;
> + int k = 0;
> + uint16_t mjd;
> +
> + mjd = *(uint16_t *) data;
> + hour = dvb_bcd(data[2]);
> + min = dvb_bcd(data[3]);
> + sec = dvb_bcd(data[4]);
> + year = ((mjd - 15078.2) / 365.25);
> + month = ((mjd - 14956.1 - (int) (year * 365.25)) / 30.6001);
> + day = mjd - 14956 - (int) (year * 365.25) - (int) (month * 30.6001);
> + if (month == 14 || month == 15) k = 1;
> + year += k;
> + month = month - 1 - k * 12;
> +
> + tm->tm_sec = sec;
> + tm->tm_min = min;
> + tm->tm_hour = hour;
> + tm->tm_mday = day;
> + tm->tm_mon = month - 1;
> + tm->tm_year = year;
> + tm->tm_isdst = -1; /* do not adjust */
It seems that the only real change here is that you replaced 1 by -1 here,
in order for the mktime() to not handle daylight saving time.
Why are you also moving this out of eit.c/eit.h?
> + mktime( tm );
> +}
> +
> diff --git a/lib/libdvbv5/tables/eit.c b/lib/libdvbv5/tables/eit.c
> index a6ba566a..799e4c9a 100644
> --- a/lib/libdvbv5/tables/eit.c
> +++ b/lib/libdvbv5/tables/eit.c
> @@ -154,34 +154,6 @@ void dvb_table_eit_print(struct dvb_v5_fe_parms *parms,
> struct dvb_table_eit *ei
> dvb_loginfo("|_ %d events", events);
> }
>
> -void dvb_time(const uint8_t data[5], struct tm *tm)
> -{
> - /* ETSI EN 300 468 V1.4.1 */
> - int year, month, day, hour, min, sec;
> - int k = 0;
> - uint16_t mjd;
> -
> - mjd = *(uint16_t *) data;
> - hour = dvb_bcd(data[2]);
> - min = dvb_bcd(data[3]);
> - sec = dvb_bcd(data[4]);
> - year = ((mjd - 15078.2) / 365.25);
> - month = ((mjd - 14956.1 - (int) (year * 365.25)) / 30.6001);
> - day = mjd - 14956 - (int) (year * 365.25) - (int) (month * 30.6001);
> - if (month == 14 || month == 15) k = 1;
> - year += k;
> - month = month - 1 - k * 12;
> -
> - tm->tm_sec = sec;
> - tm->tm_min = min;
> - tm->tm_hour = hour;
> - tm->tm_mday =
