Re: [PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder
Hi Hans,
On Mon, 2016-07-11 at 06:32 +0200, Hans Verkuil wrote:
> Hi Tiffany,
>
> My apologies for the delay, but here is my review at last:
>
> On 05/30/2016 09:52 AM, Tiffany Lin wrote:
> > This patch add g/s_selection support for MT8173
> >
> > Signed-off-by: Tiffany Lin
> > ---
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 74
> >
> > 1 file changed, 74 insertions(+)
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > index 6e72d73..23ef9a1 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > @@ -630,6 +630,77 @@ static int vidioc_try_fmt_vid_out_mplane(struct file
> > *file, void *priv,
> > return vidioc_try_fmt(f, fmt);
> > }
> >
> > +static int vidioc_venc_g_selection(struct file *file, void *priv,
> > +struct v4l2_selection *s)
> > +{
> > + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> > + struct mtk_q_data *q_data;
> > +
> > + /* crop means compose for output devices */
> > + switch (s->target) {
> > + case V4L2_SEL_TGT_CROP_DEFAULT:
> > + case V4L2_SEL_TGT_CROP_BOUNDS:
> > + case V4L2_SEL_TGT_CROP:
> > + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> > + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> > + case V4L2_SEL_TGT_COMPOSE:
> > + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> > + mtk_v4l2_err("Invalid s->type = %d", s->type);
> > + return -EINVAL;
> > + }
> > + break;
> > + default:
> > + mtk_v4l2_err("Invalid s->target = %d", s->target);
> > + return -EINVAL;
> > + }
> > +
> > + q_data = mtk_venc_get_q_data(ctx, s->type);
> > + if (!q_data)
> > + return -EINVAL;
> > +
> > + s->r.top = 0;
> > + s->r.left = 0;
> > + s->r.width = q_data->visible_width;
> > + s->r.height = q_data->visible_height;
> > +
> > + return 0;
> > +}
> > +
> > +static int vidioc_venc_s_selection(struct file *file, void *priv,
> > +struct v4l2_selection *s)
> > +{
> > + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> > + struct mtk_q_data *q_data;
> > +
> > + switch (s->target) {
> > + case V4L2_SEL_TGT_CROP_DEFAULT:
> > + case V4L2_SEL_TGT_CROP_BOUNDS:
> > + case V4L2_SEL_TGT_CROP:
> > + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> > + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> > + case V4L2_SEL_TGT_COMPOSE:
> > + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> > + mtk_v4l2_err("Invalid s->type = %d", s->type);
> > + return -EINVAL;
> > + }
> > + break;
> > + default:
> > + mtk_v4l2_err("Invalid s->target = %d", s->target);
> > + return -EINVAL;
> > + }
> > +
> > + q_data = mtk_venc_get_q_data(ctx, s->type);
> > + if (!q_data)
> > + return -EINVAL;
> > +
> > + s->r.top = 0;
> > + s->r.left = 0;
> > + q_data->visible_width = s->r.width;
> > + q_data->visible_height = s->r.height;
>
> This makes no sense.
>
> See this page:
>
> https://hverkuil.home.xs4all.nl/spec/media.html#selection-api
>
> For the video output direction (memory -> HW encoder) the data source is
> the memory, the data sink is the HW encoder. For the video capture direction
> (HW encoder -> memory) the data source is the HW encoder and the data sink
> is the memory.
>
> Usually for m2m devices the video output direction may support cropping and
> the video capture direction may support composing.
>
> It's not clear what you intend here, especially since you set left and right
> to 0. That's not what the selection operation is supposed to do.
>
I am confused about about g/s_selection.
If application want to configure encode area and crop meta-data, it
should set crop info to OUTPUT queue, is that right?
if user space still use g/s_crop ioctl, in
v4l_g_crop and v4l_s_crop, it set target to V4L2_SEL_TGT_COMPOSE_ACTIVE
when buf type is V4L2_TYPE_IS_OUTPUT.
It looks like when work with g/s_crop ioctl, command set to OUTPUT
buffer will use target V4L2_SEL_TGT_COMPOSE_ACTIVE.
When work with g/s_selection ictol, command set to OUTPUT buffer will
use V4L2_SEL_TGT_CROP_ACTIVE.
Is this correct behavior?
static int v4l_g_crop(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
{
struct v4l2_crop *p = arg;
struct v4l2_selection s = {
.type = p->type,
};
int ret;
if (ops->vidioc_g_crop)
return ops->vidioc_g_crop(file, fh, p);
/* simulate capture crop using selection api */
/* crop means compose for output devices */
if (V4L2_TYPE_IS_OUTPUT(p->type))
s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
else
s.target = V4L2_SEL_TGT_CROP_ACTIVE;
ret = ops->vidioc_g_selection(fi
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 Jul 14 04:00:19 CEST 2016 git branch: test git hash: 5cac1f67ea0363d463a58ec2d9118268fe2ba5d6 gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3428-gdfe27cf host hardware: x86_64 host os:4.6.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: ERRORS linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0-i686: ERRORS linux-4.1.1-i686: ERRORS linux-4.2-i686: ERRORS linux-4.3-i686: ERRORS linux-4.4-i686: ERRORS linux-4.5-i686: ERRORS linux-4.6-i686: ERRORS linux-4.7-rc1-i686: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0-x86_64: ERRORS linux-4.1.1-x86_64: ERRORS linux-4.2-x86_64: ERRORS linux-4.3-x86_64: ERRORS linux-4.4-x86_64: ERRORS linux-4.5-x86_64: ERRORS linux-4.6-x86_64: ERRORS linux-4.7-rc1-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS smatch: 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/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Media documentation converted to ReST markup language
Hi Mauro, On Wednesday 13 Jul 2016 11:11:43 Mauro Carvalho Chehab wrote: > Em Sat, 09 Jul 2016 20:10:21 +0300 Laurent Pinchart escreveu: > > The other one is related, the table of contents in the main page of each > > section > > (https://mchehab.fedorapeople.org/media_API_book/linux_tv/media/v4l/v4l2.h > > tml for instance) only shows the first level entries. We have a full table > > of contents now, and that's very practical to quickly search for the > > information we need without requiring many clicks (or actually any click > > at all). How can we keep that feature ? > > It is not hard to change the level of entries, although I really hated the > DocBook template that creates multi-depth TOCs everywhere, as it is very > messy to see those big indexes in the middle of the book. > > What I did was to add *one* full contents index (actually, up to level 5) > at the first page of the book: > https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html > > and kept the other ones with depth 1. Thank you, that's exactly what I had in mind. > > By the way, the "Video for Linux API" section (and the other sibling > > sections) are child nodes of the "Introduction" section. That feels quite > > odd. > > This was fixed already. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Клиентские базы данных для Вашего Бизнеса!!! Узнайте подробнее или запишите контакты. Пригодится не сейчас так позднее!!! Email: nbiruko...@gmail.com Skype: prodawez389
Клиентские базы данных для Вашего Бизнеса!!! Узнайте подробнее или запишите контакты. Пригодится не сейчас так потом!!! Email: nbiruko...@gmail.com Skype: prodawez389
Re: [PATCH 14/28] gpu: ipu-ic: Add complete image conversion support with tiling
On 07/13/2016 11:58 AM, Mauro Carvalho Chehab wrote: > > We don't do image rotation in software inside the Kernel! This is > something that should be done either by some hardware block or > in userspace. Hi Mauro, I'm not sure I follow you. This is all hardware conversions. > > We also don't do image conversions inside the Kernel. Same applies > to other similar codes on this patch. Again, I don't follow you. Of course the kernel can do image conversion! Again this is all hardware based image conversion, using the i.MX6 IPU Image Converter unit. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] cxd2841er: avoid misleading gcc warning
The addition of jump label support in dynamic_debug caused an unexpected warning in exactly one file in the kernel: drivers/media/dvb-frontends/cxd2841er.c: In function 'cxd2841er_tune_tc': include/linux/dynamic_debug.h:134:3: error: 'carrier_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized] __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^ drivers/media/dvb-frontends/cxd2841er.c:3177:11: note: 'carrier_offset' was declared here int ret, carrier_offset; ^~ The problem seems to be that the compiler gets confused by the extra conditionals in static_branch_unlikely, to the point where it can no longer keep track of which branches have already been taken, and it doesn't realize that this variable is now always initialized when it gets used. I have done lots of randconfig kernel builds and could not find any other file with this behavior, so I assume it's a rare enough glitch that we don't need to change the jump label support but instead just work around the warning in the driver. To achieve that, I'm moving the check for the return value into the switch() statement, which is an obvious transformation, but is enough to un-confuse the compiler here. The resulting code is not as nice to read, but at least we retain the behavior of warning if it gets changed to actually access an uninitialized carrier offset value in the future. Signed-off-by: Arnd Bergmann Fixes: (in linux-mm) "dynamic_debug: add jump label support" --- drivers/media/dvb-frontends/cxd2841er.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb-frontends/cxd2841er.c b/drivers/media/dvb-frontends/cxd2841er.c index 721fb074da7c..0639ca281a2c 100644 --- a/drivers/media/dvb-frontends/cxd2841er.c +++ b/drivers/media/dvb-frontends/cxd2841er.c @@ -3223,20 +3223,28 @@ static int cxd2841er_tune_tc(struct dvb_frontend *fe, ret = cxd2841er_get_carrier_offset_i( priv, p->bandwidth_hz, &carrier_offset); + if (ret) + return ret; break; case SYS_DVBT: ret = cxd2841er_get_carrier_offset_t( priv, p->bandwidth_hz, &carrier_offset); + if (ret) + return ret; break; case SYS_DVBT2: ret = cxd2841er_get_carrier_offset_t2( priv, p->bandwidth_hz, &carrier_offset); + if (ret) + return ret; break; case SYS_DVBC_ANNEX_A: ret = cxd2841er_get_carrier_offset_c( priv, &carrier_offset); + if (ret) + return ret; break; default: dev_dbg(&priv->i2c->dev, @@ -3244,8 +3252,6 @@ static int cxd2841er_tune_tc(struct dvb_frontend *fe, __func__, priv->system); return -EINVAL; } - if (ret) - return ret; dev_dbg(&priv->i2c->dev, "%s(): carrier offset %d\n", __func__, carrier_offset); p->frequency += carrier_offset; -- 2.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] uapi: export lirc.h header
This header contains the userspace API for lirc. Signed-off-by: Mauro Carvalho Chehab --- include/uapi/linux/Kbuild | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 8bdae34d1f9a..ec10cfef166a 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -245,6 +245,7 @@ endif header-y += hw_breakpoint.h header-y += l2tp.h header-y += libc-compat.h +header-y += lirc.h header-y += limits.h header-y += llc.h header-y += loop.h -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/28] gpu: ipu-ic: Add complete image conversion support with tiling
Em Wed, 13 Jul 2016 15:58:31 -0300
Mauro Carvalho Chehab escreveu:
> Em Wed, 6 Jul 2016 16:06:44 -0700
> Steve Longerbeam escreveu:
>
> > This patch implements complete image conversion support to ipu-ic,
> > with tiling to support scaling to and from images up to 4096x4096.
> > Image rotation is also supported.
> >
> > The internal API is subsystem agnostic (no V4L2 dependency except
> > for the use of V4L2 fourcc pixel formats).
An additional note: when you send a patch series that overrides a
previously sent one, you should add a version at the email title,
like:
[PATCH 14/28 v2] gpu: ipu-ic: Add complete image conversion support
with tiling
It also helps if you add a cover patch when sending big patch series like
this one.
> >
> > Callers prepare for image conversion by calling
> > ipu_image_convert_prepare(), which initializes the parameters of
> > the conversion. The caller passes in the ipu_ic task to use for
> > the conversion, the input and output image formats, a rotation mode,
> > and a completion callback and completion context pointer:
> >
> > struct image_converter_ctx *
> > ipu_image_convert_prepare(struct ipu_ic *ic,
> > struct ipu_image *in, struct ipu_image *out,
> > enum ipu_rotate_mode rot_mode,
> > image_converter_cb_t complete,
> > void *complete_context);
> >
> > The caller is given a new conversion context that must be passed to
> > the further APIs:
> >
> > struct image_converter_run *
> > ipu_image_convert_run(struct image_converter_ctx *ctx,
> > dma_addr_t in_phys, dma_addr_t out_phys);
> >
> > This queues a new image conversion request to a run queue, and
> > starts the conversion immediately if the run queue is empty. Only
> > the physaddr's of the input and output image buffers are needed,
> > since the conversion context was created previously with
> > ipu_image_convert_prepare(). Returns a new run object pointer. When
> > the conversion completes, the run pointer is returned to the
> > completion callback.
> >
> > void image_convert_abort(struct image_converter_ctx *ctx);
> >
> > This will abort any active or pending conversions for this context.
> > Any currently active or pending runs belonging to this context are
> > returned via the completion callback with an error status.
> >
> > void ipu_image_convert_unprepare(struct image_converter_ctx *ctx);
> >
> > Unprepares the conversion context. Any active or pending runs will
> > be aborted by calling image_convert_abort().
> > ---
> > drivers/gpu/ipu-v3/ipu-ic.c | 1691
> > ++-
> > include/video/imx-ipu-v3.h | 57 +-
> > 2 files changed, 1736 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> > index 5329bfe..f6a1125 100644
> > --- a/drivers/gpu/ipu-v3/ipu-ic.c
> > +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> > @@ -17,6 +17,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include "ipu-prv.h"
> >
> > /* IC Register Offsets */
> > @@ -82,6 +84,40 @@
> > #define IC_IDMAC_3_PP_WIDTH_MASK(0x3ff << 20)
> > #define IC_IDMAC_3_PP_WIDTH_OFFSET 20
> >
> > +/*
> > + * The IC Resizer has a restriction that the output frame from the
> > + * resizer must be 1024 or less in both width (pixels) and height
> > + * (lines).
> > + *
> > + * The image conversion support attempts to split up a conversion when
> > + * the desired output (converted) frame resolution exceeds the IC resizer
> > + * limit of 1024 in either dimension.
> > + *
> > + * If either dimension of the output frame exceeds the limit, the
> > + * dimension is split into 1, 2, or 4 equal stripes, for a maximum
> > + * of 4*4 or 16 tiles. A conversion is then carried out for each
> > + * tile (but taking care to pass the full frame stride length to
> > + * the DMA channel's parameter memory!). IDMA double-buffering is used
> > + * to convert each tile back-to-back when possible (see note below
> > + * when double_buffering boolean is set).
> > + *
> > + * Note that the input frame must be split up into the same number
> > + * of tiles as the output frame.
> > + */
> > +#define MAX_STRIPES_W4
> > +#define MAX_STRIPES_H4
> > +#define MAX_TILES (MAX_STRIPES_W * MAX_STRIPES_H)
> > +
> > +#define MIN_W 128
> > +#define MIN_H 128
> > +#define MAX_W 4096
> > +#define MAX_H 4096
> > +
> > +enum image_convert_type {
> > + IMAGE_CONVERT_IN = 0,
> > + IMAGE_CONVERT_OUT,
> > +};
> > +
> > struct ic_task_regoffs {
> > u32 rsc;
> > u32 tpmem_csc[2];
> > @@ -96,6 +132,16 @@ struct ic_task_bitfields {
> > u32 ic_cmb_galpha_bit;
> > };
> >
> > +struct ic_task_channels {
> > + int in;
> > + int out;
> > + int rot_in;
> > + int rot_out;
> > + int vdi_in_p;
> > + int vdi_in;
> > + int vdi_in_n;
> > +};
> > +
> > static const struct ic_tas
Re: [PATCH 14/28] gpu: ipu-ic: Add complete image conversion support with tiling
Em Wed, 6 Jul 2016 16:06:44 -0700
Steve Longerbeam escreveu:
> This patch implements complete image conversion support to ipu-ic,
> with tiling to support scaling to and from images up to 4096x4096.
> Image rotation is also supported.
>
> The internal API is subsystem agnostic (no V4L2 dependency except
> for the use of V4L2 fourcc pixel formats).
>
> Callers prepare for image conversion by calling
> ipu_image_convert_prepare(), which initializes the parameters of
> the conversion. The caller passes in the ipu_ic task to use for
> the conversion, the input and output image formats, a rotation mode,
> and a completion callback and completion context pointer:
>
> struct image_converter_ctx *
> ipu_image_convert_prepare(struct ipu_ic *ic,
> struct ipu_image *in, struct ipu_image *out,
> enum ipu_rotate_mode rot_mode,
> image_converter_cb_t complete,
> void *complete_context);
>
> The caller is given a new conversion context that must be passed to
> the further APIs:
>
> struct image_converter_run *
> ipu_image_convert_run(struct image_converter_ctx *ctx,
> dma_addr_t in_phys, dma_addr_t out_phys);
>
> This queues a new image conversion request to a run queue, and
> starts the conversion immediately if the run queue is empty. Only
> the physaddr's of the input and output image buffers are needed,
> since the conversion context was created previously with
> ipu_image_convert_prepare(). Returns a new run object pointer. When
> the conversion completes, the run pointer is returned to the
> completion callback.
>
> void image_convert_abort(struct image_converter_ctx *ctx);
>
> This will abort any active or pending conversions for this context.
> Any currently active or pending runs belonging to this context are
> returned via the completion callback with an error status.
>
> void ipu_image_convert_unprepare(struct image_converter_ctx *ctx);
>
> Unprepares the conversion context. Any active or pending runs will
> be aborted by calling image_convert_abort().
> ---
> drivers/gpu/ipu-v3/ipu-ic.c | 1691
> ++-
> include/video/imx-ipu-v3.h | 57 +-
> 2 files changed, 1736 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index 5329bfe..f6a1125 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -17,6 +17,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "ipu-prv.h"
>
> /* IC Register Offsets */
> @@ -82,6 +84,40 @@
> #define IC_IDMAC_3_PP_WIDTH_MASK(0x3ff << 20)
> #define IC_IDMAC_3_PP_WIDTH_OFFSET 20
>
> +/*
> + * The IC Resizer has a restriction that the output frame from the
> + * resizer must be 1024 or less in both width (pixels) and height
> + * (lines).
> + *
> + * The image conversion support attempts to split up a conversion when
> + * the desired output (converted) frame resolution exceeds the IC resizer
> + * limit of 1024 in either dimension.
> + *
> + * If either dimension of the output frame exceeds the limit, the
> + * dimension is split into 1, 2, or 4 equal stripes, for a maximum
> + * of 4*4 or 16 tiles. A conversion is then carried out for each
> + * tile (but taking care to pass the full frame stride length to
> + * the DMA channel's parameter memory!). IDMA double-buffering is used
> + * to convert each tile back-to-back when possible (see note below
> + * when double_buffering boolean is set).
> + *
> + * Note that the input frame must be split up into the same number
> + * of tiles as the output frame.
> + */
> +#define MAX_STRIPES_W4
> +#define MAX_STRIPES_H4
> +#define MAX_TILES (MAX_STRIPES_W * MAX_STRIPES_H)
> +
> +#define MIN_W 128
> +#define MIN_H 128
> +#define MAX_W 4096
> +#define MAX_H 4096
> +
> +enum image_convert_type {
> + IMAGE_CONVERT_IN = 0,
> + IMAGE_CONVERT_OUT,
> +};
> +
> struct ic_task_regoffs {
> u32 rsc;
> u32 tpmem_csc[2];
> @@ -96,6 +132,16 @@ struct ic_task_bitfields {
> u32 ic_cmb_galpha_bit;
> };
>
> +struct ic_task_channels {
> + int in;
> + int out;
> + int rot_in;
> + int rot_out;
> + int vdi_in_p;
> + int vdi_in;
> + int vdi_in_n;
> +};
> +
> static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
> [IC_TASK_ENCODER] = {
> .rsc = IC_PRP_ENC_RSC,
> @@ -138,12 +184,159 @@ static const struct ic_task_bitfields
> ic_task_bit[IC_NUM_TASKS] = {
> },
> };
>
> +static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
> + [IC_TASK_ENCODER] = {
> + .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
> + .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
> + .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
> + },
> + [IC_TASK_VIEWFINDER] = {
> + .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
> + .out = IPU
Re: [PATCH v2 4/4] dynamic_debug: add jump label support
On Wednesday, July 13, 2016 11:41:50 AM CEST Jason Baron wrote:
>
> Hi Arnd,
>
> Ok, this is back in linux-next now (with hopefully a fix for arm). I
> was never able to quite reproduce the arm failure you saw. So if
> you get the chance to test this it would be great.
>
I've had a day's worth of randconfig tests without running into the problem
so far.
However, I did get one new compiler warning that I have just bisected
down to 21413cd0e4ed ("dynamic_debug: add jump label support"):
/git/arm-soc/drivers/media/dvb-frontends/cxd2841er.c: In function
'cxd2841er_tune_tc':
/git/arm-soc/drivers/media/dvb-frontends/cxd2841er.c:3253:40: error:
'carrier_offset' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
if (ret)
^
return ret;
~
/git/arm-soc/drivers/media/dvb-frontends/cxd2841er.c:3209:11: note:
'carrier_offset' was declared here
int ret, carrier_offset;
^~
It's clearly a false positive warning, the code is correct, but if this is
the only one that the dynamic_debug jump labels introduce, we may as well
just work around it in the driver.
I think this is caused by the "unlikely" annotation in dynamic_dev_dbg(),
which confuses the compiler trying to figure out whether the variable
is initialized or not.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drivers/media: Employ atomic_fetch_inc()
Em Mon, 20 Jun 2016 13:05:59 -0700
Davidlohr Bueso escreveu:
> Now that we have fetch_inc() we can stop using inc_return() - 1.
>
> These are very similar to the existing OP-RETURN primitives we already
> have, except they return the value of the atomic variable _before_
> modification.
>
> Cc: Hans Verkuil
> Cc: Andy Walls
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Davidlohr Bueso
I suspect that you'll be applying this together with the other patches
in this series. So:
Acked-by: Mauro Carvalho Chehab
> ---
> drivers/media/pci/cobalt/cobalt-driver.c | 2 +-
> drivers/media/pci/cx18/cx18-driver.c | 2 +-
> drivers/media/v4l2-core/v4l2-device.c| 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/pci/cobalt/cobalt-driver.c
> b/drivers/media/pci/cobalt/cobalt-driver.c
> index 8d6f04fc8013..70dfcb0c6a72 100644
> --- a/drivers/media/pci/cobalt/cobalt-driver.c
> +++ b/drivers/media/pci/cobalt/cobalt-driver.c
> @@ -683,7 +683,7 @@ static int cobalt_probe(struct pci_dev *pci_dev,
> int i;
>
> /* FIXME - module parameter arrays constrain max instances */
> - i = atomic_inc_return(&cobalt_instance) - 1;
> + i = atomic_fetch_inc(&cobalt_instance);
>
> cobalt = kzalloc(sizeof(struct cobalt), GFP_ATOMIC);
> if (cobalt == NULL)
> diff --git a/drivers/media/pci/cx18/cx18-driver.c
> b/drivers/media/pci/cx18/cx18-driver.c
> index 260e462d91b4..5cb3408c6859 100644
> --- a/drivers/media/pci/cx18/cx18-driver.c
> +++ b/drivers/media/pci/cx18/cx18-driver.c
> @@ -908,7 +908,7 @@ static int cx18_probe(struct pci_dev *pci_dev,
> struct cx18 *cx;
>
> /* FIXME - module parameter arrays constrain max instances */
> - i = atomic_inc_return(&cx18_instance) - 1;
> + i = atomic_fetch_inc(&cx18_instance);
> if (i >= CX18_MAX_CARDS) {
> printk(KERN_ERR "cx18: cannot manage card %d, driver has a "
> "limit of 0 - %d\n", i, CX18_MAX_CARDS - 1);
> diff --git a/drivers/media/v4l2-core/v4l2-device.c
> b/drivers/media/v4l2-core/v4l2-device.c
> index 06fa5f1b2cff..1bc5b68c2724 100644
> --- a/drivers/media/v4l2-core/v4l2-device.c
> +++ b/drivers/media/v4l2-core/v4l2-device.c
> @@ -76,7 +76,7 @@ EXPORT_SYMBOL_GPL(v4l2_device_put);
> int v4l2_device_set_name(struct v4l2_device *v4l2_dev, const char *basename,
> atomic_t *instance)
> {
> - int num = atomic_inc_return(instance) - 1;
> + int num = atomic_fetch_inc(instance);
> int len = strlen(basename);
>
> if (basename[len - 1] >= '0' && basename[len - 1] <= '9')
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] v4l2-subdev.h: allow V4L2_FRMIVAL_TYPE_CONTINUOUS & _STEPWISE
Em Sun, 12 Jun 2016 00:20:59 +0200
Philippe De Muyter escreveu:
> add max_interval and step_interval to struct
> v4l2_subdev_frame_interval_enum.
>
> When filled correctly by the sensor driver, those fields must be
> used as follows by the intermediate level :
>
> struct v4l2_frmivalenum *fival;
> struct v4l2_subdev_frame_interval_enum fie;
>
> if (fie.max_interval.numerator == 0) {
> fival->type = V4L2_FRMIVAL_TYPE_DISCRETE;
> fival->discrete = fie.interval;
> } else if (fie.step_interval.numerator == 0) {
> fival->type = V4L2_FRMIVAL_TYPE_CONTINUOUS;
> fival->stepwise.min = fie.interval;
> fival->stepwise.max = fie.max_interval;
> } else {
> fival->type = V4L2_FRMIVAL_TYPE_STEPWISE;
> fival->stepwise.min = fie.interval;
> fival->stepwise.max = fie.max_interval;
> fival->stepwise.step = fie.step_interval;
> }
>
> Signed-off-by: Philippe De Muyter
> ---
> include/uapi/linux/v4l2-subdev.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/v4l2-subdev.h
> b/include/uapi/linux/v4l2-subdev.h
> index dbce2b554..846dd36 100644
> --- a/include/uapi/linux/v4l2-subdev.h
> +++ b/include/uapi/linux/v4l2-subdev.h
> @@ -127,7 +127,9 @@ struct v4l2_subdev_frame_interval_enum {
> __u32 height;
> struct v4l2_fract interval;
> __u32 which;
> - __u32 reserved[8];
> + struct v4l2_fract max_interval;
> + struct v4l2_fract step_interval;
> + __u32 reserved[4];
As this changes the userspace API, you need to also patch the
Documentation/media to reflect such change and explain the meaning
for the new fields.
Please notice that the rst documentation is under the "docs-next"
branch at the media_tree.git. You should either patch against that
or wait for the end for 4.8-rc1, where the documentation will be
merged back on the master branch.
> };
>
> /**
--
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] docs-rst: Fix some typos
Those fixes came from patchs from Andrea for the old DocBook documentation. As we're removing it on Kernel 4.8, it doesn't make sense to apply the original patches, but, as the typos were ported to ReST, let's fix the issues there. Suggested-by: Andrea Gelmini Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/fdl-appendix.xml | 2 +- Documentation/DocBook/media/v4l/lirc_device_interface.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/fdl-appendix.xml b/Documentation/DocBook/media/v4l/fdl-appendix.xml index ae22394ba997..71299a3897c4 100644 --- a/Documentation/DocBook/media/v4l/fdl-appendix.xml +++ b/Documentation/DocBook/media/v4l/fdl-appendix.xml @@ -526,7 +526,7 @@ You may extract a single document from such a collection, and - dispbibute it individually under this License, provided you + distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml b/Documentation/DocBook/media/v4l/lirc_device_interface.xml index 34cada2ca710..725b221e1f6c 100644 --- a/Documentation/DocBook/media/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml @@ -114,7 +114,7 @@ on working with the default settings initially. Some receiver have maximum resolution which is defined by internal sample rate or data format limitations. E.g. it's common that signals can only be reported in 50 microsecond steps. This integer value is used by - lircd to automatically adjust the aeps tolerance value in the lircd + lircd to automatically adjust the steps tolerance value in the lircd config file. -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] [media] hva: multi-format video encoder V4L2 driver
On 07/11/2016 08:00 PM, Nicolas Dufresne wrote:
> Le lundi 11 juillet 2016 à 17:14 +0200, Jean-Christophe Trotin a écrit :
[snip]
>> +static int hva_g_fmt_stream(struct file *file, void *fh, struct v4l2_format
>> *f)
>> +{
>> +struct hva_ctx *ctx = fh_to_ctx(file->private_data);
>> +struct device *dev = ctx_to_dev(ctx);
>> +struct hva_streaminfo *streaminfo = &ctx->streaminfo;
>> +
>> +f->fmt.pix.width = streaminfo->width;
>> +f->fmt.pix.height = streaminfo->height;
>> +f->fmt.pix.field = V4L2_FIELD_NONE;
>> +f->fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M;
>
> Hard coding this is not great.Ideally the colorimetry (if not modified)
> should be copied from OUTPUT to CAPTURE, you may also set this to
> V4L2_COLORSPACE_DEFAULT.
>
Nicolas,
Thank you for the remark.
Colorspace was hard-coded because only V4L2_COLORSPACE_SMPTE170M is supported.
However, I understand that hard-coding is not great: I will align the code in
version 3 on the colorspace management made in the coda driver.
Best regards,
Jean-Christophe.
>> +f->fmt.pix.pixelformat = streaminfo->streamformat;
>> +f->fmt.pix.bytesperline = 0;
>> +f->fmt.pix.sizeimage = ctx->max_stream_size;
>> +
>> +dev_dbg(dev, "%s V4L2 G_FMT (CAPTURE): %dx%d fmt:%.4s size:%d\n",
>> +ctx->name, f->fmt.pix.width, f->fmt.pix.height,
>> +(u8 *)&f->fmt.pix.pixelformat, f->fmt.pix.sizeimage);
>> +return 0;
>> +}
[snip]N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [ANN] Media documentation converted to ReST markup language
Em Sat, 09 Jul 2016 20:10:21 +0300 Laurent Pinchart escreveu: > The other one is related, the table of contents in the main page of each > section > (https://mchehab.fedorapeople.org/media_API_book/linux_tv/media/v4l/v4l2.html > for instance) only shows the first level entries. We have a full table of > contents now, and that's very practical to quickly search for the information > we need without requiring many clicks (or actually any click at all). How can > we keep that feature ? It is not hard to change the level of entries, although I really hated the DocBook template that creates multi-depth TOCs everywhere, as it is very messy to see those big indexes in the middle of the book. What I did was to add *one* full contents index (actually, up to level 5) at the first page of the book: https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html and kept the other ones with depth 1. > > By the way, the "Video for Linux API" section (and the other sibling > sections) > are child nodes of the "Introduction" section. That feels quite odd. This was fixed already. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.2 10/10] v4l: Add 16-bit raw bayer pixel format definitions
On Thu, Jul 7, 2016 at 7:48 AM, Sakari Ailus
wrote:
> The formats added by this patch are:
>
> V4L2_PIX_FMT_SBGGR16
> V4L2_PIX_FMT_SGBRG16
> V4L2_PIX_FMT_SGRBG16
>
> V4L2_PIX_FMT_SRGGB16 already existed before the patch. Rework the
> documentation to match that of the other sample depths.
>
> Signed-off-by: Sakari Ailus
> ---
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml | 81 ---
> Documentation/DocBook/media/v4l/pixfmt-srggb16.xml | 91
> ++
> Documentation/DocBook/media/v4l/pixfmt.xml | 2 +-
> include/uapi/linux/videodev2.h | 3 +
> 4 files changed, 95 insertions(+), 82 deletions(-)
> delete mode 100644 Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml
> create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb16.xml
>
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml
> b/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml
> deleted file mode 100644
> index 789160565..000
> --- a/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml
> +++ /dev/null
> @@ -1,81 +0,0 @@
> -
> -
> -V4L2_PIX_FMT_SBGGR16 ('BYR2')
> -&manvol;
> -
> -
> -V4L2_PIX_FMT_SBGGR16
> -Bayer RGB format
> -
> -
> -Description
> -
> -This format is similar to -linkend="V4L2-PIX-FMT-SBGGR8">
> -V4L2_PIX_FMT_SBGGR8, except each pixel has
> -a depth of 16 bits. The least significant byte is stored at lower
> -memory addresses (little-endian).
> -
> -
> - V4L2_PIX_FMT_SBGGR16 4 × 4
> -pixel image
> -
> -
> - Byte Order.
> - Each cell is one byte.
> -
> -
> -
> -
> -
> - start + 0:
> - B00low
> - B00high
> - G01low
> - G01high
> - B02low
> - B02high
> - G03low
> - G03high
> -
> -
> - start + 8:
> - G10low
> - G10high
> - R11low
> - R11high
> - G12low
> - G12high
> - R13low
> - R13high
> -
> -
> - start + 16:
> - B20low
> - B20high
> - G21low
> - G21high
> - B22low
> - B22high
> - G23low
> - G23high
> -
> -
> - start + 24:
> - G30low
> - G30high
> - R31low
> - R31high
> - G32low
> - G32high
> - R33low
> - R33high
> -
> -
> -
> -
> -
> -
> -
> -
> -
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb16.xml
> b/Documentation/DocBook/media/v4l/pixfmt-srggb16.xml
> new file mode 100644
> index 000..590266f
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb16.xml
> @@ -0,0 +1,91 @@
> +
> +
> + V4L2_PIX_FMT_SRGGB16 ('RG16'),
> +V4L2_PIX_FMT_SGRBG16 ('GR16'),
> +V4L2_PIX_FMT_SGBRG16 ('GB16'),
> +V4L2_PIX_FMT_SBGGR16 ('BYR2')
> +
> + &manvol;
> +
> +
> +id="V4L2-PIX-FMT-SRGGB16">V4L2_PIX_FMT_SRGGB16
> +id="V4L2-PIX-FMT-SGRBG16">V4L2_PIX_FMT_SGRBG16
> +id="V4L2-PIX-FMT-SGBRG16">V4L2_PIX_FMT_SGBRG16
> +id="V4L2-PIX-FMT-SBGGR16">V4L2_PIX_FMT_SBGGR16
> + 16-bit Bayer formats
> +
> +
> + Description
> +
> + These four pixel formats are raw sRGB / Bayer formats with
> +16 bits per colour. Each colour component is stored in a 16-bit word.
> +Each n-pixel row contains n/2 green samples and n/2 blue or red
> +samples, with alternating red and blue rows. Bytes are stored in
> +memory in little endian order. They are conventionally described
> +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
> +formats:
> +
> +
> + V4L2_PIX_FMT_SBGGR16 4 × 4
> +pixel image
> +
> +
> + Byte Order.
> + Each cell is one byte.
> +
> +
> +
> +
> +
> + start + 0:
> + B00low
> + B00high
> + G01low
> + G01high
> + B02low
> + B02high
> + G03low
> + G03high
> +
> +
> + start + 8:
> + G10low
> + G10high
> + R11low
> + R11high
> + G12low
> + G12high
> + R13low
> + R13high
> +
Re: [PATCH v2 0/3] support of v4l2 encoder for STMicroelectronics SOC
Hello Jean Christophe,
On Wed, Jul 13, 2016 at 9:49 AM, Jean Christophe TROTIN
wrote:
>
>
> On 07/11/2016 08:57 PM, Javier Martinez Canillas wrote:
>> On Mon, Jul 11, 2016 at 1:48 PM, Nicolas Dufresne
>> wrote:
>>> Le lundi 11 juillet 2016 à 17:14 +0200, Jean-Christophe Trotin a
>>> écrit :
>>
>> [snip]
>>
Below is the v4l2-compliance report for the version 2 of the sti hva
driver:
root@sti-next:/home/video_test# v4l2-compliance -d /dev/video0
Driver Info:
Driver name : 8c85000.hva
>>>
>>> I think it would be nice to set a driver name that means something.
>>>
Card type : 8c85000.hva
>>
>> Agreed, same for Card type. The VIDIOC_QUERYCAP ioctl documentation
>> explains what information these fields should contain:
>>
>> https://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
>>
>> For example
>> https://git.linuxtv.org/media_tree.git/commit/?id=e0d80c8acca0f221b9dedb2eab7a5184848b99b7
>>
>> Best regards,
>> Javier
>>
>
> Nicolas and Javier,
>
> Thank you for the remarks.
> I will modify the code in version 3 so that "driver" contains the name of the
> encoder ("hva"), "card" identifies the hardware version ("hva"
> with equal to 400 here, which leads to "hva400"), and
> "bus_info"
> indicates the location of the device ("platform:8c85000.hva").
>
> Before the modification:
> Driver Info:
> Driver name : 8c85000.hva
> Card type : 8c85000.hva
> Bus info : platform:hva
> Driver version: 4.7.0
>
> After the modification:
> Driver Info:
> Driver name : hva
> Card type : hva400
> Bus info : platform:8c85000.hva
> Driver version: 4.7.0
>
Thanks a lot for doing this, it looks correct to me now.
> Best regards,
> Jean-Christophe.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver
Le mercredi 13 juillet 2016 à 10:00 +0800, tiffany lin a écrit : > Hi Nicolas, > > On Tue, 2016-07-12 at 15:14 -0400, Nicolas Dufresne wrote: > > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > > > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit > : > > > > Decoder hardware produces MT21 (compressed). Image processor > can > > > > convert it to a format that can be input of display driver. > > > > Tiffany. > > > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > > > > > It can be as input format for encoder, MDP and display > drivers in > > > > our > > > > > platform. > > > > I remember display driver can only accept uncompressed MT21. > Right? > > > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > > > format. It's not usable until it's decompressed and converted > by > > > > image > > > > processor. > > > > > > Previously it was described as MediaTek block mode, and now as a > > > MediaTek compressed format. It makes me think you have no idea > what > > > this pixel format really is. Is that right ? > > > > > > The main reason why I keep asking, is that we often find > similarities > > > between what vendor like to call their proprietary formats. Doing > the > > > proper research helps not creating a mess like in Android where > you > > > have a lot of formats that all point to the same format. I > believe > > > there was the same concern when Samsung wanted to introduce their > Z- > > > flip-Z NV12 tile format. In the end they simply provided > sufficient > > > documentation so we could document it and implement software > > > converters > > > for test and validation purpose. > > > > Here's the kind of information we want in the documentation. > > > > https://chromium.googlesource.com/chromium/src/media/+/master/base/ > vide > > o_types.h#40 > > > > // MediaTek proprietary format. MT21 is similar to NV21 except > the memory > > // layout and pixel layout (swizzles). 12bpp with Y plane > followed by a 2x2 > > // interleaved VU plane. Each image contains two buffers -- Y > plane and VU > > // plane. Two planes can be non-contiguous in memory. The > starting addresses > > // of Y plane and VU plane are 4KB alignment. > > // Suppose image dimension is (width, height). For both Y plane > and VU plane: > > // Row pitch = ((width+15)/16) * 16. > > // Plane size = Row pitch * (((height+31)/32)*32) > > > > Now obviously this is incomplete, as the swizzling need to be > documented of course. > > > Because it's finally a compressed format from our codec hw, we cannot > describe its swizzling. Can you clarify why it cannot be described ? I don't buy any argument that it's impossible to convert without hardware. Intel did document their compressed formats. Debugging an integration with such format that we have literally decided to no make public is a pain. A lot of decoder got abandoned or never used because of that. It would be nice to explain the architecture you are suggesting to make this decoder useful. How will userspace application be able to use your decoder. Will the image processor usable outside the display path ? People might want to do transcoding, or other relatively common task that does not imply a display. regards, Nicolas p.s. A small note to Wu-Cheng, the definition of the DRM format in your Chromium branch is not correct. DRM uses format modifier, such that the format is the family, in your case it's most likely NV21, and the modifier is the compression or tiling algorithm in place (or both as needed). -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] vpbe_display: convert g/s_crop to g/s_selection.
On Mon, Jul 4, 2016 at 9:32 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This is part of a final push to convert all drivers to g/s_selection.
>
> Signed-off-by: Hans Verkuil
> Cc: Prabhakar Lad
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> ---
> drivers/media/platform/davinci/vpbe_display.c | 65
> +++
> 1 file changed, 37 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpbe_display.c
> b/drivers/media/platform/davinci/vpbe_display.c
> index 0abcdfe..b4a8cd2 100644
> --- a/drivers/media/platform/davinci/vpbe_display.c
> +++ b/drivers/media/platform/davinci/vpbe_display.c
> @@ -441,7 +441,7 @@ vpbe_disp_calculate_scale_factor(struct vpbe_display
> *disp_dev,
> /*
> * Application initially set the image format. Current display
> * size is obtained from the vpbe display controller. expected_xsize
> -* and expected_ysize are set through S_CROP ioctl. Based on this,
> +* and expected_ysize are set through S_SELECTION ioctl. Based on
> this,
> * driver will calculate the scale factors for vertical and
> * horizontal direction so that the image is displayed scaled
> * and expanded. Application uses expansion to display the image
> @@ -650,24 +650,23 @@ static int vpbe_display_querycap(struct file *file,
> void *priv,
> return 0;
> }
>
> -static int vpbe_display_s_crop(struct file *file, void *priv,
> -const struct v4l2_crop *crop)
> +static int vpbe_display_s_selection(struct file *file, void *priv,
> +struct v4l2_selection *sel)
> {
> struct vpbe_layer *layer = video_drvdata(file);
> struct vpbe_display *disp_dev = layer->disp_dev;
> struct vpbe_device *vpbe_dev = disp_dev->vpbe_dev;
> struct osd_layer_config *cfg = &layer->layer_info.config;
> struct osd_state *osd_device = disp_dev->osd_device;
> - struct v4l2_rect rect = crop->c;
> + struct v4l2_rect rect = sel->r;
> int ret;
>
> v4l2_dbg(1, debug, &vpbe_dev->v4l2_dev,
> - "VIDIOC_S_CROP, layer id = %d\n", layer->device_id);
> + "VIDIOC_S_SELECTION, layer id = %d\n", layer->device_id);
>
> - if (crop->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> - v4l2_err(&vpbe_dev->v4l2_dev, "Invalid buf type\n");
> + if (sel->type != V4L2_BUF_TYPE_VIDEO_OUTPUT ||
> + sel->target != V4L2_SEL_TGT_CROP)
> return -EINVAL;
> - }
>
> if (rect.top < 0)
> rect.top = 0;
> @@ -715,32 +714,45 @@ static int vpbe_display_s_crop(struct file *file, void
> *priv,
> else
> osd_device->ops.set_interpolation_filter(osd_device, 0);
>
> + sel->r = rect;
> return 0;
> }
>
> -static int vpbe_display_g_crop(struct file *file, void *priv,
> -struct v4l2_crop *crop)
> +static int vpbe_display_g_selection(struct file *file, void *priv,
> + struct v4l2_selection *sel)
> {
> struct vpbe_layer *layer = video_drvdata(file);
> struct osd_layer_config *cfg = &layer->layer_info.config;
> struct vpbe_device *vpbe_dev = layer->disp_dev->vpbe_dev;
> struct osd_state *osd_device = layer->disp_dev->osd_device;
> - struct v4l2_rect *rect = &crop->c;
> + struct v4l2_rect *rect = &sel->r;
>
> v4l2_dbg(1, debug, &vpbe_dev->v4l2_dev,
> - "VIDIOC_G_CROP, layer id = %d\n",
> + "VIDIOC_G_SELECTION, layer id = %d\n",
> layer->device_id);
>
> - if (crop->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> - v4l2_err(&vpbe_dev->v4l2_dev, "Invalid buf type\n");
> + if (sel->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
> + return -EINVAL;
> +
> + switch (sel->target) {
> + case V4L2_SEL_TGT_CROP:
> + osd_device->ops.get_layer_config(osd_device,
> +layer->layer_info.id, cfg);
> + rect->top = cfg->ypos;
> + rect->left = cfg->xpos;
> + rect->width = cfg->xsize;
> + rect->height = cfg->ysize;
> + break;
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + rect->left = 0;
> + rect->top = 0;
> + rect->width = vpbe_dev->current_timings.xres;
> + rect->height = vpbe_dev->current_timings.yres;
> + break;
> + default:
> return -EINVAL;
> }
> - osd_device->ops.get_layer_config(osd_device,
> - layer->layer_info.id, cfg);
> - rect->top = cfg->ypos;
> - rect->left = cfg->xpos;
> - rect->width = cfg->xsize;
> - rect->height = cfg->ysize;
>
> return 0;
> }
> @@ -753,13 +765,10 @@ s
[PATCH 2/2] [media] doc-rst: increase depth of the main index
It is useful to have an index with all the book contents somewhere, as it makes easier to seek for something. So, increase maxdepth to 5 for the main index at the beginning of the book. While here, remove the genindex content, as it is bogus. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/media_uapi.rst | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst index 527c6deb1a19..5e872c8297b0 100644 --- a/Documentation/media/media_uapi.rst +++ b/Documentation/media/media_uapi.rst @@ -15,8 +15,10 @@ the license is included in the chapter entitled "GNU Free Documentation License". +.. contents:: + .. toctree:: -:maxdepth: 1 +:maxdepth: 5 intro uapi/v4l/v4l2 @@ -26,10 +28,3 @@ License". uapi/cec/cec-api uapi/gen-errors uapi/fdl-appendix - -.. only:: html - - Retrieval - = - - * :ref:`genindex` -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] davinci: drop unused control callbacks
On Mon, Jul 4, 2016 at 9:34 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> These callbacks are no longer used since the davinci drivers use the
> control framework.
>
> Signed-off-by: Hans Verkuil
> Cc: Prabhakar Lad
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> ---
> drivers/media/platform/davinci/ccdc_hw_device.h | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/ccdc_hw_device.h
> b/drivers/media/platform/davinci/ccdc_hw_device.h
> index 86b9b35..ae5605d 100644
> --- a/drivers/media/platform/davinci/ccdc_hw_device.h
> +++ b/drivers/media/platform/davinci/ccdc_hw_device.h
> @@ -80,13 +80,6 @@ struct ccdc_hw_ops {
> /* Pointer to function to get line length */
> unsigned int (*get_line_length) (void);
>
> - /* Query CCDC control IDs */
> - int (*queryctrl)(struct v4l2_queryctrl *qctrl);
> - /* Set CCDC control */
> - int (*set_control)(struct v4l2_control *ctrl);
> - /* Get CCDC control */
> - int (*get_control)(struct v4l2_control *ctrl);
> -
> /* Pointer to function to set frame buffer address */
> void (*setfbaddr) (unsigned long addr);
> /* Pointer to function to get field id */
> --
> 2.8.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mtk-vcodec: fix type mismatches
Hi Arnd, On Wed, 2016-07-13 at 15:08 +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 5:56:26 PM CEST tiffany lin wrote: > > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > > index 6dcae0a0a1f2..0b25a8700877 100644 > > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > > @@ -1028,15 +1028,15 @@ static void mtk_venc_worker(struct work_struct > > > *work) > > > bs_buf.size = (size_t)dst_buf->planes[0].length; > > > > > > mtk_v4l2_debug(2, > > > - "Framebuf VA=%p PA=%llx Size=0x%lx;VA=%p PA=0x%llx > > > Size=0x%lx;VA=%p PA=0x%llx Size=%zu", > > > + "Framebuf VA=%p PA=%pad Size=0x%zx;VA=%p PA=%pad > > > Size=0x%zx;VA=%p PA=%pad Size=0x%zx", > > > frm_buf.fb_addr[0].va, > > > - (u64)frm_buf.fb_addr[0].dma_addr, > > > + &frm_buf.fb_addr[0].dma_addr, > > > frm_buf.fb_addr[0].size, > > > frm_buf.fb_addr[1].va, > > > - (u64)frm_buf.fb_addr[1].dma_addr, > > > + &frm_buf.fb_addr[1].dma_addr, > > > frm_buf.fb_addr[1].size, > > > frm_buf.fb_addr[2].va, > > > - (u64)frm_buf.fb_addr[2].dma_addr, > > > + &frm_buf.fb_addr[2].dma_addr, > > > frm_buf.fb_addr[2].size); > > This change will make debug message dump address of dma_addr field but > > not the value of the dma_addr we want. > > How about change it from > > PA=%llx -> PA=%u > > (u64)frm_buf.fb_addr[0].dma_addr -> (u32)frm_buf.fb_addr[0].dma_addr, > > > > The %llx works fine with the cast to u64, the change above is mainly for the > "%lx" > on a size_t causing a warning. > > The change to %pad is done in order to use a consistent output for the > dma_addr_t, which had a leading "0x" in two cases but not in the first > one. > > printk interprets %pad as a pointer to a dma_addr_t and prints the > address, not the pointer to it, see Documentation/printk-formats.txt, > which lets you avoid the type cast as well as the 0x. > I understood now, I will check Documentation/printk-formats.txt. Thanks for your explanation. best regards, Tiffany > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] doc-rst: fix an undefined reference
Documentation/media/uapi/cec/cec-ioc-dqevent.rst:43: WARNING: undefined label: cec_event_state_change (if the link has no caption the label must precede a section header) Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst index 0fdd4afa8d82..2785a4cb9f08 100644 --- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst +++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst @@ -45,9 +45,9 @@ there is no more room in a queue then the last event is overwritten with the new one. This means that intermediate results can be thrown away but that the latest event is always available. This also means that is it possible to read two successive events that have the same value (e.g. -two :ref:`CEC_EVENT_STATE_CHANGE ` events with the same state). In that case -the intermediate state changes were lost but it is guaranteed that the -state did change in between the two events. +two :ref:`CEC_EVENT_STATE_CHANGE ` events with +the same state). In that case the intermediate state changes were lost but +it is guaranteed that the state did change in between the two events. .. _cec-event-state-change_s: -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] support of v4l2 encoder for STMicroelectronics SOC
On 07/11/2016 08:57 PM, Javier Martinez Canillas wrote:
> On Mon, Jul 11, 2016 at 1:48 PM, Nicolas Dufresne
> wrote:
>> Le lundi 11 juillet 2016 à 17:14 +0200, Jean-Christophe Trotin a
>> écrit :
>
> [snip]
>
>>>
>>> Below is the v4l2-compliance report for the version 2 of the sti hva
>>> driver:
>>>
>>>
>>> root@sti-next:/home/video_test# v4l2-compliance -d /dev/video0
>>> Driver Info:
>>>Driver name : 8c85000.hva
>>
>> I think it would be nice to set a driver name that means something.
>>
>>>Card type : 8c85000.hva
>
> Agreed, same for Card type. The VIDIOC_QUERYCAP ioctl documentation
> explains what information these fields should contain:
>
> https://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
>
> For example
> https://git.linuxtv.org/media_tree.git/commit/?id=e0d80c8acca0f221b9dedb2eab7a5184848b99b7
>
> Best regards,
> Javier
>
Nicolas and Javier,
Thank you for the remarks.
I will modify the code in version 3 so that "driver" contains the name of the
encoder ("hva"), "card" identifies the hardware version ("hva"
with equal to 400 here, which leads to "hva400"), and
"bus_info"
indicates the location of the device ("platform:8c85000.hva").
Before the modification:
Driver Info:
Driver name : 8c85000.hva
Card type : 8c85000.hva
Bus info : platform:hva
Driver version: 4.7.0
After the modification:
Driver Info:
Driver name : hva
Card type : hva400
Bus info : platform:8c85000.hva
Driver version: 4.7.0
Best regards,
Jean-Christophe.
Re: [PATCH v2.2 09/10] v4l: 16-bit BGGR is always 16 bits
On Thu, Jul 7, 2016 at 7:48 AM, Sakari Ailus wrote: > The V4L2_PIX_FMT_SBGGR16 format is documented to contain samples of fewer > than 16 bits. However, we do have specific definitions for smaller sample > sizes. Therefore, this note is redundant from the API point of view. > > Currently only two drivers, am437x and davinci, use the V4L2_PIX_FMT_SBGGR16 > pixelformat currently. The sampling precision is understood to be 16 bits in > all current cases. > > Remove the note on sampling precision. > > Signed-off-by: Sakari Ailus > --- Acked-by: Lad, Prabhakar Cheers, --Prabhakar Lad > Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml > b/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml > index 6494b05..789160565 100644 > --- a/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml > +++ b/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml > @@ -14,9 +14,7 @@ > linkend="V4L2-PIX-FMT-SBGGR8"> > V4L2_PIX_FMT_SBGGR8, except each pixel has > a depth of 16 bits. The least significant byte is stored at lower > -memory addresses (little-endian). Note the actual sampling precision > -may be lower than 16 bits, for example 10 bits per pixel with values > -in range 0 to 1023. > +memory addresses (little-endian). > > >V4L2_PIX_FMT_SBGGR16 4 × 4 > -- > 2.7.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] vpfe_capture: convert g/s_crop to g/s_selection.
On Mon, Jul 4, 2016 at 9:32 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This is part of a final push to convert all drivers to g/s_selection.
>
> Signed-off-by: Hans Verkuil
> Cc: Prabhakar Lad
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> ---
> drivers/media/platform/davinci/vpfe_capture.c | 52
> +--
> 1 file changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpfe_capture.c
> b/drivers/media/platform/davinci/vpfe_capture.c
> index 7767e07..6efb2f1 100644
> --- a/drivers/media/platform/davinci/vpfe_capture.c
> +++ b/drivers/media/platform/davinci/vpfe_capture.c
> @@ -1610,38 +1610,53 @@ static int vpfe_cropcap(struct file *file, void *priv,
>
> v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_cropcap\n");
>
> - if (vpfe_dev->std_index >= ARRAY_SIZE(vpfe_standards))
> + if (crop->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> return -EINVAL;
> + /* If std_index is invalid, then just return (== 1:1 aspect) */
> + if (vpfe_dev->std_index >= ARRAY_SIZE(vpfe_standards))
> + return 0;
>
> - memset(crop, 0, sizeof(struct v4l2_cropcap));
> - crop->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> - crop->bounds.width = crop->defrect.width =
> - vpfe_standards[vpfe_dev->std_index].width;
> - crop->bounds.height = crop->defrect.height =
> - vpfe_standards[vpfe_dev->std_index].height;
> crop->pixelaspect = vpfe_standards[vpfe_dev->std_index].pixelaspect;
> return 0;
> }
>
> -static int vpfe_g_crop(struct file *file, void *priv,
> -struct v4l2_crop *crop)
> +static int vpfe_g_selection(struct file *file, void *priv,
> + struct v4l2_selection *sel)
> {
> struct vpfe_device *vpfe_dev = video_drvdata(file);
>
> - v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_g_crop\n");
> + v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_g_selection\n");
>
> - crop->c = vpfe_dev->crop;
> + if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + return -EINVAL;
> +
> + switch (sel->target) {
> + case V4L2_SEL_TGT_CROP:
> + sel->r = vpfe_dev->crop;
> + break;
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + sel->r.width = vpfe_standards[vpfe_dev->std_index].width;
> + sel->r.height = vpfe_standards[vpfe_dev->std_index].height;
> + break;
> + default:
> + return -EINVAL;
> + }
> return 0;
> }
>
> -static int vpfe_s_crop(struct file *file, void *priv,
> -const struct v4l2_crop *crop)
> +static int vpfe_s_selection(struct file *file, void *priv,
> + struct v4l2_selection *sel)
> {
> struct vpfe_device *vpfe_dev = video_drvdata(file);
> - struct v4l2_rect rect = crop->c;
> + struct v4l2_rect rect = sel->r;
> int ret = 0;
>
> - v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_s_crop\n");
> + v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_s_selection\n");
> +
> + if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
> + sel->target != V4L2_SEL_TGT_CROP)
> + return -EINVAL;
>
> if (vpfe_dev->started) {
> /* make sure streaming is not started */
> @@ -1669,7 +1684,7 @@ static int vpfe_s_crop(struct file *file, void *priv,
> vpfe_dev->std_info.active_pixels) ||
> (rect.top + rect.height >
> vpfe_dev->std_info.active_lines)) {
> - v4l2_err(&vpfe_dev->v4l2_dev, "Error in S_CROP params\n");
> + v4l2_err(&vpfe_dev->v4l2_dev, "Error in S_SELECTION
> params\n");
> ret = -EINVAL;
> goto unlock_out;
> }
> @@ -1682,6 +1697,7 @@ static int vpfe_s_crop(struct file *file, void *priv,
> vpfe_dev->fmt.fmt.pix.bytesperline *
> vpfe_dev->fmt.fmt.pix.height;
> vpfe_dev->crop = rect;
> + sel->r = rect;
> unlock_out:
> mutex_unlock(&vpfe_dev->lock);
> return ret;
> @@ -1760,8 +1776,8 @@ static const struct v4l2_ioctl_ops vpfe_ioctl_ops = {
> .vidioc_streamon = vpfe_streamon,
> .vidioc_streamoff= vpfe_streamoff,
> .vidioc_cropcap = vpfe_cropcap,
> - .vidioc_g_crop = vpfe_g_crop,
> - .vidioc_s_crop = vpfe_s_crop,
> + .vidioc_g_selection = vpfe_g_selection,
> + .vidioc_s_selection = vpfe_s_selection,
> .vidioc_default = vpfe_param_handler,
> };
>
> --
> 2.8.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] s5p-g2d: Replace old driver with DRM version
Le mardi 12 juillet 2016 à 20:02 -0300, Mauro Carvalho Chehab a écrit : > I suspect that you'll be applying this one via DRM tree, so: > > Em Tue, 24 May 2016 15:28:13 +0200 > Krzysztof Kozlowski escreveu: > > > Remove the old non-DRM driver because it is now entirely supported > by > > exynos_drm_g2d driver. > > > > Cc: Kyungmin Park > > Cc: Kamil Debski > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Mauro Carvalho Chehab > > PS.: If you prefer to apply this one via my tree, I'm ok too. Just > let me know when the first patch gets merged upstream. Just a note that this is effectively an API break. cheers, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] [media] mtk-vcodec: fix more type mismatches
Hi Arnd, On Wed, 2016-07-13 at 15:17 +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 6:52:43 PM CEST pochun lin wrote: > > > diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > > b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > > index f4e18bb44cb9..9a600525b3c1 100644 > > > --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > > +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > > @@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct > > > venc_h264_inst *inst) > > > wb[i].iova = inst->work_bufs[i].dma_addr; > > > > > > mtk_vcodec_debug(inst, > > > - "work_buf[%d] va=0x%p iova=0x%p size=%zu", > > > + "work_buf[%d] va=0x%p iova=%pad size=%zu", > > >i, inst->work_bufs[i].va, > > > - (void *)inst->work_bufs[i].dma_addr, > > > + &inst->work_bufs[i].dma_addr, > > >inst->work_bufs[i].size); > > > } > > > > > > > This modified will dump dma_addr's address, not dma_addr value. > > In actually, we need to dump dma_addr value. > > According to Documentation/printk-formats.txt, it gets passed by > reference: > > | DMA addresses types dma_addr_t: > | > |%pad0x01234567 or 0x0123456789abcdef > | > |For printing a dma_addr_t type which can vary based on build options, > |regardless of the width of the CPU data path. Passed by reference. > > The whole point of the %pad/%pr/%pM/... format strings is to print > something that cannot be passed by value because the type is not > a fixed-size integer. > > Arnd Got it. And sorry I was wrong. Thanks your explain clearly. Best Regards PoChun -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [media] mtk-vcodec: fix more type mismatches
On Wednesday, July 13, 2016 6:52:43 PM CEST pochun lin wrote: > > diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > index f4e18bb44cb9..9a600525b3c1 100644 > > --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c > > @@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct > > venc_h264_inst *inst) > > wb[i].iova = inst->work_bufs[i].dma_addr; > > > > mtk_vcodec_debug(inst, > > - "work_buf[%d] va=0x%p iova=0x%p size=%zu", > > + "work_buf[%d] va=0x%p iova=%pad size=%zu", > >i, inst->work_bufs[i].va, > > - (void *)inst->work_bufs[i].dma_addr, > > + &inst->work_bufs[i].dma_addr, > >inst->work_bufs[i].size); > > } > > > > This modified will dump dma_addr's address, not dma_addr value. > In actually, we need to dump dma_addr value. According to Documentation/printk-formats.txt, it gets passed by reference: | DMA addresses types dma_addr_t: | |%pad0x01234567 or 0x0123456789abcdef | |For printing a dma_addr_t type which can vary based on build options, |regardless of the width of the CPU data path. Passed by reference. The whole point of the %pad/%pr/%pM/... format strings is to print something that cannot be passed by value because the type is not a fixed-size integer. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
Hi Geert, > On mips and parisc: > >drivers/bluetooth/btwilink.c: In function 'ti_st_open': >drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit > constant conversion [-Woverflow] > hst->reg_status = -EINPROGRESS; > >drivers/nfc/nfcwilink.c: In function 'nfcwilink_open': >drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant > conversion [-Woverflow] > drv->st_register_cb_status = -EINPROGRESS; > > There are actually two issues: > 1. Whether "char" is signed or unsigned depends on the architecture. > As the completion callback data is used to pass a (negative) error > code, it should always be signed. > 2. EINPROGRESS is 150 on mips, 245 on parisc. > Hence -EINPROGRESS doesn't fit in a signed 8-bit number. > > Change the callback status from "char" to "int" to fix these. > > Signed-off-by: Geert Uytterhoeven > --- > Compile-tested only. > --- > drivers/bluetooth/btwilink.c | 4 ++-- > drivers/media/radio/wl128x/fmdrv_common.c | 2 +- > drivers/misc/ti-st/st_core.c | 2 +- > drivers/nfc/nfcwilink.c | 4 ++-- > include/linux/ti_wilink_st.h | 2 +- > 5 files changed, 7 insertions(+), 7 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mtk-vcodec: fix type mismatches
On Wednesday, July 13, 2016 5:56:26 PM CEST tiffany lin wrote: > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > index 6dcae0a0a1f2..0b25a8700877 100644 > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > > @@ -1028,15 +1028,15 @@ static void mtk_venc_worker(struct work_struct > > *work) > > bs_buf.size = (size_t)dst_buf->planes[0].length; > > > > mtk_v4l2_debug(2, > > - "Framebuf VA=%p PA=%llx Size=0x%lx;VA=%p PA=0x%llx > > Size=0x%lx;VA=%p PA=0x%llx Size=%zu", > > + "Framebuf VA=%p PA=%pad Size=0x%zx;VA=%p PA=%pad > > Size=0x%zx;VA=%p PA=%pad Size=0x%zx", > > frm_buf.fb_addr[0].va, > > - (u64)frm_buf.fb_addr[0].dma_addr, > > + &frm_buf.fb_addr[0].dma_addr, > > frm_buf.fb_addr[0].size, > > frm_buf.fb_addr[1].va, > > - (u64)frm_buf.fb_addr[1].dma_addr, > > + &frm_buf.fb_addr[1].dma_addr, > > frm_buf.fb_addr[1].size, > > frm_buf.fb_addr[2].va, > > - (u64)frm_buf.fb_addr[2].dma_addr, > > + &frm_buf.fb_addr[2].dma_addr, > > frm_buf.fb_addr[2].size); > This change will make debug message dump address of dma_addr field but > not the value of the dma_addr we want. > How about change it from > PA=%llx -> PA=%u > (u64)frm_buf.fb_addr[0].dma_addr -> (u32)frm_buf.fb_addr[0].dma_addr, > The %llx works fine with the cast to u64, the change above is mainly for the "%lx" on a size_t causing a warning. The change to %pad is done in order to use a consistent output for the dma_addr_t, which had a leading "0x" in two cases but not in the first one. printk interprets %pad as a pointer to a dma_addr_t and prints the address, not the pointer to it, see Documentation/printk-formats.txt, which lets you avoid the type cast as well as the 0x. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] [media] pulse8-cec: fix non static symbol warning
From: Wei Yongjun
Fixes the following sparse warning:
drivers/staging/media/pulse8-cec/pulse8-cec.c:427:27: warning:
symbol 'pulse8_cec_adap_ops' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/staging/media/pulse8-cec/pulse8-cec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/pulse8-cec/pulse8-cec.c
b/drivers/staging/media/pulse8-cec/pulse8-cec.c
index 7d6d5ee..94f8590 100644
--- a/drivers/staging/media/pulse8-cec/pulse8-cec.c
+++ b/drivers/staging/media/pulse8-cec/pulse8-cec.c
@@ -424,7 +424,7 @@ static int pulse8_received(struct cec_adapter *adap, struct
cec_msg *msg)
return -ENOMSG;
}
-const struct cec_adap_ops pulse8_cec_adap_ops = {
+static const struct cec_adap_ops pulse8_cec_adap_ops = {
.adap_enable = pulse8_cec_adap_enable,
.adap_log_addr = pulse8_cec_adap_log_addr,
.adap_transmit = pulse8_cec_adap_transmit,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] doc-rst: improve CEC documentation
Lots of fixups relating to references. Signed-off-by: Hans Verkuil --- Changes since v1: - Always use refs for ioctls --- diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst b/Documentation/media/uapi/cec/cec-func-ioctl.rst index a07cc7c..d0279e6d 100644 --- a/Documentation/media/uapi/cec/cec-func-ioctl.rst +++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst @@ -29,7 +29,7 @@ Arguments ``request`` CEC ioctl request code as defined in the cec.h header file, for -example CEC_ADAP_G_CAPS. +example :ref:`CEC_ADAP_G_CAPS`. ``argp`` Pointer to a request-specific structure. diff --git a/Documentation/media/uapi/cec/cec-func-open.rst b/Documentation/media/uapi/cec/cec-func-open.rst index 245d679..cbf1176 100644 --- a/Documentation/media/uapi/cec/cec-func-open.rst +++ b/Documentation/media/uapi/cec/cec-func-open.rst @@ -32,11 +32,11 @@ Arguments Open flags. Access mode must be ``O_RDWR``. When the ``O_NONBLOCK`` flag is given, the -:ref:`CEC_RECEIVE` ioctl will return EAGAIN -error code when no message is available, and the -:ref:`CEC_TRANSMIT`, -:ref:`CEC_ADAP_S_PHYS_ADDR` and -:ref:`CEC_ADAP_S_LOG_ADDRS` ioctls +:ref:`CEC_RECEIVE ` ioctl will return the EAGAIN +error code when no message is available, and ioctls +:ref:`CEC_TRANSMIT `, +:ref:`CEC_ADAP_S_PHYS_ADDR ` and +:ref:`CEC_ADAP_S_LOG_ADDRS ` all act in non-blocking mode. Other flags have no effect. diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst index 2ca9199..eaedc63 100644 --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst @@ -34,7 +34,7 @@ Description .. note:: This documents the proposed CEC API. This API is not yet finalized and is currently only available as a staging kernel module. -All cec devices must support the :ref:`CEC_ADAP_G_CAPS` ioctl. To query +All cec devices must support :ref:`ioctl CEC_ADAP_G_CAPS `. To query device information, applications call the ioctl with a pointer to a struct :ref:`cec_caps `. The driver fills the structure and returns the information to the application. The ioctl never fails. @@ -100,7 +100,7 @@ returns the information to the application. The ioctl never fails. - 0x0001 - Userspace has to configure the physical address by calling - :ref:`CEC_ADAP_S_PHYS_ADDR`. If + :ref:`ioctl CEC_ADAP_S_PHYS_ADDR `. If this capability isn't set, then setting the physical address is handled by the kernel whenever the EDID is set (for an HDMI receiver) or read (for an HDMI transmitter). @@ -112,7 +112,7 @@ returns the information to the application. The ioctl never fails. - 0x0002 - Userspace has to configure the logical addresses by calling - :ref:`CEC_ADAP_S_LOG_ADDRS`. If + :ref:`ioctl CEC_ADAP_S_LOG_ADDRS `. If this capability isn't set, then the kernel will have configured this. @@ -123,7 +123,7 @@ returns the information to the application. The ioctl never fails. - 0x0004 - Userspace can transmit CEC messages by calling - :ref:`CEC_TRANSMIT`. This implies that + :ref:`ioctl CEC_TRANSMIT `. This implies that userspace can be a follower as well, since being able to transmit messages is a prerequisite of becoming a follower. If this capability isn't set, then the kernel will handle all CEC @@ -136,7 +136,7 @@ returns the information to the application. The ioctl never fails. - 0x0008 - Userspace can use the passthrough mode by calling - :ref:`CEC_S_MODE`. + :ref:`ioctl CEC_S_MODE `. - .. _`CEC-CAP-RC`: diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst index 7d7a3b4..eab734e 100644 --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst @@ -4,9 +4,9 @@ .. _CEC_ADAP_G_LOG_ADDRS: .. _CEC_ADAP_S_LOG_ADDRS: - -ioctl CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS - + +ioctls CEC_ADAP_G_LOG_ADDRS and CEC_ADAP_S_LOG_ADDRS + Name @@ -38,19 +38,17 @@ Description .. note:: This documents the proposed CEC API. This API is not yet finalized and is currently only available as a staging kernel module. -To query the current CEC logical addresses, applications call the -:ref:`CEC_ADAP_G_LOG_ADDRS` ioctl with a pointer to a -:c:type:`struct cec_log_addrs` structure where the drivers stores -the logical addresses. +To query the current CEC logical addresses, applications call +:ref:`ioctl CEC_ADA
Re: [PATCH 2/2] [media] docs-rst: escape [] characters
Em Wed, 13 Jul 2016 08:15:48 -0300
Mauro Carvalho Chehab escreveu:
> Those characters are used for citations. Better to escape, to
> avoid them to be misinterpreted.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> diff --git a/Documentation/media/uapi/v4l/dev-raw-vbi_files/vbi_625.pdf
> b/Documentation/media/uapi/v4l/dev-raw-vbi_files/vbi_625.pdf
> index
> 765235e33a4de256a0b3fbf64ffe52946190cac4..f672b52ef683b3b6da4a43167f67ecbecfd6dc36
> 100644
> GIT binary patch
> delta 18
> ZcmaDX^HgR-AtP%{w54Ut<`TyDJOD)g2G9Ti
>
> delta 16
> XcmaDV^H^p>AtQ6NrRC-_#`in`I2#5S
>
This is clearly wrong. I'm nacking my own patch ;)
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] doc-rst: use the right markup for footnotes
According with ReST spec, footnotes should be like: [#name], and not [name]. So, change them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/v4l/audio.rst | 4 +-- Documentation/media/uapi/v4l/control.rst | 4 +-- Documentation/media/uapi/v4l/dev-overlay.rst | 16 +- Documentation/media/uapi/v4l/dev-raw-vbi.rst | 18 +-- Documentation/media/uapi/v4l/dev-sliced-vbi.rst| 4 +-- Documentation/media/uapi/v4l/diff-v4l.rst | 36 +++--- Documentation/media/uapi/v4l/extended-controls.rst | 4 +-- Documentation/media/uapi/v4l/format.rst| 4 +-- Documentation/media/uapi/v4l/func-select.rst | 4 +-- Documentation/media/uapi/v4l/hist-v4l2.rst | 4 +-- Documentation/media/uapi/v4l/mmap.rst | 12 Documentation/media/uapi/v4l/open.rst | 12 Documentation/media/uapi/v4l/rw.rst| 8 ++--- Documentation/media/uapi/v4l/standard.rst | 4 +-- Documentation/media/uapi/v4l/userp.rst | 8 ++--- Documentation/media/uapi/v4l/vidioc-enumstd.rst| 26 Documentation/media/uapi/v4l/vidioc-g-fbuf.rst | 4 +-- Documentation/media/uapi/v4l/vidioc-g-tuner.rst| 8 ++--- Documentation/media/uapi/v4l/vidioc-querycap.rst | 4 +-- Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 4 +-- 20 files changed, 94 insertions(+), 94 deletions(-) diff --git a/Documentation/media/uapi/v4l/audio.rst b/Documentation/media/uapi/v4l/audio.rst index cd3057326de7..4dd11345866c 100644 --- a/Documentation/media/uapi/v4l/audio.rst +++ b/Documentation/media/uapi/v4l/audio.rst @@ -11,7 +11,7 @@ capture devices have inputs, output devices have outputs, zero or more each. Radio devices have no audio inputs or outputs. They have exactly one tuner which in fact *is* an audio source, but this API associates tuners with video inputs or outputs only, and radio devices have none of -these. [1]_ A connector on a TV card to loop back the received audio +these. [#f1]_ A connector on a TV card to loop back the received audio signal to a sound card is not considered an audio output. Audio and video inputs and outputs are associated. Selecting a video @@ -88,7 +88,7 @@ Example: Switching to the first audio input exit(EXIT_FAILURE); } -.. [1] +.. [#f1] Actually struct :ref:`v4l2_audio ` ought to have a ``tuner`` field like struct :ref:`v4l2_input `, not only making the API more consistent but also permitting radio devices diff --git a/Documentation/media/uapi/v4l/control.rst b/Documentation/media/uapi/v4l/control.rst index feb55ac14377..10ab53dd3163 100644 --- a/Documentation/media/uapi/v4l/control.rst +++ b/Documentation/media/uapi/v4l/control.rst @@ -17,7 +17,7 @@ device. All controls are accessed using an ID value. V4L2 defines several IDs for specific purposes. Drivers can also implement their own custom -controls using ``V4L2_CID_PRIVATE_BASE`` [1]_ and higher values. The +controls using ``V4L2_CID_PRIVATE_BASE`` [#f1]_ and higher values. The pre-defined control IDs have the prefix ``V4L2_CID_``, and are listed in :ref:`control-id`. The ID is used when querying the attributes of a control, and when getting or setting the current value. @@ -522,7 +522,7 @@ Example: Changing controls /* Errors ignored */ ioctl(fd, VIDIOC_S_CTRL, &control); -.. [1] +.. [#f1] The use of ``V4L2_CID_PRIVATE_BASE`` is problematic because different drivers may use the same ``V4L2_CID_PRIVATE_BASE`` ID for different controls. This makes it hard to programatically set such controls diff --git a/Documentation/media/uapi/v4l/dev-overlay.rst b/Documentation/media/uapi/v4l/dev-overlay.rst index bf8a418e7554..3edb53bfaa27 100644 --- a/Documentation/media/uapi/v4l/dev-overlay.rst +++ b/Documentation/media/uapi/v4l/dev-overlay.rst @@ -33,7 +33,7 @@ Applications should use different file descriptors for capturing and overlay. This must be supported by all drivers capable of simultaneous capturing and overlay. Optionally these drivers may also permit capturing and overlay with a single file descriptor for compatibility -with V4L and earlier versions of V4L2. [1]_ +with V4L and earlier versions of V4L2. [#f1]_ Querying Capabilities @@ -216,7 +216,7 @@ bits like: ((__u8 *) bitmap)[w.width * y + x / 8] & (1 << (x & 7)) -where ``0`` ??? x < ``w.width`` and ``0`` ??? y <``w.height``. [2]_ +where ``0`` ??? x < ``w.width`` and ``0`` ??? y <``w.height``. [#f2]_ When a clipping bit mask is not supported the driver ignores this field, its contents after calling :ref:`VIDIOC_S_FMT ` are @@ -227,7 +227,7 @@ Applications need not create a clip list or bit mask. When they pass both, or despite negotiating chroma-keying, the results are undefined. Regardless of the chosen method, the clipping abilities of the hardware may be limited in quantity or quality. The results when these
[PATCH 2/2] [media] docs-rst: escape [] characters
Those characters are used for citations. Better to escape, to avoid them to be misinterpreted. Signed-off-by: Mauro Carvalho Chehab --- .../media/uapi/cec/cec-ioc-adap-g-caps.rst | 4 +- .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst| 6 +-- Documentation/media/uapi/cec/cec-ioc-receive.rst | 2 +- Documentation/media/uapi/dvb/ca_data_types.rst | 4 +- Documentation/media/uapi/dvb/dmx-get-pes-pids.rst | 4 +- Documentation/media/uapi/dvb/dtv-property.rst | 6 +-- Documentation/media/uapi/dvb/examples.rst | 18 +++ .../media/uapi/dvb/fe-diseqc-recv-slave-reply.rst | 4 +- .../media/uapi/dvb/fe-diseqc-send-master-cmd.rst | 4 +- Documentation/media/uapi/dvb/fe-get-info.rst | 2 +- Documentation/media/uapi/dvb/video_types.rst | 4 +- .../media/uapi/mediactl/media-ioc-device-info.rst | 10 ++-- .../uapi/mediactl/media-ioc-enum-entities.rst | 4 +- .../media/uapi/mediactl/media-ioc-g-topology.rst | 10 ++-- Documentation/media/uapi/rc/keytable.c.rst | 42 +++ Documentation/media/uapi/v4l/buffer.rst| 4 +- Documentation/media/uapi/v4l/capture.c.rst | 14 ++--- Documentation/media/uapi/v4l/dev-osd.rst | 2 +- Documentation/media/uapi/v4l/dev-raw-vbi.rst | 4 +- .../media/uapi/v4l/dev-raw-vbi_files/vbi_625.pdf | Bin 3683 -> 3685 bytes Documentation/media/uapi/v4l/dev-sdr.rst | 2 +- Documentation/media/uapi/v4l/dev-sliced-vbi.rst| 58 ++--- Documentation/media/uapi/v4l/hist-v4l2.rst | 10 ++-- Documentation/media/uapi/v4l/pixfmt-003.rst| 4 +- Documentation/media/uapi/v4l/subdev-formats.rst| 2 +- Documentation/media/uapi/v4l/v4l2grab.c.rst| 2 +- .../media/uapi/v4l/vidioc-create-bufs.rst | 2 +- .../media/uapi/v4l/vidioc-dbg-g-chip-info.rst | 6 +-- .../media/uapi/v4l/vidioc-dbg-g-register.rst | 2 +- .../media/uapi/v4l/vidioc-decoder-cmd.rst | 2 +- Documentation/media/uapi/v4l/vidioc-dqevent.rst| 4 +- .../media/uapi/v4l/vidioc-dv-timings-cap.rst | 6 +-- .../media/uapi/v4l/vidioc-encoder-cmd.rst | 2 +- .../media/uapi/v4l/vidioc-enum-dv-timings.rst | 2 +- Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 4 +- .../media/uapi/v4l/vidioc-enum-frameintervals.rst | 2 +- .../media/uapi/v4l/vidioc-enum-framesizes.rst | 2 +- .../media/uapi/v4l/vidioc-enum-freq-bands.rst | 2 +- Documentation/media/uapi/v4l/vidioc-enuminput.rst | 4 +- Documentation/media/uapi/v4l/vidioc-enumoutput.rst | 4 +- Documentation/media/uapi/v4l/vidioc-enumstd.rst| 4 +- Documentation/media/uapi/v4l/vidioc-expbuf.rst | 2 +- Documentation/media/uapi/v4l/vidioc-g-audio.rst| 4 +- Documentation/media/uapi/v4l/vidioc-g-audioout.rst | 4 +- .../media/uapi/v4l/vidioc-g-dv-timings.rst | 2 +- Documentation/media/uapi/v4l/vidioc-g-edid.rst | 2 +- .../media/uapi/v4l/vidioc-g-enc-index.rst | 4 +- .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 4 +- Documentation/media/uapi/v4l/vidioc-g-fmt.rst | 2 +- .../media/uapi/v4l/vidioc-g-frequency.rst | 2 +- Documentation/media/uapi/v4l/vidioc-g-jpegcomp.rst | 4 +- .../media/uapi/v4l/vidioc-g-modulator.rst | 4 +- Documentation/media/uapi/v4l/vidioc-g-parm.rst | 6 +-- .../media/uapi/v4l/vidioc-g-selection.rst | 2 +- .../media/uapi/v4l/vidioc-g-sliced-vbi-cap.rst | 16 +++--- Documentation/media/uapi/v4l/vidioc-g-tuner.rst| 4 +- Documentation/media/uapi/v4l/vidioc-querycap.rst | 8 +-- Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 12 ++--- Documentation/media/uapi/v4l/vidioc-reqbufs.rst| 2 +- .../media/uapi/v4l/vidioc-s-hw-freq-seek.rst | 2 +- .../uapi/v4l/vidioc-subdev-enum-frame-interval.rst | 2 +- .../uapi/v4l/vidioc-subdev-enum-frame-size.rst | 2 +- .../uapi/v4l/vidioc-subdev-enum-mbus-code.rst | 2 +- .../media/uapi/v4l/vidioc-subdev-g-crop.rst| 2 +- .../media/uapi/v4l/vidioc-subdev-g-fmt.rst | 2 +- .../uapi/v4l/vidioc-subdev-g-frame-interval.rst| 2 +- .../media/uapi/v4l/vidioc-subdev-g-selection.rst | 2 +- .../media/uapi/v4l/vidioc-subscribe-event.rst | 2 +- 68 files changed, 188 insertions(+), 188 deletions(-) diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst index 2ca9199c3305..8d9d55757d45 100644 --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst @@ -52,7 +52,7 @@ returns the information to the application. The ioctl never fails. - char - - ``driver[32]`` + - ``driver\[32\]`` - The name of the cec adapter driver. @@ -60,7 +60,7 @@ returns the information to the application. The ioctl never fails.
Re: [PATCH 2/9] async: Introduce kfence, a N:M completion mechanism
On Wed, Jul 13, 2016 at 11:38:52AM +0200, Peter Zijlstra wrote: > On Fri, Jun 24, 2016 at 10:08:46AM +0100, Chris Wilson wrote: > > diff --git a/kernel/async.c b/kernel/async.c > > index d2edd6efec56..d0bcb7cc4884 100644 > > --- a/kernel/async.c > > +++ b/kernel/async.c > > @@ -50,6 +50,7 @@ asynchronous and synchronous parts of the kernel. > > > > #include > > #include > > +#include > > #include > > #include > > #include > > So why does this live in async.c? It got its own header, why not also > give it its own .c file? I started in kernel/async (since my first goal was fine-grained async_work serialisation). It is still in kernel/async.c as the embedded fence inside the async_work needs a return code to integrate. I should have done that before posting... > Also, I'm not a particular fan of the k* naming, but I see 'fence' is > already taken. Agreed, I really want to rename the dma-buf fence to struct dma_fence - we would need to do that whilst it dma-buf fencing is still in its infancy. > > +/** > > + * DOC: kfence overview > > + * > > + * kfences provide synchronisation barriers between multiple processes. > > + * They are very similar to completions, or a pthread_barrier. Where > > + * kfence differs from completions is their ability to track multiple > > + * event sources rather than being a singular "completion event". Similar > > + * to completions, multiple processes or other kfences can listen or wait > > + * upon a kfence to signal its completion. > > + * > > + * The kfence is a one-shot flag, signaling that work has progressed passed > > + * a certain point (as measured by completion of all events the kfence is > > + * listening for) and the waiters upon kfence may proceed. > > + * > > + * kfences provide both signaling and waiting routines: > > + * > > + * kfence_pending() > > + * > > + * indicates that the kfence should itself wait for another signal. A > > + * kfence created by kfence_create() starts in the pending state. > > I would much prefer: > > * - kfence_pending(): indicates that the kfence should itself wait for > *another signal. A kfence created by kfence_create() starts in the > *pending state. > > Which is much clearer in what text belongs where. Ok, I was just copying the style from Documentation/scheduler/completion.txt > Also, what !? I don't get what this function does. Hmm. Something more like: "To check the state of a kfence without changing it in any way, call kfence_pending(), which returns true if the kfence is still waiting for its event sources to be signaled." s/signaled/completed/ depending on kfence_signal() vs kfence_complete() > > + * > > + * kfence_signal() > > + * > > + * undoes the earlier pending notification and allows the fence to complete > > + * if all pending events have then been signaled. > > So I know _signal() is the posix thing, but seeing how we already > completions, how about being consistent with those and use _complete() > for this? Possibly, but we also have the dma-buf fences to try and be fairly consistent with. struct completion is definitely a closer sibling though. The biggest conceptual change from completions though is that a kfence will be signaled multiple times before it is complete - I think that is a strong argument in favour of using _signal(). > > + * > > + * kfence_wait() > > + * > > + * allows the caller to sleep (uninterruptibly) until the fence is > > complete. > > whitespace to separate the description of kfence_wait() from whatever > else follows. > > > + * Meanwhile, > > + * > > + * kfence_complete() > > + * > > + * reports whether or not the kfence has been passed. > > kfence_done(), again to match completions. Ok, will do a spin with completion naming convention and see how that fits in (and complete the extraction to a separate .c) -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
Hi Mauro, >> On mips and parisc: >> >>drivers/bluetooth/btwilink.c: In function 'ti_st_open': >>drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit >> constant conversion [-Woverflow] >> hst->reg_status = -EINPROGRESS; >> >>drivers/nfc/nfcwilink.c: In function 'nfcwilink_open': >>drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant >> conversion [-Woverflow] >> drv->st_register_cb_status = -EINPROGRESS; >> >> There are actually two issues: >> 1. Whether "char" is signed or unsigned depends on the architecture. >> As the completion callback data is used to pass a (negative) error >> code, it should always be signed. >> 2. EINPROGRESS is 150 on mips, 245 on parisc. >> Hence -EINPROGRESS doesn't fit in a signed 8-bit number. >> >> Change the callback status from "char" to "int" to fix these. >> >> Signed-off-by: Geert Uytterhoeven > > Patch looks sane to me, but who will apply it? > > Anyway: > > Acked-by: Mauro Carvalho Chehab I can take it through bluetooth-next if there is no objection. Samuel, are you fine with that? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] async: Introduce kfence, a N:M completion mechanism
On Wed, Jul 13, 2016 at 11:20:14AM +0100, Chris Wilson wrote: > On Wed, Jul 13, 2016 at 11:38:52AM +0200, Peter Zijlstra wrote: > > Also, I'm not a particular fan of the k* naming, but I see 'fence' is > > already taken. > > Agreed, I really want to rename the dma-buf fence to struct dma_fence - > we would need to do that whilst it dma-buf fencing is still in its infancy. +1 on dma_fence, seems to make more sense than plain struct fence. Probably best to do after the recent pile of work from Gustavo to de-stage sync_file has landed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
Hi Marcel, On Wed, Jul 13, 2016 at 11:56:02AM +0100, Marcel Holtmann wrote: > Hi Mauro, > > >> On mips and parisc: > >> > >>drivers/bluetooth/btwilink.c: In function 'ti_st_open': > >>drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit > >> constant conversion [-Woverflow] > >> hst->reg_status = -EINPROGRESS; > >> > >>drivers/nfc/nfcwilink.c: In function 'nfcwilink_open': > >>drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant > >> conversion [-Woverflow] > >> drv->st_register_cb_status = -EINPROGRESS; > >> > >> There are actually two issues: > >> 1. Whether "char" is signed or unsigned depends on the architecture. > >> As the completion callback data is used to pass a (negative) error > >> code, it should always be signed. > >> 2. EINPROGRESS is 150 on mips, 245 on parisc. > >> Hence -EINPROGRESS doesn't fit in a signed 8-bit number. > >> > >> Change the callback status from "char" to "int" to fix these. > >> > >> Signed-off-by: Geert Uytterhoeven > > > > Patch looks sane to me, but who will apply it? > > > > Anyway: > > > > Acked-by: Mauro Carvalho Chehab > > I can take it through bluetooth-next if there is no objection. > > Samuel, are you fine with that? Yes, please go ahead. Cheers, Samuel. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [media] mtk-vcodec: fix more type mismatches
Hi Arnd,
On Wed, 2016-07-13 at 10:47 +0200, Arnd Bergmann wrote:
> The newly added mtk-vcodec driver produces a number of warnings in an ARM
> allmodconfig build, mainly since it assumes that dma_addr_t is 32-bit wide:
>
> mtk-vcodec/venc/venc_vp8_if.c: In function 'vp8_enc_alloc_work_buf':
> mtk-vcodec/venc/venc_vp8_if.c:212:191: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> mtk-vcodec/venc/venc_h264_if.c: In function 'h264_enc_alloc_work_buf':
> mtk-vcodec/venc/venc_h264_if.c:297:190: error: cast to pointer from integer
> of different size [-Werror=int-to-pointer-cast]
>
> This rearranges the format strings and type casts to what they should have
> been
> in order to avoid the warnings. e0f80d8d62f5 ("[media] mtk-vcodec: fix two
> compiler
> warnings") fixed some of the problems that were introduced at the same time,
> but
> missed two others.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c | 4 ++--
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> index f4e18bb44cb9..9a600525b3c1 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> @@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct venc_h264_inst
> *inst)
> wb[i].iova = inst->work_bufs[i].dma_addr;
>
> mtk_vcodec_debug(inst,
> - "work_buf[%d] va=0x%p iova=0x%p size=%zu",
> + "work_buf[%d] va=0x%p iova=%pad size=%zu",
>i, inst->work_bufs[i].va,
> - (void *)inst->work_bufs[i].dma_addr,
> + &inst->work_bufs[i].dma_addr,
>inst->work_bufs[i].size);
> }
>
This modified will dump dma_addr's address, not dma_addr value.
In actually, we need to dump dma_addr value.
Thanks.
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> index 5b4ef0f1740c..60bbcd2a0510 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> @@ -210,9 +210,9 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst
> *inst)
> wb[i].iova = inst->work_bufs[i].dma_addr;
>
> mtk_vcodec_debug(inst,
> - "work_bufs[%d] va=0x%p,iova=0x%p,size=%zu",
> + "work_bufs[%d] va=0x%p,iova=%pad,size=%zu",
>i, inst->work_bufs[i].va,
> - (void *)inst->work_bufs[i].dma_addr,
> + &inst->work_bufs[i].dma_addr,
>inst->work_bufs[i].size);
> }
>
The same as above.
Best Regards
PoChun
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
Em Mon, 6 Jun 2016 11:02:03 +0200
Geert Uytterhoeven escreveu:
> On mips and parisc:
>
> drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit
> constant conversion [-Woverflow]
>hst->reg_status = -EINPROGRESS;
>
> drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant
> conversion [-Woverflow]
> drv->st_register_cb_status = -EINPROGRESS;
>
> There are actually two issues:
> 1. Whether "char" is signed or unsigned depends on the architecture.
> As the completion callback data is used to pass a (negative) error
> code, it should always be signed.
> 2. EINPROGRESS is 150 on mips, 245 on parisc.
> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
>
> Change the callback status from "char" to "int" to fix these.
>
> Signed-off-by: Geert Uytterhoeven
Patch looks sane to me, but who will apply it?
Anyway:
Acked-by: Mauro Carvalho Chehab
> ---
> Compile-tested only.
> ---
> drivers/bluetooth/btwilink.c | 4 ++--
> drivers/media/radio/wl128x/fmdrv_common.c | 2 +-
> drivers/misc/ti-st/st_core.c | 2 +-
> drivers/nfc/nfcwilink.c | 4 ++--
> include/linux/ti_wilink_st.h | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> index 24a652f9252be899..485281b3f1677678 100644
> --- a/drivers/bluetooth/btwilink.c
> +++ b/drivers/bluetooth/btwilink.c
> @@ -51,7 +51,7 @@
> */
> struct ti_st {
> struct hci_dev *hdev;
> - char reg_status;
> + int reg_status;
> long (*st_write) (struct sk_buff *);
> struct completion wait_reg_completion;
> };
> @@ -83,7 +83,7 @@ static inline void ti_st_tx_complete(struct ti_st *hst, int
> pkt_type)
> * status.ti_st_open() function will wait for signal from this
> * API when st_register() function returns ST_PENDING.
> */
> -static void st_reg_completion_cb(void *priv_data, char data)
> +static void st_reg_completion_cb(void *priv_data, int data)
> {
> struct ti_st *lhst = priv_data;
>
> diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
> b/drivers/media/radio/wl128x/fmdrv_common.c
> index 3f9e6df7d837ac27..642b89c66bcb99eb 100644
> --- a/drivers/media/radio/wl128x/fmdrv_common.c
> +++ b/drivers/media/radio/wl128x/fmdrv_common.c
> @@ -1472,7 +1472,7 @@ static long fm_st_receive(void *arg, struct sk_buff
> *skb)
> * Called by ST layer to indicate protocol registration completion
> * status.
> */
> -static void fm_st_reg_comp_cb(void *arg, char data)
> +static void fm_st_reg_comp_cb(void *arg, int data)
> {
> struct fmdev *fmdev;
>
> diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
> index dcdbd58672ccc6d2..00051590e00f9647 100644
> --- a/drivers/misc/ti-st/st_core.c
> +++ b/drivers/misc/ti-st/st_core.c
> @@ -141,7 +141,7 @@ static void st_send_frame(unsigned char chnl_id, struct
> st_data_s *st_gdata)
> * This function is being called with spin lock held, protocol drivers are
> * only expected to complete their waits and do nothing more than that.
> */
> -static void st_reg_complete(struct st_data_s *st_gdata, char err)
> +static void st_reg_complete(struct st_data_s *st_gdata, int err)
> {
> unsigned char i = 0;
> pr_info(" %s ", __func__);
> diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
> index f81e500e765061fd..3fbd18b8e473f696 100644
> --- a/drivers/nfc/nfcwilink.c
> +++ b/drivers/nfc/nfcwilink.c
> @@ -94,7 +94,7 @@ struct nfcwilink {
> struct nci_dev *ndev;
> unsigned long flags;
>
> - charst_register_cb_status;
> + int st_register_cb_status;
> long(*st_write) (struct sk_buff *);
>
> struct completion completed;
> @@ -320,7 +320,7 @@ exit:
> }
>
> /* Called by ST when registration is complete */
> -static void nfcwilink_register_complete(void *priv_data, char data)
> +static void nfcwilink_register_complete(void *priv_data, int data)
> {
> struct nfcwilink *drv = priv_data;
>
> diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
> index 0a0d56834c8eb412..f2293028ab9d65e6 100644
> --- a/include/linux/ti_wilink_st.h
> +++ b/include/linux/ti_wilink_st.h
> @@ -71,7 +71,7 @@ struct st_proto_s {
> enum proto_type type;
> long (*recv) (void *, struct sk_buff *);
> unsigned char (*match_packet) (const unsigned char *data);
> - void (*reg_complete_cb) (void *, char data);
> + void (*reg_complete_cb) (void *, int data);
> long (*write) (struct sk_buff *skb);
> void *priv_data;
>
--
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body
Re: [PATCH 2/2] doc-rst: improve CEC documentation
Em Wed, 13 Jul 2016 12:10:23 +0200 Hans Verkuil escreveu: > On 07/13/16 12:06, Mauro Carvalho Chehab wrote: > > Hi Hans, > > > > Em Tue, 12 Jul 2016 20:07:45 +0200 > > Hans Verkuil escreveu: > > > >> From: Hans Verkuil > >> > >> Lots of fixups relating to references. > >> > >> Signed-off-by: Hans Verkuil > >> --- > >> Documentation/media/uapi/cec/cec-func-ioctl.rst| 2 +- > >> Documentation/media/uapi/cec/cec-func-open.rst | 10 +++ > >> .../media/uapi/cec/cec-ioc-adap-g-caps.rst | 18 ++-- > >> .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst| 14 - > >> .../media/uapi/cec/cec-ioc-adap-g-phys-addr.rst| 14 - > >> Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 2 +- > >> Documentation/media/uapi/cec/cec-ioc-g-mode.rst| 34 > >> +- > >> Documentation/media/uapi/cec/cec-ioc-receive.rst | 28 +- > >> 8 files changed, 58 insertions(+), 64 deletions(-) > >> > >> diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst > >> b/Documentation/media/uapi/cec/cec-func-ioctl.rst > >> index a07cc7c..d0279e6d 100644 > >> --- a/Documentation/media/uapi/cec/cec-func-ioctl.rst > >> +++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst > >> @@ -29,7 +29,7 @@ Arguments > >> > >> ``request`` > >> CEC ioctl request code as defined in the cec.h header file, for > >> -example CEC_ADAP_G_CAPS. > >> +example :ref:`CEC_ADAP_G_CAPS`. > >> > >> ``argp`` > >> Pointer to a request-specific structure. > >> diff --git a/Documentation/media/uapi/cec/cec-func-open.rst > >> b/Documentation/media/uapi/cec/cec-func-open.rst > >> index 245d679..cbf1176 100644 > >> --- a/Documentation/media/uapi/cec/cec-func-open.rst > >> +++ b/Documentation/media/uapi/cec/cec-func-open.rst > >> @@ -32,11 +32,11 @@ Arguments > >> Open flags. Access mode must be ``O_RDWR``. > >> > >> When the ``O_NONBLOCK`` flag is given, the > >> -:ref:`CEC_RECEIVE` ioctl will return EAGAIN > >> -error code when no message is available, and the > >> -:ref:`CEC_TRANSMIT`, > >> -:ref:`CEC_ADAP_S_PHYS_ADDR` and > >> -:ref:`CEC_ADAP_S_LOG_ADDRS` ioctls > >> +:ref:`CEC_RECEIVE ` ioctl will return the EAGAIN > >> +error code when no message is available, and ioctls > >> +:ref:`CEC_TRANSMIT `, > >> +:ref:`CEC_ADAP_S_PHYS_ADDR ` and > >> +:ref:`CEC_ADAP_S_LOG_ADDRS ` > >> all act in non-blocking mode. > >> > >> Other flags have no effect. > >> diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > >> b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > >> index 2ca9199..63b808e 100644 > >> --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > >> +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > >> @@ -34,7 +34,7 @@ Description > >> .. note:: This documents the proposed CEC API. This API is not yet > >> finalized > >> and is currently only available as a staging kernel module. > >> > >> -All cec devices must support the :ref:`CEC_ADAP_G_CAPS` ioctl. To query > >> +All cec devices must support ``CEC_ADAP_G_CAPS``. To query > > > > Why are you removing the ref here and on other similar places? If you > > remove it, the font and font color for it will be different and > > inconsistent. It will also be inconsistent with the other places > > within the document, were it is using a reference everywhere. > > What's the point of having a link to the same page that you are watching? > I also found it very cumbersome and ugly having to write e.g. > > :ref:`CEC_ADAP_S_PHYS_ADDR > > all the time. That is fine if it actually points to another page (it serves a > real purpose then), but on the page itself I think it is ugly. We never did > that with the DocBook documentation either. With DocBook, all ioctls, including the references, were . So, they all display the same way, no matter if they're a reference or not. However, with ReST, it is *either* a constant or a reference. So, if you use ``foo`` or :ref:`foo`, the fonts used will be different, with causes, IMHO, an ugly output, as it violates the font convention used within the document. With regards to DocBook, this was really messy. I've seen the same ioctl represented there in three ways, sometimes, even at the same file. Just to get a random example: Documentation/DocBook/media/v4l/io.xml:VIDIOC_QUERYBUF, VIDIOC_QUERYBUF Documentation/DocBook/media/v4l/vidioc-querybuf.xml: VIDIOC_QUERYBUF (You'll see lot of other cases were not even were used... Documentation/DocBook/media/v4l/v4l2.xml is lot of such cases) We should stick with just *one* typographic convention, and not randomly change it along the document. It looks really ugly when we change the typographic convention for ioctls like what this patch does. Regards Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordo
Re: [PATCH 3/9] async: Extend kfence to allow struct embedding
On Fri, Jun 24, 2016 at 10:08:47AM +0100, Chris Wilson wrote:
> @@ -151,7 +161,11 @@ static void kfence_free(struct kref *kref)
>
> WARN_ON(atomic_read(&fence->pending) > 0);
>
> - kfree(fence);
> + if (fence->flags) {
> + kfence_notify_t fn = (kfence_notify_t)fence->flags;
Maybe provide an inline helper for that conversion and also mask out the
low bits, just to be careful. You're assuming they're not set here,
which seems like a dangerous thing.
> + fn(fence);
> + } else
> + kfree(fence);
Also Codingstyle wants braces on both branches if its on one.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] async: Wrap hrtimer to provide a time source for a kfence
On Fri, Jun 24, 2016 at 10:08:49AM +0100, Chris Wilson wrote: > kfence_add_delay() is a convenience wrapper around > hrtimer_start_range_ns() to provide a time source for a kfence graph. Changelog could be greatly improved by telling us why we'd want this. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v4.7] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.7-2 For two regression fixes: - A regression when handling VIDIOC_CROPCAP at the media core; - A regression at adv7604 that was ignoring pad number in subdev ops. Thanks! Mauro The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: Linux 4.7-rc2 (2016-06-05 14:31:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.7-2 for you to fetch changes up to 6519c3d7b8621c9f4333c98ed4b703029b51ba79: [media] adv7604: Don't ignore pad number in subdev DV timings pad operations (2016-06-07 15:33:54 -0300) media fixes for v4.7-rc7 Hans Verkuil (1): [media] v4l2-ioctl: fix stupid mistake in cropcap condition Laurent Pinchart (1): [media] adv7604: Don't ignore pad number in subdev DV timings pad operations Mauro Carvalho Chehab (1): Merge tag 'v4.7-rc2' into v4l_for_linus drivers/media/i2c/adv7604.c | 46 +++- drivers/media/v4l2-core/v4l2-ioctl.c | 2 +- 2 files changed, 36 insertions(+), 12 deletions(-) Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] async: Introduce kfence, a N:M completion mechanism
On Fri, Jun 24, 2016 at 10:08:46AM +0100, Chris Wilson wrote:
> +struct kfence {
> + wait_queue_head_t wait;
> + unsigned long flags;
> + struct kref kref;
> + atomic_t pending;
> +};
> +#define KFENCE_CHECKED_BIT 0
> +
> +static void kfence_free(struct kref *kref)
> +{
> + struct kfence *fence = container_of(kref, typeof(*fence), kref);
> +
> + WARN_ON(atomic_read(&fence->pending) > 0);
> +
> + kfree(fence);
> +}
> +
> +/**
> + * kfence_put - release a reference to a kfence
> + * @fence: the kfence being disposed of
> + */
> +void kfence_put(struct kfence *fence)
> +{
> + if (fence)
> + kref_put(&fence->kref, kfence_free);
It seems very poor semantics to allow to put NULL, that would indicate a
severe logic fail.
> +}
> +EXPORT_SYMBOL_GPL(kfence_put);
> +/**
> + * kfence_get - acquire a reference to a kfence
> + * @fence: the kfence being used
> + *
> + * Returns the pointer to the kfence, with its reference count incremented.
> + */
> +struct kfence *kfence_get(struct kfence *fence)
> +{
> + if (fence)
> + kref_get(&fence->kref);
Similar, getting NULL is just horrible taste.
> + return fence;
> +}
> +EXPORT_SYMBOL_GPL(kfence_get);
> +static void __kfence_wake_up_all(struct kfence *fence,
> + struct list_head *continuation)
> +{
> + wait_queue_head_t *x = &fence->wait;
> + unsigned long flags;
> +
> + /* To prevent unbounded recursion as we traverse the graph
Broken comment style.
> + * of kfences, we move the task_list from this ready fence
> + * to the tail of the current fence we are signaling.
> + */
> + spin_lock_irqsave_nested(&x->lock, flags, 1 + !!continuation);
> + if (continuation)
> + list_splice_tail_init(&x->task_list, continuation);
> + else while (!list_empty(&x->task_list))
> + __wake_up_locked_key(x, TASK_NORMAL, &x->task_list);
> + spin_unlock_irqrestore(&x->lock, flags);
> +}
> +
> +static void __kfence_signal(struct kfence *fence,
> + struct list_head *continuation)
> +{
> + if (!atomic_dec_and_test(&fence->pending))
> + return;
> +
> + atomic_dec(&fence->pending);
You decrement twice?
> + __kfence_wake_up_all(fence, continuation);
> +}
> +
> +/**
> + * kfence_pending - mark the fence as pending a signal
I would say: increment the pending count, requiring one more completion
before the fence is done.
'Mark' completely misses the point. You need to balance these increments
with decrements, its not a boolean state.
> + * @fence: the kfence to be signaled
> + *
> + */
> +void kfence_pending(struct kfence *fence)
> +{
> + WARN_ON(atomic_inc_return(&fence->pending) <= 1);
> +}
> +EXPORT_SYMBOL_GPL(kfence_pending);
> +/**
> + * kfence_create - create a fence
> + * @gfp: the allowed allocation type
> + *
> + * A fence is created with a reference count of one, and pending a signal.
> + * After you have completed setting up the fence for use, call
> kfence_signal()
> + * to signal completion.
> + *
> + * Returns the newly allocated fence, or NULL on error.
> + */
> +struct kfence *kfence_create(gfp_t gfp)
> +{
> + struct kfence *fence;
> +
> + fence = kmalloc(sizeof(*fence), gfp);
> + if (!fence)
> + return NULL;
> +
> + kfence_init(fence);
> + return fence;
> +}
> +EXPORT_SYMBOL_GPL(kfence_create);
Why? What is the purpose of this here thing? We never provide allocation
wrappers.
> +
> +/**
> + * kfence_add - set one fence to wait upon another
Since you're going to do a whole lot other kfence_add_$foo() thingies,
why isn't this called kfence_add_kfence() ?
> + * @fence: this kfence
> + * @signaler: target kfence to wait upon
> + * @gfp: the allowed allocation type
> + *
> + * kfence_add() causes the @fence to wait upon completion of @signaler.
> + * Internally the @fence is marked as pending a signal from @signaler.
> + *
> + * Returns 1 if the @fence was added to the waiqueue of @signaler, 0
> + * if @signaler was already complete, or a negative error code.
> + */
> +int kfence_add(struct kfence *fence, struct kfence *signaler, gfp_t gfp)
> +{
> + wait_queue_t *wq;
> + unsigned long flags;
> + int pending;
> +
> + if (!signaler || kfence_complete(signaler))
Again, wth would you allow adding NULL? That's just horrible.
> + return 0;
> +
> + /* The dependency graph must be acyclic */
> + if (unlikely(kfence_check_if_after(fence, signaler)))
> + return -EINVAL;
> +
> + wq = kmalloc(sizeof(*wq), gfp);
> + if (unlikely(!wq)) {
> + if (!gfpflags_allow_blocking(gfp))
> + return -ENOMEM;
> +
> + kfence_wait(signaler);
> + return 0;
> + }
> +
> + wq->flags = 0;
> + wq->func = kfence_wake;
> + wq->private = kfence_get(fence);
> +
> + kfence_pending(fence);
> +
> + spin_lock_irqsave(&signaler->wait.lock,
Re: [PATCH 2/2] doc-rst: improve CEC documentation
Hi Hans, Em Tue, 12 Jul 2016 20:07:45 +0200 Hans Verkuil escreveu: > From: Hans Verkuil > > Lots of fixups relating to references. > > Signed-off-by: Hans Verkuil > --- > Documentation/media/uapi/cec/cec-func-ioctl.rst| 2 +- > Documentation/media/uapi/cec/cec-func-open.rst | 10 +++ > .../media/uapi/cec/cec-ioc-adap-g-caps.rst | 18 ++-- > .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst| 14 - > .../media/uapi/cec/cec-ioc-adap-g-phys-addr.rst| 14 - > Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 2 +- > Documentation/media/uapi/cec/cec-ioc-g-mode.rst| 34 > +- > Documentation/media/uapi/cec/cec-ioc-receive.rst | 28 +- > 8 files changed, 58 insertions(+), 64 deletions(-) > > diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst > b/Documentation/media/uapi/cec/cec-func-ioctl.rst > index a07cc7c..d0279e6d 100644 > --- a/Documentation/media/uapi/cec/cec-func-ioctl.rst > +++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst > @@ -29,7 +29,7 @@ Arguments > > ``request`` > CEC ioctl request code as defined in the cec.h header file, for > -example CEC_ADAP_G_CAPS. > +example :ref:`CEC_ADAP_G_CAPS`. > > ``argp`` > Pointer to a request-specific structure. > diff --git a/Documentation/media/uapi/cec/cec-func-open.rst > b/Documentation/media/uapi/cec/cec-func-open.rst > index 245d679..cbf1176 100644 > --- a/Documentation/media/uapi/cec/cec-func-open.rst > +++ b/Documentation/media/uapi/cec/cec-func-open.rst > @@ -32,11 +32,11 @@ Arguments > Open flags. Access mode must be ``O_RDWR``. > > When the ``O_NONBLOCK`` flag is given, the > -:ref:`CEC_RECEIVE` ioctl will return EAGAIN > -error code when no message is available, and the > -:ref:`CEC_TRANSMIT`, > -:ref:`CEC_ADAP_S_PHYS_ADDR` and > -:ref:`CEC_ADAP_S_LOG_ADDRS` ioctls > +:ref:`CEC_RECEIVE ` ioctl will return the EAGAIN > +error code when no message is available, and ioctls > +:ref:`CEC_TRANSMIT `, > +:ref:`CEC_ADAP_S_PHYS_ADDR ` and > +:ref:`CEC_ADAP_S_LOG_ADDRS ` > all act in non-blocking mode. > > Other flags have no effect. > diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > index 2ca9199..63b808e 100644 > --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst > @@ -34,7 +34,7 @@ Description > .. note:: This documents the proposed CEC API. This API is not yet finalized > and is currently only available as a staging kernel module. > > -All cec devices must support the :ref:`CEC_ADAP_G_CAPS` ioctl. To query > +All cec devices must support ``CEC_ADAP_G_CAPS``. To query Why are you removing the ref here and on other similar places? If you remove it, the font and font color for it will be different and inconsistent. It will also be inconsistent with the other places within the document, were it is using a reference everywhere. The same note apply to other similar changes. > device information, applications call the ioctl with a pointer to a > struct :ref:`cec_caps `. The driver fills the structure and > returns the information to the application. The ioctl never fails. > @@ -99,8 +99,8 @@ returns the information to the application. The ioctl never > fails. > > - 0x0001 > > - - Userspace has to configure the physical address by calling > - :ref:`CEC_ADAP_S_PHYS_ADDR`. If > + - Userspace has to configure the physical address by calling ioctl > + :ref:`CEC_ADAP_S_PHYS_ADDR `. If > this capability isn't set, then setting the physical address is > handled by the kernel whenever the EDID is set (for an HDMI > receiver) or read (for an HDMI transmitter). > @@ -111,8 +111,8 @@ returns the information to the application. The ioctl > never fails. > > - 0x0002 > > - - Userspace has to configure the logical addresses by calling > - :ref:`CEC_ADAP_S_LOG_ADDRS`. If > + - Userspace has to configure the logical addresses by calling ioctl > + :ref:`CEC_ADAP_S_LOG_ADDRS `. If > this capability isn't set, then the kernel will have configured > this. > > @@ -122,8 +122,8 @@ returns the information to the application. The ioctl > never fails. > > - 0x0004 > > - - Userspace can transmit CEC messages by calling > - :ref:`CEC_TRANSMIT`. This implies that > + - Userspace can transmit CEC messages by calling ioctl > + :ref:`CEC_TRANSMIT `. This implies that > userspace can be a follower as well, since being able to transmit > messages is a prerequisite of becoming a follower. If this > capability isn't set, then the kernel will handle all CEC > @@ -135,8 +135,8 @@ returns the information to the application. The ioctl > never fails. >
Re: [PATCH 2/2] doc-rst: improve CEC documentation
On 07/13/16 12:06, Mauro Carvalho Chehab wrote: > Hi Hans, > > Em Tue, 12 Jul 2016 20:07:45 +0200 > Hans Verkuil escreveu: > >> From: Hans Verkuil >> >> Lots of fixups relating to references. >> >> Signed-off-by: Hans Verkuil >> --- >> Documentation/media/uapi/cec/cec-func-ioctl.rst| 2 +- >> Documentation/media/uapi/cec/cec-func-open.rst | 10 +++ >> .../media/uapi/cec/cec-ioc-adap-g-caps.rst | 18 ++-- >> .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst| 14 - >> .../media/uapi/cec/cec-ioc-adap-g-phys-addr.rst| 14 - >> Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 2 +- >> Documentation/media/uapi/cec/cec-ioc-g-mode.rst| 34 >> +- >> Documentation/media/uapi/cec/cec-ioc-receive.rst | 28 +- >> 8 files changed, 58 insertions(+), 64 deletions(-) >> >> diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst >> b/Documentation/media/uapi/cec/cec-func-ioctl.rst >> index a07cc7c..d0279e6d 100644 >> --- a/Documentation/media/uapi/cec/cec-func-ioctl.rst >> +++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst >> @@ -29,7 +29,7 @@ Arguments >> >> ``request`` >> CEC ioctl request code as defined in the cec.h header file, for >> -example CEC_ADAP_G_CAPS. >> +example :ref:`CEC_ADAP_G_CAPS`. >> >> ``argp`` >> Pointer to a request-specific structure. >> diff --git a/Documentation/media/uapi/cec/cec-func-open.rst >> b/Documentation/media/uapi/cec/cec-func-open.rst >> index 245d679..cbf1176 100644 >> --- a/Documentation/media/uapi/cec/cec-func-open.rst >> +++ b/Documentation/media/uapi/cec/cec-func-open.rst >> @@ -32,11 +32,11 @@ Arguments >> Open flags. Access mode must be ``O_RDWR``. >> >> When the ``O_NONBLOCK`` flag is given, the >> -:ref:`CEC_RECEIVE` ioctl will return EAGAIN >> -error code when no message is available, and the >> -:ref:`CEC_TRANSMIT`, >> -:ref:`CEC_ADAP_S_PHYS_ADDR` and >> -:ref:`CEC_ADAP_S_LOG_ADDRS` ioctls >> +:ref:`CEC_RECEIVE ` ioctl will return the EAGAIN >> +error code when no message is available, and ioctls >> +:ref:`CEC_TRANSMIT `, >> +:ref:`CEC_ADAP_S_PHYS_ADDR ` and >> +:ref:`CEC_ADAP_S_LOG_ADDRS ` >> all act in non-blocking mode. >> >> Other flags have no effect. >> diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst >> b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst >> index 2ca9199..63b808e 100644 >> --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst >> +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst >> @@ -34,7 +34,7 @@ Description >> .. note:: This documents the proposed CEC API. This API is not yet finalized >> and is currently only available as a staging kernel module. >> >> -All cec devices must support the :ref:`CEC_ADAP_G_CAPS` ioctl. To query >> +All cec devices must support ``CEC_ADAP_G_CAPS``. To query > > Why are you removing the ref here and on other similar places? If you > remove it, the font and font color for it will be different and > inconsistent. It will also be inconsistent with the other places > within the document, were it is using a reference everywhere. What's the point of having a link to the same page that you are watching? I also found it very cumbersome and ugly having to write e.g. :ref:`CEC_ADAP_S_PHYS_ADDR all the time. That is fine if it actually points to another page (it serves a real purpose then), but on the page itself I think it is ugly. We never did that with the DocBook documentation either. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mtk-vcodec: fix type mismatches
Hi Arnd,
On Mon, 2016-07-11 at 23:37 +0200, Arnd Bergmann wrote:
> The newly added mtk-vcodec driver produces a number of warnings in an ARM
> allmodconfig build, mainly since it assumes that dma_addr_t is 32-bit wide:
>
> mtk-vcodec/venc/venc_vp8_if.c: In function 'vp8_enc_alloc_work_buf':
> mtk-vcodec/venc/venc_vp8_if.c:212:191: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> mtk-vcodec/venc/venc_h264_if.c: In function 'h264_enc_alloc_work_buf':
> mtk-vcodec/venc/venc_h264_if.c:297:190: error: cast to pointer from integer
> of different size [-Werror=int-to-pointer-cast]
> mtk-vcodec/mtk_vcodec_enc.c: In function 'mtk_venc_worker':
> mtk-vcodec/mtk_vcodec_enc.c:1030:46: error: format '%lx' expects argument of
> type 'long unsigned int', but argument 7 has type 'size_t {aka unsigned int}'
> [-Werror=format=]
> mtk_v4l2_debug(2,
> mtk-vcodec/mtk_vcodec_enc.c:1030:46: error: format '%lx' expects argument of
> type 'long unsigned int', but argument 10 has type 'size_t {aka unsigned
> int}' [-Werror=format=]
> mtk-vcodec/venc_vpu_if.c: In function 'vpu_enc_ipi_handler':
> mtk-vcodec/venc_vpu_if.c:40:30: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> struct venc_vpu_inst *vpu = (struct venc_vpu_inst *)msg->venc_inst;
>
> This rearranges the format strings and type casts to what they should have
> been
> in order to avoid the warnings.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c| 8
> drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c | 4 ++--
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
> drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 4 ++--
> 4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index 6dcae0a0a1f2..0b25a8700877 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -1028,15 +1028,15 @@ static void mtk_venc_worker(struct work_struct *work)
> bs_buf.size = (size_t)dst_buf->planes[0].length;
>
> mtk_v4l2_debug(2,
> - "Framebuf VA=%p PA=%llx Size=0x%lx;VA=%p PA=0x%llx
> Size=0x%lx;VA=%p PA=0x%llx Size=%zu",
> + "Framebuf VA=%p PA=%pad Size=0x%zx;VA=%p PA=%pad
> Size=0x%zx;VA=%p PA=%pad Size=0x%zx",
> frm_buf.fb_addr[0].va,
> - (u64)frm_buf.fb_addr[0].dma_addr,
> + &frm_buf.fb_addr[0].dma_addr,
> frm_buf.fb_addr[0].size,
> frm_buf.fb_addr[1].va,
> - (u64)frm_buf.fb_addr[1].dma_addr,
> + &frm_buf.fb_addr[1].dma_addr,
> frm_buf.fb_addr[1].size,
> frm_buf.fb_addr[2].va,
> - (u64)frm_buf.fb_addr[2].dma_addr,
> + &frm_buf.fb_addr[2].dma_addr,
> frm_buf.fb_addr[2].size);
This change will make debug message dump address of dma_addr field but
not the value of the dma_addr we want.
How about change it from
PA=%llx -> PA=%u
(u64)frm_buf.fb_addr[0].dma_addr -> (u32)frm_buf.fb_addr[0].dma_addr,
>
> ret = venc_if_encode(ctx, VENC_START_OPT_ENCODE_FRAME,
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> index f4e18bb44cb9..9a600525b3c1 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> @@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct venc_h264_inst
> *inst)
> wb[i].iova = inst->work_bufs[i].dma_addr;
>
> mtk_vcodec_debug(inst,
> - "work_buf[%d] va=0x%p iova=0x%p size=%zu",
> + "work_buf[%d] va=0x%p iova=%pad size=%zu",
>i, inst->work_bufs[i].va,
> - (void *)inst->work_bufs[i].dma_addr,
> + &inst->work_bufs[i].dma_addr,
>inst->work_bufs[i].size);
> }
>
Same as above.
best regards,
Tiffany
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> index 431ae706a427..5b35aa1900d7 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> @@ -210,9 +210,9 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst
> *inst)
> wb[i].iova = inst->work_bufs[i].dma_addr;
>
> mtk_vcodec_debug(inst,
> - "work_bufs[%d] va=0x%p,iova=0x%p,size=%zu",
> + "work_bufs[%d] va=0x%p,iova=%pad,size=%zu",
>
Re: [PATCH 2/9] async: Introduce kfence, a N:M completion mechanism
On Fri, Jun 24, 2016 at 10:08:46AM +0100, Chris Wilson wrote: > diff --git a/kernel/async.c b/kernel/async.c > index d2edd6efec56..d0bcb7cc4884 100644 > --- a/kernel/async.c > +++ b/kernel/async.c > @@ -50,6 +50,7 @@ asynchronous and synchronous parts of the kernel. > > #include > #include > +#include > #include > #include > #include So why does this live in async.c? It got its own header, why not also give it its own .c file? Also, I'm not a particular fan of the k* naming, but I see 'fence' is already taken. > +/** > + * DOC: kfence overview > + * > + * kfences provide synchronisation barriers between multiple processes. > + * They are very similar to completions, or a pthread_barrier. Where > + * kfence differs from completions is their ability to track multiple > + * event sources rather than being a singular "completion event". Similar > + * to completions, multiple processes or other kfences can listen or wait > + * upon a kfence to signal its completion. > + * > + * The kfence is a one-shot flag, signaling that work has progressed passed > + * a certain point (as measured by completion of all events the kfence is > + * listening for) and the waiters upon kfence may proceed. > + * > + * kfences provide both signaling and waiting routines: > + * > + * kfence_pending() > + * > + * indicates that the kfence should itself wait for another signal. A > + * kfence created by kfence_create() starts in the pending state. I would much prefer: * - kfence_pending(): indicates that the kfence should itself wait for *another signal. A kfence created by kfence_create() starts in the *pending state. Which is much clearer in what text belongs where. Also, what !? I don't get what this function does. > + * > + * kfence_signal() > + * > + * undoes the earlier pending notification and allows the fence to complete > + * if all pending events have then been signaled. So I know _signal() is the posix thing, but seeing how we already completions, how about being consistent with those and use _complete() for this? > + * > + * kfence_wait() > + * > + * allows the caller to sleep (uninterruptibly) until the fence is complete. whitespace to separate the description of kfence_wait() from whatever else follows. > + * Meanwhile, > + * > + * kfence_complete() > + * > + * reports whether or not the kfence has been passed. kfence_done(), again to match completions. > + * > + * This interface is very similar to completions, with the exception of > + * allowing multiple pending / signals to be sent before the kfence is > + * complete. > + * > + * kfence_add() / kfence_add_completion() > + * > + * sets the kfence to wait upon another fence, or completion respectively. > + * > + * Unlike completions, kfences are expected to live inside more complex > graphs > + * and form the basis for parallel execution of interdependent and so are > + * reference counted. A kfence may be created using, > + * > + * kfence_create() > + * > + * The fence starts off pending a single signal. Once you have finished > + * setting up the fence, use kfence_signal() to allow it to wait upon > + * its event sources. > + * > + * Use > + * > + * kfence_get() / kfence_put > + * > + * to acquire or release a reference on kfence respectively. > + */ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] mtk-vcodec: fix more type mismatches
The newly added mtk-vcodec driver produces a number of warnings in an ARM
allmodconfig build, mainly since it assumes that dma_addr_t is 32-bit wide:
mtk-vcodec/venc/venc_vp8_if.c: In function 'vp8_enc_alloc_work_buf':
mtk-vcodec/venc/venc_vp8_if.c:212:191: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
mtk-vcodec/venc/venc_h264_if.c: In function 'h264_enc_alloc_work_buf':
mtk-vcodec/venc/venc_h264_if.c:297:190: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
This rearranges the format strings and type casts to what they should have been
in order to avoid the warnings. e0f80d8d62f5 ("[media] mtk-vcodec: fix two
compiler
warnings") fixed some of the problems that were introduced at the same time, but
missed two others.
Signed-off-by: Arnd Bergmann
---
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c | 4 ++--
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
index f4e18bb44cb9..9a600525b3c1 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct venc_h264_inst
*inst)
wb[i].iova = inst->work_bufs[i].dma_addr;
mtk_vcodec_debug(inst,
-"work_buf[%d] va=0x%p iova=0x%p size=%zu",
+"work_buf[%d] va=0x%p iova=%pad size=%zu",
i, inst->work_bufs[i].va,
-(void *)inst->work_bufs[i].dma_addr,
+&inst->work_bufs[i].dma_addr,
inst->work_bufs[i].size);
}
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
index 5b4ef0f1740c..60bbcd2a0510 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -210,9 +210,9 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst
*inst)
wb[i].iova = inst->work_bufs[i].dma_addr;
mtk_vcodec_debug(inst,
-"work_bufs[%d] va=0x%p,iova=0x%p,size=%zu",
+"work_bufs[%d] va=0x%p,iova=%pad,size=%zu",
i, inst->work_bufs[i].va,
-(void *)inst->work_bufs[i].dma_addr,
+&inst->work_bufs[i].dma_addr,
inst->work_bufs[i].size);
}
--
2.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 19/46] [media] dma-mapping: Use unsigned long for dma_attrs
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.
Signed-off-by: Krzysztof Kozlowski
[for bdisp]
Acked-by: Fabien Dessenne
[for vb2-core]
Reviewed-by: Marek Szyprowski
---
Changes since v5:
1. Rebased on linux-next.
---
drivers/media/platform/sti/bdisp/bdisp-hw.c| 26
drivers/media/v4l2-core/videobuf2-dma-contig.c | 28 ++
drivers/media/v4l2-core/videobuf2-dma-sg.c | 21 +--
drivers/media/v4l2-core/videobuf2-vmalloc.c| 2 +-
include/media/videobuf2-core.h | 6 +++---
include/media/videobuf2-dma-contig.h | 2 --
6 files changed, 28 insertions(+), 57 deletions(-)
diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c
b/drivers/media/platform/sti/bdisp/bdisp-hw.c
index 3df66d11c795..b7892f3efd98 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-hw.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c
@@ -430,14 +430,11 @@ int bdisp_hw_get_and_clear_irq(struct bdisp_dev *bdisp)
*/
void bdisp_hw_free_nodes(struct bdisp_ctx *ctx)
{
- if (ctx && ctx->node[0]) {
- DEFINE_DMA_ATTRS(attrs);
-
- dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+ if (ctx && ctx->node[0])
dma_free_attrs(ctx->bdisp_dev->dev,
sizeof(struct bdisp_node) * MAX_NB_NODE,
- ctx->node[0], ctx->node_paddr[0], &attrs);
- }
+ ctx->node[0], ctx->node_paddr[0],
+ DMA_ATTR_WRITE_COMBINE);
}
/**
@@ -455,12 +452,10 @@ int bdisp_hw_alloc_nodes(struct bdisp_ctx *ctx)
unsigned int i, node_size = sizeof(struct bdisp_node);
void *base;
dma_addr_t paddr;
- DEFINE_DMA_ATTRS(attrs);
/* Allocate all the nodes within a single memory page */
- dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
base = dma_alloc_attrs(dev, node_size * MAX_NB_NODE, &paddr,
- GFP_KERNEL | GFP_DMA, &attrs);
+ GFP_KERNEL | GFP_DMA, DMA_ATTR_WRITE_COMBINE);
if (!base) {
dev_err(dev, "%s no mem\n", __func__);
return -ENOMEM;
@@ -493,13 +488,9 @@ void bdisp_hw_free_filters(struct device *dev)
{
int size = (BDISP_HF_NB * NB_H_FILTER) + (BDISP_VF_NB * NB_V_FILTER);
- if (bdisp_h_filter[0].virt) {
- DEFINE_DMA_ATTRS(attrs);
-
- dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+ if (bdisp_h_filter[0].virt)
dma_free_attrs(dev, size, bdisp_h_filter[0].virt,
- bdisp_h_filter[0].paddr, &attrs);
- }
+ bdisp_h_filter[0].paddr, DMA_ATTR_WRITE_COMBINE);
}
/**
@@ -516,12 +507,11 @@ int bdisp_hw_alloc_filters(struct device *dev)
unsigned int i, size;
void *base;
dma_addr_t paddr;
- DEFINE_DMA_ATTRS(attrs);
/* Allocate all the filters within a single memory page */
size = (BDISP_HF_NB * NB_H_FILTER) + (BDISP_VF_NB * NB_V_FILTER);
- dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
- base = dma_alloc_attrs(dev, size, &paddr, GFP_KERNEL | GFP_DMA, &attrs);
+ base = dma_alloc_attrs(dev, size, &paddr, GFP_KERNEL | GFP_DMA,
+ DMA_ATTR_WRITE_COMBINE);
if (!base)
return -ENOMEM;
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 863f658a3fa1..1ec4434a86bb 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -27,7 +27,7 @@ struct vb2_dc_buf {
unsigned long size;
void*cookie;
dma_addr_t dma_addr;
- struct dma_attrsattrs;
+ unsigned long attrs;
enum dma_data_direction dma_dir;
struct sg_table *dma_sgt;
struct frame_vector *vec;
@@ -130,12 +130,12 @@ static void vb2_dc_put(void *buf_priv)
kfree(buf->sgt_base);
}
dma_free_attrs(buf->dev, buf->size, buf->cookie, buf->dma_addr,
- &buf->attrs);
+ buf->attrs);
put_device(buf->dev);
kfree(buf);
}
-static void *vb2_dc_alloc(struct device *dev, const struct dma_attrs *attrs,
+static void *vb2_dc_alloc(struct device *dev, unsigned long attrs,
unsigned long size, enum dma_data_direction dma_dir,
gfp_t gfp_flags)
{
@@ -146,16 +146,16 @@ static void *vb2_dc_alloc(struct device *dev, const
struct dma_attrs *attrs,
return ERR_PTR(-ENOMEM);
if (attrs)
- buf->attrs = *attrs;
+ buf->attrs = attrs;
buf->cookie = dma_alloc_attr
[PATCH v6 45/46] dma-mapping: Remove dma_get_attr
After switching DMA attributes to unsigned long it is easier to just
compare the bits.
Signed-off-by: Krzysztof Kozlowski
[for avr32]
Acked-by: Hans-Christian Noren Egtvedt
[for arc]
Acked-by: Vineet Gupta
[for arm64 and dma-iommu]
Acked-by: Robin Murphy
---
Documentation/DMA-API.txt | 4 +--
arch/arc/mm/dma.c | 4 +--
arch/arm/mm/dma-mapping.c | 36 --
arch/arm/xen/mm.c | 4 +--
arch/arm64/mm/dma-mapping.c| 10 +++
arch/avr32/mm/dma-coherent.c | 4 +--
arch/ia64/sn/pci/pci_dma.c | 10 ++-
arch/metag/kernel/dma.c| 2 +-
arch/mips/mm/dma-default.c | 6 ++---
arch/openrisc/kernel/dma.c | 4 +--
arch/parisc/kernel/pci-dma.c | 2 +-
arch/powerpc/platforms/cell/iommu.c| 12 -
drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 2 +-
drivers/iommu/dma-iommu.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
include/linux/dma-mapping.h| 10 ---
16 files changed, 47 insertions(+), 67 deletions(-)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 24f9688bb98a..1d26eeb6b5f6 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -422,9 +422,7 @@ void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t
dma_addr,
unsigned long attrs)
{
- int foo = dma_get_attr(DMA_ATTR_FOO, attrs);
-
- if (foo)
+ if (attrs & DMA_ATTR_FOO)
/* twizzle the frobnozzle */
diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 3d1f467d1792..74bbe68dce9d 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -46,7 +46,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
* (vs. always going to memory - thus are faster)
*/
if ((is_isa_arcv2() && ioc_exists) ||
- dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs))
+ (attrs & DMA_ATTR_NON_CONSISTENT))
need_coh = 0;
/*
@@ -95,7 +95,7 @@ static void arc_dma_free(struct device *dev, size_t size,
void *vaddr,
struct page *page = virt_to_page(dma_handle);
int is_non_coh = 1;
- is_non_coh = dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs) ||
+ is_non_coh = (attrs & DMA_ATTR_NON_CONSISTENT) ||
(is_isa_arcv2() && ioc_exists);
if (PageHighMem(page) || !is_non_coh)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ebb3fde99043..43e03b5293d0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -126,7 +126,7 @@ static dma_addr_t arm_dma_map_page(struct device *dev,
struct page *page,
unsigned long offset, size_t size, enum dma_data_direction dir,
unsigned long attrs)
{
- if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+ if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_cpu_to_dev(page, offset, size, dir);
return pfn_to_dma(dev, page_to_pfn(page)) + offset;
}
@@ -155,7 +155,7 @@ static dma_addr_t arm_coherent_dma_map_page(struct device
*dev, struct page *pag
static void arm_dma_unmap_page(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir, unsigned long attrs)
{
- if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+ if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_dev_to_cpu(pfn_to_page(dma_to_pfn(dev, handle)),
handle & ~PAGE_MASK, size, dir);
}
@@ -622,9 +622,9 @@ static void __free_from_contiguous(struct device *dev,
struct page *page,
static inline pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
{
- prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
- pgprot_writecombine(prot) :
- pgprot_dmacoherent(prot);
+ prot = (attrs & DMA_ATTR_WRITE_COMBINE) ?
+ pgprot_writecombine(prot) :
+ pgprot_dmacoherent(prot);
return prot;
}
@@ -744,7 +744,7 @@ static void *__dma_alloc(struct device *dev, size_t size,
dma_addr_t *handle,
.gfp = gfp,
.prot = prot,
.caller = caller,
- .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+ .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0),
};
#ifdef CONFIG_DMA_API_DEBUG
@@ -887,7 +887,7 @@ static void __arm_dma_free(struct device *dev, size_t size,
void *cpu_addr,
.size = PAGE_ALIGN(size),
.cpu_addr = cpu_addr,
.page = page,
- .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+
[PATCH v6 01/46] [media] mtk-vcodec: Remove unused dma_attrs
The local variable dma_attrs is set but never read. Signed-off-by: Krzysztof Kozlowski --- Changes since v5: New patch. --- drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c index 60b0bde232f4..ae1eb8fde7f8 100644 --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c @@ -246,7 +246,6 @@ static int mtk_vcodec_probe(struct platform_device *pdev) struct video_device *vfd_enc; struct resource *res; int i, j, ret; - DEFINE_DMA_ATTRS(attrs); dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); if (!dev) @@ -380,9 +379,6 @@ static int mtk_vcodec_probe(struct platform_device *pdev) goto err_enc_reg; } - /* Avoid the iommu eat big hunks */ - dma_set_attr(DMA_ATTR_ALLOC_SINGLE_PAGES, &attrs); - mtk_v4l2_debug(0, "encoder registered as /dev/video%d", vfd_enc->num); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 00/46] dma-mapping: Use unsigned long for dma_attrs
Hi,
The fifth version of this patchset was merged by Andrew Morton
few days ago. It was rebased on v4.7-rc5 so it missed some ongoing
changes.
This is just rebase on next-20160713.
For easier testing the patchset is available here:
repo: https://github.com/krzk/linux
branch: for-next/dma-attrs-const-v6
Changes since v5
1. New patches:
1/46: [media] mtk-vcodec: Remove unused dma_attrs
44/46: remoteproc: qcom: Use unsigned long for dma_attrs
2. 19/46: rebased on next, some more changes inside
3. Added accumulated acks: Marek Szyprowski, Richard Kuo,
Konrad Rzeszutek Wilk, Daniel Vetter and Joerg Roedel.
Changes since v4
1. Collect some acks. Still need more.
2. Minor fixes pointed by Robin Murphy.
3. Applied changes from Bart Van Assche's comment.
4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).
Changes since v3
1. Collect some acks.
2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
the value of DMA_ATTR_WEAK_ORDERING").
3. Minor fix pointed out by Michael Ellerman.
Changes since v2
1. Follow Christoph Hellwig's comments (don't use BIT add
documentation, remove dma_get_attr).
Rationale
=
The dma-mapping core and the implementations do not change the
DMA attributes passed by pointer. Thus the pointer can point to const
data. However the attributes do not have to be a bitfield. Instead
unsigned long will do fine:
1. This is just simpler. Both in terms of reading the code and setting
attributes. Instead of initializing local attributes on the stack
and passing pointer to it to dma_set_attr(), just set the bits.
2. It brings safeness and checking for const correctness because the
attributes are passed by value.
Best regards,
Krzysztof
Krzysztof Kozlowski (46):
[media] mtk-vcodec: Remove unused dma_attrs
dma-mapping: Use unsigned long for dma_attrs
alpha: dma-mapping: Use unsigned long for dma_attrs
arc: dma-mapping: Use unsigned long for dma_attrs
ARM: dma-mapping: Use unsigned long for dma_attrs
arm64: dma-mapping: Use unsigned long for dma_attrs
avr32: dma-mapping: Use unsigned long for dma_attrs
blackfin: dma-mapping: Use unsigned long for dma_attrs
c6x: dma-mapping: Use unsigned long for dma_attrs
cris: dma-mapping: Use unsigned long for dma_attrs
frv: dma-mapping: Use unsigned long for dma_attrs
drm/exynos: dma-mapping: Use unsigned long for dma_attrs
drm/mediatek: dma-mapping: Use unsigned long for dma_attrs
drm/msm: dma-mapping: Use unsigned long for dma_attrs
drm/nouveau: dma-mapping: Use unsigned long for dma_attrs
drm/rockship: dma-mapping: Use unsigned long for dma_attrs
infiniband: dma-mapping: Use unsigned long for dma_attrs
iommu: dma-mapping: Use unsigned long for dma_attrs
[media] dma-mapping: Use unsigned long for dma_attrs
xen: dma-mapping: Use unsigned long for dma_attrs
swiotlb: dma-mapping: Use unsigned long for dma_attrs
powerpc: dma-mapping: Use unsigned long for dma_attrs
video: dma-mapping: Use unsigned long for dma_attrs
x86: dma-mapping: Use unsigned long for dma_attrs
iommu: intel: dma-mapping: Use unsigned long for dma_attrs
h8300: dma-mapping: Use unsigned long for dma_attrs
hexagon: dma-mapping: Use unsigned long for dma_attrs
ia64: dma-mapping: Use unsigned long for dma_attrs
m68k: dma-mapping: Use unsigned long for dma_attrs
metag: dma-mapping: Use unsigned long for dma_attrs
microblaze: dma-mapping: Use unsigned long for dma_attrs
mips: dma-mapping: Use unsigned long for dma_attrs
mn10300: dma-mapping: Use unsigned long for dma_attrs
nios2: dma-mapping: Use unsigned long for dma_attrs
openrisc: dma-mapping: Use unsigned long for dma_attrs
parisc: dma-mapping: Use unsigned long for dma_attrs
misc: mic: dma-mapping: Use unsigned long for dma_attrs
s390: dma-mapping: Use unsigned long for dma_attrs
sh: dma-mapping: Use unsigned long for dma_attrs
sparc: dma-mapping: Use unsigned long for dma_attrs
tile: dma-mapping: Use unsigned long for dma_attrs
unicore32: dma-mapping: Use unsigned long for dma_attrs
xtensa: dma-mapping: Use unsigned long for dma_attrs
remoteproc: qcom: Use unsigned long for dma_attrs
dma-mapping: Remove dma_get_attr
dma-mapping: Document the DMA attributes next to the declaration
Documentation/DMA-API.txt | 33 +++---
Documentation/DMA-attributes.txt | 2 +-
arch/alpha/include/asm/dma-mapping.h | 2 -
arch/alpha/kernel/pci-noop.c | 2 +-
arch/alpha/kernel/pci_iommu.c | 12 +-
arch/arc/mm/dma.c | 12 +-
arch/arm/common/dmabounce.c| 4 +-
arch/arm/include/asm/dma-mapping.h | 13 +--
arch/arm/include/asm/xen/page-coherent.h | 16 +--
arch/arm/mm/dma-mapping.c
Re: si2157: new revision?
Hello Antti! Thank you for your advice. I succeed with demod chip! ... [ 3454.060649] cx231xx #0: (pipe 0x8b80): IN: c0 0d 0f 00 74 00 04 00 <<< 6f 03 00 00 [ 3454.060784] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x64 len=10: [ 3454.060793] cx231xx #0: (pipe 0x8b80): IN: c0 05 23 c8 00 00 04 00 [ 3454.061392] <<< 80 44 33 30 [ 3454.061403] cx231xx #0: (pipe 0x8b80): IN: c0 05 63 c8 00 00 04 00 <<< 0b 73 33 30 [ 3454.061899] cx231xx #0: (pipe 0x8b80): IN: c0 05 61 c8 00 00 02 00 <<< 13 01 [ 3454.062278] 80 44 33 30 0b 73 33 30 13 01 [ 3454.062294] si2168 17-0064: firmware version: 3.0.19 But with tuner chip I have only error -32 :( ... [ 2795.770276] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x60 len=1: [ 2795.770281] cx231xx #0: (pipe 0x8680): IN: c0 06 21 c0 00 00 01 00 [ 2795.771045] <<< fe [ 2795.771048] fe [ 2795.771205] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60 len=15: c0 00 00 00 00 01 01 01 01 01 01 02 00 00 01 [ 2795.771234] cx231xx #0: (pipe 0x8600): OUT: 40 02 21 c0 00 00 0f 00 [ 2795.771235] >>> [ 2795.771236] c0 [ 2795.771237] 00 00 00 00 01 01 01 01 01 01 02 00 00 01FAILED! [ 2795.771886] cx231xx 1-2:1.1: cx231xx_send_usb_command: failed with status --32 [ 2795.771888] cx231xx #0 at cx231xx_i2c_xfer: ERROR: -32 But I discovered one thing, error will come - if write payload is bigger than 4 bytes.. Any ideas, why this happening? ... [ 3454.143285] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60 len=4: c0 00 00 00 [ 3454.143288] cx231xx #0: (pipe 0x8b00): OUT: 40 02 21 c0 00 00 04 00 [ 3454.143289] >>> c0 00 00 00 [ 3454.143884] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x60 len=1: [ 3454.143893] cx231xx #0: (pipe 0x8b80): IN: c0 06 21 c0 00 00 01 00 [ 3454.144242] <<< fe [ 3454.144244] fe [ 3454.144391] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60 len=1: 02 [ 3454.144406] cx231xx #0: (pipe 0x8b00): OUT: 40 02 21 c0 00 00 01 00 [ 3454.144406] >>> [ 3454.144407] 02 [ 3454.144767] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x60 len=13: [ 3454.144767] cx231xx #0: (pipe 0x8b80): IN: c0 06 23 c0 00 00 04 00 <<< fe fe fe fe [ 3454.145397] cx231xx #0: (pipe 0x8b80): IN: c0 06 63 c0 00 00 04 00 <<< fe fe fe fe [ 3454.145893] cx231xx #0: (pipe 0x8b80): IN: c0 06 63 c0 00 00 04 00 [ 3454.146377] <<< fe fe fe fe [ 3454.146394] cx231xx #0: (pipe 0x8b80): IN: c0 06 61 c0 00 00 01 00 [ 3454.146639] <<< fe [ 3454.146640] fe fe fe fe fe fe fe fe fe fe fe fe fe [ 3454.146676] si2157 15-0060: unknown chip version Si21254-\xfffe\xfffe\xfffe On 10.07.16 01:34, Antti Palosaari wrote: > Hey, that's your problem :] Driver development is all the time > resolving this kind of issues and you really need to resolve those > yourself. > > You will need to get I2C communication working with all the chips. > First si2168 demod and after it answers to I2C you will need to get > connection to Si2157 tuner. After both of those are answering you > could try to get tuning tests to see if demod locks. After demod locks > you know tuner is working and also demod is somehow working. If demod > lock but there is no picture you know problem is TS interface. Try > different TS settings for both USB-bridge and demod - those should > match. If it does not starts working then you have to look sniffs and > start replacing driver code with data from sniffs to until it starts > working => problematic setting is found. > > regards > Antti > > > > On 07/10/2016 12:18 AM, Oleh Kravchenko wrote: >> Hello! >> >> I'm started playing i2c, but stuck with unknown error for me - 32 >> (EPIPE?): >> [ 5651.958763] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60 >> len=15: c0 00 00 00 00 01 01 01 01 01 01 02 00 00 01 >> [ 5651.958774] cx231xx #0: (pipe 0x80001000): OUT: 40 02 21 c0 >> 00 00 >> 0f 00 >> [ 5651.958775] >>> c0 00 00 00 00 01 01 01 01 01 01 02 00 00 >> 01FAILED! >> [ 5651.959110] cx231xx 1-2:1.1: cx231xx_send_usb_command: failed >> with >> status --32 >> [ 5651.959111] cx231xx #0 at cx231xx_i2c_xfer: ERROR: -32 >> >> How this error can be fixed? :) >> >> On 04.07.16 21:47, Antti Palosaari wrote: >>> Hello >>> On 07/04/2016 09:38 PM, Oleh Kravchenko wrote: Hello Antti! I started reverse-engineering of my new TV tuner "Evromedia USB Full Hybrid Full HD" and discovered that start sequence is different from si2157.c: i2c_read_C1 1 \xFE i2c_write_C0 15 \xC0\x00\x00\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01 Do you familiar with this revision? Should I merge my changes to si2158.c? Or define another driver? >>> >>> According to chip markings those are tuner Si2158-A20 and demod >>> Si2168-A30. Both are supported already by si2157 and si2168 drivers. >>> >>> Difference is just some settings. You need to identify which setting is >>> wrong and add that to configuration options. It should be pretty >>> easy to >>> find it
[PATCH] [media] mtk-vcodec: fix default OUTPUT buffer size
When calculate OUTPUT buffer size in vidioc_try_fmt, it will add more size hw need in each plane. But in mtk_vcodec_enc_set_default_params, it do not add same size in each plane. This makes v4l2-compliance test fail. This patch fix the issue. Signed-off-by: Tiffany Lin --- drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c index 907a6d1..3ed3f2d 100644 --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c @@ -328,10 +328,11 @@ static int vidioc_try_fmt(struct v4l2_format *f, struct mtk_video_fmt *fmt) pix_fmt_mp->height += 32; mtk_v4l2_debug(0, - "before resize width=%d, height=%d, after resize width=%d, height=%d, sizeimage=%d", + "before resize width=%d, height=%d, after resize width=%d, height=%d, sizeimage=%d %d", tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height, - pix_fmt_mp->width * pix_fmt_mp->height); + pix_fmt_mp->plane_fmt[0].sizeimage, + pix_fmt_mp->plane_fmt[1].sizeimage); pix_fmt_mp->num_planes = fmt->num_planes; pix_fmt_mp->plane_fmt[0].sizeimage = @@ -1166,9 +1167,13 @@ void mtk_vcodec_enc_set_default_params(struct mtk_vcodec_ctx *ctx) (q_data->coded_height + 32) <= MTK_VENC_MAX_H) q_data->coded_height += 32; - q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height; + q_data->sizeimage[0] = + q_data->coded_width * q_data->coded_height+ + ((ALIGN(q_data->coded_width, 16) * 2) * 16); q_data->bytesperline[0] = q_data->coded_width; - q_data->sizeimage[1] = q_data->sizeimage[0] / 2; + q_data->sizeimage[1] = + (q_data->coded_width * q_data->coded_height) / 2 + + (ALIGN(q_data->coded_width, 16) * 16); q_data->bytesperline[1] = q_data->coded_width; q_data = &ctx->q_data[MTK_Q_DATA_DST]; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] s5p-g2d: Replace old driver with DRM version
On 07/13/2016 01:02 AM, Mauro Carvalho Chehab wrote: > I suspect that you'll be applying this one via DRM tree, so: > > Em Tue, 24 May 2016 15:28:13 +0200 > Krzysztof Kozlowski escreveu: > >> Remove the old non-DRM driver because it is now entirely supported by >> exynos_drm_g2d driver. >> >> Cc: Kyungmin Park >> Cc: Kamil Debski >> Signed-off-by: Krzysztof Kozlowski > > Acked-by: Mauro Carvalho Chehab > > PS.: If you prefer to apply this one via my tree, I'm ok too. Just > let me know when the first patch gets merged upstream. This patchset was insufficient and I didn't came up with follow up. Please ignore it for now. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cec: don't zero reply and timeout on error
There is really no reason to zero the reply and timeout fields if an
error occurs. This is a left-over from earlier versions where that
was used to signal errors, but this is now handled by the rx/tx_status
fields.
Signed-off-by: Hans Verkuil
---
drivers/staging/media/cec/cec-adap.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/media/cec/cec-adap.c
b/drivers/staging/media/cec/cec-adap.c
index ca34339..07147a1 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -289,7 +289,6 @@ static void cec_data_cancel(struct cec_data *data)
CEC_TX_STATUS_MAX_RETRIES;
data->attempts = 0;
data->msg.tx_error_cnt = 1;
- data->msg.reply = 0;
/* Queue transmitted message for monitoring purposes */
cec_queue_msg_monitor(data->adap, &data->msg, 1);
@@ -511,16 +510,8 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
/* Queue transmitted message for monitoring purposes */
cec_queue_msg_monitor(adap, msg, 1);
- /*
-* Clear reply and timeout on error or if the adapter is no longer
-* configured. It makes no sense to wait for a reply in that case.
-*/
- if (!(status & CEC_TX_STATUS_OK) || !adap->is_configured) {
- msg->reply = 0;
- msg->timeout = 0;
- }
-
- if (msg->timeout) {
+ if ((status & CEC_TX_STATUS_OK) && adap->is_configured &&
+ msg->timeout) {
/*
* Queue the message into the wait queue if we want to wait
* for a reply.
@@ -648,6 +639,8 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct
cec_msg *msg,
dprintk(2, "cec_transmit_msg: %*ph%s\n",
msg->len, msg->msg, !block ? " (nb)" : "");
+ msg->rx_ts = 0;
+ msg->tx_ts = 0;
msg->rx_status = 0;
msg->tx_status = 0;
msg->tx_arb_lost_cnt = 0;
@@ -812,10 +805,8 @@ void cec_received_msg(struct cec_adapter *adap, struct
cec_msg *msg)
dst->len = msg->len;
dst->rx_ts = msg->rx_ts;
dst->rx_status = msg->rx_status;
- if (abort) {
- dst->reply = 0;
+ if (abort)
dst->rx_status |= CEC_RX_STATUS_FEATURE_ABORT;
- }
/* Remove it from the wait_queue */
list_del_init(&data->list);
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] userspace API definitions for auto-focus coil
On Tue 2016-07-12 20:32:01, Mauro Carvalho Chehab wrote: > Em Sat, 18 Jun 2016 17:38:46 +0200 > Pavel Machek escreveu: > > > Hi! > > > > > > Not V4L2_CID_USER_AD5820...? > > > > > > The rest of the controls have no USER as part of the macro name, so I > > > wouldn't use it here either. > > > > Ok. > > > > > > Ok, separate header file for 2 lines seemed like a bit of overkill, > > > > but why not. > > > > > > That follows an existing pattern of how controls have been implemented in > > > other drivers. > > > > Ok. > > > > > Could you merge this with the driver patch? I've dropped that from my > > > ad5820 > > > branch as it does not compile. > > > > Yes, merged patch should be in your inbox now. > > The V4L2 core changes should be on a separate patch. Btw, you'll also > need to patch documentation to reflect such changes. We're right now > moving from DocBook to ReST markup language. The patches for it are > right now on a separate topic branch (docs-next), to be merged for > Kernel 4.8 on the next merge window. What about: I drop all the functionality but FOCUS_ABSOLUTE, which is core functionality, anyway, and does not need core changes. When V4L2 core stabilizes, it can be reintroduced. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] [media] pci: Add tw5864 driver - fixed few style nits, going to resubmit soon
On 07/13/2016 04:05 AM, Andrey Utkin wrote: > Found and fixed few very minor coding style nits, will resubmit in few days, > now still waiting for comments to v4. Can you resubmit now? I plan to review it on Friday or Monday, and I'd rather review the latest version. Regards, Hans > > https://github.com/bluecherrydvr/linux/commits/tw5864 > > commit 31f7c98a144cb3fb8a94662f002d9b6142d1f390 > Author: Andrey Utkin > Date: Wed Jul 13 05:00:28 2016 +0300 > > Fix checkpatch --strict issue > > CHECK: Alignment should match open parenthesis > #3599: FILE: drivers/media/pci/tw5864/tw5864-video.c:539: > +static int tw5864_fmt_vid_cap(struct file *file, void *priv, > + struct v4l2_format *f) > > commit 11a09a1048af597ecf374507b08c809eed91b86d > Author: Andrey Utkin > Date: Wed Jul 13 04:59:34 2016 +0300 > > Fix checkpatch --strict issue > > CHECK: Please don't use multiple blank lines > #3244: FILE: drivers/media/pci/tw5864/tw5864-video.c:184: > > commit 861b2ba8593db7abe89291a4ba85976519783f4a > Author: Andrey Utkin > Date: Wed Jul 13 04:58:37 2016 +0300 > > Fix checkpatch --strict issue > > CHECK: No space is necessary after a cast > #3053: FILE: drivers/media/pci/tw5864/tw5864-util.c:36: > + return (u8) tw_readl(TW5864_IND_DATA); > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
