Re: [PATCH] Fix VIDIOC_TRY_EXT_CTRLS regression

2012-07-30 Thread Hans Verkuil
On Mon July 30 2012 03:25:58 Mauro Carvalho Chehab wrote:
 Em 18-07-2012 10:34, Hans Verkuil escreveu:
  Hi all,
  
  This patch fixes an omission in the new v4l2_ioctls table: 
  VIDIOC_TRY_EXT_CTRLS
  must get the INFO_FL_CTRL flag, just like all the other control related 
  ioctls.
  
  Otherwise the ioctl core won't know it also has to check whether 
  v4l2_fh-ctrl_handler
  is non-zero before it can decide that this ioctl is not implemented.
  
  Caught by v4l2-compliance while I was testing the mem2mem_testdev driver.
 
 Missing SOB. It seems Steven asked for this fix. Did he test? If so, it would 
 be
 nice to get his tested-by:.

Oops!

Here it is:

Signed-off-by: Hans Verkuil hans.verk...@cisco.com

Welcome back!

Regards,

Hans

 
 Regards,
 Mauro
  
  Regards,
  
  Hans
  
  diff --git a/drivers/media/video/v4l2-ioctl.c 
  b/drivers/media/video/v4l2-ioctl.c
  index 70e0efb..17dff31 100644
  --- a/drivers/media/video/v4l2-ioctl.c
  +++ b/drivers/media/video/v4l2-ioctl.c
  @@ -1900,7 +1900,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
  IOCTL_INFO_FNC(VIDIOC_LOG_STATUS, v4l_log_status, v4l_print_newline, 0),
  IOCTL_INFO_FNC(VIDIOC_G_EXT_CTRLS, v4l_g_ext_ctrls, 
  v4l_print_ext_controls, INFO_FL_CTRL),
  IOCTL_INFO_FNC(VIDIOC_S_EXT_CTRLS, v4l_s_ext_ctrls, 
  v4l_print_ext_controls, INFO_FL_PRIO | INFO_FL_CTRL),
  -   IOCTL_INFO_FNC(VIDIOC_TRY_EXT_CTRLS, v4l_try_ext_ctrls, 
  v4l_print_ext_controls, 0),
  +   IOCTL_INFO_FNC(VIDIOC_TRY_EXT_CTRLS, v4l_try_ext_ctrls, 
  v4l_print_ext_controls, INFO_FL_CTRL),
  IOCTL_INFO_STD(VIDIOC_ENUM_FRAMESIZES, vidioc_enum_framesizes, 
  v4l_print_frmsizeenum, INFO_FL_CLEAR(v4l2_frmsizeenum, pixel_format)),
  IOCTL_INFO_STD(VIDIOC_ENUM_FRAMEINTERVALS, vidioc_enum_frameintervals, 
  v4l_print_frmivalenum, INFO_FL_CLEAR(v4l2_frmivalenum, height)),
  IOCTL_INFO_STD(VIDIOC_G_ENC_INDEX, vidioc_g_enc_index, 
  v4l_print_enc_idx, 0),
  --
  To unsubscribe from this list: send the line unsubscribe linux-media in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
 
--
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 2/2] Initial version of RDS Control utility Signed-off-by: Konke Radlow krad...@cisco.com

2012-07-30 Thread Hans Verkuil
On Sat July 28 2012 13:11:13 Hans de Goede wrote:
 Hi,
 
 Overall this looks good, but some of the code, for example the set/get freq 
 and
 get/set tuner stuff seems to be a 1 on 1 copy of code from v4l2-ctrl, please
 factor this out into a common file which can be shared between both
 utilities (I think Hans V's recent work on splitting v4l2-ctl into multiple
 files comes a long way towards this).

I'm not sure how valuable this is. If we do this, then that means a fair amount
of work in v4l2-ctl (although the split was a major step forward in that 
direction).

There are a bunch of utilities that all share some common code in that respect.
But they are all stand-alone and I would have to think carefully how to organize
the code if you want to make it easy to share code.

Bottom-line: let's keep this as a separate project and not mix it with rds-ctl.

Regards,

Hans

 
 Regards,
 
 Hans
 
 On 07/25/2012 07:44 PM, Konke Radlow wrote:
  ---
Makefile.am   |3 +-
configure.ac  |1 +
utils/rds-ctl/Makefile.am |5 +
utils/rds-ctl/rds-ctl.cpp |  978 
  +
4 files changed, 986 insertions(+), 1 deletion(-)
create mode 100644 utils/rds-ctl/Makefile.am
create mode 100644 utils/rds-ctl/rds-ctl.cpp
 
  diff --git a/Makefile.am b/Makefile.am
  index 6707f5f..47103a1 100644
  --- a/Makefile.am
  +++ b/Makefile.am
  @@ -18,7 +18,8 @@ SUBDIRS += \
  utils/v4l2-compliance \
  utils/v4l2-ctl \
  utils/v4l2-dbg \
  -   utils/v4l2-sysfs-path
  +   utils/v4l2-sysfs-path \
  +   utils/rds-ctl
 
if LINUX_OS
SUBDIRS += \
  diff --git a/configure.ac b/configure.ac
  index 1d7eb29..1ad99e6 100644
  --- a/configure.ac
  +++ b/configure.ac
  @@ -28,6 +28,7 @@ AC_CONFIG_FILES([Makefile
  utils/v4l2-sysfs-path/Makefile
  utils/xc3028-firmware/Makefile
  utils/qv4l2/Makefile
  +   utils/rds-ctl/Makefile
 
  contrib/freebsd/Makefile
  contrib/test/Makefile
  diff --git a/utils/rds-ctl/Makefile.am b/utils/rds-ctl/Makefile.am
  new file mode 100644
  index 000..9a84257
  --- /dev/null
  +++ b/utils/rds-ctl/Makefile.am
  @@ -0,0 +1,5 @@
  +bin_PROGRAMS = rds-ctl
  +
  +rds_ctl_SOURCES = rds-ctl.cpp
  +rds_ctl_LDADD = ../../lib/libv4l2/libv4l2.la 
  ../../lib/libv4l2rds/libv4l2rds.la
  +
  diff --git a/utils/rds-ctl/rds-ctl.cpp b/utils/rds-ctl/rds-ctl.cpp
  new file mode 100644
  index 000..8ddb969
  --- /dev/null
  +++ b/utils/rds-ctl/rds-ctl.cpp
  @@ -0,0 +1,978 @@
  +/*
  + * rds-ctl.cpp is based on v4l2-ctl.cpp
  + *
  + * the following applies for all RDS related parts:
  + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights 
  reserved.
  + * Author: Konke Radlow korad...@gmail.com
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU Lesser General Public License as 
  published by
  + * the Free Software Foundation; either version 2.1 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, Suite 500, Boston, MA  02110-1335 
   USA
  + */
  +
  +#include unistd.h
  +#include stdlib.h
  +#include stdio.h
  +#include string.h
  +#include wchar.h
  +#include locale.h
  +#include inttypes.h
  +#include getopt.h
  +#include sys/types.h
  +#include fcntl.h
  +#include errno.h
  +#include sys/ioctl.h
  +#include sys/time.h
  +#include dirent.h
  +#include config.h
  +#include signal.h
  +
  +#ifdef HAVE_SYS_KLOG_H
  +#include sys/klog.h
  +#endif
  +
  +#include linux/videodev2.h
  +#include libv4l2.h
  +#include libv4l2rds.h
  +
  +#include list
  +#include vector
  +#include map
  +#include string
  +#include algorithm
  +
  +#define ARRAY_SIZE(arr) ((int)(sizeof(arr) / sizeof((arr)[0])))
  +
  +typedef std::vectorstd::string dev_vec;
  +typedef std::mapstd::string, std::string dev_map;
  +
  +/* Short option list
  +
  +   Please keep in alphabetical order.
  +   That makes it easier to see which short options are still free.
  +
  +   In general the lower case is used to set something and the upper
  +   case is used to retrieve a setting. */
  +enum Option {
  +   OptSetDevice = 'd',
  +   OptGetDriverInfo = 'D',
  +   OptGetFreq = 'F',
  +   OptSetFreq = 'f',
  +   OptHelp = 'h',
  +   OptReadRds = 'R',
  +   OptGetTuner = 'T',
  +   OptSetTuner = 't',
  +   OptUseWrapper = 'w',
  +   OptAll = 128,
  +   OptFreqSeek,
  +   OptListDevices,
  +   OptOpenFile,
  +   OptPrintBlock,
  +   OptSilent,
  +   OptTunerIndex,
  +   OptVerbose,
  +   

Re: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread poma
On 06/27/2012 07:21 AM, Thomas Mair wrote:
 On 26.06.2012 19:17, poma wrote:
 On 05/28/2012 04:48 PM, Thomas Mair wrote:
 On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing 
 and did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It 
 is almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].


 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.

 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.

 I have some spare time today and will investigate the problem further.


 I tried a few things regarding the problem today and could find out a 
 few more details, but could not resolve the issue.

 The GPIO pin configuration for the devices with the fc0012 (and probably
 also with the fc0013) tuner is the following:

 GPIO0: demod power
 GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it 
 again)
 GPIO4: tuner power? (maybe antenna power?)
 GPIO5: tuner reset
 GPIO6: UHF/VHF band selection

 All of these GPIOs are configured as output. When the device is plugged in
 the tuner is powered up correctly, but I am not able to power it up when
 a reboot is performed. What I tried was the following:

 - on rtl28xxu_power_ctrl off:
   - GPIO4 = 1 (off)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl28xxu_power_ctrl on:
   - GPIO3 = 1
   - GPIO4 = 0 (on)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl2832_frontend_attach:
   - GPIO5 = 1 
   - GPIO5 = 0 

 This sequence should ensure that the tuner is powered on when the frontend
 is attached, and a tuner reset is being performed before the tuner is 
 probed.
 However this sequence fails the same way as it did before. I tried to add
 timeouts to be sure that the tuner is not probed while it is reset but that
 did not help either.

 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on the 
 tuner whatsoever.

 Is there anybody who could look at the code, or maybe knows what could be
 the cause of the problem? I suspect I am just too blind to see my own 
 mistakes.

 Regards
 Thomas


 Cheers Thomas, Hans-Frieder, Antti, Mauro!
 Hans-Frieder, are you having the same issue with fc0011af9035?
 Antti, no tricks up your sleeve?
 Senhor Mauro, is rtl2832 demod going to be merged?

 regards,
 poma

 Hi all,
 
 I will try to solve the issue as soon as I have some spare time. In the 
 meantime I 
 asked Realtek if they knew of any problems with the hardware, and I got a GPIO
 list which might help me to solve the problem.
 
 Regrads
 Thomas
 

This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs
https://gist.github.com/2171926#120
David, can you help with this tuner issue?
http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898

Cheers,
poma

--
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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)

2012-07-30 Thread Antti Palosaari

On 07/30/2012 12:21 AM, poma wrote:

On 07/20/2012 03:43 AM, Antti Palosaari wrote:

On 07/13/2012 12:07 AM, Steven Toth wrote:

On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth st...@kernellabs.com
wrote:

Nobody understands the relationship between the bridge and the
sub-component as well as the bridge driver. The current interfaces are
limiting in many ways. We solve that today with rather ugly 'attach'
structures that are inflexible, for example to set gpios to a default
state.
Then, once that interface is attached, the bridge effectively loses
most of
the control to the tuner and/or demod. The result is a large disconnect
between the bridge and subcomponents.

Why limit any interface extension to GPIOs? Why not make something a
little more flexible so we can pass custom messages around?



What did you ever decide about the enable/disable of the LNA? And, how
would the bridge do that in your proposed solution? Via the proposed
GPIO
interface?


GPIO / LNA is ready, see following patches:
add LNA support for DVB API
cxd2820r: use Kernel GPIO for GPIO access
em28xx: implement FE set_lna() callback

from:
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dvb_core

Kernel GPIOs were quite easy to implement and use - when needed
knowledge was gathered after all the testing and study. I wonder why
none was done that earlier for DVB...

It also offer nice debug/devel feature as you can mount those GPIOs via
sysfs and use directly.



Above mentioned GPIO functionality must be implemented in driver itself
to use /sys/class/gpio/… sysfs interface, right?
It is not enough to build kernel with CONFIG_GENERIC_GPIO=y,
CONFIG_GPIOLIB=y, CONFIG_GPIO_SYSFS, right?


You will need to implement callbacks for gpiolib. sysfs interface is 
then get for free.


regards
Antti

--
http://palosaari.fi/
--
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 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available

2012-07-30 Thread Marek Szyprowski
Hello,

On Thursday, July 26, 2012 1:13 PM Hideki EIRAKU wrote:

 Previously the vb2_dma_contig_mmap() function was using a dma_addr_t as a
 physical address.  The two addressses are not necessarily the same.
 For example, when using the IOMMU funtion on certain platforms, dma_addr_t
 addresses are not directly mappable physical address.
 dma_mmap_coherent() maps the address correctly.
 It is available on ARM platforms.
 
 Signed-off-by: Hideki EIRAKU h...@igel.co.jp
 ---
  drivers/media/video/videobuf2-dma-contig.c |   18 ++
  1 files changed, 18 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/videobuf2-dma-contig.c 
 b/drivers/media/video/videobuf2-dma-
 contig.c
 index 4b71326..4dc85ab 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
 @@ -101,14 +101,32 @@ static unsigned int vb2_dma_contig_num_users(void 
 *buf_priv)
  static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
  {
   struct vb2_dc_buf *buf = buf_priv;
 +#ifdef ARCH_HAS_DMA_MMAP_COHERENT
 + int ret;
 +#endif
 
   if (!buf) {
   printk(KERN_ERR No buffer to map\n);
   return -EINVAL;
   }
 
 +#ifdef ARCH_HAS_DMA_MMAP_COHERENT
 + vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);

The above line is not needed. It is up to dma_mmap_coherent() / 
dma_mmap_attrs() to set page
protection bits which match requested type of dma buffer mapping.

 + ret = dma_mmap_coherent(buf-conf-dev, vma, buf-vaddr, buf-dma_addr,
 + buf-size);
 + if (ret) {
 + pr_err(Remapping memory failed, error: %d\n, ret);
 + return ret;
 + }
 + vma-vm_flags |= VM_DONTEXPAND | VM_RESERVED;
 + vma-vm_private_data = buf-handler;
 + vma-vm_ops = vb2_common_vm_ops;
 + vma-vm_ops-open(vma);
 + return 0;
 +#else
   return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
 vb2_common_vm_ops, buf-handler);
 +#endif
  }
 
  static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,

Best regards
-- 
Marek Szyprowski
Samsung Poland RD Center


--
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] media: i.MX27: Fix mx2_emmaprp mem2mem driver clocks.

2012-07-30 Thread Javier Martin
This driver wasn't converted to the new clock framework
(e038ed50a4a767add205094c035b6943e7b30140).

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 This is broken in current stable 3.5 too. So it should be applied
 to both stable and 3.6.

---
 drivers/media/video/mx2_emmaprp.c |   27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/media/video/mx2_emmaprp.c 
b/drivers/media/video/mx2_emmaprp.c
index 0bd5815..2614a89 100644
--- a/drivers/media/video/mx2_emmaprp.c
+++ b/drivers/media/video/mx2_emmaprp.c
@@ -209,7 +209,7 @@ struct emmaprp_dev {
 
int irq_emma;
void __iomem*base_emma;
-   struct clk  *clk_emma;
+   struct clk  *clk_emma_ahb, *clk_emma_ipg;
struct resource *res_emma;
 
struct v4l2_m2m_dev *m2m_dev;
@@ -800,7 +800,8 @@ static int emmaprp_open(struct file *file)
return ret;
}
 
