Re: [PATCH v2] media: v4l2-ctrls: add control for test pattern

[Sakari Ailus]

Hi Hans,

On Sat, Sep 08, 2012 at 01:11:04PM +0200, Hans Verkuil wrote:
 On Fri September 7 2012 20:20:51 Sakari Ailus wrote:
  Hi Prabhakar,
  
  Thanks for the patch!
  
  Prabhakar Lad wrote:
   From: Lad, Prabhakar prabhakar@ti.com
  
   add V4L2_CID_TEST_PATTERN of type menu, which determines
   the internal test pattern selected by the device.
  
   Signed-off-by: Lad, Prabhakar prabhakar@ti.com
   Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
   Cc: Sakari Ailus sakari.ai...@iki.fi
   Cc: Hans Verkuil hans.verk...@cisco.com
   Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
   Cc: Mauro Carvalho Chehab mche...@infradead.org
   Cc: Sylwester Nawrocki s.nawro...@samsung.com
   Cc: Hans de Goede hdego...@redhat.com
   Cc: Kyungmin Park kyungmin.p...@samsung.com
   Cc: Rob Landley r...@landley.net
   ---
   This patches has one checkpatch warning for line over
   80 characters altough it can be avoided I have kept it
   for consistency.
  
   Changes for v2:
   1: Included display devices in the description for test pattern
   as pointed by Hans.
   2: In the menu replaced 'Test Pattern Disabled' by 'Disabled' as
   pointed by Sylwester.
   3: Removed the test patterns from menu as the are hardware specific
   as pointed by Sakari.
  
 Documentation/DocBook/media/v4l/controls.xml |   20 
 drivers/media/v4l2-core/v4l2-ctrls.c |8 
 include/linux/videodev2.h|4 
 3 files changed, 32 insertions(+), 0 deletions(-)
  
   diff --git a/Documentation/DocBook/media/v4l/controls.xml 
   b/Documentation/DocBook/media/v4l/controls.xml
   index ad873ea..173934e 100644
   --- a/Documentation/DocBook/media/v4l/controls.xml
   +++ b/Documentation/DocBook/media/v4l/controls.xml
   @@ -4311,6 +4311,26 @@ interface and may change in the future./para
   /tbody
 /entrytbl
   /row
   +   row
   + entry 
   spanname=idconstantV4L2_CID_TEST_PATTERN/constant/entry
   + entrymenu/entry
   +   /row
   +   row id=v4l2-test-pattern
   + entry spanname=descr The Capture/Display/Sensors have the 
   capability
   + to generate internal test patterns and this are hardware specific. 
   This
   + test patterns are used to test a device is properly working and can 
   generate
   + the desired waveforms that it supports./entry
   +   /row
   +   row
   + entrytbl spanname=descr cols=2
   +   tbody valign=top
   + row
   +  entryconstantV4L2_TEST_PATTERN_DISABLED/constant/entry
   +   entryTest pattern generation is disabled/entry
   + /row
   +   /tbody
   + /entrytbl
   +   /row
 rowentry/entry/row
 /tbody
   /tgroup
   diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
   b/drivers/media/v4l2-core/v4l2-ctrls.c
   index 8f2f40b..d731422 100644
   --- a/drivers/media/v4l2-core/v4l2-ctrls.c
   +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
   @@ -430,6 +430,10 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
 Advanced,
 NULL,
 };
   + static const char * const test_pattern[] = {
   + Disabled,
   + NULL,
   + };
  
 switch (id) {
 case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
   @@ -509,6 +513,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
 return jpeg_chroma_subsampling;
 case V4L2_CID_DPCM_PREDICTOR:
 return dpcm_predictor;
   + case V4L2_CID_TEST_PATTERN:
   + return test_pattern;
  
  I think it's not necessary to define test_pattern (nor be prepared to 
  return it) since the menu is going to be device specific. So the driver 
  is responsible for all of the menu items. Such menus are created using 
  v4l2_ctrl_new_custom() instead of v4l2_ctrl_new_std_menu().
  
  Looks good to me otherwise.
 
 I would suggest that we *do* make this a standard control, but the menu 
 consists
 of just one item: Disabled. After creating the control you can just set the
 ctrl-qmenu pointer to the device-specific menu. I like using standard 
 controls
 because they guarantee standard naming and type conventions. They are also
 easier to use in an application.

That's not quite enough. Also menu_skip_mask and max also need to be
replaced. In a general case min as well. It's easy to do mistakes in that
--- how about a separate function for doing that? It'd be also nice to be
able to use the existing standardised menu item strings, but that's just an
extra plus.

However I think it's beyond this patch, which I think then is be fine w/o
modifications. So on my behalf,

Acked-by: Sakari Ailus sakari.ai...@iki.fi

Cheers,

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

Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.

[Hans Verkuil]

On Sat September 8 2012 16:19:18 Sylwester Nawrocki wrote:
 On 09/08/2012 01:15 PM, Hans Verkuil wrote:
  On Fri September 7 2012 22:00:33 Sylwester Nawrocki wrote:
  On 09/07/2012 03:29 PM, Hans Verkuil wrote:
  From: Hans Verkuilhans.verk...@cisco.com
 
  During the 2012 Media Workshop it was decided that bus_info as returned
  by VIDIOC_QUERYCAP can no longer be empty. It should be a unique 
  identifier,
  and empty strings are obviously not unique.
 
  Signed-off-by: Hans Verkuilhans.verk...@cisco.com
 
  Reviewed-by: Sylwester Nawrockis.nawro...@samsung.com
 
  ---
 Documentation/DocBook/media/v4l/vidioc-querycap.xml |   14 
  ++
 1 file changed, 10 insertions(+), 4 deletions(-)
 
  diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml 
  b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
  index f33dd74..d5b1248 100644
  --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
  +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
  @@ -90,11 +90,17 @@ ambiguities./entry
entry__u8/entry
entrystructfieldbus_info/structfield[32]/entry
entryLocation of the device in the system, a
  -NUL-terminated ASCII string. For example: PCI Slot 4. This
  +NUL-terminated ASCII string. For example: PCI::05:06.0. This
 information is intended for users, to distinguish multiple
  -identical devices. If no such information is available the field may
  -simply count the devices controlled by the driver, or contain the
  -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX 
  pci_dev-slot_name example --/entry
  +identical devices. If no such information is available the field must
  +simply count the devices controlled by the driver (vivi-000). The 
  bus_info
  +must start with PCI: for PCI boards, PCIe: for PCI Express boards,
  +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices 
  and
  +parport for parallel port devices.
  +For devices without a bus it should start with the driver name, 
  optionally
 
  Most, if not all, devices are on some sort of bus. What would be an example
  of a device without a bus ?
  
  Virtual devices like vivi and platform devices. Or is there some sort of
  platform bus?
 
 OK, then virtual devices like vivi are indeed not on any bus. But saying so,
 or implicitly assuming, about platform devices would have been misleading.
 
 On ASICs and SoCs such devices are on some kind of on-chip peripheral bus, 
 e.g. AMBA APB/AHB [1].

Yes, but such busses are internal to the hardware and are not enumerated by
the kernel. The kernel will generate unique names for e.g. usb and pci busses
which is used to identify the device on that bus. And that's used also when
generating the bus_info.

That said, I checked drivers/base/platform.c and there is actually a platform
bus that's created in the kernel for platform devices. So perhaps something
like platform:devname wouldn't be such a bad idea after all. I'd have to do
some tests with this to see how it would look.

Regards,

Hans

 So perhaps we could specify that for platform devices
 bus_info should start with platform- ? A unique remainder could be easily 
 formed in drivers on basis of a memory mapped register region address/size
 and/or a device interrupt number to the CPU. However, exposing such sensitive
 data may be questionable, so it's probably better to just stick with a simple 
 counter of identical devices.
 
  Could we just be saying here For other devices instead of For devices
  without a bus, or something similar ?
  
  Well, I'd like for any device on a bus to have a consistent naming 
  convention
  so we can guarantee that bus_info is always unique.
  
  Regards,
  
  Hans
  
 
  +followed by - and an index if multiple instances of the device as 
  possible.
  +Many platform devices can have only one instance, so in that case 
  bus_info
  +is identical to thestructfielddriver/structfield   field./entry
/row
row
entry__u32/entry
 
 [1] http://www-micro.deis.unibo.it/~magagni/amba99.pdf
 
 --
 
 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
 
--
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: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.

[Sylwester Nawrocki]

On 09/09/2012 10:45 AM, Hans Verkuil wrote:
 diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml 
 b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 index f33dd74..d5b1248 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 @@ -90,11 +90,17 @@ ambiguities./entry
   entry__u8/entry
   entrystructfieldbus_info/structfield[32]/entry
   entryLocation of the device in the system, a
 -NUL-terminated ASCII string. For example: PCI Slot 4. This
 +NUL-terminated ASCII string. For example: PCI::05:06.0. This
 information is intended for users, to distinguish multiple
 -identical devices. If no such information is available the field may
 -simply count the devices controlled by the driver, or contain the
 -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX 
 pci_dev-slot_name example --/entry
 +identical devices. If no such information is available the field must
 +simply count the devices controlled by the driver (vivi-000). The 
 bus_info
 +must start with PCI: for PCI boards, PCIe: for PCI Express boards,
 +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices 
 and
 +parport for parallel port devices.
 +For devices without a bus it should start with the driver name, 
 optionally

 Most, if not all, devices are on some sort of bus. What would be an example
 of a device without a bus ?

 Virtual devices like vivi and platform devices. Or is there some sort of
 platform bus?

 OK, then virtual devices like vivi are indeed not on any bus. But saying so,
 or implicitly assuming, about platform devices would have been misleading.

 On ASICs and SoCs such devices are on some kind of on-chip peripheral bus,
 e.g. AMBA APB/AHB [1].
 
 Yes, but such busses are internal to the hardware and are not enumerated by
 the kernel. The kernel will generate unique names for e.g. usb and pci busses
 which is used to identify the device on that bus. And that's used also when
 generating the bus_info.

They are not enumerated but are commonly referred to as simple bus or AMBA 
bus and mapped to system address space. See drivers/of/platform.c or 
Documentation/devicetree/usage-model.txt. And the device names must also be 
unique IIRC. platform_bus_type is also often used for devices that don't match 
with any other existing bus_type. One could look at /sys/bus/platform/devices 
for sample list of platform devices.

 That said, I checked drivers/base/platform.c and there is actually a platform
 bus that's created in the kernel for platform devices. So perhaps something
 like platform:devname wouldn't be such a bad idea after all. I'd have to do
 some tests with this to see how it would look.

Yeah, obviously. platform:devname sounds good, bus_info would be then telling 
something about the bus, rather than being a redundant copy of driver's name.

--

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

Re: [PATCH 1/3] FCI FC2580 silicon tuner driver

[Antti Palosaari]

Hello
it does not make any sense. I just put those limits as those are DVB-T 
band lower and upper limits. Current limit values are payload from the 
history and does not suit very well newer designs. Anyhow, there should 
be some limits defined as frontend needs those to report / limit 
userspace apps.


regards
Antti

On 09/09/2012 05:33 PM, Oliver Schinagl wrote:

According to the 'spec sheet' [1] The min frequency goes as low as
170MHz (opposed to the 172MHz in this patch). Maximum frequency 'should'
be only 860MHz though. Don't know if the L Band needs to be included
into this min/max thing, as that one runs from 1350 - 1750MHz :)


[1] http://www.digitimes.com.tw/PDF/DTF960807/2007080702.pdf

On 09/09/12 04:07, Antti Palosaari wrote:

Signed-off-by: Antti Palosaaricr...@iki.fi
---
  drivers/media/tuners/Kconfig   |   7 +
  drivers/media/tuners/Makefile  |   1 +
  drivers/media/tuners/fc2580.c  | 524
