date:20110119

Em 19-01-2011 05:39, Hans Verkuil escreveu:
 Hi Mauro,
 
 I saw that 2.6.38-rc1 was released. I also noticed that not all the patches
 that are in the for_2.6.38-rc1 branch are in 2.6.38-rc1.

Yes. Unfortunately, when I was sending the pull request yesterday, I noticed
an issue on my linux next tree, and I had to abort its send. After that, Linus
released -rc1, before I have time to fix it.

People should really send me patches for the next window before the start of the
merge window, as doing it during the merge window makes my work harder and may
cause troubles like that. 

The net result is that most patches were submitted in time and were applied 
upstream.
Of course, there are usual fix patches sent during the merge window, that will 
be sent
upstream anyway during the rc period.

There are two patch series with new stuff submitted in time and merged on my 
tree that didn't reach upstream:
- vb2/s5p-fimc - they required me more time to review - I also spent 3 
days testing it;
- ngene - there were a pending API discussion - I waited for a while to 
see if
  there were some solution, before deciding to merge and move the 
problematic
  code to staging.

So, I'll need to dig into the pending patches, in order to send the ones that
are acceptable after the end of the merge window, and letting the other patches
for .39. I'll likely try to send the two above and the dib0700 patches on a 
separate
pull request, but this pull request might be rejected.

 We want to rename video_device to v4l2_devnode. So let me know when I can
 finalize my patches and, most importantly, against which branch.

It is too late for that. As I said you, the better time for doing that is during
the merge window. Linus said me that he don't want to make life easier for 
function
rename. So, he won't be accepting such patch after the merge window.

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: OMAP3 ISP and tvp5151 driver.

2011-01-19 Thread Enric Balletbò i Serra

Hi Laurent,