-   clk_enable(pcdev-clk_emma);
+   clk_prepare_enable(pcdev-clk_emma_ipg);
+   clk_prepare_enable(pcdev-clk_emma_ahb);
ctx-q_data[V4L2_M2M_SRC].fmt = formats[1];
ctx-q_data[V4L2_M2M_DST].fmt = formats[0];
 
@@ -816,7 +817,8 @@ static int emmaprp_release(struct file *file)
 
dprintk(pcdev, Releasing instance %p\n, ctx);
 
-   clk_disable(pcdev-clk_emma);
+   clk_disable_unprepare(pcdev-clk_emma_ahb);
+   clk_disable_unprepare(pcdev-clk_emma_ipg);
v4l2_m2m_ctx_release(ctx-m2m_ctx);
kfree(ctx);
 
@@ -876,9 +878,15 @@ static int emmaprp_probe(struct platform_device *pdev)
 
spin_lock_init(pcdev-irqlock);
 
-   pcdev-clk_emma = clk_get(pdev-dev, NULL);
-   if (IS_ERR(pcdev-clk_emma)) {
-   ret = PTR_ERR(pcdev-clk_emma);
+   pcdev-clk_emma_ipg = devm_clk_get(pdev-dev, ipg);
+   if (IS_ERR(pcdev-clk_emma_ipg)) {
+   ret = PTR_ERR(pcdev-clk_emma_ipg);
+   goto free_dev;
+   }
+
+   pcdev-clk_emma_ahb = devm_clk_get(pdev-dev, ahb);
+   if (IS_ERR(pcdev-clk_emma_ipg)) {
+   ret = PTR_ERR(pcdev-clk_emma_ahb);
goto free_dev;
}
 
@@ -887,12 +895,12 @@ static int emmaprp_probe(struct platform_device *pdev)
if (irq_emma  0 || res_emma == NULL) {
dev_err(pdev-dev, Missing platform resources data\n);
ret = -ENODEV;
-   goto free_clk;
+   goto free_dev;
}
 
ret = v4l2_device_register(pdev-dev, pcdev-v4l2_dev);
if (ret)
-   goto free_clk;
+   goto free_dev;
 
mutex_init(pcdev-dev_mutex);
 
@@ -965,8 +973,6 @@ rel_vdev:
video_device_release(vfd);
 unreg_dev:
v4l2_device_unregister(pcdev-v4l2_dev);
-free_clk:
-   clk_put(pcdev-clk_emma);
 free_dev:
kfree(pcdev);
 
@@ -983,7 +989,6 @@ static int emmaprp_remove(struct platform_device *pdev)
v4l2_m2m_release(pcdev-m2m_dev);
vb2_dma_contig_cleanup_ctx(pcdev-alloc_ctx);
v4l2_device_unregister(pcdev-v4l2_dev);
-   clk_put(pcdev-clk_emma);
kfree(pcdev);
 
return 0;
-- 
1.7.9.5

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


Re: [PATCH] media: i.MX27: Fix mx2_emmaprp mem2mem driver clocks.

2012-07-30 Thread Sylwester Nawrocki
Hi,

On 07/30/2012 10:37 AM, Javier Martin wrote:
 This driver wasn't converted to the new clock framework
 (e038ed50a4a767add205094c035b6943e7b30140).
 
 Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
 ---
  This is broken in current stable 3.5 too. So it should be applied
  to both stable and 3.6.

The you should add Cc: sta...@vger.kernel.org line along with
your sign-off, ideally mentioning in the patch description to
what stable kernels it applies, and it would all be handled
automatically.
I guess Mauro is going to add that missing Cc, when applying the
patch though.

--

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


[PATCH 1/1] v4l: Add missing compatibility definitions for bounds rectangles

2012-07-30 Thread Sakari Ailus
Compatibility defines for ACTUAL subdev selection rectangles were added and
also the name of the BOUNDS rectangles was changed in the process, which,
alas, went unnoticed until now. Add compatibility definitions for these
rectangles.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 include/linux/v4l2-common.h |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/v4l2-common.h b/include/linux/v4l2-common.h
index 0fa8b64..4f0667e 100644
--- a/include/linux/v4l2-common.h
+++ b/include/linux/v4l2-common.h
@@ -53,10 +53,10 @@
 /* Backward compatibility target definitions --- to be removed. */
 #define V4L2_SEL_TGT_CROP_ACTIVE   V4L2_SEL_TGT_CROP
 #define V4L2_SEL_TGT_COMPOSE_ACTIVEV4L2_SEL_TGT_COMPOSE
-#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL \
-   V4L2_SEL_TGT_CROP
-#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL \
-   V4L2_SEL_TGT_COMPOSE
+#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUALV4L2_SEL_TGT_CROP
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL V4L2_SEL_TGT_COMPOSE
+#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDSV4L2_SEL_TGT_CROP_BOUNDS
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS V4L2_SEL_TGT_COMPOSE_BOUNDS
 
 /* Selection flags */
 #define V4L2_SEL_FLAG_GE   (1  0)
-- 
1.7.2.5

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


Re: [PATCH 1/1] v4l: Add missing compatibility definitions for bounds rectangles

2012-07-30 Thread Laurent Pinchart
Hi Sakari,

Thanks for the patch.

On Monday 30 July 2012 12:08:47 Sakari Ailus wrote:
 Compatibility defines for ACTUAL subdev selection rectangles were added and
 also the name of the BOUNDS rectangles was changed in the process, which,
 alas, went unnoticed until now. Add compatibility definitions for these
 rectangles.
 
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi

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

 ---
  include/linux/v4l2-common.h |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/include/linux/v4l2-common.h b/include/linux/v4l2-common.h
 index 0fa8b64..4f0667e 100644
 --- a/include/linux/v4l2-common.h
 +++ b/include/linux/v4l2-common.h
 @@ -53,10 +53,10 @@
  /* Backward compatibility target definitions --- to be removed. */
  #define V4L2_SEL_TGT_CROP_ACTIVE V4L2_SEL_TGT_CROP
  #define V4L2_SEL_TGT_COMPOSE_ACTIVE  V4L2_SEL_TGT_COMPOSE
 -#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL \
 - V4L2_SEL_TGT_CROP
 -#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL \
 - V4L2_SEL_TGT_COMPOSE
 +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL  V4L2_SEL_TGT_CROP
 +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL V4L2_SEL_TGT_COMPOSE
 +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS  V4L2_SEL_TGT_CROP_BOUNDS
 +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS V4L2_SEL_TGT_COMPOSE_BOUNDS
 
  /* Selection flags */
  #define V4L2_SEL_FLAG_GE (1  0)

-- 
Regards,

Laurent Pinchart

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


[GIT PULL FOR 3.6] Selection API compatibility fix, small SMIA++ correction

2012-07-30 Thread Sakari Ailus
Hi Mauro,

This pull request contains an important for for the compatibility
definitions of the bounds rectangles. They were missing from the original
patches changing the selection rectangles.

There's an one-liner to fix double include in the SMIA++ driver, too.

Please pull:

The following changes since commit 931efdf58bd83af8d0578a6cc53421675daf6d41:
  
  Merge branch 'v4l_for_linus' into staging/for_v3.6 (2012-07-14 15:45:44 -0300)

are available in the git repository at:
  
  ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6

Duan Jiong (1):
  smiapp: remove duplicated include

Sakari Ailus (1):
  v4l: Add missing compatibility definitions for bounds rectangles
 
 drivers/media/video/smiapp/smiapp-core.c |1 -
 include/linux/v4l2-common.h  |8 
 2 files changed, 4 insertions(+), 5 deletions(-)

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH 0/2] Add support for RDS decoding

2012-07-30 Thread Konke Radlow
thank you for the info, it's working now
(I went for the include solution)
--
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: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread David Basden
On Mon, Jul 30, 2012 at 09:06:54AM +0200, poma wrote:
 On 06/27/2012 07:21 AM, Thomas Mair wrote:
  On 26.06.2012 19:17, poma wrote:
  On 05/28/2012 04:48 PM, Thomas Mair wrote:
  On 28.05.2012 08:58, Thomas Mair wrote:
  On 26.05.2012 04:47, poma wrote:
  On 05/20/2012 11:12 PM, Thomas Mair wrote:
  On 20.05.2012 22:08, Antti Palosaari wrote:
  On 20.05.2012 20:04, poma wrote:
  After hard/cold boot:
 
  DVB: register adapter0/net0 @ minor: 2 (0x02)
  rtl2832u_frontend_attach:
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  No compatible tuner found
 
  These errors are coming from tuner probe. As it still goes to probing 
  and did not jump out earlier when gate is opened it means that demod 
  is answering commands but tuner are not.
 
  My guess is that tuner is still on the reset or not powered at all. 
  It is almost 100% sure error is wrong tuner GPIO.
 
  There is an issue with GPIO, as FC0012 tuner callback will set 
  the value of one of the GPIO outputs. However fixing that, will
  not resolve the issue. So I need to debug the problem further.
 
  True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
  even more.
  Precisely, what breaks a tuner on next soft [re]boot are apps/utils
  which engage tzap/scan[dvb].
 
 
  To reproduce the bug it is not necessary to reboot the machine. Simply 
  unload and load of the dvb_usb_rtl28xxu module will lead to the same 
  situation.
 
  I suspect, that when power is turned off, the tuner power is not 
  switched on correctly. The mistake is not related to the OUTPUT_VAL
  registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.
 
  What makes me wonder is if no tuning operation is performed before
  reboot, the driver does work correctly after that, as poma already
  noticed.
 
  I have some spare time today and will investigate the problem further.
 
 
  I tried a few things regarding the problem today and could find out a 
  few more details, but could not resolve the issue.
 
  The GPIO pin configuration for the devices with the fc0012 (and probably
  also with the fc0013) tuner is the following:
 
  GPIO0: demod power
  GPIO3: tuner power? (the realtek driver puts this to 1 and never touches 
  it again)
  GPIO4: tuner power? (maybe antenna power?)
  GPIO5: tuner reset
  GPIO6: UHF/VHF band selection
 
  All of these GPIOs are configured as output. When the device is plugged in
  the tuner is powered up correctly, but I am not able to power it up when
  a reboot is performed. What I tried was the following:
 
  - on rtl28xxu_power_ctrl off:
- GPIO4 = 1 (off)
- GPIO5 = 0 
- GPIO6 = 0 (default state)
 
  - on rtl28xxu_power_ctrl on:
- GPIO3 = 1
- GPIO4 = 0 (on)
- GPIO5 = 0 
- GPIO6 = 0 (default state)
 
  - on rtl2832_frontend_attach:
- GPIO5 = 1 
- GPIO5 = 0 
 
  This sequence should ensure that the tuner is powered on when the frontend
  is attached, and a tuner reset is being performed before the tuner is 
  probed.
  However this sequence fails the same way as it did before. I tried to add
  timeouts to be sure that the tuner is not probed while it is reset but 
  that
  did not help either.
 
  Right now I really don't know where I should look for the solution of
  the problem. It seems that the tuner reset does not have any effect on 
  the 
  tuner whatsoever.
 
  Is there anybody who could look at the code, or maybe knows what could be
  the cause of the problem? I suspect I am just too blind to see my own 
  mistakes.
 
  Regards
  Thomas
 
 
  Cheers Thomas, Hans-Frieder, Antti, Mauro!
  Hans-Frieder, are you having the same issue with fc0011af9035?
  Antti, no tricks up your sleeve?
  Senhor Mauro, is rtl2832 demod going to be merged?
 
  regards,
  poma
 
  Hi all,
  
  I will try to solve the issue as soon as I have some spare time. In the 
  meantime I 
  asked Realtek if they knew of any problems with the hardware, and I got a 
  GPIO
  list which might help me to solve the problem.
  
  Regrads
  Thomas
  
 
 This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs
 https://gist.github.com/2171926#120
 David, can you help with this tuner issue?
 http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898
 
 Cheers,
 poma

It sounds like you're definately on the right track with the GPIO pins for
tuner power and reset lines, especially if it's not making it through the
tuner probe.

The gist you linked to above has since been merged into the rtl-sdr tree,
and the version in there is likely to be a much better reference than the
old patch I had posted: http://sdr.osmocom.org/trac/wiki/rtl-sdr
It reliably brings the rtl and the tuner 

Asus PVR-416

2012-07-30 Thread Jerry Haggard
I've been trying to get an ASUS PVR-416 card to work with MythTV .25 on 
Scientific Linux 6.  I have a bttv card working, my setup works in 
general, etc, and the driver attempts to load.  But when I check dmesg, 
I keep getting firmware load errors and checksum errors. I've tried 
every firmware I could find.  I've used the one from Atrpms, I've 
downloaded the correctly named firmware from ivtv, but no luck.  Anyone 
know anything about this card?  I've tried cutting the drivers myself 
like it says in the direcitons at mythtv.org. This is supposed to be a 
supported card, does anyone have any experience with it?

--
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 for stable] cx25821: Remove bad strcpy to read-only char*

2012-07-30 Thread Ezequiel Garcia
Hi Ben,

On Sun, Jul 29, 2012 at 10:56 PM, Ben Hutchings b...@decadent.org.uk wrote:


 If I'm doing anything wrong, just yell at me.
 [...]

 An upstream commit hash would have helped, but I found it anyway.
 Queued up for 3.2.y.


Thanks for the hint and sorry for the trouble...
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 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com

2012-07-30 Thread Konke Radlow
Hello Hans, 
no need to thank me for working on it. First of all I do it as a part of a 
summerjob, and more importantly I quite enjoy it and  intend to stay a active 
member of the development process after my time at Cisco is over.

Thank you for your comments. 

 Most fields in this struct (and in the other structs for that matter) could
 do with some more documentation.
I added a lot of short comments explaining the meaning of the fields, and 
extended the explanation part that comes before each struct definition.

  +   /** RDS info fields **/
  +   bool is_rbds;   /* use RBDS standard version of LUTs */
  +   uint16_t pi;
  +   uint8_t ps[8];
 
 Looking at rds-ctl, this contains a string, please make it 9 bytes and
 always 0 terminate it! I also notice in rds-ctl that you filter the chars
 for being valid ascii and if not replace them with a space. Does the spec
 say anything about the encoding used for this string? Could we maybe
 convert it to UTF-8 inside the library so that apps can just consume the
 string?
The character encoding complies with ISO/IEC 10646, so it basically already is 
UTF-8, and the data could be stored in a wchar_t array without conversion. 
Is that preferred over uint8_t?

  +/* adds a raw RDS block to decode it into RDS groups
  + * @return:bitmask with with updated fields set to 1
  + * @rds_data:  3 bytes of raw RDS data, obtained by calling read()
  + * on RDS capable V4L2 devices */
  +LIBV4L_PUBLIC uint32_t v4l2_rds_add(struct v4l2_rds *handle, struct
  v4l2_rds_data *rds_data);
 
 Unless I'm missing something, you are no defining struct v4l2_rds_data
 anywhere, why not just make this a uint8_t ?
