Re: Anyone capable of fixing inverted spectrum issue on tt s2-3200?

2009-12-17 Thread Newsy Paper
ok this modification does change something as I have no signal on all dvb-s2 
transponders that don't use inverted spectrum. I'm still looking for a 
transponder that has this inverted spectrum still enabled, so I'll give 
feedback as soon as I find one.

regards

Newspaperman
--- Manu Abraham abraham.m...@gmail.com schrieb am Mi, 16.12.2009:

 Von: Manu Abraham abraham.m...@gmail.com
 Betreff: Re: Anyone capable of fixing inverted spectrum issue on tt s2-3200?
 An: Newsy Paper newspaperman_germ...@yahoo.com
 CC: linux-media@vger.kernel.org
 Datum: Mittwoch, 16. Dezember 2009, 14:10
 On Wed, Dec 16, 2009 at 4:15 PM,
 Newsy Paper
 newspaperman_germ...@yahoo.com
 wrote:
  Hi,
 
  as the problem with the ORF HD transponder on Astra is
 now figured out and ORF switched inversion off again, we
 know know where the bug in the driver is. I don't know if
 the problem also occours on dvb-s(1) transponders but I'll
 try to figure that out.
 
  Is anyone able to fix that dvb-s2 problem? Perhaps it
 would also solve the problem with some transponders on 1°
 west?
 
 
 
 To verify whether an inversion will solve the issue:
 
 Please try changing
 
 line: #1313 .inversion = IQ_SWAP_ON, /* 1 */  to
 IQ_SWAP_OFF
 
 in
 
 http://linuxtv.org/hg/v4l-dvb/file/79fc32bba0a0/linux/drivers/media/dvb/ttpci/budget-ci.c
 
 and check whether that solves your inversion issue. Please
 report your findings.
 
 
 Regards,
 Manu
 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

2009-12-17 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 Hi Mauro,
 
 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the 
 following:
 
 - v4l: vpfe_capture: remove clock and ccdc resource handling
 - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver
 - v4l: vpfe capture: convert dm644x ccdc module to a platform driver
 
 And after these three patches are pulled in, then this arch patch should also 
 be
 merged for git:
 
 http://patchwork.kernel.org/patch/67669/

Hmm... It seems that git bisect will break if I merge first the conversion and 
then
the platform_data patches.

Also, we had some bad merge dependency troubles last time I merged an arch patch
on my tree, as those omap arch header files are highly volatile. I bet that, if 
I
merge the patch #67669 on my tree it will cause conflicts when I send it during
the next merge window (and it is too late for sending those patches to 
linux-next,
wait for a couple days and send upstream before -rc1).

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


Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

2009-12-17 Thread Hans Verkuil

 Hans Verkuil wrote:
 Hi Mauro,

 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for
 the following:

 - v4l: vpfe_capture: remove clock and ccdc resource handling
 - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver
 - v4l: vpfe capture: convert dm644x ccdc module to a platform driver

 And after these three patches are pulled in, then this arch patch should
 also be
 merged for git:

 http://patchwork.kernel.org/patch/67669/

 Hmm... It seems that git bisect will break if I merge first the conversion
 and then
 the platform_data patches.

Murali, what is the correct merge order? I assumed that the order you gave
me was 'safe' (as in, it always compiles after each patch). I did compile
the v4l patches, but I did not check if there was any breakage if I build
the full kernel.

 Also, we had some bad merge dependency troubles last time I merged an arch
 patch
 on my tree, as those omap arch header files are highly volatile. I bet
 that, if I
 merge the patch #67669 on my tree it will cause conflicts when I send it
 during
 the next merge window (and it is too late for sending those patches to
 linux-next,
 wait for a couple days and send upstream before -rc1).

 Cheers,
 Mauro.


So what do you want me or Murali to do? Wait until rc1 is released and
then make sure that the arch patch will apply correctly to what is in rc1?

Regards,

 Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: [PULL] soc-camera and mediabus

