date:20110107

Re: Memory sharing issue by application on V4L2 based device driver with system mmu.

2011-01-07 Thread Michel Dänzer

On Fre, 2011-01-07 at 11:17 +0900, InKi Dae wrote: 
 thank you for your comments.
 
 your second comment has no any problem as I said before, user virtual
 addess could be translated in page unit. but the problem, as you said,
 is that when cpu access to the memory in user mode, the memory
 allocated by malloc, page fault occurs so we can't find pfn to user
 virtual address. I missed that. but I think we could resolve this one.
 
 as before, user application allocates memory through malloc function
 and then send it to device driver(using userptr feature). if the pfn
 is null when device driver translated user virtual address in page
 unit then it allocates phsical memory in page unit using some
 interface such as alloc_page() and then mapping them. when pfn is
 null, to check it and allocate physical memory in page unit could be
 processed by videobuf2.
 
 of course, videobuf2 has no any duty considered for system mmu. so
 videobuf2 just provides callback for 3rd party and any platform with
 system mmu such as Samsung SoC C210 implements the function(allocating
 physical memory and mapping it) and registers it to callback of
 videobuf2. by doing so, I think your first comment could be cleared.

FWIW, TTM (drivers/gpu/drm/ttm, include/drm/ttm) is designed and used
for managing memory between CPU/GPU and kernel/userspace access. I
haven't looked at your requirements in detail, but if you haven't looked
at TTM yet, it sounds like it might be worth a look.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
--
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] Use the control framework in various subdevs

2011-01-07 Thread Hans Verkuil

Hi Mauro,

On Friday, December 31, 2010 14:36:59 Hans Verkuil wrote:
 This is a pull request for a subset of the RFC patch series I posted almost
 three weeks ago.

Please don't merge this yet. While testing the ov7670 driver I came across
some issues that may affect some drivers in this patch series as well. I need
to do some more debugging and testing to verify whether this patch series can
go ahead or not. I'll get back to you on this once I know more.

Regards,

Hans

 The only change is cx18 where Andy Walls pointed out some bugs. The same bugs
 were introduced in cx25840 and Andy's fixes for those had to be applied as 
 well
 in cx18 for the AV core.
 
 I dropped tvaudio, tda7432, tda9875 and ov7670 for now since these need more
 testing.
 
 This has been tested with the vivi, cx18, em28xx and vpif_capture/vpif_display
 drivers.
 
 Regards,
 
   Hans
 
 The following changes since commit 187134a5875df20356f4dca075db29f294115a47:
   David Henningsson (1):
 [media] DVB: IR support for TechnoTrend CT-3650
 
 are available in the git repository at:
 
   ssh://linuxtv.org/git/hverkuil/media_tree.git subdev-ctrl1
 
 Hans Verkuil (11):
   cs5345: use the control framework
   cx18: Use the control framework.
   adv7343: use control framework
   bt819: use control framework
   saa7110: use control framework
   tlv320aic23b: use control framework
   tvp514x: use the control framework
   tvp5150: use the control framework
   vpx3220: use control framework
   tvp7002: use control framework
   vivi: convert to the control framework and add test controls.
 
  drivers/media/video/adv7343.c|  167 +++---
  drivers/media/video/adv7343_regs.h   |8 +-
  drivers/media/video/bt819.c  |  129 +-
  drivers/media/video/cs5345.c |   87 ++---
  drivers/media/video/cx18/cx18-av-audio.c |   92 ++-
  drivers/media/video/cx18/cx18-av-core.c  |  175 ---
  drivers/media/video/cx18/cx18-av-core.h  |   12 +-
  drivers/media/video/cx18/cx18-controls.c |  285 
 --
  drivers/media/video/cx18/cx18-controls.h |7 +-
  drivers/media/video/cx18/cx18-driver.c   |   30 ++--
  drivers/media/video/cx18/cx18-driver.h   |2 +-
  drivers/media/video/cx18/cx18-fileops.c  |   32 +---
  drivers/media/video/cx18/cx18-ioctl.c|   24 +--
  drivers/media/video/cx18/cx18-mailbox.c  |5 +-
  drivers/media/video/cx18/cx18-mailbox.h  |5 -
  drivers/media/video/cx18/cx18-streams.c  |   16 +-
  drivers/media/video/saa7110.c|  115 +---
  drivers/media/video/tlv320aic23b.c   |   74 +---
  drivers/media/video/tvp514x.c|  236 ++---
  drivers/media/video/tvp5150.c|  157 +
  drivers/media/video/tvp7002.c|  117 +
  drivers/media/video/vivi.c   |  228 +++-
  drivers/media/video/vpx3220.c|  137 ++-
  23 files changed, 773 insertions(+), 1367 deletions(-)
 
 
 

-- 
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: Memory sharing issue by application on V4L2 based device driver with system mmu.

2011-01-07 Thread daeinki


Michel Dänzer 쓴 글:
On Fre, 2011-01-07 at 11:17 +0900, InKi Dae wrote: 

thank you for your comments.

your second comment has no any problem as I said before, user virtual
addess could be translated in page unit. but the problem, as you said,
is that when cpu access to the memory in user mode, the memory
allocated by malloc, page fault occurs so we can't find pfn to user
virtual address. I missed that. but I think we could resolve this one.

as before, user application allocates memory through malloc function
and then send it to device driver(using userptr feature). if the pfn
is null when device driver translated user virtual address in page
unit then it allocates phsical memory in page unit using some
interface such as alloc_page() and then mapping them. when pfn is
null, to check it and allocate physical memory in page unit could be
processed by videobuf2.

of course, videobuf2 has no any duty considered for system mmu. so
videobuf2 just provides callback for 3rd party and any platform with
system mmu such as Samsung SoC C210 implements the function(allocating
physical memory and mapping it) and registers it to callback of
videobuf2. by doing so, I think your first comment could be cleared.


FWIW, TTM (drivers/gpu/drm/ttm, include/drm/ttm) is designed and used
for managing memory between CPU/GPU and kernel/userspace access. I
haven't looked at your requirements in detail, but if you haven't looked
at TTM yet, it sounds like it might be worth a look.



Thank you for your advice. I would look at TTM driver.
--
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] Use the control framework in various subdevs

2011-01-07 Thread Hans Verkuil

On Friday, January 07, 2011 10:49:30 Hans Verkuil wrote:
 Hi Mauro,
 
 On Friday, December 31, 2010 14:36:59 Hans Verkuil wrote:
  This is a pull request for a subset of the RFC patch series I posted almost
  three weeks ago.
 
 Please don't merge this yet. While testing the ov7670 driver I came across
 some issues that may affect some drivers in this patch series as well. I need
 to do some more debugging and testing to verify whether this patch series can
 go ahead or not. I'll get back to you on this once I know more.

OK, this patch series is fine. The specific issues I had with ov7670 do not
apply here.

So this patch series is OK to merge.

Regards,

Hans

 
 Regards,
 
   Hans
 
  The only change is cx18 where Andy Walls pointed out some bugs. The same 
  bugs
  were introduced in cx25840 and Andy's fixes for those had to be applied as 
  well
  in cx18 for the AV core.
  
  I dropped tvaudio, tda7432, tda9875 and ov7670 for now since these need more
  testing.
  
  This has been tested with the vivi, cx18, em28xx and 
  vpif_capture/vpif_display
  drivers.
  
  Regards,
  
  Hans
  
  The following changes since commit 187134a5875df20356f4dca075db29f294115a47:
David Henningsson (1):
  [media] DVB: IR support for TechnoTrend CT-3650
  
  are available in the git repository at:
  
ssh://linuxtv.org/git/hverkuil/media_tree.git subdev-ctrl1
  
  Hans Verkuil (11):
cs5345: use the control framework
cx18: Use the control framework.
adv7343: use control framework
bt819: use control framework
saa7110: use control framework
tlv320aic23b: use control framework
tvp514x: use the control framework
tvp5150: use the control framework
vpx3220: use control framework
tvp7002: use control framework
vivi: convert to the control framework and add test controls.
  
   drivers/media/video/adv7343.c|  167 +++---
   drivers/media/video/adv7343_regs.h   |8 +-
   drivers/media/video/bt819.c  |  129 +-
   drivers/media/video/cs5345.c |   87 ++---
   drivers/media/video/cx18/cx18-av-audio.c |   92 ++-
   drivers/media/video/cx18/cx18-av-core.c  |  175 ---
   drivers/media/video/cx18/cx18-av-core.h  |   12 +-
   drivers/media/video/cx18/cx18-controls.c |  285 
  --
   drivers/media/video/cx18/cx18-controls.h |7 +-
   drivers/media/video/cx18/cx18-driver.c   |   30 ++--
   drivers/media/video/cx18/cx18-driver.h   |2 +-
   drivers/media/video/cx18/cx18-fileops.c  |   32 +---
   drivers/media/video/cx18/cx18-ioctl.c|   24 +--
   drivers/media/video/cx18/cx18-mailbox.c  |5 +-
   drivers/media/video/cx18/cx18-mailbox.h  |5 -
   drivers/media/video/cx18/cx18-streams.c  |   16 +-
   drivers/media/video/saa7110.c|  115 +---
   drivers/media/video/tlv320aic23b.c   |   74 +---
   drivers/media/video/tvp514x.c|  236 ++---
   drivers/media/video/tvp5150.c|  157 +
   drivers/media/video/tvp7002.c|  117 +
   drivers/media/video/vivi.c   |  228 +++-
   drivers/media/video/vpx3220.c|  137 ++-
   23 files changed, 773 insertions(+), 1367 deletions(-)
  
  
  
 
 

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

pctv452e driver status

2011-01-07 Thread Davide Cavalca

Hi,

I've managed to make my TechnoTrend TT-connect S2-3650 CI work using the
pctv452e driver from s2-lipianin on 2.6.35.10. It runs fine (both
regular and HD channels), but there are some minor issues:
- vdr-femon always reports a very low signal strenght (between 0 and
2%), I guess the driver is reporting an incorrect value
- about 1 out of 3 remote control key press is reported twice (I'm using
vdr-remote for it)
I haven't managed to test the CI part yet as I don't have any CI module
handy.

Are there any plans to merge this driver in the media tree and/or
eventually push it to the kernel?

Thanks,
Davide
--
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] new_build.git - avoid failing on 'rm' of nonexistent file

2011-01-07 Thread Vincent McIntyre

While attempting to build recently I have found the 'make distclean'
target fails if 'rm' tries to remove a file that is not there. The
attached patch fixes the issue for me (by using rm -f).
I converted all the other 'rm' calls to 'rm -f' along the way.

Please consider applying this.

Cheers
Vince
diff --git a/linux/Makefile b/linux/Makefile
index 695dcf2..8bbeee8 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -53,7 +52,7 @@ help:
 
 todaytar:
 	@if [ $(DIR) =  ]; then echo make $@ DIR=version; exit -1; fi
-	-rm $(PWD)/$(TODAY_TAR).bz2
+	-rm -f $(PWD)/$(TODAY_TAR).bz2
 	tar cf $(PWD)/$(TODAY_TAR) -C $(DIR) $(TARFILES)
 	-git --git-dir $(DIR)/.git log --pretty=oneline HEAD^1^1^1^1^1^1^1^1..HEAD git_log
 	tar rvf $(PWD)/linux-media.tar git_log
@@ -70,7 +69,7 @@ todaytar:
 
 tar:
 	@if [ $(DIR) =  ]; then echo make $@ DIR=version; exit -1; fi
-	-rm $(PWD)/linux-media.tar.bz2
+	-rm -f $(PWD)/linux-media.tar.bz2
 	tar cf $(PWD)/linux-media.tar -C $(DIR) $(TARFILES)
 	-git --git-dir $(DIR)/.git log --pretty=oneline HEAD^1^1^1^1^1^1^1^1..HEAD git_log
 	tar rvf $(PWD)/linux-media.tar git_log
@@ -97,7 +96,7 @@ dir: clean
 	./use_dir.pl $(DIR)
 
 distclean: clean
-	-rm linux-media.tar.bz2 linux-media.tar.bz2.md5
+	-rm -f linux-media.tar.bz2 linux-media.tar.bz2.md5
 
 apply_patches apply-patches:
 	@if [ -e .linked_dir ]; then ./use_dir.pl --recheck --silent; fi
@@ -131,7 +130,7 @@ apply_patches apply-patches:
 	mv .patches_applied .patches_applied.old; \
 	echo #$$dir  .patches_applied; \
 	cat .patches_applied.old  .patches_applied; \
-	rm .patches_applied.old; \
+	rm -f .patches_applied.old; \
 	if [ -e .linked_dir ]; then ./use_dir.pl --get_patched; fi
 
 unapply_patches unapply-patches:
@@ -141,7 +140,7 @@ unapply_patches unapply-patches:
 		echo patch -s -f -R -p1 -i ../backports/$$i; \
 		patch -s -f -R -p1 -i ../backports/$$i || break; \
 	done; \
-	rm .patches_applied; fi
+	rm -f .patches_applied; fi
 
 download:
 	wget $(LATEST_TAR_MD5) -O linux-media.tar.bz2.md5.tmp

[patch] new_build.git - drop videodev.h

2011-01-07 Thread Vincent McIntyre

'make tar' fails for me (building against ubuntu 2.6.32) unless I
remove videodev.h from TARFILES.

Is this the correct thing to do here?

diff --git a/linux/Makefile b/linux/Makefile
index 695dcf2..8bbeee8 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -20,7 +20,6 @@ TARDIR += include/media/
 TARDIR += include/linux/dvb/
 TARFILES += include/linux/usb/video.h
 TARFILES += include/linux/i2c-id.h
-TARFILES += include/linux/videodev.h
 TARFILES += include/linux/ivtv.h
 TARFILES += include/linux/mmc/sdio_ids.h
 TARFILES += include/linux/ivtvfb.h

Cheers
Vince
--
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] Corrections to dvb-apps util/scan/dvb-c/de-neftv

2011-01-07 Thread Christoph Pfister

2011/1/6 Michael Meier poempel...@mulder.franken.de:
 The scan config for de-neftv seems to be outdated: It is missing some
 channels, and (more importantly) has incorrect settings for some other
 channels, as their settings differ a little from the rest [*].
 The following patch fixes that (and, at least for me, allows reception
 on these channels to finally work).

 Signed-off-by: Michael Meier poempel...@mulder.franken.de

 [*] src: http://www.herzomedia.de/front_content.php?idcat=126 - This
 requires a little explanation: herzomedia is not the same as neftv, but
 takes over their signal; neftv itself unfortunately doesn't provide
 proper information on symbolrate/qam used, which is why I have to resort
 to herzomedia. The 466 MHz transponder is supplemented by herzomedia, it
 is not available on neftv - I propose including it anyways, as apart
 from the additional channel they are the same.
