Re: Firmware for cx23885 in linux-firmware.git is broken

2013-02-25 Thread Mauro Carvalho Chehab
Em Sun, 24 Feb 2013 20:37:07 -0800
Sri Deevi srinivasa.de...@conexant.com escreveu:

 Mauro and All,
 
 Apologies for delay in reply.
 
 Whatever firmware works keep that one as reference. If you guys think the 
 firmware from Hauppauge is latest, please keep that and I can get the 
 required permissions as needed. 
 
 Please do let me know whatever is the plan. Currently, there are no updates 
 to this firmware as I know.

David merged yesterday at linux-firmware a patch from Ben that removes this
firmware from the tree:

  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-enc.fw
  a9f8f5d901a7fb42f552e1ee6384f3bb  v4l-cx23885-enc.fw

As this firmware is known to not work with the Hauppauge devices.

The better would be if you could give us permission to redistribute,
instead, the firmware found on Hauppauge's site (Windows driver only
version there):
http://www.hauppauge.com/site/support/support_hvr1500.html
With points to:
http://hauppauge.lightpath.net/software/drivers/85drv_29272.zip

The firmware there is this one:
-rw-rw-r-- 1 mchehab mchehab 376836 Mar 17  2006 
85drv_29272/Driver85/hcw85enc.rom
1cb3c48a6684126f5e503a434f2d636b  85drv_29272/Driver85/hcw85enc.rom

With matches with the one it is known to work with this hardware:

  -r--r--r--   1 v4l v4l  376836 Fev 24 08:47 v4l-cx23885-enc.fw
  1cb3c48a6684126f5e503a434f2d636b  v4l-cx23885-enc.fw

That would fix the main firmware issue.

Regards,
Mauro


 
 Thanks
 Sri
 
 -Original Message-
 From: Joseph Yasi [mailto:joe.y...@gmail.com] 
 Sent: Sunday, February 24, 2013 8:36 AM
 To: Mauro Carvalho Chehab
 Cc: Ben Hutchings; linux-media@vger.kernel.org; David Woodhouse; Palash 
 Bandyopadhyay; Sri Deevi; Michael Krufky; Andy Walls; Hans Verkuil
 Subject: Re: Firmware for cx23885 in linux-firmware.git is broken
 
 On Sun, Feb 24, 2013 at 7:22 AM, Mauro Carvalho Chehab mche...@redhat.com 
 wrote:
  Em Sun, 24 Feb 2013 03:16:35 +
  Ben Hutchings b...@decadent.org.uk escreveu:
 
  On Fri, 2013-02-22 at 19:30 -0500, Joseph Yasi wrote:
   Hi,
  
   I'm not sure the appropriate list to email for this, but the 
   v4l-cx23885-enc.fw file in the linux-firmware.git tree is incorrect.
   It is the wrong size and just a duplicate of the 
   v4l-cx23885-avcore-01.fw. The correct file can be extracted from 
   the
   HVR1800 drivers here: http://steventoth.net/linux/hvr1800/.
 
  This was previously requested
  http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/57816
   but unfortunately it's not clear that it would be legal to redistribute 
  firmware extracted from that driver (or the driver itself).
 
  (c/c Conexant developers, Andy and Hans)
 
  Let's see if we can once for all fix this issue. So, let me do a 
  summary of the firmware situation here.
 
  Basically, the firmwares at linux-kernel are the ones that Conexant 
  gave us license to re-distribute.
 
  According with Conexant, there's one firmware that it is the same for 
  two different chips. On their words:
 
  The Merlin firmware are the same for 418 and 416/7.
 
  The envolved Conexant firmwares are the ones used by cx23885-417.c, 
  cx231xx-417.c and cx25850.c:
 
  $ git grep v4l-cx23885-enc.fw drivers/media 
  drivers/media/pci/cx23885/cx23885-417.c:#define CX23885_FIRM_IMAGE_NAME 
  v4l-cx23885-enc.fw
  drivers/media/usb/cx231xx/cx231xx-417.c:#define CX231xx_FIRM_IMAGE_NAME 
  v4l-cx23885-enc.fw
 
  $ grep define.*FIRM drivers/media/i2c/cx25840/cx25840-firmware.c
  #define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw
  #define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw
  #define CX25840_FIRMWARE v4l-cx25840.fw
 
  Those are the Conexant firmware files that we currently have at
  linux-firmware:
 
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx231xx-avcore-01.fw
  -rw-rw-r-- 1 v4l v4l 141200 Ago 10  2012 v4l-cx23418-apu.fw
  -rw-rw-r-- 1 v4l v4l 158332 Ago 10  2012 v4l-cx23418-cpu.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23418-dig.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-avcore-01.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-enc.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx25840.fw
 
  And those are their corresponding md5sum:
 
  7d3bb956dc9df0eafded2b56ba57cc42  v4l-cx231xx-avcore-01.fw 
  588f081b562f5c653a3db1ad8f65939a  v4l-cx23418-apu.fw
  b6c7ed64bc44b1a6e0840adaeac39d79  v4l-cx23418-cpu.fw
  95bc688d3e7599fd5800161e9971cc55  v4l-cx23418-dig.fw 
  a9f8f5d901a7fb42f552e1ee6384f3bb  v4l-cx23885-avcore-01.fw 
  a9f8f5d901a7fb42f552e1ee6384f3bb  v4l-cx23885-enc.fw
  dadb79e9904fc8af96e8111d9cb59320  v4l-cx25840.fw
 
  So, yes, v4l-cx23885-avcore-01.fw and v4l-cx23885-enc.fw files are 
  identical on the official released firmwares, and both have 16K.
 
  Now, Hauppauge is using different firmwares for v4l-cx23885-enc.fw and 
  v4l-cx23885-avcore-01.fw. After extracting the firmware from their zip 
  file, we have:
 
  -r--r--r--   1 v4l v4l  376836 Fev 24 08:47 

[GIT PULL FOR v3.10] ISA radio fixes

2013-02-25 Thread Hans Verkuil
Hi Mauro,

These are two small fixes for 3.10:

- capabilities were mixed up in radio-isa
- fixed a mute bug in radio-rtrack2: I got hold of a radio-rtrack2 card so
  I could finally test this driver with real hardware.

Thanks to Steve Toth for helping me obtain this card!

Regards,

Hans

The following changes since commit ed72d37a33fdf43dc47787fe220532cdec9da528:

  [media] media: Add 0x3009 USB PID to ttusb2 driver (fixed diff) (2013-02-13 
18:05:29 -0200)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git radio-isa

for you to fetch changes up to 54a2b5393931a4b794b9505158a158585822e3cf:

  radio-rtrack2: fix mute bug. (2013-02-25 12:00:15 +0100)


Hans Verkuil (2):
  radio-isa: fix querycap capabilities code.
  radio-rtrack2: fix mute bug.

 drivers/media/radio/radio-isa.c |4 ++--
 drivers/media/radio/radio-rtrack2.c |5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)
--
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


HAUPPAUGE HVR-930C analog tv feasible ??

2013-02-25 Thread jandegr1
Hi,

To get analog tv working on a hauppauge hvr-930c, I started sniffing usb and
parsing.

you can see a sample here : https://dl.dropbox.com/u/93775123/grphCable22.txt

Howeverver I am missing a lot of knowledge to jump on it right away, so I'd
as for opinion of the experts over here first.