The v4l2_rds_data structure is defined by v4l in the videodev2.h header, and is 
returned when calling the read function on a rds capable device
On Saturday, July 28, 2012 11:08:24 AM Hans de Goede wrote:
 Hi,
 
 First of all many thanks for working on this! Note I've also taken
 a quick look at the original patch with the actual implementation and that
 looks good. I'm replying here because in my mind the API is the most
 interesting thing to discuss.
 
 Comments inline.
 
 On 07/26/2012 06:21 PM, Konke Radlow wrote:
  PATCH 1/2 was missing the public header for the rds library. I'm sorry
  for that mistake:
  
  diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
  new file mode 100644
  index 000..04843d3
  --- /dev/null
  +++ b/lib/include/libv4l2rds.h
  @@ -0,0 +1,203 @@
  +/*
  + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
  reserved.
  + * Author: Konke Radlow korad...@gmail.com
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU Lesser General Public License as
  published by
  + * the Free Software Foundation; either version 2.1 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, Suite 500, Boston, MA 
  02110-1335 USA
  + */
  +
  +#ifndef __LIBV4L2RDS
  +#define __LIBV4L2RDS
  +
  +#include errno.h
  +#include stdio.h
  +#include stdlib.h
  +#include string.h
  +#include stdbool.h
  +#include unistd.h
  +#include stdint.h
  +#include sys/types.h
  +#include sys/mman.h
  +
  +#include linux/videodev2.h
  +
  +#ifdef __cplusplus
  +extern C {
  +#endif /* __cplusplus */
  +
  +#if __GNUC__ = 4
  +#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
  +#else
  +#define LIBV4L_PUBLIC
  +#endif
  +
  +/* used to define the current version (version field) of the v4l2_rds
  struct */ +#define V4L2_RDS_VERSION (1)
  +
  +/* Constants used to define the size of arrays used to store RDS
  information */
  +#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b. Of
  these +  * 32 distinct groups, 18 can be used for ODA  
purposes*/
  +#define MAX_AF_CNT 25  /* AF Method A allows a maximum of 25 AFs to be
  defined
  +* AF Method B does not impose a limit on the number of 
  AFs
  +* but it is not fully supported at the moment and will
  +* not receive more than 25 AFs */
  +
  +/* Define Constants for the possible types of RDS information
  + * used to address the relevant bit in the valid_bitmask */
  +#define V4L2_RDS_PI0x01/* Program Identification */
  +#define V4L2_RDS_PTY   0x02/* Program Type */
  +#define V4L2_RDS_TP0x04/* Traffic Program */
  +#define V4L2_RDS_PS0x08/* Program 

Re: [PATCH] cx25840: Declare MODULE_FIRMWARE usage

2012-07-30 Thread Tim Gardner

On 07/28/2012 10:52 AM, Andy Walls wrote:

On Fri, 2012-07-27 at 06:06 -0600, Tim Gardner wrote:

On 07/26/2012 03:59 PM, Andy Walls wrote:

On Thu, 2012-07-26 at 10:44 -0600, Tim Gardner wrote:

Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
   drivers/media/video/cx25840/cx25840-firmware.c |   15 ---
   1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/cx25840/cx25840-firmware.c 
b/drivers/media/video/cx25840/cx25840-firmware.c
index 8150200..b3169f9 100644
--- a/drivers/media/video/cx25840/cx25840-firmware.c
+++ b/drivers/media/video/cx25840/cx25840-firmware.c
@@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client)
cx25840_write(client, 0x803, 0x03);
   }

+#define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw
+#define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw
+#define CX25840_FIRMWARE v4l-cx25840.fw
+
   static const char *get_fw_name(struct i2c_client *client)
   {
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
@@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client *client)
if (firmware[0])
return firmware;
if (is_cx2388x(state))
-   return v4l-cx23885-avcore-01.fw;
+   return CX2388x_FIRMWARE;
if (is_cx231xx(state))
-   return v4l-cx231xx-avcore-01.fw;
-   return v4l-cx25840.fw;
+   return CX231xx_FIRMWARE;
+   return CX25840_FIRMWARE;
   }

   static int check_fw_load(struct i2c_client *client, int size)
@@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client)

return check_fw_load(client, size);
   }
+
+MODULE_FIRMWARE(CX2388x_FIRMWARE);
+MODULE_FIRMWARE(CX231xx_FIRMWARE);
+MODULE_FIRMWARE(CX25840_FIRMWARE);
+


How will the firmware attribute in the .module_info section be used?

For any one model of TV capture device, the cx25840 only needs one of
the above firmware files.  The others need not exist.

I would not want anything in user or kernel space to refuse to load the
module just because all 3 firmware files are not present.

Regards,
Andy



The MODULE_FIRMWARE macro is purely informational. Declaring the
firmware files that the driver _might_ use helps me pare down the
external firmware package to just those files that I know it must have.


Would it help if the MODULE_FIRMWARE text was more descriptive, e.g.:

MODULE_FIRMWARE(CX25840_FIRMWARE  CX25840/1/2/3 chips only);
MODULE_FIRMWARE(CX231xx_FIRMWARE  CX23100/1/2 chips only);
MODULE_FIRMWARE(CX2388x_FIRMWARE  CX23885/7/8 chips only);

Similarly for ivtv:

MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME);
MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME  PVR-350 only);
MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME  PVR-350 only);

and cx18:

MODULE_FIRMWARE(FWFILE); /* v4l-cx23418-dig.fw */
MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
MODULE_FIRMWARE(CX18_APU_FIRMWARE);
MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE  Non-HVR-1600 cards);
MODULE_FIRMWARE(FWFILE  Yuan MPC-718 only);

or would that confuse some userspace tools?



Yeah, I think it would confuse any tools that assume the firmware string 
emitted by modinfo is a literal filename.


rtg
--
Tim Gardner tim.gard...@canonical.com
--
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] media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.

2012-07-30 Thread javier Martin
Hi,
thank you for yor ACKs.

On 20 July 2012 13:31, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
 On Thu, 12 Jul 2012, Javier Martin wrote:

 These flags are not used any longer and can be safely removed
 since the following patch:
 http://www.spinics.net/lists/linux-media/msg50165.html

 Signed-off-by: Javier Martin javier.mar...@vista-silicon.com

 For the ARM tree:

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

forgive my ignorance on the matter. Could you please point me to the
git repository this patch should be merged?

Regards.

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
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: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread David Basden
  Right now I really don't know where I should look for the solution of
  the problem. It seems that the tuner reset does not have any effect on 
  the 
  tuner whatsoever.

Can I suggest setting GPIO5 to 1, leave it there, and see if it breaks. If it
doesn't, GPIO5 on the RTL isn't setup correctly somehow.

At the same time, I was rereading code from:

http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898

and at no point is GPIO5 actually set to an output or enabled that I can find.
rtl2832u_frontend_attach skips doing so. (Actually, I seem to remember running
into this problem while trying to use some DVB driver code as an example of
how to setup the RTL to talk to the FC0012)

Try giving the patch below a go. Sorry, I don't have a build environment to
hand, so there might be a typo I haven't picked up, but the upshot is that 
I'm moving the FC0012 detection to the end, setting up GPIO5, resetting the
tuner and then trying to probe for the FC0012.

Please let me know if this helps :)

David

--- a/rtl28xxu.c2012-07-30 22:31:53.789638678 +1000
+++ b/rtl28xxu.c2012-07-30 22:48:35.774607232 +1000
@@ -550,15 +550,6 @@
 
priv-tuner = TUNER_NONE;
 
-   /* check FC0012 ID register; reg=00 val=a1 */
-   ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
-   if (ret == 0  buf[0] == 0xa1) {
-   priv-tuner = TUNER_RTL2832_FC0012;
-   rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
-   info(%s: FC0012 tuner found, __func__);
-   goto found;
-   }
-
/* check FC0013 ID register; reg=00 val=a3 */
ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0013);
if (ret == 0  buf[0] == 0xa3) {
@@ -640,6 +631,71 @@
goto unsupported;
}
 
+   /* If it's a FC0012, we need to bring GPIO5/RESET
+  out of floating or it's not going to show up.
+  We set GPIO5 to an output, enable the output, then
+  reset the tuner by bringing GPIO5 high then low again.
+
+  We're testing this last so that we don't accidentally
+  mess with other hardware that wouldn't like us messing
+  with whatever is connected to the rtl2832's GPIO5
+   */
+
+   /* close demod I2C gate */
+   ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
+   if (ret)
+   goto err;
+
+   /* Set GPIO5 to be an output */
+   ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_DIR, val);
+   if (ret)
+   goto err;
+
+   val = 0xdf;
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, val);
+   if (ret)
+   goto err;
+
+   /* enable as output GPIO5 */
+   ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val);
+   if (ret)
+   goto err;
+
+   val |= 0x20;
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val);
+   if (ret)
+   goto err;
+
+   /* set GPIO5 high to reset fc0012 (if it exists) */
+   ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
+   if (ret)
+   goto err;
+
+   val |= 0x20; 
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
+   if (ret)
+   goto err;
+
+   /* bring GPIO5 low again after reset */
+   val = 0xdf;
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
+   if (ret)
+   goto err;
+
+   /* re-open demod I2C gate */
+   ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_open);
+   if (ret)
+   goto err;
+
+   /* check FC0012 ID register; reg=00 val=a1 */
+   ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
+   if (ret == 0  buf[0] == 0xa1) {
+   priv-tuner = TUNER_RTL2832_FC0012;
+   rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
+   info(%s: FC0012 tuner found, __func__);
+   goto found;
+   }
+
 unsupported:
/* close demod I2C gate */
ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
--
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 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com

2012-07-30 Thread Konke Radlow
Hello Hans,
no need to thank me for working on it. First of all I do it as a part of a
summerjob, and more importantly I quite enjoy it and  intend to stay a active
member of the development process after my time at Cisco is over.

Thank you for your comments.

 Most fields in this struct (and in the other structs for that matter) could
 do with some more documentation.
I added a lot of short comments explaining the meaning of the fields, and
extended the explanation part that comes before each struct definition.

  +   /** RDS info fields **/
  +   bool is_rbds;   /* use RBDS standard version of LUTs */
  +   uint16_t pi;
  +   uint8_t ps[8];

 Looking at rds-ctl, this contains a string, please make it 9 bytes and
 always 0 terminate it! I also notice in rds-ctl that you filter the chars
 for being valid ascii and if not replace them with a space. Does the spec
 say anything about the encoding used for this string? Could we maybe
 convert it to UTF-8 inside the library so that apps can just consume the
 string?
The character encoding complies with ISO/IEC 10646, so it basically already is
UTF-8, and the data could be stored in a wchar_t array without conversion.
Is that preferred over uint8_t?

  +/* adds a raw RDS block to decode it into RDS groups
  + * @return:bitmask with with updated fields set to 1
  + * @rds_data:  3 bytes of raw RDS data, obtained by calling read()
  + * on RDS capable V4L2 devices */
  +LIBV4L_PUBLIC uint32_t v4l2_rds_add(struct v4l2_rds *handle, struct
  v4l2_rds_data *rds_data);

 Unless I'm missing something, you are no defining struct v4l2_rds_data
 anywhere, why not just make this a uint8_t ?
The v4l2_rds_data structure is defined by v4l in the videodev2.h header, and is
returned when calling the read function on a rds capable device
source: http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-rds-data
Maybe I didn't get you point though?

greetings,
Konke
--
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: Asus PVR-416

2012-07-30 Thread Alex Deucher
On Mon, Jul 30, 2012 at 6:57 AM, Jerry Haggard xen2x...@gmail.com wrote:
 I've been trying to get an ASUS PVR-416 card to work with MythTV .25 on
 Scientific Linux 6.  I have a bttv card working, my setup works in general,
 etc, and the driver attempts to load.  But when I check dmesg, I keep
 getting firmware load errors and checksum errors. I've tried every firmware
 I could find.  I've used the one from Atrpms, I've downloaded the correctly
 named firmware from ivtv, but no luck.  Anyone know anything about this
 card?  I've tried cutting the drivers myself like it says in the direcitons
 at mythtv.org. This is supposed to be a supported card, does anyone have any
 experience with it?

I've got one and it worked years ago, but I haven't used it since.
IIRC, the initial blackbird support was added using this card, but I'm
not sure what the current state is.

Alex
--
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] mt9v022: Add support for mt9v024

2012-07-30 Thread Alex Gershgorin
This patch has been successfully tested

Signed-off-by: Alex Gershgorin al...@meprolight.com
---
 drivers/media/video/Kconfig   |2 +-
 drivers/media/video/mt9v022.c |   28 ++--
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 99937c9..38d6944 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1013,7 +1013,7 @@ config SOC_CAMERA_MT9T112
  This driver supports MT9T112 cameras from Aptina.
 
 config SOC_CAMERA_MT9V022
-   tristate mt9v022 support
+   tristate mt9v022 and mt9v024 support
depends on SOC_CAMERA  I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index bf63417..d2c1ab1 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -26,7 +26,7 @@
  * The platform has to define ctruct i2c_board_info objects and link to them
  * from struct soc_camera_link
  */
-
+static s32 chip_id;
 static char *sensor_type;
 module_param(sensor_type, charp, S_IRUGO);
 MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or \monochrome\);
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or 
\monochrome\);
 #define MT9V022_AEC_AGC_ENABLE 0xAF
 #define MT9V022_MAX_TOTAL_SHUTTER_WIDTH0xBD
 
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV   0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH0xAD
+
 /* Progressive scan, master, defaults */
 #define MT9V022_CHIP_CONTROL_DEFAULT   0x188
 