snip

Applied, thanks.

Christoph
--
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] av7110: make array offset unsigned

2011-01-07 Thread Andreas Oberritter

On 01/06/2011 08:41 PM, Dan Carpenter wrote:
 In the CA_GET_SLOT_INFO ioctl, we only check whether num is too large,
 but we don't check if it's negative.
 
 drivers/media/dvb/ttpci/av7110_ca.c
278ca_slot_info_t *info=(ca_slot_info_t *)parg;
279
280if (info-num  1)
281return -EINVAL;
282av7110-ci_slot[info-num].num = info-num;
 
 Let's just make it unsigned.
 
 Signed-off-by: Dan Carpenter erro...@gmail.com

Nack. You're changing an interface to userspace. Please add a check to
av7110_ca.c instead.

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

[RFC PATCH 0/5] Use control framework in cafe_ccic and s_config removal

2011-01-07 Thread Hans Verkuil

Hi Jon, Laurent,

This patch series converts the OLPC cafe_ccic driver to the new control
framework. It turned out that this depended on the removal of the legacy
s_config subdev operation. I originally created the ov7670 controls in
s_config, but it turned out that s_config is called after 
v4l2_device_register_subdev,
so v4l2_device_register_subdev is unable to 'inherit' the ov7670 controls
in cafe_ccic since there aren't any yet.

Another reason why s_config is a bad idea.

So the first patch removes s_config and v4l2_i2c_new_subdev_cfg and converts
any users (cafe_ccic/ov7670 among them) to v4l2_i2c_new_subdev_board, which is
what God (i.e. Jean Delvare) intended. :-)

The second patch adds the (un)register internal ops allowing subdev drivers to
do some work after the subdevice is registered with a v4l2_device. So here the
sd-v4l2_dev pointer is set. Laurent, is this sufficient for the upcoming omap3
sub-devices?

The third patch fixes a small bug in v4l2_ctrl_handler_setup() that is required
for the ov7670 conversion. This bug does not affect any existing drivers.

The last two patches convert ov7670 and cafe_ccic to the V4L2 control framework.

This saves over a 100 lines of code and adds full support of the control API
(including extended controls) to the drivers.

This has been extensively tested on my humble OLPC laptop (and it took me 4-5
hours just to get the damn thing up and running with these drivers).

Special attention was given to the handling of gain/autogain and
exposure/autoexposure.

The way this works is that setting the gain on its own will turn off autogain
(this conforms to the current behavior of ov7670), setting autogain and gain
atomically will only set the gain if autogain is set to manual.

Ditto for exposure/autoexposure.

The only question is: is the current behavior of implicitly turning off autogain
when setting a new gain value correct? I think setting the gain in that case
should do nothing.

On the other hand, I don't know if there is any code that depends on this
behavior, so perhaps we should just leave it as is.

Jon, can you take a look and let me know if it is OK with you?

Regards,

Hans

 ov7670.c |  296 ---
 1 file changed, 116 insertions(+), 180 deletions(-)
 cafe_ccic.c |   59 +++
 1 file changed, 11 insertions(+), 48 deletions(-)

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

[RFC PATCH 3/5] v4l2-ctrls: v4l2_ctrl_handler_setup must set has_new to 1

2011-01-07 Thread Hans Verkuil

Drivers can use the has_new field to determine if a new value was specified
for a control. The v4l2_ctrl_handler_setup() must always set this to 1 since
the setup has to force a full update of all controls.

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/v4l2-ctrls.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 8f81efc..64f56bb 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1280,8 +1280,10 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler 
*hdl)
if (ctrl-done)
continue;
 
-   for (i = 0; i  master-ncontrols; i++)
+   for (i = 0; i  master-ncontrols; i++) {
cur_to_new(master-cluster[i]);
+   master-cluster[i]-has_new = 1;
+   }
 