This could be benifical for several other cards with the avf4910 as well.

thx,

Jan De Graeve

--
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] af9015: do not use buffers from stack for usb_bulk_msg()

2013-02-25 Thread Mauro Carvalho Chehab
Em Mon, 25 Feb 2013 01:39:41 +0200
Antti Palosaari cr...@iki.fi escreveu:

 WARNING: at lib/dma-debug.c:947 check_for_stack+0xa7/0xf0()
 ehci-pci :00:04.1: DMA-API: device driver maps memory fromstack
 
 Reported-by: poma pomidorabelis...@gmail.com
 Signed-off-by: Antti Palosaari cr...@iki.fi
 ---
  drivers/media/usb/dvb-usb-v2/af9015.c | 34 --
  drivers/media/usb/dvb-usb-v2/af9015.h |  2 ++
  2 files changed, 18 insertions(+), 18 deletions(-)
 
 diff --git a/drivers/media/usb/dvb-usb-v2/af9015.c 
 b/drivers/media/usb/dvb-usb-v2/af9015.c
 index b86d0f2..28983aa 100644
 --- a/drivers/media/usb/dvb-usb-v2/af9015.c
 +++ b/drivers/media/usb/dvb-usb-v2/af9015.c
 @@ -30,22 +30,20 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
  
  static int af9015_ctrl_msg(struct dvb_usb_device *d, struct req_t *req)
  {
 -#define BUF_LEN 63
  #define REQ_HDR_LEN 8 /* send header size */
  #define ACK_HDR_LEN 2 /* rece header size */
   struct af9015_state *state = d_to_priv(d);
   int ret, wlen, rlen;
 - u8 buf[BUF_LEN];
   u8 write = 1;
  
 - buf[0] = req-cmd;
 - buf[1] = state-seq++;
 - buf[2] = req-i2c_addr;
 - buf[3] = req-addr  8;
 - buf[4] = req-addr  0xff;
 - buf[5] = req-mbox;
 - buf[6] = req-addr_len;
 - buf[7] = req-data_len;
 + state-buf[0] = req-cmd;
 + state-buf[1] = state-seq++;
 + state-buf[2] = req-i2c_addr;
 + state-buf[3] = req-addr  8;
 + state-buf[4] = req-addr  0xff;
 + state-buf[5] = req-mbox;
 + state-buf[6] = req-addr_len;
 + state-buf[7] = req-data_len;
  
   switch (req-cmd) {
   case GET_CONFIG:
 @@ -55,14 +53,14 @@ static int af9015_ctrl_msg(struct dvb_usb_device *d, 
 struct req_t *req)
   break;
   case READ_I2C:
   write = 0;
 - buf[2] |= 0x01; /* set I2C direction */
 + state-buf[2] |= 0x01; /* set I2C direction */
   case WRITE_I2C:
 - buf[0] = READ_WRITE_I2C;
 + state-buf[0] = READ_WRITE_I2C;
   break;
   case WRITE_MEMORY:
   if (((req-addr  0xff00) == 0xff00) ||
   ((req-addr  0xff00) == 0xae00))
 - buf[0] = WRITE_VIRTUAL_MEMORY;
 + state-buf[0] = WRITE_VIRTUAL_MEMORY;
   case WRITE_VIRTUAL_MEMORY:
   case COPY_FIRMWARE:
   case DOWNLOAD_FIRMWARE:
 @@ -90,7 +88,7 @@ static int af9015_ctrl_msg(struct dvb_usb_device *d, struct 
 req_t *req)
   rlen = ACK_HDR_LEN;
   if (write) {
   wlen += req-data_len;
 - memcpy(buf[REQ_HDR_LEN], req-data, req-data_len);
 + memcpy(state-buf[REQ_HDR_LEN], req-data, req-data_len);
   } else {
   rlen += req-data_len;
   }
 @@ -99,21 +97,21 @@ static int af9015_ctrl_msg(struct dvb_usb_device *d, 
 struct req_t *req)
   if (req-cmd == DOWNLOAD_FIRMWARE || req-cmd == RECONNECT_USB)
   rlen = 0;
  
 - ret = dvb_usbv2_generic_rw(d, buf, wlen, buf, rlen);
 + ret = dvb_usbv2_generic_rw(d, state-buf, wlen, state-buf, rlen);
   if (ret)
   goto error;
  
   /* check status */
 - if (rlen  buf[1]) {
 + if (rlen  state-buf[1]) {
   dev_err(d-udev-dev, %s: command failed=%d\n,
 - KBUILD_MODNAME, buf[1]);
 + KBUILD_MODNAME, state-buf[1]);
   ret = -EIO;
   goto error;
   }
  
   /* read request, copy returned data to return buf */
   if (!write)
 - memcpy(req-data, buf[ACK_HDR_LEN], req-data_len);
 + memcpy(req-data, state-buf[ACK_HDR_LEN], req-data_len);

Now that you're using just one buffer here, you'll need to protect this
routine with a mutex, as af9015_rc_query() may be called by a kthread 
while af9015_ctrl_msg() is running. As the RC polling code will also call
af9015_ctrl_msg() and both will be filling the very same state-buf, a
race condition happens.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: HAUPPAUGE HVR-930C analog tv feasible ??

2013-02-25 Thread Mauro Carvalho Chehab
Em Mon, 25 Feb 2013 12:01:17 +0100
jande...@dommel.be escreveu:

 Hi,
 
 To get analog tv working on a hauppauge hvr-930c, I started sniffing usb and
 parsing.
 
 you can see a sample here : https://dl.dropbox.com/u/93775123/grphCable22.txt
 
 Howeverver I am missing a lot of knowledge to jump on it right away, so I'd
 as for opinion of the experts over here first.

AFAIKT, the designs with avf4910b also has a drx-k demod on it (or maybe some
other Micronas demod, like drx-j).

When I added support for Terratec H7, I used a Linux driver made available by
Terratec at that time, as reference. See:
http://lwn.net/Articles/476992/

While I don't see the link for the driver anymore on Terratec linux site,
it seems that the file is still there at:

http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz

While H7 driver there only adds support for digital TV, you may find
something useful at drxk driver, as it has several stuff there related
to analog TV. I won't doubt that the needed bits for avf4910 are (at least
partially) there. So, you may find useful to take a look on it.

To be frank, while I would love to have analog working there, I never
found enough time to work on adding analog support for it, nor I succeeded
to get any avf4910b datasheet or development kit.

 
 This could be benifical for several other cards with the avf4910 as well.

Sure. I suspect that, once having it work for one device, it should be
trivial to make it work with the others.

 
 thx,
 
 Jan De Graeve
 
 --
 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


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 3.7/3.8 kernel won't boot with Hauppauge pvr-150

2013-02-25 Thread Mauro Carvalho Chehab
Em Fri, 22 Feb 2013 07:51:58 -0800
Hans Verkuil hverk...@xs4all.nl escreveu:

 On Friday, February 22, 2013 07:17:42 Andy Walls wrote:
  On Thu, 2013-02-21 at 22:32 -0500, Andy Walls wrote:
   Ron Andreasen dlano...@gmail.com wrote:
   
   I've been having trouble getting distros that have any kernel above the
   3.5
   series to boot (only tried 64-bit). I get a black screen with a bunch
   of
   text and the boot process goes no further. I don't know if this is
   usually
   okay, but I'm posting a link to a picture I took of my monitor with my
   cell
   phone. It's a bit blurry but hopefully it's still okay:
   
   http://imgur.com/viP1kWk,3YJXKbG
   
   The distros I've had this problem in are Kubuntu (I've tried several of
   the
   daily builds) which uses the 3.8.? (can't boot far enough to see)
   kernel,
   Cinnarch which uses the 3.7.3 kernel, and openSUSE 12.3 and I don't
   remember what version of the kernel that one used.
 
 Please note that any 3.8 kernel is terminally broken with ivtv/cx18 and will
 crash during boot as long as this patch is not applied:
 
 http://git.linuxtv.org/media_tree.git/commit/cfb046cb800ba306b211fbbe4ac633486e11055f
 
 It can be worked around by renaming ivtv-alsa.ko, as Andy mentioned.
 
 I hope to get this patch into the 3.8 stable series as soon as possible.
 I have to wait until it is merged into mainline first, though.

The patch got merged upstream yesterday:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=cfb046cb800ba306b211fbbe4ac633486e11055f

As it was tagged with:
 Cc: sta...@vger.kernel.org # for 3.8

I expect that it will be available for 3.8.1 after the end of the
merge window.

Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Firmware for cx23885 in linux-firmware.git is broken

2013-02-25 Thread Sri Deevi
Mauro,

Are you asking Hauppauge's version of ROM to be distributed with permissions ? 
Please clarify. 

If that is the case, I may not be able to do that. 

Michael,

If you can give me the details of when was the last time you got updates from 
Conexant, then I can try to help in this regard.

Thanks
Sri

-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] 
Sent: Monday, February 25, 2013 1:07 AM
To: Sri Deevi
Cc: Joseph Yasi; Ben Hutchings; linux-media@vger.kernel.org; David Woodhouse; 
Palash Bandyopadhyay; Michael Krufky; Andy Walls; Hans Verkuil
Subject: Re: Firmware for cx23885 in linux-firmware.git is broken

