Re: [PATCH 2/2] [media] vivi: Teach it to tune FPS

2012-10-23 Thread Hans Verkuil
On Mon October 22 2012 19:29:01 Kirill Smelkov wrote:
 On Mon, Oct 22, 2012 at 09:01:39PM +0400, Kirill Smelkov wrote:
  On Mon, Oct 22, 2012 at 04:16:14PM +0200, Hans Verkuil wrote:
   On Mon October 22 2012 15:54:44 Kirill Smelkov wrote:
I was testing my video-over-ethernet subsystem today, and vivi seemed to
be perfect video source for testing when one don't have lots of capture
boards and cameras. Only its framerate was hardcoded to NTSC's 30fps,
while in my country we usually use PAL (25 fps). That's why the patch.
Thanks.
   
   Rather than introducing a module option, it's much nicer if you can
   implement enum_frameintervals and g/s_parm. This can be made quite 
   flexible
   allowing you to also support 50/59.94/60 fps.
  
  Thanks for feedback. I've reworked the patch for FPS to be set via
  -{g,s}_parm(), and yes now it is more flexble, because one can set
 
 By the way, here is what I've found while working on the abovementioned
 patch:
 
  8 
 From: Kirill Smelkov k...@mns.spb.ru
 Date: Mon, 22 Oct 2012 21:14:01 +0400
 Subject: [PATCH] v4l2: Fix typo in struct v4l2_captureparm description
 
 Judging from what drivers do and from my experience temeperframe
 fraction is set in seconds - look e.g. here
 
 static int bttv_g_parm(struct file *file, void *f,
 struct v4l2_streamparm *parm)
 {
 struct bttv_fh *fh = f;
 struct bttv *btv = fh-btv;
 
 v4l2_video_std_frame_period(bttv_tvnorms[btv-tvnorm].v4l2_id,
 parm-parm.capture.timeperframe);
 
 ...
 
 void v4l2_video_std_frame_period(int id, struct v4l2_fract *frameperiod)
 {
 if (id  V4L2_STD_525_60) {
 frameperiod-numerator = 1001;
 frameperiod-denominator = 3;
 } else {
 frameperiod-numerator = 1;
 frameperiod-denominator = 25;
 }
 
 and also v4l2-ctl in userspace decodes this as seconds:
 
 if (doioctl(fd, VIDIOC_G_PARM, parm, VIDIOC_G_PARM) == 0) {
 const struct v4l2_fract tf = parm.parm.capture.timeperframe;
 
 ...
 
 printf(\tFrames per second: %.3f (%d/%d)\n,
 (1.0 * tf.denominator) / tf.numerator,
 tf.denominator, tf.numerator);
 
 The typo was there from day 1 - added in 2002 in e028b61b ([PATCH]
 add v4l2 api)(*)
 
 (*) found in history tree
 git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
 
 Signed-off-by: Kirill Smelkov k...@mns.spb.ru

Good catch. Luckily the V4L2 spec is correct, it is just that single comment
that's wrong.

Acked-by: Hans Verkuil hans.verk...@cisco.com

Thanks!

Hans

 ---
  include/uapi/linux/videodev2.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
 index 57bfa59..2fff7ff 100644
 --- a/include/uapi/linux/videodev2.h
 +++ b/include/uapi/linux/videodev2.h
 @@ -726,29 +726,29 @@ struct v4l2_window {
   __u32   field;   /* enum v4l2_field */
   __u32   chromakey;
   struct v4l2_clip__user *clips;
   __u32   clipcount;
   void__user *bitmap;
   __u8global_alpha;
  };
  
  /*
   *   C A P T U R E   P A R A M E T E R S
   */
  struct v4l2_captureparm {
   __u32  capability;/*  Supported modes */
   __u32  capturemode;   /*  Current mode */
 - struct v4l2_fract  timeperframe;  /*  Time per frame in .1us units */
 + struct v4l2_fract  timeperframe;  /*  Time per frame in seconds */
   __u32  extendedmode;  /*  Driver-specific extensions */
   __u32  readbuffers;   /*  # of buffers for read */
   __u32  reserved[4];
  };
  
  /*  Flags for 'capability' and 'capturemode' fields */
  #define V4L2_MODE_HIGHQUALITY0x0001  /*  High quality imaging mode */
  #define V4L2_CAP_TIMEPERFRAME0x1000  /*  timeperframe field is 
 supported */
  
  struct v4l2_outputparm {
   __u32  capability;   /*  Supported modes */
   __u32  outputmode;   /*  Current mode */
   struct v4l2_fract  timeperframe; /*  Time per frame in seconds */
   __u32  extendedmode; /*  Driver-specific extensions */
 
--
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] vivi: Teach it to tune FPS

2012-10-23 Thread Hans Verkuil
On Mon October 22 2012 19:01:40 Kirill Smelkov wrote:
 On Mon, Oct 22, 2012 at 04:16:14PM +0200, Hans Verkuil wrote:
  On Mon October 22 2012 15:54:44 Kirill Smelkov wrote:
   I was testing my video-over-ethernet subsystem today, and vivi seemed to
   be perfect video source for testing when one don't have lots of capture
   boards and cameras. Only its framerate was hardcoded to NTSC's 30fps,
   while in my country we usually use PAL (25 fps). That's why the patch.
   Thanks.
  
  Rather than introducing a module option, it's much nicer if you can
  implement enum_frameintervals and g/s_parm. This can be made quite flexible
  allowing you to also support 50/59.94/60 fps.
 
 Thanks for feedback. I've reworked the patch for FPS to be set via
 -{g,s}_parm(), and yes now it is more flexble, because one can set
 different FPS on different vivi devices. Only I don't know V4L2 ioctls
 details well enough and various drivers do things differently. The patch
 is below. Is it ok?

Close, but it's not quite there.

You should run the v4l2-compliance tool from the v4l-utils.git repository
(take the master branch). That will report any errors in your implementation.

In this case g/s_parm doesn't set readbuffers (set it to 1) and if timeperframe
equals { 0, 0 }, then you should get a nominal framerate (let's stick to 29.97
for that). I would set the nominal framerate whenever the denominator == 0.

For vidioc_enum_frameintervals you need to check the IN fields and fill in the
stepwise struct.

Regards,

Hans

 
 Thanks,
 Kirill
 
 
  8 
 From: Kirill Smelkov k...@mns.spb.ru
 Date: Mon, 22 Oct 2012 17:25:24 +0400
 Subject: [PATCH v2] [media] vivi: Teach it to tune FPS
 
 I was testing my video-over-ethernet subsystem today, and vivi seemed to
 be perfect video source for testing when one don't have lots of capture
 boards and cameras. Only its framerate was hardcoded to NTSC's 30fps,
 while in my country we usually use PAL (25 fps).
 
 That's why here is this patch with -enum_frameintervals and
 -{g,s}_parm implemented as suggested by Hans Verkuil. Not sure I've
 done -g_parm right -- some drivers clear parm memory before setting
 fields, some don't. As at is at least it works for me (tested via
 v4l2-ctl -P / -p fps).
 
 Thanks.
 
 Signed-off-by: Kirill Smelkov k...@mns.spb.ru
 ---
  drivers/media/platform/vivi.c | 50 
 +--
  1 file changed, 43 insertions(+), 7 deletions(-)
 
 V2:
 
 - reworked FPS setting from module param to via -{g,s}_parm() as 
 suggested
   by Hans Verkuil.
 
 diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
 index 3e6902a..c0855a5 100644
 --- a/drivers/media/platform/vivi.c
 +++ b/drivers/media/platform/vivi.c
 @@ -36,10 +36,6 @@
  
  #define VIVI_MODULE_NAME vivi
  
 -/* Wake up at about 30 fps */
 -#define WAKE_NUMERATOR 30
 -#define WAKE_DENOMINATOR 1001
 -
  #define MAX_WIDTH 1920
  #define MAX_HEIGHT 1200
  
 @@ -232,6 +228,7 @@ struct vivi_dev {
  
   /* video capture */
   struct vivi_fmt*fmt;
 + struct v4l2_fract  timeperframe;
   unsigned int   width, height;
   struct vb2_queue   vb_vidq;
   unsigned int   field_count;
 @@ -660,8 +657,8 @@ static void vivi_thread_tick(struct vivi_dev *dev)
   dprintk(dev, 2, [%p/%d] done\n, buf, buf-vb.v4l2_buf.index);
  }
  
 -#define frames_to_ms(frames) \
 - ((frames * WAKE_NUMERATOR * 1000) / WAKE_DENOMINATOR)
 +#define frames_to_ms(dev, frames)\
 + ((frames * dev-timeperframe.numerator * 1000) / 
 dev-timeperframe.denominator)
  
  static void vivi_sleep(struct vivi_dev *dev)
  {
 @@ -677,7 +674,8 @@ static void vivi_sleep(struct vivi_dev *dev)
   goto stop_task;
  
   /* Calculate time to wake up */
 - timeout = msecs_to_jiffies(frames_to_ms(1));
 + timeout = msecs_to_jiffies(frames_to_ms(dev, 1));
 +
  
   vivi_thread_tick(dev);
  
 @@ -1049,6 +1047,39 @@ static int vidioc_s_input(struct file *file, void 
 *priv, unsigned int i)
   return 0;
  }
  
 +/* timeperframe is arbitrary and continous */
 +static int vidioc_enum_frameintervals(struct file *file, void *priv,
 +  struct v4l2_frmivalenum *fival)
 +{
 + fival-type = V4L2_FRMIVAL_TYPE_CONTINUOUS;
 + return 0;
 +}
 +
 +static int vidioc_g_parm(struct file *file, void *priv, struct 
 v4l2_streamparm *parm)
 +{
 + struct vivi_dev *dev = video_drvdata(file);
 +
 + if (parm-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
 + return -EINVAL;
 +
 + parm-parm.capture.capability   = V4L2_CAP_TIMEPERFRAME;
 + parm-parm.capture.timeperframe = dev-timeperframe;
 + return 0;
 +}
 +
 +static int vidioc_s_parm(struct file *file, void *priv, struct 
 v4l2_streamparm *parm)
 +{
 + struct vivi_dev *dev = video_drvdata(file);
 +
 + if (parm-type != 

Re: [media-workshop] Tentative Agenda for the November workshop

2012-10-23 Thread Hans Verkuil
On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:
 On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:
  On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:
   On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:
On 10/22/2012 12:39 PM, Laurent Pinchart wrote:
 On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:
 Hi all,
 
 This is the tentative agenda for the media workshop on November 8,
 2012. If you have additional things that you want to discuss, or
 something is wrong or incomplete in this list, please let me know so
 I can update the list.
 
 Thank you Hans for taking care of the agenda.
 
 - Explain current merging process (Mauro)
 - Open floor for discussions on how to improve it (Mauro)
 - Write down minimum requirements for new V4L2 (and DVB?) drivers,
   both for staging and mainline acceptance: which frameworks to use,
   v4l2-compliance,
 
 etc. (Hans Verkuil)
 - V4L2 ambiguities (Hans Verkuil)
 - TSMux device (a mux rather than a demux): Alain Volmat
 - dmabuf status, esp. with regards to being able to test
 (Mauro/Samsung)
 - Device tree support (Guennadi, not known yet whether this topic is
 needed) - Creating/selecting contexts for hardware that supports this
 (Samsung, only if time is available)
 
 This last topic will likely require lots of brainstorming, and thus
 time. If the schedule permits, would anyone be interested in meeting
 earlier during the week already ?

My intention was to also possibly discuss it with others before the
actual media workshop. Would be nice if we could have arranged such a
meeting. I'm not sure about the room conditions though. It's probably
not a big issue, unless there is really many people interested in that
topic.
   
   A small room with a projector would be nice if possible, although not
   required. Who would be interested in attending a brainstorming session on
   contexts ?
  
  I would be, but the problem is that the conference is also interesting.
 
 More interesting than a brainstorming session about hardware contexts ? ;-) 
 There's of course talks I want to attend, but I can probably skip some of 
 them.
 
  The only day I have really available is the Friday *after* the summit.
 
 We'll probably need several brainstorming sessions anyway. I'd like to 
 organize one before the media summit though, as we'll have limited time to 
 discuss the topic during the summit, which doesn't suit brainstorming 
 sessions 
 very well.

Sylwester, would Samsung be able to prepare for a brainstorming session on
Monday or Tuesday? Both Laurent and myself have presentations on Wednesday,
so that's not the best day for such a session.

Do you think we should do a half-day or a full day session on this?

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


[PATCH TRIVIAL for 3.7] mem2mem: replace BUG_ON with WARN_ON

2012-10-23 Thread Nicolas THERY
See following thread for rationale:

http://www.spinics.net/lists/linux-media/msg52462.html

Tested by compilation only.

Signed-off-by: Nicolas Thery nicolas.th...@st.com
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 3ac8358..017fed8 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -510,12 +510,10 @@ struct v4l2_m2m_dev *v4l2_m2m_init(struct v4l2_m2m_ops 
*m2m_ops)
 {
struct v4l2_m2m_dev *m2m_dev;

-   if (!m2m_ops)
+   if (!m2m_ops || WARN_ON(!m2m_ops-device_run) ||
+   WARN_ON(!m2m_ops-job_abort))
return ERR_PTR(-EINVAL);

-   BUG_ON(!m2m_ops-device_run);
-   BUG_ON(!m2m_ops-job_abort);
-
m2m_dev = kzalloc(sizeof *m2m_dev, GFP_KERNEL);
if (!m2m_dev)
return ERR_PTR(-ENOMEM);
--
1.7.11.3
--
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 RESEND] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS

2012-10-23 Thread Sergei Shtylyov

Hello.

On 22-10-2012 16:12, Prabhakar Lad wrote:


From: Lad, Prabhakar prabhakar@ti.com



This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.



Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Sekhar Nori nsek...@ti.com
---
  Resending the patch since, it didn't reach the DLOS mailing list.



  This patch is based on the following patch series,
  ARM: davinci: dm365 EVM: add support for VPBE display
  (https://patchwork.kernel.org/patch/1295071/)



  arch/arm/mach-davinci/board-dm365-evm.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index 2924d61..771abb5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
.index  = 1,
.name   = Component,
.type   = V4L2_OUTPUT_TYPE_ANALOG,
-   .capabilities   = V4L2_OUT_CAP_CUSTOM_TIMINGS,
+   .capabilities   =  V4L2_OUT_CAP_DV_TIMINGS,


   Why this extra space after '='?

WBR, Sergei

--
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 RESEND] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS

2012-10-23 Thread Prabhakar Lad
Hi Sergei,

On Tue, Oct 23, 2012 at 3:18 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
 Hello.


 On 22-10-2012 16:12, Prabhakar Lad wrote:

 From: Lad, Prabhakar prabhakar@ti.com


 This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
 V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
 out.


 Signed-off-by: Lad, Prabhakar prabhakar@ti.com
 Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
 Cc: Sekhar Nori nsek...@ti.com
 ---
   Resending the patch since, it didn't reach the DLOS mailing list.


   This patch is based on the following patch series,
   ARM: davinci: dm365 EVM: add support for VPBE display
   (https://patchwork.kernel.org/patch/1295071/)


   arch/arm/mach-davinci/board-dm365-evm.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
 b/arch/arm/mach-davinci/board-dm365-evm.c
 index 2924d61..771abb5 100644
 --- a/arch/arm/mach-davinci/board-dm365-evm.c
 +++ b/arch/arm/mach-davinci/board-dm365-evm.c
 @@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
 .index  = 1,
 .name   = Component,
 .type   = V4L2_OUTPUT_TYPE_ANALOG,
 -   .capabilities   = V4L2_OUT_CAP_CUSTOM_TIMINGS,
 +   .capabilities   =  V4L2_OUT_CAP_DV_TIMINGS,


Why this extra space after '='?

My Bad, I'll post a v2 fixing it.

Regards,
--Prabhakar

 WBR, Sergei

--
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: [media-workshop] Tentative Agenda for the November workshop

2012-10-23 Thread Laurent Pinchart
Hi Hans,

On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote:
 On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:
  On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:
   On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:
On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:
 On 10/22/2012 12:39 PM, Laurent Pinchart wrote:
  On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:
  Hi all,
  
  This is the tentative agenda for the media workshop on November
  8, 2012. If you have additional things that you want to discuss,
  or something is wrong or incomplete in this list, please let me
  know so I can update the list.
  
  Thank you Hans for taking care of the agenda.
  
  - Explain current merging process (Mauro)
  - Open floor for discussions on how to improve it (Mauro)
  - Write down minimum requirements for new V4L2 (and DVB?)
drivers, both for staging and mainline acceptance: which
frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
  - V4L2 ambiguities (Hans Verkuil)
  - TSMux device (a mux rather than a demux): Alain Volmat
  - dmabuf status, esp. with regards to being able to test
(Mauro/Samsung)
  - Device tree support (Guennadi, not known yet whether this topic
is needed) - Creating/selecting contexts for hardware that
supports this (Samsung, only if time is available)
  
  This last topic will likely require lots of brainstorming, and
  thus time. If the schedule permits, would anyone be interested in
  meeting earlier during the week already ?
 
 My intention was to also possibly discuss it with others before the
 actual media workshop. Would be nice if we could have arranged such
 a meeting. I'm not sure about the room conditions though. It's
 probably not a big issue, unless there is really many people
 interested in that topic.

A small room with a projector would be nice if possible, although not
required. Who would be interested in attending a brainstorming session
on contexts ?
   
   I would be, but the problem is that the conference is also interesting.
  
  More interesting than a brainstorming session about hardware contexts ?
  ;-) There's of course talks I want to attend, but I can probably skip some
  of them.
  
   The only day I have really available is the Friday *after* the summit.
  
  We'll probably need several brainstorming sessions anyway. I'd like to
  organize one before the media summit though, as we'll have limited time to
  discuss the topic during the summit, which doesn't suit brainstorming
  sessions very well.
 
 Sylwester, would Samsung be able to prepare for a brainstorming session on
 Monday or Tuesday? Both Laurent and myself have presentations on Wednesday,
 so that's not the best day for such a session.
 
 Do you think we should do a half-day or a full day session on this?

Half a day should be more than enough to start with. The topic is quite 
complex, and we'll need to sleep over it, several times. A full day would just 
result in brain overheat. I was thinking more in the line of starting our 
thought process, so maybe twice an hour or two hours would be good. That would 
allow us to attend the ELCE talks as well :-) (there's definitely a couple of 
them that I would like to listen to).

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


Re: [PATCH RESEND] media: davinci: vpbe: fix build warning

2012-10-23 Thread Prabhakar Lad
Hi Laurent,

On Mon, Oct 22, 2012 at 5:53 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Prabhakar,

 On Monday 22 October 2012 17:47:51 Prabhakar Lad wrote:
 From: Lad, Prabhakar prabhakar@ti.com

 Warnings were generated because of the following commit changed data type
 for address pointer

 195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_
 accessors add  __iomem annotation to fix following warnings

 drivers/media/platform/davinci/vpbe_osd.c: In function ‘osd_read’:
 drivers/media/platform/davinci/vpbe_osd.c:49:2: warning: passing
  argument 1 of ‘__raw_readl’ makes pointer from integer without a cast
 [enabled by default] arch/arm/include/asm/io.h:104:19: note: expected
 ‘const volatile
  void *’ but argument is of type ‘long unsigned int’

 Signed-off-by: Lad, Prabhakar prabhakar@ti.com
 Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
 ---
   Resending the patch since, it didn't reach the DLOS mailing list.

  drivers/media/platform/davinci/vpbe_osd.c |   16 
  1 files changed, 8 insertions(+), 8 deletions(-)

 diff --git a/drivers/media/platform/davinci/vpbe_osd.c
 b/drivers/media/platform/davinci/vpbe_osd.c index bba299d..9ab9280 100644
 --- a/drivers/media/platform/davinci/vpbe_osd.c
 +++ b/drivers/media/platform/davinci/vpbe_osd.c
 @@ -46,14 +46,14 @@ static inline u32 osd_read(struct osd_state *sd, u32
 offset) {
   struct osd_state *osd = sd;

 - return readl(osd-osd_base + offset);
 + return readl(IOMEM(osd-osd_base + offset));

 A better fix, in my opinion, would be to change the osd-osd_base field to be
 a void __iomem * instead of long unsigned int.

Ok I'll make it as void * and post a v2.

Regards,
--Prabhakar

  }

  static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
  {
   struct osd_state *osd = sd;

 - writel(val, osd-osd_base + offset);
 + writel(val, IOMEM(osd-osd_base + offset));

   return val;
  }
 @@ -63,9 +63,9 @@ static inline u32 osd_set(struct osd_state *sd, u32 mask,
 u32 offset) struct osd_state *osd = sd;

   u32 addr = osd-osd_base + offset;
 - u32 val = readl(addr) | mask;
 + u32 val = readl(IOMEM(addr)) | mask;

 - writel(val, addr);
 + writel(val, IOMEM(addr));

   return val;
  }
 @@ -75,9 +75,9 @@ static inline u32 osd_clear(struct osd_state *sd, u32
 mask, u32 offset) struct osd_state *osd = sd;

   u32 addr = osd-osd_base + offset;
 - u32 val = readl(addr)  ~mask;
 + u32 val = readl(IOMEM(addr))  ~mask;

 - writel(val, addr);
 + writel(val, IOMEM(addr));

   return val;
  }
 @@ -88,9 +88,9 @@ static inline u32 osd_modify(struct osd_state *sd, u32
 mask, u32 val, struct osd_state *osd = sd;

   u32 addr = osd-osd_base + offset;
 - u32 new_val = (readl(addr)  ~mask) | (val  mask);
 + u32 new_val = (readl(IOMEM(addr))  ~mask) | (val  mask);

 - writel(new_val, addr);
 + writel(new_val, IOMEM(addr));

   return new_val;
  }
 --
 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


[PATCH] omap3isp: preview: Add support for 8-bit formats at the sink pad

2012-10-23 Thread Laurent Pinchart
Support both grayscale (Y8) and Bayer (SBGGR8, SGBRG8, SGRBG8 and
SRGGB8) formats.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/platform/omap3isp/isppreview.c |   37 ++---
 1 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isppreview.c 
b/drivers/media/platform/omap3isp/isppreview.c
index 1ae1c09..479e5c8 100644
--- a/drivers/media/platform/omap3isp/isppreview.c
+++ b/drivers/media/platform/omap3isp/isppreview.c
@@ -200,10 +200,10 @@ static void preview_enable_invalaw(struct isp_prev_device 
*prev, bool enable)
 
if (enable)
isp_reg_set(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
-   ISPPRV_PCR_WIDTH | ISPPRV_PCR_INVALAW);
+   ISPPRV_PCR_INVALAW);
else
isp_reg_clr(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
-   ISPPRV_PCR_WIDTH | ISPPRV_PCR_INVALAW);
+   ISPPRV_PCR_INVALAW);
 }
 
 /*
@@ -1014,7 +1014,7 @@ static void preview_config_averager(struct 
isp_prev_device *prev, u8 average)
 /*
  * preview_config_input_format - Configure the input format
  * @prev: The preview engine
- * @format: Format on the preview engine sink pad
+ * @info: Sink pad format information
  *
  * Enable and configure CFA interpolation for Bayer formats and disable it for
  * greyscale formats.
@@ -1025,22 +1025,29 @@ static void preview_config_averager(struct 
isp_prev_device *prev, u8 average)
  * reordered to support non-GRBG Bayer patterns.
  */
 static void preview_config_input_format(struct isp_prev_device *prev,
-   const struct v4l2_mbus_framefmt *format)
+   const struct isp_format_info *info)
 {
struct isp_device *isp = to_isp_device(prev);
struct prev_params *params;
 
-   switch (format-code) {
-   case V4L2_MBUS_FMT_SGRBG10_1X10:
+   if (info-bpp == 8)
+   isp_reg_set(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
+   ISPPRV_PCR_WIDTH);
+   else
+   isp_reg_clr(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
+   ISPPRV_PCR_WIDTH);
+
+   switch (info-flavor) {
+   case V4L2_MBUS_FMT_SGRBG8_1X8:
prev-params.cfa_order = 0;
break;
-   case V4L2_MBUS_FMT_SRGGB10_1X10:
+   case V4L2_MBUS_FMT_SRGGB8_1X8:
prev-params.cfa_order = 1;
break;
-   case V4L2_MBUS_FMT_SBGGR10_1X10:
+   case V4L2_MBUS_FMT_SBGGR8_1X8:
prev-params.cfa_order = 2;
break;
-   case V4L2_MBUS_FMT_SGBRG10_1X10:
+   case V4L2_MBUS_FMT_SGBRG8_1X8:
prev-params.cfa_order = 3;
break;
default:
@@ -1389,6 +1396,7 @@ static unsigned int preview_max_out_width(struct 
isp_prev_device *prev)
 static void preview_configure(struct isp_prev_device *prev)
 {
struct isp_device *isp = to_isp_device(prev);
+   const struct isp_format_info *info;
struct v4l2_mbus_framefmt *format;
unsigned long flags;
u32 update;
@@ -1402,17 +1410,19 @@ static void preview_configure(struct isp_prev_device 
*prev)
 
/* PREV_PAD_SINK */
format = prev-formats[PREV_PAD_SINK];
+   info = omap3isp_video_format_info(format-code);
 
preview_adjust_bandwidth(prev);
 
-   preview_config_input_format(prev, format);
+   preview_config_input_format(prev, info);
preview_config_input_size(prev, active);
 
if (prev-input == PREVIEW_INPUT_CCDC)
preview_config_inlineoffset(prev, 0);
else
preview_config_inlineoffset(prev,
-   ALIGN(format-width, 0x20) * 2);
+   ALIGN(format-width, 0x20) *
+   DIV_ROUND_UP(info-bpp, 8));
 
preview_setup_hw(prev, update, active);
 
@@ -1709,6 +1719,11 @@ __preview_get_crop(struct isp_prev_device *prev, struct 
v4l2_subdev_fh *fh,
 
 /* previewer format descriptions */
 static const unsigned int preview_input_fmts[] = {
+   V4L2_MBUS_FMT_Y8_1X8,
+   V4L2_MBUS_FMT_SGRBG8_1X8,
+   V4L2_MBUS_FMT_SRGGB8_1X8,
+   V4L2_MBUS_FMT_SBGGR8_1X8,
+   V4L2_MBUS_FMT_SGBRG8_1X8,
V4L2_MBUS_FMT_Y10_1X10,
V4L2_MBUS_FMT_SGRBG10_1X10,
V4L2_MBUS_FMT_SRGGB10_1X10,
-- 
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


Re: [media-workshop] Tentative Agenda for the November workshop

2012-10-23 Thread Sylwester Nawrocki
Hi Hans, Laurent,

On 10/23/2012 12:22 PM, Laurent Pinchart wrote:
 On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote:
 On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:
 On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:
 On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:
 On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:
 On 10/22/2012 12:39 PM, Laurent Pinchart wrote:
 On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:
 Hi all,

 This is the tentative agenda for the media workshop on November
 8, 2012. If you have additional things that you want to discuss,
 or something is wrong or incomplete in this list, please let me
 know so I can update the list.

 Thank you Hans for taking care of the agenda.

 - Explain current merging process (Mauro)
 - Open floor for discussions on how to improve it (Mauro)
 - Write down minimum requirements for new V4L2 (and DVB?)
   drivers, both for staging and mainline acceptance: which
   frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
 - V4L2 ambiguities (Hans Verkuil)
 - TSMux device (a mux rather than a demux): Alain Volmat
 - dmabuf status, esp. with regards to being able to test
   (Mauro/Samsung)
 - Device tree support (Guennadi, not known yet whether this topic
   is needed) - Creating/selecting contexts for hardware that
   supports this (Samsung, only if time is available)

 This last topic will likely require lots of brainstorming, and
 thus time. If the schedule permits, would anyone be interested in
 meeting earlier during the week already ?

 My intention was to also possibly discuss it with others before the
 actual media workshop. Would be nice if we could have arranged such
 a meeting. I'm not sure about the room conditions though. It's
 probably not a big issue, unless there is really many people
 interested in that topic.

 A small room with a projector would be nice if possible, although not
 required. Who would be interested in attending a brainstorming session
 on contexts ?

 I would be, but the problem is that the conference is also interesting.

 More interesting than a brainstorming session about hardware contexts ?
 ;-) There's of course talks I want to attend, but I can probably skip some
 of them.

 The only day I have really available is the Friday *after* the summit.

 We'll probably need several brainstorming sessions anyway. I'd like to
 organize one before the media summit though, as we'll have limited time to
 discuss the topic during the summit, which doesn't suit brainstorming
 sessions very well.

 Sylwester, would Samsung be able to prepare for a brainstorming session on
 Monday or Tuesday? Both Laurent and myself have presentations on Wednesday,
 so that's not the best day for such a session.

Kamil has presentation on Tuesday so there would be only Monday left.

 Do you think we should do a half-day or a full day session on this?
 
 Half a day should be more than enough to start with. The topic is quite 
 complex, and we'll need to sleep over it, several times. A full day would 
 just 
 result in brain overheat. I was thinking more in the line of starting our 
 thought process, so maybe twice an hour or two hours would be good. That 
 would 
 allow us to attend the ELCE talks as well :-) (there's definitely a couple of 
 them that I would like to listen to).

I agree, I wouldn't like to loose whole day of the conference for that
as well. One, two hours for the starters could be sufficient. So we can
possibly agree on some initial idea and could get back to it later.
I don't think I have already material for a full day session.

--

Regards,
Sylwester

--
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] omap3isp: preview: Add support for 8-bit formats at the sink pad

2012-10-23 Thread Laurent Pinchart
Support both grayscale (Y8) and Bayer (SBGGR8, SGBRG8, SGRBG8 and
SRGGB8) formats.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/platform/omap3isp/isppreview.c |   40 ++
 1 files changed, 28 insertions(+), 12 deletions(-)

Changes since v1:

- Handle V4L2_MBUS_FMT_Y8_1X8 in preview_config_input_size()

diff --git a/drivers/media/platform/omap3isp/isppreview.c 
b/drivers/media/platform/omap3isp/isppreview.c
index 1ae1c09..e3d192c 100644
--- a/drivers/media/platform/omap3isp/isppreview.c
+++ b/drivers/media/platform/omap3isp/isppreview.c
@@ -200,10 +200,10 @@ static void preview_enable_invalaw(struct isp_prev_device 
*prev, bool enable)
 
if (enable)
isp_reg_set(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
-   ISPPRV_PCR_WIDTH | ISPPRV_PCR_INVALAW);
+   ISPPRV_PCR_INVALAW);
else
isp_reg_clr(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
-   ISPPRV_PCR_WIDTH | ISPPRV_PCR_INVALAW);
+   ISPPRV_PCR_INVALAW);
 }
 
 /*
@@ -1014,7 +1014,7 @@ static void preview_config_averager(struct 
isp_prev_device *prev, u8 average)
 /*
  * preview_config_input_format - Configure the input format
  * @prev: The preview engine
- * @format: Format on the preview engine sink pad
+ * @info: Sink pad format information
  *
  * Enable and configure CFA interpolation for Bayer formats and disable it for
  * greyscale formats.
@@ -1025,22 +1025,29 @@ static void preview_config_averager(struct 
isp_prev_device *prev, u8 average)
  * reordered to support non-GRBG Bayer patterns.
  */
 static void preview_config_input_format(struct isp_prev_device *prev,
-   const struct v4l2_mbus_framefmt *format)
+   const struct isp_format_info *info)
 {
struct isp_device *isp = to_isp_device(prev);
struct prev_params *params;
 
-   switch (format-code) {
-   case V4L2_MBUS_FMT_SGRBG10_1X10:
+   if (info-bpp == 8)
+   isp_reg_set(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
+   ISPPRV_PCR_WIDTH);
+   else
+   isp_reg_clr(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
+   ISPPRV_PCR_WIDTH);
+
+   switch (info-flavor) {
+   case V4L2_MBUS_FMT_SGRBG8_1X8:
prev-params.cfa_order = 0;
break;
-   case V4L2_MBUS_FMT_SRGGB10_1X10:
+   case V4L2_MBUS_FMT_SRGGB8_1X8:
prev-params.cfa_order = 1;
break;
-   case V4L2_MBUS_FMT_SBGGR10_1X10:
+   case V4L2_MBUS_FMT_SBGGR8_1X8:
prev-params.cfa_order = 2;
break;
-   case V4L2_MBUS_FMT_SGBRG10_1X10:
+   case V4L2_MBUS_FMT_SGBRG8_1X8:
prev-params.cfa_order = 3;
break;
default:
@@ -1081,7 +1088,8 @@ static void preview_config_input_size(struct 
isp_prev_device *prev, u32 active)
unsigned int elv = prev-crop.top + prev-crop.height - 1;
u32 features;
 
-   if (format-code != V4L2_MBUS_FMT_Y10_1X10) {
+   if (format-code != V4L2_MBUS_FMT_Y8_1X8 
+   format-code != V4L2_MBUS_FMT_Y10_1X10) {
sph -= 2;
eph += 2;
slv -= 2;
@@ -1389,6 +1397,7 @@ static unsigned int preview_max_out_width(struct 
isp_prev_device *prev)
 static void preview_configure(struct isp_prev_device *prev)
 {
struct isp_device *isp = to_isp_device(prev);
+   const struct isp_format_info *info;
struct v4l2_mbus_framefmt *format;
unsigned long flags;
u32 update;
@@ -1402,17 +1411,19 @@ static void preview_configure(struct isp_prev_device 
*prev)
 
/* PREV_PAD_SINK */
format = prev-formats[PREV_PAD_SINK];
+   info = omap3isp_video_format_info(format-code);
 
preview_adjust_bandwidth(prev);
 
-   preview_config_input_format(prev, format);
+   preview_config_input_format(prev, info);
preview_config_input_size(prev, active);
 
if (prev-input == PREVIEW_INPUT_CCDC)
preview_config_inlineoffset(prev, 0);
else
preview_config_inlineoffset(prev,
-   ALIGN(format-width, 0x20) * 2);
+   ALIGN(format-width, 0x20) *
+   DIV_ROUND_UP(info-bpp, 8));
 
preview_setup_hw(prev, update, active);
 
@@ -1709,6 +1720,11 @@ __preview_get_crop(struct isp_prev_device *prev, struct 
v4l2_subdev_fh *fh,
 
 /* previewer format descriptions */
 static const unsigned int preview_input_fmts[] = {
+   V4L2_MBUS_FMT_Y8_1X8,
+   V4L2_MBUS_FMT_SGRBG8_1X8,
+   V4L2_MBUS_FMT_SRGGB8_1X8,
+   V4L2_MBUS_FMT_SBGGR8_1X8,
+   V4L2_MBUS_FMT_SGBRG8_1X8,
V4L2_MBUS_FMT_Y10_1X10,
V4L2_MBUS_FMT_SGRBG10_1X10,
V4L2_MBUS_FMT_SRGGB10_1X10,
-- 
Regards,

Laurent 

[PATCH v2] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS

2012-10-23 Thread Prabhakar Lad
From: Lad, Prabhakar prabhakar@ti.com

This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.

Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Sergei Shtylyov sshtyl...@mvista.com
---
 Changes for v2:
 1: fixed code  alignment as pointed by Sergei

 arch/arm/mach-davinci/board-dm365-evm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index 2924d61..8519d2d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
.index  = 1,
.name   = Component,
.type   = V4L2_OUTPUT_TYPE_ANALOG,
-   .capabilities   = V4L2_OUT_CAP_CUSTOM_TIMINGS,
+   .capabilities   = V4L2_OUT_CAP_DV_TIMINGS,
},
.subdev_name= VPBE_VENC_SUBDEV_NAME,
.default_mode   = 480p59_94,
-- 
1.7.4.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 v2] media: davinci: vpbe: fix build warning

2012-10-23 Thread Prabhakar Lad
From: Lad, Prabhakar prabhakar@ti.com

Warnings were generated because of the following commit changed data type for
address pointer

195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors
add  __iomem annotation to fix following warnings

drivers/media/platform/davinci/vpbe_osd.c: In function ‘osd_read’:
drivers/media/platform/davinci/vpbe_osd.c:49:2: warning: passing
 argument 1 of ‘__raw_readl’ makes pointer from integer without a cast [enabled 
by default]
arch/arm/include/asm/io.h:104:19: note: expected ‘const volatile
 void *’ but argument is of type ‘long unsigned int’

Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
---
 Changes for v2:
 1: Made the base addr to void __iomem * instead of long unsigned,
as pointed by Laurent.

 drivers/media/platform/davinci/vpbe_osd.c |9 -
 include/media/davinci/vpbe_osd.h  |2 +-
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_osd.c 
b/drivers/media/platform/davinci/vpbe_osd.c
index bba299d..707f243 100644
--- a/drivers/media/platform/davinci/vpbe_osd.c
+++ b/drivers/media/platform/davinci/vpbe_osd.c
@@ -62,7 +62,7 @@ static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 
offset)
 {
struct osd_state *osd = sd;
 
-   u32 addr = osd-osd_base + offset;
+   void __iomem *addr = osd-osd_base + offset;
u32 val = readl(addr) | mask;
 
writel(val, addr);
@@ -74,7 +74,7 @@ static inline u32 osd_clear(struct osd_state *sd, u32 mask, 
u32 offset)
 {
struct osd_state *osd = sd;
 
-   u32 addr = osd-osd_base + offset;
+   void __iomem *addr = osd-osd_base + offset;
u32 val = readl(addr)  ~mask;
 
writel(val, addr);
@@ -87,7 +87,7 @@ static inline u32 osd_modify(struct osd_state *sd, u32 mask, 
u32 val,
 {
struct osd_state *osd = sd;
 
-   u32 addr = osd-osd_base + offset;
+   void __iomem *addr = osd-osd_base + offset;
u32 new_val = (readl(addr)  ~mask) | (val  mask);
 
writel(new_val, addr);
@@ -1559,8 +1559,7 @@ static int osd_probe(struct platform_device *pdev)
ret = -ENODEV;
goto free_mem;
}
-   osd-osd_base = (unsigned long)ioremap_nocache(res-start,
-   osd-osd_size);
+   osd-osd_base = ioremap_nocache(res-start, osd-osd_size);
if (!osd-osd_base) {
dev_err(osd-dev, Unable to map the OSD region\n);
ret = -ENODEV;
diff --git a/include/media/davinci/vpbe_osd.h b/include/media/davinci/vpbe_osd.h
index d7e397a..5ab0d8d 100644
--- a/include/media/davinci/vpbe_osd.h
+++ b/include/media/davinci/vpbe_osd.h
@@ -357,7 +357,7 @@ struct osd_state {
spinlock_t lock;
struct device *dev;
dma_addr_t osd_base_phys;
-   unsigned long osd_base;
+   void __iomem *osd_base;
unsigned long osd_size;
/* 1--the isr will toggle the VID0 ping-pong buffer */
int pingpong;
-- 
1.7.4.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 v3] [media] vivi: Teach it to tune FPS

2012-10-23 Thread Kirill Smelkov
On Tue, Oct 23, 2012 at 08:40:04AM +0200, Hans Verkuil wrote:
 On Mon October 22 2012 19:01:40 Kirill Smelkov wrote:
  On Mon, Oct 22, 2012 at 04:16:14PM +0200, Hans Verkuil wrote:
   On Mon October 22 2012 15:54:44 Kirill Smelkov wrote:
I was testing my video-over-ethernet subsystem today, and vivi seemed to
be perfect video source for testing when one don't have lots of capture
boards and cameras. Only its framerate was hardcoded to NTSC's 30fps,
while in my country we usually use PAL (25 fps). That's why the patch.
Thanks.
   
   Rather than introducing a module option, it's much nicer if you can
   implement enum_frameintervals and g/s_parm. This can be made quite 
   flexible
   allowing you to also support 50/59.94/60 fps.
  
  Thanks for feedback. I've reworked the patch for FPS to be set via
  -{g,s}_parm(), and yes now it is more flexble, because one can set
  different FPS on different vivi devices. Only I don't know V4L2 ioctls
  details well enough and various drivers do things differently. The patch
  is below. Is it ok?
 
 Close, but it's not quite there.
 
 You should run the v4l2-compliance tool from the v4l-utils.git repository
 (take the master branch). That will report any errors in your implementation.
 
 In this case g/s_parm doesn't set readbuffers (set it to 1) and if 
 timeperframe
 equals { 0, 0 }, then you should get a nominal framerate (let's stick to 29.97
 for that). I would set the nominal framerate whenever the denominator == 0.
 
 For vidioc_enum_frameintervals you need to check the IN fields and fill in the
 stepwise struct.

Thanks for pointers and info about v4l2-compliance handy-tool. I've
tried to correct all the issues you mentioned above and here is the
patch.

(Only requirement to set stepwise.step to 1.0 for
 V4L2_FRMIVAL_TYPE_CONTINUOUS seems a bit illogical to me, but anyway,
 that's what the V4L2 spec requires...)

Thanks,
Kirill

 8 
From: Kirill Smelkov k...@mns.spb.ru
Date: Tue, 23 Oct 2012 16:56:59 +0400
Subject: [PATCH v3] [media] vivi: Teach it to tune FPS

I was testing my video-over-ethernet subsystem yesterday, and vivi
seemed to be perfect video source for testing when one don't have lots
of capture boards and cameras. Only its framerate was hardcoded to
NTSC's 30fps, while in my country we usually use PAL (25 fps) and I
needed that to precisely simulate bandwidth.

That's why here is this patch with -enum_frameintervals() and
-{g,s}_parm() implemented as suggested by Hans Verkuil which passes
v4l2-compliance and manual testing through v4l2-ctl -P / -p fps.

Regarding newly introduced __get_format(u32 pixelformat) I decided not
to convert original get_format() to operate on fourcc codes, since = 3
places in driver need to deal with v4l2_format and otherwise it won't be
handy.

Thanks.

Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
 drivers/media/platform/vivi.c | 84 ++-
 1 file changed, 75 insertions(+), 9 deletions(-)

V3:
- corrected issues with V4L2 spec compliance as pointed by Hans
  Verkuil.

V2:

- reworked FPS setting from module param to via -{g,s}_parm() as suggested
  by Hans Verkuil.


diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 3e6902a..3adea58 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -36,10 +36,6 @@
 
 #define VIVI_MODULE_NAME vivi
 
-/* Wake up at about 30 fps */
-#define WAKE_NUMERATOR 30
-#define WAKE_DENOMINATOR 1001
-
 #define MAX_WIDTH 1920
 #define MAX_HEIGHT 1200
 
@@ -69,6 +65,9 @@ MODULE_PARM_DESC(vid_limit, capture memory limit in 
megabytes);
 /* Global font descriptor */
 static const u8 *font8x16;
 
+/* default to NTSC timeperframe */
+static const struct v4l2_fract TPF_DEFAULT = {.numerator = 1001, .denominator 
= 3};
+
 #define dprintk(dev, level, fmt, arg...) \
v4l2_dbg(level, debug, dev-v4l2_dev, fmt, ## arg)
 
@@ -150,14 +149,14 @@ static struct vivi_fmt formats[] = {
},
 };
 
-static struct vivi_fmt *get_format(struct v4l2_format *f)
+static struct vivi_fmt *__get_format(u32 pixelformat)
 {
struct vivi_fmt *fmt;
unsigned int k;
 
for (k = 0; k  ARRAY_SIZE(formats); k++) {
fmt = formats[k];
-   if (fmt-fourcc == f-fmt.pix.pixelformat)
+   if (fmt-fourcc == pixelformat)
break;
}
 
@@ -167,6 +166,11 @@ static struct vivi_fmt *get_format(struct v4l2_format *f)
return formats[k];
 }
 
+static struct vivi_fmt *get_format(struct v4l2_format *f)
+{
+   return __get_format(f-fmt.pix.pixelformat);
+}
+
 /* buffer for one video frame */
 struct vivi_buffer {
/* common v4l buffer stuff -- must be first */
@@ -232,6 +236,7 @@ struct vivi_dev {
 
/* video capture */
struct vivi_fmt*fmt;
+   struct v4l2_fract  timeperframe;
unsigned int   width, height;
struct vb2_queue  

[PATCH 0/6] SMIA++ PLL and driver improvements

2012-10-23 Thread Sakari Ailus
Hi,

Here's a few SMIA++ patches from me and Laurent.

The set consists of cleanups, PLL calculator improvements and parallel bus
support for the PLL calculator.

Regards,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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/6] smiapp-pll: Correct type for min_t()

2012-10-23 Thread Sakari Ailus
Unsigned.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/i2c/smiapp-pll.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index 169f305..e92dc46 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -162,7 +162,7 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
more_mul_max);
/* Don't go above max pll op frequency. */
more_mul_max =
-   min_t(int,
+   min_t(uint32_t,
  more_mul_max,
  limits-max_pll_op_freq_hz
  / (pll-ext_clk_freq_hz / pll-pre_pll_clk_div * mul));
@@ -322,7 +322,7 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
for (sys_div = min_sys_div;
 sys_div = max_sys_div;
 sys_div += 2 - (sys_div  1)) {
-   int pix_div = DIV_ROUND_UP(vt_div, sys_div);
+   uint16_t pix_div = DIV_ROUND_UP(vt_div, sys_div);
 
if (pix_div  limits-min_vt_pix_clk_div
|| pix_div  limits-max_vt_pix_clk_div) {
-- 
1.7.2.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


[PATCH 6/6] smiapp-pll: Constify limits argument to smiapp_pll_calculate()

2012-10-23 Thread Sakari Ailus
From: Laurent Pinchart laurent.pinch...@ideasonboard.com

The limits are input parameters and should not be modified by the
smiapp_pll_calculate() function. Make them const.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/i2c/smiapp-pll.c |   35 +--
 drivers/media/i2c/smiapp-pll.h |3 ++-
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index cbef446..61e2401 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -88,7 +88,7 @@ static void print_pll(struct device *dev, struct smiapp_pll 
*pll)
 }
 
 static int __smiapp_pll_calculate(struct device *dev,
- struct smiapp_pll_limits *limits,
+ const struct smiapp_pll_limits *limits,
  struct smiapp_pll *pll, uint32_t mul,
  uint32_t div, uint32_t lane_op_clock_ratio)
 {
@@ -306,14 +306,10 @@ static int __smiapp_pll_calculate(struct device *dev,
pll-pixel_rate_csi =
pll-op_pix_clk_freq_hz * lane_op_clock_ratio;
 
-   rval = bounds_check(dev, pll-pre_pll_clk_div,
-   limits-min_pre_pll_clk_div,
-   limits-max_pre_pll_clk_div, pre_pll_clk_div);
-   if (!rval)
-   rval = bounds_check(
-   dev, pll-pll_ip_clk_freq_hz,
-   limits-min_pll_ip_freq_hz, limits-max_pll_ip_freq_hz,
-   pll_ip_clk_freq_hz);
+   rval = bounds_check(dev, pll-pll_ip_clk_freq_hz,
+   limits-min_pll_ip_freq_hz,
+   limits-max_pll_ip_freq_hz,
+   pll_ip_clk_freq_hz);
if (!rval)
rval = bounds_check(
dev, pll-pll_multiplier,
@@ -362,9 +358,12 @@ static int __smiapp_pll_calculate(struct device *dev,
return rval;
 }
 
-int smiapp_pll_calculate(struct device *dev, struct smiapp_pll_limits *limits,
+int smiapp_pll_calculate(struct device *dev,
+const struct smiapp_pll_limits *limits,
 struct smiapp_pll *pll)
 {
+   uint16_t min_pre_pll_clk_div;
+   uint16_t max_pre_pll_clk_div;
uint32_t lane_op_clock_ratio;
uint32_t mul, div;
unsigned int i;
@@ -397,33 +396,33 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
/* Figure out limits for pre-pll divider based on extclk */
dev_dbg(dev, min / max pre_pll_clk_div: %d / %d\n,
limits-min_pre_pll_clk_div, limits-max_pre_pll_clk_div);
-   limits-max_pre_pll_clk_div =
+   max_pre_pll_clk_div =
min_t(uint16_t, limits-max_pre_pll_clk_div,
  clk_div_even(pll-ext_clk_freq_hz /
   limits-min_pll_ip_freq_hz));
-   limits-min_pre_pll_clk_div =
+   min_pre_pll_clk_div =
max_t(uint16_t, limits-min_pre_pll_clk_div,
  clk_div_even_up(
  DIV_ROUND_UP(pll-ext_clk_freq_hz,
   limits-max_pll_ip_freq_hz)));
dev_dbg(dev, pre-pll check: min / max pre_pll_clk_div: %d / %d\n,
-   limits-min_pre_pll_clk_div, limits-max_pre_pll_clk_div);
+   min_pre_pll_clk_div, max_pre_pll_clk_div);
 
i = gcd(pll-pll_op_clk_freq_hz, pll-ext_clk_freq_hz);
mul = div_u64(pll-pll_op_clk_freq_hz, i);
div = pll-ext_clk_freq_hz / i;
dev_dbg(dev, mul %d / div %d\n, mul, div);
 
-   limits-min_pre_pll_clk_div =
-   max_t(uint16_t, limits-min_pre_pll_clk_div,
+   min_pre_pll_clk_div =
+   max_t(uint16_t, min_pre_pll_clk_div,
  clk_div_even_up(
  DIV_ROUND_UP(mul * pll-ext_clk_freq_hz,
   limits-max_pll_op_freq_hz)));
dev_dbg(dev, pll_op check: min / max pre_pll_clk_div: %d / %d\n,
-   limits-min_pre_pll_clk_div, limits-max_pre_pll_clk_div);
+   min_pre_pll_clk_div, max_pre_pll_clk_div);
 
-   for (pll-pre_pll_clk_div = limits-min_pre_pll_clk_div;
-pll-pre_pll_clk_div = limits-max_pre_pll_clk_div;
+   for (pll-pre_pll_clk_div = min_pre_pll_clk_div;
+pll-pre_pll_clk_div = max_pre_pll_clk_div;
 pll-pre_pll_clk_div += 2 - (pll-pre_pll_clk_div  1)) {
rval = __smiapp_pll_calculate(dev, limits, pll, mul, div,
  lane_op_clock_ratio);
diff --git a/drivers/media/i2c/smiapp-pll.h b/drivers/media/i2c/smiapp-pll.h
index 8500e6e..9491a41 100644
--- a/drivers/media/i2c/smiapp-pll.h
+++ b/drivers/media/i2c/smiapp-pll.h
@@ -107,7 +107,8 @@ struct smiapp_pll_limits {
 
 struct device;
 
-int 

[PATCH 5/6] smiapp-pll: Create a structure for OP and VT limits

2012-10-23 Thread Sakari Ailus
From: Laurent Pinchart laurent.pinch...@ideasonboard.com

OP and VT limits have identical fields, create a shared structure for
both.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/i2c/smiapp-pll.c |   54 
 drivers/media/i2c/smiapp-pll.h |   30 --
 drivers/media/i2c/smiapp/smiapp-core.c |   43 ++---
 3 files changed, 58 insertions(+), 69 deletions(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index d324360..cbef446 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -122,7 +122,7 @@ static int __smiapp_pll_calculate(struct device *dev,
more_mul_max);
/* Don't go above the division capability of op sys clock divider. */
more_mul_max = min(more_mul_max,
-  limits-max_op_sys_clk_div * pll-pre_pll_clk_div
+  limits-op.max_sys_clk_div * pll-pre_pll_clk_div
   / div);
dev_dbg(dev, more_mul_max: max_op_sys_clk_div check: %d\n,
more_mul_max);
@@ -152,7 +152,7 @@ static int __smiapp_pll_calculate(struct device *dev,
 
more_mul_factor = lcm(div, pll-pre_pll_clk_div) / div;
dev_dbg(dev, more_mul_factor: %d\n, more_mul_factor);
-   more_mul_factor = lcm(more_mul_factor, limits-min_op_sys_clk_div);
+   more_mul_factor = lcm(more_mul_factor, limits-op.min_sys_clk_div);
dev_dbg(dev, more_mul_factor: min_op_sys_clk_div: %d\n,
more_mul_factor);
i = roundup(more_mul_min, more_mul_factor);
@@ -220,19 +220,19 @@ static int __smiapp_pll_calculate(struct device *dev,
dev_dbg(dev, min_vt_div: %d\n, min_vt_div);
min_vt_div = max(min_vt_div,
 DIV_ROUND_UP(pll-pll_op_clk_freq_hz,
- limits-max_vt_pix_clk_freq_hz));
+ limits-vt.max_pix_clk_freq_hz));
dev_dbg(dev, min_vt_div: max_vt_pix_clk_freq_hz: %d\n,
min_vt_div);
min_vt_div = max_t(uint32_t, min_vt_div,
-  limits-min_vt_pix_clk_div
-  * limits-min_vt_sys_clk_div);
+  limits-vt.min_pix_clk_div
+  * limits-vt.min_sys_clk_div);
dev_dbg(dev, min_vt_div: min_vt_clk_div: %d\n, min_vt_div);
 
-   max_vt_div = limits-max_vt_sys_clk_div * limits-max_vt_pix_clk_div;
+   max_vt_div = limits-vt.max_sys_clk_div * limits-vt.max_pix_clk_div;
dev_dbg(dev, max_vt_div: %d\n, max_vt_div);
max_vt_div = min(max_vt_div,
 DIV_ROUND_UP(pll-pll_op_clk_freq_hz,
- limits-min_vt_pix_clk_freq_hz));
+ limits-vt.min_pix_clk_freq_hz));
dev_dbg(dev, max_vt_div: min_vt_pix_clk_freq_hz: %d\n,
max_vt_div);
 
@@ -240,28 +240,28 @@ static int __smiapp_pll_calculate(struct device *dev,
 * Find limitsits for sys_clk_div. Not all values are possible
 * with all values of pix_clk_div.
 */
-   min_sys_div = limits-min_vt_sys_clk_div;
+   min_sys_div = limits-vt.min_sys_clk_div;
dev_dbg(dev, min_sys_div: %d\n, min_sys_div);
min_sys_div = max(min_sys_div,
  DIV_ROUND_UP(min_vt_div,
-  limits-max_vt_pix_clk_div));
+  limits-vt.max_pix_clk_div));
dev_dbg(dev, min_sys_div: max_vt_pix_clk_div: %d\n, min_sys_div);
min_sys_div = max(min_sys_div,
  pll-pll_op_clk_freq_hz
- / limits-max_vt_sys_clk_freq_hz);
+ / limits-vt.max_sys_clk_freq_hz);
dev_dbg(dev, min_sys_div: max_pll_op_clk_freq_hz: %d\n, min_sys_div);
min_sys_div = clk_div_even_up(min_sys_div);
dev_dbg(dev, min_sys_div: one or even: %d\n, min_sys_div);
 
-   max_sys_div = limits-max_vt_sys_clk_div;
+   max_sys_div = limits-vt.max_sys_clk_div;
dev_dbg(dev, max_sys_div: %d\n, max_sys_div);
max_sys_div = min(max_sys_div,
  DIV_ROUND_UP(max_vt_div,
-  limits-min_vt_pix_clk_div));
+  limits-vt.min_pix_clk_div));
dev_dbg(dev, max_sys_div: min_vt_pix_clk_div: %d\n, max_sys_div);
max_sys_div = min(max_sys_div,
  DIV_ROUND_UP(pll-pll_op_clk_freq_hz,
-  limits-min_vt_pix_clk_freq_hz));
+  limits-vt.min_pix_clk_freq_hz));
dev_dbg(dev, max_sys_div: min_vt_pix_clk_freq_hz: %d\n, max_sys_div);
 
/*
@@ -276,13 +276,13 @@ static int __smiapp_pll_calculate(struct device *dev,
 sys_div += 2 - (sys_div  1)) {

[PATCH 4/6] smiapp-pll: Parallel bus support

2012-10-23 Thread Sakari Ailus
Support sensors with parallel interface.

Make smiapp_pll.flags also 8-bit so it fits nicely into two 32-bit words
with the other 8-bit fields.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/i2c/smiapp-pll.c |   19 +++
 drivers/media/i2c/smiapp-pll.h |   26 --
 drivers/media/i2c/smiapp/smiapp-core.c |3 ++-
 3 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index d7e3475..d324360 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -371,7 +371,7 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
int rval = -EINVAL;
 
if (pll-flags  SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE)
-   lane_op_clock_ratio = pll-lanes;
+   lane_op_clock_ratio = pll-csi2.lanes;
else
lane_op_clock_ratio = 1;
dev_dbg(dev, lane_op_clock_ratio: %d\n, lane_op_clock_ratio);
@@ -379,9 +379,20 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
dev_dbg(dev, binning: %dx%d\n, pll-binning_horizontal,
pll-binning_vertical);
 
-   /* CSI transfers 2 bits per clock per lane; thus times 2 */
-   pll-pll_op_clk_freq_hz = pll-link_freq * 2
-   * (pll-lanes / lane_op_clock_ratio);
+   switch (pll-bus_type) {
+   case SMIAPP_PLL_BUS_TYPE_CSI2:
+   /* CSI transfers 2 bits per clock per lane; thus times 2 */
+   pll-pll_op_clk_freq_hz = pll-link_freq * 2
+   * (pll-csi2.lanes / lane_op_clock_ratio);
+   break;
+   case SMIAPP_PLL_BUS_TYPE_PARALLEL:
+   pll-pll_op_clk_freq_hz = pll-link_freq * pll-bits_per_pixel
+   / DIV_ROUND_UP(pll-bits_per_pixel,
+  pll-parallel.bus_width);
+   break;
+   default:
+   return -EINVAL;
+   }
 
/* Figure out limits for pre-pll divider based on extclk */
dev_dbg(dev, min / max pre_pll_clk_div: %d / %d\n,
diff --git a/drivers/media/i2c/smiapp-pll.h b/drivers/media/i2c/smiapp-pll.h
index cb2d2db..439fe5d 100644
--- a/drivers/media/i2c/smiapp-pll.h
+++ b/drivers/media/i2c/smiapp-pll.h
@@ -27,16 +27,34 @@
 
 #include linux/device.h
 
+/* CSI-2 or CCP-2 */
+#define SMIAPP_PLL_BUS_TYPE_CSI2   0x00
+#define SMIAPP_PLL_BUS_TYPE_PARALLEL   0x01
+
+/* op pix clock is for all lanes in total normally */
+#define SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE  (1  0)
+#define SMIAPP_PLL_FLAG_NO_OP_CLOCKS   (1  1)
+
 struct smiapp_pll {
-   uint8_t lanes;
+   /* input values */
+   uint8_t bus_type;
+   union {
+   struct {
+   uint8_t lanes;
+   } csi2;
+   struct {
+   uint8_t bus_width;
+   } parallel;
+   };
+   uint8_t flags;
uint8_t binning_horizontal;
uint8_t binning_vertical;
uint8_t scale_m;
uint8_t scale_n;
uint8_t bits_per_pixel;
-   uint16_t flags;
uint32_t link_freq;
 
+   /* output values */
uint16_t pre_pll_clk_div;
uint16_t pll_multiplier;
uint16_t op_sys_clk_div;
@@ -91,10 +109,6 @@ struct smiapp_pll_limits {
uint32_t min_line_length_pck;
 };
 
-/* op pix clock is for all lanes in total normally */
-#define SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE  (1  0)
-#define SMIAPP_PLL_FLAG_NO_OP_CLOCKS   (1  1)
-
 struct device;
 
 int smiapp_pll_calculate(struct device *dev, struct smiapp_pll_limits *limits,
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 868ad0b..42316cb 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2625,7 +2625,8 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
goto out_nvm_release;
 
/* prepare PLL configuration input values */
-   pll-lanes = sensor-platform_data-lanes;
+   pll-bus_type = SMIAPP_PLL_BUS_TYPE_CSI2;
+   pll-csi2.lanes = sensor-platform_data-lanes;
pll-ext_clk_freq_hz = sensor-platform_data-ext_clk;
/* Profile 0 sensors have no separate OP clock branch. */
if (sensor-minfo.smiapp_profile == SMIAPP_PROFILE_0)
-- 
1.7.2.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


[PATCH 3/6] smiapp: Input for PLL configuration is mostly static

2012-10-23 Thread Sakari Ailus
The input values for PLL configuration are mostly static. So set them when
the sensor is registered.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/i2c/smiapp/smiapp-core.c |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index e08e588..868ad0b 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -276,11 +276,6 @@ static int smiapp_pll_update(struct smiapp_sensor *sensor)
struct smiapp_pll *pll = sensor-pll;
int rval;
 
-   memset(sensor-pll, 0, sizeof(sensor-pll));
-
-   pll-lanes = sensor-platform_data-lanes;
-   pll-ext_clk_freq_hz = sensor-platform_data-ext_clk;
-
if (sensor-minfo.smiapp_profile == SMIAPP_PROFILE_0) {
/*
 * Fill in operational clock divisors limits from the
@@ -296,20 +291,13 @@ static int smiapp_pll_update(struct smiapp_sensor *sensor)
lim.max_op_sys_clk_freq_hz = lim.max_vt_sys_clk_freq_hz;
lim.min_op_pix_clk_freq_hz = lim.min_vt_pix_clk_freq_hz;
lim.max_op_pix_clk_freq_hz = lim.max_vt_pix_clk_freq_hz;
-   /* Profile 0 sensors have no separate OP clock branch. */
-   pll-flags |= SMIAPP_PLL_FLAG_NO_OP_CLOCKS;
}
 
-   if (smiapp_needs_quirk(sensor,
-  SMIAPP_QUIRK_FLAG_OP_PIX_CLOCK_PER_LANE))
-   pll-flags |= SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE;
-
pll-binning_horizontal = sensor-binning_horizontal;
pll-binning_vertical = sensor-binning_vertical;
pll-link_freq =
sensor-link_freq-qmenu_int[sensor-link_freq-val];
pll-scale_m = sensor-scale_m;
-   pll-scale_n = sensor-limits[SMIAPP_LIMIT_SCALER_N_MIN];
pll-bits_per_pixel = sensor-csi_format-compressed;
 
rval = smiapp_pll_calculate(client-dev, lim, pll);
@@ -2369,6 +2357,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
 {
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
struct i2c_client *client = v4l2_get_subdevdata(subdev);
+   struct smiapp_pll *pll = sensor-pll;
struct smiapp_subdev *last = NULL;
u32 tmp;
unsigned int i;
@@ -2635,6 +2624,17 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
if (rval  0)
goto out_nvm_release;
 
+   /* prepare PLL configuration input values */
+   pll-lanes = sensor-platform_data-lanes;
+   pll-ext_clk_freq_hz = sensor-platform_data-ext_clk;
+   /* Profile 0 sensors have no separate OP clock branch. */
+   if (sensor-minfo.smiapp_profile == SMIAPP_PROFILE_0)
+   pll-flags |= SMIAPP_PLL_FLAG_NO_OP_CLOCKS;
+   if (smiapp_needs_quirk(sensor,
+  SMIAPP_QUIRK_FLAG_OP_PIX_CLOCK_PER_LANE))
+   pll-flags |= SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE;
+   pll-scale_n = sensor-limits[SMIAPP_LIMIT_SCALER_N_MIN];
+
rval = smiapp_update_mode(sensor);
if (rval) {
dev_err(client-dev, update mode failed\n);
-- 
1.7.2.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


[PATCH 2/6] smiapp-pll: Try other pre-pll divisors

2012-10-23 Thread Sakari Ailus
The smiapp pll calculator assumed that the minimum pre-pll divisor was
perfect. That may not always be the case, so let's try the others, too.
Typically there are just a few alternatives.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/i2c/smiapp-pll.c |  131 ++--
 1 files changed, 73 insertions(+), 58 deletions(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index e92dc46..d7e3475 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -58,7 +58,7 @@ static int bounds_check(struct device *dev, uint32_t val,
if (val = min  val = max)
return 0;
 
-   dev_warn(dev, %s out of bounds: %d (%d--%d)\n, str, val, min, max);
+   dev_dbg(dev, %s out of bounds: %d (%d--%d)\n, str, val, min, max);
 
return -EINVAL;
 }
@@ -87,14 +87,14 @@ static void print_pll(struct device *dev, struct smiapp_pll 
*pll)
dev_dbg(dev, vt_pix_clk_freq_hz \t%d\n, pll-vt_pix_clk_freq_hz);
 }
 
-int smiapp_pll_calculate(struct device *dev, struct smiapp_pll_limits *limits,
-struct smiapp_pll *pll)
+static int __smiapp_pll_calculate(struct device *dev,
+ struct smiapp_pll_limits *limits,
+ struct smiapp_pll *pll, uint32_t mul,
+ uint32_t div, uint32_t lane_op_clock_ratio)
 {
uint32_t sys_div;
uint32_t best_pix_div = INT_MAX  1;
uint32_t vt_op_binning_div;
-   uint32_t lane_op_clock_ratio;
-   uint32_t mul, div;
uint32_t more_mul_min, more_mul_max;
uint32_t more_mul_factor;
uint32_t min_vt_div, max_vt_div, vt_div;
@@ -102,54 +102,6 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
unsigned int i;
int rval;
 
-   if (pll-flags  SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE)
-   lane_op_clock_ratio = pll-lanes;
-   else
-   lane_op_clock_ratio = 1;
-   dev_dbg(dev, lane_op_clock_ratio: %d\n, lane_op_clock_ratio);
-
-   dev_dbg(dev, binning: %dx%d\n, pll-binning_horizontal,
-   pll-binning_vertical);
-
-   /* CSI transfers 2 bits per clock per lane; thus times 2 */
-   pll-pll_op_clk_freq_hz = pll-link_freq * 2
-   * (pll-lanes / lane_op_clock_ratio);
-
-   /* Figure out limits for pre-pll divider based on extclk */
-   dev_dbg(dev, min / max pre_pll_clk_div: %d / %d\n,
-   limits-min_pre_pll_clk_div, limits-max_pre_pll_clk_div);
-   limits-max_pre_pll_clk_div =
-   min_t(uint16_t, limits-max_pre_pll_clk_div,
- clk_div_even(pll-ext_clk_freq_hz /
-  limits-min_pll_ip_freq_hz));
-   limits-min_pre_pll_clk_div =
-   max_t(uint16_t, limits-min_pre_pll_clk_div,
- clk_div_even_up(
- DIV_ROUND_UP(pll-ext_clk_freq_hz,
-  limits-max_pll_ip_freq_hz)));
-   dev_dbg(dev, pre-pll check: min / max pre_pll_clk_div: %d / %d\n,
-   limits-min_pre_pll_clk_div, limits-max_pre_pll_clk_div);
-
-   i = gcd(pll-pll_op_clk_freq_hz, pll-ext_clk_freq_hz);
-   mul = div_u64(pll-pll_op_clk_freq_hz, i);
-   div = pll-ext_clk_freq_hz / i;
-   dev_dbg(dev, mul %d / div %d\n, mul, div);
-
-   limits-min_pre_pll_clk_div =
-   max_t(uint16_t, limits-min_pre_pll_clk_div,
- clk_div_even_up(
- DIV_ROUND_UP(mul * pll-ext_clk_freq_hz,
-  limits-max_pll_op_freq_hz)));
-   dev_dbg(dev, pll_op check: min / max pre_pll_clk_div: %d / %d\n,
-   limits-min_pre_pll_clk_div, limits-max_pre_pll_clk_div);
-
-   if (limits-min_pre_pll_clk_div  limits-max_pre_pll_clk_div) {
-   dev_err(dev, unable to compute pre_pll divisor\n);
-   return -EINVAL;
-   }
-
-   pll-pre_pll_clk_div = limits-min_pre_pll_clk_div;
-
/*
 * Get pre_pll_clk_div so that our pll_op_clk_freq_hz won't be
 * too high.
@@ -193,8 +145,8 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
more_mul_min);
 
if (more_mul_min  more_mul_max) {
-   dev_warn(dev,
-unable to compute more_mul_min and more_mul_max\n);
+   dev_dbg(dev,
+   unable to compute more_mul_min and more_mul_max\n);
return -EINVAL;
}
 
@@ -209,7 +161,7 @@ int smiapp_pll_calculate(struct device *dev, struct 
smiapp_pll_limits *limits,
 
dev_dbg(dev, final more_mul: %d\n, i);
if (i  more_mul_max) {
-   dev_warn(dev, final more_mul is bad, max %d\n, more_mul_max);
+   dev_dbg(dev, final more_mul is bad, max %d\n, more_mul_max);

[PATCH] [media] vivi: Kill TSTAMP_* macros

2012-10-23 Thread Kirill Smelkov
Usage of TSTAMP_* macros has gone in 2010 in 730947bc (V4L/DVB: vivi:
clean up and a major overhaul) but the macros remain. Say goodbye to
them.

Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
 drivers/media/platform/vivi.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 3adea58..bfac13d 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -356,11 +356,6 @@ static void precalculate_bars(struct vivi_dev *dev)
}
 }
 
-#define TSTAMP_MIN_Y   24
-#define TSTAMP_MAX_Y   (TSTAMP_MIN_Y + 15)
-#define TSTAMP_INPUT_X 10
-#define TSTAMP_MIN_X   (54 + TSTAMP_INPUT_X)
-
 /* 'odd' is true for pixels 1, 3, 5, etc. and false for pixels 0, 2, 4, etc. */
 static void gen_twopix(struct vivi_dev *dev, u8 *buf, int colorpos, bool odd)
 {
-- 
1.8.0.rc3.331.g5b9a629

--
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 v3 5/6] Add a V4L2 driver for SI476X MFD

2012-10-23 Thread Andrey Smirnov
This commit adds a driver that exposes all the radio related
functionality of the Si476x series of chips via the V4L2 subsystem.

Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
 drivers/media/radio/Kconfig|   17 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-si476x.c | 1549 
 3 files changed, 1567 insertions(+)
 create mode 100644 drivers/media/radio/radio-si476x.c

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 8090b87..3c79d09 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -16,6 +16,23 @@ config RADIO_SI470X
bool Silicon Labs Si470x FM Radio Receiver support
depends on VIDEO_V4L2
 
+config RADIO_SI476X
+   tristate Silicon Laboratories Si476x I2C FM Radio
+   depends on I2C  VIDEO_V4L2
+   select MFD_CORE
+   select MFD_SI476X_CORE
+   select SND_SOC_SI476X
+   ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API.  Information on
+ this API and pointers to v4l2 programs may be found at
+ file:Documentation/video4linux/API.html.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-si476x.
+
 source drivers/media/radio/si470x/Kconfig
 
 config USB_MR800
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index c03ce4f..c4618e0 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o
 obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
 obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o
 obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o
+obj-$(CONFIG_RADIO_SI476X) += radio-si476x.o
 obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o
 obj-$(CONFIG_USB_DSBR) += dsbr100.o
 obj-$(CONFIG_RADIO_SI470X) += si470x/
diff --git a/drivers/media/radio/radio-si476x.c 
b/drivers/media/radio/radio-si476x.c
new file mode 100644
index 000..c8fa90f
--- /dev/null
+++ b/drivers/media/radio/radio-si476x.c
@@ -0,0 +1,1549 @@
+#include linux/module.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/slab.h
+#include linux/atomic.h
+#include linux/videodev2.h
+#include linux/mutex.h
+#include linux/debugfs.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
+#include media/v4l2-device.h
+
+
+#include linux/mfd/si476x-core.h
+
+#define FM_FREQ_RANGE_LOW   6400
+#define FM_FREQ_RANGE_HIGH 10800
+
+#define AM_FREQ_RANGE_LOW52
+#define AM_FREQ_RANGE_HIGH 3000
+
+#define PWRLINEFLTR (1  8)
+
+#define FREQ_MUL (1000 / 625)
+
+#define SI476X_PHDIV_STATUS_LINK_LOCKED(status) (0b1000  (status))
+
+#define DRIVER_NAME si476x-radio
+#define DRIVER_CARD SI476x AM/FM Receiver
+
+enum si476x_freq_bands {
+   SI476X_BAND_FM,
+   SI476X_BAND_AM,
+};
+
+static const struct v4l2_frequency_band si476x_bands[] = {
+   [SI476X_BAND_FM] = {
+   .type   = V4L2_TUNER_RADIO,
+   .index  = SI476X_BAND_FM,
+   .capability = V4L2_TUNER_CAP_LOW
+   | V4L2_TUNER_CAP_STEREO
+   | V4L2_TUNER_CAP_RDS
+   | V4L2_TUNER_CAP_RDS_BLOCK_IO
+   | V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   =  64 * FREQ_MUL,
+   .rangehigh  = 108 * FREQ_MUL,
+   .modulation = V4L2_BAND_MODULATION_FM,
+   },
+   [SI476X_BAND_AM] = {
+   .type   = V4L2_TUNER_RADIO,
+   .index  = SI476X_BAND_AM,
+   .capability = V4L2_TUNER_CAP_LOW | 
V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   = 0.52 * FREQ_MUL,
+   .rangehigh  = 30 * FREQ_MUL,
+   .modulation = V4L2_BAND_MODULATION_AM,
+   },
+};
+
+static inline bool si476x_radio_freq_is_inside_of_the_band(u32 freq, int band)
+{
+   return freq = si476x_bands[band].rangelow 
+   freq = si476x_bands[band].rangehigh;
+}
+
+static inline bool si476x_radio_range_is_inside_of_the_band(u32 low, u32 high, 
int band)
+{
+   return low  = si476x_bands[band].rangelow 
+   high = si476x_bands[band].rangehigh;
+}
+
+#define PRIVATE_CTL_IDX(x) (x - V4L2_CID_PRIVATE_BASE)
+
+static int si476x_radio_s_ctrl(struct v4l2_ctrl *ctrl);
+static int si476x_radio_g_volatile_ctrl(struct v4l2_ctrl *ctrl);
+
+static const char * const deemphasis[] = {
+   75 us,
+   50 us,
+};
+
+enum phase_diversity_modes_idx {
+   SI476X_IDX_PHDIV_DISABLED,
+   SI476X_IDX_PHDIV_PRIMARY_COMBINING,
+   SI476X_IDX_PHDIV_PRIMARY_ANTENNA,
+   SI476X_IDX_PHDIV_SECONDARY_ANTENNA,
+   SI476X_IDX_PHDIV_SECONDARY_COMBINING,
+};
+
+static const char * const 

[PATCH v3 0/6] Driver for Si476x series of chips

2012-10-23 Thread Andrey Smirnov
This is a third version of the patchset originaly posted here:
https://lkml.org/lkml/2012/9/13/590

Second version of the patch was posted here:
https://lkml.org/lkml/2012/10/5/598

To save everyone's time I'll repost the original description of it:

This patchset contains a driver for a Silicon Laboratories 476x series
of radio tuners. The driver itself is implemented as an MFD devices
comprised of three parts: 
 1. Core device that provides all the other devices with basic
functionality and locking scheme.
 2. Radio device that translates between V4L2 subsystem requests into
Core device commands.
 3. Codec device that does similar to the earlier described task, but
for ALSA SoC subsystem.

v3 of this driver has following changes:
 - All custom ioctls were moved to be V4L2 controls or debugfs files
 - Chip properties handling was moved to regmap API, so this should
   allow for cleaner code, and hopefully more consistent behaviour of
   the driver during switch between AM/FM(wich involevs power-cycling
   of the chip)

I was hoping to not touch the code of the codec driver, since Mark has
already appplied the previous version, but because of the last item I
had to.

Unfotunately, since my ARM setup runs only 3.1 kernel, I was only able
to test this driver on a standalone USB-connected board that has a
dedicated Cortex M3 working as a transparent USB to I2C bridge which
was connected to a off-the-shelf x86-64 laptop running Ubuntu with
custom kernel compile form git.linuxtv.org/media_tree.git. Which means
that I was unable to test the change in the codec code, except for the
fact the it compiles.


Here is v4l2-compliance output for one of the tuners(as per Hans'
request):

sudo v4l2-compliance -r /dev/radio0
is radio
Driver Info:
Driver name   : si476x-radio0
Card type : SI476x AM/FM Receiver
Bus info  : platform:si476x-radio0
Driver version: 3.6.0
Capabilities  : 0x81050500
RDS Capture
Tuner
Radio
Read/Write
Device Capabilities
Device Caps   : 0x01050500
RDS Capture
Tuner
Radio
Read/Write

Compliance test for device /dev/radio0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second radio open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G_CHIP_IDENT: OK
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER: OK
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_S_HW_FREQ_SEEK: OK
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 1

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Control ioctls:
test VIDIOC_QUERYCTRL/MENU: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 2 Private Controls: 8

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_PRESETS: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK (Not Supported)
test VIDIOC_TRY_FMT: OK (Not Supported)
test VIDIOC_S_FMT: OK (Not Supported)
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)

Total: 38, Succeeded: 38, Failed: 0, Warnings: 0

Andrey Smirnov (6):
  Add header files and Kbuild plumbing for SI476x MFD core
  Add the main bulk of core driver for SI476x code
  Add commands abstraction layer for SI476X MFD
  Add chip properties handling code for SI476X MFD
  Add a V4L2 driver for SI476X MFD
  Add a codec driver for SI476X MFD

 drivers/media/radio/Kconfig|   17 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-si476x.c | 1549 
 

[PATCH v3 6/6] Add a codec driver for SI476X MFD

2012-10-23 Thread Andrey Smirnov
This commit add a sound codec driver for Silicon Laboratories 476x
series of AM/FM radio chips.

Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
 sound/soc/codecs/Kconfig  |4 +
 sound/soc/codecs/Makefile |2 +
 sound/soc/codecs/si476x.c |  259 +
 3 files changed, 265 insertions(+)
 create mode 100644 sound/soc/codecs/si476x.c

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 9f8e859..37b2911 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -53,6 +53,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_PCM3008
select SND_SOC_RT5631 if I2C
select SND_SOC_SGTL5000 if I2C
+   select SND_SOC_SI476X if MFD_SI476X_CORE
select SND_SOC_SN95031 if INTEL_SCU_IPC
select SND_SOC_SPDIF
select SND_SOC_SSM2602 if SND_SOC_I2C_AND_SPI
@@ -272,6 +273,9 @@ config SND_SOC_RT5631
 config SND_SOC_SGTL5000
tristate
 
+config SND_SOC_SI476X
+   tristate
+
 config SND_SOC_SIGMADSP
tristate
select CRC32
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 34148bb..d9ed4e4 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -44,6 +44,7 @@ snd-soc-sgtl5000-objs := sgtl5000.o
 snd-soc-alc5623-objs := alc5623.o
 snd-soc-alc5632-objs := alc5632.o
 snd-soc-sigmadsp-objs := sigmadsp.o
+snd-soc-si476x-objs := si476x.o
 snd-soc-sn95031-objs := sn95031.o
 snd-soc-spdif-tx-objs := spdif_transciever.o
 snd-soc-spdif-rx-objs := spdif_receiver.o
@@ -161,6 +162,7 @@ obj-$(CONFIG_SND_SOC_PCM3008)   += snd-soc-pcm3008.o
 obj-$(CONFIG_SND_SOC_RT5631)   += snd-soc-rt5631.o
 obj-$(CONFIG_SND_SOC_SGTL5000)  += snd-soc-sgtl5000.o
 obj-$(CONFIG_SND_SOC_SIGMADSP) += snd-soc-sigmadsp.o
+obj-$(CONFIG_SND_SOC_SI476X)   += snd-soc-si476x.o
 obj-$(CONFIG_SND_SOC_SN95031)  +=snd-soc-sn95031.o
 obj-$(CONFIG_SND_SOC_SPDIF)+= snd-soc-spdif-rx.o snd-soc-spdif-tx.o
 obj-$(CONFIG_SND_SOC_SSM2602)  += snd-soc-ssm2602.o
diff --git a/sound/soc/codecs/si476x.c b/sound/soc/codecs/si476x.c
new file mode 100644
index 000..1f34913
--- /dev/null
+++ b/sound/soc/codecs/si476x.c
@@ -0,0 +1,259 @@
+#include linux/module.h
+#include linux/slab.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/initval.h
+
+#include linux/i2c.h
+
+#include linux/mfd/si476x-core.h
+
+enum si476x_audio_registers {
+   SI476X_DIGITAL_IO_OUTPUT_FORMAT = 0x0203,
+   SI476X_DIGITAL_IO_OUTPUT_SAMPLE_RATE= 0x0202,
+};
+
+enum si476x_digital_io_output_format {
+   SI476X_DIGITAL_IO_SLOT_SIZE_SHIFT   = 11,
+   SI476X_DIGITAL_IO_SAMPLE_SIZE_SHIFT = 8,
+};
+
+#define SI476X_DIGITAL_IO_OUTPUT_WIDTH_MASK((0b111  
SI476X_DIGITAL_IO_SLOT_SIZE_SHIFT) | \
+ (0b111  
SI476X_DIGITAL_IO_SAMPLE_SIZE_SHIFT))
+#define SI476X_DIGITAL_IO_OUTPUT_FORMAT_MASK   (0b110)
+
+enum si476x_daudio_formats {
+   SI476X_DAUDIO_MODE_I2S  = (0x0  1),
+   SI476X_DAUDIO_MODE_DSP_A= (0x6  1),
+   SI476X_DAUDIO_MODE_DSP_B= (0x7  1),
+   SI476X_DAUDIO_MODE_LEFT_J   = (0x8  1),
+   SI476X_DAUDIO_MODE_RIGHT_J  = (0x9  1),
+
+   SI476X_DAUDIO_MODE_IB   = (1  5),
+   SI476X_DAUDIO_MODE_IF   = (1  6),
+};
+
+enum si476x_pcm_format {
+   SI476X_PCM_FORMAT_S8= 2,
+   SI476X_PCM_FORMAT_S16_LE= 4,
+   SI476X_PCM_FORMAT_S20_3LE   = 5,
+   SI476X_PCM_FORMAT_S24_LE= 6,
+};
+
+static unsigned int si476x_codec_read(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+   int err;
+   unsigned int val;
+   struct si476x_core *core = codec-control_data;
+
+   si476x_core_lock(core);
+   err = regmap_read(core-regmap, reg, val);
+   si476x_core_unlock(core);
+
+   if (err  0)
+   return err;
+
+   return val;
+}
+
+static int si476x_codec_write(struct snd_soc_codec *codec,
+ unsigned int reg, unsigned int val)
+{
+   int err;
+   struct si476x_core *core = codec-control_data;
+
+   si476x_core_lock(core);
+   err = regmap_write(core-regmap, reg, val);
+   si476x_core_unlock(core);
+
+   return err;
+}
+
+static int si476x_codec_set_dai_fmt(struct snd_soc_dai *codec_dai,
+   unsigned int fmt)
+{
+   int err;
+   u16 format = 0;
+
+   if ((fmt  SND_SOC_DAIFMT_MASTER_MASK) != SND_SOC_DAIFMT_CBS_CFS)
+   return -EINVAL;
+
+   switch (fmt  SND_SOC_DAIFMT_FORMAT_MASK) {
+   case SND_SOC_DAIFMT_DSP_A:
+   format |= SI476X_DAUDIO_MODE_DSP_A;
+   break;
+   case SND_SOC_DAIFMT_DSP_B:
+   format |= SI476X_DAUDIO_MODE_DSP_B;
+   break;
+   case SND_SOC_DAIFMT_I2S:
+   format |= SI476X_DAUDIO_MODE_I2S;
+   

[PATCH v3 1/6] Add header files and Kbuild plumbing for SI476x MFD core

2012-10-23 Thread Andrey Smirnov
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.

The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.

Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
 drivers/mfd/Kconfig |   14 +
 drivers/mfd/Makefile|3 +
 include/linux/mfd/si476x-core.h |  539 +++
 include/media/si476x.h  |  427 +++
 4 files changed, 983 insertions(+)
 create mode 100644 include/linux/mfd/si476x-core.h
 create mode 100644 include/media/si476x.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..3fab06d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -895,6 +895,20 @@ config MFD_WL1273_CORE
  driver connects the radio-wl1273 V4L2 module and the wl1273
  audio codec.
 
+config MFD_SI476X_CORE
+   tristate Support for Silicon Laboratories 4761/64/68 AM/FM radio.
+   depends on I2C
+   select MFD_CORE
+   default n
+   help
+ This is the core driver for the SI476x series of AM/FM radio. This MFD
+ driver connects the radio-si476x V4L2 module and the si476x
+ audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
+
 config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..942257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583)   += rc5t583.o rc5t583-irq.o
 obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
 obj-$(CONFIG_MFD_ANATOP)   += anatop-mfd.o
 obj-$(CONFIG_MFD_LM3533)   += lm3533-core.o lm3533-ctrlbank.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE)  += si476x-core.o
diff --git a/include/linux/mfd/si476x-core.h b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..08bc5dd
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,539 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include linux/kfifo.h
+#include linux/atomic.h
+#include linux/i2c.h
+#include linux/regmap.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/videodev2.h
+#include linux/regulator/consumer.h
+
+#include media/si476x.h
+
+#ifdef DEBUG
+#define DBG_BUFFER(device, header, buffer, bcount) \
+   do {\
+   dev_info((device), header); \
+   print_hex_dump_bytes(,\
+DUMP_PREFIX_OFFSET,\
+buffer, bcount);   \
+   } while (0)
+#else
+#define DBG_BUFFER(device, header, buffer, bcount) \
+   do {} while (0)
+#endif
+
+/*  si476x-i2c.c --- */
+
+enum si476x_freq_supported_chips {
+   SI476X_CHIP_SI4761 = 1,
+   SI476X_CHIP_SI4764,
+   SI476X_CHIP_SI4768,
+};
+
+enum si476x_mfd_cells {
+   SI476X_RADIO_CELL = 0,
+   SI476X_CODEC_CELL,
+   SI476X_MFD_CELLS,
+};
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the power regualtors are
+ * turned on, reset line pulled high, IRQ line is enabled(polling is
+ * active for polling use scenario) and device is turned on with
+ * POWER_UP command. The device is ready to be used.
+ * @SI476X_POWER_INCONSISTENT: This state indicates that previous
+ * power down was inconsistent, meaning some of the regulators were
+ * not turned down and thus use of the device, without power-cycling
+ * is impossible.
+ */
+enum 

[PATCH v3 3/6] Add commands abstraction layer for SI476X MFD

2012-10-23 Thread Andrey Smirnov
This patch adds all the functions used for exchanging commands with
the chip.

Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
 drivers/mfd/si476x-cmd.c | 1546 ++
 1 file changed, 1546 insertions(+)
 create mode 100644 drivers/mfd/si476x-cmd.c

diff --git a/drivers/mfd/si476x-cmd.c b/drivers/mfd/si476x-cmd.c
new file mode 100644
index 000..e2989bc
--- /dev/null
+++ b/drivers/mfd/si476x-cmd.c
@@ -0,0 +1,1546 @@
+/*
+ * include/media/si476x-cmd.c -- Subroutines implementing command
+ * protocol of si476x series of chips
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+#include linux/module.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/atomic.h
+#include linux/i2c.h
+#include linux/device.h
+#include linux/gpio.h
+#include linux/videodev2.h
+
+#include media/si476x.h
+#include linux/mfd/si476x-core.h
+
+#define msb(x)  ((u8)((u16) x  8))
+#define lsb(x)  ((u8)((u16) x   0x00FF))
+
+
+
+#define CMD_POWER_UP   0x01
+#define CMD_POWER_UP_A10_NRESP 1
+#define CMD_POWER_UP_A10_NARGS 5
+
+#define CMD_POWER_UP_A20_NRESP 1
+#define CMD_POWER_UP_A20_NARGS 5
+
+#define POWER_UP_DELAY_MS  110
+
+#define CMD_POWER_DOWN 0x11
+#define CMD_POWER_DOWN_A10_NRESP   1
+
+#define CMD_POWER_DOWN_A20_NRESP   1
+#define CMD_POWER_DOWN_A20_NARGS   1
+
+#define CMD_FUNC_INFO  0x12
+#define CMD_FUNC_INFO_NRESP7
+
+#define CMD_SET_PROPERTY   0x13
+#define CMD_SET_PROPERTY_NARGS 5
+#define CMD_SET_PROPERTY_NRESP 1
+
+#define CMD_GET_PROPERTY   0x14
+#define CMD_GET_PROPERTY_NARGS 3
+#define CMD_GET_PROPERTY_NRESP 4
+
+#define CMD_AGC_STATUS 0x17
+#define CMD_AGC_STATUS_NRESP_A10   2
+#define CMD_AGC_STATUS_NRESP_A206
+
+#define PIN_CFG_BYTE(x) (0x7F  (x))
+#define CMD_DIG_AUDIO_PIN_CFG  0x18
+#define CMD_DIG_AUDIO_PIN_CFG_NARGS4
+#define CMD_DIG_AUDIO_PIN_CFG_NRESP5
+
+#define CMD_ZIF_PIN_CFG0x19
+#define CMD_ZIF_PIN_CFG_NARGS  4
+#define CMD_ZIF_PIN_CFG_NRESP  5
+
+#define CMD_IC_LINK_GPO_CTL_PIN_CFG0x1A
+#define CMD_IC_LINK_GPO_CTL_PIN_CFG_NARGS  4
+#define CMD_IC_LINK_GPO_CTL_PIN_CFG_NRESP  5
+
+#define CMD_ANA_AUDIO_PIN_CFG  0x1B
+#define CMD_ANA_AUDIO_PIN_CFG_NARGS1
+#define CMD_ANA_AUDIO_PIN_CFG_NRESP2
+
+#define CMD_INTB_PIN_CFG   0x1C
+#define CMD_INTB_PIN_CFG_NARGS 2
+#define CMD_INTB_PIN_CFG_A10_NRESP 6
+#define CMD_INTB_PIN_CFG_A20_NRESP 3
+
+#define CMD_FM_TUNE_FREQ   0x30
+#define CMD_FM_TUNE_FREQ_A10_NARGS 5
+#define CMD_FM_TUNE_FREQ_A20_NARGS 3
+#define CMD_FM_TUNE_FREQ_NRESP 1
+
+#define CMD_FM_RSQ_STATUS  0x32
+
+#define CMD_FM_RSQ_STATUS_A10_NARGS1
+#define CMD_FM_RSQ_STATUS_A10_NRESP17
+#define CMD_FM_RSQ_STATUS_A30_NARGS1
+#define CMD_FM_RSQ_STATUS_A30_NRESP23
+
+
+#define CMD_FM_SEEK_START  0x31
+#define CMD_FM_SEEK_START_NARGS1
+#define CMD_FM_SEEK_START_NRESP1
+
+#define CMD_FM_RDS_STATUS  0x36
+#define CMD_FM_RDS_STATUS_NARGS1
+#define CMD_FM_RDS_STATUS_NRESP16
+
+#define CMD_FM_RDS_BLOCKCOUNT  0x37
+#define CMD_FM_RDS_BLOCKCOUNT_NARGS1
+#define CMD_FM_RDS_BLOCKCOUNT_NRESP8
+
+#define CMD_FM_PHASE_DIVERSITY 0x38
+#define CMD_FM_PHASE_DIVERSITY_NARGS   1
+#define CMD_FM_PHASE_DIVERSITY_NRESP   1
+
+#define CMD_FM_PHASE_DIV_STATUS0x39
+#define CMD_FM_PHASE_DIV_STATUS_NRESP  2
+
+#define CMD_AM_TUNE_FREQ   0x40
+#define CMD_AM_TUNE_FREQ_NARGS 3
+#define CMD_AM_TUNE_FREQ_NRESP 1
+
+#define CMD_AM_RSQ_STATUS  0x42
+#define 

[PATCH v3 2/6] Add the main bulk of core driver for SI476x code

2012-10-23 Thread Andrey Smirnov
This patch adds main part(out of three) of the I2C driver for the
core of MFD device.

Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
 drivers/mfd/si476x-i2c.c |  966 ++
 1 file changed, 966 insertions(+)
 create mode 100644 drivers/mfd/si476x-i2c.c

diff --git a/drivers/mfd/si476x-i2c.c b/drivers/mfd/si476x-i2c.c
new file mode 100644
index 000..6d581bd
--- /dev/null
+++ b/drivers/mfd/si476x-i2c.c
@@ -0,0 +1,966 @@
+/*
+ * include/media/si476x-i2c.c -- Core device driver for si476x MFD
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+#include linux/module.h
+
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/regulator/consumer.h
+#include linux/i2c.h
+#include linux/err.h
+
+#include linux/mfd/si476x-core.h
+
+/* Command Timeouts */
+#define DEFAULT_TIMEOUT10
+#define TIMEOUT_TUNE   70
+#define TIMEOUT_POWER_UP   33
+
+#define MAX_IO_ERRORS 10
+
+#define SI476X_DRIVER_RDS_FIFO_DEPTH   128
+
+#define SI476X_STATUS_POLL_US 0
+
+/**
+ * si476x_core_config_pinmux() - pin function configuration function
+ *
+ * @core: Core device structure
+ *
+ * Configure the functions of the pins of the radio chip.
+ *
+ * The function returns zero in case of succes or negative error code
+ * otherwise.
+ */
+static int si476x_core_config_pinmux(struct si476x_core *core)
+{
+   int err;
+   dev_dbg(core-client-dev, Configuring pinmux\n);
+   err = si476x_core_cmd_dig_audio_pin_cfg(core,
+   core-pinmux.dclk,
+   core-pinmux.dfs,
+   core-pinmux.dout,
+   core-pinmux.xout);
+   if (err  0) {
+   dev_err(core-client-dev,
+   Failed to configure digital audio pins(err = %d)\n,
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_zif_pin_cfg(core,
+ core-pinmux.iqclk,
+ core-pinmux.iqfs,
+ core-pinmux.iout,
+ core-pinmux.qout);
+   if (err  0) {
+   dev_err(core-client-dev,
+   Failed to configure ZIF pins(err = %d)\n,
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_ic_link_gpo_ctl_pin_cfg(core,
+ core-pinmux.icin,
+ core-pinmux.icip,
+ core-pinmux.icon,
+ core-pinmux.icop);
+   if (err  0) {
+   dev_err(core-client-dev,
+   Failed to configure IC-Link/GPO pins(err = %d)\n,
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_ana_audio_pin_cfg(core,
+   core-pinmux.lrout);
+   if (err  0) {
+   dev_err(core-client-dev,
+   Failed to configure analog audio pins(err = %d)\n,
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_intb_pin_cfg(core,
+  core-pinmux.intb,
+  core-pinmux.a1);
+   if (err  0) {
+   dev_err(core-client-dev,
+   Failed to configure interrupt pins(err = %d)\n,
+   err);
+   return err;
+   }
+
+   return 0;
+}
+
+static inline void si476x_core_schedule_polling_work(struct si476x_core *core)
+{
+   schedule_delayed_work(core-status_monitor,
+   usecs_to_jiffies(atomic_read(core-polling_interval)));
+}
+
+/**
+ * si476x_core_start() - early chip startup function
+ * @core: Core device structure
+ * @soft: When set, this flag forces soft startup, where soft
+ * power down is the one done by sending appropriate command instead
+ * of using reset pin of the tuner
+ *
+ * Perform required startup sequence to correctly power
+ * up the 

[PATCH v3 4/6] Add chip properties handling code for SI476X MFD

2012-10-23 Thread Andrey Smirnov
This patch adds code related to manipulation of the properties of
SI476X chips.

Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
 drivers/mfd/si476x-prop.c |  257 +
 1 file changed, 257 insertions(+)
 create mode 100644 drivers/mfd/si476x-prop.c

diff --git a/drivers/mfd/si476x-prop.c b/drivers/mfd/si476x-prop.c
new file mode 100644
index 000..3811eec
--- /dev/null
+++ b/drivers/mfd/si476x-prop.c
@@ -0,0 +1,257 @@
+/*
+ * include/media/si476x-prop.c -- Subroutines to manipulate with
+ * properties of si476x chips
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#include linux/module.h
+
+#include media/si476x.h
+#include linux/mfd/si476x-core.h
+
+struct si476x_property_range {
+   u16 low, high;
+};
+
+
+
+static bool si476x_core_element_is_in_array(u16 element, const u16 array[], 
size_t size)
+{
+   int i;
+
+   for (i = 0; i  size; i++)
+   if (element == array[i])
+   return true;
+
+   return false;
+}
+
+static bool si476x_core_element_is_in_range(u16 element,
+   const struct si476x_property_range 
range[],
+   size_t size)
+{
+   int i;
+
+   for (i = 0; i  size; i++)
+   if (element = range[i].high  element = range[i].low)
+   return true;
+
+   return false;
+}
+
+static bool si476x_core_is_valid_property_a10(struct si476x_core *core,
+ u16 property)
+{
+   static const u16 valid_properties[] = {
+   0x,
+   0x0500, 0x0501,
+   0x0600,
+   0x0709, 0x070C, 0x070D, 0x70E, 0x710,
+   0x0718,
+   0x1207, 0x1208,
+   0x2007,
+   0x2300,
+   };
+
+   static const struct si476x_property_range valid_ranges[] = {
+   { 0x0200, 0x0203 },
+   { 0x0300, 0x0303 },
+   { 0x0400, 0x0404 },
+   { 0x0700, 0x0707 },
+   { 0x1100, 0x1102 },
+   { 0x1200, 0x1204 },
+   { 0x1300, 0x1306 },
+   { 0x2000, 0x2005 },
+   { 0x2100, 0x2104 },
+   { 0x2106, 0x2106 },
+   { 0x2200, 0x220E },
+   { 0x3100, 0x3104 },
+   { 0x3207, 0x320F },
+   { 0x3300, 0x3304 },
+   { 0x3500, 0x3517 },
+   { 0x3600, 0x3617 },
+   { 0x3700, 0x3717 },
+   { 0x4000, 0x4003 },
+   };
+
+   return  si476x_core_element_is_in_range(property, valid_ranges,
+   ARRAY_SIZE(valid_ranges)) ||
+   si476x_core_element_is_in_array(property, valid_properties,
+   ARRAY_SIZE(valid_properties));
+}
+
+static bool si476x_core_is_valid_property_a20(struct si476x_core *core,
+ u16 property)
+{
+   static const u16 valid_properties[] = {
+   0x071B,
+   0x1006,
+   0x2210,
+   0x3401,
+   };
+
+   static const struct si476x_property_range valid_ranges[] = {
+   { 0x2215, 0x2219 },
+   };
+
+   return  si476x_core_is_valid_property_a10(core, property) ||
+   si476x_core_element_is_in_range(property, valid_ranges,
+   ARRAY_SIZE(valid_ranges))  ||
+   si476x_core_element_is_in_array(property, valid_properties,
+   ARRAY_SIZE(valid_properties));
+}
+
+static bool si476x_core_is_valid_property_a30(struct si476x_core *core,
+ u16 property)
+{
+   static const u16 valid_properties[] = {
+   0x071C, 0x071D,
+   0x1007, 0x1008,
+   0x220F, 0x2214,
+   0x2301,
+   0x3105, 0x3106,
+   0x3402,
+   };
+
+   static const struct si476x_property_range valid_ranges[] = {
+   { 0x0405, 0x0411 },
+   { 0x2008, 0x200B },
+   { 0x2220, 0x2223 },
+   { 0x3100, 0x3106 },
+   };
+
+   return  si476x_core_is_valid_property_a20(core, property) ||
+   si476x_core_element_is_in_range(property, valid_ranges,
+  

Re: [PATCH v3 6/6] Add a codec driver for SI476X MFD

2012-10-23 Thread Mark Brown
On Tue, Oct 23, 2012 at 11:44:32AM -0700, Andrey Smirnov wrote:
 This commit add a sound codec driver for Silicon Laboratories 476x
 series of AM/FM radio chips.

I already merged a driver for this.  If there are any changes you should
send incremental updates rather than a full new driver.


signature.asc
Description: Digital signature


[PATCH 0/23] media: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
Hello everyone,

This is a large patchset that replaces struct memcpy with struct assignment,
whenever possible at drivers/media.

The patches are hand applied and every change has been thoroughly reviewed.
However, to avoid regressions and angry users we'd like to have Acks
from maintainers.

A simplified version of the semantic match that finds
this problem is as follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

If you're thinking this change is very minor and doesn't worh the pain,
you might change your opinion reading this report from Dan Carpenter:

http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/49553

The report clearly shows how copy-paste programming paradigm, combined with
lack of memcpy type-safety can lead to very strange code.

Not to mention, using struct assignment instead of memcpy
is by far more readable.

Comments, feedback and flames are welcome. Thanks!

Peter Senna Tschudin, Ezequiel Garcia (23):
 wl128x: Replace memcpy with struct assignment
 radio-wl1273: Replace memcpy with struct assignment
 dvb-frontends: Replace memcpy with struct assignment
 dvb-core: Replace memcpy with struct assignment
 bttv: Replace memcpy with struct assignment
 cx18: Replace memcpy with struct assignment
 cx23885: Replace memcpy with struct assignment
 cx88: Replace memcpy with struct assignment
 ivtv: Replace memcpy with struct assignment
 tuners/tda18271: Replace memcpy with struct assignment
 tuners/xc2028: Replace memcpy with struct assignment
 tuners/xc4000: Replace memcpy with struct assignment
 au0828: Replace memcpy with struct assignment
 dvb-usb/friio-fe: Replace memcpy with struct assignment
 zr36067: Replace memcpy with struct assignment
 cx25840: Replace memcpy with struct assignment
 hdpvr: Replace memcpy with struct assignment
 pvrusb2: Replace memcpy with struct assignment
 pwc: Replace memcpy with struct assignment
 sn9c102: Replace memcpy with struct assignment
 usbvision: Replace memcpy with struct assignment
 cx231xx: Replace memcpy with struct assignment
 uvc: Replace memcpy with struct assignment

 drivers/media/dvb-core/dvb_frontend.c|2 +-
 drivers/media/dvb-frontends/cx24116.c|2 +-
 drivers/media/dvb-frontends/drxd_hard.c  |5 ++---
 drivers/media/dvb-frontends/stv0299.c|2 +-
 drivers/media/i2c/cx25840/cx25840-ir.c   |6 ++
 drivers/media/pci/bt8xx/bttv-i2c.c   |3 +--
 drivers/media/pci/cx18/cx18-i2c.c|6 ++
 drivers/media/pci/cx23885/cx23885-video.c|3 +--
 drivers/media/pci/cx23885/cx23888-ir.c   |6 ++
 drivers/media/pci/cx88/cx88-cards.c  |2 +-
 drivers/media/pci/cx88/cx88-i2c.c|3 +--
 drivers/media/pci/cx88/cx88-vp3054-i2c.c |3 +--
 drivers/media/pci/ivtv/ivtv-i2c.c|   12 
 drivers/media/pci/zoran/zoran_card.c |3 +--
 drivers/media/radio/radio-wl1273.c   |3 +--
 drivers/media/radio/wl128x/fmdrv_common.c|3 +--
 drivers/media/tuners/tda18271-maps.c |6 ++
 drivers/media/tuners/tuner-xc2028.c  |2 +-
 drivers/media/tuners/xc4000.c|2 +-
 drivers/media/usb/au0828/au0828-cards.c  |2 +-
 drivers/media/usb/au0828/au0828-i2c.c|9 +++--
 drivers/media/usb/cx231xx/cx231xx-cards.c|2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c|3 +--
 drivers/media/usb/dvb-usb/friio-fe.c |5 ++---
 drivers/media/usb/hdpvr/hdpvr-i2c.c  |3 +--
 drivers/media/usb/pvrusb2/pvrusb2-encoder.c  |3 +--
 drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c |4 ++--
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c |2 +-
 drivers/media/usb/pwc/pwc-if.c   |2 +-
 drivers/media/usb/sn9c102/sn9c102_core.c |4 ++--
 drivers/media/usb/usbvision/usbvision-i2c.c  |3 +--
 drivers/media/usb/uvc/uvc_v4l2.c |6 +++---
 32 files changed, 47 insertions(+), 75 deletions(-)


Ezequiel
--
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 01/23] uvc: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/uvc/uvc_v4l2.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index f00db30..4fc8737 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming *stream,
goto done;
}
 
-   memcpy(stream-ctrl, probe, sizeof probe);
+   stream-ctrl = probe;
stream-cur_format = format;
stream-cur_frame = frame;
 
@@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming 
*stream,
return -EBUSY;
}
 
-   memcpy(probe, stream-ctrl, sizeof probe);
+   probe = stream-ctrl;
probe.dwFrameInterval =
uvc_try_frame_interval(stream-cur_frame, interval);
 
@@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming 
*stream,
return ret;
}
 
-   memcpy(stream-ctrl, probe, sizeof probe);
+   stream-ctrl = probe;
mutex_unlock(stream-mutex);
 
/* Return the actual frame period. */
-- 
1.7.4.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


[PATCH 21/23] dvb-frontends: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/dvb-frontends/cx24116.c   |2 +-
 drivers/media/dvb-frontends/drxd_hard.c |5 ++---
 drivers/media/dvb-frontends/stv0299.c   |2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index b488791..2916d7c 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -819,7 +819,7 @@ static int cx24116_read_ucblocks(struct dvb_frontend *fe, 
u32 *ucblocks)
 static void cx24116_clone_params(struct dvb_frontend *fe)
 {
struct cx24116_state *state = fe-demodulator_priv;
-   memcpy(state-dcur, state-dnxt, sizeof(state-dcur));
+   state-dcur = state-dnxt;
 }
 
 /* Wait for LNB */
diff --git a/drivers/media/dvb-frontends/drxd_hard.c 
b/drivers/media/dvb-frontends/drxd_hard.c
index 6d98537..dca1752 100644
--- a/drivers/media/dvb-frontends/drxd_hard.c
+++ b/drivers/media/dvb-frontends/drxd_hard.c
@@ -2963,7 +2963,7 @@ struct dvb_frontend *drxd_attach(const struct drxd_config 
*config,
return NULL;
memset(state, 0, sizeof(*state));
 
-   memcpy(state-ops, drxd_ops, sizeof(struct dvb_frontend_ops));
+   state-ops = drxd_ops;
state-dev = dev;
state-config = *config;
state-i2c = i2c;
@@ -2974,8 +2974,7 @@ struct dvb_frontend *drxd_attach(const struct drxd_config 
*config,
if (Read16(state, 0, 0, 0)  0)
goto error;
 
-   memcpy(state-frontend.ops, drxd_ops,
-  sizeof(struct dvb_frontend_ops));
+   state-frontend.ops = drxd_ops;
state-frontend.demodulator_priv = state;
ConfigureMPEGOutput(state, 0);
return state-frontend;
diff --git a/drivers/media/dvb-frontends/stv0299.c 
b/drivers/media/dvb-frontends/stv0299.c
index 92a6075..b57ecf4 100644
--- a/drivers/media/dvb-frontends/stv0299.c
+++ b/drivers/media/dvb-frontends/stv0299.c
@@ -420,7 +420,7 @@ static int stv0299_send_legacy_dish_cmd (struct 
dvb_frontend* fe, unsigned long
 
do_gettimeofday (nexttime);
if (debug_legacy_dish_switch)
-   memcpy (tv[0], nexttime, sizeof (struct timeval));
+   tv[0] = nexttime;
stv0299_writeregI (state, 0x0c, reg0x0c | 0x50); /* set LNB to 18V */
 
dvb_frontend_sleep_until(nexttime, 32000);
-- 
1.7.4.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


[PATCH 23/23] wl128x: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/radio/wl128x/fmdrv_common.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/radio/wl128x/fmdrv_common.c 
b/drivers/media/radio/wl128x/fmdrv_common.c
index bf867a6..902f19d 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -1563,8 +1563,7 @@ int fmc_prepare(struct fmdev *fmdev)
fmdev-irq_info.mask = FM_MAL_EVENT;
 
/* Region info */
-   memcpy(fmdev-rx.region, region_configs[default_radio_region],
-   sizeof(struct region_info));
+   fmdev-rx.region = region_configs[default_radio_region];
 
fmdev-rx.mute_mode = FM_MUTE_OFF;
fmdev-rx.rf_depend_mute = FM_RX_RF_DEPENDENT_MUTE_OFF;
-- 
1.7.4.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


[PATCH 22/23] radio-wl1273: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/radio/radio-wl1273.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 9b0c9fa..6e55e93 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -2084,8 +2084,7 @@ static int __devinit wl1273_fm_radio_probe(struct 
platform_device *pdev)
}
 
/* V4L2 configuration */
-   memcpy(radio-videodev, wl1273_viddev_template,
-  sizeof(wl1273_viddev_template));
+   radio-videodev = wl1273_viddev_template;
 
radio-videodev.v4l2_dev = radio-v4l2dev;
 
-- 
1.7.4.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


[PATCH 14/23] tuners/tda18271: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/tuners/tda18271-maps.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/tuners/tda18271-maps.c 
b/drivers/media/tuners/tda18271-maps.c
index fb881c6..b62e925 100644
--- a/drivers/media/tuners/tda18271-maps.c
+++ b/drivers/media/tuners/tda18271-maps.c
@@ -1290,13 +1290,11 @@ int tda18271_assign_map_layout(struct dvb_frontend *fe)
switch (priv-id) {
case TDA18271HDC1:
priv-maps = tda18271c1_map_layout;
-   memcpy(priv-std, tda18271c1_std_map,
-  sizeof(struct tda18271_std_map));
+   priv-std = tda18271c1_std_map;
break;
case TDA18271HDC2:
priv-maps = tda18271c2_map_layout;
-   memcpy(priv-std, tda18271c2_std_map,
-  sizeof(struct tda18271_std_map));
+   priv-std = tda18271c2_std_map;
break;
default:
ret = -EINVAL;
-- 
1.7.4.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


[PATCH 17/23] cx23885: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/pci/cx23885/cx23885-video.c |3 +--
 drivers/media/pci/cx23885/cx23888-ir.c|6 ++
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-video.c 
b/drivers/media/pci/cx23885/cx23885-video.c
index 1a21926..62be144 100644
--- a/drivers/media/pci/cx23885/cx23885-video.c
+++ b/drivers/media/pci/cx23885/cx23885-video.c
@@ -1818,8 +1818,7 @@ int cx23885_video_register(struct cx23885_dev *dev)
spin_lock_init(dev-slock);
 
/* Initialize VBI template */
-   memcpy(cx23885_vbi_template, cx23885_video_template,
-   sizeof(cx23885_vbi_template));
+   cx23885_vbi_template = cx23885_video_template;
strcpy(cx23885_vbi_template.name, cx23885-vbi);
 
dev-tvnorm = cx23885_video_template.current_norm;
diff --git a/drivers/media/pci/cx23885/cx23888-ir.c 
b/drivers/media/pci/cx23885/cx23888-ir.c
index c2bc39c..e448146 100644
--- a/drivers/media/pci/cx23885/cx23888-ir.c
+++ b/drivers/media/pci/cx23885/cx23888-ir.c
@@ -1236,13 +1236,11 @@ int cx23888_ir_probe(struct cx23885_dev *dev)
cx23888_ir_write4(dev, CX23888_IR_IRQEN_REG, 0);
 
mutex_init(state-rx_params_lock);
-   memcpy(default_params, default_rx_params,
-  sizeof(struct v4l2_subdev_ir_parameters));
+   default_params = default_rx_params;
v4l2_subdev_call(sd, ir, rx_s_parameters, default_params);
 
mutex_init(state-tx_params_lock);
-   memcpy(default_params, default_tx_params,
-  sizeof(struct v4l2_subdev_ir_parameters));
+   default_params = default_tx_params;
v4l2_subdev_call(sd, ir, tx_s_parameters, default_params);
} else {
kfifo_free(state-rx_kfifo);
-- 
1.7.4.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


[PATCH 18/23] cx18: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Cc: Andy Walls awa...@md.metrocast.net
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/pci/cx18/cx18-i2c.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-i2c.c 
b/drivers/media/pci/cx18/cx18-i2c.c
index 51609d5..930d40f 100644
--- a/drivers/media/pci/cx18/cx18-i2c.c
+++ b/drivers/media/pci/cx18/cx18-i2c.c
@@ -240,15 +240,13 @@ int init_cx18_i2c(struct cx18 *cx)
 
for (i = 0; i  2; i++) {
/* Setup algorithm for adapter */
-   memcpy(cx-i2c_algo[i], cx18_i2c_algo_template,
-   sizeof(struct i2c_algo_bit_data));
+   cx-i2c_algo[i] = cx18_i2c_algo_template;
cx-i2c_algo_cb_data[i].cx = cx;
cx-i2c_algo_cb_data[i].bus_index = i;
cx-i2c_algo[i].data = cx-i2c_algo_cb_data[i];
 
/* Setup adapter */
-   memcpy(cx-i2c_adap[i], cx18_i2c_adap_template,
-   sizeof(struct i2c_adapter));
+   cx-i2c_adap[i] = cx18_i2c_adap_template;
cx-i2c_adap[i].algo_data = cx-i2c_algo[i];
sprintf(cx-i2c_adap[i].name + strlen(cx-i2c_adap[i].name),
 #%d-%d, cx-instance, i);
-- 
1.7.4.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


[PATCH 20/23] dvb-core: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/dvb-core/dvb_frontend.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 7e92793..c770464 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2256,7 +2256,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
printk(%s switch command: 0x%04lx\n, 
__func__, swcmd);
do_gettimeofday(nexttime);
if (dvb_frontend_debug)
-   memcpy(tv[0], nexttime, sizeof(struct 
timeval));
+   tv[0] = nexttime;
/* before sending a command, initialize by sending
 * a 32ms 18V to the switch
 */
-- 
1.7.4.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


[PATCH 19/23] bttv: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/pci/bt8xx/bttv-i2c.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/bt8xx/bttv-i2c.c 
b/drivers/media/pci/bt8xx/bttv-i2c.c
index 580c8e6..7398afa 100644
--- a/drivers/media/pci/bt8xx/bttv-i2c.c
+++ b/drivers/media/pci/bt8xx/bttv-i2c.c
@@ -366,8 +366,7 @@ int __devinit init_bttv_i2c(struct bttv *btv)
 
strlcpy(btv-c.i2c_adap.name, bttv,
sizeof(btv-c.i2c_adap.name));
-   memcpy(btv-i2c_algo, bttv_i2c_algo_bit_template,
-  sizeof(bttv_i2c_algo_bit_template));
+   btv-i2c_algo = bttv_i2c_algo_bit_template;
btv-i2c_algo.udelay = i2c_udelay;
btv-i2c_algo.data = btv;
btv-c.i2c_adap.algo_data = btv-i2c_algo;
-- 
1.7.4.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


[PATCH 16/23] cx88: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/pci/cx88/cx88-cards.c  |2 +-
 drivers/media/pci/cx88/cx88-i2c.c|3 +--
 drivers/media/pci/cx88/cx88-vp3054-i2c.c |3 +--
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/media/pci/cx88/cx88-cards.c 
b/drivers/media/pci/cx88/cx88-cards.c
index 0c25524..e2e0b8f 100644
--- a/drivers/media/pci/cx88/cx88-cards.c
+++ b/drivers/media/pci/cx88/cx88-cards.c
@@ -3743,7 +3743,7 @@ struct cx88_core *cx88_core_create(struct pci_dev *pci, 
int nr)
cx88_card_list(core, pci);
}
 
-   memcpy(core-board, cx88_boards[core-boardnr], sizeof(core-board));
+   core-board = cx88_boards[core-boardnr];
 
if (!core-board.num_frontends  (core-board.mpeg  CX88_MPEG_DVB))
core-board.num_frontends = 1;
diff --git a/drivers/media/pci/cx88/cx88-i2c.c 
b/drivers/media/pci/cx88/cx88-i2c.c
index de0f1af..cf2d696 100644
--- a/drivers/media/pci/cx88/cx88-i2c.c
+++ b/drivers/media/pci/cx88/cx88-i2c.c
@@ -139,8 +139,7 @@ int cx88_i2c_init(struct cx88_core *core, struct pci_dev 
*pci)
if (i2c_udelay5)
i2c_udelay=5;
 
-   memcpy(core-i2c_algo, cx8800_i2c_algo_template,
-  sizeof(core-i2c_algo));
+   core-i2c_algo = cx8800_i2c_algo_template;
 
 
core-i2c_adap.dev.parent = pci-dev;
diff --git a/drivers/media/pci/cx88/cx88-vp3054-i2c.c 
b/drivers/media/pci/cx88/cx88-vp3054-i2c.c
index d77f8ec..deede6e 100644
--- a/drivers/media/pci/cx88/cx88-vp3054-i2c.c
+++ b/drivers/media/pci/cx88/cx88-vp3054-i2c.c
@@ -118,8 +118,7 @@ int vp3054_i2c_probe(struct cx8802_dev *dev)
return -ENOMEM;
dev-vp3054 = vp3054_i2c;
 
-   memcpy(vp3054_i2c-algo, vp3054_i2c_algo_template,
-  sizeof(vp3054_i2c-algo));
+   vp3054_i2c-algo = vp3054_i2c_algo_template;
 
vp3054_i2c-adap.dev.parent = dev-pci-dev;
strlcpy(vp3054_i2c-adap.name, core-name,
-- 
1.7.4.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 00/23] em28xx: add support fur USB bulk transfers

2012-10-23 Thread Frank Schäfer
Hi,

Am 21.10.2012 21:13, schrieb Devin Heitmueller:
 Hi Frank,

 On Sun, Oct 21, 2012 at 12:52 PM, Frank Schäfer
 fschaefer@googlemail.com wrote:
 This patch series adds support for USB bulk transfers to the em28xx driver.
 This is a welcome change that some users have been asking about for a while.

Yes, I know...


 Patch 1 is a bugfix for the image data processing with non-interlaced 
 devices (webcams)
 that should be considered for stable (see commit message).

 Patches 2-21 extend the driver to support USB bulk transfers.
 USB endpoint mapping had to be extended and is a bit tricky.
 It might still not be sufficient to handle ALL isoc/bulk endpoints of ALL 
 existing devices,
 but it should work with the devices we have seen so far and (most important 
 !)
 preserves backwards compatibility to the current driver behavior.
 Isoc endpoints/transfers are preffered by default, patch 21 adds a module 
 parameter to change this behavior.

 The last two patches are follow-up patches not really related to USB 
 tranfers.
 Patch 22 reduces the code size in em28xx-video by merging the two URB data 
 processing functions
 This is generally good stuff.  When I originally added the VBI
 support, I kept the URB handlers separate initially to reduce the risk
 of breaking existing devices, and always assumed that at some point
 the two routines would be merged.  You did regression test without VBI
 support enabled though, right?

Yes, but when you take a look at the code, you will see that this patch
nothing really changes for VBI devices.
The problem / regression potential is the non-VBI-devices as they are
now using the VBI-version, too, but they have been tested.
Btw, why didn't you test this function with VBI disabled when you added
it ? ;)


 and patch 23 enables VBI-support for em2840-devices.
 Patch 23 shouldn't be applied unless somebody has an em2840 device to
 test with first.  Nobody has complained about this so far, and it's
 better to not support VBI than to possibly break existing support.

Btw, what about em2874 / em2884 / em28174 ?
We should really sort these kind of things out when adding new devices...


 Please note that I could test the changes with an analog non-interlaced 
 non-VBI device only !
 So further tests with DVB/interlaced/VBI devices are strongly recommended !
 So here's the problem:  I don't have the cycles to test this, and all
 the refactoring presents a very real risk that breakage of existing
 support could occur.  You've basically got three options if you want
 to see this merged upstream:

 1.  Wait for me to eventually do the testing.
 2.  Plead for users to do testing, in particular of the VBI support
 for interlaced devices (which is 99% of devices out there)
 3.  See if Mauro has time to do the testing.

I would say 1 + 2 + 3 ;)
And maybe it's a good chance for the people who were asking for this
feature in the past.

I know there are lots of other people on this list having such a device.

 4.  Spend $30 and buy one of the dozens of em28xx based analog capture
 devices out there and do the validation yourself (a huge percentage of
 the Video tape capture devices are em28xx based.  For example, when
 I did the original VBI work, I used the following:

 KWorld DVD Maker USB 2.0 VS- USB2800 USB 2.0 Interface
 http://www.newegg.com/Product/Product.aspx?Item=N82E16815100112

 If you're in the United States, I can mail you a device for testing.
 But given how dirt-cheap they are, buying one yourself might be easier
 (and if the money is really the issue, send me your paypal details
 offline and I'll give you the $30.00).

No, thank you. I already have too many devices which I actually don't need.
I'm doing this as a hobby and at the moment, I'm focussed on getting the
devices I already have working properly (which isn't a small task).

I personally don't need this feature uptsream at the moment.
The device I used for testing supports ISOC as well and the em25xx
webcam I'm currently working on will likely use gspca at the end.

 Thanks for you hard work on this, and it will be great to get this
 stuff into the mainline.

I did what I could do. Now its up to others ;)

Regards,
Frank

 Devin


--
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 10/23] dvb-usb/friio-fe: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/dvb-usb/friio-fe.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/friio-fe.c 
b/drivers/media/usb/dvb-usb/friio-fe.c
index 90a70c6..d56f927 100644
--- a/drivers/media/usb/dvb-usb/friio-fe.c
+++ b/drivers/media/usb/dvb-usb/friio-fe.c
@@ -421,11 +421,10 @@ struct dvb_frontend *jdvbt90502_attach(struct 
dvb_usb_device *d)
 
/* setup the state */
state-i2c = d-i2c_adap;
-   memcpy(state-config, friio_fe_config, sizeof(friio_fe_config));
+   state-config = friio_fe_config;
 
/* create dvb_frontend */
-   memcpy(state-frontend.ops, jdvbt90502_ops,
-  sizeof(jdvbt90502_ops));
+   state-frontend.ops = jdvbt90502_ops;
state-frontend.demodulator_priv = state;
 
if (jdvbt90502_init(state-frontend)  0)
-- 
1.7.4.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


[PATCH 12/23] tuners/xc4000: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/tuners/xc4000.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/tuners/xc4000.c b/drivers/media/tuners/xc4000.c
index 4937712..d178dee 100644
--- a/drivers/media/tuners/xc4000.c
+++ b/drivers/media/tuners/xc4000.c
@@ -1066,7 +1066,7 @@ check_device:
goto fail;
}
 
-   memcpy(priv-cur_fw, new_fw, sizeof(priv-cur_fw));
+   priv-cur_fw = new_fw;
 
/*
 * By setting BASE in cur_fw.type only after successfully loading all
-- 
1.7.4.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


[PATCH 15/23] ivtv: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Cc: Andy Walls awa...@md.metrocast.net
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/pci/ivtv/ivtv-i2c.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
b/drivers/media/pci/ivtv/ivtv-i2c.c
index d47f41a..27a8466 100644
--- a/drivers/media/pci/ivtv/ivtv-i2c.c
+++ b/drivers/media/pci/ivtv/ivtv-i2c.c
@@ -719,13 +719,10 @@ int init_ivtv_i2c(struct ivtv *itv)
return -ENODEV;
}
if (itv-options.newi2c  0) {
-   memcpy(itv-i2c_adap, ivtv_i2c_adap_hw_template,
-  sizeof(struct i2c_adapter));
+   itv-i2c_adap = ivtv_i2c_adap_hw_template;
} else {
-   memcpy(itv-i2c_adap, ivtv_i2c_adap_template,
-  sizeof(struct i2c_adapter));
-   memcpy(itv-i2c_algo, ivtv_i2c_algo_template,
-  sizeof(struct i2c_algo_bit_data));
+   itv-i2c_adap = ivtv_i2c_adap_template;
+   itv-i2c_algo = ivtv_i2c_algo_template;
}
itv-i2c_algo.udelay = itv-options.i2c_clock_period / 2;
itv-i2c_algo.data = itv;
@@ -735,8 +732,7 @@ int init_ivtv_i2c(struct ivtv *itv)
itv-instance);
i2c_set_adapdata(itv-i2c_adap, itv-v4l2_dev);
 
-   memcpy(itv-i2c_client, ivtv_i2c_client_template,
-  sizeof(struct i2c_client));
+   itv-i2c_client = ivtv_i2c_client_template;
itv-i2c_client.adapter = itv-i2c_adap;
itv-i2c_adap.dev.parent = itv-pdev-dev;
 
-- 
1.7.4.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


cron job: media_tree daily build: WARNINGS

2012-10-23 Thread Hans Verkuil
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:Tue Oct 23 19:00:22 CEST 2012
git hash:74df06daf632ce2d321d01cb046004768352efc4
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: WARNINGS
linux-git-arm-eabi-exynos: WARNINGS
linux-git-arm-eabi-omap: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-sh: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-i686: WARNINGS
linux-3.4-i686: WARNINGS
linux-3.5-i686: WARNINGS
linux-3.6-i686: WARNINGS
linux-3.7-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
linux-3.4-x86_64: WARNINGS
linux-3.5-x86_64: WARNINGS
linux-3.6-x86_64: WARNINGS
linux-3.7-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification 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


[PATCH 13/23] tuners/xc2028: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/tuners/tuner-xc2028.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/tuners/tuner-xc2028.c 
b/drivers/media/tuners/tuner-xc2028.c
index 7bcb6b0..0945173 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -870,7 +870,7 @@ check_device:
}
 
 read_not_reliable:
-   memcpy(priv-cur_fw, new_fw, sizeof(priv-cur_fw));
+   priv-cur_fw = new_fw;
 
/*
 * By setting BASE in cur_fw.type only after successfully loading all
-- 
1.7.4.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


[PATCH 11/23] au0828: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/au0828/au0828-cards.c |2 +-
 drivers/media/usb/au0828/au0828-i2c.c   |9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-cards.c 
b/drivers/media/usb/au0828/au0828-cards.c
index 448361c..8830d6d 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -192,7 +192,7 @@ void au0828_card_setup(struct au0828_dev *dev)
 
dprintk(1, %s()\n, __func__);
 
-   memcpy(dev-board, au0828_boards[dev-boardnr], sizeof(dev-board));
+   dev-board = au0828_boards[dev-boardnr];
 
if (dev-i2c_rc == 0) {
dev-i2c_client.addr = 0xa0  1;
diff --git a/drivers/media/usb/au0828/au0828-i2c.c 
b/drivers/media/usb/au0828/au0828-i2c.c
index 4ded17f..71fbe59 100644
--- a/drivers/media/usb/au0828/au0828-i2c.c
+++ b/drivers/media/usb/au0828/au0828-i2c.c
@@ -364,12 +364,9 @@ int au0828_i2c_register(struct au0828_dev *dev)
 {
dprintk(1, %s()\n, __func__);
 
-   memcpy(dev-i2c_adap, au0828_i2c_adap_template,
-  sizeof(dev-i2c_adap));
-   memcpy(dev-i2c_algo, au0828_i2c_algo_template,
-  sizeof(dev-i2c_algo));
-   memcpy(dev-i2c_client, au0828_i2c_client_template,
-  sizeof(dev-i2c_client));
+   dev-i2c_adap = au0828_i2c_adap_template;
+   dev-i2c_algo = au0828_i2c_algo_template;
+   dev-i2c_client = au0828_i2c_client_template;
 
dev-i2c_adap.dev.parent = dev-usbdev-dev;
 
-- 
1.7.4.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: [RFC/PATCH] v4l: Add V4L2_CID_FLASH_HW_STROBE_MODE control

2012-10-23 Thread Sakari Ailus
Hi Sylwester,

On Tue, Oct 16, 2012 at 11:45:59PM +0200, Sylwester Nawrocki wrote:
 On 10/14/2012 08:30 PM, Sakari Ailus wrote:
  Currently the flash control reference states that The V4L2 flash controls
  are intended to provide generic access to flash controller devices. Flash
  controller devices are typically used in digital cameras.
  
  Whether or not higher level controls should be part of the same class is a
  valid question. The controls intended to expose certain frames with flash
  are quite different from those used to control the low-level flash chip: the
  user is fully responsible for timing and the flash sequence.
  
  For higher level controls that could be implemented using the low-level
  controls for the end user, the user would likely prefer to say things like
  please give me a frame exposed with flash. Since the timing is no longer
  implemented by the user, the user would need to know which frames have been
  exposed and how, at least in a general case. Getting around this could
  involve configuring the sensor before starting streaming. Perhaps this is an
  assumption we could accept now, before we have proper means for passing
  frame-related parameters to user space.
 
 Yes, right. This auto strobe control seems to be a higher level one, since
 we have a firmware program that is taking care of some things that normally
 would be done through the existing Flash class controls by a user space
 application/library.
 
 I'm not really sure if we need a new class. It's even hard to name it.
 I don't see such an auto strobe control as a high level one, from an end 
 application POV. It's more like the existing controls are low level.

After thinking about it awhile, an alternative I see to this is to put it to
the camera class. It's got other high level controls as well, those related
to e.g. AF. I have to admit I'm not certain which one would be a better
choice in the long run. I'm leaning towards the camera class, though.

Say, if you'd create low level controls for lens movement, you probably
wouldn't put them to the existing camera class. They wouldn't seem to fit
there.

Laurent, Hans, others: do you have an opinion on this?

 With V4L2 device profiles, when eventually we create them... it might not
 matter if we create separate flash control class for flash controllers,
 camera sensors, each one low or high level.
 
 I agree with your remarks regarding pre-configuring a sensor. Frame meta
 data could carry relevant information, but so far we don't have standard
 solution for that.

Agreed. But as long as we assume there's streamoff, we don't even need one.

  V4L2_CID_FLASH_HW_STROBE_AUTO
 
  with options:
V4L2_FLASH_HW_STROBE_OFF
V4L2_FLASH_HW_STROBE_AUTO
V4L2_FLASH_HW_STROBE_ON
 
  The _HW prefix probably needs to be removed there.
  
  V4L2_CID_FLASH_STROBE_AUTO sounds good to me as such.
  
  Do you always need to streamoff first, after which these the sensors perform
  a single capture with flash enabled, or how does it work? How about the
  subsequent captures; will they be done with flash enabled as well (requiring
  a possible flash cool-off time) or will the flash be disabled for them?
 
 Currently a streamoff is needed in general. The pipeline needs to be
 reconfigured for different resolution/image format. The flash should be 
 fired as configured per each capture request. I imagine sensor could delay 
 actual capture when the Flash is not ready, due to required cool-off/
 re-charge time. Such an information would need to be provided to the sensor 
 somehow, e.g. with a private ioctl. I don't have much experience yet with 
 more advanced Flash circuits/controls. 

The simple flash controller chips I'm familiar with don't have such fancy
features. One just has to be patient with commanding the LED. :)

If there was a sensor that can do this automatically, then why not?

 So V4L2_FLASH_STROBE_ON would mean, for each executed capture request the 
 Flash is to be triggered unconditionally.
 
  For something more complex we'd require something else than a control
  interface; possibly a private IOCTL to set frame-specific flash parameters.
 
 Yes, I agree with that. Per frame meta data is needed to figure out, e.g. 
 which frame has been exposed with flash and which one without.

This was discussed in Cambourne last year. The frame parameters could be
given with a single IOCTL (possibly private or not), and the results would
be available on a plane of a multi-plane buffer. More in the meeting notes.

URL:http://www.digipedia.pl/usenet/thread/18550/849/

  Albeit I think that this control would be very different from what the rest
  of the controls in the class do, I don't see a better place for it either. I
  wouldn't mind hearing others' opinions, though.
 
 Maybe we could consider just documenting this kind of controls in a separate 
 section ?
 
  OTOH it seems V4L2_CID_FLASH_LED_MODE and V4L2_CID_FLASH_TORCH_INTENSITY
  could do the same. 

Re: [PATCH v3 6/6] Add a codec driver for SI476X MFD

2012-10-23 Thread Andrey Smirnov
On 10/23/2012 12:24 PM, Mark Brown wrote:
 On Tue, Oct 23, 2012 at 11:44:32AM -0700, Andrey Smirnov wrote:
 This commit add a sound codec driver for Silicon Laboratories 476x
 series of AM/FM radio chips.
 I already merged a driver for this.  If there are any changes you should
 send incremental updates rather than a full new driver.

 OK, will do.

--
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: [RFC] Processing context in the V4L2 subdev and V4L2 controls API ?

2012-10-23 Thread Sakari Ailus
Hi Laurent and others,

On Wed, Oct 17, 2012 at 01:55:10AM +0200, Laurent Pinchart wrote:
 On Monday 15 October 2012 10:20:00 Hans Verkuil wrote:
  On Sat October 13 2012 22:08:29 Sylwester Nawrocki wrote:
   On 09/21/2012 02:26 PM, Hans Verkuil wrote:
On Tue September 18 2012 17:06:54 Sylwester Nawrocki wrote:
Hi All,

I'm trying to fulfil following requirements with V4L2 API that are
specific to most of Samsung camera sensors with embedded SoC ISP and
also for local SoC camera ISPs:
  - separate pixel format and pixel resolution needs to be configured
in a device for camera preview and capture;
  
  - there is a need to set capture or preview mode in a device
explicitly as it makes various adjustments (in firmware) in each
operation mode and controls external devices accordingly (e.g.
camera Flash);
  
  - some devices have more than two use case specific contexts that a
user needs to choose from, e.g. video preview, video capture, still
preview, still capture; for each of these modes there are separate
settings, especially pixel resolution and others corresponding to
existing v4l2 controls;
  
  - some devices can have two processing contexts enabled
simultaneously, e.g. a sensor emitting YUYV and JPEG streams
simultaneously (please see discussion [1]).

This makes me considering making the v4l2 subdev (and maybe v4l2
controls) API processing (capture) context aware.
 
 I think we have several distinct issues here that should be discussed 
 separately (but of course considered together), otherwise we'll just create a 
 horrible mess (or just fail to create it).
 
 I see contexts as hardware-provided parameters storage. Depending on the 
 hardware, contexts can
 
 - Store a small subset of, a large subset of or all parameters (the later 
 being quite unlikely).
 
 - Be associated with hardware operation modes (a snapshot context in a 
 sensor could be hardwired to snapshot mode for instance) but don't need to, 
 I'm aware of sensors that have multiple contexts that are not in any way 
 associated with a particular operation mode.
 
 - Support cloning a different context.
 
 As such, contexts are containers that need to support operations such as 
 cloning and selection of the active context. As long as those contexts are 
 local to a subdev I pretty much agree with Hans, we should reuse our existing 
 APIs and add ioctls to handle context-specific operations.
 
 I'm not convinced we should support pure software contexts for devices that 
 don't support hardware contexts, but I believe the API should allow to do so.
 
 This won't be straightforward.
 
 However this won't be enough. I'm pretty sure that we will soon need (if we 
 don't already) cross-subdev contexts, for instance to support hardware 
 contexts local to a sensor that creates several subdevs. Modifying parameters 
 of a context shouldn't be a huge issue in that case, but selecting the active 
 context would be more problematic as it would involve cross-subdev operations 
 that can't be expressed through the V4L2 subdev API.
 
 We also need to consider that contexts can store parameters that directly 
 influence media bus formats on connected links. I have no clear use case at 
 the moment, but link configuration might also be part of the context. This 
 would call for handling contexts on the media controller device node. That's 
 opening Pandora's box, but I feel that we will need to at some point anyway 
 to 
 support atomic pipeline reconfiguration.
 
 This won't be straightforward. I know I'm repeating myself :-)

Contexts (or cross-subdev contexts) might not be that difficult after all.
We have a standard API but the device that provides the API could be made
the means of selecting the context. Logical subdevs. E.g. for contexts 0 and
1 (for a single driver):


pixel array 0   pixel array 1
|   |
|   |
binner 0binner 1
 \ /
   \ /
 \  c0 / c1
   \ /
 \ /
  output
|
|


This approach cannot address limitations on the context, i.e. whether it's
just a few parameters or more. But it'd allow the user space to configure
the device whenver with the implicit knowledge of the contexts. Links c0 and
c1 would be enabled or disabled to choose the context.

This wouldn't scale to cases where the number of contexts supported is
variable or large.

I agree with Laurent that high level controls are in general difficult to
standardise, and probably so because there tends to be more assumptions
taken than when it comes to low level controls.

Also switching contexts while streaming might be out of question, but I
wonder if that's really so important. The hardware has developed into a
direction (as well as the V4L2 framework with VB2) where 

[PATCH 06/23] pvrusb2: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Cc: Mike Isely is...@pobox.com
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/pvrusb2/pvrusb2-encoder.c  |3 +--
 drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c |4 ++--
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c |2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c 
b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
index e046fda..f7702ae 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
@@ -422,8 +422,7 @@ int pvr2_encoder_adjust(struct pvr2_hdw *hdw)
pvr2_trace(PVR2_TRACE_ERROR_LEGS,
   Error from cx2341x module code=%d,ret);
} else {
-   memcpy(hdw-enc_cur_state,hdw-enc_ctl_state,
-  sizeof(struct cx2341x_mpeg_params));
+   hdw-enc_cur_state = hdw-enc_ctl_state;
hdw-enc_cur_valid = !0;
}
return ret;
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c 
b/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
index 885ce11..9691156 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
@@ -649,8 +649,8 @@ void pvr2_i2c_core_init(struct pvr2_hdw *hdw)
}
 
// Configure the adapter and set up everything else related to it.
-   memcpy(hdw-i2c_adap,pvr2_i2c_adap_template,sizeof(hdw-i2c_adap));
-   memcpy(hdw-i2c_algo,pvr2_i2c_algo_template,sizeof(hdw-i2c_algo));
+   hdw-i2c_adap = pvr2_i2c_adap_template;
+   hdw-i2c_algo = pvr2_i2c_algo_template;
strlcpy(hdw-i2c_adap.name,hdw-name,sizeof(hdw-i2c_adap.name));
hdw-i2c_adap.dev.parent = hdw-usb_dev-dev;
hdw-i2c_adap.algo = hdw-i2c_algo;
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c 
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index db249ca..5b622ec 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -1339,7 +1339,7 @@ static void pvr2_v4l2_dev_init(struct pvr2_v4l2_dev *dip,
return;
}
 
-   memcpy(dip-devbase,vdev_template,sizeof(vdev_template));
+   dip-devbase = vdev_template;
dip-devbase.release = pvr2_video_device_release;
dip-devbase.ioctl_ops = pvr2_ioctl_ops;
{
-- 
1.7.4.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


[PATCH 08/23] cx25840: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/i2c/cx25840/cx25840-ir.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-ir.c 
b/drivers/media/i2c/cx25840/cx25840-ir.c
index 38ce76e..9ae977b 100644
--- a/drivers/media/i2c/cx25840/cx25840-ir.c
+++ b/drivers/media/i2c/cx25840/cx25840-ir.c
@@ -1251,13 +1251,11 @@ int cx25840_ir_probe(struct v4l2_subdev *sd)
cx25840_write4(ir_state-c, CX25840_IR_IRQEN_REG, 0);
 
mutex_init(ir_state-rx_params_lock);
-   memcpy(default_params, default_rx_params,
-  sizeof(struct v4l2_subdev_ir_parameters));
+   default_params = default_rx_params;
v4l2_subdev_call(sd, ir, rx_s_parameters, default_params);
 
mutex_init(ir_state-tx_params_lock);
-   memcpy(default_params, default_tx_params,
-  sizeof(struct v4l2_subdev_ir_parameters));
+   default_params = default_tx_params;
v4l2_subdev_call(sd, ir, tx_s_parameters, default_params);
 
return 0;
-- 
1.7.4.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


[PATCH 09/23] zr36067: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/pci/zoran/zoran_card.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/zoran/zoran_card.c 
b/drivers/media/pci/zoran/zoran_card.c
index fffc54b..cea325d 100644
--- a/drivers/media/pci/zoran/zoran_card.c
+++ b/drivers/media/pci/zoran/zoran_card.c
@@ -708,8 +708,7 @@ static const struct i2c_algo_bit_data 
zoran_i2c_bit_data_template = {
 static int
 zoran_register_i2c (struct zoran *zr)
 {
-   memcpy(zr-i2c_algo, zoran_i2c_bit_data_template,
-  sizeof(struct i2c_algo_bit_data));
+   zr-i2c_algo = zoran_i2c_bit_data_template;
zr-i2c_algo.data = zr;
strlcpy(zr-i2c_adapter.name, ZR_DEVNAME(zr),
sizeof(zr-i2c_adapter.name));
-- 
1.7.4.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


[PATCH 07/23] hdpvr: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Cc: Mike Isely is...@pobox.com
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/hdpvr/hdpvr-i2c.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/hdpvr/hdpvr-i2c.c 
b/drivers/media/usb/hdpvr/hdpvr-i2c.c
index 82e819f..2df60bf 100644
--- a/drivers/media/usb/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/usb/hdpvr/hdpvr-i2c.c
@@ -217,8 +217,7 @@ int hdpvr_register_i2c_adapter(struct hdpvr_device *dev)
 
hdpvr_activate_ir(dev);
 
-   memcpy(dev-i2c_adapter, hdpvr_i2c_adapter_template,
-  sizeof(struct i2c_adapter));
+   dev-i2c_adapter = hdpvr_i2c_adapter_template;
dev-i2c_adapter.dev.parent = dev-udev-dev;
 
i2c_set_adapdata(dev-i2c_adapter, dev);
-- 
1.7.4.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


[PATCH 03/23] usbvision: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/usbvision/usbvision-i2c.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/usbvision/usbvision-i2c.c 
b/drivers/media/usb/usbvision/usbvision-i2c.c
index 89fec02..ba262a3 100644
--- a/drivers/media/usb/usbvision/usbvision-i2c.c
+++ b/drivers/media/usb/usbvision/usbvision-i2c.c
@@ -189,8 +189,7 @@ int usbvision_i2c_register(struct usb_usbvision *usbvision)
if (usbvision-registered_i2c)
return 0;
 
-   memcpy(usbvision-i2c_adap, i2c_adap_template,
-  sizeof(struct i2c_adapter));
+   usbvision-i2c_adap = i2c_adap_template;
 
sprintf(usbvision-i2c_adap.name, %s-%d-%s, i2c_adap_template.name,
usbvision-dev-bus-busnum, usbvision-dev-devpath);
-- 
1.7.4.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


[PATCH 02/23] cx231xx: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/cx231xx/cx231xx-cards.c |2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c |3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index b84ebc5..352d676 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -705,7 +705,7 @@ void cx231xx_sleep_s5h1432(struct cx231xx *dev)
 
 static inline void cx231xx_set_model(struct cx231xx *dev)
 {
-   memcpy(dev-board, cx231xx_boards[dev-model], sizeof(dev-board));
+   dev-board = cx231xx_boards[dev-model];
 }
 
 /* Since cx231xx_pre_card_setup() requires a proper dev-model,
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c 
b/drivers/media/usb/cx231xx/cx231xx-video.c
index fedf785..c5109ba 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -2627,8 +2627,7 @@ int cx231xx_register_analog_devices(struct cx231xx *dev)
 dev-name, video_device_node_name(dev-vdev));
 
/* Initialize VBI template */
-   memcpy(cx231xx_vbi_template, cx231xx_video_template,
-  sizeof(cx231xx_vbi_template));
+   cx231xx_vbi_template = cx231xx_video_template;
strcpy(cx231xx_vbi_template.name, cx231xx-vbi);
 
/* Allocate and fill vbi video_device struct */
-- 
1.7.4.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


[PATCH 05/23] pwc: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Cc: Hans de Goede hdego...@redhat.com
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/pwc/pwc-if.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 42e36ba..cc5c7d8 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -1003,7 +1003,7 @@ static int usb_pwc_probe(struct usb_interface *intf, 
const struct usb_device_id
vb2_queue_init(pdev-vb_queue);
 
/* Init video_device structure */
-   memcpy(pdev-vdev, pwc_template, sizeof(pwc_template));
+   pdev-vdev = pwc_template;
strcpy(pdev-vdev.name, name);
pdev-vdev.queue = pdev-vb_queue;
pdev-vdev.queue-lock = pdev-vb_queue_lock;
-- 
1.7.4.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


[PATCH 04/23] sn9c102: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy((to), (from), E);
+to = from;
// /smpl

Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/sn9c102/sn9c102_core.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/sn9c102/sn9c102_core.c 
b/drivers/media/usb/sn9c102/sn9c102_core.c
index 5bfc8e2..4cae6f8 100644
--- a/drivers/media/usb/sn9c102/sn9c102_core.c
+++ b/drivers/media/usb/sn9c102/sn9c102_core.c
@@ -2824,7 +2824,7 @@ sn9c102_vidioc_querybuf(struct sn9c102_device* cam, void 
__user * arg)
b.index = cam-nbuffers || cam-io != IO_MMAP)
return -EINVAL;
 
-   memcpy(b, cam-frame[b.index].buf, sizeof(b));
+   b = cam-frame[b.index].buf;
 
if (cam-frame[b.index].vma_use_count)
b.flags |= V4L2_BUF_FLAG_MAPPED;
@@ -2927,7 +2927,7 @@ sn9c102_vidioc_dqbuf(struct sn9c102_device* cam, struct 
file* filp,
 
f-state = F_UNUSED;
 
-   memcpy(b, f-buf, sizeof(b));
+   b = f-buf;
if (f-vma_use_count)
b.flags |= V4L2_BUF_FLAG_MAPPED;
 
-- 
1.7.4.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 15/23] ivtv: Replace memcpy with struct assignment

2012-10-23 Thread Andy Walls
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.

This one is a code maintenance win. :)

See my comments at the end for the difference in assembled code on an
AMD x86_64 CPU using
$ gcc --version
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)


 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl
 
 Cc: Andy Walls awa...@md.metrocast.net

Signed-off-by: Andy Walls awa...@md.metrocast.net


 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/pci/ivtv/ivtv-i2c.c |   12 
  1 files changed, 4 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
 b/drivers/media/pci/ivtv/ivtv-i2c.c
 index d47f41a..27a8466 100644
 --- a/drivers/media/pci/ivtv/ivtv-i2c.c
 +++ b/drivers/media/pci/ivtv/ivtv-i2c.c
 @@ -719,13 +719,10 @@ int init_ivtv_i2c(struct ivtv *itv)
   return -ENODEV;
   }
   if (itv-options.newi2c  0) {
 - memcpy(itv-i2c_adap, ivtv_i2c_adap_hw_template,
 -sizeof(struct i2c_adapter));
 + itv-i2c_adap = ivtv_i2c_adap_hw_template;
   } else {
 - memcpy(itv-i2c_adap, ivtv_i2c_adap_template,
 -sizeof(struct i2c_adapter));
 - memcpy(itv-i2c_algo, ivtv_i2c_algo_template,
 -sizeof(struct i2c_algo_bit_data));
 + itv-i2c_adap = ivtv_i2c_adap_template;
 + itv-i2c_algo = ivtv_i2c_algo_template;
   }
   itv-i2c_algo.udelay = itv-options.i2c_clock_period / 2;
   itv-i2c_algo.data = itv;
 @@ -735,8 +732,7 @@ int init_ivtv_i2c(struct ivtv *itv)
   itv-instance);
   i2c_set_adapdata(itv-i2c_adap, itv-v4l2_dev);
  
 - memcpy(itv-i2c_client, ivtv_i2c_client_template,
 -sizeof(struct i2c_client));
 + itv-i2c_client = ivtv_i2c_client_template;
   itv-i2c_client.adapter = itv-i2c_adap;
   itv-i2c_adap.dev.parent = itv-pdev-dev;
  

I looked at the generated assembly with only this last change
implemented:

$ objdump -h -r -d -l -s orig-ivtv-i2c.o.sav | less
[...]
 07e0  69767476 20696e74 65726e61  ivtv interna
 07f0 6c00     l...
 0800      
 0810      
 0820      
 0830      
[...]
init_ivtv_i2c():
/home/andy/cx18dev/git/media_tree/drivers/media/video/ivtv/ivtv-i2c.c:738
13bb:   48 c7 c6 00 00 00 00mov$0x0,%rsi
13be: R_X86_64_32S  .rodata+0x7e0
13c2:   48 8d bb 30 04 01 00lea0x10430(%rbx),%rdi
13c9:   b9 5a 00 00 00  mov$0x5a,%ecx
13ce:   f3 48 a5rep movsq %ds:(%rsi),%es:(%rdi)


$ objdump -h -r -d -l -s orig-ivtv-i2c.o.sav | less
[...]
 07e0  69767476 20696e74 65726e61  ivtv interna
 07f0 6c00     l...
 0800      
 0810      
 0820      
 0830      
[...]
init_ivtv_i2c():
/home/andy/cx18dev/git/media_tree/drivers/media/video/ivtv/ivtv-i2c.c:738
13bb:   48 8d bb 30 04 01 00lea0x10430(%rbx),%rdi
13c2:   48 c7 c6 00 00 00 00mov$0x0,%rsi
13c5: R_X86_64_32S  .rodata+0x7e0
13c9:   b9 5a 00 00 00  mov$0x5a,%ecx
13ce:   f3 48 a5rep movsq %ds:(%rsi),%es:(%rdi)


The generated code is reordered, but essentially identical.  So I guess
in this instance, the preprocessor defines resolved such that an x86-64
optimized memcpy() function was not used from the linux kernel source.

Since all of these memcpy()'s are only called once for each board at
board initialization, performance here really doesn't matter here
anyway.  (Unless one is insanely trying to shave microseconds off boot
time :P )

With other memcpy()/assignement_operator replacement patches, you may
wish to keep performance in mind, if you are patching a frequently
called function.

Regards,
Andy


--
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 17/23] cx23885: Replace memcpy with struct assignment

2012-10-23 Thread Andy Walls
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.
 
 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl
 
 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com

This patch looks OK to me.  You forgot to CC: Steven Toth and/or Devin
Heitmueller (I can't remember who did the VBI work.)

For cx23885-video.c:
Reviewed-by: Andy Walls awa...@md.metrocast.net

For cx23885-ir.c:
Signed-off-by: Andy Walls awa...@md.metrocast.net


 ---
  drivers/media/pci/cx23885/cx23885-video.c |3 +--
  drivers/media/pci/cx23885/cx23888-ir.c|6 ++
  2 files changed, 3 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/media/pci/cx23885/cx23885-video.c 
 b/drivers/media/pci/cx23885/cx23885-video.c
 index 1a21926..62be144 100644
 --- a/drivers/media/pci/cx23885/cx23885-video.c
 +++ b/drivers/media/pci/cx23885/cx23885-video.c
 @@ -1818,8 +1818,7 @@ int cx23885_video_register(struct cx23885_dev *dev)
   spin_lock_init(dev-slock);
  
   /* Initialize VBI template */
 - memcpy(cx23885_vbi_template, cx23885_video_template,
 - sizeof(cx23885_vbi_template));
 + cx23885_vbi_template = cx23885_video_template;
   strcpy(cx23885_vbi_template.name, cx23885-vbi);
  
   dev-tvnorm = cx23885_video_template.current_norm;
 diff --git a/drivers/media/pci/cx23885/cx23888-ir.c 
 b/drivers/media/pci/cx23885/cx23888-ir.c
 index c2bc39c..e448146 100644
 --- a/drivers/media/pci/cx23885/cx23888-ir.c
 +++ b/drivers/media/pci/cx23885/cx23888-ir.c
 @@ -1236,13 +1236,11 @@ int cx23888_ir_probe(struct cx23885_dev *dev)
   cx23888_ir_write4(dev, CX23888_IR_IRQEN_REG, 0);
  
   mutex_init(state-rx_params_lock);
 - memcpy(default_params, default_rx_params,
 -sizeof(struct v4l2_subdev_ir_parameters));
 + default_params = default_rx_params;
   v4l2_subdev_call(sd, ir, rx_s_parameters, default_params);
  
   mutex_init(state-tx_params_lock);
 - memcpy(default_params, default_tx_params,
 -sizeof(struct v4l2_subdev_ir_parameters));
 + default_params = default_tx_params;
   v4l2_subdev_call(sd, ir, tx_s_parameters, default_params);
   } else {
   kfifo_free(state-rx_kfifo);


--
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 18/23] cx18: Replace memcpy with struct assignment

2012-10-23 Thread Andy Walls
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.
 
 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl
 
 Cc: Andy Walls awa...@md.metrocast.net

Signed-off-by: Andy Walls awa...@md.metrocast.net

 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/pci/cx18/cx18-i2c.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/pci/cx18/cx18-i2c.c 
 b/drivers/media/pci/cx18/cx18-i2c.c
 index 51609d5..930d40f 100644
 --- a/drivers/media/pci/cx18/cx18-i2c.c
 +++ b/drivers/media/pci/cx18/cx18-i2c.c
 @@ -240,15 +240,13 @@ int init_cx18_i2c(struct cx18 *cx)
  
   for (i = 0; i  2; i++) {
   /* Setup algorithm for adapter */
 - memcpy(cx-i2c_algo[i], cx18_i2c_algo_template,
 - sizeof(struct i2c_algo_bit_data));
 + cx-i2c_algo[i] = cx18_i2c_algo_template;
   cx-i2c_algo_cb_data[i].cx = cx;
   cx-i2c_algo_cb_data[i].bus_index = i;
   cx-i2c_algo[i].data = cx-i2c_algo_cb_data[i];
  
   /* Setup adapter */
 - memcpy(cx-i2c_adap[i], cx18_i2c_adap_template,
 - sizeof(struct i2c_adapter));
 + cx-i2c_adap[i] = cx18_i2c_adap_template;
   cx-i2c_adap[i].algo_data = cx-i2c_algo[i];
   sprintf(cx-i2c_adap[i].name + strlen(cx-i2c_adap[i].name),
#%d-%d, cx-instance, i);


--
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 08/23] cx25840: Replace memcpy with struct assignment

2012-10-23 Thread Andy Walls
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.
 
 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl
 

This patch is fine.

Signed-off-by: Andy Walls awa...@md.metrocast.net

 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/i2c/cx25840/cx25840-ir.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/i2c/cx25840/cx25840-ir.c 
 b/drivers/media/i2c/cx25840/cx25840-ir.c
 index 38ce76e..9ae977b 100644
 --- a/drivers/media/i2c/cx25840/cx25840-ir.c
 +++ b/drivers/media/i2c/cx25840/cx25840-ir.c
 @@ -1251,13 +1251,11 @@ int cx25840_ir_probe(struct v4l2_subdev *sd)
   cx25840_write4(ir_state-c, CX25840_IR_IRQEN_REG, 0);
  
   mutex_init(ir_state-rx_params_lock);
 - memcpy(default_params, default_rx_params,
 -sizeof(struct v4l2_subdev_ir_parameters));
 + default_params = default_rx_params;
   v4l2_subdev_call(sd, ir, rx_s_parameters, default_params);
  
   mutex_init(ir_state-tx_params_lock);
 - memcpy(default_params, default_tx_params,
 -sizeof(struct v4l2_subdev_ir_parameters));
 + default_params = default_tx_params;
   v4l2_subdev_call(sd, ir, tx_s_parameters, default_params);
  
   return 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


Re: [PATCH 13/23] tuners/xc2028: Replace memcpy with struct assignment

2012-10-23 Thread Andy Walls
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.
 
 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl
 
 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/tuners/tuner-xc2028.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/tuners/tuner-xc2028.c 
 b/drivers/media/tuners/tuner-xc2028.c
 index 7bcb6b0..0945173 100644
 --- a/drivers/media/tuners/tuner-xc2028.c
 +++ b/drivers/media/tuners/tuner-xc2028.c
 @@ -870,7 +870,7 @@ check_device:
   }
  
  read_not_reliable:
 - memcpy(priv-cur_fw, new_fw, sizeof(priv-cur_fw));
 + priv-cur_fw = new_fw;

This memcpy() can get called almost every time
tuner-xc2028.c:generic_set_freq() is called.  

This copies a 32 byte (I think) structure on a 32 bit machine.

I am assuming the difference in performance between the memcpy and
assignment operator is negligible.

Regards,
Andy


   /*
* By setting BASE in cur_fw.type only after successfully loading all


--
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 0/6] SMIA++ PLL and driver improvements

2012-10-23 Thread Laurent Pinchart
Hi Sakari,

Thanks for the patches.

On Tuesday 23 October 2012 18:42:32 Sakari Ailus wrote:
 Hi,
 
 Here's a few SMIA++ patches from me and Laurent.
 
 The set consists of cleanups, PLL calculator improvements and parallel bus
 support for the PLL calculator.

For the whole series,

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

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


Re: [PATCH v3 1/6] Add header files and Kbuild plumbing for SI476x MFD core

2012-10-23 Thread Joe Perches
On Tue, 2012-10-23 at 11:44 -0700, Andrey Smirnov wrote:
 This patch adds all necessary header files and Kbuild plumbing for the
 core driver for Silicon Laboratories Si476x series of AM/FM tuner
 chips.

[]

 +#ifdef DEBUG
 +#define DBG_BUFFER(device, header, buffer, bcount)   \
 + do {\
 + dev_info((device), header); \
 + print_hex_dump_bytes(,\
 +  DUMP_PREFIX_OFFSET,\
 +  buffer, bcount);   \
 + } while (0)

maybe just:
dev_dbg(device, whatever_fmt : %*ph\n, bcount, buffer);
at each call site


--
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 15/23] ivtv: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
Hey Andy,

On Tue, Oct 23, 2012 at 7:08 PM, Andy Walls awa...@md.metrocast.net wrote:
 On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.

 This one is a code maintenance win. :)

 See my comments at the end for the difference in assembled code on an
 AMD x86_64 CPU using
 $ gcc --version
 gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)


 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.

 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)

 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl

 Cc: Andy Walls awa...@md.metrocast.net

 Signed-off-by: Andy Walls awa...@md.metrocast.net


 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/pci/ivtv/ivtv-i2c.c |   12 
  1 files changed, 4 insertions(+), 8 deletions(-)

 diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
 b/drivers/media/pci/ivtv/ivtv-i2c.c
 index d47f41a..27a8466 100644
 --- a/drivers/media/pci/ivtv/ivtv-i2c.c
 +++ b/drivers/media/pci/ivtv/ivtv-i2c.c
 @@ -719,13 +719,10 @@ int init_ivtv_i2c(struct ivtv *itv)
   return -ENODEV;
   }
   if (itv-options.newi2c  0) {
 - memcpy(itv-i2c_adap, ivtv_i2c_adap_hw_template,
 -sizeof(struct i2c_adapter));
 + itv-i2c_adap = ivtv_i2c_adap_hw_template;
   } else {
 - memcpy(itv-i2c_adap, ivtv_i2c_adap_template,
 -sizeof(struct i2c_adapter));
 - memcpy(itv-i2c_algo, ivtv_i2c_algo_template,
 -sizeof(struct i2c_algo_bit_data));
 + itv-i2c_adap = ivtv_i2c_adap_template;
 + itv-i2c_algo = ivtv_i2c_algo_template;
   }
   itv-i2c_algo.udelay = itv-options.i2c_clock_period / 2;
   itv-i2c_algo.data = itv;
 @@ -735,8 +732,7 @@ int init_ivtv_i2c(struct ivtv *itv)
   itv-instance);
   i2c_set_adapdata(itv-i2c_adap, itv-v4l2_dev);

 - memcpy(itv-i2c_client, ivtv_i2c_client_template,
 -sizeof(struct i2c_client));
 + itv-i2c_client = ivtv_i2c_client_template;
   itv-i2c_client.adapter = itv-i2c_adap;
   itv-i2c_adap.dev.parent = itv-pdev-dev;


 I looked at the generated assembly with only this last change
 implemented:

 $ objdump -h -r -d -l -s orig-ivtv-i2c.o.sav | less
 [...]
  07e0  69767476 20696e74 65726e61  ivtv interna
  07f0 6c00     l...
  0800      
  0810      
  0820      
  0830      
 [...]
 init_ivtv_i2c():
 /home/andy/cx18dev/git/media_tree/drivers/media/video/ivtv/ivtv-i2c.c:738
 13bb:   48 c7 c6 00 00 00 00mov$0x0,%rsi
 13be: R_X86_64_32S  .rodata+0x7e0
 13c2:   48 8d bb 30 04 01 00lea0x10430(%rbx),%rdi
 13c9:   b9 5a 00 00 00  mov$0x5a,%ecx
 13ce:   f3 48 a5rep movsq %ds:(%rsi),%es:(%rdi)


 $ objdump -h -r -d -l -s orig-ivtv-i2c.o.sav | less
 [...]
  07e0  69767476 20696e74 65726e61  ivtv interna
  07f0 6c00     l...
  0800      
  0810      
  0820      
  0830      
 [...]
 init_ivtv_i2c():
 /home/andy/cx18dev/git/media_tree/drivers/media/video/ivtv/ivtv-i2c.c:738
 13bb:   48 8d bb 30 04 01 00lea0x10430(%rbx),%rdi
 13c2:   48 c7 c6 00 00 00 00mov$0x0,%rsi
 13c5: R_X86_64_32S  .rodata+0x7e0
 13c9:   b9 5a 00 00 00  mov$0x5a,%ecx
 13ce:   f3 48 a5rep movsq %ds:(%rsi),%es:(%rdi)


 The generated code is reordered, but essentially identical.  So I guess
 in this instance, the preprocessor defines resolved such that an x86-64
 optimized memcpy() function was not used from the linux kernel source.

 Since all of these memcpy()'s are only called once for each board at
 board initialization, performance here really doesn't matter here
 anyway.  (Unless one is insanely trying to shave microseconds off boot
 time :P )

 With other memcpy()/assignement_operator replacement patches, you may
 wish to keep performance in mind, if you are patching a frequently
 called function.


Thanks for your thorough review on generated assembly.
It's certainly very helpful.

However, IMHO, this kind of 

Re: [PATCH 04/23] sn9c102: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.

 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.

 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)

 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl

 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/usb/sn9c102/sn9c102_core.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/usb/sn9c102/sn9c102_core.c 
 b/drivers/media/usb/sn9c102/sn9c102_core.c
 index 5bfc8e2..4cae6f8 100644
 --- a/drivers/media/usb/sn9c102/sn9c102_core.c
 +++ b/drivers/media/usb/sn9c102/sn9c102_core.c
 @@ -2824,7 +2824,7 @@ sn9c102_vidioc_querybuf(struct sn9c102_device* cam, 
 void __user * arg)
 b.index = cam-nbuffers || cam-io != IO_MMAP)
 return -EINVAL;

 -   memcpy(b, cam-frame[b.index].buf, sizeof(b));
 +   b = cam-frame[b.index].buf;

 if (cam-frame[b.index].vma_use_count)
 b.flags |= V4L2_BUF_FLAG_MAPPED;
 @@ -2927,7 +2927,7 @@ sn9c102_vidioc_dqbuf(struct sn9c102_device* cam, struct 
 file* filp,

 f-state = F_UNUSED;

 -   memcpy(b, f-buf, sizeof(b));
 +   b = f-buf;
 if (f-vma_use_count)
 b.flags |= V4L2_BUF_FLAG_MAPPED;


Andy: you got me thinking on performance.
Most patches are initialization or setup code.

Here we patch a xxx_vidioc_dqbuf() function.
Is this a speed sensitive path?

I still think this change can't hurt performance,
but I may be wrong!


Ezequiel
--
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 17/23] cx23885: Replace memcpy with struct assignment

2012-10-23 Thread Ezequiel Garcia
(CCed Steven Toth and Devin Heitmueller)

On Tue, Oct 23, 2012 at 7:16 PM, Andy Walls awa...@md.metrocast.net wrote:
 On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.

 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.

 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)

 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl

 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com

 This patch looks OK to me.  You forgot to CC: Steven Toth and/or Devin
 Heitmueller (I can't remember who did the VBI work.)

Done, thank you.

Ezequiel
--
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] stk1160: Try to continue with fewer transfer buffers

2012-10-23 Thread Ezequiel Garcia
Many people are trying to use stk1160 on low memory devices.
Instead of failing if one allocation fails, we allow the driver
to continue working if fewer transfer buffers are available.

Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/usb/stk1160/stk1160-video.c |   23 +--
 drivers/media/usb/stk1160/stk1160.h   |5 +++--
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/stk1160/stk1160-video.c 
b/drivers/media/usb/stk1160/stk1160-video.c
index 8bdfb02..e620be0 100644
--- a/drivers/media/usb/stk1160/stk1160-video.c
+++ b/drivers/media/usb/stk1160/stk1160-video.c
@@ -475,7 +475,11 @@ int stk1160_alloc_isoc(struct stk1160 *dev)
if (!dev-isoc_ctl.transfer_buffer[i]) {
stk1160_err(cannot alloc %d bytes for tx[%d] buffer\n,
sb_size, i);
-   goto free_i_bufs;
+
+   /* Not enough transfer buffers, so just give up */
+   if (i  STK1160_MIN_BUFS)
+   goto free_i_bufs;
+   goto nomore_tx_bufs;
}
memset(dev-isoc_ctl.transfer_buffer[i], 0, sb_size);
 
@@ -506,13 +510,28 @@ int stk1160_alloc_isoc(struct stk1160 *dev)
}
}
 
-   stk1160_dbg(urbs allocated\n);
+   stk1160_dbg(%d urbs allocated\n, num_bufs);
 
/* At last we can say we have some buffers */
dev-isoc_ctl.num_bufs = num_bufs;
 
return 0;
 
+nomore_tx_bufs:
+   /*
+* Failed to allocate desired buffer count. However, we may have
+* enough to work fine, so we just free the extra urb,
+* store the allocated count and keep going, fingers crossed!
+*/
+   usb_free_urb(dev-isoc_ctl.urb[i]);
+   dev-isoc_ctl.urb[i] = NULL;
+
+   stk1160_warn(%d urbs allocated. Trying to continue...\n, i-1);
+
+   dev-isoc_ctl.num_bufs = i-1;
+
+   return 0;
+
 free_i_bufs:
/* Save the allocated buffers so far, so we can properly free them */
dev-isoc_ctl.num_bufs = i+1;
diff --git a/drivers/media/usb/stk1160/stk1160.h 
b/drivers/media/usb/stk1160/stk1160.h
index 68c8707..05b05b1 100644
--- a/drivers/media/usb/stk1160/stk1160.h
+++ b/drivers/media/usb/stk1160/stk1160.h
@@ -30,11 +30,12 @@
 #define STK1160_VERSION0.9.5
 #define STK1160_VERSION_NUM0x000905
 
-/* TODO: Decide on number of packets for each buffer */
+/* Decide on number of packets for each buffer */
 #define STK1160_NUM_PACKETS 64
 
 /* Number of buffers for isoc transfers */
-#define STK1160_NUM_BUFS 16 /* TODO */
+#define STK1160_NUM_BUFS 16
+#define STK1160_MIN_BUFS 1
 
 /* TODO: This endpoint address should be retrieved */
 #define STK1160_EP_VIDEO 0x82
-- 
1.7.8.6

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