/* Skip button controls and read-only controls. */
if (ctrl-type == V4L2_CTRL_TYPE_BUTTON ||
-- 
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

[RFC PATCH 1/5] v4l2-subdev: remove core.s_config and v4l2_i2c_new_subdev_cfg()

2011-01-07 Thread Hans Verkuil

The core.s_config op was meant for legacy drivers that needed to work with old
pre-2.6.26 kernels. This is no longer relevant. Unfortunately, this op was
incorrectly called from several drivers.

Replace those occurences with proper i2c_board_info structs and call
v4l2_i2c_new_subdev_board.

After these changes v4l2_i2c_new_subdev_cfg() was no longer used, so remove
that function as well.

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/cafe_ccic.c|   11 +++-
 drivers/media/video/cx25840/cx25840-core.c |   22 ++--
 drivers/media/video/em28xx/em28xx-cards.c  |   18 ---
 drivers/media/video/ivtv/ivtv-i2c.c|9 +++-
 drivers/media/video/mt9v011.c  |   29 ---
 drivers/media/video/mt9v011.h  |   36 -
 drivers/media/video/mt9v011_regs.h |   36 +
 drivers/media/video/ov7670.c   |   74 
 drivers/media/video/sr030pc30.c|   10 
 drivers/media/video/v4l2-common.c  |   19 +--
 include/media/mt9v011.h|   17 ++
 include/media/v4l2-common.h|   13 +-
 include/media/v4l2-subdev.h|6 +--
 13 files changed, 130 insertions(+), 170 deletions(-)
 delete mode 100644 drivers/media/video/mt9v011.h
 create mode 100644 drivers/media/video/mt9v011_regs.h
 create mode 100644 include/media/mt9v011.h

diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
index 789087c..7488b47 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/cafe_ccic.c
@@ -2001,6 +2001,11 @@ static int cafe_pci_probe(struct pci_dev *pdev,
.min_width = 320,
.min_height = 240,
};
+   struct i2c_board_info ov7670_info = {
+   .type = ov7670,
+   .addr = 0x42,
+   .platform_data = sensor_cfg,
+   };
 
/*
 * Start putting together one of our big camera structures.
@@ -2062,9 +2067,9 @@ static int cafe_pci_probe(struct pci_dev *pdev,
if (dmi_check_system(olpc_xo1_dmi))
sensor_cfg.clock_speed = 45;
 
-   cam-sensor_addr = 0x42;
-   cam-sensor = v4l2_i2c_new_subdev_cfg(cam-v4l2_dev, cam-i2c_adapter,
-   ov7670, 0, sensor_cfg, cam-sensor_addr, NULL);
+   cam-sensor_addr = ov7670_info.addr;
+   cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev, 
cam-i2c_adapter,
+   ov7670_info, NULL);
if (cam-sensor == NULL) {
ret = -ENODEV;
goto out_smbus;
diff --git a/drivers/media/video/cx25840/cx25840-core.c 
b/drivers/media/video/cx25840/cx25840-core.c
index dfb198d..9b384ac 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1682,20 +1682,6 @@ static int cx25840_log_status(struct v4l2_subdev *sd)
return 0;
 }
 
-static int cx25840_s_config(struct v4l2_subdev *sd, int irq, void 
*platform_data)
-{
-   struct cx25840_state *state = to_state(sd);
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-
-   if (platform_data) {
-   struct cx25840_platform_data *pdata = platform_data;
-
-   state-pvr150_workaround = pdata-pvr150_workaround;
-   set_input(client, state-vid_input, state-aud_input);
-   }
-   return 0;
-}
-
 static int cx23885_irq_handler(struct v4l2_subdev *sd, u32 status,
   bool *handled)
 {
@@ -1787,7 +1773,6 @@ static const struct v4l2_ctrl_ops cx25840_ctrl_ops = {
 
 static const struct v4l2_subdev_core_ops cx25840_core_ops = {
.log_status = cx25840_log_status,
-   .s_config = cx25840_s_config,
.g_chip_ident = cx25840_g_chip_ident,
.g_ctrl = v4l2_subdev_g_ctrl,
.s_ctrl = v4l2_subdev_s_ctrl,
@@ -1974,7 +1959,6 @@ static int cx25840_probe(struct i2c_client *client,
state-vid_input = CX25840_COMPOSITE7;
state-aud_input = CX25840_AUDIO8;
state-audclk_freq = 48000;
-   state-pvr150_workaround = 0;
state-audmode = V4L2_TUNER_MODE_LANG1;
state-vbi_line_offset = 8;
state-id = id;
@@ -2019,6 +2003,12 @@ static int cx25840_probe(struct i2c_client *client,
v4l2_ctrl_cluster(2, state-volume);
v4l2_ctrl_handler_setup(state-hdl);
 
+   if (client-dev.platform_data) {
+   struct cx25840_platform_data *pdata = client-dev.platform_data;
+
+   state-pvr150_workaround = pdata-pvr150_workaround;
+   }
+
cx25840_ir_probe(sd);
return 0;
 }
diff --git a/drivers/media/video/em28xx/em28xx-cards.c 
b/drivers/media/video/em28xx/em28xx-cards.c
index 8af302b..2822aeb 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -33,6 +33,7 @@
 #include media/saa7115.h
 #include media/tvp5150.h
 #include media/tvaudio.h
+#include media/mt9v011.h

[RFC PATCH 2/5] v4l2-subdev: add (un)register internal ops

2011-01-07 Thread Hans Verkuil

Some subdevs need to call into the board code after they are registered
and have a valid struct v4l2_device pointer. The s_config op was abused
for this, but now that it is removed we need a cleaner way of solving this.

So this patch adds a struct with internal ops that the v4l2 core can call.

Currently only two ops exist: register and unregister. Subdevs can implement
these to call the board code and pass it the v4l2_device pointer, which the
board code can then use to get access to the struct that embeds the
v4l2_device.

It is expected that in the future open and close ops will also be added.

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/v4l2-device.c |4 
 include/media/v4l2-subdev.h   |   17 +
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-device.c 
b/drivers/media/video/v4l2-device.c
index 7fe6f92..0780c32 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -131,6 +131,8 @@ int v4l2_device_register_subdev(struct v4l2_device 
*v4l2_dev,
if (err)
return err;
sd-v4l2_dev = v4l2_dev;
+   if (sd-internal_ops  sd-internal_ops-registered)
+   sd-internal_ops-registered(sd);
spin_lock(v4l2_dev-lock);
list_add_tail(sd-list, v4l2_dev-subdevs);
spin_unlock(v4l2_dev-lock);
@@ -146,6 +148,8 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev *sd)
spin_lock(sd-v4l2_dev-lock);
list_del(sd-list);
spin_unlock(sd-v4l2_dev-lock);
+   if (sd-internal_ops  sd-internal_ops-unregistered)
+   sd-internal_ops-unregistered(sd);
sd-v4l2_dev = NULL;
module_put(sd-owner);
 }
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 42fbe46..f559562 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -411,6 +411,21 @@ struct v4l2_subdev_ops {
const struct v4l2_subdev_sensor_ops *sensor;
 };
 
+/*
+ * Internal ops. Never call this from drivers, only the v4l2 framework can call
+ * these ops.
+ *
+ * registered: called when this subdev is registered. When called the v4l2_dev
+ * field is set to the correct v4l2_device.
+ *
+ * unregistered: called when this subdev is unregistered. When called the
+ * v4l2_dev field is still set to the correct v4l2_device.
+ */
+struct v4l2_subdev_internal_ops {
+   int (*registered)(struct v4l2_subdev *sd);
+   int (*unregistered)(struct v4l2_subdev *sd);
+};
+
 #define V4L2_SUBDEV_NAME_SIZE 32
 
 /* Set this flag if this subdev is a i2c device. */
@@ -427,6 +442,8 @@ struct v4l2_subdev {
u32 flags;
struct v4l2_device *v4l2_dev;
const struct v4l2_subdev_ops *ops;
+   /* Never call these internal ops from within a driver! */
+   const struct v4l2_subdev_internal_ops *internal_ops;
/* The control handler of this subdev. May be NULL. */
struct v4l2_ctrl_handler *ctrl_handler;
/* name must be unique */
-- 
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

[RFC PATCH 5/5] cafe_ccic: implement the control framework.

2011-01-07 Thread Hans Verkuil

And also swapped the out_free and out_unreg labels as they were in the
wrong order.

Tested with the OLPC laptop.

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/cafe_ccic.c |   59 +++---
 1 files changed, 11 insertions(+), 48 deletions(-)

diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
index 7488b47..44ec342 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/cafe_ccic.c
@@ -35,6 +35,7 @@
 #include linux/slab.h
 #include media/v4l2-device.h
 #include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
 #include media/v4l2-chip-ident.h
 #include linux/device.h
 #include linux/wait.h
@@ -145,6 +146,7 @@ struct cafe_sio_buffer {
 struct cafe_camera
 {
struct v4l2_device v4l2_dev;
+   struct v4l2_ctrl_handler ctrl_handler;
enum cafe_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users;  /* How many open FDs */
@@ -1466,48 +1468,6 @@ static unsigned int cafe_v4l_poll(struct file *filp,
 
 
 
-static int cafe_vidioc_queryctrl(struct file *filp, void *priv,
-   struct v4l2_queryctrl *qc)
-{
-   struct cafe_camera *cam = priv;
-   int ret;
-
-   mutex_lock(cam-s_mutex);
-   ret = sensor_call(cam, core, queryctrl, qc);
-   mutex_unlock(cam-s_mutex);
-   return ret;
-}
-
-
-static int cafe_vidioc_g_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct cafe_camera *cam = priv;
-   int ret;
-
-   mutex_lock(cam-s_mutex);
-   ret = sensor_call(cam, core, g_ctrl, ctrl);
-   mutex_unlock(cam-s_mutex);
-   return ret;
-}
-
-
-static int cafe_vidioc_s_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct cafe_camera *cam = priv;
-   int ret;
-
-   mutex_lock(cam-s_mutex);
-   ret = sensor_call(cam, core, s_ctrl, ctrl);
-   mutex_unlock(cam-s_mutex);
-   return ret;
-}
-
-
-
-
-
 static int cafe_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
 {
@@ -1792,9 +1752,6 @@ static const struct v4l2_ioctl_ops cafe_v4l_ioctl_ops = {
.vidioc_dqbuf   = cafe_vidioc_dqbuf,
.vidioc_streamon= cafe_vidioc_streamon,
.vidioc_streamoff   = cafe_vidioc_streamoff,
-   .vidioc_queryctrl   = cafe_vidioc_queryctrl,
-   .vidioc_g_ctrl  = cafe_vidioc_g_ctrl,
-   .vidioc_s_ctrl  = cafe_vidioc_s_ctrl,
.vidioc_g_parm  = cafe_vidioc_g_parm,
.vidioc_s_parm  = cafe_vidioc_s_parm,
.vidioc_enum_framesizes = cafe_vidioc_enum_framesizes,
@@ -2031,6 +1988,10 @@ static int cafe_pci_probe(struct pci_dev *pdev,
INIT_LIST_HEAD(cam-sb_avail);
INIT_LIST_HEAD(cam-sb_full);
tasklet_init(cam-s_tasklet, cafe_frame_tasklet, (unsigned long) cam);
+   ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+   if (ret)
+   goto out_unreg;
+   cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
/*
 * Get set up on the PCI bus.
 */
@@ -2087,10 +2048,10 @@ static int cafe_pci_probe(struct pci_dev *pdev,
cam-vdev.debug = 0;
 /* cam-vdev.debug = V4L2_DEBUG_IOCTL_ARG;*/
cam-vdev.v4l2_dev = cam-v4l2_dev;
+   video_set_drvdata(cam-vdev, cam);
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out_unlock;
-   video_set_drvdata(cam-vdev, cam);
 
/*
 * If so requested, try to get our DMA buffers now.
@@ -2113,9 +2074,10 @@ out_freeirq:
free_irq(pdev-irq, cam);
 out_iounmap:
pci_iounmap(pdev, cam-regs);
-out_free:
-   v4l2_device_unregister(cam-v4l2_dev);
 out_unreg:
+   v4l2_ctrl_handler_free(cam-ctrl_handler);
+   v4l2_device_unregister(cam-v4l2_dev);
+out_free:
kfree(cam);
 out:
return ret;
@@ -2154,6 +2116,7 @@ static void cafe_pci_remove(struct pci_dev *pdev)
if (cam-users  0)
cam_warn(cam, Removing a device with users!\n);
cafe_shutdown(cam);
+   v4l2_ctrl_handler_free(cam-ctrl_handler);
v4l2_device_unregister(cam-v4l2_dev);
kfree(cam);
 /* No unlock - it no longer exists */
-- 
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

[RFC PATCH 4/5] ov7670: use the control framework

2011-01-07 Thread Hans Verkuil

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/ov7670.c |  296 -
 1 files changed, 116 insertions(+), 180 deletions(-)

diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index d4e7c11..4da8b62 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,6 +19,7 @@
 #include media/v4l2-device.h
 #include media/v4l2-chip-ident.h
 #include media/v4l2-mediabus.h
+#include media/v4l2-ctrls.h
 
 #include ov7670.h
 
@@ -191,9 +192,23 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+   struct v4l2_ctrl_handler hdl;
+   struct {
+   /* gain cluster */
+   struct v4l2_ctrl *auto_gain;
+   struct v4l2_ctrl *gain;
+   };
+   struct {
+   /* exposure cluster */
+   struct v4l2_ctrl *auto_exposure;
+   struct v4l2_ctrl *exposure;
+   };
+   struct {
+   /* saturation/hue cluster */
+   struct v4l2_ctrl *saturation;
+   struct v4l2_ctrl *hue;
+   };
struct ov7670_format_struct *fmt;  /* Current format */
-   unsigned char sat;  /* Saturation value */
-   int hue;/* Hue value */
int min_width;  /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -206,6 +221,11 @@ static inline struct ov7670_info *to_state(struct 
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
 }
 
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+   return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
 
 
 /*
@@ -1043,23 +1063,23 @@ static int ov7670_cosine(int theta)
 
 
 static void ov7670_calc_cmatrix(struct ov7670_info *info,
-   int matrix[CMATRIX_LEN])
+   int matrix[CMATRIX_LEN], int sat, int hue)
 {
int i;
/*
 * Apply the current saturation setting first.
 */
for (i = 0; i  CMATRIX_LEN; i++)
-   matrix[i] = (info-fmt-cmatrix[i]*info-sat)  7;
+   matrix[i] = (info-fmt-cmatrix[i] * sat)  7;
/*
 * Then, if need be, rotate the hue value.
 */
-   if (info-hue != 0) {
+   if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
 
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
-   sinth = ov7670_sine(info-hue);
-   costh = ov7670_cosine(info-hue);
+   sinth = ov7670_sine(hue);
+   costh = ov7670_cosine(hue);
 
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1072,60 +1092,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info 
*info,
 
 
 
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
-{
-   struct ov7670_info *info = to_state(sd);
-   int matrix[CMATRIX_LEN];
-   int ret;
-
-   info-sat = value;
-   ov7670_calc_cmatrix(info, matrix);
-   ret = ov7670_store_cmatrix(sd, matrix);
-   return ret;
-}
-
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
-   struct ov7670_info *info = to_state(sd);
-
-   *value = info-sat;
-   return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
 {
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
 
-   if (value  -180 || value  180)
-   return -EINVAL;
-   info-hue = value;
-   ov7670_calc_cmatrix(info, matrix);
+   ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
 }
 
 
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
-   struct ov7670_info *info = to_state(sd);
-
-   *value = info-hue;
-   return 0;
-}
-
-
 /*
  * Some weird registers seem to store values in a sign/magnitude format!
  */
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
-   if ((v  0x80) == 0)
-   return v + 128;
-   return 128 - (v  0x7f);
-}
-
 
 static unsigned char ov7670_abs_to_sm(unsigned char v)
 {
@@ -1147,40 +1128,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd, 
int value)
return ret;
 }
 
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
-   unsigned char v = 0;
-   int ret = ov7670_read(sd, REG_BRIGHT, v);
-
-   *value = ov7670_sm_to_abs(v);
-   return ret;
-}
-
 static int ov7670_s_contrast(struct v4l2_subdev *sd, int value)
 {
return ov7670_write(sd, REG_CONTRAS, (unsigned char) value);
 }
 
-static int

Re: [RFC PATCH 3/5] v4l2-ctrls: v4l2_ctrl_handler_setup must set has_new to 1

2011-01-07 Thread Laurent Pinchart

Hi Hans,

On Friday 07 January 2011 13:47:33 Hans Verkuil wrote:
 Drivers can use the has_new field to determine if a new value was specified
 for a control. The v4l2_ctrl_handler_setup() must always set this to 1
 since the setup has to force a full update of all controls.

According to include/media/v4l2-ctrls.h, has_new is a Internal flag: set when 
there is a valid new value. Drivers should then not use it.

If you want to use the flag in a driver, the comment should be changed and its 
usage should be documented in Documentation/video4linux/v4l2-controls.txt.

 Signed-off-by: Hans Verkuil hverk...@xs4all.nl
 ---
  drivers/media/video/v4l2-ctrls.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/video/v4l2-ctrls.c
 b/drivers/media/video/v4l2-ctrls.c index 8f81efc..64f56bb 100644
 --- a/drivers/media/video/v4l2-ctrls.c
 +++ b/drivers/media/video/v4l2-ctrls.c
 @@ -1280,8 +1280,10 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler
 *hdl) if (ctrl-done)
   continue;
 
 - for (i = 0; i  master-ncontrols; i++)
 + for (i = 0; i  master-ncontrols; i++) {
   cur_to_new(master-cluster[i]);
 + master-cluster[i]-has_new = 1;
 + }
 
   /* Skip button controls and read-only controls. */
   if (ctrl-type == V4L2_CTRL_TYPE_BUTTON ||

-- 
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: [RFC PATCH 2/5] v4l2-subdev: add (un)register internal ops

2011-01-07 Thread Laurent Pinchart

Hi Hans,

Thanks for the patch.

On Friday 07 January 2011 13:47:32 Hans Verkuil wrote:
 Some subdevs need to call into the board code after they are registered
 and have a valid struct v4l2_device pointer. The s_config op was abused
 for this, but now that it is removed we need a cleaner way of solving this.
 
 So this patch adds a struct with internal ops that the v4l2 core can call.
 
 Currently only two ops exist: register and unregister. Subdevs can
 implement these to call the board code and pass it the v4l2_device
 pointer, which the board code can then use to get access to the struct
 that embeds the v4l2_device.
 
 It is expected that in the future open and close ops will also be added.
 
 Signed-off-by: Hans Verkuil hverk...@xs4all.nl

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

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

[PATCH v12 3/8] davinci vpbe: OSD(On Screen Display) block

2011-01-07 Thread Manjunath Hadli

This patch implements the functionality of the OSD block
of the VPBE. The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/vpbe_osd.c  | 1216 +++
 drivers/media/video/davinci/vpbe_osd_regs.h |  364 
 include/media/davinci/vpbe_osd.h|  397 +
 3 files changed, 1977 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe_osd.c
 create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
 create mode 100644 include/media/davinci/vpbe_osd.h

diff --git a/drivers/media/video/davinci/vpbe_osd.c 
b/drivers/media/video/davinci/vpbe_osd.c
new file mode 100644
index 000..081bb71
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -0,0 +1,1216 @@
+/*
+ * Copyright (C) 2007-2010 Texas Instruments Inc
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Andy Lowe (al...@mvista.com), MontaVista Software
+ * - Initial version
+ * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd.
+ * - ported to sub device interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/slab.h
+
+#include mach/io.h
+#include mach/cputype.h
+#include mach/hardware.h
+
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_osd.h
+
+#include linux/io.h
+#include vpbe_osd_regs.h
+
+#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME
+
+/* register access routines */
+static inline u32 osd_read(struct osd_state *sd, u32 offset)
+{
+   struct osd_state *osd = sd;
+   return readl(osd-osd_base + offset);
+}
+
+static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
+{
+   struct osd_state *osd = sd;
+   writel(val, osd-osd_base + offset);
+   return val;
+}
+
+static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset)
+{
+   struct osd_state *osd = sd;
+
+   u32 addr = osd-osd_base + offset;
+   u32 val = readl(addr) | mask;
+
+   writel(val, addr);
+   return val;
+}
+
+static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset)
+{
+   struct osd_state *osd = sd;
+   u32 addr = osd-osd_base + offset;
+   u32 val = readl(addr)  ~mask;
+
+   writel(val, addr);
+   return val;
+}
+
+static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
+u32 offset)
+{
+   struct osd_state *osd = sd;
+
+   u32 addr = osd-osd_base + offset;
+   u32 new_val = (readl(addr)  ~mask) | (val  mask);
+   writel(new_val, addr);
+   return new_val;
+}
+
+/* define some macros for layer and pixfmt classification */
+#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1))
+#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1))
+#define is_rgb_pixfmt(pixfmt) \
+   (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
+#define is_yc_pixfmt(pixfmt) \
+   (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+   ((pixfmt) == PIXFMT_NV12))
+#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
+#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO  5)
+
+/**
+ * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446
+ * @sd - ptr to struct osd_state
+ * @field_inversion - inversion flag
+ * @fb_base_phys - frame buffer address
+ * @lconfig - ptr to layer config
+ *
+ * This routine implements a workaround for the field signal inversion silicon
+ * erratum described in Advisory 1.3.8 for the DM6446.  The fb_base_phys and
+ * lconfig parameters apply to the vid0 window.  This routine should be called
+ * whenever the vid0 layer configuration or start address is modified, or when
+ * the OSD field inversion setting is modified.
+ * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or
+ *  0 otherwise
+ */
+static

[PATCH v12 4/8] davinci vpbe: VENC( Video Encoder) implementation

2011-01-07 Thread Manjunath Hadli

This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/vpbe_venc.c  |  556 ++
 drivers/media/video/davinci/vpbe_venc_regs.h |  177 
 include/media/davinci/vpbe_venc.h|   41 ++
 3 files changed, 774 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe_venc.c
 create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
 create mode 100644 include/media/davinci/vpbe_venc.h

diff --git a/drivers/media/video/davinci/vpbe_venc.c 
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..07290dd
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,556 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+   struct v4l2_subdev sd;
+   struct venc_callback *callback;
+   struct venc_platform_data *pdata;
+   struct device *pdev;
+   u32 output;
+   v4l2_std_id std;
+   spinlock_t lock;
+   void __iomem *venc_base;
+   void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+   struct venc_state *venc = to_state(sd);
+
+   return readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+   struct venc_state *venc = to_state(sd);
+   writel(val, (venc-venc_base + offset));
+   return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+   u32 new_val = (venc_read(sd, offset)  ~mask) | (val  mask);
+
+   venc_write(sd, offset, new_val);
+   return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+   struct venc_state *venc = to_state(sd);
+
+   writel(val, venc-vdaccfg_reg);
+
+   val = readl(venc-vdaccfg_reg);
+   return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+   int ret = 0;
+
+   switch (out_index) {
+   case 0:
+   v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+   venc_write(sd, VENC_DACSEL, 0);
+   break;
+   case 1:
+   v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+   venc_write(sd, VENC_DACSEL, 0x210);
+   break;
+   case  2:
+   venc_write(sd, VENC_DACSEL, 0x543);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+   return ret;
+}
+
+static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+   v4l2_dbg(debug, 2, sd, venc_enabledigitaloutput\n);
+
+   if (benable) {
+   venc_write(sd, VENC_VMOD, 0);
+   venc_write(sd, VENC_CVBS, 0);
+   venc_write(sd, VENC_LCDOUT, 0);
+   venc_write(sd, VENC_HSPLS, 0);
+

[PATCH v12 2/8] davinci vpbe: VPBE display driver

2011-01-07 Thread Manjunath Hadli

This patch implements the core functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/vpbe.c |  826 
 include/media/davinci/vpbe.h   |  185 
 2 files changed, 1011 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe.c
 create mode 100644 include/media/davinci/vpbe.h

diff --git a/drivers/media/video/davinci/vpbe.c 
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..3dbd265
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,826 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+
+#define VPBE_DEFAULT_OUTPUTComposite
+#define VPBE_DEFAULT_MODE  ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static  struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(ef_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+   struct vpbe_display_config *vpbe_config = vpbe_dev-cfg;
+   int index = vpbe_dev-current_sd_index;
+
+   return ((index == 0) ? vpbe_config-venc :
+   vpbe_config-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config *vpbe_config,
+int index)
+{
+   char *encoder_name = vpbe_config-outputs[index].subdev_name;
+   int i;
+
+   /* Venc is always first */
+   if (!strcmp(encoder_name, vpbe_config-venc.module_name))
+   return 0;
+
+   for (i = 0; i  vpbe_config-num_ext_encoders; i++) {
+   if (!strcmp(encoder_name,
+vpbe_config-ext_encoders[i].module_name))
+   return i+1;
+   }
+   return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+   if (NULL == cropcap)
+   return -EINVAL;
+   cropcap-bounds.left = 0;
+   cropcap-bounds.top = 0;
+   cropcap-bounds.width = vpbe_dev-current_timings.xres;
+   cropcap-bounds.height = vpbe_dev-current_timings.yres;
+   cropcap-defrect = cropcap-bounds;
+   return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+

[PATCH v12 2/8] davinci vpbe: VPBE display driver

2011-01-07 Thread Manjunath Hadli

This patch implements the core functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/vpbe.c |  826 
 include/media/davinci/vpbe.h   |  185 
 2 files changed, 1011 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe.c
 create mode 100644 include/media/davinci/vpbe.h

diff --git a/drivers/media/video/davinci/vpbe.c 
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..3dbd265
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,826 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+
+#define VPBE_DEFAULT_OUTPUTComposite
+#define VPBE_DEFAULT_MODE  ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static  struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(ef_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+   struct vpbe_display_config *vpbe_config = vpbe_dev-cfg;
+   int index = vpbe_dev-current_sd_index;
+
+   return ((index == 0) ? vpbe_config-venc :
+   vpbe_config-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config *vpbe_config,
+int index)
+{
+   char *encoder_name = vpbe_config-outputs[index].subdev_name;
+   int i;
+
+   /* Venc is always first */
+   if (!strcmp(encoder_name, vpbe_config-venc.module_name))
+   return 0;
+
+   for (i = 0; i  vpbe_config-num_ext_encoders; i++) {
+   if (!strcmp(encoder_name,
+vpbe_config-ext_encoders[i].module_name))
+   return i+1;
+   }
+   return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+   if (NULL == cropcap)
+   return -EINVAL;
+   cropcap-bounds.left = 0;
+   cropcap-bounds.top = 0;
+   cropcap-bounds.width = vpbe_dev-current_timings.xres;
+   cropcap-bounds.height = vpbe_dev-current_timings.yres;
+   cropcap-defrect = cropcap-bounds;
+   return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+

[PATCH v12 6/8] davinci vpbe: board specific additions

2011-01-07 Thread Manjunath Hadli

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 |   86 --
 1 files changed, 70 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..8abef65 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -5,7 +5,7 @@
  *
  * 2007 (c) MontaVista Software, Inc. This file is licensed under
  * the terms of the GNU General Public License version 2. This program
- * is licensed as is without any warranty of any kind, whether express
+ * is licensed without any warranty of any kind, whether express
  * or implied.
  */
 #include linux/kernel.h
@@ -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),
+   .outputs = dm644x_vpbe_outputs,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
-   davinci_fb_device,
rtc_dev,
 };
 
@@ -630,6 +681,9 @@ davinci_evm_map_io(void)
 {
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(vpfe_cfg);
+
+   /* setup configuration for vpbe devices */
+

[PATCH v12 7/8] davinci vpbe: Build infrastructure for VPBE driver

2011-01-07 Thread Manjunath Hadli

This patch adds the build infra-structure for Davinci
VPBE dislay driver.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/Kconfig  |   22 ++
 drivers/media/video/davinci/Makefile |2 ++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/davinci/Kconfig 
b/drivers/media/video/davinci/Kconfig
index 6b19540..a7f11e7 100644
--- a/drivers/media/video/davinci/Kconfig
+++ b/drivers/media/video/davinci/Kconfig
@@ -91,3 +91,25 @@ config VIDEO_ISIF
 
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
+
+config VIDEO_DM644X_VPBE
+   tristate DM644X VPBE HW module
+   select VIDEO_VPSS_SYSTEM
+   select VIDEOBUF_DMA_CONTIG
+   help
+   Enables VPBE modules used for display on a DM644x
+   SoC.
+
+   To compile this driver as a module, choose M here: the
+   module will be called vpbe.
+
+
+config VIDEO_VPBE_DISPLAY
+   tristate VPBE V4L2 Display driver
+   select VIDEO_DM644X_VPBE
+   default y
+   help
+   Enables VPBE V4L2 Display driver on a DMXXX device
+
+   To compile this driver as a module, choose M here: the
+   module will be called vpbe_display.
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index a379557..ae7dafb 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
 obj-$(CONFIG_VIDEO_ISIF) += isif.o
+obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o
+obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o
-- 
1.6.2.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 v12 8/8] davinci vpbe: Readme text for Dm6446 vpbe

2011-01-07 Thread Manjunath Hadli

Please refer to this file for detailed documentation of
davinci vpbe v4l2 driver.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 Documentation/video4linux/README.davinci-vpbe |   93 +
 1 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/video4linux/README.davinci-vpbe

diff --git a/Documentation/video4linux/README.davinci-vpbe 
b/Documentation/video4linux/README.davinci-vpbe
new file mode 100644
index 000..7a460b0
--- /dev/null
+++ b/Documentation/video4linux/README.davinci-vpbe
@@ -0,0 +1,93 @@
+
+VPBE V4L2 driver design
+ ==
+
+ File partitioning
+ -
+ V4L2 display device driver
+ drivers/media/video/davinci/vpbe_display.c
+ drivers/media/video/davinci/vpbe_display.h
+
+ VPBE display controller
+ drivers/media/video/davinci/vpbe.c
+ drivers/media/video/davinci/vpbe.h
+
+ VPBE venc sub device driver
+ drivers/media/video/davinci/vpbe_venc.c
+ drivers/media/video/davinci/vpbe_venc.h
+ drivers/media/video/davinci/vpbe_venc_regs.h
+
+ VPBE osd driver
+ drivers/media/video/davinci/vpbe_osd.c
+ drivers/media/video/davinci/vpbe_osd.h
+ drivers/media/video/davinci/vpbe_osd_regs.h
+
+ Functional partitioning
+ ---
+
+ Consists of the following (in the same order as the list under file
+ partitioning):-
+
+ 1. V4L2 display driver
+Implements creation of video2 and video3 device nodes and
+provides v4l2 device interface to manage VID0 and VID1 layers.
+
+ 2. Display controller
+Loads up VENC, OSD and external encoders such as ths8200. It provides
+a set of API calls to V4L2 drivers to set the output/standards
+in the VENC or external sub devices. It also provides
+a device object to access the services from OSD subdevice
+using sub device ops. The connection of external encoders to VENC LCD
+controller port is done at init time based on default output and standard
+selection or at run time when application change the output through
+V4L2 IOCTLs.
+
+When connected to an external encoder, vpbe controller is also responsible
+for setting up the interface between VENC and external encoders based on
+board specific settings (specified in board-xxx-evm.c). This allows
+interfacing external encoders such as ths8200. The setup_if_config()
+is implemented for this as well as configure_venc() (part of the next 
patch)
+API to set timings in VENC for a specific display resolution. As of this
+patch series, the interconnection and enabling and setting of the external
+encoders is not present, and would be a part of the next patch series.
+
+ 3. VENC subdevice module
+Responsible for setting outputs provided through internal DACs and also
+setting timings at LCD controller port when external encoders are connected
+at the port or LCD panel timings required. When external encoder/LCD panel
+is connected, the timings for a specific standard/preset is retrieved from
+the board specific table and the values are used to set the timings in
+venc using non-standard timing mode.
+
+Support LCD Panel displays using the VENC. For example to support a Logic
+PD display, it requires setting up the LCD controller port with a set of
+timings for the resolution supported and setting the dot clock. So we could
+add the available outputs as a board specific entry (i.e add the LogicPD
+output name to board-xxx-evm.c). A table of timings for various LCDs
+supported can be maintained in the board specific setup file to support
+various LCD displays.As of this patch a basic driver is present, and this
+support for external encoders and displays forms a part of the next
+patch series.
+
+ 4. OSD module
+OSD module implements all OSD layer management and hardware specific
+features. The VPBE module interacts with the OSD for enabling and
+disabling appropriate features of the OSD.
+
+ Current status:-
+
+ A fully functional working version of the V4L2 driver is available. This
+ driver has been tested with NTSC and PAL standards and buffer streaming.
+
+ Following are TBDs.
+
+ vpbe display controller
+- Add support for external encoders.
+- add support for selecting external encoder as default at probe time.
+
+ vpbe venc sub device
+- add timings for supporting ths8200
+- add support for LogicPD LCD.
+
+ FB drivers
+- Add support for fbdev drivers.- Ready and part of subsequent patches.
-- 
1.6.2.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 v12 5/8] davinci vpbe: platform specific additions

2011-01-07 Thread Manjunath Hadli

This patch implements the overall device creation for the Video
display driver.

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/dm644x.c  |  168 +--
 arch/arm/mach-davinci/include/mach/dm644x.h |   20 +++-
 2 files changed, 177 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..99bdeef 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -5,7 +5,7 @@
  *
  * 2007 (c) Deep Root Systems, LLC. This file is licensed under
  * the terms of the GNU General Public License version 2. This program
- * is licensed as is without any warranty of any kind, whether express
+ * is licensed without any warranty of any kind, whether express
  * or implied.
  */
 #include linux/init.h
@@ -618,6 +618,7 @@ static struct resource vpfe_resources[] = {
 };
 
 static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
 static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +655,138 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
 }
 
+static struct resource dm644x_osd_resources[] = {
+   {
+   .start  = 0x01C72600,
+   .end= 0x01C72600 + 0x1ff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct osd_platform_data osd_data = {
+   .vpbe_type = DM644X_VPBE,
+   .field_inv_wa_enable = 0,
+};
+
+static struct platform_device dm644x_osd_dev = {
+   .name   = VPBE_OSD_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_osd_resources),
+   .resource   = dm644x_osd_resources,
+   .dev = {
+   .dma_mask   = dm644x_osd_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = osd_data,
+   },
+};
+
+static struct resource dm644x_venc_resources[] = {
+   /* venc registers io space */
+   {
+   .start  = 0x01C72400,
+   .end= 0x01C72400 + 0x17f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+#define VPSS_CLKCTL 0x01C40044
+
+static void __iomem *vpss_clkctl_reg;
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+   int ret = 0;
+
+   if (NULL == vpss_clkctl_reg)
+   return -EINVAL;
+   switch (type) {
+   case VPBE_ENC_STD:
+   writel(0x18, vpss_clkctl_reg);
+   break;
+   case VPBE_ENC_DV_PRESET:
+   switch ((unsigned int)mode) {
+   case V4L2_DV_480P59_94:
+   case V4L2_DV_576P50:
+writel(0x19, vpss_clkctl_reg);
+   break;
+   case V4L2_DV_720P60:
+   case V4L2_DV_1080I60:
+   case V4L2_DV_1080P30:
+   /*
+* For HD, use external clock source since
+* HD requires higher clock rate
+*/
+   writel(0xa, vpss_clkctl_reg);
+   break;
+   default:
+   ret  = -EINVAL;
+   break;
+   }
+   break;
+   default:
+   ret  = -EINVAL;
+   }
+   return ret;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+   .name   = vpbe-v4l2,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+   .resource   = dm644x_v4l2_disp_resources,
+   .dev = {
+   .dma_mask   = vpbe_display_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+   .venc_type  = DM644X_VPBE,
+   .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+   .name   = VPBE_VENC_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_venc_resources),
+   .resource   = dm644x_venc_resources,
+   .dev = {
+   .dma_mask   = dm644x_venc_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = dm644x_venc_pdata,
+   },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device

[patch v2] [media] av7110: check for negative array offset

2011-01-07 Thread Dan Carpenter

info-num comes from the user.  It's type int.  If the user passes
in a negative value that would cause memory corruption.

Signed-off-by: Dan Carpenter erro...@gmail.com
---
V2: change the check instead of making num and unsigned int

diff --git a/drivers/media/dvb/ttpci/av7110_ca.c 
b/drivers/media/dvb/ttpci/av7110_ca.c
index 122c728..923a8e2 100644
--- a/drivers/media/dvb/ttpci/av7110_ca.c
+++ b/drivers/media/dvb/ttpci/av7110_ca.c
@@ -277,7 +277,7 @@ static int dvb_ca_ioctl(struct file *file, unsigned int 
cmd, void *parg)
{
ca_slot_info_t *info=(ca_slot_info_t *)parg;
 
-   if (info-num  1)
+   if ((unsigned)info-num  1)
return -EINVAL;
av7110-ci_slot[info-num].num = info-num;
av7110-ci_slot[info-num].type = 
FW_CI_LL_SUPPORT(av7110-arm_app) ?
--
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] av7110: make array offset unsigned

2011-01-07 Thread Dan Carpenter

On Fri, Jan 07, 2011 at 01:44:15PM +0100, Andreas Oberritter wrote:
 Nack. You're changing an interface to userspace. Please add a check to
 av7110_ca.c instead.
 

Ok.  I've done that and resent the patch.

But just for my own understanding, why is it wrong to change an int to
an unsigned int in the userspace API?  Who would notice?  (I'm still
quite a newbie at system programming).

regards,
dan carpenter

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

Re: [RFC PATCH 1/5] v4l2-subdev: remove core.s_config and v4l2_i2c_new_subdev_cfg()

2011-01-07 Thread Laurent Pinchart

Hi Hans,

On Friday 07 January 2011 13:47:31 Hans Verkuil wrote:

[snip]
 
 diff --git a/drivers/media/video/cx25840/cx25840-core.c
 b/drivers/media/video/cx25840/cx25840-core.c index dfb198d..9b384ac 100644
 --- a/drivers/media/video/cx25840/cx25840-core.c
 +++ b/drivers/media/video/cx25840/cx25840-core.c
 @@ -1682,20 +1682,6 @@ static int cx25840_log_status(struct v4l2_subdev
 *sd) return 0;
  }
 
 -static int cx25840_s_config(struct v4l2_subdev *sd, int irq, void
 *platform_data) -{
 - struct cx25840_state *state = to_state(sd);
 - struct i2c_client *client = v4l2_get_subdevdata(sd);
 -
 - if (platform_data) {
 - struct cx25840_platform_data *pdata = platform_data;
 -
 - state-pvr150_workaround = pdata-pvr150_workaround;
 - set_input(client, state-vid_input, state-aud_input);
 - }
 - return 0;
 -}
 -
  static int cx23885_irq_handler(struct v4l2_subdev *sd, u32 status,
  bool *handled)
  {

[snip]

 @@ -2019,6 +2003,12 @@ static int cx25840_probe(struct i2c_client *client,
   v4l2_ctrl_cluster(2, state-volume);
   v4l2_ctrl_handler_setup(state-hdl);
 
 + if (client-dev.platform_data) {
 + struct cx25840_platform_data *pdata = client-dev.platform_data;
 +
 + state-pvr150_workaround = pdata-pvr150_workaround;
 + }
 +

No need to call set_input() anymore ?

   cx25840_ir_probe(sd);
   return 0;
  }

[snip]

 diff --git a/drivers/media/video/mt9v011_regs.h
 b/drivers/media/video/mt9v011_regs.h new file mode 100644
 index 000..d6a5a08
 --- /dev/null
 +++ b/drivers/media/video/mt9v011_regs.h
 @@ -0,0 +1,36 @@
 +/*
 + * mt9v011 -Micron 1/4-Inch VGA Digital Image Sensor
 + *
 + * Copyright (c) 2009 Mauro Carvalho Chehab (mche...@redhat.com)
 + * This code is placed under the terms of the GNU General Public License
 v2 + */
 +
 +#ifndef MT9V011_REGS_H_
 +#define MT9V011_REGS_H_
 +
 +#define R00_MT9V011_CHIP_VERSION 0x00
 +#define R01_MT9V011_ROWSTART 0x01
 +#define R02_MT9V011_COLSTART 0x02
 +#define R03_MT9V011_HEIGHT   0x03
 +#define R04_MT9V011_WIDTH0x04
 +#define R05_MT9V011_HBLANK   0x05
 +#define R06_MT9V011_VBLANK   0x06
 +#define R07_MT9V011_OUT_CTRL 0x07
 +#define R09_MT9V011_SHUTTER_WIDTH0x09
 +#define R0A_MT9V011_CLK_SPEED0x0a
 +#define R0B_MT9V011_RESTART  0x0b
 +#define R0C_MT9V011_SHUTTER_DELAY0x0c
 +#define R0D_MT9V011_RESET0x0d
 +#define R1E_MT9V011_DIGITAL_ZOOM 0x1e
 +#define R20_MT9V011_READ_MODE0x20
 +#define R2B_MT9V011_GREEN_1_GAIN 0x2b
 +#define R2C_MT9V011_BLUE_GAIN0x2c
 +#define R2D_MT9V011_RED_GAIN 0x2d
 +#define R2E_MT9V011_GREEN_2_GAIN 0x2e
 +#define R35_MT9V011_GLOBAL_GAIN  0x35
 +#define RF1_MT9V011_CHIP_ENABLE  0xf1
 +
 +#define MT9V011_VERSION  0x8232
 +#define MT9V011_REV_B_VERSION0x8243

What about merging this into mt9v011.c ?

 +
 +#endif

-- 
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: [PATCH v12 5/8] davinci vpbe: platform specific additions

2011-01-07 Thread Sergei Shtylyov


Hello.

On 07-01-2011 16:40, Manjunath Hadli wrote:


This patch implements the overall device creation for the Video
display driver.



Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com
Acked-by: Muralidharan Karicherim-kariche...@ti.com
Acked-by: Hans Verkuilhverk...@xs4all.nl

[...]


diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h 
b/arch/arm/mach-davinci/include/mach/dm644x.h
index 5a1b26d..b59591c 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -6,8 +6,7 @@
   *
   * This program is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * the Free Software Foundation; either version 2 of the License.


   Unfinished sentence. Did you intend to changed the license to GPL 2 only?
If so, it's worth mentioning in the changelog...

[...]

@@ -40,8 +43,21 @@
  #define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600
  #define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800

+/* VPBE register base addresses */
+#define DM644X_VENC_REG_BASE   0x01C72400


   You defined the macro but don't use it...


+#define DM644X_VPBE_REG_BASE   0x01C72780
+
+#define DM644X_OSD_REG_BASE0x01C72600


   Same comment...


+#define DM644X_VPBE_REG_BASE   0x01C72780


   This is duplicate.


+
+#define OSD_REG_SIZE   0x0100


   Your OSD platform device however has its resource of size 0x200...


+/* SYS register addresses */
+#define SYS_VPSS_CLKCTL0x01C40044


   You've already #define'd and used VPSS_CLKCTL -- this is duplicate/unused.

WBR, Sergei
--
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] av7110: make array offset unsigned

2011-01-07 Thread Vasiliy Kulikov

On Fri, Jan 07, 2011 at 16:51 +0300, Dan Carpenter wrote:
 But just for my own understanding, why is it wrong to change an int to
 an unsigned int in the userspace API?  Who would notice?

E.g. the same check in userspace (var  0).  If var has changed the sign
then the result would differ.

-- 
Vasiliy
--
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] av7110: make array offset unsigned

2011-01-07 Thread Andreas Oberritter

On 01/07/2011 02:51 PM, Dan Carpenter wrote:
 On Fri, Jan 07, 2011 at 01:44:15PM +0100, Andreas Oberritter wrote:
 Nack. You're changing an interface to userspace. Please add a check to
 av7110_ca.c instead.

 
 Ok.  I've done that and resent the patch.

Thanks. I'm OK with the patch, but I'll leave it to the maintainer of
av7110 to decide whether he likes the cast or prefers an additional
signed compare. I added him to CC.

 But just for my own understanding, why is it wrong to change an int to
 an unsigned int in the userspace API?  Who would notice?  (I'm still
 quite a newbie at system programming).

It would generate compiler warnings in userspace for programs checking
for values  0 or assigning negative values (for whatever reason).

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

RE: [PATCH v12 5/8] davinci vpbe: platform specific additions

2011-01-07 Thread Hadli, Manjunath

On Fri, Jan 07, 2011 at 19:27:37, Sergei Shtylyov wrote:
 Hello.
 
 On 07-01-2011 16:40, Manjunath Hadli wrote:
 
  This patch implements the overall device creation for the Video 
  display driver.
 
  Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com
  Acked-by: Muralidharan Karicherim-kariche...@ti.com
  Acked-by: Hans Verkuilhverk...@xs4all.nl
 [...]
 
  diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h 
  b/arch/arm/mach-davinci/include/mach/dm644x.h
  index 5a1b26d..b59591c 100644
  --- a/arch/arm/mach-davinci/include/mach/dm644x.h
  +++ b/arch/arm/mach-davinci/include/mach/dm644x.h
  @@ -6,8 +6,7 @@
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published 
  by
  - * the Free Software Foundation; either version 2 of the License, or
  - * (at your option) any later version.
  + * the Free Software Foundation; either version 2 of the License.
 
 Unfinished sentence. Did you intend to changed the license to GPL 2 only?
 If so, it's worth mentioning in the changelog...
This should read like this:

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation version 2.

I will change it appropriately.
 
 [...]
  @@ -40,8 +43,21 @@
#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600
#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800
 
  +/* VPBE register base addresses */
  +#define DM644X_VENC_REG_BASE   0x01C72400
 
 You defined the macro but don't use it...
 
  +#define DM644X_VPBE_REG_BASE   0x01C72780
  +
  +#define DM644X_OSD_REG_BASE0x01C72600
 
 Same comment...
 
  +#define DM644X_VPBE_REG_BASE   0x01C72780
 
 This is duplicate.
 
  +
  +#define OSD_REG_SIZE   0x0100
 
 Your OSD platform device however has its resource of size 0x200...
 
  +/* SYS register addresses */
  +#define SYS_VPSS_CLKCTL0x01C40044
 
 You've already #define'd and used VPSS_CLKCTL -- this is duplicate/unused.
We are using the base addresses from platform resources. I will delete these.
 
 WBR, Sergei
 

--
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-07 Thread Laurent Pinchart

Hi Andy,

On Thursday 06 January 2011 19:28:56 Andy Walls wrote:
 On Thu, 2011-01-06 at 16:33 +0100, Laurent Pinchart wrote:
  Hi everybody,
  
  I ran into an issue when implementing cropping and scaling on the OMAP3
  ISP resizer sub-device using the pad-level operations. As nobody seems
  to be happy with the V4L2 crop ioctls, I thought I would ask for
  comments about the subdev pad-level API to avoid repeating the same
  mistakes.
  
  A little background information first. The OMAP3 ISP resizer has an input
  and an output pad. It receives images on its input pad, performs
  cropping to a user-configurable rectange and then scales that rectangle
  up or down to a user-configurable output size. The resulting image is
  output on the output pad.
  
  The hardware sets various restrictions on the crop rectangle and on the
  output size, or more precisely on the relationship between them.
  Horizontal and vertical scaling ratios are independent (at least
  independent enough for the purpose of this discussion), so I'll will not
  comment on one of them in particular.
  
  The minimum and maximum scaling ratios are roughly 1/4 and x4. A complex
  equation describes the relationship between the ratio, the cropped size
  and the output size. It involves integer arithmetics and must be
  fullfilled exactly, so not all combination of crop rectangle and output
  size can be achieved.
  
  The driver expects the user to set the input size first. It propagates
  the input format to the output pad, resetting the crop rectangle. That
  behaviour is common to all the OMAP3 ISP modules, and I don't think much
  discussion is needed there.
 
 I'll note here that the driver is allowing the application to make *two*
 assumptions here:
 
   output size == input size
 and
   output pixel resolution == input pixel resolution
 
 If I'm taking a picture of a building, at a distance from the building
 such that the input image has a resolution of 1 pixel per 5 cm in the
 plane of the building, then the output image also has a pixel resolution
 of 1 pixel per 5 cm in the plane of the building.

I'm not sure to follow you here. If the resizer upscales the image by 2, you 
will have 2 pixels per 5 cm at the output.

  The user can then configure the crop rectangle and the output size
  independently. As not all combinations are possible, configuring one of
  them can modify the other one as a side effect.
 
 What enforces the modification, the hardware or the driver?

The hardware requires several conditions to be fulfilled, and the driver 
enforces that.

 IMO, a crop should be a crop with no scaling or interpolation side
 effects.  If I have 1 pixel per 5 cm on the input, I should get 1 pixel
 per 5 cm on the output.

Correct, but I'm not talking about crop only. The OMAP3 ISP resizer first 
crops the input image, and then scales the cropped image to output a cropped 
and resized image.

 Changing the output size when setting a new crop window is IMO the
 correct thing to do since:
 
 a. it maintains the pixel resolution (e.g. 1 pixel per 5 cm).
 
 b. it is a predictable result that people and applications can rely upon
 
 c. It fail due to any implicit zoom constraint violation
 
 d. The application also knows what the new output size will be, since it
 just set the crop window to that same size
 
   This is where problems come from.
  
  Let's assume that the input size, the crop rectangle and the output size
  are all set to 4000x4000. The user then wants to crop a 500x500
  rectangle and scale it up to 750x750.
  
  If the user first sets the crop rectangle to 500x500,  the 4000x4000
  output size would result in a x8 scaling factor, not supported by the
  resizer. The driver must then either modify the requested crop rectangle
  or the output size to fullfill the hardware requirements.
 
 My suggestion is to have the driver modify the output size as a side
 effect.  Changing the output size already happens as a side effect when
 the application sets the input size.

That's what we're currently doing, but it introduces an issue, see below.

  If the user first sets the output size to 750x750 we end up with a
  similar problem, and the driver needs to modify one of crop rectangle or
  output size as well.
  
  When the stream is on, the output size can't be modified as it would
  change the captured frame size.
 
 Hmm.
 
   The crop rectangle and scaling ratios, on the other
  
  hand, can be modified to implement digital zoom. For that reason, the
  resizer driver doesn't modify the output size when the crop rectangle is
  set while a stream is running, but restricts the crop rectangle size.
  With the above example as a starting point, requesting a 500x500 crop
  rectangle, which would result in an unsupported x8 zoom, will return a
  1000x1000 crop rectangle.
 
 But in this situation - fixed input size, fixed output size - you know
 exactly what scaling levels are supported, 1/4x to 4x, right?

The driver know

Re: [PATCH v12 5/8] davinci vpbe: platform specific additions

2011-01-07 Thread Sergei Shtylyov


On 07-01-2011 17:13, Hadli, Manjunath wrote:


This patch implements the overall device creation for the Video
display driver.



Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com
Acked-by: Muralidharan Karicherim-kariche...@ti.com
Acked-by: Hans Verkuilhverk...@xs4all.nl

[...]



diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h
b/arch/arm/mach-davinci/include/mach/dm644x.h
index 5a1b26d..b59591c 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h

[...]

@@ -40,8 +43,21 @@
   #define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600
   #define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800



+/* VPBE register base addresses */
+#define DM644X_VENC_REG_BASE   0x01C72400



 You defined the macro but don't use it...



+#define DM644X_VPBE_REG_BASE   0x01C72780
+
+#define DM644X_OSD_REG_BASE0x01C72600



 Same comment...



+#define DM644X_VPBE_REG_BASE   0x01C72780



 This is duplicate.



+
+#define OSD_REG_SIZE   0x0100



 Your OSD platform device however has its resource of size 0x200...



+/* SYS register addresses */
+#define SYS_VPSS_CLKCTL0x01C40044



 You've already #define'd and used VPSS_CLKCTL -- this is duplicate/unused.



We are using the base addresses from platform resources. I will delete these.


   You could use these macros to #define the platfrom resources, if you 
#define'd them already.


WBR, Sergei
--
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: [Query][videobuf-dma-sg] Pages in Highmem handling

2011-01-07 Thread Aguirre, Sergio

Hi Mauro,

 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
 Sent: Monday, December 20, 2010 5:23 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; Warren, Christina; Boateng, Akwasi;
 Russell King
 Subject: Re: [Query][videobuf-dma-sg] Pages in Highmem handling

 Hi Sergio,

 Em 27-08-2010 11:57, Aguirre, Sergio escreveu:
  Hi,

  I see that in current videobuf library, for DMA SG code, these functions
 fail when
  Detecting a page in Highmem region:

  - videobuf_pages_to_sg
  - videobuf_vmalloc_to_sg

  Now, what's the real reason to not allow handling of Highmem pages?
  Is it an assumption that _always_ HighMem is not reachable by DMA?

  I guess my point is, OMAP platform (and maybe other platforms) can
 handle
  Highmem pages without any problem. I commented these validations:

  65 static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char
 *virt,
  66   int nr_pages)
  67 {

  ...

  77 for (i = 0; i  nr_pages; i++, virt += PAGE_SIZE) {
  78 pg = vmalloc_to_page(virt);
  79 if (NULL == pg)
  80 goto err;
  81 /* BUG_ON(PageHighMem(pg)); */

  ...

  96 static struct scatterlist *videobuf_pages_to_sg(struct page **pages,
  97 int nr_pages, int
 offset)
  98 {

  ...

  109 /* if (PageHighMem(pages[0])) */
  110 /* DMA to highmem pages might not work */
  111 /* goto highmem; */
  112 sg_set_page(sglist[0], pages[0], PAGE_SIZE - offset,
 offset);
  113 for (i = 1; i  nr_pages; i++) {
  114 if (NULL == pages[i])
  115 goto nopage;
  116 /* if (PageHighMem(pages[i]))
  117 goto highmem; */
  118 sg_set_page(sglist[i], pages[i], PAGE_SIZE, 0);
  119 }

  Can somebody shed any light on this?

 Sorry for taking so long to answer you.

Hey, no worries. That's fine.

 Basically, videobuf code were written at Linux 2.4 days, to be used by
 bttv driver (and later used by cx88 and saa7134). At that time, there
 where
 a hack for the usage of highmem (I think it was called bigmem or something
 like that).

 As I was not maintaining the code on that time, I'm not really sure what
 where
 the issues, but I suspect that this were an arch-implementation limit
 related to DMA transfers at highmem, on that time, due to x86 intrinsic
 limits. I'm not sure about the current limits of newer x86 chips, on 32
 and on 64 bits mode, but i think that this limit doesn't exist anymore.

 So, I suspect that just converting it to a call to dma_capable() should
 be enough to fix the issue.

Ok, sounds reasonable.

 Yet, as videobuf2 is almost ready for merge, maybe the best is to take
 some efforts on testing it, and to be sure that it doesn't contain any
 arch-specific limits inside its code.

So, do you want me to make a patch for this, or is this already taken care
on videobuf2?

Regards,
Sergio

 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: RFC: V4L2 driver for Qualcomm MSM camera.

2011-01-07 Thread Laurent Pinchart

Hi,

On Friday 07 January 2011 01:03:58 Yupeng Yan wrote:
 Thanks for the comments - certainly good arguments to our lawyers :-)...
 actually the information of how to config the ISP HW is requested to be
 protected for now, we are working on certain degree of openness.
 
 The HW config code is just a small part of the user space (daemon)
 tasks, the user space code also processes ISP states, carries out 3A
 algorithm and perform post processing features, etc. which will have to
 be protected, this is the reason why the daemon is used in QC solution.

That's fine. Having closed-source userspace 3A and post-processing isn't an 
issue as far as the Linux driver is concerned.

We have the exact same requirements for the OMAP3. The 3A and image quality 
enhancement algorithms are implemented in userspace, in a library that can be 
used by applications (currently either through an open-source LGPL GStreamer 
element that links to the closed-source library, or through a libv4l plugin).

There is no legal need to implement this in a daemon. LGPL software can be 
linked to closed-source libraries, there is no risk there. If you insist on 
implementing a daemon (I really can't understand why that would be needed), 
the best solution would be to provide a library that applications can use to 
communicate with the daemon. That library (and the daemon) should handle 3A 
and post-processing tasks only. All ISP control (configuring the pipeline(s), 
starting/stopping the stream(s), handling the video buffers, getting/setting 
controls, reading statistics data, ...) must be implemented in the open-source 
kernel driver.

-- 
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: [PATCH] [media] v4l: soc-camera: add enum-frame-size ioctl

2011-01-07 Thread Laurent Pinchart

Hi Guennadi,

On Friday 07 January 2011 15:37:35 Guennadi Liakhovetski wrote:
 On Fri, 7 Jan 2011, Qing Xu wrote:
  pass VIDIOC_ENUM_FRAMESIZES down to sub device drivers. So far no
  special handling in soc-camera core.
 
 Hm, no, guess what? I don't think this can work. The parameter, that this
 routine gets from the user struct v4l2_frmsizeenum contains a member
 pixel_format, which is a fourcc code. Whereas subdevices don't deal with
 them, they deal with mediabus codes. It is the same problem as with old
 s/g/try/enum_fmt, which we replaced with respective mbus variants. So, we
 either have to add our own .enum_mbus_framesizes video subdevice
 operation, or we abuse this one, but interpret the pixel_format field as a
 media-bus code.
 
 Currently I only see one subdev driver, that implements this API:
 ov7670.c, and it just happily ignores the pixel_format altogether...
 
 Hans, Laurent, what do you think?

Use the pad-level subdev operations, they take a media bus code as argument 
;-)

 In the soc-camera case you will have to use soc_camera_xlate_by_fourcc()
 to convert to media-bus code from fourcc. A nit-pick: please, follow the
 style of the file, that you patch and don't add double empty lines between
 functions.
 
 A side question: why do you need this format at all? Is it for some custom
 application? What is your use-case, that makes try_fmt / s_fmt
 insufficient for you and how does enum_framesizes help you?

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

[PATCH 0/5] Make the UVC API public

2011-01-07 Thread Laurent Pinchart

Hi everybody,

This patch set moves the uvcvideo.h header file from drivers/media/video/uvc
to include/linux, making the UVC API public.

One last API cleanup is needed before making the API public. The
UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET} are now deprecated and scheduled for removal.

I'll work with Martin Rubli to make sure an up-to-date uvcdynctrl version will
be available by the time I send a pull request for those patches.

Laurent Pinchart (4):
  uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
  uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
  uvcvideo: Include linux/types.h in uvcvideo.h
  uvcvideo: Move uvcvideo.h to include/linux

Martin Rubli (1):
  uvcvideo: Add UVCIOC_CTRL_QUERY ioctl

 Documentation/feature-removal-schedule.txt |   23 +
 Documentation/ioctl/ioctl-number.txt   |2 +-
 drivers/media/video/uvc/uvc_ctrl.c |  334 +--
 drivers/media/video/uvc/uvc_driver.c   |3 +-
 drivers/media/video/uvc/uvc_isight.c   |3 +-
 drivers/media/video/uvc/uvc_queue.c|3 +-
 drivers/media/video/uvc/uvc_status.c   |3 +-
 drivers/media/video/uvc/uvc_v4l2.c |   36 ++-
 drivers/media/video/uvc/uvc_video.c|3 +-
 drivers/media/video/uvc/uvcvideo.h |  658 ---
 include/linux/Kbuild   |1 +
 include/linux/uvcvideo.h   |  667 
 12 files changed, 927 insertions(+), 809 deletions(-)
 delete mode 100644 drivers/media/video/uvc/uvcvideo.h
 create mode 100644 include/linux/uvcvideo.h

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

[PATCH 1/5] uvcvideo: Add UVCIOC_CTRL_QUERY ioctl

2011-01-07 Thread Laurent Pinchart

From: Martin Rubli martin_ru...@logitech.com

This ioctl extends UVCIOC_CTRL_GET/SET by not only allowing to get/set
XU controls but to also send arbitrary UVC commands to XU controls,
namely GET_CUR, SET_CUR, GET_MIN, GET_MAX, GET_RES, GET_LEN, GET_INFO
and GET_DEF. This is required for applications to work with XU controls,
so that they can properly query the size and allocate the necessary
buffers.

Signed-off-by: Martin Rubli martin_ru...@logitech.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_ctrl.c |   92 
 drivers/media/video/uvc/uvc_v4l2.c |   19 ++-
 drivers/media/video/uvc/uvcvideo.h |   11 -
 3 files changed, 87 insertions(+), 35 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..47175cc 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1344,32 +1344,33 @@ static int uvc_ctrl_init_xu_ctrl(struct uvc_device *dev,
 }
 
 int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
-   struct uvc_xu_control *xctrl, int set)
+   struct uvc_xu_control_query *xqry)
 {
struct uvc_entity *entity;
-   struct uvc_control *ctrl = NULL;
+   struct uvc_control *ctrl;
unsigned int i, found = 0;
-   int restore = 0;
-   __u8 *data;
+   __u32 reqflags;
+   __u16 size;
+   __u8 *data = NULL;
int ret;
 
/* Find the extension unit. */
list_for_each_entry(entity, chain-entities, chain) {
if (UVC_ENTITY_TYPE(entity) == UVC_VC_EXTENSION_UNIT 
-   entity-id == xctrl-unit)
+   entity-id == xqry-unit)
break;
}
 