Em Sun, 24 Feb 2013 20:37:07 -0800
Sri Deevi srinivasa.de...@conexant.com escreveu:

 Mauro and All,
 
 Apologies for delay in reply.
 
 Whatever firmware works keep that one as reference. If you guys think the 
 firmware from Hauppauge is latest, please keep that and I can get the 
 required permissions as needed. 
 
 Please do let me know whatever is the plan. Currently, there are no updates 
 to this firmware as I know.

David merged yesterday at linux-firmware a patch from Ben that removes this 
firmware from the tree:

  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-enc.fw 
  a9f8f5d901a7fb42f552e1ee6384f3bb  v4l-cx23885-enc.fw

As this firmware is known to not work with the Hauppauge devices.

The better would be if you could give us permission to redistribute, instead, 
the firmware found on Hauppauge's site (Windows driver only version there):
http://www.hauppauge.com/site/support/support_hvr1500.html
With points to:
http://hauppauge.lightpath.net/software/drivers/85drv_29272.zip

The firmware there is this one:
-rw-rw-r-- 1 mchehab mchehab 376836 Mar 17  2006 
85drv_29272/Driver85/hcw85enc.rom
1cb3c48a6684126f5e503a434f2d636b  85drv_29272/Driver85/hcw85enc.rom

With matches with the one it is known to work with this hardware:

  -r--r--r--   1 v4l v4l  376836 Fev 24 08:47 v4l-cx23885-enc.fw
  1cb3c48a6684126f5e503a434f2d636b  v4l-cx23885-enc.fw

That would fix the main firmware issue.

Regards,
Mauro


 
 Thanks
 Sri
 
 -Original Message-
 From: Joseph Yasi [mailto:joe.y...@gmail.com]
 Sent: Sunday, February 24, 2013 8:36 AM
 To: Mauro Carvalho Chehab
 Cc: Ben Hutchings; linux-media@vger.kernel.org; David Woodhouse; 
 Palash Bandyopadhyay; Sri Deevi; Michael Krufky; Andy Walls; Hans 
 Verkuil
 Subject: Re: Firmware for cx23885 in linux-firmware.git is broken
 
 On Sun, Feb 24, 2013 at 7:22 AM, Mauro Carvalho Chehab mche...@redhat.com 
 wrote:
  Em Sun, 24 Feb 2013 03:16:35 +
  Ben Hutchings b...@decadent.org.uk escreveu:
 
  On Fri, 2013-02-22 at 19:30 -0500, Joseph Yasi wrote:
   Hi,
  
   I'm not sure the appropriate list to email for this, but the 
   v4l-cx23885-enc.fw file in the linux-firmware.git tree is incorrect.
   It is the wrong size and just a duplicate of the 
   v4l-cx23885-avcore-01.fw. The correct file can be extracted from 
   the
   HVR1800 drivers here: http://steventoth.net/linux/hvr1800/.
 
  This was previously requested
  http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/57816
   but unfortunately it's not clear that it would be legal to redistribute 
  firmware extracted from that driver (or the driver itself).
 
  (c/c Conexant developers, Andy and Hans)
 
  Let's see if we can once for all fix this issue. So, let me do a 
  summary of the firmware situation here.
 
  Basically, the firmwares at linux-kernel are the ones that Conexant 
  gave us license to re-distribute.
 
  According with Conexant, there's one firmware that it is the same 
  for two different chips. On their words:
 
  The Merlin firmware are the same for 418 and 416/7.
 
  The envolved Conexant firmwares are the ones used by cx23885-417.c, 
  cx231xx-417.c and cx25850.c:
 
  $ git grep v4l-cx23885-enc.fw drivers/media 
  drivers/media/pci/cx23885/cx23885-417.c:#define CX23885_FIRM_IMAGE_NAME 
  v4l-cx23885-enc.fw
  drivers/media/usb/cx231xx/cx231xx-417.c:#define CX231xx_FIRM_IMAGE_NAME 
  v4l-cx23885-enc.fw
 
  $ grep define.*FIRM drivers/media/i2c/cx25840/cx25840-firmware.c
  #define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw
  #define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw
  #define CX25840_FIRMWARE v4l-cx25840.fw
 
  Those are the Conexant firmware files that we currently have at
  linux-firmware:
 
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx231xx-avcore-01.fw
  -rw-rw-r-- 1 v4l v4l 141200 Ago 10  2012 v4l-cx23418-apu.fw
  -rw-rw-r-- 1 v4l v4l 158332 Ago 10  2012 v4l-cx23418-cpu.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23418-dig.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-avcore-01.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-enc.fw
  -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx25840.fw
 
  And those are their corresponding md5sum:
 
  7d3bb956dc9df0eafded2b56ba57cc42  v4l-cx231xx-avcore-01.fw 
  588f081b562f5c653a3db1ad8f65939a 

Re: [PATCH] Media: remove incorrect __exit markups