@@ -185,7 +189,9 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
-   ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+   ret = reg_write(client, (chip_id == 0x1324) ?
+   MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+   MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,8 +244,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct 
v4l2_crop *a)
ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
if (ret = 0) {
if (ret  1) /* Autoexposure */
-   ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
-   rect.height + mt9v022-y_skip_top + 43);
+   ret = reg_write(client, (chip_id == 0x1324) ?
+   MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+   MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+   rect.height + mt9v022-y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
rect.height + mt9v022-y_skip_top + 43);
@@ -566,18 +574,17 @@ static int mt9v022_video_probe(struct i2c_client *client)
 {
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
-   s32 data;
int ret;
unsigned long flags;
 
/* Read out the chip version register */
-   data = reg_read(client, MT9V022_CHIP_VERSION);
+   chip_id = reg_read(client, MT9V022_CHIP_VERSION);
 
/* must be 0x1311 or 0x1313 */
-   if (data != 0x1311  data != 0x1313) {
+   if (chip_id != 0x1311  chip_id != 0x1313  chip_id != 0x1324) {
ret = -ENODEV;
dev_info(client-dev, No MT9V022 found, ID register 0x%x\n,
-data);
+chip_id);
goto ei2c;
}
 
@@ -632,7 +639,7 @@ static int mt9v022_video_probe(struct i2c_client *client)
mt9v022-fmt = mt9v022-fmts[0];
 
dev_info(client-dev, Detected a MT9V022 chip ID %x, %s sensor\n,
-data, mt9v022-model == V4L2_IDENT_MT9V022IX7ATM ?
+chip_id, mt9v022-model == V4L2_IDENT_MT9V022IX7ATM ?
 monochrome : colour);
 
ret = mt9v022_init(client);
@@ -728,7 +735,8 @@ static int mt9v022_s_mbus_config(struct v4l2_subdev *sd,
if (!(flags  V4L2_MBUS_VSYNC_ACTIVE_HIGH))
pixclk |= 0x2;
 
-   ret = reg_write(client, MT9V022_PIXCLK_FV_LV, pixclk);
+   ret = reg_write(client, (chip_id == 0x1324) ? MT9V024_PIXCLK_FV_LV :
+   MT9V022_PIXCLK_FV_LV, pixclk);
if (ret  0)
return ret;
 
-- 
1.7.0.4

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


Re: [PATCH RFCv3] add DTMB support for DVB API

2012-07-30 Thread Mauro Carvalho Chehab
Em 10-07-2012 12:04, Antti Palosaari escreveu:
 Cc: Patrick Boettcher pboettc...@kernellabs.com
 Cc: Andreas Oberritter o...@linuxtv.org
 Cc: Mauro Carvalho Chehab mche...@redhat.com
 Acked-by: Patrick Boettcher pboettc...@kernellabs.com
 Signed-off-by: Antti Palosaari cr...@iki.fi

On a quick check, it looks ok on my eyes.

 ---
   Documentation/DocBook/media/dvb/dvbproperty.xml |   40 
 ++-
   drivers/media/dvb/dvb-core/dvb_frontend.c   |   14 ++--
   drivers/media/dvb/dvb-core/dvb_frontend.h   |2 ++
   drivers/media/dvb/frontends/atbm8830.c  |2 +-
   drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
   drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
   include/linux/dvb/frontend.h|   21 ++--
   include/linux/dvb/version.h |2 +-
   8 files changed, 74 insertions(+), 11 deletions(-)
 
 diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
 b/Documentation/DocBook/media/dvb/dvbproperty.xml
 index e633c09..05230ed 100644
 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml
 +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
 @@ -194,6 +194,7 @@ get/set up to 64 properties. The actual meaning of each 
 property is described on
   APSK_16,
   APSK_32,
   DQPSK,
 + QAM_4_NR,
} fe_modulation_t;
   /programlisting
   /section
 @@ -265,6 +266,7 @@ typedef enum fe_code_rate {
   FEC_AUTO,
   FEC_3_5,
   FEC_9_10,
 + FEC_2_5,
   } fe_code_rate_t;
   /programlisting
   parawhich correspond to error correction rates of 1/2, 2/3, etc.,
 @@ -351,7 +353,7 @@ typedef enum fe_delivery_system {
   SYS_ISDBC,
   SYS_ATSC,
   SYS_ATSCMH,
 - SYS_DMBTH,
 + SYS_DTMB,
   SYS_CMMB,
   SYS_DAB,
   SYS_DVBT2,
 @@ -725,6 +727,9 @@ typedef enum fe_guard_interval {
   GUARD_INTERVAL_1_128,
   GUARD_INTERVAL_19_128,
   GUARD_INTERVAL_19_256,
 + GUARD_INTERVAL_PN420,
 + GUARD_INTERVAL_PN595,
 + GUARD_INTERVAL_PN945,
   } fe_guard_interval_t;
   /programlisting
   
 @@ -733,6 +738,7 @@ typedef enum fe_guard_interval {
   try to find the correct guard interval (if capable) and 
 will use TMCC to fill
   in the missing parameters./para
   para2) Intervals 1/128, 19/128 and 19/256 are used only for 
 DVB-T2 at present/para
 + para3) DTMB specifies PN420, PN595 and PN945./para
   /section
   section id=DTV-TRANSMISSION-MODE
   titleconstantDTV_TRANSMISSION_MODE/constant/title
 @@ -749,6 +755,8 @@ typedef enum fe_transmit_mode {
   TRANSMISSION_MODE_1K,
   TRANSMISSION_MODE_16K,
   TRANSMISSION_MODE_32K,
 + TRANSMISSION_MODE_C1,
 + TRANSMISSION_MODE_C3780,
   } fe_transmit_mode_t;
   /programlisting
   paraNotes:/para
 @@ -760,6 +768,7 @@ typedef enum fe_transmit_mode {
   use TMCC to fill in the missing parameters./para
   para3) DVB-T specifies 2K and 8K as valid sizes./para
   para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
 + para5) DTMB specifies C1 and C3780./para
   /section
   section id=DTV-HIERARCHY
   titleconstantDTV_HIERARCHY/constant/title
 @@ -796,6 +805,17 @@ typedef enum fe_hierarchy {
   FE_GET_INFO. In the case of a legacy frontend, the 
 result is just the same
   as with FE_GET_INFO, but in a more structured format 
 /para
   /section
 + section id=DTV-INTERLEAVING
 + titleconstantDTV_INTERLEAVING/constant/title
 + paraInterleaving mode/para
 + programlisting
 +enum fe_interleaving {
 + INTERLEAVING_NONE,
 + INTERLEAVING_240,
 + INTERLEAVING_720,
 +};
 + /programlisting
 + /section
   /section
   section id=frontend-property-terrestrial-systems
   titleProperties used on terrestrial delivery systems/title
 @@ -934,6 +954,24 @@ typedef enum fe_hierarchy {
   listitemparalink 
 linkend=DTV-ATSCMH-SCCC-CODE_MODE-DconstantDTV_ATSCMH_SCCC_CODE_MODE_D/constant/link/para/listitem
   /itemizedlist
   /section
 + section id=dtmb-params
 + titleDTMB delivery system/title
 + paraThe following parameters are valid for 
 DTMB:/para
 + itemizedlist mark='opencircle'
 + listitemparalink 
 linkend=DTV-API-VERSIONconstantDTV_API_VERSION/constant/link/para/listitem
 + listitemparalink 
 linkend=DTV-DELIVERY-SYSTEMconstantDTV_DELIVERY_SYSTEM/constant/link/para/listitem
 + listitemparalink 
 linkend=DTV-TUNEconstantDTV_TUNE/constant/link/para/listitem
 + listitemparalink 
 linkend=DTV-CLEARconstantDTV_CLEAR/constant/link/para/listitem
 + listitemparalink 
 

Re: [PATCH] media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.

2012-07-30 Thread Guennadi Liakhovetski
Hi Javier

On Mon, 30 Jul 2012, javier Martin wrote:

 Hi,
 thank you for yor ACKs.
 
 On 20 July 2012 13:31, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
  On Thu, 12 Jul 2012, Javier Martin wrote:
 
  These flags are not used any longer and can be safely removed
  since the following patch:
  http://www.spinics.net/lists/linux-media/msg50165.html
 
  Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
 
  For the ARM tree:
 
  Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 
 forgive my ignorance on the matter. Could you please point me to the
 git repository this patch should be merged?

Sorry, my for the ARM tree comment was probably not clear enough. This 
patch should certainly go via the ARM (SoC) tree, since it only touches 
arch/arm. So, the maintainer (Sascha - added to CC), that will be 
forwarding this patch to Linus can thereby add my acked-by to this 
patch, if he feels like it.

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: patches to media_build, and a few other things

2012-07-30 Thread Mauro Carvalho Chehab
Hi Hin-Tak,

Em 17-07-2012 11:35, Antti Palosaari escreveu:
 On 07/17/2012 01:21 AM, Hin-Tak Leung wrote:

It seems I lost your original email. Anyway:

 I have a couple of patches to my local media_build repo, which do these:

 - a new option --as-is to the build script. It basically suppresses any 
 git pull/rebase to both media_build and the ./media subdirectory (if used in 
 combination with --main-git). In combination to --main-git, you are left on 
 your own and be wholy responsible about what is inside ./media - I use that 
 to check Antti's work (which is on a branch), and also since I have some 
 interrim patches to media_build itself, I would prefer I can tell it not to  
 pull/merge .

Seems fine for me.

 - a small change to v4l/Makefile , to install under 
 /lib/modules/$(KERNELRELEASE)/updates/... - recent fedora seems to have a 
 modprobe preference to load from ../updates/... (or at least, that's the 
 case of having installed compat-wireless at some stage - one might want to 
 steal some code from that?), when more than one kernel module of the same 
 name exists. This is so as not to trash distro-shipped modules (and also if 
 one cleans out .../updates/... and runs depmod -a, one is back to distro 
 as shipped behavior). Also trashing distro-shipped modules have the 
 side-effect of making drpm not to work and whole kernel packages are 
 downloaded in the next yum upgrade.

This needs to be smart enough to detect if the system is Fedora and if it is a 
version compatible with updates (17 or upper ?).

It should be noticed that Ubuntu has a similar kind of preference, but it uses 
the modules on a separate place.



 I also have a suggestion to make:

 - How http://linux/linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2
 is generated, probably should be documented. Over the weekend I was playing 
 with one with timestamp Jul 7, and it is quite broken with firstly header 
 files not in the right place (linux/v4l2-common.h instead of 
 media/v4l2-common.h), and also the following:

It does:
$ run make -C linux todaytar DIR=~/tmp/media_build

The script should be updating the media_build to the very latest version.

I'll double check if this is happening fine.

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


Re: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread poma
On 07/30/2012 12:17 PM, David Basden wrote:
 On Mon, Jul 30, 2012 at 09:06:54AM +0200, poma wrote:
 On 06/27/2012 07:21 AM, Thomas Mair wrote:
 On 26.06.2012 19:17, poma wrote:
 On 05/28/2012 04:48 PM, Thomas Mair wrote:
 On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing 
 and did not jump out earlier when gate is opened it means that demod 
 is answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. 
 It is almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].


 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.

 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.

 I have some spare time today and will investigate the problem further.


 I tried a few things regarding the problem today and could find out a 
 few more details, but could not resolve the issue.

 The GPIO pin configuration for the devices with the fc0012 (and probably
 also with the fc0013) tuner is the following:

 GPIO0: demod power
 GPIO3: tuner power? (the realtek driver puts this to 1 and never touches 
 it again)
 GPIO4: tuner power? (maybe antenna power?)
 GPIO5: tuner reset
 GPIO6: UHF/VHF band selection

 All of these GPIOs are configured as output. When the device is plugged in
 the tuner is powered up correctly, but I am not able to power it up when
 a reboot is performed. What I tried was the following:

 - on rtl28xxu_power_ctrl off:
   - GPIO4 = 1 (off)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl28xxu_power_ctrl on:
   - GPIO3 = 1
   - GPIO4 = 0 (on)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl2832_frontend_attach:
   - GPIO5 = 1 
   - GPIO5 = 0 

 This sequence should ensure that the tuner is powered on when the frontend
 is attached, and a tuner reset is being performed before the tuner is 
 probed.
 However this sequence fails the same way as it did before. I tried to add
 timeouts to be sure that the tuner is not probed while it is reset but 
 that
 did not help either.

 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on 
 the 
 tuner whatsoever.

 Is there anybody who could look at the code, or maybe knows what could be
 the cause of the problem? I suspect I am just too blind to see my own 
 mistakes.

 Regards
 Thomas


 Cheers Thomas, Hans-Frieder, Antti, Mauro!
 Hans-Frieder, are you having the same issue with fc0011af9035?
 Antti, no tricks up your sleeve?
 Senhor Mauro, is rtl2832 demod going to be merged?

 regards,
 poma

 Hi all,

 I will try to solve the issue as soon as I have some spare time. In the 
 meantime I 
 asked Realtek if they knew of any problems with the hardware, and I got a 
 GPIO
 list which might help me to solve the problem.

 Regrads
 Thomas


 This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs
 https://gist.github.com/2171926#120
 David, can you help with this tuner issue?
 http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898

 Cheers,
 poma
 
 It sounds like you're definately on the right track with the GPIO pins for
 tuner power and reset lines, especially if it's not making it through the
 tuner probe.
 
 The gist you linked to above has since been merged into the rtl-sdr tree,
 and the version in there is likely to be a much better reference than the
 old patch I had posted: http://sdr.osmocom.org/trac/wiki/rtl-sdr
 It reliably brings the rtl and the tuner up from cold, after reboots, and
 multiple times without rebooting. Given 

Re: set default protocol for TerraTec Cinergy XXS to nec

2012-07-30 Thread Mauro Carvalho Chehab
Em 16-07-2012 17:22, Toralf Förster escreveu:
 For a TerraTec Cinergy XXS USB stick (Bus 001 Device 008: ID 0ccd:00ab 
 TerraTec Electronic GmbH )
 I've to switch the protocol every time after plugin to get (at least few) 
 keys working :
 
 $ sudo ir-keytable --protocol=nec --sysdev=`ir-keytable 21 | head -n 1 | 
 cut -f5 -d'/'`
 
 /me wonders whether nec should be set as the default for this key in kernel 
 or not

It makes sense to patch it to use the nec protocol. If not all keys are 
working, it also makes
sense to fix the kernel table to handle all codes, or to point to a new table 
where all
Terratec keys are defined.

Could you please write such patch?

Thank you!
Mauro

 
 
  From the syslog :
 2012-07-16T22:12:53.357+02:00 n22 kernel: usb 1-1: new high-speed USB device 
 number 7 using ehci_hcd
 2012-07-16T22:12:53.460+02:00 n22 kernel: ehci_hcd :00:1a.7: 
 dma_pool_free ehci_qh, f60cd4e0/f4e0 (bad dma)
 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: New USB device found, 
 idVendor=0ccd, idProduct=00ab
 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: New USB device strings: 
 Mfr=1, Product=2, SerialNumber=3
 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: Product: Cinergy T XXS
 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: Manufacturer: TerraTec GmbH
 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: SerialNumber: 01
 2012-07-16T22:12:53.639+02:00 n22 kernel: dvb-usb: found a 'Terratec Cinergy 
 T USB XXS (HD)/ T3' in cold state, will try to load a firmware
 2012-07-16T22:12:53.650+02:00 n22 kernel: dvb-usb: downloading firmware from 
 file 'dvb-usb-dib0700-1.20.fw'
 2012-07-16T22:12:53.854+02:00 n22 kernel: dib0700: firmware started 
 successfully.
 2012-07-16T22:12:54.355+02:00 n22 kernel: dvb-usb: found a 'Terratec Cinergy 
 T USB XXS (HD)/ T3' in warm state.
 2012-07-16T22:12:54.355+02:00 n22 kernel: dvb-usb: will pass the complete 
 MPEG2 transport stream to the software demuxer.
 2012-07-16T22:12:54.355+02:00 n22 kernel: DVB: registering new adapter 
 (Terratec Cinergy T USB XXS (HD)/ T3)
 2012-07-16T22:12:54.560+02:00 n22 kernel: DVB: registering adapter 0 frontend 
 0 (DiBcom 7000PC)...
 2012-07-16T22:12:54.763+02:00 n22 kernel: DiB0070: successfully identified
 2012-07-16T22:12:54.801+02:00 n22 kernel: Registered IR keymap rc-dib0700-rc5
 2012-07-16T22:12:54.801+02:00 n22 kernel: input: IR-receiver inside an USB 
 DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/rc/rc0/input15
 2012-07-16T22:12:54.801+02:00 n22 kernel: rc0: IR-receiver inside an USB DVB 
 receiver as /devices/pci:00/:00:1a.7/usb1/1-1/rc/rc0
 2012-07-16T22:12:54.801+02:00 n22 kernel: dvb-usb: schedule remote query 
 interval to 50 msecs.
 2012-07-16T22:12:54.801+02:00 n22 kernel: dvb-usb: Terratec Cinergy T USB XXS 
 (HD)/ T3 successfully initialized and connected.
 2012-07-16T22:12:54.801+02:00 n22 kernel: usbcore: registered new interface 
 driver dvb_usb_dib0700
 2012-07-16T22:12:55.000+02:00 n22 sudo: tfoerste : TTY=pts/2 ; 
 PWD=/home/tfoerste/tmp ; USER=root ; COMMAND=/usr/bin/ir-keytable 
 --protocol=nec --sysdev=rc0
 

--
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: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread poma
On 07/30/2012 02:56 PM, David Basden wrote:
 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on 
 the 
 tuner whatsoever.
 
 Can I suggest setting GPIO5 to 1, leave it there, and see if it breaks. If it
 doesn't, GPIO5 on the RTL isn't setup correctly somehow.
 
 At the same time, I was rereading code from:
 
 http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898
 
 and at no point is GPIO5 actually set to an output or enabled that I can find.
 rtl2832u_frontend_attach skips doing so. (Actually, I seem to remember running
 into this problem while trying to use some DVB driver code as an example of
 how to setup the RTL to talk to the FC0012)
 
 Try giving the patch below a go. Sorry, I don't have a build environment to
 hand, so there might be a typo I haven't picked up, but the upshot is that 
 I'm moving the FC0012 detection to the end, setting up GPIO5, resetting the
 tuner and then trying to probe for the FC0012.
 
 Please let me know if this helps :)
 
 David
 
 --- a/rtl28xxu.c  2012-07-30 22:31:53.789638678 +1000
 +++ b/rtl28xxu.c  2012-07-30 22:48:35.774607232 +1000
 @@ -550,15 +550,6 @@
  
   priv-tuner = TUNER_NONE;
  
 - /* check FC0012 ID register; reg=00 val=a1 */
 - ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
 - if (ret == 0  buf[0] == 0xa1) {
 - priv-tuner = TUNER_RTL2832_FC0012;
 - rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
 - info(%s: FC0012 tuner found, __func__);
 - goto found;
 - }
 -
   /* check FC0013 ID register; reg=00 val=a3 */
   ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0013);
   if (ret == 0  buf[0] == 0xa3) {
 @@ -640,6 +631,71 @@
   goto unsupported;
   }
  
 + /* If it's a FC0012, we need to bring GPIO5/RESET
 +out of floating or it's not going to show up.
 +We set GPIO5 to an output, enable the output, then
 +reset the tuner by bringing GPIO5 high then low again.
 +
 +We're testing this last so that we don't accidentally
 +mess with other hardware that wouldn't like us messing
 +with whatever is connected to the rtl2832's GPIO5
 + */
 +
 + /* close demod I2C gate */
 + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
 + if (ret)
 + goto err;
 +
 + /* Set GPIO5 to be an output */
 + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_DIR, val);
 + if (ret)
 + goto err;
 +
 + val = 0xdf;
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, val);
 + if (ret)
 + goto err;
 +
 + /* enable as output GPIO5 */
 + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val);
 + if (ret)
 + goto err;
 +
 + val |= 0x20;
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val);
 + if (ret)
 + goto err;
 +
 + /* set GPIO5 high to reset fc0012 (if it exists) */
 + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
 + if (ret)
 + goto err;
 +
 + val |= 0x20; 
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
 + if (ret)
 + goto err;
 +
 + /* bring GPIO5 low again after reset */
 + val = 0xdf;
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
 + if (ret)
 + goto err;
 +
 + /* re-open demod I2C gate */
 + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_open);
 + if (ret)
 + goto err;
 +
 + /* check FC0012 ID register; reg=00 val=a1 */
 + ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
 + if (ret == 0  buf[0] == 0xa1) {
 + priv-tuner = TUNER_RTL2832_FC0012;
 + rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
 + info(%s: FC0012 tuner found, __func__);
 + goto found;
 + }
 +
  unsupported:
   /* close demod I2C gate */
   ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
 