-   if (entity-id != xctrl-unit) {
+   if (entity-id != xqry-unit) {
uvc_trace(UVC_TRACE_CONTROL, Extension unit %u not found.\n,
-   xctrl-unit);
-   return -EINVAL;
+   xqry-unit);
+   return -ENOENT;
}
 
/* Find the control and perform delayed initialization if needed. */
for (i = 0; i  entity-ncontrols; ++i) {
ctrl = entity-controls[i];
-   if (ctrl-index == xctrl-selector - 1) {
+   if (ctrl-index == xqry-selector - 1) {
found = 1;
break;
}
@@ -1377,8 +1378,8 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
 
if (!found) {
uvc_trace(UVC_TRACE_CONTROL, Control %pUl/%u not found.\n,
-   entity-extension.guidExtensionCode, xctrl-selector);
-   return -EINVAL;
+   entity-extension.guidExtensionCode, xqry-selector);
+   return -ENOENT;
}
 
if (mutex_lock_interruptible(chain-ctrl_mutex))
@@ -1390,43 +1391,72 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
goto done;
}
 
-   /* Validate control data size. */
-   if (ctrl-info.size != xctrl-size) {
+   /* Validate the required buffer size and flags for the request */
+   reqflags = 0;
+   size = ctrl-info.size;
+
+   switch (xqry-query) {
+   case UVC_GET_CUR:
+   reqflags = UVC_CONTROL_GET_CUR;
+   break;
+   case UVC_GET_MIN:
+   reqflags = UVC_CONTROL_GET_MIN;
+   break;
+   case UVC_GET_MAX:
+   reqflags = UVC_CONTROL_GET_MAX;
+   break;
+   case UVC_GET_DEF:
+   reqflags = UVC_CONTROL_GET_DEF;
+   break;
+   case UVC_GET_RES:
+   reqflags = UVC_CONTROL_GET_RES;
+   break;
+   case UVC_SET_CUR:
+   reqflags = UVC_CONTROL_SET_CUR;
+   break;
+   case UVC_GET_LEN:
+   size = 2;
+   break;
+   case UVC_GET_INFO:
+   size = 1;
+   break;
+   default:
ret = -EINVAL;
goto done;
}
 
-   if ((set  !(ctrl-info.flags  UVC_CONTROL_SET_CUR)) ||
-   (!set  !(ctrl-info.flags  UVC_CONTROL_GET_CUR))) {
-   ret = -EINVAL;
+   if (size != xqry-size) {
+   ret = -ENOBUFS;
goto done;
}
 
-   memcpy(uvc_ctrl_data(ctrl, UVC_CTRL_DATA_BACKUP),
-  uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),
-  ctrl-info.size);
-   data = uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT);
-   restore = set;
+   if (reqflags  !(ctrl-info.flags  reqflags)) {
+   ret = -EBADRQC;
+   goto done;
+   }
 