2013-02-25 Thread Dmitry Torokhov
On Mon, Feb 25, 2013 at 08:49:26AM +0100, Guennadi Liakhovetski wrote:
 Hi Dmitry
 
 On Sun, 24 Feb 2013, Dmitry Torokhov wrote:
 
  Even if bus is not hot-pluggable, the devices can be unbound from the
  driver via sysfs, so we should not be using __exit annotations on
  remove() methods. The only exception is drivers registered with
  platform_driver_probe() which specifically disables sysfs bind/unbind
  attributes.
  
  Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
  ---
   drivers/media/i2c/adp1653.c  | 4 ++--
   drivers/media/i2c/smiapp/smiapp-core.c   | 4 ++--
   drivers/media/platform/soc_camera/omap1_camera.c | 4 ++--
   drivers/media/radio/radio-si4713.c   | 4 ++--
   drivers/media/rc/ir-rx51.c   | 4 ++--
   5 files changed, 10 insertions(+), 10 deletions(-)
 
 [snip]
 
  diff --git a/drivers/media/platform/soc_camera/omap1_camera.c 
  b/drivers/media/platform/soc_camera/omap1_camera.c
  index 39a77f0..5f548ac 100644
  --- a/drivers/media/platform/soc_camera/omap1_camera.c
  +++ b/drivers/media/platform/soc_camera/omap1_camera.c
  @@ -1677,7 +1677,7 @@ exit:
  return err;
   }
   
  -static int __exit omap1_cam_remove(struct platform_device *pdev)
  +static int omap1_cam_remove(struct platform_device *pdev)
   {
  struct soc_camera_host *soc_host = to_soc_camera_host(pdev-dev);
  struct omap1_cam_dev *pcdev = container_of(soc_host,
  @@ -1709,7 +1709,7 @@ static struct platform_driver omap1_cam_driver = {
  .name   = DRIVER_NAME,
  },
  .probe  = omap1_cam_probe,
  -   .remove = __exit_p(omap1_cam_remove),
  +   .remove = omap1_cam_remove,
   };
   
   module_platform_driver(omap1_cam_driver);
 
 This looks correct, but don't we also have to remove __init from 
 omap1_cam_probe()? Or would that be a separate patch?

Thanks Guennadi, I missed that one, will update the patch.

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


Please update DVB-T frequency list 'dvb-t/nl-All'

2013-02-25 Thread Geert Hedde Bosman

Hello,
in summer 2012 in the Netherlands major frequency changes took place in 
DVB-t broadcast. Some new frequencies were added as well. Therefore the 
frequency-file dvb/dvb-t/nl-All is no longer actual. Could someone (i 
believe Cristoph P. is one of the maintainers) please update this file? 
The website http://radio-tv-nederland.nl/ provides an up to date 
frequency list.
As an example: i had to add the following line to the file 'nl-All' to 
get the FTA tv-stations in the north of the Netherlands as it was missing:

T 67400 8MHz 1/2 NONE QAM64 8k 1/4 NONE

regards
GHB

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

2013-02-25 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:   Mon Feb 25 19:00:28 CET 2013
git branch: for_v3.9
git hash:   ed72d37a33fdf43dc47787fe220532cdec9da528
gcc version:i686-linux-gcc (GCC) 4.7.2
host hardware:  x86_64
host os:3.8.03-marune

linux-git-arm-davinci: WARNINGS
linux-git-arm-exynos: ERRORS
linux-git-arm-omap: WARNINGS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.31.14-i686: WARNINGS
linux-2.6.32.27-i686: WARNINGS
linux-2.6.33.7-i686: WARNINGS
linux-2.6.34.7-i686: WARNINGS
linux-2.6.35.9-i686: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: OK
linux-2.6.31.14-x86_64: WARNINGS
linux-2.6.32.27-x86_64: WARNINGS
linux-2.6.33.7-x86_64: WARNINGS
linux-2.6.34.7-x86_64: WARNINGS
linux-2.6.35.9-x86_64: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Firmware for cx23885 in linux-firmware.git is broken

2013-02-25 Thread Mauro Carvalho Chehab
Em Mon, 25 Feb 2013 08:17:34 -0800
Sri Deevi srinivasa.de...@conexant.com escreveu:

 Mauro,
 
 Are you asking Hauppauge's version of ROM to be distributed with permissions 
 ? 
 Please clarify. 
 
 If that is the case, I may not be able to do that. 

I've no idea if Hauppauge customized it, or if they just bundled a Conexant
version of it. I suspect it was the last case, but maybe Michael or Steven
may have or check with someone else about the origin of that firmware
(85drv_29272/Driver85/hcw85enc.rom).

Regards,
Mauro

 
 Michael,
 
 If you can give me the details of when was the last time you got updates from 
 Conexant, then I can try to help in this regard.
 
 Thanks
 Sri
 
 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] 
 Sent: Monday, February 25, 2013 1:07 AM
 To: Sri Deevi
 Cc: Joseph Yasi; Ben Hutchings; linux-media@vger.kernel.org; David Woodhouse; 
 Palash Bandyopadhyay; Michael Krufky; Andy Walls; Hans Verkuil
 Subject: Re: Firmware for cx23885 in linux-firmware.git is broken
 
 Em Sun, 24 Feb 2013 20:37:07 -0800
 Sri Deevi srinivasa.de...@conexant.com escreveu:
 
  Mauro and All,
  
  Apologies for delay in reply.
  
  Whatever firmware works keep that one as reference. If you guys think the 
  firmware from Hauppauge is latest, please keep that and I can get the 
  required permissions as needed. 
  
  Please do let me know whatever is the plan. Currently, there are no updates 
  to this firmware as I know.
 
 David merged yesterday at linux-firmware a patch from Ben that removes this 
 firmware from the tree:
 
   -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-enc.fw 
   a9f8f5d901a7fb42f552e1ee6384f3bb  v4l-cx23885-enc.fw
 
 As this firmware is known to not work with the Hauppauge devices.
 
 The better would be if you could give us permission to redistribute, instead, 
 the firmware found on Hauppauge's site (Windows driver only version there):
   http://www.hauppauge.com/site/support/support_hvr1500.html
 With points to:
   http://hauppauge.lightpath.net/software/drivers/85drv_29272.zip
 
 The firmware there is this one:
   -rw-rw-r-- 1 mchehab mchehab 376836 Mar 17  2006 
 85drv_29272/Driver85/hcw85enc.rom
   1cb3c48a6684126f5e503a434f2d636b  85drv_29272/Driver85/hcw85enc.rom
 
 With matches with the one it is known to work with this hardware:
 
   -r--r--r--   1 v4l v4l  376836 Fev 24 08:47 v4l-cx23885-enc.fw
   1cb3c48a6684126f5e503a434f2d636b  v4l-cx23885-enc.fw
 
 That would fix the main firmware issue.
 
 Regards,
 Mauro
 
 
  
  Thanks
  Sri
  
  -Original Message-
  From: Joseph Yasi [mailto:joe.y...@gmail.com]
  Sent: Sunday, February 24, 2013 8:36 AM
  To: Mauro Carvalho Chehab
  Cc: Ben Hutchings; linux-media@vger.kernel.org; David Woodhouse; 
  Palash Bandyopadhyay; Sri Deevi; Michael Krufky; Andy Walls; Hans 
  Verkuil
  Subject: Re: Firmware for cx23885 in linux-firmware.git is broken
  
  On Sun, Feb 24, 2013 at 7:22 AM, Mauro Carvalho Chehab mche...@redhat.com 
  wrote:
   Em Sun, 24 Feb 2013 03:16:35 +
   Ben Hutchings b...@decadent.org.uk escreveu:
  
   On Fri, 2013-02-22 at 19:30 -0500, Joseph Yasi wrote:
Hi,
   
