linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: linux-media@vger.kernel.org, Enrico <ebutera@users.berlios.de>,
	Jean-Philippe Francois <jp.francois@cynove.com>,
	Abhishek Reddy Kondaveeti <areddykondaveeti@aptina.com>,
	Gary Thomas <gary@mlbassoc.com>,
	Javier Martinez Canillas <martinez.javier@gmail.com>
Subject: Re: [PATCH 1/6] omap3isp: video: Split format info bpp field into width and bpp
Date: Wed, 27 Jun 2012 13:54:30 +0200	[thread overview]
Message-ID: <3151444.lq5j8qGhle@avalon> (raw)
In-Reply-To: <4FEAE987.6060104@iki.fi>

Hi Sakari,

Thanks for the review.

On Wednesday 27 June 2012 14:07:51 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > The bpp field currently stores the sample width and is aligned to the
> > next multiple of 8 bits when computing data size in memory. This won't
> > work anymore for YUYV8_2X8 formats. Split the bpp field into a sample
> > width and a bits per pixel value.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> ...
> 
> > diff --git a/drivers/media/video/omap3isp/ispvideo.h
> > b/drivers/media/video/omap3isp/ispvideo.h index 5acc909..f8092cc 100644
> > --- a/drivers/media/video/omap3isp/ispvideo.h
> > +++ b/drivers/media/video/omap3isp/ispvideo.h
> > @@ -51,7 +51,8 @@ struct v4l2_pix_format;
> > 
> >   * @flavor: V4L2 media bus format code for the same pixel layout but
> >   *	shifted to be 8 bits per pixel. =0 if format is not shiftable.
> >   * @pixelformat: V4L2 pixel format FCC identifier
> > 
> > - * @bpp: Bits per pixel
> > + * @width: Data bus width
> > + * @bpp: Bits per pixel (when stored in memory)
> 
> Would it make sense to use bytes rather than bits?

I'll change that.

> Also width isn't really the width of the data bus on serial busses, is it?
> How about busses that transfer pixels 8 bits at the time?

I could change the comment to "bits per pixel (when transferred on a bus)", 
would that be better ?

> You can also stop using ALIGN() in isp_video_mbus_to_pix() (in ispvideo.c)
> as the ISP will always write complete bytes.

Indeed.

> I might even switch the meaning between width and bpp but this is up to you.

I got used to width/bpp as defined by this patch, so that would be confusing 
:-)

> >   */
> >  
> >  struct isp_format_info {
> >  
> >  	enum v4l2_mbus_pixelcode code;
> > 
> > @@ -59,6 +60,7 @@ struct isp_format_info {
> > 
> >  	enum v4l2_mbus_pixelcode uncompressed;
> >  	enum v4l2_mbus_pixelcode flavor;
> >  	u32 pixelformat;
> > 
> > +	unsigned int width;
> > 
> >  	unsigned int bpp;
> >  
> >  };
> > 
> > @@ -106,7 +108,7 @@ struct isp_pipeline {
> > 
> >  	struct v4l2_fract max_timeperframe;
> >  	struct v4l2_subdev *external;
> >  	unsigned int external_rate;
> > 
> > -	unsigned int external_bpp;
> > +	unsigned int external_width;
> > 
> >  };
> >  
> >  #define to_isp_pipeline(__e) \

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2012-06-27 11:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26 13:45 [PATCH 0/6] YUV input support for the OMAP3 ISP Laurent Pinchart
2012-06-26 13:45 ` [PATCH 1/6] omap3isp: video: Split format info bpp field into width and bpp Laurent Pinchart
2012-06-27 11:07   ` Sakari Ailus
2012-06-27 11:54     ` Laurent Pinchart [this message]
2012-06-27 11:56       ` Laurent Pinchart
2012-06-27 11:59       ` Sakari Ailus
2012-06-26 13:45 ` [PATCH 2/6] omap3isp: video: Add YUYV8_2X8 and UYVY8_2X8 support Laurent Pinchart
2012-06-26 13:45 ` [PATCH 3/6] omap3isp: csi2: Add V4L2_MBUS_FMT_YUYV8_2X8 support Laurent Pinchart
2012-06-26 13:45 ` [PATCH 4/6] omap3isp: ccdc: Remove support for interlaced data and master HS/VS mode Laurent Pinchart
2012-06-27 11:09   ` Sakari Ailus
2012-06-26 13:45 ` [PATCH 5/6] omap3isp: ccdc: Remove ispccdc_syncif structure Laurent Pinchart
2012-06-27 11:20   ` Sakari Ailus
2012-06-26 13:45 ` [PATCH 6/6] omap3isp: ccdc: Add YUV input formats support Laurent Pinchart
2012-06-27 11:55   ` Sakari Ailus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3151444.lq5j8qGhle@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=areddykondaveeti@aptina.com \
    --cc=ebutera@users.berlios.de \
    --cc=gary@mlbassoc.com \
    --cc=jp.francois@cynove.com \
    --cc=linux-media@vger.kernel.org \
    --cc=martinez.javier@gmail.com \
    --cc=sakari.ailus@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).