2011/1/18 Laurent Pinchart laurent.pinch...@ideasonboard.com:
 Hi Enric,

 On Tuesday 18 January 2011 10:20:43 Enric Balletbò i Serra wrote:

 Now seems yavta is blocked dequeuing a buffer ( VIDIOC_DQBUF ), with
 strace I get

 $ strace ./yavta -f SGRBG10 -s 720x525 -n 1 --capture=1 -F /dev/video2

 mmap2(NULL, 756000, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x4011f000
 write(1, Buffer 0 mapped at address 0x401..., 39Buffer 0 mapped at
 address 0x4011f000.
 ) = 39
 ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0xbede36cc) = 0
 ioctl(3, VIDIOC_STREAMON, 0xbede365c)   = 0
 gettimeofday({10879, 920196}, NULL)     = 0
 ioctl(3, VIDIOC_DQBUF

 and the code where stops is here

 ispqueue.c
 913   buf = list_first_entry(queue-queue, struct isp_video_buffer, stream);
 914   ret = isp_video_buffer_wait(buf, nonblocking);

 Any idea ?

 My guess is that the CCDC doesn't receive the amount of lines it expects.

 The CCDC generates an interrupt at 2/3 of the image and another one at the
 beginning of the last line. Start by checking if the ISP generates any
 interrupt to the host with cat /proc/interrupts. If it doesn't, then the CCDC
 receives less than 2/3 of the expected number of lines. If it does, it
 probably receives between 2/3 and 3/3. You can add printk statements in
 ispccdc_vd0_isr() and ispccdc_vd1_isr() to confirm this.

Looks like my problem is that  ispccdc_vd0_isr() and ispccdc_vd1_isr()
are never called, adding printk in these functions I see only a lots
of ispccdc_hs_vs_isr(), Seems the CCDC receives less than 2/3 of
expected number lines. Using an oscilloscope I see VS and HS data
lines of the camera interface, so seems physical interface is working.

I guess I'm missing something to configure in tvp5150 driver but I
don't know. Any help ?

Here is a CCDC Register dump

[ 6211.404205] *** ccdc_configure : height 525
[ 6211.404205] *** ccdc_configure : width 720
[ 6211.404205] omap3isp omap3isp: -CCDC Register dump-
[ 6211.411315] omap3isp omap3isp: ###CCDC PCR=0x0001
[ 6211.416381] omap3isp omap3isp: ###CCDC SYN_MODE=0x0001
[ 6211.421905] omap3isp omap3isp: ###CCDC HD_VD_WID=0x
[ 6211.427520] omap3isp omap3isp: ###CCDC PIX_LINES=0x
[ 6211.433135] omap3isp omap3isp: ###CCDC HORZ_INFO=0x028f
[ 6211.438751] omap3isp omap3isp: ###CCDC VERT_START=0x
[ 6211.58] omap3isp omap3isp: ###CCDC VERT_LINES=0x
[ 6211.450164] omap3isp omap3isp: ###CCDC CULLING=0x
[ 6211.455566] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x
[ 6211.461181] omap3isp omap3isp: ###CCDC SDOFST=0x
[ 6211.466552] omap3isp omap3isp: ###CCDC SDR_ADDR=0x
[ 6211.472076] omap3isp omap3isp: ###CCDC CLAMP=0x
[ 6211.477325] omap3isp omap3isp: ###CCDC DCSUB=0x
[ 6211.482604] omap3isp omap3isp: ###CCDC COLPTN=0x
[ 6211.487945] omap3isp omap3isp: ###CCDC BLKCMP=0x
[ 6211.493286] omap3isp omap3isp: ###CCDC FPC=0x8000
[ 6211.498382] omap3isp omap3isp: ###CCDC FPC_ADDR=0x
[ 6211.503906] omap3isp omap3isp: ###CCDC VDINT=0x002a
[ 6211.509155] omap3isp omap3isp: ###CCDC ALAW=0x
[ 6211.514343] omap3isp omap3isp: ###CCDC REC656IF=0x0002
[ 6211.519866] omap3isp omap3isp: ###CCDC CFG=0xb210
[ 6211.524932] omap3isp omap3isp: ###CCDC FMTCFG=0x
[ 6211.530303] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0
[ 6211.535827] omap3isp omap3isp: ###CCDC FMT_VERT=0x0200
[ 6211.541351] omap3isp omap3isp: ###CCDC PRGEVEN0=0x00013210
[ 6211.546875] omap3isp omap3isp: ###CCDC PRGEVEN1=0x
[ 6211.552398] omap3isp omap3isp: ###CCDC PRGODD0=0x
[ 6211.557830] omap3isp omap3isp: ###CCDC PRGODD1=0x
[ 6211.563262] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00
[ 6211.568603] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x
[ 6211.574310] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x
[ 6211.580108] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x
[ 6211.586151] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x
[ 6211.592376] omap3isp omap3isp: 

Thanks in advance,
Enric


 --
 Regards,

 Laurent Pinchart

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

Re: OMAP3 ISP and tvp5151 driver.

2011-01-19 Thread Laurent Pinchart

Hi Enric,

On Wednesday 19 January 2011 12:05:54 Enric Balletbò i Serra wrote:
 2011/1/18 Laurent Pinchart laurent.pinch...@ideasonboard.com:
  On Tuesday 18 January 2011 10:20:43 Enric Balletbò i Serra wrote:
  Now seems yavta is blocked dequeuing a buffer ( VIDIOC_DQBUF ), with
  strace I get
  
  $ strace ./yavta -f SGRBG10 -s 720x525 -n 1 --capture=1 -F /dev/video2
  
  mmap2(NULL, 756000, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x4011f000
  write(1, Buffer 0 mapped at address 0x401..., 39Buffer 0 mapped at
  address 0x4011f000.
  ) = 39
  ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0xbede36cc) = 0
  ioctl(3, VIDIOC_STREAMON, 0xbede365c)   = 0
  gettimeofday({10879, 920196}, NULL) = 0
  ioctl(3, VIDIOC_DQBUF
  
  and the code where stops is here
  
  ispqueue.c
  913   buf = list_first_entry(queue-queue, struct isp_video_buffer,
  stream); 914   ret = isp_video_buffer_wait(buf, nonblocking);
  
  Any idea ?
  
  My guess is that the CCDC doesn't receive the amount of lines it expects.
  
  The CCDC generates an interrupt at 2/3 of the image and another one at
  the beginning of the last line. Start by checking if the ISP generates
  any interrupt to the host with cat /proc/interrupts. If it doesn't, then
  the CCDC receives less than 2/3 of the expected number of lines. If it
  does, it probably receives between 2/3 and 3/3. You can add printk
  statements in ispccdc_vd0_isr() and ispccdc_vd1_isr() to confirm this.
 
 Looks like my problem is that  ispccdc_vd0_isr() and ispccdc_vd1_isr()
 are never called, adding printk in these functions I see only a lots
 of ispccdc_hs_vs_isr(), Seems the CCDC receives less than 2/3 of
 expected number lines. Using an oscilloscope I see VS and HS data
 lines of the camera interface, so seems physical interface is working.
 
 I guess I'm missing something to configure in tvp5150 driver but I
 don't know. Any help ?

Try to hack the ISP driver to generate the VD1 interrupt much earlier (after a 
couple of lines only). If you get it, then modify the number of lines to see 
how many lines the CCDC receives. This should hopefully give you a hint.

-- 
Regards,

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

Re: video_device - v4l2_devnode rename

Em 19-01-2011 05:39, Hans Verkuil escreveu:
 Hi Mauro,
 
 We want to rename video_device to v4l2_devnode. So let me know when I can
 finalize my patches and, most importantly, against which branch.
 
 My current tree:
 
 http://git.linuxtv.org/hverkuil/media_tree.git?a=shortlog;h=refs/heads/devnode2
 
 tracks for_2.6.38-rc1 and should apply cleanly at the moment.

Even not being able to handle it for .38, I did a look on the proposed
changes. I'm not convinced about those renaming stuff.

By looking on other subsystems, it seems to me that video_device_register()
is a better name than any other name. Btw, by far, the use of _node for the
device registration on Linux kernel is not usual at all:

$ git grep -e _register  --and -e ( --and -e node include |grep -v 
of_mdiobus_register(
include/linux/compaction.h:extern int compaction_register_node(struct node 
*node);
include/linux/compaction.h:static inline int compaction_register_node(struct 
node *node)
include/linux/swap.h:extern int scan_unevictable_register_node(struct node 
*node);
include/linux/swap.h:static inline int scan_unevictable_register_node(struct 
node *node)

There are only 2 functions using it. On those, the node at the function 
register name is due to struct node, and they likely make sense.

A seek for *register*device or *device*register patterns show a lot:

$ git grep -e _register_device  --and -e (  include|wc -l
28

$ git grep -e _device_register  --and -e (  include|wc -l
32

Basically, what I'm trying to say is that, on all subsystems, the function that 
creates
the devices is called *register*device or *device*register.

Why should we adopt anything different than the kernel convention for V4L2?

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: [GIT PATCHES FOR 2.6.38] Compile error fix

Em 18-01-2011 23:41, Oliver Endriss escreveu:
 On Tuesday 18 January 2011 21:03:49 Hans Verkuil wrote:
 Hi Mauro,

 That beautiful 'OK' from the daily build disappeared again. This should bring
 it back :-)

 Regards,

  Hans

 The following changes since commit fd4564a8c4f23b5ea6526180898ca2aedda2444e:
   Jarod Wilson (1):
 [media] staging/lirc: fix mem leaks and ptr err usage

 are available in the git repository at:

   ssh://linuxtv.org/git/hverkuil/media_tree.git cxd2099
 
 I've already posted that fix here:
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg27186.html
 https://patchwork.kernel.org/patch/485781/

Hi Oliver,

Thanks for the patch. I noticed that problem late night when preparing my 
linux-next tree,
and added the same fix you did there:

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commit;h=9fca5943233de717b3edcd4a84a51d93e3eae302

Hans/Oliver,

I didn't backport it yet to the main tree. I'll be doing it today.

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] request for 2.6.38-rc1

2011-01-19 Thread Patrick Boettcher

Hi Mauro,

On Sun, 16 Jan 2011, Mauro Carvalho Chehab wrote:

Em 14-01-2011 12:51, Patrick Boettcher escreveu:

Hi Mauro,

if it is not too late, here is a pull request for some new devices from DiBcom.
It would be nice to have it in 2.6.38-rc1.

Pull from

git://linuxtv.org/pb/media_tree.git staging/for_2.6.38-rc1.dibcom

for

DiB: Codingstype updates

Not sure if this is by purpose, but you're changing all
msleep(10) into msleep(20). This sounds very weird for a
CodingStyle fix:

- msleep(10);
+ msleep(20);

I was as surprised as you when I saw that changed, but in fact it is a
checkpatch-fix: it seems that checkpatch is warning about msleep or less
than 20ms.

Maybe it is not the right fix to put them to msleep(20), but I think this
is better than to do udelay(1).

What do you think?

+ if (request_firmware(state-frontend_firmware, dib9090.fw,
adap-dev-udev-dev)) {

Where's dib9090.fw firmware is available? The better is to submit a patch to
linux-firmware
with the firmware binary, with some license that allows end-users to use it
with your device
and distros/distro partners to re-distribute it. While here, please add also
the other
dibcom firmwares.

The dib0700-firmware is already available through a license. The
dib9090-firmware will come later. It'll take a moment before everything is
ready.

Vendors are free to use their own legal text for it. There are several examples
for it
at:

http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob_plain;f=WHENCE;hb=HEAD

Btw, there are two alignment errors (one at dib7000p, for some cases, aligned
with 4 chars),
and another at dib8000, where all statements after an if are aligned with 3
tabs plus one space.
I'm fixing those issues, c/c you at the fix patches.

Nice, thank you.

best regards,
--

Patrick
--
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: video_device - v4l2_devnode rename

2011-01-19 Thread Hans Verkuil

 Em 19-01-2011 05:39, Hans Verkuil escreveu:
 Hi Mauro,

 I saw that 2.6.38-rc1 was released. I also noticed that not all the
 patches
 that are in the for_2.6.38-rc1 branch are in 2.6.38-rc1.

 Yes. Unfortunately, when I was sending the pull request yesterday, I
 noticed
 an issue on my linux next tree, and I had to abort its send. After that,
 Linus
 released -rc1, before I have time to fix it.

 People should really send me patches for the next window before the start
 of the
 merge window, as doing it during the merge window makes my work harder and
 may
 cause troubles like that.

 The net result is that most patches were submitted in time and were
 applied upstream.
 Of course, there are usual fix patches sent during the merge window, that
 will be sent
 upstream anyway during the rc period.

Speaking of that, my prio patches and the dsbr100 patches (with the new
v4l2_device release callback) can be moved to 2.6.39. If they can be
merged fairly early on, then I can build on those.

 There are two patch series with new stuff submitted in time and merged on
 my
 tree that didn't reach upstream:
   - vb2/s5p-fimc - they required me more time to review - I also spent 3
 days testing it;
   - ngene - there were a pending API discussion - I waited for a while to
 see if
 there were some solution, before deciding to merge and move the
 problematic
 code to staging.

 So, I'll need to dig into the pending patches, in order to send the ones
 that
 are acceptable after the end of the merge window, and letting the other
 patches
 for .39. I'll likely try to send the two above and the dib0700 patches on
 a separate
 pull request, but this pull request might be rejected.

 We want to rename video_device to v4l2_devnode. So let me know when I
 can
 finalize my patches and, most importantly, against which branch.

 It is too late for that. As I said you, the better time for doing that is
 during
 the merge window. Linus said me that he don't want to make life easier for
 function
 rename. So, he won't be accepting such patch after the merge window.

You were going to tell me when you had finished merging so that I wouldn't
aim at a moving target. This is very annoying.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

--
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: video_device - v4l2_devnode rename

2011-01-19 Thread Hans Verkuil

 Em 19-01-2011 05:39, Hans Verkuil escreveu:
 Hi Mauro,

 We want to rename video_device to v4l2_devnode. So let me know when I
 can
 finalize my patches and, most importantly, against which branch.

 My current tree:

 http://git.linuxtv.org/hverkuil/media_tree.git?a=shortlog;h=refs/heads/devnode2

 tracks for_2.6.38-rc1 and should apply cleanly at the moment.

 Even not being able to handle it for .38, I did a look on the proposed
 changes. I'm not convinced about those renaming stuff.

 By looking on other subsystems, it seems to me that
 video_device_register()
 is a better name than any other name. Btw, by far, the use of _node for
 the
 device registration on Linux kernel is not usual at all:

 $ git grep -e _register  --and -e ( --and -e node include |grep -v
 of_mdiobus_register(
 include/linux/compaction.h:extern int compaction_register_node(struct node
 *node);
 include/linux/compaction.h:static inline int
 compaction_register_node(struct node *node)
 include/linux/swap.h:extern int scan_unevictable_register_node(struct node
 *node);
 include/linux/swap.h:static inline int
 scan_unevictable_register_node(struct node *node)

 There are only 2 functions using it. On those, the node at the function
 register name is due to struct node, and they likely make sense.

 A seek for *register*device or *device*register patterns show a lot:

 $ git grep -e _register_device  --and -e (  include|wc -l
 28

 $ git grep -e _device_register  --and -e (  include|wc -l
 32

 Basically, what I'm trying to say is that, on all subsystems, the function
 that creates
 the devices is called *register*device or *device*register.

 Why should we adopt anything different than the kernel convention for
 V4L2?

I'm sure we went through this before.

1) the name originates from the time that drivers had only one video node.
It makes little sense anymore when drivers can create many video, radio,
vbi and later v4l-subdev nodes. The key thing is that this driver
registers a V4L2 node.

2) struct v4l2_device and struct video_device look too similar. While
v4l2_device represents the whole V4L2 hardware, the video_device
represents the video/radio/vbi/... device node only.

3) (less important) all types/functions within the v4l2 framework now have
the v4l2_ prefix, except this one. Aligning this will make everything more
consistent and recognizable.

We're not like most other subsystems where often just a single device node
is registered. We have much more complex hardware. So I think that
'v4l2_devnode' much more clearly identifies what it represents than
'video_device'.

Regards,

  Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

--
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: video_device - v4l2_devnode rename

Em 19-01-2011 09:53, Hans Verkuil escreveu:
 Em 19-01-2011 05:39, Hans Verkuil escreveu:
 Hi Mauro,

 I saw that 2.6.38-rc1 was released. I also noticed that not all the
 patches
 that are in the for_2.6.38-rc1 branch are in 2.6.38-rc1.

 Yes. Unfortunately, when I was sending the pull request yesterday, I
 noticed
 an issue on my linux next tree, and I had to abort its send. After that,
 Linus
 released -rc1, before I have time to fix it.

 People should really send me patches for the next window before the start
 of the
 merge window, as doing it during the merge window makes my work harder and
 may
 cause troubles like that.

 The net result is that most patches were submitted in time and were
 applied upstream.
 Of course, there are usual fix patches sent during the merge window, that
 will be sent
 upstream anyway during the rc period.
 
 Speaking of that, my prio patches and the dsbr100 patches (with the new
 v4l2_device release callback) can be moved to 2.6.39. If they can be
 merged fairly early on, then I can build on those.
 
 There are two patch series with new stuff submitted in time and merged on
 my
 tree that didn't reach upstream:
  - vb2/s5p-fimc - they required me more time to review - I also spent 3
 days testing it;
  - ngene - there were a pending API discussion - I waited for a while to
 see if
there were some solution, before deciding to merge and move the
 problematic
code to staging.

 So, I'll need to dig into the pending patches, in order to send the ones
 that
 are acceptable after the end of the merge window, and letting the other
 patches
 for .39. I'll likely try to send the two above and the dib0700 patches on
 a separate
 pull request, but this pull request might be rejected.

 We want to rename video_device to v4l2_devnode. So let me know when I
 can
 finalize my patches and, most importantly, against which branch.

 It is too late for that. As I said you, the better time for doing that is
 during
 the merge window. Linus said me that he don't want to make life easier for
 function
 rename. So, he won't be accepting such patch after the merge window.
 
 You were going to tell me when you had finished merging so that I wouldn't
 aim at a moving target. This is very annoying.

The vb2 merge took a longer time than I expected. Sorry for that.

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: PROBLEM: kernel BUG at drivers/media/video/em28xx/em28xx-video.c:891

2011-01-19 Thread Rune Saetre


Hi

Yes. I will try it out and post a message as soon as I have some 
experience with it.


Regards
Rune

--
We are proud to present our new web-pages at www.aptomar.com
Do not miss our video-window to the world; aptotube

Rune Sætre rune.sae...@aptomar.com
aptomar as

Tel.   (+47) 40 00 34 03
Mob.   (+47) 93 43 42 85
Fax    (+47) 73 51 00 84

www.aptomar.com


On Wed, 19 Jan 2011, Patrik Jakobsson wrote:


On 01/18/2011 05:30 PM, Hans Verkuil wrote:

On Tuesday, January 18, 2011 17:14:03 Patrik Jakobsson wrote:

Hello Rune

I'm trying to learn more about the linux kernel so I figured helping
with bugs is a good way to get started.

On 01/18/2011 02:20 AM, Rune Saetre wrote:

Hi

The crash is not as consistent as I first believed. I have managed to
stop and start capturing several (but not many) times without the
driver crashing now.


To me it seems that the resource locking (functions res_get, res_check,
res_locked and res_free) is subject to race condition.

I looked at older versions of the code and found that there used to be
locks around some of these pieces. It was removed in commit:

0499a5aa777f8e56e46df362f0bb9d9d116186f9 - V4L/DVB: em28xx: remove BKL

Other V4L drivers use pretty much the same code (res_get, res_free,
etc.) for resource locking but still have the mutex_lock/unlock around
it. Does anyone know why this was removed?

Because now the video4linux core does the locking.

Anyway, I'm pretty sure this is the bug that was fixed here:

http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09413.html

This fix will be in 2.6.38.

The change in the locking mechanism had nothing to do this particular bug.
It was just incorrect administration of resources.

Regards,

Hans

Thanks for the explanation. I see now how the V4L core locks around the 
ioctls. The member unlocked_ioctl of struct v4l2_file_operations confused me 
a little. Maybe serialized_ioctl would be a better name? Not a big issue 
though.


Hopefully the patch fixes your problem Rune.

Thanks
Patrik Jakobsson


Thanks
Patrik Jakobsson

The trace logs also differ slightly. Here is the last one:

Jan 18 02:12:08 mate kernel: [  117.219326] [ cut here
]
Jan 18 02:12:08 mate kernel: [  117.219412] kernel BUG at
drivers/media/video/em28xx/em28xx-video.c:891!
Jan 18 02:12:08 mate kernel: [  117.219507] invalid opcode:  [#1]
PREEMPT SMP Jan 18 02:12:08 mate kernel: [  117.219597] last sysfs
file: /sys/devices/virtual/block/dm-8/stat
Jan 18 02:12:08 mate kernel: [  117.219681] CPU 1 Jan 18 02:12:08 mate
kernel: [  117.219714] Modules linked in: acpi_cpufreq mperf
cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative
ppdev lp nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs binfmt_misc
fuse dummy bridge stp ext2 mbcache coretemp kvm_intel kvm loop
firewire_sbp2 tuner snd_hda_codec_realtek arc4 snd_hda_intel
snd_usb_audio snd_hda_codec ecb snd_seq_dummy snd_pcm_oss
snd_mixer_oss saa7115 snd_pcm ir_lirc_codec lirc_dev ir_sony_decoder
snd_hwdep snd_usbmidi_lib em28xx ir_jvc_decoder ir_rc6_decoder
snd_seq_oss snd_seq_midi snd_rawmidi r8169 ir_rc5_decoder mii
ir_nec_decoder snd_seq_midi_event i915 v4l2_common iwlagn iwlcore
snd_seq ir_core drm_kms_helper drm videobuf_vmalloc snd_timer
snd_seq_device videobuf_core pcmcia joydev mac80211 uvcvideo videodev
v4l1_compat v4l2_compat_ioctl32 tveeprom cfg80211 rfkill i2c_i801
i2c_algo_bit tpm_tis tpm yenta_socket snd intel_agp shpchp pci_hotplug
video output pcmcia_rsrc wmi pcmcia_core soundcore snd_page_alloc
parport_pc parport i2c_cor
Jan 18 02:12:08 mate kernel:  irda tpm_bios intel_gtt pcspkr crc_ccitt
psmouse evdev serio_raw container processor battery ac button reiserfs
dm_mod raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor
xor async_memcpy async_tx raid1 raid0 multipath linear md_mod
ide_cd_mod cdrom sd_mod ata_generic pata_acpi ata_piix crc_t10dif
ide_pci_generic ahci libahci sdhci_pci firewire_ohci sdhci libata
scsi_mod piix ide_core firewire_core mmc_core uhci_hcd tg3 thermal
crc_itu_t thermal_sys ehci_hcd [last unloaded: scsi_wait_scan]
Jan 18 02:12:08 mate kernel: [  117.220091] Jan 18 02:12:08 mate
kernel: [  117.220091] Pid: 3154, comm: camera_factory_ Not tainted
2.6.37-rst #1 Victoria/TravelMate 6292 Jan 18 02:12:08 mate
kernel: [  117.220091] RIP: 0010:[a05a37f4]
[a05a37f4] res_free+0x14/0x49 [em28xx]
Jan 18 02:12:08 mate kernel: [  117.220091] RSP:
0018:8800794a1c48  EFLAGS: 00010297
Jan 18 02:12:08 mate kernel: [  117.220091] RAX: 0001 RBX:
88007b94dc00 RCX: 
Jan 18 02:12:08 mate kernel: [  117.220091] RDX:  RSI:
8800378e7000 RDI: 88007b94dc00
Jan 18 02:12:09 mate kernel: [  117.220091] RBP: 8800378e7000 R08:
0001 R09: 0c52
Jan 18 02:12:09 mate kernel: [  117.220091] R10:  R11:
0246 R12: 
Jan 18 02:12:09 mate kernel: [  117.220091] R13: a05ab920 R14:

Re: video_device - v4l2_devnode rename

Em 19-01-2011 09:59, Hans Verkuil escreveu:
 Em 19-01-2011 05:39, Hans Verkuil escreveu:
 Hi Mauro,

 We want to rename video_device to v4l2_devnode. So let me know when I
 can
 finalize my patches and, most importantly, against which branch.

 My current tree:

 http://git.linuxtv.org/hverkuil/media_tree.git?a=shortlog;h=refs/heads/devnode2

 tracks for_2.6.38-rc1 and should apply cleanly at the moment.

 Even not being able to handle it for .38, I did a look on the proposed
 changes. I'm not convinced about those renaming stuff.

 By looking on other subsystems, it seems to me that
 video_device_register()
 is a better name than any other name. Btw, by far, the use of _node for
 the
 device registration on Linux kernel is not usual at all:

 $ git grep -e _register  --and -e ( --and -e node include |grep -v
 of_mdiobus_register(
 include/linux/compaction.h:extern int compaction_register_node(struct node
 *node);
 include/linux/compaction.h:static inline int
 compaction_register_node(struct node *node)
 include/linux/swap.h:extern int scan_unevictable_register_node(struct node
 *node);
 include/linux/swap.h:static inline int
 scan_unevictable_register_node(struct node *node)

 There are only 2 functions using it. On those, the node at the function
 register name is due to struct node, and they likely make sense.

 A seek for *register*device or *device*register patterns show a lot:

 $ git grep -e _register_device  --and -e (  include|wc -l
 28

 $ git grep -e _device_register  --and -e (  include|wc -l
 32

 Basically, what I'm trying to say is that, on all subsystems, the function
 that creates
 the devices is called *register*device or *device*register.

 Why should we adopt anything different than the kernel convention for
 V4L2?
 
 I'm sure we went through this before.

Maybe.

 1) the name originates from the time that drivers had only one video node.
 It makes little sense anymore when drivers can create many video, radio,
 vbi and later v4l-subdev nodes. The key thing is that this driver
 registers a V4L2 node.

Each of those has its own struct device, so each of those are different
devices. As we've discussed previously, subdev is a bad name, as, on Linux,
everything that ultimately creates a /dev on userspace is a device.

 2) struct v4l2_device and struct video_device look too similar. While
 v4l2_device represents the whole V4L2 hardware, the video_device
 represents the video/radio/vbi/... device node only.

So, maybe v4l2_device is not a good name for it, as it is a set of video 
devices.

 3) (less important) all types/functions within the v4l2 framework now have
 the v4l2_ prefix, except this one. Aligning this will make everything more
 consistent and recognizable.
 
 We're not like most other subsystems where often just a single device node
 is registered. We have much more complex hardware. So I think that
 'v4l2_devnode' much more clearly identifies what it represents than
 'video_device'.

There are other subsystems where drivers register several devices. For example, 
I have one 3G modem here that registers 4 devices.

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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
On Jan 16, 2011, at 10:29 PM, Andy Walls wrote:

On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote:
Mauro,

Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes
for 2.6.38.

The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set
defaults for I2C client address 0x71. I know I was the one who
recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv
rely on it for the moment - Mea culpa.

The lirc_zilog changes are tested to work with both Tx and Rx with an
HVR-1600. I don't want to continue much further on lirc_zilog changes,
unitl a few things happen:

1. I have developed, and have had tested, a patch for the pvrusb2 driver
to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported
device.

Mauro,

I have developed a patch for pvrusb2 and Mike Isely provided his Ack. I
have added it to my z8 branch and this pull request.

I've finally got around to trying it out with the HVR-1950 I've got here,
and it does do the trick for ir-kbd-i2c (albeit I never see proper key
repeats, only alternating press/release key events).

Yay, a small victory.

I explicitly set the polling interval to 260 ms in pvrusb2, based on
your hdpvr findings and lirc_zilog code. I guess you can try tweaking
that back to 100 ms.

Not working with
lirc_zilog yet, it fails to load, due to an -EIO ret to one of the
i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't
looked into it any more than that yet.

Well technically lirc_zilog doesn't probe anymore. It relies on the
bridge driver telling it the truth.

But yes, lirc_zilog is overly sensitive to anything not being right
during lirc_zilog.c:ir_probe().

BTW, does your HVR-1950 have a blaster? The simple code I added to
pvrusb2 doesn't try to detect a unit on address 0x70. It always assumes
the Z8 is Tx capable.

With the cx18 and ivtv cards, the Hauppauge EEPROM indicates whether a
blaster is present. For those bridge drivers, I can communicate that
information to the IR modules.

For the hdpvr and pvrusb2, my short term plan was to always assume a Z8
could Tx, and make lirc_zilog not barf when it couldn't talk to a Tx
unit. I notice that Mike had written some short, simple IR unit
detection code here for other reasons:

http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l661
http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l542

For debugging, you might want to hack in a probe of address 0x70 for
your HVR-1950, to ensure the Tx side responds in the bridge driver.

Regards,
Andy

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

Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote:
 For debugging, you might want to hack in a probe of address 0x70 for
 your HVR-1950, to ensure the Tx side responds in the bridge driver. 

... keeping in mind that the Z8 doesn't seem to like quick writes, so
short reads should be used for probing purpose.

-- 
Jean Delvare
--
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] request for 2.6.38-rc1

Em 19-01-2011 09:34, Patrick Boettcher escreveu:
Hi Mauro,

On Sun, 16 Jan 2011, Mauro Carvalho Chehab wrote:

Em 14-01-2011 12:51, Patrick Boettcher escreveu:
Hi Mauro,

if it is not too late, here is a pull request for some new devices from
DiBcom. It would be nice to have it in 2.6.38-rc1.

Pull from

git://linuxtv.org/pb/media_tree.git staging/for_2.6.38-rc1.dibcom

for

DiB: Codingstype updates

Not sure if this is by purpose, but you're changing all
msleep(10) into msleep(20). This sounds very weird for a
CodingStyle fix:

-msleep(10);
+msleep(20);

I was as surprised as you when I saw that changed, but in fact it is a
checkpatch-fix: it seems that checkpatch is warning about msleep or less than
20ms.

Maybe it is not the right fix to put them to msleep(20), but I think this is
better than to do udelay(1).

What do you think?

Well, that is more a warning for the developer that the actual sleep time
may/will vary, depending
on how CONFIG_HZ is set. See: http://lkml.org/lkml/2007/8/3/250

There's actually a new function that can be used to disable such warnings (also
at linux/delay.h):
usleep_range(unsigned long min, unsigned long max);

If the device is very sensible if sleeping for a long time, using
usleep_range() is a good idea,
as it will rely on a different wake up implementation. Otherwise, if anything
between 10-20ms is OK,
I would just use msleep(10).

+if (request_firmware(state-frontend_firmware, dib9090.fw,
adap-dev-udev-dev)) {

The dib0700-firmware is already available through a license. The
dib9090-firmware will come later. It'll take a moment before everything is
ready.

Hmm... on a quick search at the web, I found this:
http://www.kernellabs.com/firmware/dib0700/README.dib0700

If those are the latest license terms, they are OK for linux-firmware tree
submission. After your
OK, I'll be adding the dibcom firmwares to my linux-firmware tree and ask the
upstream maintainer
to pull from it. It would be nice if dib9090 firmware could be licensed under
similar terms, and
also be submitted to linux-firmware tree.

Vendors are free to use their own legal text for it. There are several
examples for it
at:

http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob_plain;f=WHENCE;hb=HEAD

Btw, there are two alignment errors (one at dib7000p, for some cases,
aligned with 4 chars),
and another at dib8000, where all statements after an if are aligned with 3
tabs plus one space.
I'm fixing those issues, c/c you at the fix patches.

Nice, thank you.

Unfortunately, I did one error with the last patch. Accidentally, I folded a
checkpatch.pl
shut up patch. Due to that, I missed the merge window. I'll be sending an
upstream request
for pulling it on a separate branch, together with two other improvement
patches (vb2 and ngene).
Let's hope that those will be accepted for .38.

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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 19 Jan 2011, Andy Walls wrote:

 On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
 
 
   Not working with
  lirc_zilog yet, it fails to load, due to an -EIO ret to one of the
  i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't
  looked into it any more than that yet.
 
 Well technically lirc_zilog doesn't probe anymore.  It relies on the
 bridge driver telling it the truth.

The bridge driver (pvrusb2) still does one probe if it's a 24xxx device: 
It probes 0x71 in order to determine if it is dealing with an MCE 
variant device.  Hauppauge did not change the USB ID when they released 
the 24xxx MCE variant (which has the IR blaster, thus the zilog device).  
The only way to tell the two devices apart is by discovering the 
existence of the zilog device - and the bridge driver needs to do this 
in order to properly disable its emulated I2C IR receiver which would 
otherwise be needed for the non-MCE device.

Based on the discussion here, could that probe be a source of trouble on 
the 24XXX MCE device?

This probing behavior does not happen for HVR-1950 (or HVR-1900) since 
there's only one possible IR configuration there.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 2011-01-19 at 13:40 +0100, Jean Delvare wrote:
 On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote:
  For debugging, you might want to hack in a probe of address 0x70 for
  your HVR-1950, to ensure the Tx side responds in the bridge driver. 
 
 ... keeping in mind that the Z8 doesn't seem to like quick writes, so
 short reads should be used for probing purpose.
 

Noted.  Thanks.

Actually, I think that might be due to the controller in the USB
connected devices (hdpvr and pvrusb2).  The PCI connected devices, like
cx18 cards, don't have a problem with the Z8, the default I2C probe
method, and i2c-algo-bit.
(A good example of why only bridge drivers should do any required
probing.)


Looking at the code in pvrusb2, it appears to already use a 0 length
read for a probe:

http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l542

Regards,
Andy

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

Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 19 Jan 2011, Andy Walls wrote:

 On Wed, 2011-01-19 at 13:40 +0100, Jean Delvare wrote:
  On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote:
   For debugging, you might want to hack in a probe of address 0x70 for
   your HVR-1950, to ensure the Tx side responds in the bridge driver. 
  
  ... keeping in mind that the Z8 doesn't seem to like quick writes, so
  short reads should be used for probing purpose.
  
 
 Noted.  Thanks.
 
 Actually, I think that might be due to the controller in the USB
 connected devices (hdpvr and pvrusb2).  The PCI connected devices, like
 cx18 cards, don't have a problem with the Z8, the default I2C probe
 method, and i2c-algo-bit.
 (A good example of why only bridge drivers should do any required
 probing.)
 
 
 Looking at the code in pvrusb2, it appears to already use a 0 length
 read for a probe:
 
 http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l542

Yes but that function is used in two places: (1) If a bus scan is 
performed during initialization (normally it isn't), and (2) it is 
called once ONLY for a 24xxx device (targeting 0x71) in order to 
determine if it is dealing with the MCE variant.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 2011-01-19 at 07:20 -0600, Mike Isely wrote:
 On Wed, 19 Jan 2011, Andy Walls wrote:
 
  On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
  
  
Not working with
   lirc_zilog yet, it fails to load, due to an -EIO ret to one of the
   i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't
   looked into it any more than that yet.
  
  Well technically lirc_zilog doesn't probe anymore.  It relies on the
  bridge driver telling it the truth.
 
 The bridge driver (pvrusb2) still does one probe if it's a 24xxx device: 
 It probes 0x71 in order to determine if it is dealing with an MCE 
 variant device.  Hauppauge did not change the USB ID when they released 
 the 24xxx MCE variant (which has the IR blaster, thus the zilog device).  
 The only way to tell the two devices apart is by discovering the 
 existence of the zilog device - and the bridge driver needs to do this 
 in order to properly disable its emulated I2C IR receiver which would 
 otherwise be needed for the non-MCE device.
 
 Based on the discussion here, could that probe be a source of trouble on 
 the 24XXX MCE device?

IMO, No. I think it is needed and just fine.

As I understand it, the rules/guidelines for I2C probing are now
something like this:

1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
do hardware probes at all.  They are to assume the bridge or platform
drivers verified the I2C slave hardware's existence somehow.

2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the
I2C subsystem to probe hardware that it knows for sure exists, or knows
for sure does not exist.  Just add the I2C device or not.

3. Bridge drivers should generally ask the I2C subsystem to probe for
hardware that _may_ exist.

4. If the default I2C subsystem hardware probe method doesn't work on a
particular hardware unit, the bridge driver may perform its own hardware
probe or provide a custom hardware probe method to the I2C subsystem.
hdpvr and pvrusb2 currently do the former.


 This probing behavior does not happen for HVR-1950 (or HVR-1900) since 
 there's only one possible IR configuration there.

So the HVR-1950 only has Z8's capable of both Tx and Rx?  No HVR-1950
has an Rx only Z8 unit?

Regards,
Andy



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

Re: [PATCH 0/1] radio-timb: Add tuner and DSP to the I2C bus

2011-01-19 Thread Richard Röjfors

On 11/26/2010 11:03 AM, Hans Verkuil wrote:
 On Friday, November 26, 2010 10:51:10 Richard Röjfors wrote:
 To follow is a patch to add the tuner and DSP passed in the platform data
 to the I2C bus.

 This patch is to be applied after Hans' patch to remove usage of the
 blocking ioctl.
 
 Is this something you need to have fixed for 2.6.37, or is 2.6.38 good enough?

It seems like this didn't make it to 2.6.38-rc1, is it possible to get it in 
before
the final 2.6.38? This is a bug fix...

--Richard
--
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] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors

2011-01-19 Thread Michael Jones

Hi Martin,

a couple of comments inline below.

On 01/19/2011 12:27 AM, Laurent Pinchart wrote:
 Hi Martin,
 
 Thanks for the patch. One comment below.
 
 On Tuesday 18 January 2011 22:27:42 Martin Hostettler wrote:
 Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
 synchronous interface.

 When in 8bit mode don't apply DC substraction of 64 per default as this
 would remove 1/4 of the sensor range.

 When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel) mode
 set the CDCC to output 8bit per pixel instead of 16bit.

 Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
 ---
  drivers/media/video/isp/ispccdc.c  |   22 ++
  drivers/media/video/isp/ispvideo.c |2 ++
  2 files changed, 20 insertions(+), 4 deletions(-)

 Changes since first version:
  - forward ported to current media.git

 diff --git a/drivers/media/video/isp/ispccdc.c
 b/drivers/media/video/isp/ispccdc.c index 578c8bf..c7397c9 100644
 --- a/drivers/media/video/isp/ispccdc.c
 +++ b/drivers/media/video/isp/ispccdc.c
 @@ -43,6 +43,7 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
 v4l2_subdev_fh *fh, unsigned int pad, enum v4l2_subdev_format_whence
 which);

  static const unsigned int ccdc_fmts[] = {
 +V4L2_MBUS_FMT_Y8_1X8,
  V4L2_MBUS_FMT_SGRBG10_1X10,
  V4L2_MBUS_FMT_SRGGB10_1X10,
  V4L2_MBUS_FMT_SBGGR10_1X10,
 @@ -1127,6 +1128,9 @@ static void ccdc_configure(struct isp_ccdc_device
 *ccdc) ccdc-syncif.datsz = pdata ? pdata-width : 10;
  ispccdc_config_sync_if(ccdc, ccdc-syncif);

 +/* CCDC_PAD_SINK */
 +format = ccdc-formats[CCDC_PAD_SINK];
 +
  syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);

  /* Use the raw, unprocessed data when writing to memory. The H3A and
 @@ -1144,10 +1148,15 @@ static void ccdc_configure(struct isp_ccdc_device
 *ccdc) else
  syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;

 -isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
 +/* Use PACK8 mode for 1byte per pixel formats */

 -/* CCDC_PAD_SINK */
 -format = ccdc-formats[CCDC_PAD_SINK];
 +if (isp_video_format_info(format-code)-bpp = 8)
 +syn_mode |= ISPCCDC_SYN_MODE_PACK8;
 +else
 +syn_mode = ~ISPCCDC_SYN_MODE_PACK8;
 +

It would make sense to me to move this bit into ispccdc_config_sync_if().

 +
 +isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);

  /* Mosaic filter */
  switch (format-code) {
 @@ -2244,7 +2253,12 @@ int isp_ccdc_init(struct isp_device *isp)
  ccdc-syncif.vdpol = 0;

  ccdc-clamp.oblen = 0;
 -ccdc-clamp.dcsubval = 64;
 +
 +if (isp-pdata-subdevs-interface == ISP_INTERFACE_PARALLEL
 + isp-pdata-subdevs-bus.parallel.width = 8)
 +ccdc-clamp.dcsubval = 0;
 +else
 +ccdc-clamp.dcsubval = 64;
 
 I don't like this too much. What happens if you have several sensors 
 connected 
 to the system with different bus width ?

I see Laurent's point here.  Maybe move the dcsubval assignment into
ccdc_configure().  Also, don't we also want to remove dcsubval for an
8-bit serially-attached sensor?  In ccdc_configure() you could make it
conditional on the mbus format's width on the CCDC sink pad.

 
  ccdc-vpcfg.pixelclk = 0;

 diff --git a/drivers/media/video/isp/ispvideo.c
 b/drivers/media/video/isp/ispvideo.c index 5f984e4..cd3d331 100644
 --- a/drivers/media/video/isp/ispvideo.c
 +++ b/drivers/media/video/isp/ispvideo.c
 @@ -221,6 +221,8 @@ isp_video_check_format(struct isp_video *video, struct
 isp_video_fh *vfh) }

  static struct isp_format_info formats[] = {
 +{ V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
 +  V4L2_MBUS_FMT_Y8_1X8, V4L2_PIX_FMT_GREY, 8, },
  { V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
  { V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
 


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

Hi Andy,

On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
 As I understand it, the rules/guidelines for I2C probing are now
 something like this:
 
 1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
 do hardware probes at all.  They are to assume the bridge or platform
 drivers verified the I2C slave hardware's existence somehow.
 
 2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the
 I2C subsystem to probe hardware that it knows for sure exists, or knows
 for sure does not exist.  Just add the I2C device or not.
 
 3. Bridge drivers should generally ask the I2C subsystem to probe for
 hardware that _may_ exist.
 
 4. If the default I2C subsystem hardware probe method doesn't work on a
 particular hardware unit, the bridge driver may perform its own hardware
 probe or provide a custom hardware probe method to the I2C subsystem.
 hdpvr and pvrusb2 currently do the former.

Yes, that's exactly how things are supposed to work now. And hopefully
it makes sense and helps you all write cleaner code (that was the
intent at least.)

-- 
Jean Delvare
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes


On Wed, 19 Jan 2011, Andy Walls wrote:

   [...]

 
 So the HVR-1950 only has Z8's capable of both Tx and Rx?  No HVR-1950
 has an Rx only Z8 unit?

As far as I know, that is indeed the case - Tx and Rx always.

It's the older 24xxx devices where there could be a difference, and 
that's why the probe only takes place there.  (And in the receive-only 
24xxx configuration it's not a Z8 but something wierd that is only 
accessible through FX2 commands not via I2C, which is why the bridge 
driver emulates the older I2C chip, making IR reception behave like the 
original 29xxx device.)

  -Mike

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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/2] [media] dib8000: fix small memory leak on error

2011-01-19 Thread Dan Carpenter

kfree(state) if fe allocation fails.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/dvb/frontends/dib8000.c 
b/drivers/media/dvb/frontends/dib8000.c
index 3e20aa8..c1c3e26 100644
--- a/drivers/media/dvb/frontends/dib8000.c
+++ b/drivers/media/dvb/frontends/dib8000.c
@@ -2514,7 +2514,7 @@ struct dvb_frontend *dib8000_attach(struct i2c_adapter 
*i2c_adap, u8 i2c_addr, s
return NULL;
fe = kzalloc(sizeof(struct dvb_frontend), GFP_KERNEL);
if (fe == NULL)
-   return NULL;
+   goto error;
 
memcpy(state-cfg, cfg, sizeof(struct dib8000_config));
state-i2c.adap = i2c_adap;
--
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/2] [media] dib9000: fix return type in dib9000_mbx_send_attr()

2011-01-19 Thread Dan Carpenter

dib9000_mbx_send_attr() returns an int.  It doesn't work to save
negative error codes in an unsigned char, so I've made ret an int
type.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/dvb/frontends/dib9000.c 
b/drivers/media/dvb/frontends/dib9000.c
index 43fb6e4..9151876 100644
--- a/drivers/media/dvb/frontends/dib9000.c
+++ b/drivers/media/dvb/frontends/dib9000.c
@@ -486,10 +486,11 @@ static int dib9000_mbx_host_init(struct dib9000_state 
*state, u8 risc_id)
 #define MAX_MAILBOX_TRY 100
 static int dib9000_mbx_send_attr(struct dib9000_state *state, u8 id, u16 * 
data, u8 len, u16 attr)
 {
-   u8 ret = 0, *d, b[2];
+   u8 *d, b[2];
u16 tmp;
u16 size;
u32 i;
+   int ret = 0;
 
if (!state-platform.risc.fw_is_running)
return -EINVAL;
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

Hi Andy,

On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
 adding some new fields for struct IR_i2c_init_data is acceptable.
 Specifically, I'd like to add a transceiver_lock mutex, a transceiver
 reset callback, and a data pointer for that reset callback.
 (Only lirc_zilog would use the reset callback and data pointer.)

Adding fields to these structures is perfectly fine, if you need to do
that, just go on.

But I'm a little confused about the names you chose,
ir_transceiver_lock and transceiver_lock. These seem too
TX-oriented for a mutex that is supposed to synchronize TX and RX
access. It's particularly surprising for the ir-kbd-i2c driver, which
as far as I know only supports RX. The name xcvr_lock you used for
lirc_zilog seems more appropriate.

-- 
Jean Delvare
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 19 Jan 2011, Jean Delvare wrote:

 Hi Andy,
 
 On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
  3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
  adding some new fields for struct IR_i2c_init_data is acceptable.
  Specifically, I'd like to add a transceiver_lock mutex, a transceiver
  reset callback, and a data pointer for that reset callback.
  (Only lirc_zilog would use the reset callback and data pointer.)
 
 Adding fields to these structures is perfectly fine, if you need to do
 that, just go on.
 
 But I'm a little confused about the names you chose,
 ir_transceiver_lock and transceiver_lock. These seem too
 TX-oriented for a mutex that is supposed to synchronize TX and RX
 access. It's particularly surprising for the ir-kbd-i2c driver, which
 as far as I know only supports RX. The name xcvr_lock you used for
 lirc_zilog seems more appropriate.

Actually the term transceiver is normally understood to mean both 
directions.  Otherwise it would be receiver or transmitter.  
Another screwy as aspect of english, and I say this as a native english 
speaker.  The term xcvr is usually just considered to be shorthand for 
transceiver.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 19 Jan 2011 09:09:47 -0600 (CST), Mike Isely wrote:
 On Wed, 19 Jan 2011, Jean Delvare wrote:
 
  Hi Andy,
  
  On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
   3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
   adding some new fields for struct IR_i2c_init_data is acceptable.
   Specifically, I'd like to add a transceiver_lock mutex, a transceiver
   reset callback, and a data pointer for that reset callback.
   (Only lirc_zilog would use the reset callback and data pointer.)
  
  Adding fields to these structures is perfectly fine, if you need to do
  that, just go on.
  
  But I'm a little confused about the names you chose,
  ir_transceiver_lock and transceiver_lock. These seem too
  TX-oriented for a mutex that is supposed to synchronize TX and RX
  access. It's particularly surprising for the ir-kbd-i2c driver, which
  as far as I know only supports RX. The name xcvr_lock you used for
  lirc_zilog seems more appropriate.
 
 Actually the term transceiver is normally understood to mean both 
 directions.  Otherwise it would be receiver or transmitter.  
 Another screwy as aspect of english, and I say this as a native english 
 speaker.  The term xcvr is usually just considered to be shorthand for 
 transceiver.

Oh. I stand corrected, thanks.

-- 
Jean Delvare
--
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] v4l: soc-camera: add enum-frame-size ioctl

On Tue, 18 Jan 2011, Qing Xu wrote:

 Hi Guennadi,
 
 Thanks for reviewing my patch! I update it again following your 
 suggestion, please take your time to review it again, Thanks a lot!
 
 -Qing
 
 Email: qi...@marvell.com
 Application Processor Systems Engineering,
 Marvell Technology Group Ltd.
 
 -Original Message-
 From: Qing Xu [mailto:qi...@marvell.com]
 Sent: 2011年1月19日 10:37
 To: g.liakhovet...@gmx.de
 Cc: linux-media@vger.kernel.org; Qing Xu
 Subject: [PATCH] [media] v4l: soc-camera: add enum-frame-size ioctl
 
 add vidioc_enum_framesizes implementation
 
 Signed-off-by: Qing Xu qi...@marvell.com
 ---
  drivers/media/video/soc_camera.c |   34 ++
  include/media/soc_camera.h   |1 +
  include/media/v4l2-subdev.h  |2 ++
  3 files changed, 37 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/soc_camera.c 
 b/drivers/media/video/soc_camera.c
 index 052bd6d..5e0aa9e 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c
 @@ -145,6 +145,15 @@ static int soc_camera_s_std(struct file *file, void 
 *priv, v4l2_std_id *a)
 return v4l2_subdev_call(sd, core, s_std, *a);
  }
 
 +static int soc_camera_enum_fsizes(struct file *file, void *fh,
 +struct v4l2_frmsizeenum *fsize)
 +{
 +   struct soc_camera_device *icd = file-private_data;
 +   struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
 +
 +   return ici-ops-enum_fsizes(icd, fsize);
 +}
 +
  static int soc_camera_reqbufs(struct file *file, void *priv,
   struct v4l2_requestbuffers *p)
  {
 @@ -1160,6 +1169,28 @@ static int default_s_parm(struct soc_camera_device 
 *icd,
 return v4l2_subdev_call(sd, video, s_parm, parm);
  }
 
 +static int default_enum_fsizes(struct soc_camera_device *icd,
 + struct v4l2_frmsizeenum *fsize)
 +{
 +   int ret;
 +   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
 +   const struct soc_camera_format_xlate *xlate;
 +   __u32 pixfmt = fsize-pixel_format;
 +   struct v4l2_frmsizeenum *fsize_mbus = fsize;

Please, test your patches before posting! The above should have been

+   struct v4l2_frmsizeenum *fsize_mbus = *fsize;

 +
 +   xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
 +   if (!xlate)
 +   return -EINVAL;
 +   /* map xlate-code to pixel_format, sensor only handle xlate-code*/
 +   fsize_mbus-pixel_format = xlate-code;
 +
 +   ret = v4l2_subdev_call(sd, video, enum_mbus_fsizes, fsize_mbus);
 +   if (ret  0)
 +   return ret;
 +
 +   return 0;

Yes, almost. You're still missing one important point though: you're not 
returning the result to the user... So, before your return 0; you have 
to add two more lines:

+   *fsize = *fsize_mbus;
+   fsize-pixel_format = pixfmt;

Thanks
Guennadi

 +}
 +
  static void soc_camera_device_init(struct device *dev, void *pdata)
  {
 dev-platform_data  = pdata;
 @@ -1195,6 +1226,8 @@ int soc_camera_host_register(struct soc_camera_host 
 *ici)
 ici-ops-set_parm = default_s_parm;
 if (!ici-ops-get_parm)
 ici-ops-get_parm = default_g_parm;
 +   if (!ici-ops-enum_fsizes)
 +   ici-ops-enum_fsizes = default_enum_fsizes;
 
 mutex_lock(list_lock);
 list_for_each_entry(ix, hosts, list) {
 @@ -1302,6 +1335,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops 
 = {
 .vidioc_g_input  = soc_camera_g_input,
 .vidioc_s_input  = soc_camera_s_input,
 .vidioc_s_std= soc_camera_s_std,
 +   .vidioc_enum_framesizes  = soc_camera_enum_fsizes,
 .vidioc_reqbufs  = soc_camera_reqbufs,
 .vidioc_try_fmt_vid_cap  = soc_camera_try_fmt_vid_cap,
 .vidioc_querybuf = soc_camera_querybuf,
 diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
 index 86e3631..6e4800c 100644
 --- a/include/media/soc_camera.h
 +++ b/include/media/soc_camera.h
 @@ -85,6 +85,7 @@ struct soc_camera_host_ops {
 int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
 int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
 int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
 +   int (*enum_fsizes)(struct soc_camera_device *, struct 
 v4l2_frmsizeenum *);
 unsigned int (*poll)(struct file *, poll_table *);
 const struct v4l2_queryctrl *controls;
 int num_controls;
 diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
 index b0316a7..0d482c9 100644
 --- a/include/media/v4l2-subdev.h
 +++ b/include/media/v4l2-subdev.h
 @@ -275,6 +275,8 @@ struct v4l2_subdev_video_ops {
 struct v4l2_dv_timings *timings);
 int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,

RE: soc-camera jpeg support?

On Tue, 18 Jan 2011, Qing Xu wrote:

 
 Sorry, which solution you would like me to implement?
 (1) is to add SOC_MBUS_PACKING_VARIABLE define and add error code in 
 soc_mbus_bytes_per_line(),
 and (2) is to implement int (*try_fmt)(struct v4l2_subdev *sd, struct 
 v4l2_format *fmt); in subdev, directly get V4L2_PIX_FMT_JPEG info from 
 host driver.

Number (1), please. Sensor drivers should not use v4l2_format, only 
mediabus formats. Your host driver should proceed as usual: if the user is 
requesting the JPEG fourcc format from it, it should look in the format 
translation table, find there the respective JPEG mediabus code, and 
configure the sensor with it. Only when calculating buffer sizes the host 
driver will have to treat JPEG specially. This way you have to add 3 
things to the generic code: definitions for JPEG mediabus code and a 
variable-line length packing, and an entry to the fourcc-mediabus 
translation table.

Thanks
Guennadi

 
 -Qing
 
 -Original Message-
 From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
 Sent: 2011年1月19日 1:31
 To: Qing Xu
 Cc: Laurent Pinchart; Linux Media Mailing List
 Subject: RE: soc-camera jpeg support?
 
 Thanks for the code! With it at hand it is going to be easier to
 understand and evaluate changes, that you propose to the generic modules.
 
 On Mon, 17 Jan 2011, Qing Xu wrote:
 
  Hi, Guennadi,
 
  Oh, yes, I agree with you, you are right, it is really not that simple,
  JPEG is always a headache,:(, as it is quite different from original
  yuv/rgb format, it has neither fixed bits-per-sample, nor fixed
  packing/bytes-per-line/per-frame, so when coding, I just hack value of
  .bits_per_sample and .packing, in fact, you will see in our host driver,
  if we find it is JPEG, will ignore bytes-per-line value, for example, in
  pxa955_videobuf_prepare(), for jpeg, we always allocate fixed buffer
  size for it (or, a better method is to allocate buffer size =
  width*height/jpeg-compress-ratio).
 
  I have 2 ideas:
  1) Do you think it is reasonable to add a not-fixed define into 
  soc_mbus_packing:
  enum soc_mbus_packing {
  SOC_MBUS_PACKING_NOT_FIXED,
  ...
  };
  And then, .bits_per_sample  = 0, /* indicate that sample bits is 
  not-fixed*/
  And, in function:
  s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf)
  {
  switch (mf-packing) {
  case SOC_MBUS_PACKING_NOT_FIXED:
  return 0;
  case SOC_MBUS_PACKING_NONE:
  return width * mf-bits_per_sample / 8;
  ...
  }
  return -EINVAL;
  }
 
  2) Or, an workaround in sensor(ov5642.c), is to implement:
  int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
  use the member (fmt-pix-pixelformat == V4L2_PIX_FMT_JPEG) to find out
  if it is jpeg. And in host driver, it calls try_fmt() into sensor. In
  this way, no need to change soc-camera common code, but I feel that it
  goes against with your xxx_mbus_xxx design purpose, right?
 
 I actually prefer this one, but with an addition of V4L2_MBUS_FMT_JPEG_1X8
 as per your additional üatch, but, please, also add a new packing, e.g.,
 SOC_MBUS_PACKING_COMPRESSED (or SOC_MBUS_PACKING_VARIABLE?). So, that we
 can cleanly translate between V4L2_MBUS_FMT_JPEG_1X8 and
 V4L2_PIX_FMT_JPEG, but host drivers, that want to support this, will have
 to know to calculate frame sizes in some special way, not just aborting,
 if soc_mbus_bytes_per_line() returned an error. We might also consider
 returning a different error code for this case, e.g., we could change the
 general error case to return -ENOENT, and use -EINVAL for cases like JPEG,
 where data is valid, but no valid calculation is possible.
 
 Thanks
 Guennadi
 
  What do you think?
 
  Please check the attachment, it is our host camera controller driver and 
  sensor.
 
  Thanks a lot!
  -Qing
 
  -Original Message-
  From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
  Sent: 2011Äê1ÔÂ18ÈÕ 1:39
  To: Qing Xu
  Cc: Laurent Pinchart; Linux Media Mailing List
  Subject: Re: soc-camera jpeg support?
 
  On Mon, 17 Jan 2011, Qing Xu wrote:
 
   Hi,
  
   Many of our sensors support directly outputting JPEG data to camera
   controller, do you feel it's reasonable to add jpeg support into
   soc-camera? As it seems that there is no define in v4l2-mediabus.h which
   is suitable for our case.
 
  In principle I have nothing against this, but, I'm afraid, it is not quite
  that simple. I haven't worked with such sensors myself, but, AFAIU, the
  JPEG image format doesn't have fixed bytes-per-line and bytes-per-frame
  values. If you add it like you propose, this would mean, that it just
  delivers normal 8 bits per pixel images. OTOH, soc_mbus_bytes_per_line()
  would just return -EINVAL for your JPEG format, so, unsupporting drivers
  would just error out, which is not all that bad. When the first driver
  decides to

Re: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-19 Thread VDR User

On Sun, Jan 9, 2011 at 6:14 PM, Mark Zimmerman markz...@frii.com wrote:
 I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but
 which fails to initialize with the latest 2.6.36 kernel. The firmware
 fails to load due to an i2c failure. A search of the archives indicates
 that this is not the first time this issue has occurred.

 What can I do to help get this problem fixed?

 Here is the dmesg from 2.6.35, for the two tuners:

 xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
 xc5000: firmware read 12401 bytes.
 xc5000: firmware uploading...
 xc5000: firmware upload complete...
 xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
 xc5000: firmware read 12401 bytes.
 xc5000: firmware uploading...
 xc5000: firmware upload complete..

 and here is what happens with 2.6.36:

 xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
 xc5000: firmware read 12401 bytes.
 xc5000: firmware uploading...
 xc5000: I2C write failed (len=3)
 xc5000: firmware upload complete...
 xc5000: Unable to initialise tuner
 xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
 xc5000: firmware read 12401 bytes.
 xc5000: firmware uploading...
 xc5000: I2C write failed (len=3)
 xc5000: firmware upload complete...


 More information about this: I tried 2.6.37 (vanilla source from
 kernel.org) and the problem persisted. So, I enabled these options:
 CONFIG_I2C_DEBUG_CORE=y
 CONFIG_I2C_DEBUG_ALGO=y
 CONFIG_I2C_DEBUG_BUS=y
 hoping to get more information but this time the firmware loaded
 successfully and the tuner works properly.

 This leads me to suspect a race condition somewhere, or maybe a
 tunable parameter that can be adjusted. The fact that the 'write
 failed' message occurs before the 'upload complete' message would tend
 to support this. Can anyone suggest something I might try?

Can someone please look into this and possibly provide a fix for the
bug?  I'm surprised it hasn't happened yet after all this time but
maybe it's been forgotten the bug existed.

Thanks.
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 7:21 AM, Andy Walls wrote:

On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
On Jan 16, 2011, at 10:29 PM, Andy Walls wrote:

On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote:
Mauro,

Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes
for 2.6.38.

The lirc_zilog changes are tested to work with both Tx and Rx with an
HVR-1600. I don't want to continue much further on lirc_zilog changes,
unitl a few things happen:

1. I have developed, and have had tested, a patch for the pvrusb2 driver
to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported
device.

Mauro,

I have developed a patch for pvrusb2 and Mike Isely provided his Ack. I
have added it to my z8 branch and this pull request.

I've finally got around to trying it out with the HVR-1950 I've got here,
and it does do the trick for ir-kbd-i2c (albeit I never see proper key
repeats, only alternating press/release key events).

Yay, a small victory.

I explicitly set the polling interval to 260 ms in pvrusb2, based on
your hdpvr findings and lirc_zilog code. I guess you can try tweaking
that back to 100 ms.

Ah, okay, hadn't yet looked at the code. That explains why it was acting
just like the hdpvr when its interval is 260 then. :)

I'll confirm whether or not the behavior of the 1950 is identical with
an interval of 100.

Not working with
lirc_zilog yet, it fails to load, due to an -EIO ret to one of the
i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't
looked into it any more than that yet.

Well technically lirc_zilog doesn't probe anymore. It relies on the
bridge driver telling it the truth.

But yes, lirc_zilog is overly sensitive to anything not being right
during lirc_zilog.c:ir_probe().

BTW, does your HVR-1950 have a blaster?

Yes, it does, looks like a jack identical to the one on the hdpvr, which
is good, since I don't have the 1950's blaster cable.

The simple code I added to
pvrusb2 doesn't try to detect a unit on address 0x70. It always assumes
the Z8 is Tx capable.

With the cx18 and ivtv cards, the Hauppauge EEPROM indicates whether a
blaster is present. For those bridge drivers, I can communicate that
information to the IR modules.

For the hdpvr and pvrusb2, my short term plan was to always assume a Z8
could Tx, and make lirc_zilog not barf when it couldn't talk to a Tx
unit.

Sounds sane to me.

I notice that Mike had written some short, simple IR unit
detection code here for other reasons:

For debugging, you might want to hack in a probe of address 0x70 for
your HVR-1950, to ensure the Tx side responds in the bridge driver.

Yeah, will definitely have to take a closer look at the pvrusb2 code.

--
Jarod Wilson
ja...@wilsonet.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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

2011-01-19 Thread Devin Heitmueller

On Wed, Jan 19, 2011 at 11:08 AM, Jarod Wilson ja...@wilsonet.com wrote:
 BTW, does your HVR-1950 have a blaster?

 Yes, it does, looks like a jack identical to the one on the hdpvr, which
 is good, since I don't have the 1950's blaster cable.

Correct - it uses the same cable as the HD-PVR.  The IR receiver on
that device is built into the front of the unit though, unlike the PCI
cards where it's on the cable.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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 v16 3/3] davinci vpbe: board specific additions

2011-01-19 Thread Robert Mellen

Are the davinci vpbe patches specific only to the DM644x platform? I am
developing on the DM365 and would like to use the OSD features implemented
in the patches. Are there plans to port these patches to the DM365? Is it
only a matter of changing the board-specific files, such as
board-dm365-evm.c?

Sincerely,
Robert Mellen


-Original Message-
From:
davinci-linux-open-source-bounces+robert.mellen=gvimd.com@linux.davincidsp.c
om
[mailto:davinci-linux-open-source-bounces+robert.mellen=gvimd@linux.davi
ncidsp.com] On Behalf Of Manjunath Hadli
Sent: Tuesday, January 18, 2011 8:40 AM
To: LMML; LAK; Kevin Hilman
Cc: dlos; Mauro Carvalho Chehab
Subject: [PATCH v16 3/3] davinci vpbe: board specific additions

This patch implements tables for display timings,outputs and
other board related functionalities.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 arch/arm/mach-davinci/board-dm644x-evm.c |   84
-
 1 files changed, 69 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..95ea13d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -176,18 +176,6 @@ static struct platform_device
davinci_evm_nandflash_device = {
.resource   = davinci_evm_nandflash_resource,
 };
 
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
-   .name   = davincifb,
-   .id = -1,
-   .dev = {
-   .dma_mask   = davinci_fb_dma_mask,
-   .coherent_dma_mask  = DMA_BIT_MASK(32),
-   },
-   .num_resources = 0,
-};
-
 static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -337,7 +325,6 @@ static struct pcf857x_platform_data pcf_data_u2 = {
.teardown   = evm_led_teardown,
 };
 
-
 /* U18 - A/V clock generator and user switch */
 
 static int sw_gpio;
@@ -404,7 +391,6 @@ static struct pcf857x_platform_data pcf_data_u18 = {
.teardown   = evm_u18_teardown,
 };
 
-
 /* U35 - various I/O signals used to manage USB, CF, ATA, etc */
 
 static int
@@ -616,8 +602,73 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
 
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+   {ntsc, VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+   {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+   {pal, VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+   {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+   {480p59_94, VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+   {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+   {576p50, VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+   {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + encoders. Keep the order same
+ * as that of encoders. First that from venc followed by that from
+ * encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+   {
+   .output = {
+   .index = 0,
+   .name = Composite,
+   .type = V4L2_OUTPUT_TYPE_ANALOG,
+   .std = VENC_STD_ALL,
+   .capabilities = V4L2_OUT_CAP_STD,
+   },
+   .subdev_name = VPBE_VENC_SUBDEV_NAME,
+   .default_mode = ntsc,
+   .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+   .modes = vbpe_enc_std_timings,
+   },
+   {
+   .output = {
+   .index = 1,
+   .name = Component,
+   .type = V4L2_OUTPUT_TYPE_ANALOG,
+   .capabilities = V4L2_OUT_CAP_PRESETS,
+   },
+   .subdev_name = VPBE_VENC_SUBDEV_NAME,
+   .default_mode = 480p59_94,
+   .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+   .modes = vbpe_enc_preset_timings,
+   },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+   .module_name = dm644x-vpbe-display,
+   .i2c_adapter_id = 1,
+   .osd = {
+   .module_name = VPBE_OSD_SUBDEV_NAME,
+   },
+   .venc = {
+   .module_name = VPBE_VENC_SUBDEV_NAME,
+   },
+   .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+

Re: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-19 Thread Devin Heitmueller

On Wed, Jan 19, 2011 at 10:59 AM, VDR User user@gmail.com wrote:
 Can someone please look into this and possibly provide a fix for the
 bug?  I'm surprised it hasn't happened yet after all this time but
 maybe it's been forgotten the bug existed.

You shouldn't be too surprised.  In many cases device support for more
obscure products comes not from the maintainer of the actual driver
but rather from some random user who hacked in an additional board
profile (in many cases, not doing it correctly but good enough so it
works for them).  In cases like that, the changes get committed, the
original submitter disappears, and then when things break there is
nobody with the appropriate knowledge and the hardware to debug the
problem.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: How to support MIPI CSI-2 controller in soc-camera framework?

(a general request: could you please configure your mailer to wrap lines 
at somewhere around 70 characters?)

On Tue, 18 Jan 2011, Qing Xu wrote:

 Hi,
 
 Our chip support both MIPI and parallel interface. The HW connection logic is
 sensor(such as ov5642) - our MIPI controller(handle DPHY timing/ CSI-2 
 things) - our camera controller (handle DMA transmitting/ fmt/ size 
 things). Now, I find the driver of sh_mobile_csi2.c, it seems like a 
 CSI-2 driver, but I don't quite understand how it works:
 1) how the host controller call into this driver?

This is a normal v4l2-subdev driver. Platform data for the 
sh_mobile_ceu_camera driver provides a link to CSI2 driver data, then the 
host driver loads the CSI2 driver, which then links itself into the 
subdevice list. Look at arch/arm/mach-shmobile/board-ap4evb.c how the data 
is linked:

static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
.flags = SH_CEU_FLAG_USE_8BIT_BUS,
.csi2_dev = csi2_device.dev,
};

and in the hosz driver drivers/media/video/sh_mobile_ceu_camera.c look in 
the sh_mobile_ceu_probe function below the lines:

csi2 = pcdev-pdata-csi2_dev;
if (csi2) {
...


 2) how the host controller/sensor negotiate MIPI variable with this 
 driver, such as D-PHY timing(hs_settle/hs_termen/clk_settle/clk_termen), 
 number of lanes...?

Since I only had a limited number of MIPI setups, I haven't implemented 
maximum flexibility. A part of the parameters is hard-coded, another part 
is provided in the platform driver, yet another part is calculated 
dynamically.

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: [PATCH V2] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors

2011-01-19 Thread Laurent Pinchart

Hi Michael,

On Wednesday 19 January 2011 14:45:46 Michael Jones wrote:
 On 01/19/2011 12:27 AM, Laurent Pinchart wrote:
  On Tuesday 18 January 2011 22:27:42 Martin Hostettler wrote:
  Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
  synchronous interface.
  
  When in 8bit mode don't apply DC substraction of 64 per default as this
  would remove 1/4 of the sensor range.
  
  When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel)
  mode set the CDCC to output 8bit per pixel instead of 16bit.
  
  Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
  ---
  
   drivers/media/video/isp/ispccdc.c  |   22 ++
   drivers/media/video/isp/ispvideo.c |2 ++
   2 files changed, 20 insertions(+), 4 deletions(-)
  
  Changes since first version:
 - forward ported to current media.git
  
  diff --git a/drivers/media/video/isp/ispccdc.c
  b/drivers/media/video/isp/ispccdc.c index 578c8bf..c7397c9 100644
  --- a/drivers/media/video/isp/ispccdc.c
  +++ b/drivers/media/video/isp/ispccdc.c
  @@ -43,6 +43,7 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
  v4l2_subdev_fh *fh, unsigned int pad, enum v4l2_subdev_format_whence
  which);
  
   static const unsigned int ccdc_fmts[] = {
  
  +  V4L2_MBUS_FMT_Y8_1X8,
  
 V4L2_MBUS_FMT_SGRBG10_1X10,
 V4L2_MBUS_FMT_SRGGB10_1X10,
 V4L2_MBUS_FMT_SBGGR10_1X10,
  
  @@ -1127,6 +1128,9 @@ static void ccdc_configure(struct isp_ccdc_device
  *ccdc) ccdc-syncif.datsz = pdata ? pdata-width : 10;
  
 ispccdc_config_sync_if(ccdc, ccdc-syncif);
  
  +  /* CCDC_PAD_SINK */
  +  format = ccdc-formats[CCDC_PAD_SINK];
  +
  
 syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
 
 /* Use the raw, unprocessed data when writing to memory. The H3A and
  
  @@ -1144,10 +1148,15 @@ static void ccdc_configure(struct
  isp_ccdc_device *ccdc) else
  
 syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;
  
  -  isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
  +  /* Use PACK8 mode for 1byte per pixel formats */
  
  -  /* CCDC_PAD_SINK */
  -  format = ccdc-formats[CCDC_PAD_SINK];
  +  if (isp_video_format_info(format-code)-bpp = 8)
  +  syn_mode |= ISPCCDC_SYN_MODE_PACK8;
  +  else
  +  syn_mode = ~ISPCCDC_SYN_MODE_PACK8;
  +
 
 It would make sense to me to move this bit into ispccdc_config_sync_if().

Why do you think so ? This configures how the data is written to memory, while 
ispccdc_config_sync_if() configures the CCDC input interface.

  +
  +  isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
  
 /* Mosaic filter */
 switch (format-code) {
  
  @@ -2244,7 +2253,12 @@ int isp_ccdc_init(struct isp_device *isp)
  
 ccdc-syncif.vdpol = 0;
 
 ccdc-clamp.oblen = 0;
  
  -  ccdc-clamp.dcsubval = 64;
  +
  +  if (isp-pdata-subdevs-interface == ISP_INTERFACE_PARALLEL
  +   isp-pdata-subdevs-bus.parallel.width = 8)
  +  ccdc-clamp.dcsubval = 0;
  +  else
  +  ccdc-clamp.dcsubval = 64;
  
  I don't like this too much. What happens if you have several sensors
  connected to the system with different bus width ?
 
 I see Laurent's point here.  Maybe move the dcsubval assignment into
 ccdc_configure().  Also, don't we also want to remove dcsubval for an
 8-bit serially-attached sensor?  In ccdc_configure() you could make it
 conditional on the mbus format's width on the CCDC sink pad.

This piece of code only sets the default value. If the user sets another 
value, the driver must not override it silently when the video stream is 
started. I'm not really sure how to properly fix this. The best solution is of 
course to set the value from userspace.

 ccdc-vpcfg.pixelclk = 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

Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 8:20 AM, Mike Isely wrote:

 This probing behavior does not happen for HVR-1950 (or HVR-1900) since 
 there's only one possible IR configuration there.

Just to be 100% clear, the device I'm poking it is definitely an
HVR-1950, using ir_scheme PVR2_IR_SCHEME_ZILOG, so the probe bits
shouldn't coming into play with anything I'm doing. Only just now
started looking at the pvrusb2 code. Wow, there's a LOT of it. ;)

-- 
Jarod Wilson
ja...@wilsonet.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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

Jean,

As Mike noted, transceiver is a contraction of transmitter-receiver. But I
wouldn't blame English speakers in general for that, just English speaking
engineers. ;)

English speaking engineers (likely) also orignated use of the x as shorthand
for trans- and crys-.

Transceiver_lock was intended to mean a lock protecting access to both
portions of a chip: tx and rx.

I'm still mulling it all over though. Some change will be made to
IR_i2c_init_data. I found I need some more time to design exactly what I need.

Regards,
Andy

Mike Isely is...@isely.net wrote:

On Wed, 19 Jan 2011, Jean Delvare wrote:

Hi Andy,

On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
adding some new fields for struct IR_i2c_init_data is acceptable.
Specifically, I'd like to add a transceiver_lock mutex, a transceiver
reset callback, and a data pointer for that reset callback.
(Only lirc_zilog would use the reset callback and data pointer.)

Adding fields to these structures is perfectly fine, if you need to do
that, just go on.

But I'm a little confused about the names you chose,
ir_transceiver_lock and transceiver_lock. These seem too
TX-oriented for a mutex that is supposed to synchronize TX and RX
access. It's particularly surprising for the ir-kbd-i2c driver, which
as far as I know only supports RX. The name xcvr_lock you used for
lirc_zilog seems more appropriate.

Actually the term transceiver is normally understood to mean both
directions. Otherwise it would be receiver or transmitter.
Another screwy as aspect of english, and I say this as a native english
speaker. The term xcvr is usually just considered to be shorthand for
transceiver.

-Mike

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 19 Jan 2011, Jarod Wilson wrote:

 On Jan 19, 2011, at 8:20 AM, Mike Isely wrote:
 
  This probing behavior does not happen for HVR-1950 (or HVR-1900) since 
  there's only one possible IR configuration there.
 
 Just to be 100% clear, the device I'm poking it is definitely an
 HVR-1950, using ir_scheme PVR2_IR_SCHEME_ZILOG, so the probe bits
 shouldn't coming into play with anything I'm doing. Only just now
 started looking at the pvrusb2 code. Wow, there's a LOT of it. ;)

Yes, and yes :-)

The standalone driver version (which is loaded with ifdef's that allow 
compilation back to 2.6.11) makes the in-kernel driver look small by 
comparison.

There is a fair degree of compartmentalization between the modules.  
The roadmap to what it does for just HVR-1950 you can find by first 
looking at the declarations in pvrusb2-devattr.h and then the 
device-specific configurations in pvrusb2-devattr.c.  From there you can 
usually grep your way around to see how those configuration bits affect 
the rest of the driver.  Most of the really fun stuff is in 
pvrusb2-hdw.c.  Pretty much everything else supports or uses that 
central component.

The actual stuff which deals with I2C is not that large.  Beyond making 
the access possible at all, the driver largely just tries to stay out of 
the way of external logic that needs to reach the bus.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 11:57 AM, Mike Isely wrote:

 On Wed, 19 Jan 2011, Jarod Wilson wrote:
 
 On Jan 19, 2011, at 8:20 AM, Mike Isely wrote:
 
 This probing behavior does not happen for HVR-1950 (or HVR-1900) since 
 there's only one possible IR configuration there.
 
 Just to be 100% clear, the device I'm poking it is definitely an
 HVR-1950, using ir_scheme PVR2_IR_SCHEME_ZILOG, so the probe bits
 shouldn't coming into play with anything I'm doing. Only just now
 started looking at the pvrusb2 code. Wow, there's a LOT of it. ;)
 
 Yes, and yes :-)
 
 The standalone driver version (which is loaded with ifdef's that allow 
 compilation back to 2.6.11) makes the in-kernel driver look small by 
 comparison.
 
 There is a fair degree of compartmentalization between the modules.  
 The roadmap to what it does for just HVR-1950 you can find by first 
 looking at the declarations in pvrusb2-devattr.h and then the 
 device-specific configurations in pvrusb2-devattr.c.  From there you can 
 usually grep your way around to see how those configuration bits affect 
 the rest of the driver.  Most of the really fun stuff is in 
 pvrusb2-hdw.c.  Pretty much everything else supports or uses that 
 central component.
 
 The actual stuff which deals with I2C is not that large.  Beyond making 
 the access possible at all, the driver largely just tries to stay out of 
 the way of external logic that needs to reach the bus.

Cool, thanks much for the pointers, that does help. Based on just
looking at pvrusb2-i2c-core.c's pvr2_i2c_register_ir() versus the
hdpvr's register function, I think I already see how to make the
IR part co-operate with lirc_zilog, and have hacked up a quick patch
to test that theory out...

Basically, rather than calling i2c_new_device() independently for
each address (0x70 and 0x71), call it a single time with an
i2c_board_info struct that looks similar to what's in the hdpvr
driver now. The -EIO I was seeing from lirc_zilog, from what I can
recall, is identical to what was happening with the hdpvr prior to
commit 37634d7308c5c1bdde03ab703a3cac3f0fb12453 (in media_tree.git).

Should be able to test this after lunch.

-- 
Jarod Wilson
ja...@wilsonet.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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:

 Hi Andy,
 
 On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
 As I understand it, the rules/guidelines for I2C probing are now
 something like this:
 
 1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
 do hardware probes at all.  They are to assume the bridge or platform
 drivers verified the I2C slave hardware's existence somehow.
 
 2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the
 I2C subsystem to probe hardware that it knows for sure exists, or knows
 for sure does not exist.  Just add the I2C device or not.
 
 3. Bridge drivers should generally ask the I2C subsystem to probe for
 hardware that _may_ exist.
 
 4. If the default I2C subsystem hardware probe method doesn't work on a
 particular hardware unit, the bridge driver may perform its own hardware
 probe or provide a custom hardware probe method to the I2C subsystem.
 hdpvr and pvrusb2 currently do the former.
 
 Yes, that's exactly how things are supposed to work now. And hopefully
 it makes sense and helps you all write cleaner code (that was the
 intent at least.)

One more i2c question...

Am I correct in assuming that since the zilog is a single device, which
can be accessed via two different addresses (0x70 for tx, 0x71 for rx),
that i2c_new_device() just once with both addresses in i2c_board_info
is correct, vs. calling i2c_new_device() once for each address?

At least, I'm reasonably sure that was the key to making the hdpvr IR
behave with lirc_zilog, and after lunch, I should know if that's also
the case for pvrusb2 devices w/a zilog IR chip.

-- 
Jarod Wilson
ja...@wilsonet.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: [RFC] Cropping and scaling with subdev pad-level operations

2011-01-19 Thread Sakari Ailus

Hi Hans, others,

Hans Verkuil wrote:
 Hi Laurent,
 
 My apologies that this reply is so late, but I knew I had to sit down and 
 think
 carefully about this and I didn't have time for that until today.
 
 I've decided not to quote your post but instead restate the problem in my own
 words.
 
 Seen abstractly you have an entity with inputs, outputs and a processing 
 pipeline
 that transforms the input(s) to the output(s) somehow. And each stage of that
 pipeline has its own configuration.
 
 You want to provide the developer that sets up such an entity with a 
 systematic
 and well-defined procedure while at the same time you want to keep the 
 entity's
 code as simple as possible.
 
 Part of this procedure is already decided: you always start with defining the
 inputs. The confusion begins with how to setup the configuration and the 
 outputs.
 
 I think the only reasonably way is to configure the pipeline stages in strict 
 order
 from the input to the output.
 
 So you start with defining the inputs. For a scaler the next thing to set is 
 the
 crop rectangle. And then finally the output.
 
 At each stage the entity will only check if the configuration parameters can 
 work
 with the input. It may make the rest of the pipeline invalid, but that's OK 
 for
 now.

This would mean that there would have to be a strict order in which
parameters would be set since as a result of changes a set of other
settings would be rendered invalid.

Virtually every block in the OMAP 3 ISP, for example, is able to do
cropping. Scaling is only possible with the resizer, though. I would
expect that this holds true for almost all similar pieces of hardware as
the cropping can be implemented using different first line start
addresses, offsets and lengts.

 The final step comes when the output is defined. If that returns OK, then you
 know the whole pipeline is valid.
 
 So what to do when you have an input and an output configured and someone 
 suddenly
 changes the crop configuration to a value that doesn't work with that 
 input/output
 combinations?
 
 The two options I've seen are:
 
 1) modify the crop configuration to fit the output
 2) modify the output configuration to fit the crop
 
 But there is a third option which I think works much better:
 
 3) accept the crop configuration if it fits the input, but report back to the 
 caller
that it invalidates the output.

 What the entity does with this crop configuration is purely up to the
entity: it can
 just store it in a shadow configuration and wait with applying it to the 
 hardware
 until it receives a consistent output format, or it can modify the output 
 format to
 fit the crop configuration. In any case, if changes are made, then they 
 should be
 made 'upstream'. This makes the behavior consistent. As long as you work your 
 way
 from input to output, you know that any configuration you've set for earlier 
 stages
 stay put and won't change unexpectedly.

It should be also possible to change both crop and source format at the
same time since the former may necessitate a change to the latter as
well, but it is a must to apply both for the same frame. Even if the
in-between configuration is valid, it is unwanted.

So I think there would have to be a flag to tell only apply the crop
change when the source format is changed. Also, the formats should be
changeable on different pads in a single operation.

I have to say that I like this in the sense that it does not explicitly
restrict the ioctls that can be used to change settings related to crop
/ scaling, but OTOH I don't see a need for further ioctls. Also single
ioctls have well defined and quite generic functionality.

On the other hand, this would necessitate the driver to cache the user
originating parameters without applying them. If the user uses g_fmt()
before the parameters have been applied, which format should be
returned, the deferred one or the current one?

What do you think about a more generic, explicit defer/commit flag in
the format and crop ioctls? The crop and format settings could be
deferred until another one is given w/o defer flag set. The
functionality would stay essentially the same.

The user space must behave itself but that's expected anyway...

 And if you decide to change a 'mid-pipeline' configuration, then you will get 
 a
 status back that tells you whether or not you broke the upstream 
 configuration.
 
 The advantage is that at any stage the driver code just has to check whether 
 the
 new configuration is valid given the input (in which case the call will 
 succeed)
 and whether the new configuration is valid for the current output and report 
 that
 in a status field.
 
 Note that 'input' and 'output' do not necessarily refer to pads, it may also 
 refer
 to stages of a pipeline. And the same principle should hold for both the 
 subdev
 API and for the 'main' V4L API (more about that later).
 
 A suggested alternative was to do the configuration atomically. I do not

Re: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-19 Thread VDR User

On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 Can someone please look into this and possibly provide a fix for the
 bug?  I'm surprised it hasn't happened yet after all this time but
 maybe it's been forgotten the bug existed.

 You shouldn't be too surprised.  In many cases device support for more
 obscure products comes not from the maintainer of the actual driver
 but rather from some random user who hacked in an additional board
 profile (in many cases, not doing it correctly but good enough so it
 works for them).  In cases like that, the changes get committed, the
 original submitter disappears, and then when things break there is
 nobody with the appropriate knowledge and the hardware to debug the
 problem.

Good point.  My understanding is that this is a fairly common card so
I wouldn't think that would be the case.  At any rate, hopefully we'll
be able to narrow down the cause of the problem and get it fixed.

Thanks.
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 12:12 PM, Jarod Wilson wrote:

 On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:
 
 Hi Andy,
 
 On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
 As I understand it, the rules/guidelines for I2C probing are now
 something like this:
 
 1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
 do hardware probes at all.  They are to assume the bridge or platform
 drivers verified the I2C slave hardware's existence somehow.
 
 2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the
 I2C subsystem to probe hardware that it knows for sure exists, or knows
 for sure does not exist.  Just add the I2C device or not.
 
 3. Bridge drivers should generally ask the I2C subsystem to probe for
 hardware that _may_ exist.
 
 4. If the default I2C subsystem hardware probe method doesn't work on a
 particular hardware unit, the bridge driver may perform its own hardware
 probe or provide a custom hardware probe method to the I2C subsystem.
 hdpvr and pvrusb2 currently do the former.
 
 Yes, that's exactly how things are supposed to work now. And hopefully
 it makes sense and helps you all write cleaner code (that was the
 intent at least.)
 
 One more i2c question...
 
 Am I correct in assuming that since the zilog is a single device, which
 can be accessed via two different addresses (0x70 for tx, 0x71 for rx),
 that i2c_new_device() just once with both addresses in i2c_board_info
 is correct, vs. calling i2c_new_device() once for each address?
 
 At least, I'm reasonably sure that was the key to making the hdpvr IR
 behave with lirc_zilog, and after lunch, I should know if that's also
 the case for pvrusb2 devices w/a zilog IR chip.

Actually, in looking at things closer and talking to Andy on irc, it
looks like this:

static struct i2c_board_info pvr2_xcvr_i2c_board_info = {
I2C_BOARD_INFO(ir_tx_z8f0811_haup, Z8F0811_IR_TX_I2C_ADDR),
I2C_BOARD_INFO(ir_rx_z8f0811_haup, Z8F0811_IR_RX_I2C_ADDR),
};

Expands to:

static struct i2c_board_info pvr2_xcvr_i2c_board_info = {
.type = ir_tx_z8f0811_haup,
.addr = Z8F0811_IR_TX_I2C_ADDR,
.type = ir_rx_z8f0811_haup,
.addr = Z8F0811_IR_RX_I2C_ADDR,
};

In which case, we're actually only registering 0x71 -- i2c_new_device()
certainly only appears to act on a single address, anyway.

-- 
Jarod Wilson
ja...@wilsonet.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: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-19 Thread Mark Zimmerman

On Wed, Jan 19, 2011 at 09:22:28AM -0800, VDR User wrote:
 On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
  Can someone please look into this and possibly provide a fix for the
  bug? ??I'm surprised it hasn't happened yet after all this time but
  maybe it's been forgotten the bug existed.
 
  You shouldn't be too surprised. ??In many cases device support for more
  obscure products comes not from the maintainer of the actual driver
  but rather from some random user who hacked in an additional board
  profile (in many cases, not doing it correctly but good enough so it
  works for them). ??In cases like that, the changes get committed, the
  original submitter disappears, and then when things break there is
  nobody with the appropriate knowledge and the hardware to debug the
  problem.
 
 Good point.  My understanding is that this is a fairly common card so
 I wouldn't think that would be the case.  At any rate, hopefully we'll
 be able to narrow down the cause of the problem and get it fixed.
 

Were there changes to i2c between 2.6.35 and 2.6.36 that are missing
from the xc5000 driver?  If so, is there another driver that has the
required updates so I can look at what changed?  I would like to get
some traction on this but I really don't know where to start.

Thanks,
-- Mark
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Wed, 19 Jan 2011 12:12:49 -0500, Jarod Wilson wrote:
 On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:
 
  Hi Andy,
  
  On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
  As I understand it, the rules/guidelines for I2C probing are now
  something like this:
  
  1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
  do hardware probes at all.  They are to assume the bridge or platform
  drivers verified the I2C slave hardware's existence somehow.
  
  2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the
  I2C subsystem to probe hardware that it knows for sure exists, or knows
  for sure does not exist.  Just add the I2C device or not.
  
  3. Bridge drivers should generally ask the I2C subsystem to probe for
  hardware that _may_ exist.
  
  4. If the default I2C subsystem hardware probe method doesn't work on a
  particular hardware unit, the bridge driver may perform its own hardware
  probe or provide a custom hardware probe method to the I2C subsystem.
  hdpvr and pvrusb2 currently do the former.
  
  Yes, that's exactly how things are supposed to work now. And hopefully
  it makes sense and helps you all write cleaner code (that was the
  intent at least.)
 
 One more i2c question...
 
 Am I correct in assuming that since the zilog is a single device, which
 can be accessed via two different addresses (0x70 for tx, 0x71 for rx),
 that i2c_new_device() just once with both addresses in i2c_board_info
 is correct, vs. calling i2c_new_device() once for each address?

Preliminary technical nitpicking: you can't actually pass two addresses
in i2c_board_info, so the second address has to be passed as platform
data.

I am sorry if you expected an authoritative answer, but... both options
are actually possible.

If you use a single call to i2c_new_device(), you'll have a single
i2c_client to start with, and you'll have to instantiate the second one
in the probe function using i2c_new_dummy().

If you instead decide to call i2c_new_device() twice, there will be two
calls to the probe function (which can be the same one in a single
driver, or two different ones in separate drivers, at your option.) If
any synchronization is needed between the two i2c_clients, you have to
use the bridge driver as a relay, as Andy proposed doing already.

Really, both are possible, and the two options aren't that different in
the end. I can't think of anything that can be done with one that
couldn't be achieved with the other.

 At least, I'm reasonably sure that was the key to making the hdpvr IR
 behave with lirc_zilog, and after lunch, I should know if that's also
 the case for pvrusb2 devices w/a zilog IR chip.

-- 
Jean Delvare
--
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 01/12] soc_camera: add control handler support

Hi Hans

This is not a complete review yet, but just something that occurred to me, 
while looking at the result of applying all these your patches, maybe you 
could just explain, why I'm wrong, or this will be something to change in 
the next version:

On Wed, 12 Jan 2011, Hans Verkuil wrote:

 The soc_camera framework is switched over to use the control framework.
 After this patch none of the controls in subdevs or host drivers are 
 available,
 until those drivers are also converted to the control framework.
 
 Signed-off-by: Hans Verkuil hverk...@xs4all.nl
 ---
  drivers/media/video/soc_camera.c  |  104 
 +++--
  drivers/media/video/soc_camera_platform.c |8 ++-
  include/media/soc_camera.h|2 +
  3 files changed, 33 insertions(+), 81 deletions(-)
 
 diff --git a/drivers/media/video/soc_camera.c 
 b/drivers/media/video/soc_camera.c
 index a66811b..7de3fe2 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c

[snip]

 @@ -908,6 +840,8 @@ static int soc_camera_init_i2c(struct soc_camera_device 
 *icd,
   icl-board_info, NULL);
   if (!subdev)
   goto ei2cnd;
 + if (v4l2_ctrl_add_handler(icd-ctrl_handler, subdev-ctrl_handler))
 + goto ei2cnd;
  
   client = v4l2_get_subdevdata(subdev);
  

Is this really i2c-specific? You added this to soc_camera_init_i2c(), 
which is only even built if I2C is configured, and is only used with i2c 
subdevs. It is called from soc_camera_probe(), if the respective subdev 
has i2c board-information. Otherwise a generic initialisation will take 
place, as is, e.g., the case with the soc-camera-platform driver. 
Shouldn't this call to add_handler be moved directly to soc_camera_probe() 
ot be used for all - not only i2c - subdevs? And one more nitpick below:

 @@ -963,15 +897,15 @@ static int soc_camera_probe(struct device *dev)
   if (icl-reset)
   icl-reset(icd-pdev);
  
 - ret = ici-ops-add(icd);
 - if (ret  0)
 - goto eadd;
 -
   /* Must have icd-vdev before registering the device */
   ret = video_dev_create(icd);
   if (ret  0)
   goto evdc;
  
 + ret = ici-ops-add(icd);
 + if (ret  0)
 + goto eadd;
 +

Yes, this is something, I'll have to think about / have a look at / test.

   /* Non-i2c cameras, e.g., soc_camera_platform, have no board_info */
   if (icl-board_info) {
   ret = soc_camera_init_i2c(icd, icl);
 @@ -1054,10 +988,10 @@ eiufmt:
   }
  enodrv:
  eadddev:
 - video_device_release(icd-vdev);
 -evdc:
   ici-ops-remove(icd);
  eadd:
 + video_device_release(icd-vdev);
 +evdc:
   soc_camera_power_set(icd, icl, 0);
  epower:
   regulator_bulk_free(icl-num_regulators, icl-regulators);
 @@ -1324,9 +1258,6 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops 
 = {
   .vidioc_dqbuf= soc_camera_dqbuf,
   .vidioc_streamon = soc_camera_streamon,
   .vidioc_streamoff= soc_camera_streamoff,
 - .vidioc_queryctrl= soc_camera_queryctrl,
 - .vidioc_g_ctrl   = soc_camera_g_ctrl,
 - .vidioc_s_ctrl   = soc_camera_s_ctrl,
   .vidioc_cropcap  = soc_camera_cropcap,
   .vidioc_g_crop   = soc_camera_g_crop,
   .vidioc_s_crop   = soc_camera_s_crop,
 @@ -1355,6 +1286,7 @@ static int video_dev_create(struct soc_camera_device 
 *icd)
   vdev-ioctl_ops = soc_camera_ioctl_ops;
   vdev-release   = video_device_release;
   vdev-tvnorms   = V4L2_STD_UNKNOWN;
 + vdev-ctrl_handler  = icd-ctrl_handler;
  
   icd-vdev = vdev;
  
 @@ -1402,13 +1334,24 @@ static int __devinit soc_camera_pdrv_probe(struct 
 platform_device *pdev)
   if (!icd)
   return -ENOMEM;
  
 + /*
 +  * Currently the subdev with the largest number of controls (13) is
 +  * ov6550. So let's pick 16 as a hint for the control handler. Note
 +  * that this is a hint only: too large and you waste some memory, too
 +  * small and there is a (very) small performance hit when looking up
 +  * controls in the internal hash.
 +  */
 + ret = v4l2_ctrl_handler_init(icd-ctrl_handler, 16);
 + if (ret  0)
 + goto escdevreg;
 +
   icd-iface = icl-bus_id;
   icd-pdev = pdev-dev;
   platform_set_drvdata(pdev, icd);
  
   ret = soc_camera_device_register(icd);
   if (ret  0)
 - goto escdevreg;
 + goto eschdlinit;

hm, no, eXXX means in my notation XXX has failed. So, escdevreg means 
soc_camera_device_register() failed and your eschdlinit should go to the 
previous goto.

  
   soc_camera_device_init(icd-dev, icl);
  
 @@ -1417,6 +1360,8 @@ static int __devinit soc_camera_pdrv_probe(struct 
 platform_device *pdev)
  
   return 0;
  
 +eschdlinit:
 + v4l2_ctrl_handler_free(icd-ctrl_handler);

Re: [PATCH V2] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors

2011-01-19 Thread martin

On Wed, Jan 19, 2011 at 12:27:19AM +0100, Laurent Pinchart wrote:
 Hi Martin,
 
 Thanks for the patch. One comment below.
 
 On Tuesday 18 January 2011 22:27:42 Martin Hostettler wrote:
  Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
  synchronous interface.
  
  When in 8bit mode don't apply DC substraction of 64 per default as this
  would remove 1/4 of the sensor range.
  
  When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel) mode
  set the CDCC to output 8bit per pixel instead of 16bit.
  
  Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
  ---
   drivers/media/video/isp/ispccdc.c  |   22 ++
   drivers/media/video/isp/ispvideo.c |2 ++
   2 files changed, 20 insertions(+), 4 deletions(-)
  
  Changes since first version:
  - forward ported to current media.git
  
  diff --git a/drivers/media/video/isp/ispccdc.c
  b/drivers/media/video/isp/ispccdc.c index 578c8bf..c7397c9 100644
[...]
  @@ -2244,7 +2253,12 @@ int isp_ccdc_init(struct isp_device *isp)
  ccdc-syncif.vdpol = 0;
  
  ccdc-clamp.oblen = 0;
  -   ccdc-clamp.dcsubval = 64;
  +
  +   if (isp-pdata-subdevs-interface == ISP_INTERFACE_PARALLEL
  +isp-pdata-subdevs-bus.parallel.width = 8)
  +   ccdc-clamp.dcsubval = 0;
  +   else
  +   ccdc-clamp.dcsubval = 64;
 
 I don't like this too much. What happens if you have several sensors 
 connected 
 to the system with different bus width ?
 

Yes, you're right of course, the current code is semantically broken.

But the only clean solution i can think of is setting it to 0
unconditionally.
I'm not sure what this default should acomplish, so maybe i'm missing
something here, but i think the right value if dc substraction is needed
would be highly sensor specific?
I think all other of these postprocessing features for the CCDC default to
off, so it would make sense to default this to off too.

The overenginered solution would be to maintain a different value for each
bus width and let the user change the setting for the buswidth of the
currently linked sensor. In a way this would make sense,
because the DC substraction is fundamentally dependent on the bus size i
think. But i don't think anyone would want such complexity.

But i think it wouldn't be nice if every user of an 8bit sensor needs to
set this manually just to get the sensor working in a sane way (for 8bit
substracting 64 is insane, for wider buses it's different)

So how to proceed with this?

 - Martin Hostettler
--
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: [BUG] media: dvb: dib9000: buggy locking

2011-01-19 Thread Malcolm Priestley

On Wed, 2011-01-19 at 16:10 +0300, Vasiliy Kulikov wrote:
 Hi,
 
 I've noticed that locking in drivers/media/dvb/frontends/dib9000.c is
 not correct:
 
 static int dib9000_fw_get_channel(...)
 {
 ...
   DibAcquireLock(state-platform.risc.mem_mbx_lock);
 ...
 
 error:
   DibReleaseLock(state-platform.risc.mem_mbx_lock);
   return ret;
 }
 
 #define DibAcquireLock(lock) do { if (mutex_lock_interruptible(lock)  0) 
 dprintk(could not get the lock); } while (0)
 #define DibReleaseLock(lock) mutex_unlock(lock)
 
 
 1) If mutex is not hold, then the critical section is not protected.
 
 2) If mutex was not hold, then the code tries to release not holded
 mutex.

I didn't think that was a problem, because most callers didn't have code
to handle the error. and would therefore hopefully just call again.

What I noticed in particular the lock is never released on error
condition as in...

static int dib9000_read_ber(struct dvb_frontend *fe, u32 * ber)
{
struct dib9000_state *state = fe-demodulator_priv;
u16 c[16];

DibAcquireLock(state-platform.risc.mem_mbx_lock);
if (dib9000_fw_memmbx_sync(state, FE_SYNC_CHANNEL)  0)
return -EIO;   --the lock is never 
released.
dib9000_risc_mem_read(state, FE_MM_R_FE_MONITOR, (u8 *) c, sizeof(c));
DibReleaseLock(state-platform.risc.mem_mbx_lock);

*ber = c[10]  16 | c[11];
return 0;
}


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

Re: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

2011-01-19 Thread Andreas Oberritter

On 01/19/2011 06:03 PM, Thierry LELEGARD wrote:
 OK, then what? Is the S2API behavior (returning cached - but incorrect - 
 tuning
 parameter values) satisfactory for everyone or shall we adapt S2API to mimic 
 the
 API V3 behavior (return the actual tuning parameter values as automatically
 adjusted by the driver)?

To quote myself:

if that's still the case in Git (I didn't verify), then it should indeed
be changed to behave like v3 does. Would you mind to submit a patch, please?

I haven't heard any objections, so just go on if you want. Otherwise I
might prepare a patch once time permits.

Regards,
Andreas
--
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: OK

2011-01-19 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:Wed Jan 19 19:00:28 CET 2011
git master:   1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-x86_64: OK
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

A linux-media.tar.bz2 archive with the latest media git sources that can be
used with the media_build tree is available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday-linux-media.tar.bz2

Rename to linux-media.tar.bz2, put it in the media_build/linux directory,
go to the directory and type 'make untar'.

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: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-19 Thread Timothy D. Lenz

So what would a mainstream dual (or more) tuner card be? I've found 
these Fusions to be flaky. Had one die and another went flaky when I 
enabled the sleep mode. Can't really afford any more now, but am always 
watching. A company called Ceton seems to havea  quad, but it's a cable 
card tuner costing $450.


On 1/19/2011 9:13 AM, Devin Heitmueller wrote:

On Wed, Jan 19, 2011 at 10:59 AM, VDR Useruser@gmail.com  wrote:

Can someone please look into this and possibly provide a fix for the
bug?  I'm surprised it hasn't happened yet after all this time but
maybe it's been forgotten the bug existed.


You shouldn't be too surprised.  In many cases device support for more
obscure products comes not from the maintainer of the actual driver
but rather from some random user who hacked in an additional board
profile (in many cases, not doing it correctly but good enough so it
works for them).  In cases like that, the changes get committed, the
original submitter disappears, and then when things break there is
nobody with the appropriate knowledge and the hardware to debug the
problem.

Devin


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

Re: [PATCH] v4l: Add driver for Micron MT9M032 camera sensor

2011-01-19 Thread martin

Hi Hans,

Thanks for the quick review.

offtopic
I just noticed i didn't really understand the new control framework that well, 
could
you maybe add a comment pointing to Documentation/video4linux/v4l2-controls.txt 
in
the v4l2-ctrl.h header? I think that would help a lot.
/offtopic

On Wed, Jan 19, 2011 at 12:05:10AM +0100, Hans Verkuil wrote:
 Hi Martin,
 
 On Tuesday, January 18, 2011 23:18:42 Martin Hostettler wrote:
  The MT9M032 is a parallel 1284x812 sensor from Micron controlled through 
  I2C.
  
  The driver creates a V4L2 subdevice. It currently supports cropping, gain,
  exposure and v/h flipping controls in monochrome mode with an
  external pixel clock.
 
 Now, this is a truly bleeding edge driver :-)
 
 Pads aren't even merged yet!