I'm not sure the appropriate list to email for this, but the 
v4l-cx23885-enc.fw file in the linux-firmware.git tree is incorrect.
It is the wrong size and just a duplicate of the 
v4l-cx23885-avcore-01.fw. The correct file can be extracted from 
the
HVR1800 drivers here: http://steventoth.net/linux/hvr1800/.
  
   This was previously requested
   http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/57816
but unfortunately it's not clear that it would be legal to redistribute 
   firmware extracted from that driver (or the driver itself).
  
   (c/c Conexant developers, Andy and Hans)
  
   Let's see if we can once for all fix this issue. So, let me do a 
   summary of the firmware situation here.
  
   Basically, the firmwares at linux-kernel are the ones that Conexant 
   gave us license to re-distribute.
  
   According with Conexant, there's one firmware that it is the same 
   for two different chips. On their words:
  
   The Merlin firmware are the same for 418 and 416/7.
  
   The envolved Conexant firmwares are the ones used by cx23885-417.c, 
   cx231xx-417.c and cx25850.c:
  
   $ git grep v4l-cx23885-enc.fw drivers/media 
   drivers/media/pci/cx23885/cx23885-417.c:#define CX23885_FIRM_IMAGE_NAME 
   v4l-cx23885-enc.fw
   drivers/media/usb/cx231xx/cx231xx-417.c:#define CX231xx_FIRM_IMAGE_NAME 
   v4l-cx23885-enc.fw
  
   $ grep define.*FIRM drivers/media/i2c/cx25840/cx25840-firmware.c
   #define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw
   #define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw
   #define CX25840_FIRMWARE v4l-cx25840.fw
  
   Those are the Conexant firmware files that we currently have at
   linux-firmware:
  
   -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx231xx-avcore-01.fw
   -rw-rw-r-- 1 v4l v4l 141200 

RE: Firmware for cx23885 in linux-firmware.git is broken

2013-02-25 Thread Sri Deevi
I am also checking with internal resources. Let me see what I can find out 
about the same.

Thanks
Sri

-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] 
Sent: Monday, February 25, 2013 2:21 PM
To: Sri Deevi
Cc: Joseph Yasi; Ben Hutchings; linux-media@vger.kernel.org; David Woodhouse; 
Palash Bandyopadhyay; Michael Krufky; Andy Walls; Hans Verkuil; Jay Guillory; 
Steven Toth
Subject: Re: Firmware for cx23885 in linux-firmware.git is broken

Em Mon, 25 Feb 2013 08:17:34 -0800
Sri Deevi srinivasa.de...@conexant.com escreveu:

 Mauro,
 
 Are you asking Hauppauge's version of ROM to be distributed with permissions 
 ? 
 Please clarify. 
 
 If that is the case, I may not be able to do that. 

I've no idea if Hauppauge customized it, or if they just bundled a Conexant 
version of it. I suspect it was the last case, but maybe Michael or Steven may 
have or check with someone else about the origin of that firmware 
(85drv_29272/Driver85/hcw85enc.rom).

Regards,
Mauro

 
 Michael,
 
 If you can give me the details of when was the last time you got updates from 
 Conexant, then I can try to help in this regard.
 
 Thanks
 Sri
 
 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
 Sent: Monday, February 25, 2013 1:07 AM
 To: Sri Deevi
 Cc: Joseph Yasi; Ben Hutchings; linux-media@vger.kernel.org; David 
 Woodhouse; Palash Bandyopadhyay; Michael Krufky; Andy Walls; Hans 
 Verkuil
 Subject: Re: Firmware for cx23885 in linux-firmware.git is broken
 
 Em Sun, 24 Feb 2013 20:37:07 -0800
 Sri Deevi srinivasa.de...@conexant.com escreveu:
 
  Mauro and All,
  
  Apologies for delay in reply.
  
  Whatever firmware works keep that one as reference. If you guys think the 
  firmware from Hauppauge is latest, please keep that and I can get the 
  required permissions as needed. 
  
  Please do let me know whatever is the plan. Currently, there are no updates 
  to this firmware as I know.
 
 David merged yesterday at linux-firmware a patch from Ben that removes this 
 firmware from the tree:
 
   -rw-rw-r-- 1 v4l v4l  16382 Ago 10  2012 v4l-cx23885-enc.fw 
   a9f8f5d901a7fb42f552e1ee6384f3bb  v4l-cx23885-enc.fw
 
 As this firmware is known to not work with the Hauppauge devices.
 
 The better would be if you could give us permission to redistribute, instead, 
 the firmware found on Hauppauge's site (Windows driver only version there):
   http://www.hauppauge.com/site/support/support_hvr1500.html
 With points to:
   http://hauppauge.lightpath.net/software/drivers/85drv_29272.zip
 
 The firmware there is this one:
   -rw-rw-r-- 1 mchehab mchehab 376836 Mar 17  2006 
 85drv_29272/Driver85/hcw85enc.rom
   1cb3c48a6684126f5e503a434f2d636b  85drv_29272/Driver85/hcw85enc.rom
 
 With matches with the one it is known to work with this hardware:
 
   -r--r--r--   1 v4l v4l  376836 Fev 24 08:47 v4l-cx23885-enc.fw
   1cb3c48a6684126f5e503a434f2d636b  v4l-cx23885-enc.fw
 
 That would fix the main firmware issue.
 
 Regards,
 Mauro
 
 
  
  Thanks
  Sri
  
  -Original Message-
  From: Joseph Yasi [mailto:joe.y...@gmail.com]
  Sent: Sunday, February 24, 2013 8:36 AM
  To: Mauro Carvalho Chehab
  Cc: Ben Hutchings; linux-media@vger.kernel.org; David Woodhouse; 
  Palash Bandyopadhyay; Sri Deevi; Michael Krufky; Andy Walls; Hans 
  Verkuil
  Subject: Re: Firmware for cx23885 in linux-firmware.git is broken
  
  On Sun, Feb 24, 2013 at 7:22 AM, Mauro Carvalho Chehab mche...@redhat.com 
  wrote:
   Em Sun, 24 Feb 2013 03:16:35 + Ben Hutchings 
   b...@decadent.org.uk escreveu:
  
   On Fri, 2013-02-22 at 19:30 -0500, Joseph Yasi wrote:
Hi,
   
I'm not sure the appropriate list to email for this, but the 
v4l-cx23885-enc.fw file in the linux-firmware.git tree is incorrect.
It is the wrong size and just a duplicate of the 
v4l-cx23885-avcore-01.fw. The correct file can be extracted 
from the
HVR1800 drivers here: http://steventoth.net/linux/hvr1800/.
  
   This was previously requested
   http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/57816
but unfortunately it's not clear that it would be legal to redistribute 
   firmware extracted from that driver (or the driver itself).
  
   (c/c Conexant developers, Andy and Hans)
  
   Let's see if we can once for all fix this issue. So, let me do a 
   summary of the firmware situation here.
  
   Basically, the firmwares at linux-kernel are the ones that 
   Conexant gave us license to re-distribute.
  
   According with Conexant, there's one firmware that it is the same 
   for two different chips. On their words:
  
   The Merlin firmware are the same for 418 and 416/7.
  
   The envolved Conexant firmwares are the ones used by 
   cx23885-417.c, cx231xx-417.c and cx25850.c:
  
   $ git grep v4l-cx23885-enc.fw drivers/media 
   drivers/media/pci/cx23885/cx23885-417.c:#define CX23885_FIRM_IMAGE_NAME 
   v4l-cx23885-enc.fw
   