-   if (set  copy_from_user(data, xctrl-data, xctrl-size)) {
+   data = kmalloc(size, GFP_KERNEL);
+   if (data == NULL) {
+   ret = -ENOMEM;
+   goto done;
+   }
+
+   if (xqry-query == UVC_SET_CUR 
+   copy_from_user(data, xqry-data, size)) {

[PATCH 5/5] uvcvideo: Move uvcvideo.h to include/linux

2011-01-07 Thread Laurent Pinchart

The header file is used by userspace applications, make it public.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/ioctl/ioctl-number.txt |2 +-
 drivers/media/video/uvc/uvc_ctrl.c   |2 +-
 drivers/media/video/uvc/uvc_driver.c |3 +-
 drivers/media/video/uvc/uvc_isight.c |3 +-
 drivers/media/video/uvc/uvc_queue.c  |3 +-
 drivers/media/video/uvc/uvc_status.c |3 +-
 drivers/media/video/uvc/uvc_v4l2.c   |3 +-
 drivers/media/video/uvc/uvc_video.c  |3 +-
 drivers/media/video/uvc/uvcvideo.h   |  668 --
 include/linux/Kbuild |1 +
 include/linux/uvcvideo.h |  667 +
 11 files changed, 676 insertions(+), 682 deletions(-)
 delete mode 100644 drivers/media/video/uvc/uvcvideo.h
 create mode 100644 include/linux/uvcvideo.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index d6a63c7..ff41158 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -165,7 +165,7 @@ Code  Seq#(hex) Include FileComments
 'T'all arch/x86/include/asm/ioctls.h   conflict!
 'T'C0-DF   linux/if_tun.h  conflict!
 'U'all sound/asound.h  conflict!
-'U'00-0F   drivers/media/video/uvc/uvcvideo.h  conflict!
+'U'00-0F   linux/uvcvideo.hconflict!
 'U'00-CF   linux/uinput.h  conflict!
 'U'00-EF   linux/usbdevice_fs.h
 'U'C0-CF   drivers/bluetooth/hci_uart.h
diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index d6fe13d..185ae90 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -17,12 +17,12 @@
 #include linux/slab.h
 #include linux/uaccess.h
 #include linux/usb.h
+#include linux/uvcvideo.h
 #include linux/videodev2.h
 #include linux/vmalloc.h
 #include linux/wait.h
 #include asm/atomic.h
 
-#include uvcvideo.h
 
 #define UVC_CTRL_DATA_CURRENT  0
 #define UVC_CTRL_DATA_BACKUP   1
diff --git a/drivers/media/video/uvc/uvc_driver.c 
b/drivers/media/video/uvc/uvc_driver.c
index a1e9dfb..e41285a 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -28,6 +28,7 @@
 #include linux/module.h
 #include linux/slab.h
 #include linux/usb.h
+#include linux/uvcvideo.h
 #include linux/videodev2.h
 #include linux/vmalloc.h
 #include linux/wait.h
@@ -36,8 +37,6 @@
 
 #include media/v4l2-common.h
 
-#include uvcvideo.h
-
 #define DRIVER_AUTHOR  Laurent Pinchart  \
laurent.pinch...@ideasonboard.com
 #define DRIVER_DESCUSB Video Class driver
diff --git a/drivers/media/video/uvc/uvc_isight.c 
b/drivers/media/video/uvc/uvc_isight.c
index 74bbe8f..8217c5d 100644
--- a/drivers/media/video/uvc/uvc_isight.c
+++ b/drivers/media/video/uvc/uvc_isight.c
@@ -16,8 +16,7 @@
 #include linux/usb.h
 #include linux/kernel.h
 #include linux/mm.h
-
-#include uvcvideo.h
+#include linux/uvcvideo.h
 
 /* Built-in iSight webcams implements most of UVC 1.0 except a
  * different packet format. Instead of sending a header at the
diff --git a/drivers/media/video/uvc/uvc_queue.c 
b/drivers/media/video/uvc/uvc_queue.c
index f14581b..36f3c58 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -16,13 +16,12 @@
 #include linux/list.h
 #include linux/module.h
 #include linux/usb.h
+#include linux/uvcvideo.h
 #include linux/videodev2.h
 #include linux/vmalloc.h
 #include linux/wait.h
 #include asm/atomic.h
 
-#include uvcvideo.h
-
 /* 
  * Video buffers queue management.
  *
diff --git a/drivers/media/video/uvc/uvc_status.c 
b/drivers/media/video/uvc/uvc_status.c
index b749277..905d3eb 100644
--- a/drivers/media/video/uvc/uvc_status.c
+++ b/drivers/media/video/uvc/uvc_status.c
@@ -16,8 +16,7 @@
 #include linux/slab.h
 #include linux/usb.h
 #include linux/usb/input.h
-
-#include uvcvideo.h
+#include linux/uvcvideo.h
 
 /* --
  * Input device
diff --git a/drivers/media/video/uvc/uvc_v4l2.c 
b/drivers/media/video/uvc/uvc_v4l2.c
index c03046a..ac0fbac 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -17,6 +17,7 @@
 #include linux/module.h
 #include linux/slab.h
 #include linux/usb.h
+#include linux/uvcvideo.h
 #include linux/videodev2.h
 #include linux/vmalloc.h
 #include linux/mm.h
@@ -26,8 +27,6 @@
 #include media/v4l2-common.h
 #include media/v4l2-ioctl.h
 
-#include uvcvideo.h
-
 /* 
  * UVC ioctls
  */
diff --git a/drivers/media/video/uvc/uvc_video.c 
b/drivers/media/video/uvc/uvc_video.c
index 5673d67..43f955e 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@

[PATCH 2/5] uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}

2011-01-07 Thread Laurent Pinchart

Those ioctls are deprecated, list them in the features removal schedule
for 2.6.39.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/feature-removal-schedule.txt |   23 +++
 drivers/media/video/uvc/uvc_v4l2.c |   14 ++
 2 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index f2742e1..0251dff 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -566,3 +566,26 @@ Why:   This field is deprecated. I2C device drivers 
shouldn't change their
 Who:   Jean Delvare kh...@linux-fr.org
 
 
+
+What:  Support for UVCIOC_CTRL_ADD in the uvcvideo driver
+When:  2.6.39
+Why:   The information passed to the driver by this ioctl is now queried
+   dynamically from the device.
+Who:   Laurent Pinchart laurent.pinch...@ideasonboard.com
+
+
+
+What:  Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver
+When:  2.6.39
+Why:   Used only by applications compiled against older driver versions.
+   Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls.
+Who:   Laurent Pinchart laurent.pinch...@ideasonboard.com
+
+
+
+What:  Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver
+When:  2.6.39
+Why:   Superseded by the UVCIOC_CTRL_QUERY ioctl.
+Who:   Laurent Pinchart laurent.pinch...@ideasonboard.com
+
+
diff --git a/drivers/media/video/uvc/uvc_v4l2.c 
b/drivers/media/video/uvc/uvc_v4l2.c
index 7432336..c03046a 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1020,10 +1020,20 @@ static long uvc_v4l2_do_ioctl(struct file *file, 
unsigned int cmd, void *arg)
 
/* Dynamic controls. */
case UVCIOC_CTRL_ADD:
+   uvc_printk(KERN_INFO, Deprecated UVCIOC_CTRL_ADD ioctl 
+  will be removed in 2.6.39.\n);
+   uvc_printk(KERN_INFO, See http://www.ideasonboard.org/uvc/ 
+  for upgrade instructions.\n);
+
/* Legacy ioctl, kept for API compatibility reasons */
return -EEXIST;
 
case UVCIOC_CTRL_MAP_OLD:
+   uvc_printk(KERN_INFO, Deprecated UVCIOC_CTRL_MAP_OLD ioctl 
+  will be removed in 2.6.39.\n);
+   uvc_printk(KERN_INFO, See http://www.ideasonboard.org/uvc/;
+  for upgrade instructions.\n);
+
case UVCIOC_CTRL_MAP:
return uvc_ioctl_ctrl_map(chain, arg,
  cmd == UVCIOC_CTRL_MAP_OLD);
@@ -1041,6 +1051,10 @@ static long uvc_v4l2_do_ioctl(struct file *file, 
unsigned int cmd, void *arg)
.data   = xctrl-data,
};
 