Yes, indeed. Blame the omap3 ISP driver for this :)

 
 Got some small comments:
 
  Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
  ---
   drivers/media/video/Kconfig |7 +
   drivers/media/video/Makefile|1 +
   drivers/media/video/mt9m032.c   |  834 
  +++
   drivers/media/video/mt9m032.h   |   38 ++
   include/media/v4l2-chip-ident.h |1 +
   5 files changed, 881 insertions(+), 0 deletions(-)
   create mode 100644 drivers/media/video/mt9m032.c
   create mode 100644 drivers/media/video/mt9m032.h
  
  diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
  index 9fad1a6..f2d5f80 100644
  --- a/drivers/media/video/Kconfig
  +++ b/drivers/media/video/Kconfig
  @@ -773,6 +773,13 @@ config SOC_CAMERA_MT9M001
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
   
  +config VIDEO_MT9M032
  +   tristate MT9M032 camera sensor support
  +   depends on I2C  VIDEO_V4L2
  +   help
  + This driver supports MT9M032 cameras from Micron, monochrome
  + models only.
  +
   config SOC_CAMERA_MT9M111
  tristate mt9m111, mt9m112 and mt9m131 support
  depends on SOC_CAMERA  I2C
  diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
  index 8f70b06..3e7299f 100644
  --- a/drivers/media/video/Makefile
  +++ b/drivers/media/video/Makefile
  @@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
   obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
   obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
   obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
  +obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
   obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
   obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
   obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
  diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
  new file mode 100644
  index 000..fe6af7b
  --- /dev/null
  +++ b/drivers/media/video/mt9m032.c
  @@ -0,0 +1,834 @@
  +/*
  + * Driver for MT9M032 CMOS Image Sensor from Micron
  + *
  + * Copyright (C) 2010-2011 Lund Engineering
  + * Contact: Gil Lund gwl...@lundeng.com
  + * Author: Martin Hostettler mar...@neutronstar.dyndns.org
  + *
  + * This program is free software; you can redistribute it and/or
  + * modify it under the terms of the GNU General Public License
  + * version 2 as published by the Free Software Foundation.
  + *
  + * This program is distributed in the hope that it will be useful, but
  + * WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  + * General Public License for more details.
  + *
  + * You should have received a copy of the GNU General Public License
  + * along with this program; if not, write to the Free Software
  + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
  + * 02110-1301 USA
  + */
  +
  +#include linux/delay.h
  +#include linux/i2c.h
  +#include linux/init.h
  +#include linux/kernel.h
  +#include linux/module.h
  +#include linux/slab.h
  +#include linux/v4l2-mediabus.h
  +
  +#include media/media-entity.h
  +#include media/v4l2-chip-ident.h
  +#include media/v4l2-ctrls.h
  +#include media/v4l2-device.h
  +#include media/v4l2-subdev.h
  +
  +#include mt9m032.h
  +
  +#define MT9M032_CHIP_VERSION   0x00
  +#define MT9M032_ROW_START  0x01
  +#define MT9M032_COLUMN_START   0x02
  +#define MT9M032_ROW_SIZE   0x03
  +#define MT9M032_COLUMN_SIZE0x04
  +#define MT9M032_HBLANK 0x05
  +#define MT9M032_VBLANK 0x06
  +#define MT9M032_SHUTTER_WIDTH_HIGH 0x08
  +#define MT9M032_SHUTTER_WIDTH_LOW  0x09
  +#define MT9M032_PIX_CLK_CTRL   0x0A
  +#define MT9M032_RESTART0x0B
  +#define MT9M032_RESET  0x0D
  +#define MT9M032_PLL_CONFIG10x11
  +#define MT9M032_READ_MODE1 0x1E
  +#define MT9M032_READ_MODE2 0x20
  +#define MT9M032_GAIN_GREEN10x2B
  +#define MT9M032_GAIN_BLUE  0x2C
  +#define MT9M032_GAIN_RED   0x2D
  +#define MT9M032_GAIN_GREEN20x2E
  +/* write only */
  +#define