[PATCH v5 3/8] mfd: Add the main bulk of core driver for SI476x code

2013-02-25 Thread Andrey Smirnov
From: Andrey Smirnov andreysm@charmander.(none)

This patch adds main part(out of three) of the I2C driver for the
core of MFD device.

Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com
---
 drivers/mfd/si476x-i2c.c |  878 ++
 1 file changed, 878 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..053a6a3
--- /dev/null
+++ b/drivers/mfd/si476x-i2c.c
@@ -0,0 +1,878 @@
+/*
+ * drivers/mfd/si476x-i2c.c -- Core device driver for si476x MFD
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ * Copyright (C) 2013 Andrey Smirnov
+ *
+ * Author: Andrey Smirnov andrew.smir...@gmail.com
+ *
+ * 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
+
+#define SI476X_MAX_IO_ERRORS   10
+#define SI476X_DRIVER_RDS_FIFO_DEPTH   128
+
+/**
+ * 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(SI476X_STATUS_POLL_US));
+}
+
+/**
+ * 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 chip and perform initial configuration. It does the
+ * following sequence of actions:
+ *   1. Claims and enables the power supplies VD and VIO1 required
+ *  

[PATCH v5 6/8] v4l2: Add documentation for the FM RX controls

2013-02-25 Thread Andrey Smirnov
Add appropriate documentation for all the newly added standard
controls.

Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com
---
 Documentation/DocBook/media/v4l/compat.xml |3 +
 Documentation/DocBook/media/v4l/controls.xml   |   72 
 .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml   |   11 ++-
 3 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index 104a1a2..f418bc3 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2310,6 +2310,9 @@ more information./para
listitem
  paraAdded FM Modulator (FM TX) Extended Control Class: 
constantV4L2_CTRL_CLASS_FM_TX/constant and their Control IDs./para
/listitem
+listitem
+ paraAdded FM Receiver (FM RX) Extended Control Class: 
constantV4L2_CTRL_CLASS_FM_RX/constant and their Control IDs./para
+   /listitem
listitem
  paraAdded Remote Controller chapter, describing the default Remote 
Controller mapping for media devices./para
/listitem
diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index 9e8f854..e8fe005 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4687,4 +4687,76 @@ interface and may change in the future./para
   /table
 
 /section
+
+section id=fm-rx-controls
+  titleFM Receiver Control Reference/title
+
+  paraThe FM Receiver (FM_RX) class includes controls for common 
features of
+  FM Reception capable devices./para
+
+  table pgwide=1 frame=none id=fm-rx-control-id
+  titleFM_RX Control IDs/title
+
+  tgroup cols=4
+colspec colname=c1 colwidth=1* /
+colspec colname=c2 colwidth=6* /
+colspec colname=c3 colwidth=2* /
+colspec colname=c4 colwidth=6* /
+spanspec namest=c1 nameend=c2 spanname=id /
+spanspec namest=c2 nameend=c4 spanname=descr /
+thead
+  row
+entry spanname=id align=leftID/entry
+entry align=leftType/entry
+  /rowrow rowsep=1entry spanname=descr 
align=leftDescription/entry
+  /row
+/thead
+tbody valign=top
+  rowentry/entry/row
+  row
+entry 
spanname=idconstantV4L2_CID_FM_RX_CLASS/constantnbsp;/entry
+entryclass/entry
+  /rowrowentry spanname=descrThe FM_RX class
+descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a
+description of this control class./entry
+  /row
+  row
+entry 
spanname=idconstantV4L2_CID_RDS_RECEPTION/constantnbsp;/entry
+entryboolean/entry
+  /rowrowentry spanname=descrEnables/disables RDS
+ reception by the radio tuner/entry
+  /row
+  row
+   entry 
spanname=idconstantV4L2_CID_TUNE_DEEMPHASIS/constantnbsp;/entry
+   entryinteger/entry
+ /row
+ row id=v4l2-deemphasisentry spanname=descrConfigures the 
de-emphasis value for reception.
+A de-emphasis filter is applied to the broadcast to accentuate the high audio 
frequencies.
+Depending on the region, a time constant of either 50 or 75 useconds is used. 
The enumnbsp;v4l2_emphasis
+defines possible values for de-emphasis. Here they are:/entry
+   /rowrow
+   entrytbl spanname=descr cols=2
+ tbody valign=top
+   row
+ 
entryconstantV4L2_PREEMPHASIS_DISABLED/constantnbsp;/entry
+ entryNo de-emphasis is applied./entry
+   /row
+   row
+ 
entryconstantV4L2_PREEMPHASIS_50_uS/constantnbsp;/entry
+ entryA de-emphasis of 50 uS is used./entry
+   /row
+   row
+ 
entryconstantV4L2_PREEMPHASIS_75_uS/constantnbsp;/entry
+ entryA de-emphasis of 75 uS is used./entry
+   /row
+ /tbody
+   /entrytbl
+
+ /row
+  rowentry/entry/row
+/tbody
+  /tgroup
+  /table
+
+  /section
 /section
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml 
b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
index 4e16112..b03a57b 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
@@ -9,7 +9,7 @@ VIDIOC_TRY_EXT_CTRLS/refentrytitle
 refnameVIDIOC_G_EXT_CTRLS/refname
 refnameVIDIOC_S_EXT_CTRLS/refname
 refnameVIDIOC_TRY_EXT_CTRLS/refname
-refpurposeGet or set the value of several controls, try control
+   refpurposeGet or set the value of several controls, try control
 values/refpurpose
   /refnamediv
 
@@ -319,6 +319,15 @@ These controls are described in xref
processing controls. These controls 

[PATCH v5 7/8] v4l2: Add private controls base for SI476X

2013-02-25 Thread Andrey Smirnov
Add a base to be used for allocation of all the SI476X specific
controls in the corresponding driver.

Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com
---
 include/uapi/linux/v4l2-controls.h |4 
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 296d20e..133703d 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -147,6 +147,10 @@ enum v4l2_colorfx {
  * of controls. We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_MEYE_BASE(V4L2_CID_USER_BASE + 
0x1000)
 
+/* The base for the si476x driver controls. See include/media/si476x.h for the 
list
+ * of controls. */
+#define V4L2_CID_USER_SI476X_BASE  (V4L2_CID_USER_BASE + 0x2000)
+
 /* MPEG-class control IDs */
 
 #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
-- 
1.7.10.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 v5 0/8] Driver for Si476x series of chips

2013-02-25 Thread Andrey Smirnov
This is a fourth 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

Third version of the patch was posted here:
https://lkml.org/lkml/2012/10/23/510

Fourth version of the patch was posted here:
https://lkml.org/lkml/2013/2/18/572

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.

v5 of this driver has following changes:
- Generic controls are converted to standard ones
- Custom controls use a differend offest as base
- Added documentation with controls description