2009-12-17 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote:
 On Mon, 14 Dec 2009, Jonathan Cameron wrote:

 
 Having bridge-specific code in a sub-device driver will be a disaster in the
 long run. Well, we've seen what happens when you do it that way.

True.

 As far as I know the only soc-dependency left now is for bus configuration.
 Proposals were made some time ago and we should pick that up again and remove
 that last dependency.

We should really go on that direction. V4L i2c drivers shouldn't depend on
platform_data. I've experienced some very bad time fixing conflicts
and waiting for arch merges in order to try to avoid conflicts related
to platform_data changes that should be reflected into V4L drivers.

Even after migrating to -git, this problem won't solve, since the header
files that holds platform_data are highly volatile: on all kernel versions,
they had several changes, and the platform_data patch made while changing
the V4L code needs to be changed during the next merge window.

Due to that, I don't doubt that some earlier merges had broke git bisect
capabilities on those drivers that rely on the highly volatile platform_data
header files applied on arch tree and a separate patch applied on v4l tree.

It seems that we'll need to have some code that will be responsible to
handle arch/platform_data glue, to be merged in the same subsystem that
holds the *.h files, taking care on the required differences for drivers
that need platform_data to work, and a separate code to handle the V4L
functionalities.

In other words, drivers like soc_camera and omap core should be broken
internally into two separate files (or modules), one with V4L bits and
the other with arch/platform_data glue, where the second one should be
be maintained together with the corresponding arch code.

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


Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

2009-12-17 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 Hans Verkuil wrote:
 Hi Mauro,

 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for
 the following:

 - v4l: vpfe_capture: remove clock and ccdc resource handling
 - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver
 - v4l: vpfe capture: convert dm644x ccdc module to a platform driver

 And after these three patches are pulled in, then this arch patch should
 also be
 merged for git:

 http://patchwork.kernel.org/patch/67669/
 Hmm... It seems that git bisect will break if I merge first the conversion
 and then
 the platform_data patches.
 
 Murali, what is the correct merge order? I assumed that the order you gave
 me was 'safe' (as in, it always compiles after each patch). I did compile
 the v4l patches, but I did not check if there was any breakage if I build
 the full kernel.

To be safe, it needs not only to compile, but also to not break the driver, 
otherwise
bisecting the affected drivers will not work.

 So what do you want me or Murali to do? Wait until rc1 is released and
 then make sure that the arch patch will apply correctly to what is in rc1?

This won't solve, since, between 2.6.33-rc1 and the next open window (2.6.34 
window),
I bet that the *.h file will change enough for the merge to not apply.

I see two ways:

1) (if it is safe to apply the platform_data patch without the v4l changes) send
the patch to the -arch maintainer, as he'll handle the other changes to the same
header file;

2) create a platform_data glue module/file that will handle the 
arch/platform_data
glue for omap drivers and maintain it together with arch. All V4L specific code
should be kept maintained on V4L subsystem.

(2) is better, but will probably require more time to happen, but IMHO, this is 
the
solution to avoid having troubles like that on all merge windows.

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


Cinergy 2400i - Micronas APB 7202A Open Sourced!

2009-12-17 Thread sijones2006
Hi,

I know this has been brought up a number of times on Myth and other 
lists but there is now a change of circumstances.

The PCI-e bridge (MICRONAS APB 7202A) has now an open source driver. 
It is available here git://projects.vdr-developer.org/mediapointer-dvb-
s2.git 
could this now be pulled into the main V4L source? as it has been 
brought upto date with the current DVB tree.

The demodulators MICRONAS DRX 3975D seem to have a driver in the 
current tree.

My only issue is now the 

* Tuner #1: THOMSON DTT 75202A (with RF connector)
* Tuner #2: THOMSON DTT 75207 (with pin RF input)

I can't seem to be able to find a tuner that will work out of the git 
source I have pulled.

both the ngene and modulator modules I have to modprobe in, if i 
reboot they dont get reloaded, am currently running Unbuntu 9.10, any 
help would be appreciated! 