+   uvc_printk(KERN_INFO, Deprecated UVCIOC_CTRL_[GS]ET ioctls 
+  will be removed in 2.6.39.\n);
+   uvc_printk(KERN_INFO, See http://www.ideasonboard.org/uvc/ 
+  for upgrade instructions.\n);
return uvc_xu_ctrl_query(chain, xqry);
}
 
-- 
1.7.2.2

--
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] new_build.git - avoid failing on 'rm' of nonexistent file

2011-01-07 Thread Jarod Wilson

On Jan 7, 2011, at 6:53 AM, Vincent McIntyre wrote:

 While attempting to build recently I have found the 'make distclean'
 target fails if 'rm' tries to remove a file that is not there. The
 attached patch fixes the issue for me (by using rm -f).
 I converted all the other 'rm' calls to 'rm -f' along the way.
 
 Please consider applying this.

Yeah, I did the same earlier for another target, I'll go ahead and get
it applied and pushed.

-- 
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: [patch] new_build.git - drop videodev.h

2011-01-07 Thread Jarod Wilson

On Jan 7, 2011, at 7:04 AM, Vincent McIntyre wrote:

 'make tar' fails for me (building against ubuntu 2.6.32) unless I
 remove videodev.h from TARFILES.
 
 Is this the correct thing to do here?