Andrey Smirnov (8):
  mfd: Add header files and Kbuild plumbing for SI476x MFD core
  mfd: Add commands abstraction layer for SI476X MFD
  mfd: Add the main bulk of core driver for SI476x code
  mfd: Add chip properties handling code for SI476X MFD
  v4l2: Add standard controls for FM receivers
  v4l2: Add documentation for the FM RX controls
  v4l2: Add private controls base for SI476X
  v4l2: Add a V4L2 driver for SI476X MFD

 Documentation/DocBook/media/v4l/compat.xml |3 +
 Documentation/DocBook/media/v4l/controls.xml   |   72 +
 .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml   |   11 +-
 Documentation/video4linux/si476x.txt   |  187 +++
 drivers/media/radio/Kconfig|   17 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-si476x.c | 1581 
 drivers/media/v4l2-core/v4l2-ctrls.c   |   14 +-
 drivers/mfd/Kconfig|   13 +
 drivers/mfd/Makefile   |4 +
 drivers/mfd/si476x-cmd.c   | 1553 +++
 drivers/mfd/si476x-i2c.c   |  878 +++
 drivers/mfd/si476x-prop.c  |  234 +++
 include/linux/mfd/si476x-core.h|  525 +++
 include/media/si476x.h |  426 ++
 include/uapi/linux/v4l2-controls.h |   17 +-
 16 files changed, 5531 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/video4linux/si476x.txt
 create mode 100644 drivers/media/radio/radio-si476x.c
 create mode 100644 drivers/mfd/si476x-cmd.c
 create mode 100644 drivers/mfd/si476x-i2c.c
 create mode 100644 drivers/mfd/si476x-prop.c
 create mode 100644 include/linux/mfd/si476x-core.h
 create mode 100644 include/media/si476x.h

-- 
1.7.10.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 v5 5/8] v4l2: Add standard controls for FM receivers

