linux-kernel - Re: [Patch 2/2] media: ti-vpe: vpe: allow use of user specified stride

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170215143430.GA10737@ti.com>
Date:   Wed, 15 Feb 2017 08:34:30 -0600
From:   Benoit Parrot <bparrot@...com>
To:     Tomi Valkeinen <tomi.valkeinen@...com>
CC:     Hans Verkuil <hverkuil@...all.nl>,
        Mauro Carvalho Chehab <mchehab@....samsung.com>,
        <linux-media@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Jyri Sarha <jsarha@...com>,
        Peter Ujfalusi <peter.ujfalusi@...com>
Subject: Re: [Patch 2/2] media: ti-vpe: vpe: allow use of user specified
 stride

Tomi Valkeinen <tomi.valkeinen@...com> wrote on Wed [2017-Feb-15 13:22:42 +0200]:
> Hi,
> 
> On 13/02/17 15:06, Benoit Parrot wrote:
> > Bytesperline/stride was always overwritten by VPE to the most
> > adequate value based on needed alignment.
> > 
> > However in order to make use of arbitrary size DMA buffer it
> > is better to use the user space provide stride instead.
> > 
> > The driver will still calculate an appropriate stride but will
> > use the provided one when it is larger than the calculated one.
> > 
> > Signed-off-by: Benoit Parrot <bparrot@...com>
> > ---
> >  drivers/media/platform/ti-vpe/vpe.c | 28 ++++++++++++++++++++--------
> >  1 file changed, 20 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c
> > index 2dd67232b3bc..c47151495b6f 100644
> > --- a/drivers/media/platform/ti-vpe/vpe.c
> > +++ b/drivers/media/platform/ti-vpe/vpe.c
> > @@ -1597,6 +1597,7 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
> >  	struct v4l2_plane_pix_format *plane_fmt;
> >  	unsigned int w_align;
> >  	int i, depth, depth_bytes, height;
> > +	unsigned int stride = 0;
> >  
> >  	if (!fmt || !(fmt->types & type)) {
> >  		vpe_err(ctx->dev, "Fourcc format (0x%08x) invalid.\n",
> > @@ -1683,16 +1684,27 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
> >  		plane_fmt = &pix->plane_fmt[i];
> >  		depth = fmt->vpdma_fmt[i]->depth;
> >  
> > -		if (i == VPE_LUMA)
> > -			plane_fmt->bytesperline = (pix->width * depth) >> 3;
> > -		else
> > -			plane_fmt->bytesperline = pix->width;
> > +		stride = (pix->width * fmt->vpdma_fmt[VPE_LUMA]->depth) >> 3;
> > +		if (stride > plane_fmt->bytesperline)
> > +			plane_fmt->bytesperline = stride;
> 
> The old code calculates different bytes per line for luma and chroma,
> but the new one calculates only for luma. Is that correct?

The previous method which happened to produce the correct value was
not proper as the spec for NV12/NV16 states that the chroma bytes per
line/stride should be the same as the LUMA stride only the number of
lines might differ which affect how the sizeimage component is
calculated. This patch takes that into account.

Benoit

> 
>  Tomi
>