Re: [RFC V10 3/7] drivers:media:radio: wl128x: FM Driver Common sources

Manju,

Em 18-01-2011 11:19, halli manjunatha escreveu:
  have a look at the driver it’s already reviewed by Hans Verkuil.
 Please let me know if you are okay to include this in mainline.

As I've already pointed you, just send me a pull request from your tree when
you think it is ready. I'll be reviewing it after that. There are just too much
reviews on those drivers from TI for me to dig into every single version, 
especially
since, on most cases, I can't really contribute much, as I don't have 
OMAP3/Davinci
datasheets and the required devices here for testing, and that the reviews
come from someone at TI and/or one of your customers with a real test case
scenario.

So, as agreed in the past, I just mark all those drivers with RFC at patchwork
and I wait for the driver maintainer to send me a pull request, indicating me
that you've reached on a point where the driver/patch series is ready for its
addition.

So, if you think you're ready, you just need to send a pull request to the ML.
You don't even need to c/c me on that (and please avoid doing it, otherwise
I end by having multiple copies of your pull request, flooding my email with no
good reason).

Thanks,
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 12:43 PM, Jean Delvare wrote:

 On Wed, 19 Jan 2011 12:12:49 -0500, Jarod Wilson wrote:
 On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:
 
 Hi Andy,
 
 On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
 As I understand it, the rules/guidelines for I2C probing are now
 something like this:
 
 1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
 do hardware probes at all.  They are to assume the bridge or platform
 drivers verified the I2C slave hardware's existence somehow.
 
 2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the
 I2C subsystem to probe hardware that it knows for sure exists, or knows
 for sure does not exist.  Just add the I2C device or not.
 
 3. Bridge drivers should generally ask the I2C subsystem to probe for
 hardware that _may_ exist.
 
 4. If the default I2C subsystem hardware probe method doesn't work on a
 particular hardware unit, the bridge driver may perform its own hardware
 probe or provide a custom hardware probe method to the I2C subsystem.
 hdpvr and pvrusb2 currently do the former.
 
 Yes, that's exactly how things are supposed to work now. And hopefully
 it makes sense and helps you all write cleaner code (that was the
 intent at least.)
 
 One more i2c question...
 
 Am I correct in assuming that since the zilog is a single device, which
 can be accessed via two different addresses (0x70 for tx, 0x71 for rx),
 that i2c_new_device() just once with both addresses in i2c_board_info
 is correct, vs. calling i2c_new_device() once for each address?
 
 Preliminary technical nitpicking: you can't actually pass two addresses
 in i2c_board_info, so the second address has to be passed as platform
 data.
 
 I am sorry if you expected an authoritative answer, but... both options
 are actually possible.
 
 If you use a single call to i2c_new_device(), you'll have a single
 i2c_client to start with, and you'll have to instantiate the second one
 in the probe function using i2c_new_dummy().
 
 If you instead decide to call i2c_new_device() twice, there will be two
 calls to the probe function (which can be the same one in a single
 driver, or two different ones in separate drivers, at your option.) If
 any synchronization is needed between the two i2c_clients, you have to
 use the bridge driver as a relay, as Andy proposed doing already.
 
 Really, both are possible, and the two options aren't that different in
 the end. I can't think of anything that can be done with one that
 couldn't be achieved with the other.