Yep, videodev.h goes away in 2.6.38. Will apply and push this too.

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

[RFC/PATCH v6 0/4] Multi Format Codec 5.1 driver for S5PC110 SoC

2011-01-07 Thread Kamil Debski

Hello,

This is the sixth version of the MFC 5.1 driver, decoding part. The suggestions
and comments from the group members have been very helpful.

I would be grateful for your comments. Original cover letter ant detailed change
log has been attached below.

Best regards,
Kamil Debski

* Changelog:

==
 Changes since v5
==

1) Changes suggested by Hans Verkuil:
- small change in videodev2.h - corrected control offsets
- made the code more readable by simplifying if statements and using temporary
  pointers
- mfc_mutex is now included in s5p_mfc_dev structure
- after discussion with Peter Oh modification of fourcc defintions
 (replaced DX52 and DX53 with DX50)

2) Changes suggested by JongHun Han:
- comsmetic changed of defines in regs-mfc5.h
- in buffers that have no width adn height, such as the buffer for compressed
  stream, those values are set to 0 instead of 1
- remove redundant pointer to MFC registers
- change name of the union in s5p_mfc_buf from paddr to cookie
- removed global variable (struct s5p_mfc_dev *dev) and moved to use 
video_drvdata

3) Other changes:
- added check for values returned after parsing header - in rare circumstances 
MFC
  hw returned 0x0 as image size and this could cause problems

==
 Changes since v4
==

1) Changes suggested by Kukjin Kim from:
- removed comment arch/arm/mach-s5pv210/include/mach/map.h
- changed device name to s5p-mfc (removed 5, MFC version number)
  also removed the version number from the name of MFC device file
- added GPL license to arch/arm/plat-s5p/dev-mfc.c
- removed unused include file from dev-mfc.c and unnecessary comments

2) Cache handling improvement:
- changed cache handling to use dma_map_single and dma_unmap_single

==
 Changes since v3
==

1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski)
- s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions
have been merged
- queue initialization has been adapted to the new API
- use of the allocator memops has been changed, now there are single
memops for all the allocator contexts

2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions
- parts of the s5p_mfc_try_run function have been moved to separate
functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames,
s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst
s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers)
- s5p_mfc_handle_frame_int has been split to the following functions:
s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new
and s5p_mfc_handle_frame to handle different cases

3) Remove remaining magic numbers and tidy up comments

==
 Changes since v2
==

1) Update to newest videobuf2 API
This is the major change from v2. The videobuf2 API will hopefully have no more
major API changes. Buffer initialization has been moved from buf_prepare
callback to buf_init to simplify the process. Locking mechanism has been
modified to the requirements of new videobuf2 version.
2) Code cleanup
Removed more magic contants and replaced them with appropriate defines. Changed
code to use unlocked_ioctl instead of ioctl in v4l2 file ops.
3) Allocators
All internal buffer allocations are done using the selected vb2 allocator,
instead of using CMA functions directly.

==
 Changes since v1
==

1) Cleanup accoridng to Peter Oh suggestions on the mailing list (Thanks).

* Original cover letter:

==
 Introduction
==

The purpose of this RFC is to discuss the driver for a hw video codec
embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to
handle video decoding of in a range of formats.

So far no hardware codec was supported in V4L2 and this would be the
first one. I guess there are more similar device that would benefit from
a V4L2 unified interface. I suggest a separate control class for codec
devices - V4L2_CTRL_CLASS_CODEC.

Internally the driver uses videobuf2 framework and CMA memory allocator.
I am aware that those have not yet been merged, but I wanted to start
discussion about the driver earlier so it could be merged sooner. The
driver posted here is the initial version, so I suppose it will require
more work.

==
 Device interface
==

The driver principle is based on the idea of memory-to-memory devices:
it provides a single video node and each opened file handle gets its own
private context with separate buffer queues. Each context consist of 2
buffer queues: OUTPUT (for source buffers, i.e. encoded video frames)
and CAPTURE (for destination buffers, i.e. decoded raw video frames).
The process of decoding video data from stream is a bit more complicated
than typical memory-to-memory processing, that's why the m2m framework
is not directly used (it is too limited for this case). The main reason
for this is the fact that the CAPTURE buffers can be

[RFC/PATCH v6 4/4] s5pv210: Enable MFC on Goni

2011-01-07 Thread Kamil Debski

This patch enables MFC 5.1 on Goni board. Multi Format Codec 5.1 is capable
of handling a range of video codecs.

Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-s5pv210/Kconfig |1 +
 arch/arm/mach-s5pv210/mach-goni.c |3 ++-
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index c45a1b7..43f408d 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -85,6 +85,7 @@ config MACH_GONI
select S3C_DEV_HSMMC2
select S3C_DEV_I2C1
select S3C_DEV_I2C2
+   select S5P_DEV_MFC
select S3C_DEV_USB_HSOTG
select S5P_DEV_ONENAND
select SAMSUNG_DEV_KEYPAD
diff --git a/arch/arm/mach-s5pv210/mach-goni.c 
b/arch/arm/mach-s5pv210/mach-goni.c
index 8d19ead..553a60e 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -810,6 +810,7 @@ static struct platform_device *goni_devices[] __initdata = {
goni_i2c_gpio5,
mmc2_fixed_voltage,
goni_device_gpiokeys,
+   s5p_device_mfc,
s5p_device_fimc0,
s5p_device_fimc1,
s5p_device_fimc2,
@@ -857,7 +858,7 @@ static void __init goni_reserve(void)
};
 
static const char map[] __initconst =
-   s5p-mfc5/f=fw;s5p-mfc5/a=b1;s5p-mfc5/b=b2;*=b1,b2;
+   s5p-mfc/f=fw;s5p-mfc/a=b1;s5p-mfc/b=b2;*=b1,b2;
 
cma_set_defaults(regions, map);
cma_early_regions_reserve(NULL);
-- 
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 1/1] Add plugin support to libv4l

2011-01-07 Thread Yordan Kamenov

A libv4l2 plugin will sit in between libv4l2 itself and the
actual /dev/video device node a fd refers to. It will be called each time
libv4l2 wants to do an operation (read/write/ioctl/mmap/munmap) on the
actual /dev/video node in question.

Signed-off-by: Yordan Kamenov ykame...@mm-sol.com
---
 lib/include/libv4l2-plugin.h |   74 
 lib/include/libv4l2.h|   15 ++
 lib/libv4l2/Makefile |4 +-
 lib/libv4l2/libv4l2-priv.h   |9 +
 lib/libv4l2/libv4l2.c|   56 ++-
 lib/libv4l2/v4l2-plugin.c|  399 ++
 lib/libv4l2/v4l2convert.c|   20 ++-
 7 files changed, 568 insertions(+), 9 deletions(-)
 create mode 100644 lib/include/libv4l2-plugin.h
 create mode 100644 lib/libv4l2/v4l2-plugin.c

diff --git a/lib/include/libv4l2-plugin.h b/lib/include/libv4l2-plugin.h
new file mode 100644
index 000..881b55d
--- /dev/null
+++ b/lib/include/libv4l2-plugin.h
@@ -0,0 +1,74 @@
+/*
+* Copyright (C) 2010 Nokia Corporation multime...@maemo.org
+
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU Lesser General Public License as published by
+* the Free Software Foundation; either version 2.1 of the License, or
+* (at your option) any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+*/
+
+#ifndef __LIBV4L2_PLUGIN_H
+#define __LIBV4L2_PLUGIN_H
+
+#include sys/types.h
+
+/* A libv4l2 plugin will sit in between libv4l2 itself and the
+   actual /dev/video device node a fd refers to. It will be called each time
+   libv4l2 wants to do an operation (read/write/ioctl/mmap/munmap) on the
+   actual /dev/video node in question. When called the plugin can then choose
+   to do one of the following:
+   1. Pass the call unmodified to the fd, and return the return value unmodifed
+   2. Modify some arguments in the call and pass it through
+   3. Modify the return(ed) value(s) of a passed through call
+   4. Not do any operation on the fd at all but instead completely fake it
+   (which opens the possibility for fake v4l devices)
+
+   libv4l2 plugins should *never* use any global variables. All data should be
+   bound to the specific fd to which the plugin is bound. This ensures that for
+   example a plugin for a specific type of usb webcam will also work when 2
+   identical cameras are plugged into a system (and both are used from the same
+   process).
+
+   A libv4l2 plugin can register plugin private data using:
+   void libv4l2_set_plugindata(int fd, void *plugin_data);
+
+   And can get this data out of libv4l2 again inside a callback using:
+   void *libv4l2_get_plugindata(int fd);
+
+   Note that a plugin should call libv4l2_set_plugindata only once per fd !
+   Calling it a second time will overwrite the previous value. The logical
+   place to use libv4l2_set_plugindata is from the plugin's open callback.
+*/
+
+/* Plugin callback function struct */
+struct libv4l2_plugin_data {
+   int (*open)(const char *file, int oflag, ...);
+   int (*close)(int fd);
+   int (*ioctl)(int fd, unsigned long int request, ...);
+   ssize_t (*read)(int fd, void *buffer, size_t n);
+   void *(*mmap)(void *start, size_t length, int prot, int flags,
+   int fd, int64_t offset);
+   /* Note as munmap has no fd argument, defining a callback for munmap
+   will result in it getting called for *any* call to v4l2_munmap.
+   So if a plugin defines a callback for munmap (because for
+   example it returns fake mmap buffers from its mmap callback).
+   Then it must keep track of the addresses at which these buffers
+   live and their size and check the munmap arguments to see if the
+   munmap call was meant for it. */
+   int (*munmap)(void *_start, size_t length);
+};
+
+/* Plugin utility functions */
+void libv4l2_set_plugindata(int fd, void *plugin_data);
+void *libv4l2_get_plugindata(int fd);
+
+#endif
diff --git a/lib/include/libv4l2.h b/lib/include/libv4l2.h
index cc0ab4a..2123546 100644
--- a/lib/include/libv4l2.h
+++ b/lib/include/libv4l2.h
@@ -22,6 +22,7 @@
 #include stdio.h
 #include unistd.h
 #include stdint.h