…sorry for the delay,
After applied patch no luck - in attach is dmesg for working original
Realtek driver(dvb_usb_rtl2832), and second one(dvb-usb-rtl28xxu)
rtl2832 part by Thomas with tuner issue, still not working.
Most intriguing is tuner get stucked by tuning(t-zapping)!

Cheers,
poma

ps.
Thank you so far, really thorough explanation!




dvb-usb-rtl28xxu-dmesg.txt
…
rtl28xxu_module_init:
rtl28xxu_probe: interface=0
check for warm bda 2831
check for warm 14aa 160
check for warm 14aa 161
something went very wrong, device was not found in current device list - let's 
see what comes next.
check for warm ccd a9
check for warm 1f4d b803
dvb-usb: found a 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' in warm state.
power control: 1
rtl2832u_power_ctrl: onoff=1
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
all in all I will use 24576 bytes for streaming
allocating buffer 0
buffer 

[PATCH -resend] DVB: dib0700, remove double \n's from log

2012-07-30 Thread Jiri Slaby
err() already adds \n to the end of the format string. So remove one
more \n from formatting strings in the dib0700 driver.

Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Michael Krufky mkru...@linuxtv.org
---
 drivers/media/dvb/dvb-usb/dib0700_core.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c 
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 7e9e00f..ef87229 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -768,13 +768,13 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
/* Starting in firmware 1.20, the RC info is provided on a bulk pipe */
purb = usb_alloc_urb(0, GFP_KERNEL);
if (purb == NULL) {
-   err(rc usb alloc urb failed\n);
+   err(rc usb alloc urb failed);
return -ENOMEM;
}
 
purb-transfer_buffer = kzalloc(RC_MSG_SIZE_V1_20, GFP_KERNEL);
if (purb-transfer_buffer == NULL) {
-   err(rc kzalloc failed\n);
+   err(rc kzalloc failed);
usb_free_urb(purb);
return -ENOMEM;
}
@@ -786,7 +786,7 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
 
ret = usb_submit_urb(purb, GFP_ATOMIC);
if (ret) {
-   err(rc submit urb failed\n);
+   err(rc submit urb failed);
kfree(purb-transfer_buffer);
usb_free_urb(purb);
}
-- 
1.7.10.4


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


Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365

2012-07-30 Thread Hans Verkuil
On Sat July 28 2012 00:01:24 Sakari Ailus wrote:
 Hi Prabhakar,
 
 Thanks for the patch, and my apologies for delayed answer!
 
 On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote:
  From: Manjunath Hadli manjunath.ha...@ti.com
  
  add new enum entries for supporting the media-bus formats on dm365.
  These include some bayer and some non-bayer formats.
  V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used
  internal to the hardware by the resizer.
  V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format
  that is supported by dm365 hardware.
  
  Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  Acked-by: Hans Verkuil hans.verk...@cisco.com
  Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
  Signed-off-by: Lad, Prabhakar prabhakar@ti.com
  Cc: Sakari Ailus sakari.ai...@iki.fi
  Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
   Documentation/DocBook/media/v4l/subdev-formats.xml |  250 
  +++-
   include/linux/v4l2-mediabus.h  |   10 +-
   2 files changed, 252 insertions(+), 8 deletions(-)
  
  diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
  b/Documentation/DocBook/media/v4l/subdev-formats.xml
  index 49c532e..75dc275 100644
  --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
  +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
  @@ -353,9 +353,9 @@
  listitemparaThe number of bits per pixel component. All components 
  are
  transferred on the same number of bits. Common values are 8, 10 and 
  12./para
  /listitem
  -   listitemparaIf the pixel components are DPCM-compressed, a mention 
  of the
  -   DPCM compression and the number of bits per compressed pixel 
  component./para
  -   /listitem
  +   listitemparaThe compression (optional). If the pixel components are
  +   ALAW- or DPCM-compressed, a mention of the compression scheme and the
  +   number of bits per compressed pixel component./para/listitem
  listitemparaThe number of bus samples per pixel. Pixels that are 
  wider than
  the bus width must be transferred in multiple samples. Common values are
  1 and 2./para/listitem
  @@ -504,6 +504,74 @@
entryrsubscript1/subscript/entry
entryrsubscript0/subscript/entry
  /row
  +   row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8
  + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry
  + entry0x3015/entry
  + entry/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entrybsubscript7/subscript/entry
  + entrybsubscript6/subscript/entry
  + entrybsubscript5/subscript/entry
  + entrybsubscript4/subscript/entry
  + entrybsubscript3/subscript/entry
  + entrybsubscript2/subscript/entry
  + entrybsubscript1/subscript/entry
  + entrybsubscript0/subscript/entry
  +   /row
  +   row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8
  + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry
  + entry0x3016/entry
  + entry/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entrygsubscript7/subscript/entry
  + entrygsubscript6/subscript/entry
  + entrygsubscript5/subscript/entry
  + entrygsubscript4/subscript/entry
  + entrygsubscript3/subscript/entry
  + entrygsubscript2/subscript/entry
  + entrygsubscript1/subscript/entry
  + entrygsubscript0/subscript/entry
  +   /row
  +   row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8
  + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry
  + entry0x3017/entry
  + entry/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entrygsubscript7/subscript/entry
  + entrygsubscript6/subscript/entry
  + entrygsubscript5/subscript/entry
  + entrygsubscript4/subscript/entry
  + entrygsubscript3/subscript/entry
  + entrygsubscript2/subscript/entry
  + entrygsubscript1/subscript/entry
  + entrygsubscript0/subscript/entry
  +   /row
  +   row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8
  + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry
  + entry0x3018/entry
  + entry/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entry-/entry
  + entryrsubscript7/subscript/entry
  + entryrsubscript6/subscript/entry
  + entryrsubscript5/subscript/entry
  + entryrsubscript4/subscript/entry
  + entryrsubscript3/subscript/entry
  + entryrsubscript2/subscript/entry
  + entryrsubscript1/subscript/entry
  + entryrsubscript0/subscript/entry
  +   /row
  row id=V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8
entryV4L2_MBUS_FMT_SBGGR10_DPCM8_1X8/entry
entry0x300b/entry
  @@ -853,10 +921,16 @@

[GIT PULL for v3.6-rc1] media updates

2012-07-30 Thread Mauro Carvalho Chehab
Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus

This is the first part of the media patches for v3.6. During my 3-weeks vacation
that finished yesterday, I got about 400 patches on my queue. My intention is
to handle at least part of the pending stuff today, sending you another pull
request tomorrow with some other stuff that are mature enough for v3.6.

This patch series contain:
- new DVB frontend: rtl2832;
- new video drivers: adv7393;
- some unused files got removed;
- a selection API cleanup between V4L2 and V4L2 subdev API's;
- a major redesign at v4l-ioctl2, in order to clean it up;
- several driver fixes and improvements.

Thanks!
Mauro

-

Latest commit at the branch: 
c893e7c64e36087dceb4662917976a81d1754fc0 Merge branch 'patches_for_v3.6' into 
v4l_for_linus
The following changes since commit ec3ed85f926f4e900bc48cec6e72abbe6475321f:

  [media] Revert [media] V4L: JPEG class documentation corrections 
(2012-07-07 00:12:50 -0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus

for you to fetch changes up to c893e7c64e36087dceb4662917976a81d1754fc0:

  Merge branch 'patches_for_v3.6' into v4l_for_linus (2012-07-30 14:22:44 -0300)



Albert Wang (1):
  [media] videobuf2: correct the #ifndef text mistake in 
videobuf2-dma-contig.h

Andy Shevchenko (1):
  [media] media: dvb-usb: print mac address via native %pM

Antti Palosaari (5):
  [media] tda10071: fix DiSEqC message len check
  [media] tda10071: use decimal numbers for indexes and lengths
  [media] tda10071: convert Kernel dev_* logging
  [media] a8293: fix register 00 init value
  [media] a8293: use Kernel dev_* logging

Benoît Thébaudeau (4):
  [media] media: gpio-ir-recv: fix missing udev by-path entry
  [media] media: gpio-ir-recv: add map name
  [media] media: gpio-ir-recv: switch to module_platform_driver
  media: add Analog Devices ADV7393 video encoder driver

Dan Carpenter (3):
  [media] videobuf-dma-contig: use gfp_t for GFP flags
  [media] staging: solo6x10: fix | vs 
  [media] drxk: fix a '' vs '|' bug

Daniel Glöckner (10):
  [media] tvaudio: fix TDA9873 constants
  [media] tvaudio: fix tda8425_setmode
  [media] tvaudio: use V4L2_TUNER_MODE_SAP for TDA985x SAP
  [media] tvaudio: remove watch_stereo
  [media] tvaudio: don't use thread for TA8874Z
  [media] tvaudio: use V4L2_TUNER_SUB_* for bitfields
  [media] tvaudio: obey V4L2 tuner audio matrix
  [media] tvaudio: support V4L2_TUNER_MODE_LANG1_LANG2
  [media] tvaudio: don't report mono when stereo is received
  [media] tvaudio: rename getmode and setmode

David Dillow (2):
  [media] cx231xx: use TRANSFER_TYPE enum for cleanup
  [media] cx231xx: don't DMA to random addresses

Dmitry Lifshitz (1):
  [media] tvp5150: fix kernel crash if chip is unavailable

Du, Changbin (1):
  [media] media: gpio-ir-recv: add allowed_protos for platform data

Ezequiel García (6):
  [media] em28xx: Make em28xx_ir_change_protocol a static function
  [media] em28xx: Fix wrong AC97 mic register usage
  [media] em28xx: Rename AC97 registers to use sound/ac97_codec.h 
definitions
  [media] em28xx: Remove unused AC97 register definitions
  [media] em28xx: Make a few drxk_config structs static
  [media] staging: solo6x10: Fix TODO file with proper maintainer

Hans Verkuil (57):
  [media] videodev2.h: add new hwseek capability bits
  [media] v4l2 spec: document the new v4l2_tuner capabilities
  [media] S_HW_FREQ_SEEK: set capability flags and return ENODATA instead 
of EAGAIN
  [media] V4L2 spec: clarify a few modulator issues
  [media] V4L2 Spec: fix typo: NTSC - NRSC
  [media] zr364xx: embed video_device and register it at the end of probe
  [media] zr364xx: introduce v4l2_device
  [media] zr364xx: convert to the control framework
  [media] zr364xx: fix querycap and fill in colorspace
  [media] zr364xx: add support for control events
  [media] zr364xx: allow multiple opens
  [media] zr364xx: add suspend/resume support
  [media] v4l2-ioctl.c: move a block of code down, no other changes
  [media] v4l2-ioctl.c: introduce INFO_FL_CLEAR to replace switch
  [media] v4l2-ioctl.c: v4l2-ioctl: add debug and callback/offset 
functionality
  [media] v4l2-ioctl.c: remove an unnecessary #ifdef
  [media] v4l2-ioctl.c: use the new table for querycap and i/o ioctls
  [media] v4l2-ioctl.c: use the new table for priority ioctls
  [media] v4l2-ioctl.c: use the new table for format/framebuffer ioctls
  [media] v4l2-ioctl.c: use the new table for overlay/streamon/off ioctls
  [media] v4l2-ioctl.c: use the new table for std/tuner/modulator ioctls
  [media] 

Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365

2012-07-30 Thread Laurent Pinchart
Hi Hans,

On Monday 30 July 2012 20:36:36 Hans Verkuil wrote:
 On Sat July 28 2012 00:01:24 Sakari Ailus wrote:
  On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote:
   From: Manjunath Hadli manjunath.ha...@ti.com
   
   add new enum entries for supporting the media-bus formats on dm365.
   These include some bayer and some non-bayer formats.
   V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used
   internal to the hardware by the resizer.
   V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format
   that is supported by dm365 hardware.
   
   Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
   Acked-by: Hans Verkuil hans.verk...@cisco.com
   Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
   Signed-off-by: Lad, Prabhakar prabhakar@ti.com
   Cc: Sakari Ailus sakari.ai...@iki.fi
   Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
   
Documentation/DocBook/media/v4l/subdev-formats.xml |  250
+++- include/linux/v4l2-mediabus.h
 |   10 +-
2 files changed, 252 insertions(+), 8 deletions(-)
   
   diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
   b/Documentation/DocBook/media/v4l/subdev-formats.xml index
   49c532e..75dc275 100644
   --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
   +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
   @@ -353,9 +353,9 @@
   
 listitemparaThe number of bits per pixel component. All 
components
 are
 transferred on the same number of bits. Common values are 8, 10 and
 12./para /listitem
   
   - listitemparaIf the pixel components are DPCM-compressed, a 
mention
   of the -  DPCM compression and the number of bits per compressed pixel
   component./para -   /listitem
   + listitemparaThe compression (optional). If the pixel components
   are
   + ALAW- or DPCM-compressed, a mention of the compression scheme and the
   + number of bits per compressed pixel component./para/listitem
   
 listitemparaThe number of bus samples per pixel. Pixels that are
 wider than the bus width must be transferred in multiple samples.
 Common values are 1 and 2./para/listitem
   
   @@ -504,6 +504,74 @@
   
   entryrsubscript1/subscript/entry
   entryrsubscript0/subscript/entry
 
 /row
   
   + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8
   +   entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry
   +   entry0x3015/entry
   +   entry/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entrybsubscript7/subscript/entry
   +   entrybsubscript6/subscript/entry
   +   entrybsubscript5/subscript/entry
   +   entrybsubscript4/subscript/entry
   +   entrybsubscript3/subscript/entry
   +   entrybsubscript2/subscript/entry
   +   entrybsubscript1/subscript/entry
   +   entrybsubscript0/subscript/entry
   + /row
   + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8
   +   entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry
   +   entry0x3016/entry
   +   entry/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entrygsubscript7/subscript/entry
   +   entrygsubscript6/subscript/entry
   +   entrygsubscript5/subscript/entry
   +   entrygsubscript4/subscript/entry
   +   entrygsubscript3/subscript/entry
   +   entrygsubscript2/subscript/entry
   +   entrygsubscript1/subscript/entry
   +   entrygsubscript0/subscript/entry
   + /row
   + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8
   +   entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry
   +   entry0x3017/entry
   +   entry/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entrygsubscript7/subscript/entry
   +   entrygsubscript6/subscript/entry
   +   entrygsubscript5/subscript/entry
   +   entrygsubscript4/subscript/entry
   +   entrygsubscript3/subscript/entry
   +   entrygsubscript2/subscript/entry
   +   entrygsubscript1/subscript/entry
   +   entrygsubscript0/subscript/entry
   + /row
   + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8
   +   entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry
   +   entry0x3018/entry
   +   entry/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entry-/entry
   +   entryrsubscript7/subscript/entry
   +   entryrsubscript6/subscript/entry
   +   entryrsubscript5/subscript/entry
   +   entryrsubscript4/subscript/entry
   +   entryrsubscript3/subscript/entry
   +   entryrsubscript2/subscript/entry
   +   entryrsubscript1/subscript/entry
   +   entryrsubscript0/subscript/entry
   + /row
   
 row id=V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8
 
   entryV4L2_MBUS_FMT_SBGGR10_DPCM8_1X8/entry
   entry0x300b/entry
   
   @@ -853,10 +921,16 @@
   
  

[PATCH] media: mx3_camera: buf_init() add buffer state check

2012-07-30 Thread Alex Gershgorin
This patch check the state of the buffer when calling buf_init() method.
The thread 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the problem.
Both MMAP and USERPTR methods was successfully tested.

Signed-off-by: Alex Gershgorin al...@meprolight.com
---
 drivers/media/video/mx3_camera.c |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index f13643d..950a8fe 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
struct mx3_camera_dev *mx3_cam = ici-priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
 
-   /* This is for locking debugging only */
-   INIT_LIST_HEAD(buf-queue);
-   sg_init_table(buf-sg, 1);
+   if (buf-state != CSI_BUF_PREPARED) {
+   /* This is for locking debugging only */
+   INIT_LIST_HEAD(buf-queue);
+   sg_init_table(buf-sg, 1);
 
-   buf-state = CSI_BUF_NEEDS_INIT;
+   buf-state = CSI_BUF_NEEDS_INIT;
 
-   mx3_cam-buf_total += vb2_plane_size(vb, 0);
+   mx3_cam-buf_total += vb2_plane_size(vb, 0);
+   }
 
return 0;
 }