Yeah, see my follow-up mail. The code in hdpvr-i2c.c is clearly a bit
off now, and only worked in my testing, as at the time, I was using
an older lirc_zilog from prior to Andy's changes that still used the
old style binding and probing directly in the driver. I'm working on
fixing up hdpvr-i2c further right now, and will do some more prodding
with pvrusb2, the code for which looks correct with two i2c_new_device()
calls in it, one for each address, so I just need to figure out why
lirc_zilog is getting an -EIO trying to get tx brought up.

-- 
Jarod Wilson
ja...@wilsonet.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

[PATCH] s2255drv: firmware re-loading changes

2011-01-19 Thread Sensoray Linux Development

Change for firmware re-loading and updated firmware versions.

Signed-off-by: Dean Anderson linux-...@sensoray.com


diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index b63f8ca..561909b 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
@@ -57,7 +57,7 @@
 #include linux/usb.h
 
 #define S2255_MAJOR_VERSION1
-#define S2255_MINOR_VERSION20
+#define S2255_MINOR_VERSION21
 #define S2255_RELEASE  0
 #define S2255_VERSION  KERNEL_VERSION(S2255_MAJOR_VERSION, \
   S2255_MINOR_VERSION, \
@@ -312,9 +312,9 @@ struct s2255_fh {
 };
 
 /* current cypress EEPROM firmware version */