+#include libv4l2-plugin.h
 
 #ifdef __cplusplus
 extern C {
@@ -108,6 +109,20 @@ LIBV4L_PUBLIC int v4l2_get_control(int fd, int cid);
(note the fd is left open in this case). */
 LIBV4L_PUBLIC int v4l2_fd_open(int fd, int v4l2_flags);
 
+
+LIBV4L_PUBLIC int v4l2_plugin_open(int *plugin_used, const char *file,
+

[patch v3] [media] av7110: check for negative array offset

2011-01-07 Thread Dan Carpenter

info-num comes from the user.  It's type int.  If the user passes
in a negative value that would cause memory corruption.

Signed-off-by: Dan Carpenter erro...@gmail.com
---
V2: change the check instead of making num and unsigned int
V3: white space changes

diff --git a/drivers/media/dvb/ttpci/av7110_ca.c 
b/drivers/media/dvb/ttpci/av7110_ca.c
index 122c728..923a8e2 100644
--- a/drivers/media/dvb/ttpci/av7110_ca.c
+++ b/drivers/media/dvb/ttpci/av7110_ca.c
@@ -277,7 +277,7 @@ static int dvb_ca_ioctl(struct file *file, unsigned int 
cmd, void *parg)
{
ca_slot_info_t *info=(ca_slot_info_t *)parg;
 
-   if (info-num  1)
+   if (info-num  0 || info-num  1)
return -EINVAL;
av7110-ci_slot[info-num].num = info-num;
av7110-ci_slot[info-num].type = 
FW_CI_LL_SUPPORT(av7110-arm_app) ?

--
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: Debug code in HG repositories

2011-01-07 Thread Devin Heitmueller

On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Hi guys,

 are you aware that there is a lot of '#if 0' code in the HG repositories
 which is not in GIT?

 When drivers were submitted to the kernel from HG, the '#if 0' stuff was
 stripped, unless it was marked as 'keep'...

 This was fine, when development was done with HG.

 As GIT is being used now, that code will be lost, as soon as the HG
 repositories have been removed...

 Any opinions how this should be handled?

 CU
 Oliver

I complained about this months ago.  The problem is that when we were
using HG, the HG repo was a complete superset of what went into Git
(including development/debug code).  But now that we use Git, neither
is a superset of the other.

If you base your changes on Git, you have to add back in all the
portability code (and any #if 0 you added as the maintainer for
development/debugging).  Oh, and regular users cannot test any of your
changes because they aren't willing to upgrade their entire kernel.

If you base your changes on Hg, nothing merges cleanly when submitted
upstream so your patches get rejected.

Want to know why we are seeing regressions all over the place?
Because *NOBODY* is testing the code until after the kernel goes
stable (since while many are willing to install a v4l-dvb tree, very
few will are willing to upgrade their entire kernel just to test one
driver).  We've probably lost about 98% of our user base of testers.

Oh, and users have to git clone 500M+ of data, and not everybody in
the world has bandwidth fast enough to make that worth their time (it
took me several hours last time I did it).

Anyway, I've beaten this horse to death and it's fallen on deaf ears.
Merge overhead has reached the point where it's just not worth my
time/effort to submit anything upstream anymore.

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: Debug code in HG repositories

2011-01-07 Thread Theodore Kilgore



On Fri, 7 Jan 2011, Hans Verkuil wrote:

 On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
  On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
   Hi guys,
  
   are you aware that there is a lot of '#if 0' code in the HG repositories
   which is not in GIT?
  
   When drivers were submitted to the kernel from HG, the '#if 0' stuff was
   stripped, unless it was marked as 'keep'...
  
   This was fine, when development was done with HG.
  
   As GIT is being used now, that code will be lost, as soon as the HG
   repositories have been removed...
  
   Any opinions how this should be handled?
  
   CU
   Oliver
  
  I complained about this months ago.  The problem is that when we were
  using HG, the HG repo was a complete superset of what went into Git
  (including development/debug code).  But now that we use Git, neither
  is a superset of the other.
  
  If you base your changes on Git, you have to add back in all the
  portability code (and any #if 0 you added as the maintainer for
  development/debugging).  Oh, and regular users cannot test any of your
  changes because they aren't willing to upgrade their entire kernel.
  
  If you base your changes on Hg, nothing merges cleanly when submitted
  upstream so your patches get rejected.
  
  Want to know why we are seeing regressions all over the place?
  Because *NOBODY* is testing the code until after the kernel goes
  stable (since while many are willing to install a v4l-dvb tree, very
  few will are willing to upgrade their entire kernel just to test one
  driver).  We've probably lost about 98% of our user base of testers.
 
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.
 
  Oh, and users have to git clone 500M+ of data, and not everybody in
  the world has bandwidth fast enough to make that worth their time (it
  took me several hours last time I did it).
 
 Currently the media_build tree copies the drivers from a git tree. Which, as
 you say, can be a big problem for non-developers. But all it really needs are
 the media drivers. So perhaps it might be a good idea to make a daily snapshot
 of the drivers and make it available for download on linuxtv.org. That archive
 is only 3.5 MB, so much easier to download.
 
  Anyway, I've beaten this horse to death and it's fallen on deaf ears.
  Merge overhead has reached the point where it's just not worth my
  time/effort to submit anything upstream anymore.
 
 The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
 much work. Any attempt to work from the hg tree is doomed. The media_build
 seems to be a viable alternative. As a developer you still have to go through
 the painful process of cloning the git repo, but it is a one time thing. Once
 it's cloned then you only have to follow the new commits, which is much, much
 faster.
 
 And regarding regressions: I'm amazed how few regressions we have considering
 the furious rate of development. The media subsystem is still one of the most
 active subsystems in the kernel and probably will remain so for the forseeable
 future as well.
 
 It would be a shame not to submit patches upstream, that never ends well in
 the long run.
 
 With respect to '#if 0': for the most part I'd say: good riddance. In my
 many years of experience as a SW engineer I have never seen anyone actually
 turn on '#if 0' code once it's been in the code for more than, say, a year.
 Usually people just leave it there because they are too lazy to remove it,
 or they don't understand what it is for and are too scared to remove it.
 
 If it is code partially implementing a feature that needs more work, then
 it may sound like a good idea to keep it. However, after it's in the code for
 more than a year, then nobody remembers what the code was about and what still
 had to be done to make it work. And it's hell to figure that out after such a
 long time. Never put such code in the mainline. Keep it in a branch if you
 have to.
 
 Anyway, if there is some '#if 0' code that you want to preserve in git, then
 you have to make a patch to add it. But you probably will have to have very
 good reasons for adding '#if 0' code to the mainline.
 
 Regards,
 
   Hans
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

I think you are both right. There, that ought to be pleasing. :-)

More seriously (quoting from above)

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
should
 promote this more. 

Probably a

Re: Debug code in HG repositories

2011-01-07 Thread Oliver Endriss

On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
 On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
  On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
   Hi guys,
  
   are you aware that there is a lot of '#if 0' code in the HG repositories
   which is not in GIT?
  
   When drivers were submitted to the kernel from HG, the '#if 0' stuff was
   stripped, unless it was marked as 'keep'...
  
   This was fine, when development was done with HG.
  
   As GIT is being used now, that code will be lost, as soon as the HG
   repositories have been removed...
  
   Any opinions how this should be handled?
  
   CU
   Oliver
  
  I complained about this months ago.  The problem is that when we were
  using HG, the HG repo was a complete superset of what went into Git
  (including development/debug code).  But now that we use Git, neither
  is a superset of the other.
  
  If you base your changes on Git, you have to add back in all the
  portability code (and any #if 0 you added as the maintainer for
  development/debugging).  Oh, and regular users cannot test any of your
  changes because they aren't willing to upgrade their entire kernel.
  
  If you base your changes on Hg, nothing merges cleanly when submitted
  upstream so your patches get rejected.
  
  Want to know why we are seeing regressions all over the place?
  Because *NOBODY* is testing the code until after the kernel goes
  stable (since while many are willing to install a v4l-dvb tree, very
  few will are willing to upgrade their entire kernel just to test one
  driver).  We've probably lost about 98% of our user base of testers.
 
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.
 
  Oh, and users have to git clone 500M+ of data, and not everybody in
  the world has bandwidth fast enough to make that worth their time (it
  took me several hours last time I did it).
 
 Currently the media_build tree copies the drivers from a git tree. Which, as
 you say, can be a big problem for non-developers. But all it really needs are
 the media drivers. So perhaps it might be a good idea to make a daily snapshot
 of the drivers and make it available for download on linuxtv.org. That archive
 is only 3.5 MB, so much easier to download.
 
  Anyway, I've beaten this horse to death and it's fallen on deaf ears.
  Merge overhead has reached the point where it's just not worth my
  time/effort to submit anything upstream anymore.
 
 The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
 much work. Any attempt to work from the hg tree is doomed. The media_build
 seems to be a viable alternative. As a developer you still have to go through
 the painful process of cloning the git repo, but it is a one time thing. Once
 it's cloned then you only have to follow the new commits, which is much, much
 faster.
 
 And regarding regressions: I'm amazed how few regressions we have considering
 the furious rate of development. The media subsystem is still one of the most
 active subsystems in the kernel and probably will remain so for the forseeable
 future as well.

Regressions can be detected only if you have enough testers!

With the current situation, it is very likely that regressions will not
show up before major linux distributions switch to a new kernel.
Afaics the user base is neglectible at the moment. So you can expect
that regressions will show up months after release of a new kernel.

Anyway, this is off-topic. I was not talking about regressions.

 It would be a shame not to submit patches upstream, that never ends well in
 the long run.
 
 With respect to '#if 0': for the most part I'd say: good riddance. In my
 many years of experience as a SW engineer I have never seen anyone actually
 turn on '#if 0' code once it's been in the code for more than, say, a year.
 Usually people just leave it there because they are too lazy to remove it,
 or they don't understand what it is for and are too scared to remove it.
 
 If it is code partially implementing a feature that needs more work, then
 it may sound like a good idea to keep it. However, after it's in the code for
 more than a year, then nobody remembers what the code was about and what still
 had to be done to make it work. And it's hell to figure that out after such a
 long time. Never put such code in the mainline. Keep it in a branch if you
 have to.
 
 Anyway, if there is some '#if 0' code that you want to preserve in git, then
 you have to make a patch to add it. But you probably will have to have very
 good reasons for adding '#if 0' code to the mainline.

I do not care about some #ifdef'ed printk statements.

There are large pieces of driver code which

Re: Debug code in HG repositories

2011-01-07 Thread Vincent McIntyre

On 1/8/11, Hans Verkuil hverk...@xs4all.nl wrote:

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.


As an end-user I would be interested in seeing this added, since it
will allow faster detection of breakage in the older versions. For
instance building against 2.6.32 fails like this:

  CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
function 'hdpvr_new_i2c_ir':
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
too many arguments to function 'i2c_new_probed_device'
make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
Error 1
make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
make: *** [default] Error 2

It's unclear that adding this would cause a lot of extra work; the
patches that need to be applied are quite few - a tribute to the
design work!

For what it's worth, I've attached the shell script I use to pull
updates and do a new build.
Doing the initial setup is well explained by the
linuxtv.org/media_tree.git page,
but this script may be of use to end users wanting to track development.

Cheers
Vince


update-and-build.sh
Description: Bourne shell script

[GIT PULL FOR 2.6.38] af9013 IF config fix

2011-01-07 Thread Antti Palosaari


Moi Mauro,

PULL that bug fix to the 2.6.38

t. Antti


The following changes since commit 0a97a683049d83deaf636d18316358065417d87b:

  [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 
-0200)


are available in the git repository at:
  git://linuxtv.org/anttip/media_tree.git af9015

Antti Palosaari (1):
  af9013: fix AF9013 TDA18271 IF config

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

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

Re: Debug code in HG repositories

2011-01-07 Thread VDR User

On Fri, Jan 7, 2011 at 1:06 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.

I'd just like to note that I have been using the media_build daily
snapshots with much success.  IMO, it's about as close as you're going
to get to the old hg system.  As a (mostly) end-user, I am one of the
people unwilling to hassle with the entire git tree (kernel included),
but since the introduction of media_build, we're once again able to
test new code much like we did before.  I strongly urge any end-user
who hasn't given it a try, to do so.

Regards,
Derek
--
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: Debug code in HG repositories

2011-01-07 Thread Jarod Wilson

On Jan 7, 2011, at 3:13 PM, Devin Heitmueller wrote:

 On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Hi guys,
 
 are you aware that there is a lot of '#if 0' code in the HG repositories
 which is not in GIT?
 
 When drivers were submitted to the kernel from HG, the '#if 0' stuff was
 stripped, unless it was marked as 'keep'...
 
 This was fine, when development was done with HG.
 
 As GIT is being used now, that code will be lost, as soon as the HG
 repositories have been removed...
 
 Any opinions how this should be handled?
 
 CU
 Oliver
 
 I complained about this months ago.  The problem is that when we were
 using HG, the HG repo was a complete superset of what went into Git
 (including development/debug code).  But now that we use Git, neither
 is a superset of the other.
 
 If you base your changes on Git, you have to add back in all the
 portability code (and any #if 0 you added as the maintainer for
 development/debugging).  Oh, and regular users cannot test any of your
 changes because they aren't willing to upgrade their entire kernel.
 
 If you base your changes on Hg, nothing merges cleanly when submitted
 upstream so your patches get rejected.
 
 Want to know why we are seeing regressions all over the place?
 Because *NOBODY* is testing the code until after the kernel goes
 stable (since while many are willing to install a v4l-dvb tree, very
 few will are willing to upgrade their entire kernel just to test one
 driver).  We've probably lost about 98% of our user base of testers.

What Hans said re: media_build. I've been pointing quite a few people on
the mythtv-users mailing list in that direction for updated drivers on
top of their distro kernels.

Additionally, the current Fedora 14 kernels (which are 2.6.35.10-based)
carry a patchset developed using media_build with essentially the 2.6.38
rc1 snapshot code, so a fair number of Fedora users *are* testing this
code long before its in a stable upstream kernel release.


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

54 matches

Mail list logo