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  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]
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
> 



Powered by blists - more mailing lists