+
  drivers/media/tuners/fc2580.h  |  52 
  drivers/media/tuners/fc2580_priv.h | 134 ++
  5 files changed, 718 insertions(+)
  create mode 100644 drivers/media/tuners/fc2580.c
  create mode 100644 drivers/media/tuners/fc2580.h
  create mode 100644 drivers/media/tuners/fc2580_priv.h

diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index f9e299c..622375e 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -229,6 +229,13 @@ config MEDIA_TUNER_E4000
  help
Elonics E4000 silicon tuner driver.

+config MEDIA_TUNER_FC2580
+tristate FCI FC2580 silicon tuner
+depends on MEDIA_SUPPORT  I2C
+default m if !MEDIA_SUBDRV_AUTOSELECT
+help
+  FCI FC2580 silicon tuner driver.
+
  config MEDIA_TUNER_TUA9001
  tristate Infineon TUA 9001 silicon tuner
  depends on MEDIA_SUPPORT  I2C
diff --git a/drivers/media/tuners/Makefile
b/drivers/media/tuners/Makefile
index 9f7b2c2..5e569b1 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
  obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
  obj-$(CONFIG_MEDIA_TUNER_TDA18212) += tda18212.o
  obj-$(CONFIG_MEDIA_TUNER_E4000) += e4000.o
+obj-$(CONFIG_MEDIA_TUNER_FC2580) += fc2580.o
  obj-$(CONFIG_MEDIA_TUNER_TUA9001) += tua9001.o
  obj-$(CONFIG_MEDIA_TUNER_FC0011) += fc0011.o
  obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
diff --git a/drivers/media/tuners/fc2580.c
b/drivers/media/tuners/fc2580.c
new file mode 100644
index 000..afc0491
--- /dev/null
+++ b/drivers/media/tuners/fc2580.c
@@ -0,0 +1,524 @@
+/*
+ * FCI FC2580 silicon tuner driver
+ *
+ * Copyright (C) 2012 Antti Palosaaricr...@iki.fi
+ *
+ *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; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *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.
+ *
+ *You should have received a copy of the GNU General Public
License along
+ *with this program; if not, write to the Free Software
Foundation, Inc.,
+ *51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include fc2580_priv.h
+
+/*
+ * TODO:
+ * I2C write and read works only for one single register. Multiple
registers
+ * could not be accessed using normal register address auto-increment.
+ * There could be (very likely) register to change that behavior
+ *
+ * Due to that limitation functions:
+ *   fc2580_wr_regs()
+ *   fc2580_rd_regs()
+ * could not be used for accessing more than one register at once.
+ *
+ * TODO:
+ * Currently it blind writes bunch of static registers from the
+ * fc2580_freq_regs_lut[] when fc2580_set_params() is called. Add some
+ * logic to reduce unneeded register writes.
+ * There is also don't-care registers, initialized with value 0xff,
and those
+ * are also written to the chip currently (yes, not wise).
+ */
+
+/* write multiple registers */
+static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val,
int len)
+{
+int ret;
+u8 buf[1 + len];
+struct i2c_msg msg[1] = {
+{
+.addr = priv-cfg-i2c_addr,
+.flags = 0,
+.len = sizeof(buf),
+.buf = buf,
+}
+};
+
+buf[0] = reg;
+memcpy(buf[1], val, len);
+
+ret = i2c_transfer(priv-i2c, msg, 1);
+if (ret == 1) {
+ret = 0;
+} else {
+dev_warn(priv-i2c-dev, %s: i2c wr failed=%d reg=%02x  \
+len=%d\n, KBUILD_MODNAME, ret, reg, len);
+ret = -EREMOTEIO;
+}
+return ret;
+}
+
+/* read multiple registers */
+static int fc2580_rd_regs(struct fc2580_priv *priv, u8 

Re: [PATCH 1/3] FCI FC2580 silicon tuner driver

[Oliver Schinagl]

According to the 'spec sheet' [1] The min frequency goes as low as 
170MHz (opposed to the 172MHz in this patch). Maximum frequency 'should' 
be only 860MHz though. Don't know if the L Band needs to be included 
into this min/max thing, as that one runs from 1350 - 1750MHz :)



[1] http://www.digitimes.com.tw/PDF/DTF960807/2007080702.pdf

On 09/09/12 04:07, Antti Palosaari wrote:

Signed-off-by: Antti Palosaaricr...@iki.fi
---
  drivers/media/tuners/Kconfig   |   7 +
  drivers/media/tuners/Makefile  |   1 +
  drivers/media/tuners/fc2580.c  | 524 +
  drivers/media/tuners/fc2580.h  |  52 
  drivers/media/tuners/fc2580_priv.h | 134 ++
  5 files changed, 718 insertions(+)
  create mode 100644 drivers/media/tuners/fc2580.c
  create mode 100644 drivers/media/tuners/fc2580.h
  create mode 100644 drivers/media/tuners/fc2580_priv.h

diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index f9e299c..622375e 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -229,6 +229,13 @@ config MEDIA_TUNER_E4000
help
  Elonics E4000 silicon tuner driver.

+config MEDIA_TUNER_FC2580
+   tristate FCI FC2580 silicon tuner
+   depends on MEDIA_SUPPORT  I2C
+   default m if !MEDIA_SUBDRV_AUTOSELECT
+   help
+ FCI FC2580 silicon tuner driver.
+
  config MEDIA_TUNER_TUA9001
tristate Infineon TUA 9001 silicon tuner
depends on MEDIA_SUPPORT  I2C
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index 9f7b2c2..5e569b1 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
  obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
  obj-$(CONFIG_MEDIA_TUNER_TDA18212) += tda18212.o
  obj-$(CONFIG_MEDIA_TUNER_E4000) += e4000.o
+obj-$(CONFIG_MEDIA_TUNER_FC2580) += fc2580.o
  obj-$(CONFIG_MEDIA_TUNER_TUA9001) += tua9001.o
  obj-$(CONFIG_MEDIA_TUNER_FC0011) += fc0011.o
  obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