-#define S2255_CUR_USB_FWVER((3  8) | 6)
+#define S2255_CUR_USB_FWVER((3  8) | 11)
 /* current DSP FW version */
-#define S2255_CUR_DSP_FWVER 8
+#define S2255_CUR_DSP_FWVER 10102
 /* Need DSP version 5+ for video status feature */
 #define S2255_MIN_DSP_STATUS  5
 #define S2255_MIN_DSP_COLORFILTER 8
@@ -492,9 +492,11 @@ static void planar422p_to_yuv_packed(const unsigned char 
*in,
 
 static void s2255_reset_dsppower(struct s2255_dev *dev)
 {
-   s2255_vendor_req(dev, 0x40, 0x0b0b, 0x0b0b, NULL, 0, 1);
+   s2255_vendor_req(dev, 0x40, 0x0b0b, 0x0b01, NULL, 0, 1);
msleep(10);
s2255_vendor_req(dev, 0x50, 0x, 0x, NULL, 0, 1);
+   msleep(600);
+   s2255_vendor_req(dev, 0x10, 0x, 0x, NULL, 0, 1);
return;
 }
 


--
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 0/3] Convert SR030PC30 driver to use the control framework and the regulator API

Hello,

the following patch set is an update for the sr030pc30 sensor driver.
The second patch converts the driver to use the control framework and
adds two new controls as it required relatively little effort to have 
them exported.
The third patch replaces the set_power callback with regulator framework
calls, the RESET and STANDBY gpios are passed as platform data and are
now directly managed in the driver, rather than having the power handling
code repeated in each board setup file. 