-- 
1.7.0.4

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


Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365

2012-07-30 Thread Hans Verkuil
On Mon July 30 2012 21:06:33 Laurent Pinchart wrote:
 Hi Hans,
 
 On Monday 30 July 2012 20:36:36 Hans Verkuil wrote:
  On Sat July 28 2012 00:01:24 Sakari Ailus wrote:
   On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote:
From: Manjunath Hadli manjunath.ha...@ti.com

add new enum entries for supporting the media-bus formats on dm365.
These include some bayer and some non-bayer formats.
V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used
internal to the hardware by the resizer.
V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format
that is supported by dm365 hardware.

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---

 Documentation/DocBook/media/v4l/subdev-formats.xml |  250
 +++- include/linux/v4l2-mediabus.h
  |   10 +-
 2 files changed, 252 insertions(+), 8 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
b/Documentation/DocBook/media/v4l/subdev-formats.xml index
49c532e..75dc275 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -353,9 +353,9 @@

listitemparaThe number of bits per pixel component. All 
 components
are
transferred on the same number of bits. Common values are 8, 10 
and
12./para /listitem

-   listitemparaIf the pixel components are DPCM-compressed, a 
 mention
of the -DPCM compression and the number of bits per compressed 
pixel
component./para - /listitem
+   listitemparaThe compression (optional). If the pixel 
components
are
+   ALAW- or DPCM-compressed, a mention of the compression scheme 
and the
+   number of bits per compressed pixel component./para/listitem

listitemparaThe number of bus samples per pixel. Pixels 
that are
wider than the bus width must be transferred in multiple 
samples.
Common values are 1 and 2./para/listitem

@@ -504,6 +504,74 @@

  entryrsubscript1/subscript/entry
  entryrsubscript0/subscript/entry

/row

+   row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8
+ entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry
+ entry0x3015/entry
+ entry/entry
+ entry-/entry
+ entry-/entry
+ entry-/entry
+ entry-/entry
+ entrybsubscript7/subscript/entry
+ entrybsubscript6/subscript/entry
+ entrybsubscript5/subscript/entry
+ entrybsubscript4/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+   /row
+   row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8
+ entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry
+ entry0x3016/entry
+ entry/entry
+ entry-/entry
+ entry-/entry
+ entry-/entry
+ entry-/entry
+ entrygsubscript7/subscript/entry
+ entrygsubscript6/subscript/entry
+ entrygsubscript5/subscript/entry
+ entrygsubscript4/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+   /row
+   row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8
+ entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry
+ entry0x3017/entry
+ entry/entry
+ entry-/entry
+ entry-/entry
+ entry-/entry
+ entry-/entry
+ entrygsubscript7/subscript/entry
+ entrygsubscript6/subscript/entry
+ entrygsubscript5/subscript/entry
+ entrygsubscript4/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+   /row
+   row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8
+ entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry
+ entry0x3018/entry
+ entry/entry
+ entry-/entry
  

cron job: media_tree daily build: ERRORS

2012-07-30 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Mon Jul 30 19:00:22 CEST 2012
git hash:9bc31633c20ca6a49071f2162c232ae556151cc2
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: ERRORS
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: ERRORS
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: ERRORS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The 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


Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365

2012-07-30 Thread Sylwester Nawrocki
Hi Laurent,

On 07/30/2012 09:06 PM, Laurent Pinchart wrote:
 -  bus. Possible values are YUYV, UYVY, YVYU and VYUY./para/listitem
 +  bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with
 no
 +  dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC
 formats. + /para/listitem

listitemparaThe number of bits per pixel component. All
 components
are
transferred on the same number of bits. Common values are 8, 10 and
12./para  /listitem

 I dicussed dummy vs. padding (zeros) with Laurent and we concluded we
 should use zero padding instead. The difference is that when processing
 the pixels no extra operations are necessary to get rid of the dummy data
 when the dummy bits are actually zero --- which in practice always is the
 case.

 I'm not aware of hardware that would assign padding bits (in this very
 purpose) that are a part of writes the width of bus width something else
 than zeros. It wouldn't make much sense either.

 So I suggest that dummy is replaced by padding which is defined to be
 zero.

 The letter in the format name could be 'Z', for example.

 Hans: what do you think?

 Bad idea. First of all, some hardware or FPGA can insert different values
 there. It's something that Cisco uses in some cases: it makes it easier to
 identify the dummy values if they have a non-zero fixed value.

 Another reason for not doing this is when such formats are used to display
 video: you don't want to force the software to fill in the dummy values
 with a specific value for no good reason. That would only cost extra CPU
 cycles.
 
 On the other hand, when you process data that includes dummy bits stored in
 memory, knowing that the dummy bits are zero can save a mask operation.
 
 I don't have a strong opinion whether we should use zero or dummy bits for
 media bus formats. For memory formats I'd be inclined to use zero bits (at
 least when capturing).

Perhaps it would make sense to assume those dummy bits have undefined
value and add some other API for retrieving/setting them where possible,
e.g. a v4l2 control ?

It just feels like an unnecessary API limitation to assume those dummy
bits are always zero.

--

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: [GIT PULL FOR v3.6] DVB USB v2

2012-07-30 Thread Mauro Carvalho Chehab
Em 09-07-2012 15:49, Antti Palosaari escreveu:
 On 07/07/2012 01:22 AM, Mauro Carvalho Chehab wrote:
 Em 03-07-2012 18:47, Antti Palosaari escreveu:
 On 07/02/2012 04:08 PM, Antti Palosaari wrote:
 Here it is finally - quite totally rewritten DVB-USB-framework. I
 haven't got almost any feedback so far...

 I rebased it in order to fix compilation issues coming from Kconfig.


 regards
 Antti


 The following changes since commit
 6887a4131da3adaab011613776d865f4bcfb5678:

 Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)

 are available in the git repository at:

 git://linuxtv.org/anttip/media_tree.git dvb_usb_pull

 for you to fetch changes up to 747abaa1e0ee4415e67026c119cb73e6277f4898:

 dvb_usb_v2: remove usb_clear_halt() from stream (2012-07-02 15:54:29
 +0300)

 
 Antti Palosaari (103):
 dvb_usb_v2: copy current dvb_usb as a starting point

 Naming the DVB USB v2 as dvb_usb, instead of dvb-usb is very very ugly.
 It took me some time to discover what happened.

 You should have named it as dvb-usb-v2 instead, or to store it into
 a separate directory.

 This is even worse as it seems that this series doesn't change all
 drivers to use dvb usb v2. So, it will be harder to discover what
 drivers are at V1 and what are at V2.

 I won't merge it as-is at staging/for_v3.6. I may eventually create
 a separate topic branch and add them there, while the namespace mess
 is not corrected, if I still have some time today. Otherwise, I'll only
 handle that after returning from vacations.
 
 I moved it to the dvb-usb-v2 directory. Same location only added patch top of 
 that.
 
 Surely I can convert all drivers and use old directory, but IMHO it is simply 
 too risky. We have already too much problems coming from that kind of big 
 changes.
 
 And what goes to file naming hyphen (-) vs. underscore (_), underscore seems 
 to be much more common inside Kernel. Anyhow, I keep directory name as 
 dvb-usb-v2 to follow old naming.
 
 $ find ./ -type f -printf %f\n | grep _ | wc -l
 21465
 $ find ./ -type f -printf %f\n | grep - | wc -l
 13927

The above works for me, but unfortunately, the tree can't be applied.

The fact is that there are lots of duplicated symbols between dvb-usb and 
dvb-usb-v2.
They'll fail if someone would compile everything bultin (make allyesconfig).

I tried to remove the Kconfig/Makefile changes from the initial patch, moving 
it to
happen just before the first driver using dvb-usb-v2. See:


http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/dvb-usb-v2


The patch that adds it to the build system is enclosed. It is basically what's 
there at
the initial patch, plus the changes done at the intermediate patches at the 
Makefile.

The result is shown below:

# make ARCH=i386 allyesconfig
...
$ make ARCH=i386 CONFIG_DEBUG_SECTION_MISMATCH=y M=drivers/media
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function 
`_GLOBAL__sub_I_65535_0_dvb_usb_download_firmware':
/home/v4l/v4l/patchwork/include/linux/usb.h:197: multiple definition of 
`dvb_usb_disable_rc_polling'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/include/linux/usb.h:1570:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `usb_urb_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb_urb.c:310: multiple 
definition of `usb_urb_init'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb-urb.c:213:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function 
`dvb_usb_adapter_frontend_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:332: multiple 
definition of `dvb_usb_adapter_frontend_init'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:221:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_exit':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:260: multiple 
definition of `dvb_usb_adapter_dvb_exit'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:164:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:191: multiple 
definition of `dvb_usb_adapter_dvb_init'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:98:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_device_power_ctrl':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_init.c:254: multiple 
definition of `dvb_usb_device_power_ctrl'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-init.c:216:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_remote_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_remote.c:42: multiple 

Re: [RFC] media DT bindings

2012-07-30 Thread Sylwester Nawrocki
On 07/23/2012 02:14 PM, Mark Brown wrote:
 On Wed, Jul 18, 2012 at 07:00:15PM +0200, Sylwester Nawrocki wrote:
 
 One possible solution would be to have host/bridge drivers to register
 a clkdev entry for I2C client device, so it can acquire the clock through
 just clk_get(). We would have to ensure the clock is not tried to be
 accessed before it is registered by a bridge. This would require to add
 clock handling code to all sensor/encoder subdev drivers though..
 
 If this is done well it could just be a simple callback, and we could
 probably arrange for the framework to just implement the default
 behaviour if the driver doesn't do anything explicit.

I agree, if a clock is bound to a sub-device beforehand it could 
probably be done with just a callback as well. Implementing default 
behaviour at the framework makes a lot of sense too, it could ease 
the conversion process significantly.

 Of couse this is one of those things where we really need the generic
 clock API to be generally available...

Indeed, I hope it won't take too much time before at least some of the
platforms get converted.

--

Thanks,
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: [RFC/PATCH 05/13] media: s5p-fimc: Add device tree support for FIMC devices

2012-07-30 Thread Sylwester Nawrocki
Hi Laurent,

On 07/26/2012 04:54 PM, Laurent Pinchart wrote:
 On Wednesday 18 July 2012 21:53:34 Sylwester Nawrocki wrote:
 I think we need a one combined RFC and continue discussions in one thread.
 
 Agreed.
 
 Still, our proposals are quite different, but I believe we need something
 in between. I presume we should focus more to have common bindings for
 subdevs that are reused among different host/ISP devices, i.e. sensors and
 encoders. For simple host interfaces we can likely come up with common
 binding patterns, but more complex processing pipelines may require
 a sort of individual approach.

 The suspend/resume handling is still something I don't have an idea
 on how the solution for might look like..
 Instantiating all devices from a top level driver could help, but it
 is only going to work when platforms are converted to the common clock
 framework and have their clocks instantiated from device tree.

 This week I'm out of office, and next one or two I have some pending
 assignments. So there might be some delay before I can dedicate some
 reasonable amount of time to carry on with that topic.

 I unfortunately won't be attending KS this time.
 
 That's bad news :-( I still think this topic should be discussed during KS, I

Yeah, shit happens.. :) I guess -ENOBUDGET this time... I didn't really 
plan early to attend KS, I might be coming to ELCE though. However it's 
a rather distant event and we'll probably get most things settled by 
that time.

 expect several developers to be interested. The media workshop might not be
 the best venue though, as we might need quite a lot of time.

 Until KS let's continue the discussion by e-mail.

OK, thank you for taking time to review the RFCs.

--

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: Asus PVR-416

2012-07-30 Thread Andy Walls
On Mon, 2012-07-30 at 06:57 -0400, Jerry Haggard wrote:
 I've been trying to get an ASUS PVR-416 card to work with MythTV .25 on 
 Scientific Linux 6.  I have a bttv card working, my setup works in 
 general, etc, and the driver attempts to load.  But when I check dmesg, 
 I keep getting firmware load errors and checksum errors. I've tried 
 every firmware I could find.  I've used the one from Atrpms, I've 
 downloaded the correctly named firmware from ivtv, but no luck.  Anyone 
 know anything about this card?  I've tried cutting the drivers myself 
 like it says in the direcitons at mythtv.org. This is supposed to be a 
 supported card, does anyone have any experience with it?

No experience with it.  It is supposedly a Blackbird design supported by
the cx88 driver.

My standard response for legacy PCI cards that are responding somewhat,
but aren't working properly, is to

1. remove all the legacy PCI cards from all the slots
2. blow the dust out of all the slots
3. if feasible, reseat only the 1 card and test again
4. reseat all the cards and test again

Since legacy PCI uses reflected wave switching, dust in any one slot can
cause problems.  It's a troubleshooting step that's easy enough to do.