new file mode 100644
index 000..afc0491
--- /dev/null
+++ b/drivers/media/tuners/fc2580.c
@@ -0,0 +1,524 @@
+/*
+ * FCI FC2580 silicon tuner driver
+ *
+ * Copyright (C) 2012 Antti Palosaaricr...@iki.fi
+ *
+ *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; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *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.
+ *
+ *You should have received a copy of the GNU General Public License along
+ *with this program; if not, write to the Free Software Foundation, Inc.,
+ *51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include fc2580_priv.h
+
+/*
+ * TODO:
+ * I2C write and read works only for one single register. Multiple registers
+ * could not be accessed using normal register address auto-increment.
+ * There could be (very likely) register to change that behavior
+ *
+ * Due to that limitation functions:
+ *   fc2580_wr_regs()
+ *   fc2580_rd_regs()
+ * could not be used for accessing more than one register at once.
+ *
+ * TODO:
+ * Currently it blind writes bunch of static registers from the
+ * fc2580_freq_regs_lut[] when fc2580_set_params() is called. Add some
+ * logic to reduce unneeded register writes.
+ * There is also don't-care registers, initialized with value 0xff, and those
+ * are also written to the chip currently (yes, not wise).
+ */
+
+/* write multiple registers */
+static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
+{
+   int ret;
+   u8 buf[1 + len];
+   struct i2c_msg msg[1] = {
+   {
+   .addr = priv-cfg-i2c_addr,
+   .flags = 0,
+   .len = sizeof(buf),
+   .buf = buf,
+   }
+   };
+
+   buf[0] = reg;
+   memcpy(buf[1], val, len);
+
+   ret = i2c_transfer(priv-i2c, msg, 1);
+   if (ret == 1) {
+   ret = 0;
+   } else {
+   dev_warn(priv-i2c-dev, %s: i2c wr failed=%d reg=%02x  \
+   len=%d\n, KBUILD_MODNAME, ret, reg, len);
+   ret = -EREMOTEIO;
+   }
+   return ret;
+}
+
+/* read multiple registers */
+static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
+{
+   int ret;
+   u8 buf[len];
+   struct i2c_msg msg[2] = {
+   {
+   .addr = priv-cfg-i2c_addr,
+   .flags = 0,
+ 

Re: dvb-apps scan files

[Hernán Rossetto]

It seems these were not added to the dvb-apps mercurial repo.

Is this the way to submit these files ?
If not, please let me know and I'll follow the right procedure.

Thanks again,
Hernán.-

On Sat, Sep 8, 2012 at 3:54 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
 Great!

 On Sat, Sep 8, 2012 at 12:48 AM, Hernán Rossetto hmronl...@gmail.com wrote:
 Please add the attached files for Argentina and Brazil to the DVB-T scan 
 list.

 You will notice they have the same content already published here
 http://www.linuxtv.org/wiki/index.php/ISDB-T_Frequency_Table


 Muchas gracias!
 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: [RFC PATCH v6] media: add v4l2 subdev driver for S5K4ECGX sensor

[Francesco Lavra]

Hi,
I'm going to report the (few) things which are also present in
Sylwester's tree.

On 09/06/2012 05:08 PM, Sangwook Lee wrote:
 This patch adds driver for S5K4ECGX sensor with embedded ISP SoC,
 S5K4ECGX, which is a 5M CMOS Image sensor from Samsung
 The driver implements preview mode of the S5K4ECGX sensor.
 capture (snapshot) operation, face detection are missing now.
 Following controls are supported:
 contrast/saturation/brightness/sharpness
 
 Signed-off-by: Sangwook Lee sangwook@linaro.org
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com

[snip]

 +static const char * const s5k4ecgx_supply_names[] = {
 + /*
 +  * Usually 2.8V is used for analog power (vdda)
 +  * and digital IO (vddio, vddd_core)

s/vddd_core/vddcore

[snip]

 +static int s5k4ecgx_load_firmware(struct v4l2_subdev *sd)
 +{
 + const struct firmware *fw;
 + int err, i, regs_num;
 + struct i2c_client *client = v4l2_get_subdevdata(sd);
 + u16 val;
 + u32 addr, crc, crc_file, addr_inc = 0;
 +
 + err = request_firmware(fw, S5K4ECGX_FIRMWARE, sd-v4l2_dev-dev);
 + if (err) {
 + v4l2_err(sd, Failed to read firmware %s\n, S5K4ECGX_FIRMWARE);
 + return err;
 + }
 + regs_num = *(u32 *)(fw-data);
 + v4l2_dbg(3, debug, sd, FW: %s size %d register sets %d\n,
 +  S5K4ECGX_FIRMWARE, fw-size, regs_num);
 + regs_num++; /* Add header */
 + if (fw-size != regs_num * FW_RECORD_SIZE + FW_CRC_SIZE) {
 + err = -EINVAL;
 + goto fw_out;
 + }
 + crc_file = *(u32 *)(fw-data + regs_num * FW_RECORD_SIZE);

Depending on the value of regs_num, this may result in unaligned access

[snip]

 +static int s5k4ecgx_s_power(struct v4l2_subdev *sd, int on)
 +{
 + struct s5k4ecgx *priv = to_s5k4ecgx(sd);
 + int ret;
 +
 + v4l2_dbg(1, debug, sd, Switching %s\n, on ? on : off);
 +
 + if (on) {
 + ret = __s5k4ecgx_power_on(priv);
 + if (ret  0)
 + return ret;
 + /* Time to stabilize sensor */
 + msleep(100);
 + ret = s5k4ecgx_init_sensor(sd);
 + if (ret  0)
 + __s5k4ecgx_power_off(priv);
 + else
 + priv-set_params = 1;
 + } else {
 + ret = __s5k4ecgx_power_off(priv);
 + }
 +
 + return 0;

return ret;

[snip]

 +static int s5k4ecgx_probe(struct i2c_client *client,
 +   const struct i2c_device_id *id)
 +{
 + int ret, i;
 + struct v4l2_subdev *sd;
 + struct s5k4ecgx *priv;
 + struct s5k4ecgx_platform_data *pdata = client-dev.platform_data;
 +
 + if (pdata == NULL) {
 + dev_err(client-dev, platform data is missing!\n);
 + return -EINVAL;
 + }
 + priv = devm_kzalloc(client-dev, sizeof(struct s5k4ecgx), GFP_KERNEL);
 + if (!priv)
 + return -ENOMEM;
 +
 + mutex_init(priv-lock);
 + priv-streaming = 0;
 +
 + sd = priv-sd;
 + /* Registering subdev */
 + v4l2_i2c_subdev_init(sd, client, s5k4ecgx_ops);
 + strlcpy(sd-name, S5K4ECGX_DRIVER_NAME, sizeof(sd-name));
 +
 + sd-internal_ops = s5k4ecgx_subdev_internal_ops;
 + /* Support v4l2 sub-device user space API */
 + sd-flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 +
 + priv-pad.flags = MEDIA_PAD_FL_SOURCE;
 + sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
 + ret = media_entity_init(sd-entity, 1, priv-pad, 0);
 + if (ret)
 + return ret;
 +
 + ret = s5k4ecgx_config_gpios(priv, pdata);
 + if (ret) {
 + dev_err(client-dev, Failed to set gpios\n);
 + goto out_err1;
 + }
 + for (i = 0; i  S5K4ECGX_NUM_SUPPLIES; i++)
 + priv-supplies[i].supply = s5k4ecgx_supply_names[i];
 +
 + ret = devm_regulator_bulk_get(client-dev, S5K4ECGX_NUM_SUPPLIES,
 +  priv-supplies);
 + if (ret) {
 + dev_err(client-dev, Failed to get regulators\n);
 + goto out_err2;
 + }
 + ret = s5k4ecgx_init_v4l2_ctrls(priv);
 + if (ret)
 + goto out_err2;
 +
 + priv-curr_pixfmt = s5k4ecgx_formats[0];
 + priv-curr_frmsize = s5k4ecgx_prev_sizes[0];
 +
 + return 0;
 +
 +out_err2:
 + s5k4ecgx_free_gpios(priv);
 +out_err1:
 + media_entity_cleanup(priv-sd.entity);
 +
 + return ret;
 +}
 +
 +static int s5k4ecgx_remove(struct i2c_client *client)
 +{
 + struct v4l2_subdev *sd = i2c_get_clientdata(client);
 + struct s5k4ecgx *priv = to_s5k4ecgx(sd);
 +
 + mutex_destroy(priv-lock);
 + v4l2_device_unregister_subdev(sd);
 + v4l2_ctrl_handler_free(priv-handler);
 + media_entity_cleanup(sd-entity);
 +
 + return 0;

Maybe s5k4ecgx_free_gpios() should be called?

Regards,
Francesco
--
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  

[PATCH 1/6] gspca_pac7302: add support for device 1ae7:2001 Speedlink Snappy Microphone SL-6825-SBK

[Frank Schäfer]

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Cc: sta...@kernel.org
---
 drivers/media/usb/gspca/pac7302.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/usb/gspca/pac7302.c 
b/drivers/media/usb/gspca/pac7302.c
index 4877f7a..e906f56 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -905,6 +905,7 @@ static const struct usb_device_id device_table[] = {
{USB_DEVICE(0x093a, 0x262a)},
{USB_DEVICE(0x093a, 0x262c)},
{USB_DEVICE(0x145f, 0x013c)},
+   {USB_DEVICE(0x1ae7, 0x2001)}, /* SpeedLink Snappy Mic SL-6825-SBK */
{}
 };
 MODULE_DEVICE_TABLE(usb, device_table);
-- 
1.7.7

--
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] gspca_pac7302: make red balance and blue balance controls work again

[Frank Schäfer]

Fix a regression from kernel 3.4 which has been introduced with the conversion 
of the gspca driver to the v4l2 control framework.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Cc: sta...@kernel.org
---
 drivers/media/usb/gspca/pac7302.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/usb/gspca/pac7302.c 
b/drivers/media/usb/gspca/pac7302.c
index e906f56..eb3c90e4 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -616,7 +616,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
sd-red_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_RED_BALANCE, 0, 3, 1, 1);
sd-blue_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
-   V4L2_CID_RED_BALANCE, 0, 3, 1, 1);
+   V4L2_CID_BLUE_BALANCE, 0, 3, 1, 1);
 
gspca_dev-autogain = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
-- 
1.7.7

--
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] gspca_pac7302: add sharpness control

[Frank Schäfer]

The Windows driver uses page 0 register 0xb6 for sharpness adjustment.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
 drivers/media/usb/gspca/pac7302.c |   25 -
 1 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/drivers/media/usb/gspca/pac7302.c 
b/drivers/media/usb/gspca/pac7302.c
index eb3c90e4..8c29613 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -26,6 +26,11 @@
 /*
  * Some documentation about various registers as determined by trial and error.
  *
+ * Register page 0:
+ *
+ * Address Description
+ * 0xb6Sharpness control (bits 0-4)
+ *
  * Register page 1:
  *
  * Address Description
@@ -66,6 +71,7 @@
  * -++---
  *  0   | 0x0f..0x20 | setcolors()
  *  0   | 0xa2..0xab | setbrightcont()
+ *  0   | 0xb6   | setsharpness()
  *  0   | 0xc5   | setredbalance()
  *  0   | 0xc6   | setwhitebalance()
  *  0   | 0xc7   | setbluebalance()
@@ -109,6 +115,7 @@ struct sd {
struct v4l2_ctrl *hflip;
struct v4l2_ctrl *vflip;
};
+   struct v4l2_ctrl *sharpness;
u8 flags;
 #define FL_HFLIP 0x01  /* mirrored by default */
 #define FL_VFLIP 0x02  /* vertical flipped by default */
@@ -531,6 +538,16 @@ static void sethvflip(struct gspca_dev *gspca_dev)
reg_w(gspca_dev, 0x11, 0x01);
 }
 
+static void setsharpness(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   reg_w(gspca_dev, 0xff, 0x00);   /* page 0 */
+   reg_w(gspca_dev, 0xb6, sd-sharpness-val);
+
+   reg_w(gspca_dev, 0xdc, 0x01);
+}
+
 /* this function is called at probe and resume time for pac7302 */
 static int sd_init(struct gspca_dev *gspca_dev)
 {
@@ -584,6 +601,9 @@ static int sd_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_HFLIP:
sethvflip(gspca_dev);
break;
+   case V4L2_CID_SHARPNESS:
+   setsharpness(gspca_dev);
+   break;
default:
return -EINVAL;
}
@@ -601,7 +621,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
struct v4l2_ctrl_handler *hdl = gspca_dev-ctrl_handler;
 
gspca_dev-vdev.ctrl_handler = hdl;
-   v4l2_ctrl_handler_init(hdl, 11);
+   v4l2_ctrl_handler_init(hdl, 12);
 
sd-brightness = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 32, 1, 16);
@@ -632,6 +652,9 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
sd-vflip = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
 
+   sd-sharpness = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
+   V4L2_CID_SHARPNESS, 0, 15, 1, 8);
+
if (hdl-error) {
pr_err(Could not initialize controls\n);
return hdl-error;
-- 
1.7.7

--
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 4/6] gspca_pac7302: increase default value for white balance temperature

[Frank Schäfer]

The current white balance temperature default value is 4, which is much too 
small (possible values are 0-255).
Improve the picture quality by increasing the default value to 55, which is the 
default value used by the Windows driver.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
 drivers/media/usb/gspca/pac7302.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/usb/gspca/pac7302.c 
b/drivers/media/usb/gspca/pac7302.c
index 8c29613..bed34df 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -632,7 +632,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
V4L2_CID_SATURATION, 0, 255, 1, 127);
sd-white_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_WHITE_BALANCE_TEMPERATURE,
-   0, 255, 1, 4);
+   0, 255, 1, 55);
sd-red_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_RED_BALANCE, 0, 3, 1, 1);
sd-blue_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
-- 
1.7.7

--
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 5/6] gspca_pac7302: avoid duplicate calls of the image quality adjustment functions on capturing start

[Frank Schäfer]

There is no need to call the image quality adjustment functions in sd_start.
The gspca main driver calls v4l2_ctrl_handler_setup in gspca_init_transfer,
which already applies all image control values.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
 drivers/media/usb/gspca/pac7302.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/media/usb/gspca/pac7302.c 
b/drivers/media/usb/gspca/pac7302.c
index bed34df..71fa5a4 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -673,14 +673,6 @@ static int sd_start(struct gspca_dev *gspca_dev)
 
reg_w_var(gspca_dev, start_7302,
page3_7302, sizeof(page3_7302));
-   setbrightcont(gspca_dev);
-   setcolors(gspca_dev);
-   setwhitebalance(gspca_dev);
-   setredbalance(gspca_dev);
-   setbluebalance(gspca_dev);
-   setexposure(gspca_dev);
-   setgain(gspca_dev);
-   sethvflip(gspca_dev);
 
sd-sof_read = 0;
sd-autogain_ignore_frames = 0;
-- 
1.7.7

--
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] gspca_pac7302: extend register documentation

[Frank Schäfer]

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
 drivers/media/usb/gspca/pac7302.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/media/usb/gspca/pac7302.c 
b/drivers/media/usb/gspca/pac7302.c
index 71fa5a4..2d5c6d83 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -29,6 +29,15 @@
  * Register page 0:
  *
  * Address Description
+ * 0x02Red balance control
+ * 0x03Green balance control
+ * 0x04Blue balance control
+ *  Valus are inverted (0=max, 255=min).
+ *  The Windows driver uses a quadratic approach to map
+ *  the settable values (0-200) on register values:
+ *  min=0x80, default=0x40, max=0x20
+ * 0x0f-0x20   Colors, saturation and exposure control
+ * 0xa2-0xab   Brightness, contrast and gamma control
  * 0xb6Sharpness control (bits 0-4)
  *
  * Register page 1:
-- 
1.7.7

--
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/3] libv4lconvert: fix format of the error messages concerning jpeg frame size mismatch

[Frank Schäfer]

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
 lib/libv4lconvert/jpeg.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/libv4lconvert/jpeg.c b/lib/libv4lconvert/jpeg.c
index e088a90..aa9cace 100644
--- a/lib/libv4lconvert/jpeg.c
+++ b/lib/libv4lconvert/jpeg.c
@@ -56,7 +56,7 @@ int v4lconvert_decode_jpeg_tinyjpeg(struct v4lconvert_data 
*data,
}
 