The patch series contains:

[PATCH 1/3] sr030pc30: Remove empty s_stream op
[PATCH 2/3] sr030pc30: Use the control framework
[PATCH 3/3] sr030pc30: Add regulator framework support


Regards,
Sylwester



--
Sylwester Nawrocki
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 1/3] sr030pc30: Remove empty s_stream op

s_stream does nothing in current form so remove it.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungin.p...@samsung.com
---
 drivers/media/video/sr030pc30.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/sr030pc30.c b/drivers/media/video/sr030pc30.c
index c901721..e1eced1 100644
--- a/drivers/media/video/sr030pc30.c
+++ b/drivers/media/video/sr030pc30.c
@@ -714,11 +714,6 @@ static int sr030pc30_base_config(struct v4l2_subdev *sd)
return ret;
 }
 
-static int sr030pc30_s_stream(struct v4l2_subdev *sd, int enable)
-{
-   return 0;
-}
-
 static int sr030pc30_s_power(struct v4l2_subdev *sd, int on)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -761,7 +756,6 @@ static const struct v4l2_subdev_core_ops sr030pc30_core_ops 
= {
 };
 
 static const struct v4l2_subdev_video_ops sr030pc30_video_ops = {
-   .s_stream   = sr030pc30_s_stream,
.g_mbus_fmt = sr030pc30_g_fmt,
.s_mbus_fmt = sr030pc30_s_fmt,
.try_mbus_fmt   = sr030pc30_try_fmt,
-- 
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

[PATCH 2/3] sr030pc30: Use the control framework

Implement controls using the control framework.
Add horizontal/vertical flip controls, minor cleanup.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/sr030pc30.c |  311 +--
 1 files changed, 132 insertions(+), 179 deletions(-)

diff --git a/drivers/media/video/sr030pc30.c b/drivers/media/video/sr030pc30.c
index e1eced1..1a195f0 100644
--- a/drivers/media/video/sr030pc30.c
+++ b/drivers/media/video/sr030pc30.c
@@ -19,6 +19,8 @@
 #include linux/i2c.h
 #include linux/delay.h
 #include linux/slab.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
 #include media/v4l2-device.h
 #include media/v4l2-subdev.h
 #include media/v4l2-mediabus.h
@@ -141,17 +143,24 @@ module_param(debug, int, 0644);
 
 struct sr030pc30_info {
struct v4l2_subdev sd;
+   struct v4l2_ctrl_handler hdl;
+   struct {
+   /* exposure/auto-exposure cluster */
+   struct v4l2_ctrl *autoexposure;
+   struct v4l2_ctrl *exposure;
+   };
+   struct {
+   /* blue/red/autowhitebalance cluster */
+   struct v4l2_ctrl *autowb;
+   struct v4l2_ctrl *blue;
+   struct v4l2_ctrl *red;
+   };
+   struct v4l2_ctrl *hflip;
+   struct v4l2_ctrl *vflip;
const struct sr030pc30_platform_data *pdata;
const struct sr030pc30_format *curr_fmt;
const struct sr030pc30_frmsize *curr_win;
-   unsigned int auto_wb:1;
-   unsigned int auto_exp:1;
-   unsigned int hflip:1;
-   unsigned int vflip:1;
unsigned int sleep:1;
-   unsigned int exposure;
-   u8 blue_balance;
-   u8 red_balance;
u8 i2c_reg_page;
 };
 
@@ -172,52 +181,6 @@ struct i2c_regval {
u16 val;
 };
 
-static const struct v4l2_queryctrl sr030pc30_ctrl[] = {
-   {
-   .id = V4L2_CID_AUTO_WHITE_BALANCE,
-   .type   = V4L2_CTRL_TYPE_BOOLEAN,
-   .name   = Auto White Balance,
-   .minimum= 0,
-   .maximum= 1,
-   .step   = 1,
-   .default_value  = 1,
-   }, {
-   .id = V4L2_CID_RED_BALANCE,
-   .type   = V4L2_CTRL_TYPE_INTEGER,
-   .name   = Red Balance,
-   .minimum= 0,
-   .maximum= 127,
-   .step   = 1,
-   .default_value  = 64,
-   .flags  = 0,
-   }, {
-   .id = V4L2_CID_BLUE_BALANCE,
-   .type   = V4L2_CTRL_TYPE_INTEGER,
-   .name   = Blue Balance,
-   .minimum= 0,
-   .maximum= 127,
-   .step   = 1,
-   .default_value  = 64,
-   }, {
-   .id = V4L2_CID_EXPOSURE_AUTO,
-   .type   = V4L2_CTRL_TYPE_INTEGER,
-   .name   = Auto Exposure,
-   .minimum= 0,
-   .maximum= 1,
-   .step   = 1,
-   .default_value  = 1,
-   }, {
-   .id = V4L2_CID_EXPOSURE,
-   .type   = V4L2_CTRL_TYPE_INTEGER,
-   .name   = Exposure,
-   .minimum= EXPOS_MIN_MS,
-   .maximum= EXPOS_MAX_MS,
-   .step   = 1,
-   .default_value  = 1,
-   }, {
-   }
-};
-
 /* supported resolutions */
 static const struct sr030pc30_frmsize sr030pc30_sizes[] = {
{
@@ -323,6 +286,11 @@ static inline struct sr030pc30_info *to_sr030pc30(struct 
v4l2_subdev *sd)
return container_of(sd, struct sr030pc30_info, sd);
 }
 
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+   return container_of(ctrl-handler, struct sr030pc30_info, hdl)-sd;
+}
+
 static inline int set_i2c_page(struct sr030pc30_info *info,
   struct i2c_client *client, unsigned int reg)
 {
@@ -395,59 +363,56 @@ static int sr030pc30_pwr_ctrl(struct v4l2_subdev *sd,
 
 static inline int sr030pc30_enable_autoexposure(struct v4l2_subdev *sd, int on)
 {
-   struct sr030pc30_info *info = to_sr030pc30(sd);
/* auto anti-flicker is also enabled here */
-   int ret = cam_i2c_write(sd, AE_CTL1_REG, on ? 0xDC : 0x0C);
-   if (!ret)
-   info-auto_exp = on;
-   return ret;
+   return cam_i2c_write(sd, AE_CTL1_REG, on ? 0xDC : 0x0C);
 }
 
 static int sr030pc30_set_exposure(struct v4l2_subdev *sd, int value)
 {
struct sr030pc30_info *info = to_sr030pc30(sd);
-
unsigned long expos = value * info-pdata-clk_rate / (8 * 1000);
+   int ret;
 
-   int ret = cam_i2c_write(sd, EXP_TIMEH_REG, expos  16  0xFF);
+   ret = cam_i2c_write(sd, EXP_TIMEH_REG,

[PATCH 3/3] sr030pc30: Add regulator framework support

Use the regulator API instead of the set_power callback.
Handle RESET and STANDBY gpio in the driver when needed.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/sr030pc30.c |  193 ++-
 include/media/sr030pc30.h   |   14 ++-
 2 files changed, 162 insertions(+), 45 deletions(-)

diff --git a/drivers/media/video/sr030pc30.c b/drivers/media/video/sr030pc30.c
index 1a195f0..940ac37 100644
--- a/drivers/media/video/sr030pc30.c
+++ b/drivers/media/video/sr030pc30.c
@@ -18,6 +18,8 @@
 
 #include linux/i2c.h
 #include linux/delay.h
+#include linux/gpio.h
+#include linux/regulator/consumer.h
 #include linux/slab.h
 #include media/v4l2-chip-ident.h
 #include media/v4l2-ctrls.h
@@ -141,6 +143,12 @@ module_param(debug, int, 0644);
 #define EXPOS_MIN_MS   1
 #define EXPOS_MAX_MS   125
 
+static const char * const sr030pc30_supply_name[] = {
+   vdd_core, vddio, vdda
+};
+
+#define SR030PC30_NUM_SUPPLIES ARRAY_SIZE(sr030pc30_supply_name)
+
 struct sr030pc30_info {
struct v4l2_subdev sd;
struct v4l2_ctrl_handler hdl;
@@ -160,7 +168,11 @@ struct sr030pc30_info {
const struct sr030pc30_platform_data *pdata;
const struct sr030pc30_format *curr_fmt;
const struct sr030pc30_frmsize *curr_win;
+   unsigned int power:1;
unsigned int sleep:1;
+   struct regulator_bulk_data supply[SR030PC30_NUM_SUPPLIES];
+   u32 gpio_nreset;
+   u32 gpio_nstby;
u8 i2c_reg_page;
 };
 
@@ -473,7 +485,7 @@ static int sr030pc30_s_ctrl(struct v4l2_ctrl *ctrl)
 
switch (ctrl-id) {
case V4L2_CID_AUTO_WHITE_BALANCE:
-   if (!ctrl-has_new)
+   if (!ctrl-is_new)
ctrl-val = 0;
 
ret = sr030pc30_enable_autowhitebalance(sd, ctrl-val);
@@ -487,7 +499,7 @@ static int sr030pc30_s_ctrl(struct v4l2_ctrl *ctrl)
return ret;
 
case V4L2_CID_EXPOSURE_AUTO:
-   if (!ctrl-has_new)
+   if (!ctrl-is_new)
ctrl-val = V4L2_EXPOSURE_MANUAL;
 
if (ctrl-val == V4L2_EXPOSURE_MANUAL)
@@ -622,9 +634,66 @@ static int sr030pc30_base_config(struct v4l2_subdev *sd)
return v4l2_ctrl_handler_setup(info-hdl);
 }
 
+static int sr030pc30_power_enable(struct sr030pc30_info *info)
+{
+   int ret;
+
+   if (info-power)
+   return 0;
+
+   if (gpio_is_valid(info-gpio_nstby))
+   gpio_set_value(info-gpio_nstby, 0);
+
+   if (gpio_is_valid(info-gpio_nreset))
+   gpio_set_value(info-gpio_nreset, 0);
+
+   ret = regulator_bulk_enable(SR030PC30_NUM_SUPPLIES, info-supply);
+   if (ret)
+   return ret;
+
+   if (gpio_is_valid(info-gpio_nreset)) {
+   msleep(50);
+   gpio_set_value(info-gpio_nreset, 1);
+   }
+   if (gpio_is_valid(info-gpio_nstby)) {
+   udelay(1000);
+   gpio_set_value(info-gpio_nstby, 1);
+   }
+   if (gpio_is_valid(info-gpio_nreset)) {
+   udelay(1000);
+   gpio_set_value(info-gpio_nreset, 0);
+   msleep(100);
+   gpio_set_value(info-gpio_nreset, 1);
+   msleep(20);
+   }
+
+   info-power = 1;
+   return 0;
+}
+
+static int sr030pc30_power_disable(struct sr030pc30_info *info)
+{
+   int ret;
+
+   if (!info-power)
+   return 0;
+
+   ret = regulator_bulk_disable(SR030PC30_NUM_SUPPLIES, info-supply);
+   if (ret)
+   return ret;
+
+   if (gpio_is_valid(info-gpio_nstby))
+   gpio_set_value(info-gpio_nstby, 0);
+
+   if (gpio_is_valid(info-gpio_nreset))
+   gpio_set_value(info-gpio_nreset, 0);
+
+   info-power = 0;
+   return 0;
+}
+
 static int sr030pc30_s_power(struct v4l2_subdev *sd, int on)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
struct sr030pc30_info *info = to_sr030pc30(sd);
const struct sr030pc30_platform_data *pdata = info-pdata;
int ret;
@@ -632,23 +701,15 @@ static int sr030pc30_s_power(struct v4l2_subdev *sd, int 
on)
if (WARN(pdata == NULL, No platform data!\n))
return -ENOMEM;
 
-   /*
-* Put sensor into power sleep mode before switching off
-* power and disabling MCLK.
-*/
-   if (!on)
-   sr030pc30_pwr_ctrl(sd, false, true);
-
-   /* set_power controls sensor's power and clock */
-   if (pdata-set_power) {
-   ret = pdata-set_power(client-dev, on);
+   /* Put sensor into power sleep mode before switching supply off. */
+   if (on) {
+   ret = sr030pc30_power_enable(info);
if (ret)
return ret;
-   }
-
-   if (on) {
ret = sr030pc30_base_config(sd);
} else {
+

RE: How to support MIPI CSI-2 controller in soc-camera framework?

2011-01-19 Thread Qing Xu

Hi,

(a general request: could you please configure your mailer to wrap
Lines at somewhere around 70 characters?)
very sorry for the un-convenience!

Thanks for your description! I could verify and try your way on our
CSI-2 driver.
Also, our another chip's camera controller support both MIPI and
traditional parallel(H_sync/V_sync) interface, we hope host can
negotiate with sensor on MIPI configure, as the sensor could be
parallel interface or MIPI interface, so I have a proposal as
follow:

in soc_camera.h, SOCAM_XXX defines all HW connection properties,
I thing MIPI(1/2/3/4 lanes) is also a kind of HW connection
property, and it is mutex with parallel properties(if sensor
support mipi connection, the HW signal has no parallel property
any more), once host controller find subdev support MIPI, it will
enable MIPI functional itself, and if subdev only support parallel,
it will enable parallel functional itself.
(you can find the proposal in the code which I have sent, refer to 
pxa955_cam_set_bus_param() in pxa955_cam.c, ov5642_query_bus_param
In ov5642.c)

--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
if (f == SOCAM_PCLK_SAMPLE_RISING || f == 
SOCAM_PCLK_SAMPLE_FALLING)
flags ^= SOCAM_PCLK_SAMPLE_RISING | 
SOCAM_PCLK_SAMPLE_FALLING;
}
+   if (icl-flags  SOCAM_MIPI) {
+   flags = SOCAM_MIPI | SOCAM_MIPI_1LANE | SOCAM_MIPI_2LANE
+   | SOCAM_MIPI_3LANE | SOCAM_MIPI_4LANE;
+   }

return flags;
 }

--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h

 #define SOCAM_DATA_ACTIVE_HIGH (1  14)
 #define SOCAM_DATA_ACTIVE_LOW  (1  15)

+#define SOCAM_MIPI (1  16)
+#define SOCAM_MIPI_1LANE   (1  17)
+#define SOCAM_MIPI_2LANE   (1  18)
+#define SOCAM_MIPI_3LANE   (1  19)
+#define SOCAM_MIPI_4LANE   (1  20)
+

 static inline unsigned long soc_camera_bus_param_compatible(
unsigned long camera_flags, unsigned long bus_flags)
 {
-   unsigned long common_flags, hsync, vsync, pclk, data, buswidth, mode;
+   unsigned long common_flags, hsync, vsync, pclk, data, buswidth, mode, 
mipi;

common_flags = camera_flags  bus_flags;

@@ -261,8 +267,10 @@ static inline unsigned long 
soc_camera_bus_param_compatible(
data = common_flags  (SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_LOW);
mode = common_flags  (SOCAM_MASTER | SOCAM_SLAVE);
buswidth = common_flags  SOCAM_DATAWIDTH_MASK;
+   mipi = common_flags  (SOCAM_MIPI | SOCAM_MIPI_1LANE | SOCAM_MIPI_2LANE
+   | SOCAM_MIPI_3LANE | 
SOCAM_MIPI_4LANE);

-   return (!hsync || !vsync || !pclk || !data || !mode || !buswidth) ? 0 :
+   return ((!hsync || !vsync || !pclk || !data || !mode || !buswidth)  
(!mipi)) ? 0 :
common_flags;
 }


-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: 2011年1月20日 0:20
To: Qing Xu
Cc: Laurent Pinchart; Linux Media Mailing List
Subject: Re: How to support MIPI CSI-2 controller in soc-camera framework?

(a general request: could you please configure your mailer to wrap lines
at somewhere around 70 characters?)

On Tue, 18 Jan 2011, Qing Xu wrote:

 Hi,

 Our chip support both MIPI and parallel interface. The HW connection logic is
 sensor(such as ov5642) - our MIPI controller(handle DPHY timing/ CSI-2
 things) - our camera controller (handle DMA transmitting/ fmt/ size
 things). Now, I find the driver of sh_mobile_csi2.c, it seems like a
 CSI-2 driver, but I don't quite understand how it works:
 1) how the host controller call into this driver?

This is a normal v4l2-subdev driver. Platform data for the
sh_mobile_ceu_camera driver provides a link to CSI2 driver data, then the
host driver loads the CSI2 driver, which then links itself into the
subdevice list. Look at arch/arm/mach-shmobile/board-ap4evb.c how the data
is linked:

static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
.flags = SH_CEU_FLAG_USE_8BIT_BUS,
.csi2_dev = csi2_device.dev,
};

and in the hosz driver drivers/media/video/sh_mobile_ceu_camera.c look in
the sh_mobile_ceu_probe function below the lines:

csi2 = pcdev-pdata-csi2_dev;
if (csi2) {
...


 2) how the host controller/sensor negotiate MIPI variable with this
 driver, such as D-PHY timing(hs_settle/hs_termen/clk_settle/clk_termen),
 number of lanes...?

Since I only had a limited number of MIPI setups, I haven't implemented
maximum flexibility. A part of the parameters is hard-coded, another part
is provided in the platform driver, yet another part is calculated
dynamically.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH v16 3/3] davinci vpbe: board specific additions

2011-01-19 Thread Kaspter Ju

Hi Robert,

On Thu, Jan 20, 2011 at 12:12 AM, Robert Mellen robert.mel...@gvimd.com wrote:
 Are the davinci vpbe patches specific only to the DM644x platform? I am
 developing on the DM365 and would like to use the OSD features implemented
 in the patches. Are there plans to port these patches to the DM365? Is it
 only a matter of changing the board-specific files, such as
 board-dm365-evm.c?

[snip]

AFAIK, these patches are DM644x platform specific, If you wanna use it
on DM365,you have to change all of this for DM365 not only the
board-specific files. Maybe this is on someone's queue.

Best Regards,
Kaspter.

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




-- 
Kaspter Ju
--
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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 3:08 PM, Jarod Wilson wrote:

 On Jan 19, 2011, at 12:43 PM, Jean Delvare wrote:
 
 Preliminary technical nitpicking: you can't actually pass two addresses
 in i2c_board_info, so the second address has to be passed as platform
 data.
 
 I am sorry if you expected an authoritative answer, but... both options
 are actually possible.
 
 If you use a single call to i2c_new_device(), you'll have a single
 i2c_client to start with, and you'll have to instantiate the second one
 in the probe function using i2c_new_dummy().
 
 If you instead decide to call i2c_new_device() twice, there will be two
 calls to the probe function (which can be the same one in a single
 driver, or two different ones in separate drivers, at your option.) If
 any synchronization is needed between the two i2c_clients, you have to
 use the bridge driver as a relay, as Andy proposed doing already.
 
 Really, both are possible, and the two options aren't that different in
 the end. I can't think of anything that can be done with one that
 couldn't be achieved with the other.
 
 Yeah, see my follow-up mail. The code in hdpvr-i2c.c is clearly a bit
 off now, and only worked in my testing, as at the time, I was using
 an older lirc_zilog from prior to Andy's changes that still used the
 old style binding and probing directly in the driver. I'm working on
 fixing up hdpvr-i2c further right now, and will do some more prodding
 with pvrusb2, the code for which looks correct with two i2c_new_device()
 calls in it, one for each address, so I just need to figure out why
 lirc_zilog is getting an -EIO trying to get tx brought up.

So as we were discussing on irc today, the -EIO is within lirc_zilog's
send_boot_data() function. The firmware is loaded, and then we send the
z8 a command to activate the firmware, immediately follow by an attempt
to read the firmware version. The z8 is still busy when we do that, and
throwing in a simple mdelay() remedies the problem for both the hvr-1950
and the hdpvr -- tried 100 initially, and all the way down to 20 still
worked, didn't try any lower.

And I definitely horked up the hdpvr i2c a bit, but have a follow-up
patch that goes back to doing the right thing with two i2c_new_device()
calls, which I've successfully tested with the latest lirc_zilog plus
mdelay patch.

Will post patches tomorrow though, its already past my bed time.

-- 
Jarod Wilson
ja...@wilsonet.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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

On Jan 19, 2011, at 11:45 PM, Jarod Wilson wrote:

 So as we were discussing on irc today, the -EIO is within lirc_zilog's
 send_boot_data() function. The firmware is loaded, and then we send the
 z8 a command to activate the firmware, immediately follow by an attempt
 to read the firmware version. The z8 is still busy when we do that, and
 throwing in a simple mdelay() remedies the problem for both the hvr-1950
 and the hdpvr -- tried 100 initially, and all the way down to 20 still
 worked, didn't try any lower.
 
 And I definitely horked up the hdpvr i2c a bit, but have a follow-up
 patch that goes back to doing the right thing with two i2c_new_device()
 calls, which I've successfully tested with the latest lirc_zilog plus
 mdelay patch.
 
 Will post patches tomorrow though, its already past my bed time.

D'oh. Forgot to mention: while lirc_zilog tx binds to the hvr-1950, it
doesn't actually work, I get -EIO when trying to transmit, iirc. So that
is on the list of things to poke at some tomorrow as well.

-- 
Jarod Wilson
ja...@wilsonet.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

[PATCH] [media] v4l: soc-camera: add enum-frame-size ioctl

2011-01-19 Thread Qing Xu

add vidioc_enum_framesizes implementation, follow default_g_parm()
and g_mbus_fmt() method

Signed-off-by: Qing Xu qi...@marvell.com
---
 drivers/media/video/soc_camera.c |   36 
 include/media/soc_camera.h   |1 +
 include/media/v4l2-subdev.h  |2 ++
 3 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 052bd6d..c89010a 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -145,6 +145,15 @@ static int soc_camera_s_std(struct file *file, void *priv, 
v4l2_std_id *a)
return v4l2_subdev_call(sd, core, s_std, *a);
 }
 
+static int soc_camera_enum_fsizes(struct file *file, void *fh,
+struct v4l2_frmsizeenum *fsize)
+{
+   struct soc_camera_device *icd = file-private_data;
+   struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+
+   return ici-ops-enum_fsizes(icd, fsize);
+}
+
 static int soc_camera_reqbufs(struct file *file, void *priv,
  struct v4l2_requestbuffers *p)
 {
@@ -1160,6 +1169,30 @@ static int default_s_parm(struct soc_camera_device *icd,
return v4l2_subdev_call(sd, video, s_parm, parm);
 }
 
+static int default_enum_fsizes(struct soc_camera_device *icd,
+ struct v4l2_frmsizeenum *fsize)
+{
+   int ret;
+   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+   const struct soc_camera_format_xlate *xlate;
+   __u32 pixfmt = fsize-pixel_format;
+   struct v4l2_frmsizeenum *fsize_mbus = fsize;
+
+   xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+   if (!xlate)
+   return -EINVAL;
+   /* map xlate-code to pixel_format, sensor only handle xlate-code*/
+   fsize_mbus-pixel_format = xlate-code;
+
+   ret = v4l2_subdev_call(sd, video, enum_mbus_fsizes, fsize_mbus);
+   if (ret  0)
+   return ret;
+
+   fsize-pixel_format = pixfmt;
+
+   return 0;
+}
+
 static void soc_camera_device_init(struct device *dev, void *pdata)
 {
dev-platform_data  = pdata;
@@ -1195,6 +1228,8 @@ int soc_camera_host_register(struct soc_camera_host *ici)
ici-ops-set_parm = default_s_parm;
if (!ici-ops-get_parm)
ici-ops-get_parm = default_g_parm;
+   if (!ici-ops-enum_fsizes)
+   ici-ops-enum_fsizes = default_enum_fsizes;
 
mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
@@ -1302,6 +1337,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops = 
{
.vidioc_g_input  = soc_camera_g_input,
.vidioc_s_input  = soc_camera_s_input,
.vidioc_s_std= soc_camera_s_std,
+   .vidioc_enum_framesizes  = soc_camera_enum_fsizes,
.vidioc_reqbufs  = soc_camera_reqbufs,
.vidioc_try_fmt_vid_cap  = soc_camera_try_fmt_vid_cap,
.vidioc_querybuf = soc_camera_querybuf,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 86e3631..6e4800c 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -85,6 +85,7 @@ struct soc_camera_host_ops {
int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
+   int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum 
*);
unsigned int (*poll)(struct file *, poll_table *);
const struct v4l2_queryctrl *controls;
int num_controls;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b0316a7..0d482c9 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -275,6 +275,8 @@ struct v4l2_subdev_video_ops {
struct v4l2_dv_timings *timings);
int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
 enum v4l2_mbus_pixelcode *code);
+   int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
+struct v4l2_frmsizeenum *fsize);
int (*g_mbus_fmt)(struct v4l2_subdev *sd,
  struct v4l2_mbus_framefmt *fmt);
int (*try_mbus_fmt)(struct v4l2_subdev *sd,
-- 
1.6.3.3

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

[PATCH] tm6000: add/rework reg.defines

2011-01-19 Thread Dmitri Belimov

Hi

Rework registers defines. Add TM6000 specific registers defines.
Add marks and comments for TM6010 specific registers.

diff --git a/drivers/staging/tm6000/tm6000-regs.h 
b/drivers/staging/tm6000/tm6000-regs.h
index 1f0ced8..5375a83 100644
--- a/drivers/staging/tm6000/tm6000-regs.h
+++ b/drivers/staging/tm6000/tm6000-regs.h
@@ -97,6 +97,34 @@ enum {
TM6000_URB_MSG_ERR,
 };
 
+/* Define specific TM6000 Video decoder registers */
+#define TM6000_REQ07_RD8_TEST_SEL  0x07, 0xd8
+#define TM6000_REQ07_RD9_A_SIM_SEL 0x07, 0xd9
+#define TM6000_REQ07_RDA_CLK_SEL   0x07, 0xda
+#define TM6000_REQ07_RDB_OUT_SEL   0x07, 0xdb
+#define TM6000_REQ07_RDC_NSEL_I2S  0x07, 0xdc
+#define TM6000_REQ07_RDD_GPIO2_MDRV0x07, 0xdd
+#define TM6000_REQ07_RDE_GPIO1_MDRV0x07, 0xde
+#define TM6000_REQ07_RDF_PWDOWN_ACLK   0x07, 0xdf
+#define TM6000_REQ07_RE0_VADC_REF_CTL  0x07, 0xe0
+#define TM6000_REQ07_RE1_VADC_DACLIMP  0x07, 0xe1
+#define TM6000_REQ07_RE2_VADC_STATUS_CTL   0x07, 0xe2
+#define TM6000_REQ07_RE3_VADC_INP_LPF_SEL1 0x07, 0xe3
+#define TM6000_REQ07_RE4_VADC_TARGET1  0x07, 0xe4
+#define TM6000_REQ07_RE5_VADC_INP_LPF_SEL2 0x07, 0xe5
+#define TM6000_REQ07_RE6_VADC_TARGET2  0x07, 0xe6
+#define TM6000_REQ07_RE7_VADC_AGAIN_CTL0x07, 0xe7
+#define TM6000_REQ07_RE8_VADC_PWDOWN_CTL   0x07, 0xe8
+#define TM6000_REQ07_RE9_VADC_INPUT_CTL1   0x07, 0xe9
+#define TM6000_REQ07_REA_VADC_INPUT_CTL2   0x07, 0xea
+#define TM6000_REQ07_REB_VADC_AADC_MODE0x07, 0xeb
+#define TM6000_REQ07_REC_VADC_AADC_LVOL0x07, 0xec
+#define TM6000_REQ07_RED_VADC_AADC_RVOL0x07, 0xed
+#define TM6000_REQ07_REE_VADC_CTRL_SEL_CONTROL 0x07, 0xee
+#define TM6000_REQ07_REF_VADC_GAIN_MAP_CTL 0x07, 0xef
+#define TM6000_REQ07_RFD_BIST_ERR_VST_LOW  0x07, 0xfd
+#define TM6000_REQ07_RFE_BIST_ERR_VST_HIGH 0x07, 0xfe
+
 /* Define TM6000/TM6010 Video decoder registers */
 #define TM6010_REQ07_R00_VIDEO_CONTROL00x07, 0x00
 #define TM6010_REQ07_R01_VIDEO_CONTROL10x07, 0x01
@@ -241,6 +269,7 @@ enum {
 #define TM6010_REQ07_RC9_VEND1 0x07, 0xc9
 #define TM6010_REQ07_RCA_VEND0 0x07, 0xca
 #define TM6010_REQ07_RCB_DELAY 0x07, 0xcb
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RCC_ACTIVE_VIDEO_IF   0x07, 0xcc
 #define TM6010_REQ07_RD0_USB_PERIPHERY_CONTROL 0x07, 0xd0
 #define TM6010_REQ07_RD1_ADDR_FOR_REQ1 0x07, 0xd1
@@ -250,32 +279,59 @@ enum {
 #define TM6010_REQ07_RD5_POWERSAVE 0x07, 0xd5
 #define TM6010_REQ07_RD6_ENDP_REQ1_REQ20x07, 0xd6
 #define TM6010_REQ07_RD7_ENDP_REQ3_REQ40x07, 0xd7
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR0x07, 0xd8
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR_BSIZE  0x07, 0xd9
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR_WAKEUP_SEL 0x07, 0xda
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR_WAKEUP_ADD 0x07, 0xdb
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR_LEADER10x07, 0xdc
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR_LEADER00x07, 0xdd
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR_PULSE_CNT1 0x07, 0xde
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RD8_IR_PULSE_CNT0 0x07, 0xdf
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE0_DVIDEO_SOURCE 0x07, 0xe0
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE0_DVIDEO_SOURCE_IF  0x07, 0xe1
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE2_OUT_SEL2  0x07, 0xe2
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE3_OUT_SEL1  0x07, 0xe3
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE4_OUT_SEL0  0x07, 0xe4
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE5_REMOTE_WAKEUP 0x07, 0xe5
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE7_PUB_GPIO  0x07, 0xe7
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE8_TYPESEL_MOS_I2S   0x07, 0xe8
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RE9_TYPESEL_MOS_TS0x07, 0xe9
+/* ONLY for TM6010 */
 #define TM6010_REQ07_REA_TYPESEL_MOS_CCIR  0x07, 0xea
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RF0_BIST_CRC_RESULT0  0x07, 0xf0
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RF1_BIST_CRC_RESULT1  0x07, 0xf1
+/* ONLY for TM6010 */
 #define TM6010_REQ07_RF2_BIST_CRC_RESULT2

Re: [PATCH] [media] v4l: soc-camera: add enum-frame-size ioctl

On Thu, 20 Jan 2011, Qing Xu wrote:

 add vidioc_enum_framesizes implementation, follow default_g_parm()
 and g_mbus_fmt() method
 
 Signed-off-by: Qing Xu qi...@marvell.com
 ---
  drivers/media/video/soc_camera.c |   36 
  include/media/soc_camera.h   |1 +
  include/media/v4l2-subdev.h  |2 ++
  3 files changed, 39 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/soc_camera.c 
 b/drivers/media/video/soc_camera.c
 index 052bd6d..c89010a 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c
 @@ -145,6 +145,15 @@ static int soc_camera_s_std(struct file *file, void 
 *priv, v4l2_std_id *a)
   return v4l2_subdev_call(sd, core, s_std, *a);
  }
  
 +static int soc_camera_enum_fsizes(struct file *file, void *fh,
 +  struct v4l2_frmsizeenum *fsize)
 +{
 + struct soc_camera_device *icd = file-private_data;
 + struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
 +
 + return ici-ops-enum_fsizes(icd, fsize);
 +}
 +
  static int soc_camera_reqbufs(struct file *file, void *priv,
 struct v4l2_requestbuffers *p)
  {
 @@ -1160,6 +1169,30 @@ static int default_s_parm(struct soc_camera_device 
 *icd,
   return v4l2_subdev_call(sd, video, s_parm, parm);
  }
  
 +static int default_enum_fsizes(struct soc_camera_device *icd,
 +   struct v4l2_frmsizeenum *fsize)
 +{
 + int ret;
 + struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
 + const struct soc_camera_format_xlate *xlate;
 + __u32 pixfmt = fsize-pixel_format;
 + struct v4l2_frmsizeenum *fsize_mbus = fsize;
 +
 + xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
 + if (!xlate)
 + return -EINVAL;
 + /* map xlate-code to pixel_format, sensor only handle xlate-code*/
 + fsize_mbus-pixel_format = xlate-code;
 +
 + ret = v4l2_subdev_call(sd, video, enum_mbus_fsizes, fsize_mbus);
 + if (ret  0)
 + return ret;
 +
 + fsize-pixel_format = pixfmt;

NAK. Please do it the way I suggested in my last email or explain why you 
think, it was wrong.

Guennadi

 +
 + return 0;
 +}
 +
  static void soc_camera_device_init(struct device *dev, void *pdata)
  {
   dev-platform_data  = pdata;
 @@ -1195,6 +1228,8 @@ int soc_camera_host_register(struct soc_camera_host 
 *ici)
   ici-ops-set_parm = default_s_parm;
   if (!ici-ops-get_parm)
   ici-ops-get_parm = default_g_parm;
 + if (!ici-ops-enum_fsizes)
 + ici-ops-enum_fsizes = default_enum_fsizes;
  
   mutex_lock(list_lock);
   list_for_each_entry(ix, hosts, list) {
 @@ -1302,6 +1337,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops 
 = {
   .vidioc_g_input  = soc_camera_g_input,
   .vidioc_s_input  = soc_camera_s_input,
   .vidioc_s_std= soc_camera_s_std,
 + .vidioc_enum_framesizes  = soc_camera_enum_fsizes,
   .vidioc_reqbufs  = soc_camera_reqbufs,
   .vidioc_try_fmt_vid_cap  = soc_camera_try_fmt_vid_cap,
   .vidioc_querybuf = soc_camera_querybuf,
 diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
 index 86e3631..6e4800c 100644
 --- a/include/media/soc_camera.h
 +++ b/include/media/soc_camera.h
 @@ -85,6 +85,7 @@ struct soc_camera_host_ops {
   int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
   int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
   int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
 + int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum 
 *);
   unsigned int (*poll)(struct file *, poll_table *);
   const struct v4l2_queryctrl *controls;
   int num_controls;
 diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
 index b0316a7..0d482c9 100644
 --- a/include/media/v4l2-subdev.h
 +++ b/include/media/v4l2-subdev.h
 @@ -275,6 +275,8 @@ struct v4l2_subdev_video_ops {
   struct v4l2_dv_timings *timings);
   int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
enum v4l2_mbus_pixelcode *code);
 + int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
 +  struct v4l2_frmsizeenum *fsize);
   int (*g_mbus_fmt)(struct v4l2_subdev *sd,
 struct v4l2_mbus_framefmt *fmt);
   int (*try_mbus_fmt)(struct v4l2_subdev *sd,
 -- 
 1.6.3.3
 

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

media_build: build fails against (ubuntu) 2.6.32 on pvrusb2-debugifc.c

2011-01-19 Thread Vincent McIntyre

Hi,

I am building against linux-2.6.32-26-generic from ubuntu, with just
the linux-headers package.

I know there is a big fat warning about doing this but I thought I
should report the issue
because mostly building like this does work.

The build was against a clean checkout of the media_build tree, using build.sh.

The build fails with:
  CC [M]  /home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-sysfs.o
  CC [M]  /home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.o
/home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.c:
In function 'debugifc_parse_unsigned_number':
/home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.c:108:
error: implicit declaration of function 'hex_to_bin'
make[3]: *** 
[/home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.o]
Error 1

I was able to get the build to complete by hand-editing v4l/config-compat.h
@@ -11,6 +11,8 @@

 #include linux/mmdebug.h

+#define NEED_HEX_TO_BIN 1
+
 #undef CONFIG_VIDEO_SH_VOU
 #undef CONFIG_VIDEO_SH_VOU_MODULE
 #undef CONFIG_MX1_VIDEO

and rerunning make.

After inspecting the relevant commit[1] I'm a bit baffled as to why
this occurred.
It seems as though the header file is not being found correctly,
although it does exist,
at /usr/src/linux-headers-2.6.32-26-generic/include/linux/kernel.h.

 % grep -i hex_to_bin
/usr/src/linux-headers-2.6.32-26-generic/include/linux/kernel.h
 %

I'll poke a bit more into this and hopefully come up with a fix.
Cheers
Vince

[1] 
http://git.linuxtv.org/media_build.git?a=commit;h=2f3b6a700ee9b687b59a1eda8f8336b9aa4c47a6
--
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] v4l: soc-camera: add enum-frame-size ioctl