If the source for the PCI-e bridge can be brought into current then it 
would seem a number of cards would be able to work.

I think someone has already tried some work on another card which uses 
this bridge as wel

http://article.gmane.org/gmane.linux.drivers.video-input-
infrastructure/9180/match=ngene


Cheers

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


Re: [PATCH 3/4 v12] TVP7002 driver for DM365

2009-12-17 Thread Alexey Klimov
Hello,

On Thu, Dec 17, 2009 at 12:32 AM,  santiago.nu...@ridgerun.com wrote:
 From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

 This patch provides the implementation of the TVP7002 decoder
 driver for DM365. Implemented using the V4L2 DV presets API.
 Removed shadow register values. Testing shows that the device
 needs not to be powered down and up for correct behaviour.
 Improved readability. Uses helper function for preset information.

 Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 ---
  drivers/media/video/tvp7002.c | 1189 
 +
  1 files changed, 1189 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/tvp7002.c

 diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
 new file mode 100644
 index 000..6ce57b6
 --- /dev/null
 +++ b/drivers/media/video/tvp7002.c
 @@ -0,0 +1,1189 @@
 +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
 + * Digitizer with Horizontal PLL registers
 + *
 + * Copyright (C) 2009 Texas Instruments Inc
 + * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 + *
 + * This code is partially based upon the TVP5150 driver
 + * written by Mauro Carvalho Chehab (mche...@infradead.org),
 + * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
 + * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
 + * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 + */
 +#include linux/delay.h
 +#include linux/i2c.h
 +#include linux/videodev2.h
 +#include media/tvp7002.h
 +#include media/v4l2-device.h
 +#include media/v4l2-chip-ident.h
 +#include media/v4l2-common.h
 +#include tvp7002_reg.h
 +
 +MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
 +MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
 +MODULE_LICENSE(GPL);
 +
 +/* Module Name */
 +#define TVP7002_MODULE_NAME    tvp7002
 +
 +/* I2C retry attempts */
 +#define I2C_RETRY_COUNT                (5)
 +
 +/* End of registers */
 +#define TVP7002_EOR            0x5c
 +
 +/* Read write definition for registers */
 +#define TVP7002_READ           0
 +#define TVP7002_WRITE          1
 +#define TVP7002_RESERVED       2
 +
 +/* Interlaced vs progressive mask and shift */
 +#define TVP7002_IP_SHIFT       5
 +#define TVP7002_INPR_MASK      (0x01  TVP7002_IP_SHIFT)
 +
 +/* Shift for CPL and LPF registers */
 +#define TVP7002_CL_SHIFT       8
 +#define TVP7002_CL_MASK                0x0f
 +
 +/* Debug functions */
 +static int debug;
 +module_param(debug, bool, 0644);
 +MODULE_PARM_DESC(debug, Debug level (0-2));
 +
 +/* Structure for register values */
 +struct i2c_reg_value {
 +       u8 reg;
 +       u8 value;
 +       u8 type;
 +};
 +
 +/*
 + * Register default values (according to tvp7002 datasheet)
 + * In the case of read-only registers, the value (0xff) is
 + * never written. R/W functionality is controlled by the
 + * writable bit in the register struct definition.
 + */
 +static const struct i2c_reg_value tvp7002_init_default[] = {
 +       { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
 +       { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
 +       { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
 +       { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
 +       { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
 +       { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
 +       { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
 +       { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
 +       { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
 +       { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
 +       { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
 +       { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
 +       { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
 +       { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
 +       { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
 +       { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
 +       { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
 +       { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
 +       { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
 +       { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
 +       { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
 +       { 

Re: Cinergy 2400i - Micronas APB 7202A Open Sourced!

2009-12-17 Thread Oliver Endriss
Hi,

sijones2...@o2.co.uk wrote:
 I know this has been brought up a number of times on Myth and other 
 lists but there is now a change of circumstances.
 
 The PCI-e bridge (MICRONAS APB 7202A) has now an open source driver. 
 It is available here git://projects.vdr-developer.org/mediapointer-dvb-
 s2.git 
 could this now be pulled into the main V4L source? as it has been 
 brought upto date with the current DVB tree.

The driver cannot be pulled in 'as is' for various reasons, but we are
currently preparing the driver to make it ready for inclusion into the
master HG repository/kernel.

Please stand by.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
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: Cinergy 2400i - Micronas APB 7202A Open Sourced!

2009-12-17 Thread sijones2006
 
 The PCI-e bridge (MICRONAS APB 7202A) has now an open source 
driver. 
 It is available here git://projects.vdr-developer.org/mediapointer-
dvb-
 s2.git 
 could this now be pulled into the main V4L source? as it has been 
 brought upto date with the current DVB tree.

The driver cannot be pulled in 'as is' for various reasons, but we 
are
currently preparing the driver to make it ready for inclusion into 
the
master HG repository/kernel.

Is there a repository that I can use to build / test this? and is the 
tuner supported as well??
--
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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c

2009-12-17 Thread Alan Stern
On Wed, 16 Dec 2009, Sean wrote:

 Thanks, that patch definitely traps the bug. Unfortunately there are so 
 many debug messages that the capture-example.c times out trying to 
 connect to the webcam. The debug messages slow down the process enough 
 to make that happen. But if I modify your patch and take out the extra 
 debug messages, it works well. The modified patch is below.

The patch doesn't fix anything.  The point was to gather enough 
information to figure out what's going wrong.  Without the debug 
messages, there's no information.

Perhaps things will slow down less if you change the new ohci_info() 
calls in the patch to ohci_dbg().  Or perhaps you can increase the 
timeout values in capture-example.c.

You should also apply this patch (be sure to enable CONFIG_USB_DEBUG):

http://marc.info/?l=linux-usbm=126056642931083w=2

It probably won't make any difference, but including it anyway is
worthwhile.

Alan Stern

--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

2009-12-17 Thread Karicheri, Muralidharan
Mauro,

Kevin is going to merge the arch part #67669 as we did last time.
Please merge only the v4l2 part. I have copied Kevin in this email.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Thursday, December 17, 2009 6:18 AM
To: Hans Verkuil
Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

Hans Verkuil wrote:
 Hi Mauro,

 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for
the following:

 - v4l: vpfe_capture: remove clock and ccdc resource handling
 - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver
 - v4l: vpfe capture: convert dm644x ccdc module to a platform driver

 And after these three patches are pulled in, then this arch patch should
also be
 merged for git:

 http://patchwork.kernel.org/patch/67669/

Hmm... It seems that git bisect will break if I merge first the conversion
and then
the platform_data patches.

Also, we had some bad merge dependency troubles last time I merged an arch
patch
on my tree, as those omap arch header files are highly volatile. I bet that,
if I
merge the patch #67669 on my tree it will cause conflicts when I send it
during
the next merge window (and it is too late for sending those patches to
linux-next,
wait for a couple days and send upstream before -rc1).

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


RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

2009-12-17 Thread Karicheri, Muralidharan
Hans  Mauro,

I have already replied to Mauro's email.

This is what we had followed last time for vpfe capture.

Mauro will merge the v4l2 part and Kevin will merge the arch part.
These needs be done in sync so that it will compile fine in the upstream.

Let me know if this cannot be done this time.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Thursday, December 17, 2009 6:30 AM
To: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci


 Hans Verkuil wrote:
 Hi Mauro,

 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for
 the following:

 - v4l: vpfe_capture: remove clock and ccdc resource handling
 - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver
 - v4l: vpfe capture: convert dm644x ccdc module to a platform driver

 And after these three patches are pulled in, then this arch patch should
 also be
 merged for git:

 http://patchwork.kernel.org/patch/67669/

 Hmm... It seems that git bisect will break if I merge first the
conversion
 and then
 the platform_data patches.

Murali, what is the correct merge order? I assumed that the order you gave
me was 'safe' (as in, it always compiles after each patch). I did compile
the v4l patches, but I did not check if there was any breakage if I build
the full kernel.

 Also, we had some bad merge dependency troubles last time I merged an
arch
 patch
 on my tree, as those omap arch header files are highly volatile. I bet
 that, if I
 merge the patch #67669 on my tree it will cause conflicts when I send it
 during
 the next merge window (and it is too late for sending those patches to
 linux-next,
 wait for a couple days and send upstream before -rc1).

 Cheers,
 Mauro.


So what do you want me or Murali to do? Wait until rc1 is released and
then make sure that the arch patch will apply correctly to what is in rc1?

Regards,

 Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: linux-next: Tree for December 17 (media/dvb)

2009-12-17 Thread Randy Dunlap
On Thu, 17 Dec 2009 16:58:40 +1100 Stephen Rothwell wrote:

 Hi all,
 
 My usual call for calm: please do not put stuff destined for 2.6.34 into
 linux-next trees until after 2.6.33-rc1.
 
 Changes since 20091216:


(repeating:)

drivers/media/dvb/frontends/dib8000.h:104: error: expected expression before 
'}' token
drivers/media/dvb/frontends/dib8000.h:104: warning: left-hand operand of comma 
expression has no effect

return CT_SHUTDOWN,


s/,/;/ and fix indentation.

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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-12-17 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Thu Dec 17 19:00:05 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13833:2c1341c0c20b
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.32-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: ERRORS
linux-2.6.28-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30-i686: ERRORS
linux-2.6.31-i686: ERRORS
linux-2.6.32-i686: ERRORS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-mips: OK
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.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: Cinergy 2400i - Micronas APB 7202A Open Sourced!

2009-12-17 Thread sijones2006

sijones2...@o2.co.uk writes:
 

 The PCI-e bridge (MICRONAS APB 7202A) has now an open source 
 driver. 

 It is available here git://projects.vdr-developer.org/mediapointer-
 dvb-

 s2.git 

 could this now be pulled into the main V4L source? as it has been 

 brought upto date with the current DVB tree.
 

The driver cannot be pulled in 'as is' for various reasons, but we 
 are

currently preparing the driver to make it ready for inclusion into 
 the

master HG repository/kernel.
 
 Is there a repository that I can use to build / test this? and is 
the 
 tuner supported as well??

I am not sure about the git repo but the original release included
drivers for the cards on the market (dual DVBS2 by DigitalDevices, 
Terratec Cinergy and an ATSC card) and all prototype cards.
Since most of the driver was written in 2005 it is a little 
behind regarding kernel API changes and available in-kernel drivers 
for 
tuners and demods. But you should be able to get hints from it
to adapt it to the current kernel/DVB repo. 


Thanks for your reply, when I looked through the original source code 
I can't see a driver for the tuner THOMSON DTT 75202A, is included in 
the code but named something else?

When I load the ngene module, should it say anything more than the 
copyright notice in the kernel logs?
--
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 - v1 4/6] V4L - vpfe_capture bug fix and enhancements

2009-12-17 Thread Nori, Sekhar
On Wed, Dec 16, 2009 at 13:11:57, Hans Verkuil wrote:
 On Wednesday 16 December 2009 00:37:52 Karicheri, Muralidharan wrote:
  Hans,
 
  I remember there was a comment against an earlier patch that asks
  for combining such statements since it makes the function appear
  as big. Not sure who had made that comment. That is the reason you
  find code like this in this patch. It was initially done with multiple
  OR statements to construct the value to be written to the register as you 
  stated below as
 
  val = bc-horz.win_count_calc 
 ISIF_HORZ_BC_WIN_COUNT_MASK;
  val |= !!bc-horz.base_win_sel_calc 
 ISIF_HORZ_BC_WIN_SEL_SHIFT;
 
  I have checked few other drivers such as bt819.c ir-kbd-i2c.c,
  mt9m111.c etc, where similar statements are found, but they have used 
  hardcoded values masks which makes it appears less complex. But I
  like to reduce magic numbers as much possible in the code.

 Personally I have mixed feelings about the use for symbolic names for things
 like this. The problem is that they do not help me understanding the code.
 The names tend to be long, leading to these broken up lines, and if I want
 to know how the bits are distributed in the value I continuously have to
 do the look up in the header containing these defines.

 Frankly, I have a similar problem with using symbolic names for registers.
 Every time I need to look up a register in the datasheet I first need to
 look up the register number the register name maps to. All datasheets seem
 to be organized around the register addresses and there rarely is a datasheet
 that has an index of symbolic names.

 Using hard-coded numbers together with a well written comment tends to be much
 more readable in my opinion. I don't really think there is anything magic 
 about
 these numbers: these are exactly the numbers that I need to know whenever I
 have to deal with the datasheet. Having to go through a layer of obfuscation
 is just plain irritating to me.

 However, I seem to be a minority when it comes to this and I've given up
 arguing for this...

 Note that all this assumes that the datasheet is publicly available. If it
 is a reversed engineered driver or based on NDA datasheets only, then the
 symbolic names may be all there is to make you understand what is going on.


[...]


 That seems overkill. I actually think it can be improved a lot by visually
 grouping the lines:

  val = (bc-horz.win_count_calc 
  ISIF_HORZ_BC_WIN_COUNT_MASK) |
((!!bc-horz.base_win_sel_calc) 
  ISIF_HORZ_BC_WIN_SEL_SHIFT) |
((!!bc-horz.clamp_pix_limit) 
  ISIF_HORZ_BC_PIX_LIMIT_SHIFT) |
((bc-horz.win_h_sz_calc 
  ISIF_HORZ_BC_WIN_H_SIZE_MASK) 
  ISIF_HORZ_BC_WIN_H_SIZE_SHIFT) |
((bc-horz.win_v_sz_calc 
  ISIF_HORZ_BC_WIN_V_SIZE_MASK) 
  ISIF_HORZ_BC_WIN_V_SIZE_SHIFT);

 Now I can at least see the various values that are ORed.


I liked this piece of code from drivers/mtd/nand/s3c2410.c. Serves as
a good template to do this sort of thing.

#define S3C2410_NFCONF_TACLS(x)((x)8)
#define S3C2410_NFCONF_TWRPH0(x)   ((x)4)
#define S3C2410_NFCONF_TWRPH1(x)   ((x)0)

[Okay, spaces around '', please :)]

[...]

if (plat != NULL) {
tacls = s3c_nand_calc_rate(plat-tacls, clkrate, tacls_max);
twrph0 = s3c_nand_calc_rate(plat-twrph0, clkrate, 8);
twrph1 = s3c_nand_calc_rate(plat-twrph1, clkrate, 8);
}

[...]

mask = (S3C2410_NFCONF_TACLS(3) |
S3C2410_NFCONF_TWRPH0(7) |
S3C2410_NFCONF_TWRPH1(7));
set = S3C2410_NFCONF_EN;
set |= S3C2410_NFCONF_TACLS(tacls - 1);
set |= S3C2410_NFCONF_TWRPH0(twrph0 - 1);
set |= S3C2410_NFCONF_TWRPH1(twrph1 - 1);

[...]

cfg = readl(info-regs + S3C2410_NFCONF);
cfg = ~mask;
cfg |= set;
writel(cfg, info-regs + S3C2410_NFCONF);

And Murali said:

 Huh? That does not explain why apparently bc-horz.win_h_sz_calc can be
 larger
 than ISIF_HORZ_BC_WIN_H_SIZE_MASK.
 because the values come from the user and since we can't use the enum
 for the types, I have to make sure the value is within range. Other way
 to do is to check the value in the validate() function. I am inclined to
 do the validation so that the  statements with masks can be removed while 
 setting it in
 the register.

Agree fully here. Either a separate validate function or
an if check before using the values. Results with masking
or without masking are both unpredictable.

Thanks,
Sekhar

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