if (header_width != width || header_height != height) {
-   V4LCONVERT_ERR(unexpected width / height in JPEG header
+   V4LCONVERT_ERR(unexpected width / height in JPEG header: 
   expected: %ux%u, header: %ux%u\n,
   width, height, header_width, header_height);
errno = EIO;
@@ -288,7 +288,7 @@ int v4lconvert_decode_jpeg_libjpeg(struct v4lconvert_data 
*data,
 
if (data-cinfo.image_width  != width ||
data-cinfo.image_height != height) {
-   V4LCONVERT_ERR(unexpected width / height in JPEG header
+   V4LCONVERT_ERR(unexpected width / height in JPEG header: 
   expected: %ux%u, header: %ux%u\n, width,
   height, data-cinfo.image_width,
   data-cinfo.image_height);
-- 
1.7.7

--
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/3] libv4lconvert: pac7302-devices: remove unneeded flag V4LCONTROL_WANTS_WB

[Frank Schäfer]

The gspca_pac7302 driver already provides this control.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
 lib/libv4lconvert/control/libv4lcontrol.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/lib/libv4lconvert/control/libv4lcontrol.c 
b/lib/libv4lconvert/control/libv4lcontrol.c
index 1272256..3d7a816 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -202,14 +202,10 @@ static const struct v4lcontrol_flags_info 
v4lcontrol_flags[] = {
{ 0x145f, 0x013a, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
{ 0x2001, 0xf115, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
/* Pac7302 based devices */
-   { 0x093a, 0x2620, 0x0f, NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
-   { 0x06f8, 0x3009, 0,NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
-   { 0x06f8, 0x301b, 0,NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
-   { 0x145f, 0x013c, 0,NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
+   { 0x093a, 0x2620, 0x0f, NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x06f8, 0x3009, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x06f8, 0x301b, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x145f, 0x013c, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
/* Pac7311 based devices */
{ 0x093a, 0x2600, 0x0f, NULL, NULL, V4LCONTROL_WANTS_WB },
/* sq905 devices */
-- 
1.7.7

--
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/3] libv4lconvert: update the list of pac7302 webcams

[Frank Schäfer]

All pac7302 webcams need image rotation, so synchronize the list with the 
driver.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
 lib/libv4lconvert/control/libv4lcontrol.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/lib/libv4lconvert/control/libv4lcontrol.c 
b/lib/libv4lconvert/control/libv4lcontrol.c
index 3d7a816..6eea121 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -202,10 +202,21 @@ static const struct v4lcontrol_flags_info 
v4lcontrol_flags[] = {
{ 0x145f, 0x013a, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
{ 0x2001, 0xf115, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
/* Pac7302 based devices */
-   { 0x093a, 0x2620, 0x0f, NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
{ 0x06f8, 0x3009, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
{ 0x06f8, 0x301b, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2620, 0x0f, NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2611, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2622, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2624, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2625, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2626, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2627, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2628, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2629, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x262a, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x262c, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
{ 0x145f, 0x013c, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x1ae7, 0x2001, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
/* Pac7311 based devices */
{ 0x093a, 0x2600, 0x0f, NULL, NULL, V4LCONTROL_WANTS_WB },
/* sq905 devices */
-- 
1.7.7

--
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 v2] drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c: fix error return code

[walter harms]

looks ok to me,
note: i do not have the hardware
Reviewed-by: walter harms wha...@bfs.de

Am 08.09.2012 16:01, schrieb Peter Senna Tschudin:
 From: Peter Senna Tschudin peter.se...@gmail.com
 
 Convert a nonnegative error return code to a negative one, as returned
 elsewhere in the function.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 (
 if@p1 (\(ret  0\|ret != 0\))
  { ... return ret; }
 |
 ret@p1 = 0
 )
 ... when != ret = e1
 when != ret
 *if(...)
 {
   ... when != ret = e2
   when forall
  return ret;
 }
 
 // /smpl
 
 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 
 ---
 walter harms wha...@bfs.de, thanks for the tip. Please take a look 
 carefully to check if I got your suggestion correctly. It was tested by 
 compilation only.
 
  drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c |   30 
 ++---
  1 file changed, 12 insertions(+), 18 deletions(-)
 
 diff --git a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c 
 b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
 index c8c94fb..b663dac 100644
 --- a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
 +++ b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
 @@ -704,11 +704,9 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev 
 *dev, int channel_select,
  {
   struct sram_channel *sram_ch;
   u32 tmp;
 - int retval = 0;
   int err = 0;
   int data_frame_size = 0;
   int risc_buffer_size = 0;
 - int str_length = 0;
  
   if (dev-_is_running_ch2) {
   pr_info(Video Channel is still running so return!\n);
 @@ -744,20 +742,16 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev 
 *dev, int channel_select,
   risc_buffer_size = dev-_isNTSC_ch2 ?
   NTSC_RISC_BUF_SIZE : PAL_RISC_BUF_SIZE;
  
 - if (dev-input_filename_ch2) {
 - str_length = strlen(dev-input_filename_ch2);
 - dev-_filename_ch2 = kmemdup(dev-input_filename_ch2,
 -  str_length + 1, GFP_KERNEL);
 -
 - if (!dev-_filename_ch2)
 - goto error;
 - } else {
 - str_length = strlen(dev-_defaultname_ch2);
 - dev-_filename_ch2 = kmemdup(dev-_defaultname_ch2,
 -  str_length + 1, GFP_KERNEL);
 + if (dev-input_filename_ch2)
 + dev-_filename_ch2 = kstrdup(dev-input_filename_ch2,
 + GFP_KERNEL);
 + else
 + dev-_filename_ch2 = kstrdup(dev-_defaultname_ch2,
 + GFP_KERNEL);
  
 - if (!dev-_filename_ch2)
 - goto error;
 + if (!dev-_filename_ch2) {
 + err = -ENOENT;
 + goto error;
   }
  
   /* Default if filename is empty string */
 @@ -773,7 +767,7 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev, 
 int channel_select,
   }
   }
  
 - retval = cx25821_sram_channel_setup_upstream(dev, sram_ch,
 + err = cx25821_sram_channel_setup_upstream(dev, sram_ch,
   dev-_line_size_ch2, 0);
  
   /* setup fifo + format */
 @@ -783,9 +777,9 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev, 
 int channel_select,
   dev-upstream_databuf_size_ch2 = data_frame_size * 2;
  
   /* Allocating buffers and prepare RISC program */
 - retval = cx25821_upstream_buffer_prepare_ch2(dev, sram_ch,
 + err = cx25821_upstream_buffer_prepare_ch2(dev, sram_ch,
   dev-_line_size_ch2);
 - if (retval  0) {
 + if (err  0) {
   pr_err(%s: Failed to set up Video upstream buffers!\n,
  dev-name);
   goto error;
 
 
 
--
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

MFC Encode on S5PV210 hangs

[Mike Dyer]

Hi All,

I'm trying to use the MFC encoder to generate an H264 bitstream using
the V4L2 interface.  I've tried using my own application, and also the
example encode application here:
git://git.infradead.org/users/kmpark/public-apps

Both exhibit the same behavior.  Input frames are queued up until the
input queue is full, but only one frame is emitted (which I guess is the
H264 header).  The encoder then just sits there.

I'm not sure where to start looking, so any advice is appreciated.

Cheers,
Mike

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

[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:Sun Sep  9 19:00:22 CEST 2012
git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324
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: OK
linux-git-arm-eabi-omap: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: 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-rc2-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-rc2-i686: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.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 v2] [media] rc-core: prevent divide by zero bug in s_tx_carrier()

[Dan Carpenter]

Several of the drivers use carrier as a divisor in their s_tx_carrier()
functions.  We should do a sanity check here like we do for
LIRC_SET_REC_CARRIER.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
v2: Ben Hutchings pointed out that my first patch was not a complete
fix.

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 6ad4a07..28dc0f0 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -211,6 +211,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
if (!dev-s_tx_carrier)
return -EINVAL;
 
+   if (val = 0)
+   return -EINVAL;
+
return dev-s_tx_carrier(dev, val);
 
case LIRC_SET_SEND_DUTY_CYCLE:
--
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] Support for Asus MyCinema U3100Mini Plus

[oliver]

From: Oliver Schinagl oli...@schinagl.nl

Initial support for the Asus MyCinema U3100Mini Plus. This currently
does not work however. It uses teh af9033/5 demodulater with an
FCI FC2580 tuner.

Signed-off-by: Oliver Schinagl oli...@schinagl.nl
---
 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/af9033.c  |  4 
 drivers/media/dvb-frontends/af9033.h  |  1 +
 drivers/media/dvb-frontends/af9033_priv.h | 36 +++
 drivers/media/usb/dvb-usb-v2/Kconfig  |  1 +
 drivers/media/usb/dvb-usb-v2/af9035.c | 12 +++
 drivers/media/usb/dvb-usb-v2/af9035.h |  1 +
 7 files changed, 56 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
 #define USB_PID_ASUS_U3000 0x171f
 #define USB_PID_ASUS_U3000H0x1736
 #define USB_PID_ASUS_U3100 0x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
 #define USB_PID_YUAN_EC372S0x1edc
 #define USB_PID_YUAN_STK7700PH 0x1f08
 #define USB_PID_YUAN_PD378S0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c 
b/drivers/media/dvb-frontends/af9033.c
index cd8c883..1568c6a 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -318,6 +318,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+   case AF9033_TUNER_FC2580:
+   len = ARRAY_SIZE(tuner_init_fc2580);
+   init = tuner_init_fc2580;
+   break;
default:
pr_debug(%s: unsupported tuner ID=%d\n, __func__,
state-cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h 
b/drivers/media/dvb-frontends/af9033.h
index 9e302c3..3dd6edd 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
 #define AF9033_TUNER_FC0011  0x28 /* Fitipower FC0011 */
 #define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
 #define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580  0x32 /* FCI FC2580 */
u8 tuner;
 
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h 
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..4126255 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,41 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
 };
 
+static const struct reg_val tuner_init_fc2580[] = {
+   { 0x800046, AF9033_TUNER_FC2580 },
+   { 0x800057, 0x01 },
+   { 0x800058, 0x00 },
+   { 0x80005f, 0x00 },
+   { 0x800060, 0x00 },
+   { 0x800071, 0x05 },
+   { 0x800072, 0x02 },
+   { 0x800074, 0x01 },
+   { 0x800079, 0x01 },
+   { 0x800093, 0x00 },
+   { 0x800094, 0x00 },
+   { 0x800095, 0x00 },
+   { 0x800096, 0x05 },
+   { 0x8000b3, 0x01 },
+   { 0x8000c3, 0x01 },
+   { 0x8000c4, 0x00 },
+   { 0x80f007, 0x00 },
+   { 0x80f00c, 0x19 },
+   { 0x80f00d, 0x1A },
+   { 0x80f00e, 0x00 },
+   { 0x80f00f, 0x02 },
+   { 0x80f010, 0x00 },
+   { 0x80f011, 0x02 },
+   { 0x80f012, 0x00 },
+   { 0x80f013, 0x02 },
+   { 0x80f014, 0x00 },
+   { 0x80f015, 0x02 },
+   { 0x80f01f, 0x96 },
+   { 0x80f020, 0x00 },
+   { 0x80f029, 0x96 },
+   { 0x80f02a, 0x00 },
+   { 0x80f077, 0x01 },
+   { 0x80f1e6, 0x01 },
+};
+
 #endif /* AF9033_PRIV_H */
 
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
b/drivers/media/usb/dvb-usb-v2/Kconfig
index e09930c..834bfec 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -40,6 +40,7 @@ config DVB_USB_AF9035
select MEDIA_TUNER_FC0011 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_TDA18218 if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_FC2580 if MEDIA_SUBDRV_AUTOSELECT
help
  Say Y here to support the Afatech AF9035 based DVB USB receiver.
 
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 9e5bbf9..952fbdb 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -546,6 +546,7 @@ static int af9035_read_config(struct dvb_usb_device *d)
case AF9033_TUNER_FC0011:
case AF9033_TUNER_MXL5007T:
case AF9033_TUNER_TDA18218:
+   case AF9033_TUNER_FC2580:

Re: [PATCH] Support for Asus MyCinema U3100Mini Plus

[Oliver Schinagl]

Hi All/Antti,

I used Antti's previous patch to try to get some support in for the Asus 
MyCinema U3100Mini Plus as it uses a supported driver (af9035) and now 
supported tuner (FCI FC2580).


It compiles fine and almost works :(

Here's what I get, which I have no idea what causes it.

dmesg output:
[  380.677434] usb 1-3: New USB device found, idVendor=0b05, idProduct=1779
[  380.677445] usb 1-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[  380.677452] usb 1-3: Product: AF9035A USB Device
[  380.677458] usb 1-3: Manufacturer: Afa Technologies Inc.
[  380.677463] usb 1-3: SerialNumber: AF01020abcdef12301
[  380.683361] input: Afa Technologies Inc. AF9035A USB Device as 
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input15
[  380.683505] hid-generic 0003:0B05:1779.0004: input: USB HID v1.01 
Keyboard [Afa Technologies Inc. AF9035A USB Device] on 
usb-:00:12.2-3/input1

[  380.703807] usbcore: registered new interface driver dvb_usb_af9035
[  380.704553] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold 
state
[  380.705075] usb 1-3: dvb_usbv2: downloading firmware from file 
'dvb-usb-af9035-02.fw'

[  381.014996] dvb_usb_af9035: firmware version=11.5.9.0
[  381.015018] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm 
state
[  381.017172] usb 1-3: dvb_usbv2: will pass the complete MPEG2 
transport stream to the software demuxer

[  381.017242] DVB: registering new adapter (Asus U3100Mini Plus)
[  381.037184] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[  381.037200] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech 
AF9033 (DVB-T))...

[  381.044197] i2c i2c-1: fc2580: i2c rd failed=-5 reg=01 len=1
[  381.044357] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while 
loading driver (-19)


using the following modules.
fc2580  4189  -1
af9033 10266  0
dvb_usb_af9035  8924  0
dvb_usbv2  11388  1 dvb_usb_af9035
dvb_core   71756  1 dvb_usbv2
rc_core10583  2 dvb_usbv2,dvb_usb_af9035

I'm supprised though that dvb-pll isn't there. Wasn't that a 
requirement? [1]


For the tuner 'script' firmware/init bit, I used the 'official' driver [2].

Also the i2c-addr and clock comes from these files.



One minor questions I have regarding the recently submitted RTL and 
AF9033 drivers, is one uses AF9033_TUNER_* whereas the other uses 
TUNER_RTL2832_*. Any reason for this? It just confused me is all.


Oliver

[1] http://linuxtv.org/wiki/index.php/DVB_via_USB#Introduction
[2] http://git.schinagl.nl/AF903x_SRC.git/tree/api/FCI_FC2580_Script.h


On 09/09/12 22:47, oli...@schinagl.nl wrote:

From: Oliver Schinagloli...@schinagl.nl

Initial support for the Asus MyCinema U3100Mini Plus. This currently
does not work however. It uses teh af9033/5 demodulater with an
FCI FC2580 tuner.

Signed-off-by: Oliver Schinagloli...@schinagl.nl
---
  drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
  drivers/media/dvb-frontends/af9033.c  |  4 
  drivers/media/dvb-frontends/af9033.h  |  1 +
  drivers/media/dvb-frontends/af9033_priv.h | 36 +++
  drivers/media/usb/dvb-usb-v2/Kconfig  |  1 +
  drivers/media/usb/dvb-usb-v2/af9035.c | 12 +++
  drivers/media/usb/dvb-usb-v2/af9035.h |  1 +
  7 files changed, 56 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
  #define USB_PID_ASUS_U30000x171f
  #define USB_PID_ASUS_U3000H   0x1736
  #define USB_PID_ASUS_U31000x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
  #define USB_PID_YUAN_EC372S   0x1edc
  #define USB_PID_YUAN_STK7700PH0x1f08
  #define USB_PID_YUAN_PD378S   0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c 
b/drivers/media/dvb-frontends/af9033.c
index cd8c883..1568c6a 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -318,6 +318,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+   case AF9033_TUNER_FC2580:
+   len = ARRAY_SIZE(tuner_init_fc2580);
+   init = tuner_init_fc2580;
+   break;
default:
pr_debug(%s: unsupported tuner ID=%d\n, __func__,
state-cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h 
b/drivers/media/dvb-frontends/af9033.h
index 9e302c3..3dd6edd 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
  #define AF9033_TUNER_FC0011  0x28 /* 

Re: [patch v2] [media] rc-core: prevent divide by zero bug in s_tx_carrier()

[walter harms]

Hi all,
I am not sure if that is a good idea.
it should be in the hands of the driver who to use these 'val'
some driver may need a higher value like this one:

static int iguanair_set_tx_carrier(struct rc_dev *dev, uint32_t carrier)
{
struct iguanair *ir = dev-priv;

if (carrier  25000 || carrier  15)
return -EINVAL;

There are also examples where 0 has a special meaning (to be fair not
with this function). Example:
  cfsetospeed() ...  The zero baud rate, B0, is used to terminate the 
connection.

I have no clue who will use the 0 but ...

just my 2 cents,
re,
 wh

Am 09.09.2012 22:31, schrieb Dan Carpenter:
 Several of the drivers use carrier as a divisor in their s_tx_carrier()
 functions.  We should do a sanity check here like we do for
 LIRC_SET_REC_CARRIER.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 ---
 v2: Ben Hutchings pointed out that my first patch was not a complete
 fix.
 
 diff --git a/drivers/media/rc/ir-lirc-codec.c 
 b/drivers/media/rc/ir-lirc-codec.c
 index 6ad4a07..28dc0f0 100644
 --- a/drivers/media/rc/ir-lirc-codec.c
 +++ b/drivers/media/rc/ir-lirc-codec.c
 @@ -211,6 +211,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
 int cmd,
   if (!dev-s_tx_carrier)
   return -EINVAL;
  
 + if (val = 0)
 + return -EINVAL;
 +
   return dev-s_tx_carrier(dev, val);
  
   case LIRC_SET_SEND_DUTY_CYCLE:




--
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] drivers: media: video: Add support for Aptina ar0130 sensor

[Guennadi Liakhovetski]

Hi Prashanth

On Fri, 7 Sep 2012, Prashanth Subramanya wrote:

 This driver adds basic support for Aptina ar0130 1.2M sensor.
 
 Signed-off-by: Prashanth Subramanya sprasha...@aptina.com
 ---
  drivers/media/video/Kconfig   |7 +
  drivers/media/video/Makefile  |1 +
  drivers/media/video/ar0130.c  | 1114 
 +
  drivers/media/video/ar0130_regs.h |  107 
  include/media/ar0130.h|   52 ++
  include/media/v4l2-chip-ident.h   |1 +
  6 files changed, 1282 insertions(+)
  create mode 100644 drivers/media/video/ar0130.c
  create mode 100644 drivers/media/video/ar0130_regs.h
  create mode 100644 include/media/ar0130.h
 
 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
 index 99937c9..54d7063 100644
 --- a/drivers/media/video/Kconfig
 +++ b/drivers/media/video/Kconfig
 @@ -493,6 +493,13 @@ config VIDEO_VS6624
 To compile this driver as a module, choose M here: the
 module will be called vs6624.
  
 +config VIDEO_AR0130
 + tristate Aptina AR0130 support
 + depends on I2C  VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 + ---help---
 + This is a Video4Linux2 sensor-level driver for the Aptina
 + ar0130 1.2 Mpixel camera.
 +
  config VIDEO_MT9M032
   tristate MT9M032 camera sensor support
   depends on I2C  VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
 index d209de0..a208911 100644
 --- a/drivers/media/video/Makefile
 +++ b/drivers/media/video/Makefile
 @@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
  obj-$(CONFIG_VIDEO_OV7670)   += ov7670.o
  obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
  obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
 +obj-$(CONFIG_VIDEO_AR0130) += ar0130.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
  obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
  obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
 diff --git a/drivers/media/video/ar0130.c b/drivers/media/video/ar0130.c
 new file mode 100644
 index 000..d257fe8
 --- /dev/null
 +++ b/drivers/media/video/ar0130.c
 @@ -0,0 +1,1114 @@
 +/*
 + * drivers/media/video/ar0130.c
 + *
 + * Aptina AR0130 sensor driver
 + *
 + * Copyright (C) 2012 Aptina Imaging
 + *
 + * Contributor Prashanth Subramanya sprasha...@aptina.com
 + *
 + * Based on MT9P031 driver
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * 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.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + *
 + */
 +
 +#include linux/delay.h
 +#include linux/device.h
 +#include linux/i2c.h
 +#include linux/log2.h
 +#include linux/pm.h
 +#include linux/slab.h
 +#include media/v4l2-subdev.h
 +#include linux/videodev2.h
 +#include linux/module.h
 +
 +#include media/ar0130.h
 +#include media/v4l2-chip-ident.h
 +#include media/v4l2-ctrls.h
 +#include media/v4l2-device.h
 +#include media/v4l2-subdev.h
 +#include media/soc_camera.h

Do you really need the soc_camera.h header? From a quick glance I didn't 
find any uses of the soc-camera API. If I missed them and you really are 
using the API, the driver should probably go under 
drivers/media/i2c/soc_camera/ and be submitted to the mainline via my 
tree. Since you're submitting your patch against an older tree, it is not 
clear, what your intended destination is. Further, since your driver is 
using the pad API, it very much looks like you don't need soc-camera. If 
this is the case, please, remove the header.

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

Re: pac7302-webcams and libv4lconvert interaction

[Hans de Goede]

Hi,

On 09/06/2012 05:13 PM, Frank Schäfer wrote:


Hi,

I'm currently looking into the gspca_pac7302-driver and how it interacts
with libv4lconvert.
This is how it currently works
- driver announces v4l2_pix_format 640x480 (width x height)
- the frames (jpeg) passed to userspace are encoded as 480x640 and this
complies with the jpeg-header we generate
- libv4lconvert checks width/height in the jpeg-header and compares them
with the image format announced by the kernel:
a) values are the same:
   1) V4LCONTROL_ROTATED_90_JPEG is NOT set for the device (standard
case):
   = everything is fine, image is decoded
   2) V4LCONTROL_ROTATED_90_JPEG is set for the device:
   = libv4lconvert bails out with -EIO displaying the error
message unexpected width / height in JPEG header: expected: 640x480,
header: 480x640
b) values are different:
   1) V4LCONTROL_ROTATED_90_JPEG is NOT set:
   = libv4lconvert bails out with -EIO displaying the error
message unexpected width / height in JPEG header: expected: 640x480,
header: 480x640
   2) V4LCONTROL_ROTATED_90_JPEG is set:
   = image is decoded and rotated correctly


Thinking about this for some minutes:

1) shouldn't the kernel always announce the real image format (size) of
the data it passes to userspace ?


It is passing the real size, the data is just in a vary funky format which
needs rotation as part of its decoding / decompression.


Current behavior seems inconsistent to me...
Announcing the actual image size allows applications which trust the API
value more than the value in the frame header to decode the image
correctly without using libv4lconvert (although the image would still be
rotated).


That assumes that the app would know how to decompress the data which it
will not know, these cams do not generate standard JPEG data, libv4lconvert's
decompression code is the only decompression code for this fsck-ed up JPEG-s,
short of the windows drivers code.


2) shouldn't libv4lconvert always rotate the image if
V4LCONTROL_ROTATED_90_JPEG is set for a device ?
It seems like a2) is a bug, because the expected size should be 640x480,
too.


rotating by 90 degrees also swaps the width and height, which are usually
not the same, so rotating an image which starts at 640x480 will yield
a final image of 480x640 which will not be what the app expects.



3) because all pac7302 devices are sending rotated image data, we should
add them ALL to libv4lconvert. Currently only 4 of the 14 devices are on
the list.
Do you want me to send a patch ?


I see you've send a patch in the mean time, I'll reply in more detail to
this to the patch mail.

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

Re: [PATCH 1/3] libv4lconvert: fix format of the error messages concerning jpeg frame size mismatch

[Hans de Goede]

Thanks, applied (and will be pushed to the official repo soon).

On 09/09/2012 08:36 PM, Frank Schäfer wrote:

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
  lib/libv4lconvert/jpeg.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/libv4lconvert/jpeg.c b/lib/libv4lconvert/jpeg.c
index e088a90..aa9cace 100644
--- a/lib/libv4lconvert/jpeg.c
+++ b/lib/libv4lconvert/jpeg.c
@@ -56,7 +56,7 @@ int v4lconvert_decode_jpeg_tinyjpeg(struct v4lconvert_data 
*data,
}

if (header_width != width || header_height != height) {
-   V4LCONVERT_ERR(unexpected width / height in JPEG header
+   V4LCONVERT_ERR(unexpected width / height in JPEG header: 
   expected: %ux%u, header: %ux%u\n,
   width, height, header_width, header_height);
errno = EIO;
@@ -288,7 +288,7 @@ int v4lconvert_decode_jpeg_libjpeg(struct v4lconvert_data 
*data,

if (data-cinfo.image_width  != width ||
data-cinfo.image_height != height) {
-   V4LCONVERT_ERR(unexpected width / height in JPEG header
+   V4LCONVERT_ERR(unexpected width / height in JPEG header: 
   expected: %ux%u, header: %ux%u\n, width,
   height, data-cinfo.image_width,
   data-cinfo.image_height);


--
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/3] libv4lconvert: pac7302-devices: remove unneeded flag V4LCONTROL_WANTS_WB

[Hans de Goede]

Hi,

On 09/09/2012 08:36 PM, Frank Schäfer wrote:

The gspca_pac7302 driver already provides this control.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
  lib/libv4lconvert/control/libv4lcontrol.c |   12 
  1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/lib/libv4lconvert/control/libv4lcontrol.c 
b/lib/libv4lconvert/control/libv4lcontrol.c
index 1272256..3d7a816 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -202,14 +202,10 @@ static const struct v4lcontrol_flags_info 
v4lcontrol_flags[] = {
{ 0x145f, 0x013a, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
{ 0x2001, 0xf115, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
/* Pac7302 based devices */
-   { 0x093a, 0x2620, 0x0f, NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
-   { 0x06f8, 0x3009, 0,NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
-   { 0x06f8, 0x301b, 0,NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
-   { 0x145f, 0x013c, 0,NULL, NULL,
-   V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
+   { 0x093a, 0x2620, 0x0f, NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x06f8, 0x3009, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x06f8, 0x301b, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x145f, 0x013c, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
/* Pac7311 based devices */
{ 0x093a, 0x2600, 0x0f, NULL, NULL, V4LCONTROL_WANTS_WB },
/* sq905 devices */



WANTS_WB does not add a whitebalance control, which these cameras indeed
already have, it adds a (software) autowhitebalance control, which enables
libv4lconvert doing software whitebalance correction. Although your
kernel patch for the pac7302 driver to pick a better default whitebalance
value, probably helps a lot to get the colors less screwed up, in the end
we still need some sort of awb to adjust to changing lightning conditions,
that is what this flag adds, as the pac7302 driver lacks awb.

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

Re: [PATCH 3/3] libv4lconvert: update the list of pac7302 webcams

[Hans de Goede]

Hi,

On 09/09/2012 08:36 PM, Frank Schäfer wrote:

All pac7302 webcams need image rotation, so synchronize the list with the 
driver.

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
  lib/libv4lconvert/control/libv4lcontrol.c |   13 -
  1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/lib/libv4lconvert/control/libv4lcontrol.c 
b/lib/libv4lconvert/control/libv4lcontrol.c
index 3d7a816..6eea121 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -202,10 +202,21 @@ static const struct v4lcontrol_flags_info 
v4lcontrol_flags[] = {
{ 0x145f, 0x013a, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
{ 0x2001, 0xf115, 0,NULL, NULL, V4LCONTROL_WANTS_WB, 1500 },
/* Pac7302 based devices */
-   { 0x093a, 0x2620, 0x0f, NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },


The 0x0f here is a mask, so this one entry covers all device ids from
0x2620 - 0x262f, so...


{ 0x06f8, 0x3009, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
{ 0x06f8, 0x301b, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2620, 0x0f, NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2611, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2622, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2624, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2625, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2626, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2627, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2628, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x2629, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x262a, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x093a, 0x262c, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },


The addition of all these is not necessary.


{ 0x145f, 0x013c, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },
+   { 0x1ae7, 0x2001, 0,NULL, NULL, V4LCONTROL_ROTATED_90_JPEG },


This one is necessary, I'll go and add it right away.

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

Re: [PATCH] Support for Asus MyCinema U3100Mini Plus

[Antti Palosaari]

On 09/09/2012 11:49 PM, Oliver Schinagl wrote:

Hi All/Antti,

I used Antti's previous patch to try to get some support in for the Asus
MyCinema U3100Mini Plus as it uses a supported driver (af9035) and now
supported tuner (FCI FC2580).

It compiles fine and almost works :(

Here's what I get, which I have no idea what causes it.

dmesg output:
[  380.677434] usb 1-3: New USB device found, idVendor=0b05, idProduct=1779
[  380.677445] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[  380.677452] usb 1-3: Product: AF9035A USB Device
[  380.677458] usb 1-3: Manufacturer: Afa Technologies Inc.
[  380.677463] usb 1-3: SerialNumber: AF01020abcdef12301
[  380.683361] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input15
[  380.683505] hid-generic 0003:0B05:1779.0004: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-:00:12.2-3/input1
[  380.703807] usbcore: registered new interface driver dvb_usb_af9035
[  380.704553] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold
state
[  380.705075] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[  381.014996] dvb_usb_af9035: firmware version=11.5.9.0
[  381.015018] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm
state
[  381.017172] usb 1-3: dvb_usbv2: will pass the complete MPEG2
transport stream to the software demuxer
[  381.017242] DVB: registering new adapter (Asus U3100Mini Plus)
[  381.037184] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[  381.037200] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[  381.044197] i2c i2c-1: fc2580: i2c rd failed=-5 reg=01 len=1
[  381.044357] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
loading driver (-19)


I2C communication to tuner chip does not work at all. It tries to read 
chip id register but fails. If you enable debugs you will see which 
error status af9035 reports.


There is likely 3 possibilities:
1) wrong I2C address
2) wrong GPIOs
 * tuner is not powered on or it is on standby
3) wrong firmware
 * it very unlikely that even wrong firmware fails basic I2C...


using the following modules.
fc2580  4189  -1
af9033 10266  0
dvb_usb_af9035  8924  0
dvb_usbv2  11388  1 dvb_usb_af9035
dvb_core   71756  1 dvb_usbv2
rc_core10583  2 dvb_usbv2,dvb_usb_af9035

I'm supprised though that dvb-pll isn't there. Wasn't that a
requirement? [1]


No. dvb-pll is used for old simple 4-byte PLLs. FCI FC2580 is modern 
silicon tuner. There is PLL used inside FC2580 for frequency synthesizer 
but no dvb-pll needed as all calculations are done inside that driver. 
Silicon tuners are so much more complicated to program than old 4-byte 
PLLs, thus own driver is needed for each silicon tuner chip.



For the tuner 'script' firmware/init bit, I used the 'official' driver [2].

Also the i2c-addr and clock comes from these files.


Aaah, now I see. At least I2C address is wrong. You use 0xac but should 
be 0x56. There is wrong 8-bit address used. 0xac  1 == 0x56.



16384000 (16.384MHz) is FC2580 internal clock what I understand. It 
should be OK. I suspect that everyone uses it for DVB-T to save 
components / make design simple.



One minor questions I have regarding the recently submitted RTL and
AF9033 drivers, is one uses AF9033_TUNER_* whereas the other uses
TUNER_RTL2832_*. Any reason for this? It just confused me is all.


It is just naming issue driver, driver author decision. Usually names 
start with driver name letters (in that case RTL28XXU_). It is not big 
issue for variable names unless it is too general to conflict some 
library. For function names driver names prefix (rtl28xxu_) should be 
used as it eases debugging (example ooops is dumped showing function names).



Antti



Oliver

[1] http://linuxtv.org/wiki/index.php/DVB_via_USB#Introduction
[2] http://git.schinagl.nl/AF903x_SRC.git/tree/api/FCI_FC2580_Script.h


On 09/09/12 22:47, oli...@schinagl.nl wrote:

From: Oliver Schinagloli...@schinagl.nl

Initial support for the Asus MyCinema U3100Mini Plus. This currently
does not work however. It uses teh af9033/5 demodulater with an
FCI FC2580 tuner.

Signed-off-by: Oliver Schinagloli...@schinagl.nl
---
  drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
  drivers/media/dvb-frontends/af9033.c  |  4 
  drivers/media/dvb-frontends/af9033.h  |  1 +
  drivers/media/dvb-frontends/af9033_priv.h | 36
+++
  drivers/media/usb/dvb-usb-v2/Kconfig  |  1 +
  drivers/media/usb/dvb-usb-v2/af9035.c | 12 +++
  drivers/media/usb/dvb-usb-v2/af9035.h |  1 +
  7 files changed, 56 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 

[GIT PULL FOR 3.7]: shark 1 2 / tea575x tea5777 AM support + misc gspca fixes

[Hans de Goede]

Hi Mauro,

Please pull from my media-for_v3.7 branch for AM frequency band support
for the shark 1  2 / tea575x  tea5777 AM support, as well as various
gspca and 2 pwc fixes.

The following changes since commit 79e8c7bebb467bbc3f2514d75bba669a3f354324:

  Merge tag 'v3.6-rc3' into staging/for_v3.7 (2012-08-24 11:25:10 -0300)

are available in the git repository at:


  git://linuxtv.org/hgoede/gspca.git media-for_v3.7

for you to fetch changes up to f16eef4206a3b155451d3fde19c5f4411ba5516e:

  gspca_pac7302: extend register documentation (2012-09-09 23:14:04 +0200)


Emil Goode (1):
  gspca: dubious one-bit signed bitfield

Ezequiel Garcia (2):
  pwc: Use vb2 queue mutex through a single name
  pwc: Remove unneeded struct vb2_queue clearing

Frank Schäfer (6):
  gspca_pac7302: add support for device 1ae7:2001 Speedlink Snappy 
Microphone SL-6825-SBK
  gspca_pac7302: make red balance and blue balance controls work again
  gspca_pac7302: add sharpness control
  gspca_pac7302: increase default value for white balance temperature
  gspca_pac7302: avoid duplicate calls of the image quality adjustment 
functions on capturing start
  gspca_pac7302: extend register documentation

Hans de Goede (10):
  media-api-docs: Documented V4L2_TUNER_CAP_HWSEEK_PROG_LIM in G_TUNER docs
  snd_tea575x: Add support for tuning AM
  radio-tea5777.c: Get rid of do_div usage
  radio-tea5777: Add support for tuning AM
  radio-shark2: Add support for suspend  resume
  radio-shark: Add support for suspend  resume
  gspca: Don't set gspca_dev-dev to NULL before stop0
  gspca_finepix: Remove unnecessary lock/unlock call
  gspca: Update / fix various comments wrt workqueue usb_lock usage
  gspca: Fix input urb creation / destruction surrounding suspend resume

Peter Senna Tschudin (1):
  drivers/media/usb/gspca/cpia1.c: fix error return code

 Documentation/DocBook/media/v4l/vidioc-g-tuner.xml |   6 +
 drivers/media/radio/radio-shark.c  |  44 -
 drivers/media/radio/radio-shark2.c |  39 
 drivers/media/radio/radio-tea5777.c| 197 +++-
 drivers/media/radio/radio-tea5777.h|   3 +
 drivers/media/usb/gspca/cpia1.c|   2 +-
 drivers/media/usb/gspca/finepix.c  |  18 +-
 drivers/media/usb/gspca/gspca.c|  12 +-
 drivers/media/usb/gspca/jl2005bcd.c|  18 +-
 drivers/media/usb/gspca/ov519.c|  16 +-
 drivers/media/usb/gspca/pac7302.c  |  47 +++--
 drivers/media/usb/gspca/sn9c20x.c  |   2 +
 drivers/media/usb/gspca/sonixj.c   |   2 +
 drivers/media/usb/gspca/sq905.c|  19 +-
 drivers/media/usb/gspca/sq905c.c   |  18 +-
 drivers/media/usb/gspca/vicam.c|  17 +-
 drivers/media/usb/gspca/xirlink_cit.c  |   4 +-
 drivers/media/usb/gspca/zc3xx.c|   8 +-
 drivers/media/usb/pwc/pwc-if.c |   3 +-
 include/sound/tea575x-tuner.h  |   4 +
 sound/i2c/other/tea575x-tuner.c| 200 +
 21 files changed, 519 insertions(+), 160 deletions(-)

Thanks  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

Re: [PATCH 1/6] gspca_pac7302: add support for device 1ae7:2001 Speedlink Snappy Microphone SL-6825-SBK

[Hans de Goede]

Hi,

Entire series applied and included in my pull-req for 3.7 which I just send out.

Thanks,

Hans


On 09/09/2012 08:02 PM, Frank Schäfer wrote:

Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Cc: sta...@kernel.org
---
  drivers/media/usb/gspca/pac7302.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/usb/gspca/pac7302.c 
b/drivers/media/usb/gspca/pac7302.c
index 4877f7a..e906f56 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -905,6 +905,7 @@ static const struct usb_device_id device_table[] = {
{USB_DEVICE(0x093a, 0x262a)},
{USB_DEVICE(0x093a, 0x262c)},
{USB_DEVICE(0x145f, 0x013c)},
+   {USB_DEVICE(0x1ae7, 0x2001)}, /* SpeedLink Snappy Mic SL-6825-SBK */
{}
  };
  MODULE_DEVICE_TABLE(usb, device_table);


--
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 14/14] drivers/media/usb/gspca/cpia1.c: fix error return code

[Hans de Goede]

Hi,

Applied to my gspca tree and included in my pull-req for 3.7 which I just send 
out.

Thanks,

Hans


On 09/06/2012 05:24 PM, Peter Senna Tschudin wrote:

From: Peter Senna Tschudin peter.se...@gmail.com

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

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

// smpl
(
if@p1 (\(ret  0\|ret != 0\))
  { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
 when != ret
*if(...)
{
   ... when != ret = e2
   when forall
  return ret;
}

// /smpl

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

---
  drivers/media/usb/gspca/cpia1.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
index 2499a88..b3ba47d 100644
--- a/drivers/media/usb/gspca/cpia1.c
+++ b/drivers/media/usb/gspca/cpia1.c
@@ -751,7 +751,7 @@ static int goto_high_power(struct gspca_dev *gspca_dev)
if (signal_pending(current))
return -EINTR;

-   do_command(gspca_dev, CPIA_COMMAND_GetCameraStatus, 0, 0, 0, 0);
+   ret = do_command(gspca_dev, CPIA_COMMAND_GetCameraStatus, 0, 0, 0, 0);
if (ret)
return ret;


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


--
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 02/10] pwc: Remove unneeded struct vb2_queue clearing

[Hans de Goede]

Hi,

Thanks! Applied to my gspca / media / pwc tree and included in my pull-req for 
3.7 which I just send out.

Regards,

Hans


On 08/23/2012 03:08 PM, Ezequiel Garcia wrote:

struct vb2_queue is allocated through kzalloc as part of a larger struct,
there's no need to clear it.

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

diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index de7c7ba..825c61a 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -994,7 +994,6 @@ static int usb_pwc_probe(struct usb_interface *intf, const 
struct usb_device_id
pdev-power_save = my_power_save;

/* Init videobuf2 queue structure */
-   memset(pdev-vb_queue, 0, sizeof(pdev-vb_queue));
pdev-vb_queue.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
pdev-vb_queue.io_modes = VB2_MMAP | VB2_USERPTR | VB2_READ;
pdev-vb_queue.drv_priv = pdev;


--
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] gspca: Fix locking issues related to suspend/resume

[Hans de Goede]

Hi,

Thanks for the report, it turns out that the checking for gspca_dev-dev,
rather then gspca_dev-present (which is a mod I made on top of
Hans Verkuil's orginal patch), turns out to be a bad idea in general
as its racy, this race has been fixed by this commit:
http://git.linuxtv.org/hgoede/gspca.git/commitdiff/a454f0811950742475b76dbf5ac10876e48ffaaa

Which should also appease the static checker warnings.

Thanks  Regards,

Hans


On 07/19/2012 02:13 PM, Dan Carpenter wrote:

Hello Hans Verkuil,

This is a semi-automatic email about new static checker warnings.

The patch 254902b01d2a: [media] gspca: Fix locking issues related to
suspend/resume from May 6, 2012, leads to the following Smatch
complaint:

drivers/media/video/gspca/sq905c.c:176 sq905c_dostream()
 warn: variable dereferenced before check 'gspca_dev-dev' (see line 
180)

drivers/media/video/gspca/sq905c.c
158  /* Request the header, which tells the size to 
download */
159  ret = usb_bulk_msg(gspca_dev-dev,
160  usb_rcvbulkpipe(gspca_dev-dev, 0x81),
 ^^
Derereference inside the calls to usb_bulk_msg() and usb_rcvbulkpipe().

161  buffer, FRAME_HEADER_LEN, act_len,
162  SQ905C_DATA_TIMEOUT);
163  PDEBUG(D_STREAM,
164  Got %d bytes out of %d for header,
165  act_len, FRAME_HEADER_LEN);
166  if (ret  0 || act_len  FRAME_HEADER_LEN)
167  goto quit_stream;
168  /* size is read from 4 bytes starting 0x40, little 
endian */
169  bytes_left = 
buffer[0x40]|(buffer[0x41]8)|(buffer[0x42]16)
170  |(buffer[0x43]24);
171  PDEBUG(D_STREAM, bytes_left = 0x%x, bytes_left);
172  /* We keep the header. It has other information, too. 
*/
173  packet_type = FIRST_PACKET;
174  gspca_frame_add(gspca_dev, packet_type,
175  buffer, FRAME_HEADER_LEN);
176 while (bytes_left  0  gspca_dev-dev) {
  ^^
New check.

177 data_len = bytes_left  SQ905C_MAX_TRANSFER ?
178 SQ905C_MAX_TRANSFER : bytes_left;
179 ret = usb_bulk_msg(gspca_dev-dev,
180 usb_rcvbulkpipe(gspca_dev-dev, 0x81),
 ^^
Some more dereferences here.

181 buffer, data_len, act_len,
182 SQ905C_DATA_TIMEOUT);
183  if (ret  0 || act_len  data_len)
184  goto quit_stream;
185  PDEBUG(D_STREAM,
186  Got %d bytes out of %d for frame,
187  data_len, bytes_left);
188  bytes_left -= data_len;
189  if (bytes_left == 0)
190  packet_type = LAST_PACKET;
191  else
192  packet_type = INTER_PACKET;
193  gspca_frame_add(gspca_dev, packet_type,
194  buffer, data_len);
195  }

regards,
dan carpenter

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


--
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 v2] [media] rc-core: prevent divide by zero bug in s_tx_carrier()

[Ben Hutchings]

On Sun, 2012-09-09 at 23:01 +0200, walter harms wrote:
 Hi all,
 I am not sure if that is a good idea.
 it should be in the hands of the driver who to use these 'val'

 some driver may need a higher value like this one:

I doubt that any driver can actually work with the full range of
positive values, but at least they're less likely to crash.

 static int iguanair_set_tx_carrier(struct rc_dev *dev, uint32_t carrier)
 {
   struct iguanair *ir = dev-priv;
 
   if (carrier  25000 || carrier  15)
   return -EINVAL;
 
 There are also examples where 0 has a special meaning (to be fair not
 with this function). Example:
   cfsetospeed() ...  The zero baud rate, B0, is used to terminate the 
 connection.

 I have no clue who will use the 0 but ...
[...]

If an ioctl is defined for a whole class of devices then it is perfectly
valid for the core code for that class to do (some) parameter validation
for the ioctl.  As I'm not really familiar with LIRC I can't say for
sure that 0 is invalid, but if it is then driver writers should not
expect to be able to assign a driver-specific meaning to it.  Consider
what would happen if the LIRC developers wanted to assign a generic
meaning to a value of 0 some time later.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Support for Asus MyCinema U3100Mini Plus

[Oliver Schinagl]

On 09/09/12 23:51, Antti Palosaari wrote:

On 09/09/2012 11:49 PM, Oliver Schinagl wrote:

Hi All/Antti,

I used Antti's previous patch to try to get some support in for the Asus
MyCinema U3100Mini Plus as it uses a supported driver (af9035) and now
supported tuner (FCI FC2580).

It compiles fine and almost works :(

Here's what I get, which I have no idea what causes it.

dmesg output:
[ 380.677434] usb 1-3: New USB device found, idVendor=0b05,
idProduct=1779
[ 380.677445] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 380.677452] usb 1-3: Product: AF9035A USB Device
[ 380.677458] usb 1-3: Manufacturer: Afa Technologies Inc.
[ 380.677463] usb 1-3: SerialNumber: AF01020abcdef12301
[ 380.683361] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input15
[ 380.683505] hid-generic 0003:0B05:1779.0004: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-:00:12.2-3/input1
[ 380.703807] usbcore: registered new interface driver dvb_usb_af9035
[ 380.704553] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold
state
[ 380.705075] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[ 381.014996] dvb_usb_af9035: firmware version=11.5.9.0
[ 381.015018] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm
state
[ 381.017172] usb 1-3: dvb_usbv2: will pass the complete MPEG2
transport stream to the software demuxer
[ 381.017242] DVB: registering new adapter (Asus U3100Mini Plus)
[ 381.037184] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[ 381.037200] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[ 381.044197] i2c i2c-1: fc2580: i2c rd failed=-5 reg=01 len=1
[ 381.044357] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
loading driver (-19)


I2C communication to tuner chip does not work at all. It tries to read
chip id register but fails. If you enable debugs you will see which
error status af9035 reports.

CONFIG_DVB_USB_DEBUG was enabled, but nothing extra :(



There is likely 3 possibilities:
1) wrong I2C address

Well as linked before, I used it from the 'official' driver, where it says:
#define FC2580_ADDRESS 0xAC

grepping the entire source of theirs, I then found this in FC2580.c
TunerDescription tuner_FC2580 = {
   FC2580_open,/** Function to open tuner.*/
   FC2580_close,   /** Function to close tuner.   */
   FC2580_set, /** Function set frequency.*/
   FC2580_scripts, /** Scripts.   */
   FC2580_scriptSets,  /** Length of scripts. */
   FC2580_ADDRESS, /** The I2C address of tuner.  */
   1,  /** Valid length of tuner register.*/
   0,  /** IF frequency of tuner. */
   True,   /** Spectrum inversion.*/
   0x32,   /** tuner id   */
};

The only other thing that I recognize is the scripts, which is some init 
code (which I asked about below, which should also be right, unless I 
made a typo) and the tuner id, which is the first thing in the script 
and in my patch defined as AF9033_TUNER_FC2580. No idea of its 
significance :)



2) wrong GPIOs
* tuner is not powered on or it is on standby

How/where would I check that?


3) wrong firmware
* it very unlikely that even wrong firmware fails basic I2C...
I know there's a few versions right? the 01 02 etc? But that is mostly 
in relation with the af9035 mostly right?





using the following modules.
fc2580 4189 -1
af9033 10266 0
dvb_usb_af9035 8924 0
dvb_usbv2 11388 1 dvb_usb_af9035
dvb_core 71756 1 dvb_usbv2
rc_core 10583 2 dvb_usbv2,dvb_usb_af9035

I'm supprised though that dvb-pll isn't there. Wasn't that a
requirement? [1]


No. dvb-pll is used for old simple 4-byte PLLs. FCI FC2580 is modern
silicon tuner. There is PLL used inside FC2580 for frequency synthesizer
but no dvb-pll needed as all calculations are done inside that driver.
Silicon tuners are so much more complicated to program than old 4-byte
PLLs, thus own driver is needed for each silicon tuner chip.

Ah, well then the wiki needs a small update ;)



For the tuner 'script' firmware/init bit, I used the 'official' driver
[2].

Also the i2c-addr and clock comes from these files.


Aaah, now I see. At least I2C address is wrong. You use 0xac but should
be 0x56. There is wrong 8-bit address used. 0xac  1 == 0x56.
That I don't understand (as I wrote above) 0xac 'should' be the correct, 
but appearantly it needs to be shifted. Why?





16384000 (16.384MHz) is FC2580 internal clock what I understand. It
should be OK. I suspect that everyone uses it for DVB-T to save
components / make design simple.
I would assume so, since also that is in the original sources; fc2580.c 
lists it as:

#define FREQ_XTAL   16384   //16.384MHz

Re: [patch v2] [media] rc-core: prevent divide by zero bug in s_tx_carrier()

[Sean Young]

On Sun, Sep 09, 2012 at 11:31:42PM +0300, Dan Carpenter wrote:
 Several of the drivers use carrier as a divisor in their s_tx_carrier()
 functions.  We should do a sanity check here like we do for
 LIRC_SET_REC_CARRIER.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 ---
 v2: Ben Hutchings pointed out that my first patch was not a complete
 fix.
 
 diff --git a/drivers/media/rc/ir-lirc-codec.c 
 b/drivers/media/rc/ir-lirc-codec.c
 index 6ad4a07..28dc0f0 100644
 --- a/drivers/media/rc/ir-lirc-codec.c
 +++ b/drivers/media/rc/ir-lirc-codec.c
 @@ -211,6 +211,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
 int cmd,
   if (!dev-s_tx_carrier)
   return -EINVAL;

This should be ENOSYS.

  
 + if (val = 0)
 + return -EINVAL;
 +

1) val is unsigned so it would never be less than zero.

2) A value of zero means disabling carrier modulation, which is used by 
   the mceusb driver.

So the check belongs in the individual drivers, as in the original patch.


Sean
--
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] Support for Asus MyCinema U3100Mini Plus

[Antti Palosaari]

On 09/10/2012 01:26 AM, Oliver Schinagl wrote:

On 09/09/12 23:51, Antti Palosaari wrote:

On 09/09/2012 11:49 PM, Oliver Schinagl wrote:

Hi All/Antti,

I used Antti's previous patch to try to get some support in for the Asus
MyCinema U3100Mini Plus as it uses a supported driver (af9035) and now
supported tuner (FCI FC2580).

It compiles fine and almost works :(

Here's what I get, which I have no idea what causes it.

dmesg output:
[ 380.677434] usb 1-3: New USB device found, idVendor=0b05,
idProduct=1779
[ 380.677445] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 380.677452] usb 1-3: Product: AF9035A USB Device
[ 380.677458] usb 1-3: Manufacturer: Afa Technologies Inc.
[ 380.677463] usb 1-3: SerialNumber: AF01020abcdef12301
[ 380.683361] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input15
[ 380.683505] hid-generic 0003:0B05:1779.0004: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-:00:12.2-3/input1
[ 380.703807] usbcore: registered new interface driver dvb_usb_af9035
[ 380.704553] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold
state
[ 380.705075] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[ 381.014996] dvb_usb_af9035: firmware version=11.5.9.0
[ 381.015018] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm
state
[ 381.017172] usb 1-3: dvb_usbv2: will pass the complete MPEG2
transport stream to the software demuxer
[ 381.017242] DVB: registering new adapter (Asus U3100Mini Plus)
[ 381.037184] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[ 381.037200] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[ 381.044197] i2c i2c-1: fc2580: i2c rd failed=-5 reg=01 len=1
[ 381.044357] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
loading driver (-19)


I2C communication to tuner chip does not work at all. It tries to read
chip id register but fails. If you enable debugs you will see which
error status af9035 reports.

CONFIG_DVB_USB_DEBUG was enabled, but nothing extra :(



There is likely 3 possibilities:
1) wrong I2C address

Well as linked before, I used it from the 'official' driver, where it says:
#define FC2580_ADDRESS 0xAC

grepping the entire source of theirs, I then found this in FC2580.c
TunerDescription tuner_FC2580 = {
FC2580_open,/** Function to open tuner.*/
FC2580_close,   /** Function to close tuner.   */
FC2580_set, /** Function set frequency.*/
FC2580_scripts, /** Scripts.   */
FC2580_scriptSets,  /** Length of scripts. */
FC2580_ADDRESS, /** The I2C address of tuner.  */
1,  /** Valid length of tuner register.*/
0,  /** IF frequency of tuner. */
True,   /** Spectrum inversion.*/
0x32,   /** tuner id   */
};

The only other thing that I recognize is the scripts, which is some init
code (which I asked about below, which should also be right, unless I
made a typo) and the tuner id, which is the first thing in the script
and in my patch defined as AF9033_TUNER_FC2580. No idea of its
significance :)


2) wrong GPIOs
* tuner is not powered on or it is on standby

How/where would I check that?


3) wrong firmware
* it very unlikely that even wrong firmware fails basic I2C...

I know there's a few versions right? the 01 02 etc? But that is mostly
in relation with the af9035 mostly right?




using the following modules.
fc2580 4189 -1
af9033 10266 0
dvb_usb_af9035 8924 0
dvb_usbv2 11388 1 dvb_usb_af9035
dvb_core 71756 1 dvb_usbv2
rc_core 10583 2 dvb_usbv2,dvb_usb_af9035

I'm supprised though that dvb-pll isn't there. Wasn't that a
requirement? [1]


No. dvb-pll is used for old simple 4-byte PLLs. FCI FC2580 is modern
silicon tuner. There is PLL used inside FC2580 for frequency synthesizer
but no dvb-pll needed as all calculations are done inside that driver.
Silicon tuners are so much more complicated to program than old 4-byte
PLLs, thus own driver is needed for each silicon tuner chip.

Ah, well then the wiki needs a small update ;)



For the tuner 'script' firmware/init bit, I used the 'official' driver
[2].

Also the i2c-addr and clock comes from these files.


Aaah, now I see. At least I2C address is wrong. You use 0xac but should
be 0x56. There is wrong 8-bit address used. 0xac  1 == 0x56.

That I don't understand (as I wrote above) 0xac 'should' be the correct,
but appearantly it needs to be shifted. Why?


Because it is wrong in vendor driver you look. I2C addresses are 7 bit 
long and LSB bit used for direction (read or write). Try to search some 
I2C tutorials. This kind of wrong I2C addresses are called usually 8-bit 
I2C address.

Re: [patch v2] [media] rc-core: prevent divide by zero bug in s_tx_carrier()

[Ben Hutchings]

On Sun, 2012-09-09 at 23:26 +0100, Sean Young wrote:
 On Sun, Sep 09, 2012 at 11:31:42PM +0300, Dan Carpenter wrote:
  Several of the drivers use carrier as a divisor in their s_tx_carrier()
  functions.  We should do a sanity check here like we do for
  LIRC_SET_REC_CARRIER.
  
  Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
  ---
  v2: Ben Hutchings pointed out that my first patch was not a complete
  fix.
  
  diff --git a/drivers/media/rc/ir-lirc-codec.c 
  b/drivers/media/rc/ir-lirc-codec.c
  index 6ad4a07..28dc0f0 100644
  --- a/drivers/media/rc/ir-lirc-codec.c
  +++ b/drivers/media/rc/ir-lirc-codec.c
  @@ -211,6 +211,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
  int cmd,
  if (!dev-s_tx_carrier)
  return -EINVAL;
 
 This should be ENOSYS.
 
   
  +   if (val = 0)
  +   return -EINVAL;
  +
 
 1) val is unsigned so it would never be less than zero.
 
 2) A value of zero means disabling carrier modulation, which is used by 
the mceusb driver.

 So the check belongs in the individual drivers, as in the original patch.

Oh well, sorry for pointing Dan in the wrong direction.  Is the special
case documented somewhere?

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.


signature.asc
Description: This is a digitally signed message part

[PATCH v5] media: v4l2-ctrls: add control for dpcm predictor

[Prabhakar Lad]

From: Lad, Prabhakar prabhakar@ti.com

add V4L2_CID_DPCM_PREDICTOR control of type menu, which
determines the dpcm predictor. The predictor can be either
simple or advanced.

Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rob Landley r...@landley.net
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.

Changes for v5:
1: Changed the control's name to 'Simple' and  'Advanced'
   as pointed by Sakari.
2: Changed the description of DPCM. Thanks to Sakari for
   providing the description.

Changes for v4:
1: Aligned the description to fit appropriately in the
   para tag, pointed by Sylwester.

Changes for v3:
1: Added better explanation for DPCM, pointed by Hans.

Changes for v2:
1: Added documentaion in controls.xml pointed by Sylwester.
2: Chnaged V4L2_DPCM_PREDICTOR_ADVANCE to V4L2_DPCM_PREDICTOR_ADVANCED
   pointed by Sakari.

 Documentation/DocBook/media/v4l/controls.xml |   39 +-
 drivers/media/v4l2-core/v4l2-ctrls.c |9 ++
 include/linux/videodev2.h|5 +++
 3 files changed, 52 insertions(+), 1 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index 93b9c68..2c1599f 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4267,7 +4267,44 @@ interface and may change in the future./para
pixels / second.
/entry
  /row
- rowentry/entry/row
+ row
+   entry 
spanname=idconstantV4L2_CID_DPCM_PREDICTOR/constant/entry
+   entrymenu/entry
+ /row
+ row id=v4l2-dpcm-predictor
+   entry spanname=descr Differential pulse-code modulation (DPCM) 
compression can
+   be used to compress the samples into fewer bits than they would 
otherwise require.
+   This is done by calculating the difference between consecutive 
samples and outputting
+   the difference which in average is much smaller than the values of 
the samples
+   themselves since there is generally lots of correlation between 
adjacent pixels. In
+   decompression the original samples are reconstructed. The process 
isn't lossless as
+   the encoded sample size in bits is less than the original.
+
+   paraFormats using DPCM compression include xref 
linkend=pixfmt-srggb10dpcm8 /./para
+
+   paraThis control is used to select the predictor used to encode 
the samples./para
+
+   paraThe main difference between the simple and the advanced 
predictors is image quality,
+   with advanced predictor supposed to produce better quality images 
as a result. Simple
+   predictor can be used e.g. for testing purposes. For more 
information about DPCM see ulink
+   
url=http://en.wikipedia.org/wiki/Differential_pulse-code_modulation;Wikipedia/ulink./para
+   /entry
+ /row
+ row
+   entrytbl spanname=descr cols=2
+ tbody valign=top
+   row
+entryconstantV4L2_DPCM_PREDICTOR_SIMPLE/constant/entry
+ entryPredictor type is simple/entry
+   /row
+   row
+ 
entryconstantV4L2_DPCM_PREDICTOR_ADVANCED/constant/entry
+ entryPredictor type is advanced/entry
+   /row
+ /tbody
+   /entrytbl
+ /row
+   rowentry/entry/row
/tbody
   /tgroup
   /table
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6a2ee7..8f2f40b 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -425,6 +425,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Gray,
NULL,
};
+   static const char * const dpcm_predictor[] = {
+   Simple,
+   Advanced,
+   NULL,
+   };
 
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +507,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+   case V4L2_CID_DPCM_PREDICTOR:
+   return dpcm_predictor;
 
default:
return NULL;
@@ -732,6 +739,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IMAGE_PROC_CLASS: return Image Processing 
Controls;
case