2013-02-25 Thread Andrey Smirnov
This commit introduces new class of standard controls
V4L2_CTRL_CLASS_FM_RX. This class is intended to all controls
pertaining to FM receiver chips. Also, two controls belonging to said
class are added as a part of this commit: V4L2_CID_TUNE_DEEMPHASIS and
V4L2_CID_RDS_RECEPTION.

Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com
---
 drivers/media/v4l2-core/v4l2-ctrls.c |   14 +++---
 include/uapi/linux/v4l2-controls.h   |   13 -
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6b28b58..8b89fb8 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -297,8 +297,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Text,
NULL
};
-   static const char * const tune_preemphasis[] = {
-   No Preemphasis,
+   static const char * const tune_emphasis[] = {
+   None,
50 Microseconds,
75 Microseconds,
NULL,
@@ -508,7 +508,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
case V4L2_CID_SCENE_MODE:
return scene_mode;
case V4L2_CID_TUNE_PREEMPHASIS:
-   return tune_preemphasis;
+   return tune_emphasis;
+   case V4L2_CID_TUNE_DEEMPHASIS:
+   return tune_emphasis;
case V4L2_CID_FLASH_LED_MODE:
return flash_led_mode;
case V4L2_CID_FLASH_STROBE_SOURCE:
@@ -799,6 +801,9 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_DV_RX_POWER_PRESENT:  return Power Present;
case V4L2_CID_DV_RX_RGB_RANGE:  return Rx RGB Quantization 
Range;
 
+   case V4L2_CID_FM_RX_CLASS:  return FM Radio Receiver 
Controls;
+   case V4L2_CID_TUNE_DEEMPHASIS:  return De-Emphasis;
+   case V4L2_CID_RDS_RECEPTION:return RDS Reception;
default:
return NULL;
}
@@ -846,6 +851,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_MPEG4_QPEL:
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
+   case V4L2_CID_RDS_RECEPTION:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -904,6 +910,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_DV_TX_RGB_RANGE:
case V4L2_CID_DV_RX_RGB_RANGE:
case V4L2_CID_TEST_PATTERN:
+   case V4L2_CID_TUNE_DEEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
@@ -926,6 +933,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_IMAGE_SOURCE_CLASS:
case V4L2_CID_IMAGE_PROC_CLASS:
case V4L2_CID_DV_CLASS:
+   case V4L2_CID_FM_RX_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index dcd6374..296d20e 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -59,6 +59,7 @@
 #define V4L2_CTRL_CLASS_IMAGE_SOURCE   0x009e  /* Image source 
controls */
 #define V4L2_CTRL_CLASS_IMAGE_PROC 0x009f  /* Image processing 
controls */
 #define V4L2_CTRL_CLASS_DV 0x00a0  /* Digital Video 
controls */
+#define V4L2_CTRL_CLASS_FM_RX  0x00a1  /* Digital Video 
controls */
 
 /* User-class control IDs */
 
@@ -711,10 +712,14 @@ enum v4l2_auto_focus_range {
 #define V4L2_CID_PILOT_TONE_FREQUENCY  (V4L2_CID_FM_TX_CLASS_BASE + 98)
 
 #define V4L2_CID_TUNE_PREEMPHASIS  (V4L2_CID_FM_TX_CLASS_BASE + 
112)
-enum v4l2_preemphasis {
+enum v4l2_xemphasis {
V4L2_PREEMPHASIS_DISABLED   = 0,
V4L2_PREEMPHASIS_50_uS  = 1,
V4L2_PREEMPHASIS_75_uS  = 2,
+   V4L2_DEEMPHASIS_DISABLED= V4L2_PREEMPHASIS_DISABLED,
+   V4L2_DEEMPHASIS_50_uS   = V4L2_PREEMPHASIS_50_uS,
+   V4L2_DEEMPHASIS_75_uS   = V4L2_PREEMPHASIS_75_uS,
+
 };
 #define V4L2_CID_TUNE_POWER_LEVEL  (V4L2_CID_FM_TX_CLASS_BASE + 
113)
 #define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 114)
@@ -825,4 +830,10 @@ enum v4l2_dv_rgb_range {
 #defineV4L2_CID_DV_RX_POWER_PRESENT(V4L2_CID_DV_CLASS_BASE 
+ 100)
 #define V4L2_CID_DV_RX_RGB_RANGE   (V4L2_CID_DV_CLASS_BASE + 101)
 
+#define V4L2_CID_FM_RX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS   (V4L2_CTRL_CLASS_FM_RX | 1)
+
+#define V4L2_CID_TUNE_DEEMPHASIS   

[PATCH v5 4/8] mfd: Add chip properties handling code for SI476X MFD

2013-02-25 Thread Andrey Smirnov
From: Andrey Smirnov andreysm@charmander.(none)

This patch adds code related to manipulation of the properties of
SI476X chips.

Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com
---
 drivers/mfd/si476x-prop.c |  234 +
 1 file changed, 234 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..d2b5cc0
--- /dev/null
+++ b/drivers/mfd/si476x-prop.c
@@ -0,0 +1,234 @@
+/*
+ * drivers/mfd/si476x-prop.c -- Subroutines to manipulate with
+ * properties of si476x chips
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ * Copyright (C) 2013 Andrey Smirnov
+ *
+ * Author: Andrey Smirnov andrew.smir...@gmail.com
+ *
+ * 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) ||
+   

[PATCH v5 2/8] mfd: Add commands abstraction layer for SI476X MFD

2013-02-25 Thread Andrey Smirnov
From: Andrey Smirnov andreysm@charmander.(none)

This patch adds all the functions used for exchanging commands with
the chip.

Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com
---
 drivers/mfd/si476x-cmd.c | 1553 ++
 1 file changed, 1553 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..0ae1b63
--- /dev/null
+++ b/drivers/mfd/si476x-cmd.c
@@ -0,0 +1,1553 @@
+/*
+ * drivers/mfd/si476x-cmd.c -- Subroutines implementing command
+ * protocol of si476x series of chips
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ * Copyright (C) 2013 Andrey Smirnov
+ *
+ * Author: Andrey Smirnov andrew.smir...@gmail.com
+ *
+ * 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 

[PATCH v5 1/8] mfd: Add header files and Kbuild plumbing for SI476x MFD core

2013-02-25 Thread Andrey Smirnov
From: Andrey Smirnov andreysm@charmander.(none)

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 andrew.smir...@gmail.com
---
 drivers/mfd/Kconfig |   13 +
 drivers/mfd/Makefile|4 +
 include/linux/mfd/si476x-core.h |  525 +++
 3 files changed, 542 insertions(+)
 create mode 100644 include/linux/mfd/si476x-core.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1c0abd4..3214927 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -970,6 +970,19 @@ 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 and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8b977f8..bf7627b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -131,6 +131,10 @@ obj-$(CONFIG_MFD_JZ4740_ADC)   += jz4740-adc.o
 obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
 obj-$(CONFIG_MFD_VX855)+= vx855.o
 obj-$(CONFIG_MFD_WL1273_CORE)  += wl1273-core.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE)  += si476x-core.o
+
 obj-$(CONFIG_MFD_CS5535)   += cs5535-mfd.o
 obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
 obj-$(CONFIG_MFD_PM8921_CORE)  += pm8921-core.o
diff --git a/include/linux/mfd/si476x-core.h b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..2136b26
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,525 @@
+/*
+ * 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
+
+/* Command Timeouts */
+#define SI476X_DEFAULT_TIMEOUT 10
+#define SI476X_TIMEOUT_TUNE70
+#define SI476X_TIMEOUT_POWER_UP33
+#define SI476X_STATUS_POLL_US  0
+
+/*  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 si476x_power_state {
+   SI476X_POWER_DOWN   = 0,
+   SI476X_POWER_UP_FULL= 1,
+   SI476X_POWER_INCONSISTENT   = 2,
+};
+
+/**
+ * struct si476x_core - internal data structure representing the
+ * underlying core device which all the MFD cell-devices use.
+ *
+ * @client: Actual I2C client used to transfer 

[PATCH v2] Media: remove incorrect __init/__exit markups

2013-02-25 Thread Dmitry Torokhov
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Similarly probe() methods should not be marked __init unless
platform_driver_probe() is used.

Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---

v1-v2: removed __init markup on omap1_cam_probe() that was pointed out
by Guennadi Liakhovetski.

 drivers/media/i2c/adp1653.c  | 4 ++--
 drivers/media/i2c/smiapp/smiapp-core.c   | 4 ++--
 drivers/media/platform/soc_camera/omap1_camera.c | 6 +++---
 drivers/media/radio/radio-si4713.c   | 4 ++--
 drivers/media/rc/ir-rx51.c   | 4 ++--
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index df16380..ef75abe 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -447,7 +447,7 @@ free_and_quit:
return ret;
 }
 
-static int __exit adp1653_remove(struct i2c_client *client)
+static int adp1653_remove(struct i2c_client *client)
 {
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
struct adp1653_flash *flash = to_adp1653_flash(subdev);
@@ -476,7 +476,7 @@ static struct i2c_driver adp1653_i2c_driver = {
.pm = adp1653_pm_ops,
},
.probe  = adp1653_probe,
-   .remove = __exit_p(adp1653_remove),
+   .remove = adp1653_remove,
.id_table   = adp1653_id_table,
 };
 
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 83c7ed7..cae4f46 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2833,7 +2833,7 @@ static int smiapp_probe(struct i2c_client *client,
 sensor-src-pads, 0);
 }
 
-static int __exit smiapp_remove(struct i2c_client *client)
+static int smiapp_remove(struct i2c_client *client)
 {
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
@@ -2881,7 +2881,7 @@ static struct i2c_driver smiapp_i2c_driver = {
.pm = smiapp_pm_ops,
},
.probe  = smiapp_probe,
-   .remove = __exit_p(smiapp_remove),
+   .remove = smiapp_remove,
.id_table = smiapp_id_table,
 };
 
diff --git a/drivers/media/platform/soc_camera/omap1_camera.c 
b/drivers/media/platform/soc_camera/omap1_camera.c
index 39a77f0..e5091b7 100644
--- a/drivers/media/platform/soc_camera/omap1_camera.c
+++ b/drivers/media/platform/soc_camera/omap1_camera.c
@@ -1546,7 +1546,7 @@ static struct soc_camera_host_ops omap1_host_ops = {
.poll   = omap1_cam_poll,
 };
 
-static int __init omap1_cam_probe(struct platform_device *pdev)
+static int omap1_cam_probe(struct platform_device *pdev)
 {
struct omap1_cam_dev *pcdev;
struct resource *res;
@@ -1677,7 +1677,7 @@ exit:
return err;
 }
 
-static int __exit omap1_cam_remove(struct platform_device *pdev)
+static int omap1_cam_remove(struct platform_device *pdev)
 {
struct soc_camera_host *soc_host = to_soc_camera_host(pdev-dev);
struct omap1_cam_dev *pcdev = container_of(soc_host,
@@ -1709,7 +1709,7 @@ static struct platform_driver omap1_cam_driver = {
.name   = DRIVER_NAME,
},
.probe  = omap1_cam_probe,
-   .remove = __exit_p(omap1_cam_remove),
+   .remove = omap1_cam_remove,
 };
 
 module_platform_driver(omap1_cam_driver);
diff --git a/drivers/media/radio/radio-si4713.c 
b/drivers/media/radio/radio-si4713.c
index 1507c9d..8ae8442d 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -328,7 +328,7 @@ exit:
 }
 
 /* radio_si4713_pdriver_remove - remove the device */
-static int __exit radio_si4713_pdriver_remove(struct platform_device *pdev)
+static int radio_si4713_pdriver_remove(struct platform_device *pdev)
 {
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
struct radio_si4713_device *rsdev = container_of(v4l2_dev,
@@ -350,7 +350,7 @@ static struct platform_driver radio_si4713_pdriver = {
.name   = radio-si4713,
},
.probe  = radio_si4713_pdriver_probe,
-   .remove = __exit_p(radio_si4713_pdriver_remove),
+   .remove = radio_si4713_pdriver_remove,
 };
 
 module_platform_driver(radio_si4713_pdriver);
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 8ead492..31b955b 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -464,14 +464,14 @@ static int lirc_rx51_probe(struct platform_device *dev)
return 0;
 }
 
-static int __exit lirc_rx51_remove(struct platform_device *dev)
+static 

Re: [PATCH v2] Media: remove incorrect __init/__exit markups

2013-02-25 Thread Guennadi Liakhovetski
On Mon, 25 Feb 2013, Dmitry Torokhov wrote:

 Even if bus is not hot-pluggable, the devices can be unbound from the
 driver via sysfs, so we should not be using __exit annotations on
 remove() methods. The only exception is drivers registered with
 platform_driver_probe() which specifically disables sysfs bind/unbind
 attributes.
 
 Similarly probe() methods should not be marked __init unless
 platform_driver_probe() is used.
 
 Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
 ---
 
 v1-v2: removed __init markup on omap1_cam_probe() that was pointed out
   by Guennadi Liakhovetski.
 
  drivers/media/platform/soc_camera/omap1_camera.c | 6 +++---

Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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