If that doesn't work, we would need to see the output of dmesg
and/or /var/log/messages when the module is being loaded and the
firmware loaded.  If providing logs, please don't just grep on the
'cx88' lines, since other modules are involved in getting the card
working.

Regards,
Andy

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


[media-ctl PATCH 1/1] libv4l2subdev: Add v4l2_subdev_enum_mbus_code()

2012-07-30 Thread Sakari Ailus
v4l2_subdev_enum_mbus_code() enumerates over supported media bus formats on
a pad.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 src/v4l2subdev.c |   23 +++
 src/v4l2subdev.h |   14 ++
 2 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
index d60bd7e..6b6df0a 100644
--- a/src/v4l2subdev.c
+++ b/src/v4l2subdev.c
@@ -58,6 +58,29 @@ void v4l2_subdev_close(struct media_entity *entity)
entity-fd = -1;
 }
 
+int v4l2_subdev_enum_mbus_code(struct media_entity *entity,
+  uint32_t *code, uint32_t pad, uint32_t index)
+{
+   struct v4l2_subdev_mbus_code_enum c;
+   int ret;
+
+   ret = v4l2_subdev_open(entity);
+   if (ret  0)
+   return ret;
+
+   memset(c, 0, sizeof(c));
+   c.pad = pad;
+   c.index = index;
+
+   ret = ioctl(entity-fd, VIDIOC_SUBDEV_ENUM_MBUS_CODE, c);
+   if (ret  0)
+   return -errno;
+
+   *code = c.code;
+
+   return 0;
+}
+
 int v4l2_subdev_get_format(struct media_entity *entity,
struct v4l2_mbus_framefmt *format, unsigned int pad,
enum v4l2_subdev_format_whence which)
diff --git a/src/v4l2subdev.h b/src/v4l2subdev.h
index 5d55482..1cca7b9 100644
--- a/src/v4l2subdev.h
+++ b/src/v4l2subdev.h
@@ -22,6 +22,7 @@
 #ifndef __SUBDEV_H__
 #define __SUBDEV_H__
 
+#include stdint.h
 #include linux/v4l2-subdev.h
 
 struct media_entity;
@@ -47,6 +48,19 @@ int v4l2_subdev_open(struct media_entity *entity);
 void v4l2_subdev_close(struct media_entity *entity);
 
 /**
+ * @brief Enumerate mbus pixel codes.
+ * @param entity - subdev-device media entity.
+ * @param code - mbus pixel code
+ *
+ * Enumerate media bus pixel codes. This is just a wrapper for
+ * VIDIOC_SUBDEV_ENUM_MBUS_CODE IOCTL.
+ *
+ * @return 0 on success, or a negative error code on failure.
+ */
+int v4l2_subdev_enum_mbus_code(struct media_entity *entity,
+  uint32_t *code, uint32_t pad, uint32_t index);
+
+/**
  * @brief Retrieve the format on a pad.
  * @param entity - subdev-device media entity.
  * @param format - format to be filled.
-- 
1.7.2.5

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


Re: [PATCH] Use a named union in struct v4l2_ioctl_info

2012-07-30 Thread Stephen Rothwell
Hi Mauro,

On Fri, 13 Jul 2012 11:25:30 +1000 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 On Thu, 12 Jul 2012 18:06:24 +0200 Hans Verkuil hverk...@xs4all.nl wrote:
 
  struct v4l2_ioctl_info uses an anonymous union, which is initialized
  in the v4l2_ioctls table.
  
  Unfortunately gcc  4.6 uses a non-standard syntax for that, so trying to
  compile v4l2-ioctl.c with an older gcc will fail.
  
  It is possible to work around this by testing the gcc version, but in this
  case it is easier to make the union named since it is used in only a few
  places.
  
  Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem
  in linux-next. Since Mauro is still on holiday you'll have to apply it 
  manually.
 
 I have added this as a merge fix for today.

Ping?
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpMPD0fMfa9j.pgp
Description: PGP signature


Re: [PULL] video_visstrim for 3.6

2012-07-30 Thread Mauro Carvalho Chehab
Em 26-07-2012 06:36, Javier Martin escreveu:
 Hi Mauro,
 this pull request is composed of two series that provide support for two 
 mem2mem devices:
 - 'm2m-deinterlace' video deinterlacer
 - 'coda video codec'
 I've included platform support for them too.
 
 
 The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:
 
Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
 
 are available in the git repository at:
 
https://github.com/jmartinc/video_visstrim.git for_3.6
 
 for you to fetch changes up to 9bb10266da63ae7f8f198573e099580e9f98f4e8:
 
i.MX27: Visstrim_M10: Add support for deinterlacing driver. (2012-07-26 
 10:57:30 +0200)
 
 
 Javier Martin (5):
i.MX: coda: Add platform support for coda in i.MX27.
media: coda: Add driver for Coda video codec.
Visstrim M10: Add support for Coda.
media: Add mem2mem deinterlacing driver.
i.MX27: Visstrim_M10: Add support for deinterlacing driver.
 
   arch/arm/mach-imx/clk-imx27.c   |4 +-
   arch/arm/mach-imx/devices-imx27.h   |4 +
   arch/arm/mach-imx/mach-imx27_visstrim_m10.c |   49 +-
   arch/arm/plat-mxc/devices/Kconfig   |6 +-
   arch/arm/plat-mxc/devices/Makefile  |1 +
   arch/arm/plat-mxc/devices/platform-imx27-coda.c |   37 +
   arch/arm/plat-mxc/include/mach/devices-common.h |8 +

I need ARM maintainer's ack for the patches that touch the above files.

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


Re: [GIT PULL FOR v3.6] DVB USB v2

2012-07-30 Thread Antti Palosaari

On 07/30/2012 11:46 PM, Mauro Carvalho Chehab wrote:

Em 09-07-2012 15:49, Antti Palosaari escreveu:

On 07/07/2012 01:22 AM, Mauro Carvalho Chehab wrote:

Em 03-07-2012 18:47, Antti Palosaari escreveu:

On 07/02/2012 04:08 PM, Antti Palosaari wrote:

Here it is finally - quite totally rewritten DVB-USB-framework. I
haven't got almost any feedback so far...


I rebased it in order to fix compilation issues coming from Kconfig.



regards
Antti


The following changes since commit
6887a4131da3adaab011613776d865f4bcfb5678:

 Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)

are available in the git repository at:

 git://linuxtv.org/anttip/media_tree.git dvb_usb_pull

for you to fetch changes up to 747abaa1e0ee4415e67026c119cb73e6277f4898:

 dvb_usb_v2: remove usb_clear_halt() from stream (2012-07-02 15:54:29
+0300)


Antti Palosaari (103):
 dvb_usb_v2: copy current dvb_usb as a starting point


Naming the DVB USB v2 as dvb_usb, instead of dvb-usb is very very ugly.
It took me some time to discover what happened.

You should have named it as dvb-usb-v2 instead, or to store it into
a separate directory.

This is even worse as it seems that this series doesn't change all
drivers to use dvb usb v2. So, it will be harder to discover what
drivers are at V1 and what are at V2.

I won't merge it as-is at staging/for_v3.6. I may eventually create
a separate topic branch and add them there, while the namespace mess
is not corrected, if I still have some time today. Otherwise, I'll only
handle that after returning from vacations.


I moved it to the dvb-usb-v2 directory. Same location only added patch top of 
that.

Surely I can convert all drivers and use old directory, but IMHO it is simply 
too risky. We have already too much problems coming from that kind of big 
changes.

And what goes to file naming hyphen (-) vs. underscore (_), underscore seems to 
be much more common inside Kernel. Anyhow, I keep directory name as dvb-usb-v2 
to follow old naming.

$ find ./ -type f -printf %f\n | grep _ | wc -l
21465
$ find ./ -type f -printf %f\n | grep - | wc -l
13927


The above works for me, but unfortunately, the tree can't be applied.

The fact is that there are lots of duplicated symbols between dvb-usb and 
dvb-usb-v2.
They'll fail if someone would compile everything bultin (make allyesconfig).

I tried to remove the Kconfig/Makefile changes from the initial patch, moving 
it to
happen just before the first driver using dvb-usb-v2. See:


http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/dvb-usb-v2


The patch that adds it to the build system is enclosed. It is basically what's 
there at
the initial patch, plus the changes done at the intermediate patches at the 
Makefile.

The result is shown below:

# make ARCH=i386 allyesconfig
...
$ make ARCH=i386 CONFIG_DEBUG_SECTION_MISMATCH=y M=drivers/media
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function 
`_GLOBAL__sub_I_65535_0_dvb_usb_download_firmware':
/home/v4l/v4l/patchwork/include/linux/usb.h:197: multiple definition of 
`dvb_usb_disable_rc_polling'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/include/linux/usb.h:1570:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `usb_urb_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb_urb.c:310: multiple 
definition of `usb_urb_init'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb-urb.c:213:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function 
`dvb_usb_adapter_frontend_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:332: multiple 
definition of `dvb_usb_adapter_frontend_init'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:221:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_exit':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:260: multiple 
definition of `dvb_usb_adapter_dvb_exit'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:164:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:191: multiple 
definition of `dvb_usb_adapter_dvb_init'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:98:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_device_power_ctrl':
/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_init.c:254: multiple 
definition of `dvb_usb_device_power_ctrl'
drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-init.c:216:
 first defined here
drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_remote_init':

Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements

2012-07-30 Thread Mauro Carvalho Chehab
Em 25-07-2012 10:48, Antti Palosaari escreveu:
 On 07/25/2012 04:24 PM, Devin Heitmueller wrote:
 On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner tim.gard...@canonical.com 
 wrote:
 This will make modinfo more useful with regard
 to discovering necessary firmware files.

 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: Michael Krufky mkru...@kernellabs.com
 Cc: Eddi De Pieri e...@depieri.net
 Cc: linux-media@vger.kernel.org
 Signed-off-by: Tim Gardner tim.gard...@canonical.com
 ---
   drivers/media/common/tuners/xc5000.c |8 ++--
   1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/common/tuners/xc5000.c 
 b/drivers/media/common/tuners/xc5000.c
 index dcca42c..4d33f86 100644
 --- a/drivers/media/common/tuners/xc5000.c
 +++ b/drivers/media/common/tuners/xc5000.c
 @@ -210,13 +210,15 @@ struct xc5000_fw_cfg {
  u16 size;
   };

 +#define XC5000A_FIRMWARE dvb-fe-xc5000-1.6.114.fw
   static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
 -   .name = dvb-fe-xc5000-1.6.114.fw,
 +   .name = XC5000A_FIRMWARE,
  .size = 12401,
   };

 +#define XC5000C_FIRMWARE dvb-fe-xc5000c-41.024.5.fw
   static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
 -   .name = dvb-fe-xc5000c-41.024.5.fw,
 +   .name = XC5000C_FIRMWARE,
  .size = 16497,
   };

 @@ -1253,3 +1255,5 @@ EXPORT_SYMBOL(xc5000_attach);
   MODULE_AUTHOR(Steven Toth);
   MODULE_DESCRIPTION(Xceive xc5000 silicon tuner driver);
   MODULE_LICENSE(GPL);
 +MODULE_FIRMWARE(XC5000A_FIRMWARE);
 +MODULE_FIRMWARE(XC5000C_FIRMWARE);
 -- 

 Hi Tim,

 I'm just eyeballing the patch and I'm not familiar with this new
 functionality, but where are the new macros you're specifying actually
 defined?  You're swapping out the filename for XC5000A_FIRMWARE, but
 where is the actual reference to dvb-fe-xc5000-1.6.114.fw?

 Also, Mauro, can I merge this into my tree first rather than you
 pulling it direct?  I've got a whole patch series for xc5000 that I'm
 slated to issue a PULL for this weekend, and I *really* don't want to
 rebase the series for a four line change (which will definitely cause
 a conflict).

Devin,

As you didn't send your pull request in time for 3.6, I'll add this one,
as otherwise it will miss the 3.6 bus. 

You don't need to rebase your pull request due to that anyway, as, if a
merge conflict happens, I'll fix it, as it should be trivial.

I'm fixing trivial merge conflicts like that all the time. Just today, I
fixed maybe dozens of similar ones.

The conflicts that I ask developers to rework are the ones where the complex
logic is modified by two different patches.


 Devin
 
 Also this issue has been spoken earlier and nacked. It was 2009 when Ben 
 Hutchings sends large patch serie adding MODULE_FIRMWARE for every 
 Linux-Media driver. I am not sure if arguments are changed after that to 
 allow it now.
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg11373.html

On Ben's patchset, firmwares were added to the bridge driver. That's wrong.

Adding it to the driver that actually uses the firmware looks OK on my eyes.

 regards
 Antti

Regards,
Mauro

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


Re: [PATCH] Add support for Prof Revolution DVB-S2 8000 PCI-E card

2012-07-30 Thread Mauro Carvalho Chehab
Em 26-07-2012 15:08, Mariusz Bialonczyk escreveu:
 The device is based on STV0903 demodulator, STB6100 tuner
 and CX23885 chipset; subsystem id: 8000:3034
 
 Signed-off-by: Mariusz Bialonczyk ma...@skyboo.net

This is the second time I see this patch. It seems very similar to the
one sent by Wojciech. So, who is the author of this patch?


 ---
   drivers/media/video/cx23885/Kconfig |1 +
   drivers/media/video/cx23885/cx23885-cards.c |   10 +
   drivers/media/video/cx23885/cx23885-dvb.c   |   56 
 +++
   drivers/media/video/cx23885/cx23885.h   |1 +
   4 files changed, 68 insertions(+)
 
 diff --git a/drivers/media/video/cx23885/Kconfig 
 b/drivers/media/video/cx23885/Kconfig
 index b391e9b..510adfe 100644
 --- a/drivers/media/video/cx23885/Kconfig
 +++ b/drivers/media/video/cx23885/Kconfig
 @@ -21,6 +21,7 @@ config VIDEO_CX23885
   select DVB_STV6110 if !DVB_FE_CUSTOMISE
   select DVB_CX24116 if !DVB_FE_CUSTOMISE
   select DVB_STV0900 if !DVB_FE_CUSTOMISE
 + select DVB_STV090x if !DVB_FE_CUSTOMISE
   select DVB_DS3000 if !DVB_FE_CUSTOMISE
   select DVB_STV0367 if !DVB_FE_CUSTOMISE
   select MEDIA_TUNER_MT2131 if !MEDIA_TUNER_CUSTOMISE

You've included 3 files at -dvb:

+#include stv090x.h
+#include stb6100.h
+#include stb6100_cfg.h

but you're selecting only STV090x. It seems you missed stb6100 here.


 diff --git a/drivers/media/video/cx23885/cx23885-cards.c 
 b/drivers/media/video/cx23885/cx23885-cards.c
 index 080e111..50fedff 100644
 --- a/drivers/media/video/cx23885/cx23885-cards.c
 +++ b/drivers/media/video/cx23885/cx23885-cards.c
 @@ -564,6 +564,10 @@ struct cx23885_board cx23885_boards[] = {
   [CX23885_BOARD_TEVII_S471] = {
   .name   = TeVii S471,
   .portb  = CX23885_MPEG_DVB,
 + },
 + [CX23885_BOARD_PROF_8000] = {
 + .name   = Prof Revolution DVB-S2 8000,
 + .portb  = CX23885_MPEG_DVB,
   }
   };
   const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
 @@ -776,6 +780,10 @@ struct cx23885_subid cx23885_subids[] = {
   .subvendor = 0xd471,
   .subdevice = 0x9022,
   .card  = CX23885_BOARD_TEVII_S471,
 + }, {
 + .subvendor = 0x8000,
 + .subdevice = 0x3034,
 + .card  = CX23885_BOARD_PROF_8000,
   },
   };
   const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
 @@ -1155,6 +1163,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
   cx_set(GP0_IO, 0x00040004);
   break;
   case CX23885_BOARD_TBS_6920:
 + case CX23885_BOARD_PROF_8000:
   cx_write(MC417_CTL, 0x0036);
   cx_write(MC417_OEN, 0x1000);
   cx_set(MC417_RWD, 0x0002);
 @@ -1536,6 +1545,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
   case CX23885_BOARD_TEVII_S470:
   case CX23885_BOARD_TEVII_S471:
   case CX23885_BOARD_DVBWORLD_2005:
 + case CX23885_BOARD_PROF_8000:
   ts1-gen_ctrl_val  = 0x5; /* Parallel */
   ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
   ts1-src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
 diff --git a/drivers/media/video/cx23885/cx23885-dvb.c 
 b/drivers/media/video/cx23885/cx23885-dvb.c
 index cd54268..ba046ea 100644
 --- a/drivers/media/video/cx23885/cx23885-dvb.c
 +++ b/drivers/media/video/cx23885/cx23885-dvb.c
 @@ -63,6 +63,9 @@
   #include stv0367.h
   #include drxk.h
   #include mt2063.h
 +#include stv090x.h
 +#include stb6100.h
 +#include stb6100_cfg.h
   
   static unsigned int debug;
   
 @@ -489,6 +492,42 @@ static struct xc5000_config mygica_x8506_xc5000_config = 
 {
   .if_khz = 5380,
   };
   
 +static struct stv090x_config prof_8000_stv090x_config = {
 +.device = STV0903,
 +.demod_mode = STV090x_SINGLE,
 +.clk_mode   = STV090x_CLK_EXT,
 +.xtal   = 2700,
 +.address= 0x6A,
 +.ts1_mode   = STV090x_TSMODE_PARALLEL_PUNCTURED,
 +.repeater_level = STV090x_RPTLEVEL_64,
 +.adc1_range = STV090x_ADC_2Vpp,
 +.diseqc_envelope_mode   = false,
 +
 +.tuner_get_frequency= stb6100_get_frequency,
 +.tuner_set_frequency= stb6100_set_frequency,
 +.tuner_set_bandwidth= stb6100_set_bandwidth,
 +.tuner_get_bandwidth= stb6100_get_bandwidth,
 +};
 +
 +static struct stb6100_config prof_8000_stb6100_config = {
 + .tuner_address = 0x60,
 + .refclock = 2700,
 +};
 +
 +static int p8000_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t 
 voltage)
 +{
 + struct cx23885_tsport *port = fe-dvb-priv;
 + struct cx23885_dev *dev = port-dev;
 +
 + if (voltage == SEC_VOLTAGE_18)
 + cx_write(MC417_RWD, 0x1e00);
 + else if 

Re: [PATCH 2/2] [media] ngene: add support for Terratec Cynergy 2400i, Dual DVB-T

2012-07-30 Thread Mauro Carvalho Chehab
Em 29-07-2012 17:50, Patrice Chotard escreveu:
 [media] ngene: add support for Terratec Cynergy 2400i
   Dual DVB-T

Sorry, but the patch got line wrapped. Please re-send this patch series.

Thanks!
Mauro
 
 This code is based on ngene initial check-in
 (dae52d009fc950b5c209260d50fcc000f5becd3c)
 
 Signed-off-by: Patrice Chotard patricechot...@free.fr
 ---
   drivers/media/dvb/ngene/ngene-cards.c |  263
 +
   1 files changed, 263 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/dvb/ngene/ngene-cards.c
 b/drivers/media/dvb/ngene/ngene-cards.c
 index 7539a5d..08c610f 100644
 --- a/drivers/media/dvb/ngene/ngene-cards.c
 +++ b/drivers/media/dvb/ngene/ngene-cards.c
 @@ -42,6 +42,8 @@
   #include mt2131.h
   #include tda18271c2dd.h
   #include drxk.h
 +#include drxd.h
 +#include dvb-pll.h
 
 
   
 //
 @@ -312,6 +314,235 @@ static int demod_attach_lg330x(struct
 ngene_channel *chan)
   return (chan-fe) ? 0 : -ENODEV;
   }
 
 +static int demod_attach_drxd(struct ngene_channel *chan)
 +{
 + struct drxd_config *feconf;
 +
 + feconf = chan-dev-card_info-fe_config[chan-number];
 +
 + chan-fe = dvb_attach(drxd_attach, feconf, chan,
 + chan-i2c_adapter, chan-dev-pci_dev-dev);
 + if (!chan-fe) {
 + pr_err(No DRXD found!\n);
 + return -ENODEV;
 + }
 +
 + if (!dvb_attach(dvb_pll_attach, chan-fe, feconf-pll_address,
 + chan-i2c_adapter,
 + feconf-pll_type)) {
 + pr_err(No pll(%d) found!\n, feconf-pll_type);
 + return -ENODEV;
 + }
 + return 0;
 +}
 +
 +//
 +/* EEPROM TAGS
 **/
 +//
 +
 +#define MICNG_EE_START  0x0100
 +#define MICNG_EE_END0x0FF0
 +
 +#define MICNG_EETAG_END00x
 +#define MICNG_EETAG_END10x
 +
 +/* 0x0001 - 0x000F reserved for housekeeping */
 +/* 0x - 0xFFFE reserved for housekeeping */
 +
 +/* Micronas assigned tags
 +   EEProm tags for hardware support */
 +
 +#define MICNG_EETAG_DRXD1_OSCDEVIATION  0x1000  /* 2 Bytes data */
 +#define MICNG_EETAG_DRXD2_OSCDEVIATION  0x1001  /* 2 Bytes data */
 +
 +#define MICNG_EETAG_MT2060_1_1STIF  0x1100  /* 2 Bytes data */
 +#define MICNG_EETAG_MT2060_2_1STIF  0x1101  /* 2 Bytes data */
 +
 +/* Tag range for OEMs */
 +
 +#define MICNG_EETAG_OEM_FIRST  0xC000
 +#define MICNG_EETAG_OEM_LAST   0xFFEF
 +
 +static int i2c_write_eeprom(struct i2c_adapter *adapter,
 + u8 adr, u16 reg, u8 data)
 +{
 + u8 m[3] = {(reg  8), (reg  0xff), data};
 + struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m,
 +   .len = sizeof(m)};
 +
 + if (i2c_transfer(adapter, msg, 1) != 1) {
 + pr_err(DEVICE_NAME : Error writing EEPROM!\n);
 + return -EIO;
 + }
 + return 0;
 +}
 +
 +static int i2c_read_eeprom(struct i2c_adapter *adapter,
 +u8 adr, u16 reg, u8 *data, int len)
 +{
 + u8 msg[2] = {(reg  8), (reg  0xff)};
 + struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
 +.buf = msg, .len = 2 },
 +   {.addr = adr, .flags = I2C_M_RD,
 +.buf = data, .len = len} };
 +
 + if (i2c_transfer(adapter, msgs, 2) != 2) {
 + pr_err(DEVICE_NAME : Error reading EEPROM\n);
 + return -EIO;
 + }
 + return 0;
 +}
 +
 +static int ReadEEProm(struct i2c_adapter *adapter,
 +   u16 Tag, u32 MaxLen, u8 *data, u32 *pLength)
 +{
 + int status = 0;
 + u16 Addr = MICNG_EE_START, Length, tag = 0;
 + u8  EETag[3];
 +
 + while (Addr + sizeof(u16) + 1  MICNG_EE_END) {
 + if (i2c_read_eeprom(adapter, 0x50, Addr, EETag, sizeof(EETag)))
 + return -1;
 + tag = (EETag[0]  8) | EETag[1];
 + if (tag == MICNG_EETAG_END0 || tag == MICNG_EETAG_END1)
 + return -1;
 + if (tag == Tag)
 + break;
 + Addr += sizeof(u16) + 1 + EETag[2];
 + }
 + if (Addr + sizeof(u16) + 1 + EETag[2]  MICNG_EE_END) {
 + pr_err(DEVICE_NAME
 +: Reached EOEE @ Tag = %04x Length = %3d\n,
 +tag, EETag[2]);
 + return -1;
 + }
 + Length = EETag[2];
 + if (Length  MaxLen)
 + Length = (u16) MaxLen;
 + if (Length  0) {
 + Addr += sizeof(u16) + 1;
 + status = i2c_read_eeprom(adapter, 0x50, Addr, data, Length);
 + if (!status) {
 + *pLength = EETag[2];
 + if (Length  EETag[2])
 + 

[git:v4l-dvb/for_v3.6] [media] s2255drv: Add MODULE_FIRMWARE statement

2012-07-30 Thread Mauro Carvalho Chehab
This is an automatic generated email to let you know that the following patch 
were queued at the 
http://git.linuxtv.org/media_tree.git tree:

Subject: [media] s2255drv: Add MODULE_FIRMWARE statement
Author:  Tim Gardner tim.gard...@canonical.com
Date:Tue Jul 24 16:52:27 2012 -0300

Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Dean Anderson linux-...@sensoray.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Dan Carpenter dan.carpen...@oracle.com
Cc: Hans de Goede hdego...@redhat.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 drivers/media/video/s2255drv.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

---

http://git.linuxtv.org/media_tree.git?a=commitdiff;h=1bec982dd432a187459d59900a16cd79d5eea7fc

diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index 01c2179..95007dd 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
@@ -2686,3 +2686,4 @@ MODULE_DESCRIPTION(Sensoray 2255 Video for Linux 
driver);
 MODULE_AUTHOR(Dean Anderson (Sensoray Company Inc.));
 MODULE_LICENSE(GPL);
 MODULE_VERSION(S2255_VERSION);
+MODULE_FIRMWARE(FIRMWARE_FILE_NAME);
--
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


[git:v4l-dvb/for_v3.6] [media] lgs8gxx: Declare MODULE_FIRMWARE usage

2012-07-30 Thread Mauro Carvalho Chehab
This is an automatic generated email to let you know that the following patch 
were queued at the 
http://git.linuxtv.org/media_tree.git tree:

Subject: [media] lgs8gxx: Declare MODULE_FIRMWARE usage
Author:  Tim Gardner tim.gard...@canonical.com
Date:Wed Jul 25 12:54:02 2012 -0300

Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 drivers/media/dvb/frontends/lgs8gxx.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

---

http://git.linuxtv.org/media_tree.git?a=commitdiff;h=ccb7c5939cc7185fdecb913f4c7cba94cf82287e

diff --git a/drivers/media/dvb/frontends/lgs8gxx.c 
b/drivers/media/dvb/frontends/lgs8gxx.c
index 568363a..c2ea274 100644
--- a/drivers/media/dvb/frontends/lgs8gxx.c
+++ b/drivers/media/dvb/frontends/lgs8gxx.c
@@ -40,6 +40,8 @@
 static int debug;
 static int fake_signal_str = 1;
 
+#define LGS8GXX_FIRMWARE lgs8g75.fw
+
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).);
 
@@ -592,7 +594,7 @@ static int lgs8g75_init_data(struct lgs8gxx_state *priv)
int rc;
int i;
 
-   rc = request_firmware(fw, lgs8g75.fw, priv-i2c-dev);
+   rc = request_firmware(fw, LGS8GXX_FIRMWARE, priv-i2c-dev);
if (rc)
return rc;
 
@@ -1070,3 +1072,4 @@ EXPORT_SYMBOL(lgs8gxx_attach);
 MODULE_DESCRIPTION(Legend Silicon LGS8913/LGS8GXX DMB-TH demodulator driver);
 MODULE_AUTHOR(David T. L. Wong davidtlw...@gmail.com);
 MODULE_LICENSE(GPL);
+MODULE_FIRMWARE(LGS8GXX_FIRMWARE);
--
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


[git:v4l-dvb/for_v3.6] [media] xc5000: Add MODULE_FIRMWARE statements

2012-07-30 Thread Mauro Carvalho Chehab
This is an automatic generated email to let you know that the following patch 
were queued at the 
http://git.linuxtv.org/media_tree.git tree:

Subject: [media] xc5000: Add MODULE_FIRMWARE statements
Author:  Tim Gardner tim.gard...@canonical.com
Date:Wed Jul 25 09:15:19 2012 -0300

This will make modinfo more useful with regard
to discovering necessary firmware files.

Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Michael Krufky mkru...@kernellabs.com
Cc: Eddi De Pieri e...@depieri.net
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 drivers/media/common/tuners/xc5000.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

---

http://git.linuxtv.org/media_tree.git?a=commitdiff;h=3422f2a6bc0ed9b1fa159a33d94efef08f142570

diff --git a/drivers/media/common/tuners/xc5000.c 
b/drivers/media/common/tuners/xc5000.c
index bac8009..362a8d7 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -210,13 +210,15 @@ struct xc5000_fw_cfg {
u16 size;
 };
 
+#define XC5000A_FIRMWARE dvb-fe-xc5000-1.6.114.fw
 static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
-   .name = dvb-fe-xc5000-1.6.114.fw,
+   .name = XC5000A_FIRMWARE,
.size = 12401,
 };
 
+#define XC5000C_FIRMWARE dvb-fe-xc5000c-41.024.5.fw
 static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
-   .name = dvb-fe-xc5000c-41.024.5.fw,
+   .name = XC5000C_FIRMWARE,
.size = 16497,
 };
 
@@ -1259,3 +1261,5 @@ EXPORT_SYMBOL(xc5000_attach);
 MODULE_AUTHOR(Steven Toth);
 MODULE_DESCRIPTION(Xceive xc5000 silicon tuner driver);
 MODULE_LICENSE(GPL);
+MODULE_FIRMWARE(XC5000A_FIRMWARE);
+MODULE_FIRMWARE(XC5000C_FIRMWARE);
--
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


[git:v4l-dvb/for_v3.6] [media] tlg2300: Declare MODULE_FIRMWARE usage

2012-07-30 Thread Mauro Carvalho Chehab
This is an automatic generated email to let you know that the following patch 
were queued at the 
http://git.linuxtv.org/media_tree.git tree:

Subject: [media] tlg2300: Declare MODULE_FIRMWARE usage
Author:  Tim Gardner tim.gard...@canonical.com
Date:Wed Jul 25 15:41:04 2012 -0300

Cc: Huang Shijie shij...@gmail.com
Cc: Kang Yong kangy...@telegent.com
Cc: Zhang Xiaobing xbzh...@telegent.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
Acked-by: Huang Shijie shij...@gmail.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 drivers/media/video/tlg2300/pd-main.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

---

http://git.linuxtv.org/media_tree.git?a=commitdiff;h=4d98015eef6fa97b0cbba7310041ab75b223524b

diff --git a/drivers/media/video/tlg2300/pd-main.c 
b/drivers/media/video/tlg2300/pd-main.c
index c096b3f..7b1f6eb 100644
--- a/drivers/media/video/tlg2300/pd-main.c
+++ b/drivers/media/video/tlg2300/pd-main.c
@@ -53,7 +53,8 @@ int debug_mode;
 module_param(debug_mode, int, 0644);
 MODULE_PARM_DESC(debug_mode, 0 = disable, 1 = enable, 2 = verbose);
 
-static const char *firmware_name = tlg2300_firmware.bin;
+#define TLG2300_FIRMWARE tlg2300_firmware.bin
+static const char *firmware_name = TLG2300_FIRMWARE;
 static struct usb_driver poseidon_driver;
 static LIST_HEAD(pd_device_list);
 
@@ -532,3 +533,4 @@ MODULE_AUTHOR(Telegent Systems);
 MODULE_DESCRIPTION(For tlg2300-based USB device );
 MODULE_LICENSE(GPL);
 MODULE_VERSION(0.0.2);
+MODULE_FIRMWARE(TLG2300_FIRMWARE);
--
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