Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
Am Mittwoch, 5. Oktober 2011, 07:58:51 schrieb Antti Palosaari: On 10/05/2011 07:59 AM, Greg KH wrote: Why not just use the usb-serial core and then you get a ttyUSB* device node for free? It also should provide a lot of the basic tty infrastructure and ring buffer logic all ready to use. Since I don't see how I can access same platform data from DVB USB and USB-serial driver (usb_set_intfdata). I asked that earlier, see: http://www.mail-archive.com/linux-media@vger.kernel.org/msg36027.html Yes, and I'll have to give you the same answer as then. But, Greg, Antti makes a very valid point here. The generic code assumes that it owns intfdata, that is you cannot use it as is for access to anything that lacks its own interface. But this is not a fatal flaw. We can alter the generic code to use an accessor function the driver can provide and make it default to get/set_intfdata What do you think? Regards Oliver -- - - - SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany - - - -- 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: serial device name for smart card reader that is integrated to Anysee DVB USB device
On 10/05/2011 09:15 AM, Oliver Neukum wrote: Am Mittwoch, 5. Oktober 2011, 07:58:51 schrieb Antti Palosaari: On 10/05/2011 07:59 AM, Greg KH wrote: Why not just use the usb-serial core and then you get a ttyUSB* device node for free? It also should provide a lot of the basic tty infrastructure and ring buffer logic all ready to use. Since I don't see how I can access same platform data from DVB USB and USB-serial driver (usb_set_intfdata). I asked that earlier, see: http://www.mail-archive.com/linux-media@vger.kernel.org/msg36027.html Yes, and I'll have to give you the same answer as then. But, Greg, Antti makes a very valid point here. The generic code assumes that it owns intfdata, that is you cannot use it as is for access to anything that lacks its own interface. But this is not a fatal flaw. We can alter the generic code to use an accessor function the driver can provide and make it default to get/set_intfdata What do you think? Oliver, I looked your old thread reply but I didn't catch how you meant it to happen. Could you give some small example? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
On Wed, Oct 05, 2011 at 08:15:17AM +0200, Oliver Neukum wrote: Am Mittwoch, 5. Oktober 2011, 07:58:51 schrieb Antti Palosaari: On 10/05/2011 07:59 AM, Greg KH wrote: Why not just use the usb-serial core and then you get a ttyUSB* device node for free? It also should provide a lot of the basic tty infrastructure and ring buffer logic all ready to use. Since I don't see how I can access same platform data from DVB USB and USB-serial driver (usb_set_intfdata). I asked that earlier, see: http://www.mail-archive.com/linux-media@vger.kernel.org/msg36027.html Yes, and I'll have to give you the same answer as then. But, Greg, Antti makes a very valid point here. The generic code assumes that it owns intfdata, that is you cannot use it as is for access to anything that lacks its own interface. But this is not a fatal flaw. We can alter the generic code to use an accessor function the driver can provide and make it default to get/set_intfdata What do you think? I totally forgot about that previous answer, I write too much email :) Anyway, yes, if we can alter the core to make this work for this type of device, that is probably much easier than having to write a whole tty driver just for this one type of device. I'll gladly take such a patch. thanks, greg k-h -- 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: [RFCv4 PATCH 0/6]: add poll_requested_events() function
On Thursday 29 September 2011 09:44:06 Hans Verkuil wrote: This is the fourth version of this patch series, incorporating the comments from Andrew Morton: I've split up the multiple-assignment line and added a comment explaining the purpose of the new function in poll.h. It's also rebased to the current staging/for_v3.2 branch of the linux-media tree. There are no other changes compared to the RFCv3 patches. I'd very much like to get an Acked-by (or additional comments) from Al or Andrew! This patch series really should go into v3.2 which is getting close. Normally I would have posted this v4 3 weeks ago, but due to Real Life interference in the past few weeks I was unable to. But I'm back, and this is currently the highest priority for me. This is becoming annoying. Andrew, Al, can one of you please Ack this patch or review it? We *really* need this enhancement for our v4l drivers. I've been asking for an ack (or review) for ages and for the most part I got radio silence. Jon Corbet has already reviewed the code in early July (!), so I don't see why this is taking so long. Mauro needs an ack from one of you before he can merge it. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
Am Mittwoch, 5. Oktober 2011, 08:19:10 schrieb Antti Palosaari:
On 10/05/2011 09:15 AM, Oliver Neukum wrote:
But, Greg, Antti makes a very valid point here. The generic code assumes
that
it owns intfdata, that is you cannot use it as is for access to anything
that lacks
its own interface. But this is not a fatal flaw. We can alter the generic
code to use
an accessor function the driver can provide and make it default to
get/set_intfdata
What do you think?
Oliver, I looked your old thread reply but I didn't catch how you meant
it to happen. Could you give some small example?
Look at this structure:
struct dvb_usb_device {
struct dvb_usb_device_properties props;
struct dvb_usb_device_description *desc;
struct usb_device *udev;
#define DVB_USB_STATE_INIT0x000
#define DVB_USB_STATE_I2C 0x001
#define DVB_USB_STATE_DVB 0x002
#define DVB_USB_STATE_REMOTE 0x004
int state;
int powered;
/* locking */
struct mutex usb_mutex;
/* i2c */
struct mutex i2c_mutex;
struct i2c_adapter i2c_adap;
intnum_adapters_initialized;
struct dvb_usb_adapter adapter[MAX_NO_OF_ADAPTER_PER_DEVICE];
/* remote control */
struct rc_dev *rc_dev;
struct input_dev *input_dev;
char rc_phys[64];
struct delayed_work rc_query_work;
u32 last_event;
int last_state;
struct module *owner;
void *priv;
};
It contains a pointer to an input device. You could add a pointer to a usb
serial device here. This leaves you with two problems.
1. The USB serial layer will try to set intfdata
We will need to change it to use a function the driver provides to store
a pointer to its private data.
2. The usb serial layer will not learn about events it needs to learn about.
We need to extended the usb dvb code to call into a sufficiently abstracted
method in the usb serial code.
Conceptually the usb serial code is ready to share an interface among
multiple serial ports, but not to share an interface with something else.
I described the steps necesary to allow that. This is new, so there are
no examples.
Regards
Oliver
--
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] media_build: two fixes + one unresolved issue
Hi Mauro,
While doing a compatibility build I found three issues. I've got patches for
two,
but one issue is still unresolved.
The first is this small patch to get rid of this warning when doing 'make
install':
make -C firmware install
make[2]: Entering directory `/home/hve/work/media_build/v4l/firmware'
Installing firmwares at /lib/firmware: vicam/firmware.fw dabusb/firmware.fw
dabusb/bitstream.bin ttusb-budget/dspbootcode.bin
cpia2/stv0672_vp4.bin av7110/bootcode.bin *.fw* cp: target
`/lib/firmware/v4l-pvrusb2-29xxx-01.fw' is not a directory
make[2]: [install] Error 1 (ignored)
The fix is simply to remove '*.fw*' since it doesn't match any files.
diff --git a/v4l/firmware/Makefile b/v4l/firmware/Makefile
index fb53ef2..bcbc784 100644
--- a/v4l/firmware/Makefile
+++ b/v4l/firmware/Makefile
@@ -22,7 +22,7 @@ distclean: clean
install: default
@echo -n Installing firmwares at $(FW_DIR):
-@for i in $(DIRS); do if [ ! -d $(FW_DIR)/$$i ]; then mkdir -p
$(FW_DIR)/$$i; fi; done
- -@for i in $(TARGETS) *.fw*; do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done
+ -@for i in $(TARGETS); do echo -n $$i ; cp $$i $(FW_DIR)/$$i; done
@echo
rminstall:
I think this fix is fine, unless this is something you want to have for the
future.
The other is a kernel naming issue: my aptosid distro (debian based) running
kernel v3.0.0 uses a different naming convention:
$ uname -r
3.0-4.slh.6-aptosid-amd64
So the sublevel is not shown.
This patch makes the sublevel optional (and assumes it to be 0 if absent):
diff --git a/linux/patches_for_kernel.pl b/linux/patches_for_kernel.pl
index c19b216..33348d9 100755
--- a/linux/patches_for_kernel.pl
+++ b/linux/patches_for_kernel.pl
@@ -13,8 +13,11 @@ my $file = ../backports/backports.txt;
open IN, $file or die can't find $file\n;
sub kernel_version($) {
- $_[0] =~ m/^(\d+)\.(\d+)\.(\d+)/;
- return ($1*65536 + $2*256 + $3);
+ my $sublevel;
+
+ $_[0] =~ m/^(\d+)\.(\d+)\.?(\d*)/;
+ $sublevel = $3 == ? 0 : $3;
+ return ($1*65536 + $2*256 + $sublevel);
}
my $kernel = kernel_version($version);
diff --git a/v4l/Makefile b/v4l/Makefile
index ab07a7a..311924e 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -248,7 +248,7 @@ ifneq ($(VER),)
@echo $(VER)|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n,$$1,$$2,$$3,$$1,$$2,$$3,$$4);
};' $(obj)/.version
else
@echo No version yet, using `uname -r`
- @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) { printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.
%s.%s%s\n,$$1,$$2,$$3,$$1,$$2,$$3,$$4); };' $(obj)/.version
+ @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.?([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s,$$1,$$2,$$3==?0:$$3,$$_);
};' $(obj)/.version
endif
endif
The last issue I have is that the media.ko module isn't installed when I run
'make install'. I tried to fix it, but I got lost in the Makefile/perl magic :-)
Let me know if you are OK with these two patches, and if you can fix the last
issue (or give me some hints on how to fix it), then that would be great!
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE.request information
Thanks for the reply. As suggested in the possible numbers of cards, I found the number (card = 174) which allows the card to scan for TV frequencies. Unfortunately the scan does not finish successfully, because it also needs the identification of the tuner. Have suggestions for the number of tuners. Waiting for your suggestion for the number of tuners to try, I would like to write for confirmation of ASUSTeK (Device [1043:8188]) have an address where I can write. Thank you for the answer LD Il 03/10/2011 20:50, Charlie X. Liu ha scritto: Checking in the CARDLIST.saa7134 ( http://www.mjmwired.net/kernel/Documentation/video4linux/CARDLIST.saa7134 ), sounds, it (Device [1043:8188]) is not in the CARDLIST yet. Then, you may check with ASUSTeK and see which one in the CARDLIST is closer to it. Like: 78 - ASUSTeK P7131 Dual [1043:4862] 112 - ASUSTeK P7131 Hybrid [1043:4876] 146 - ASUSTeK P7131 Analog .. .. 174 - Asus Europa Hybrid OEM [1043:4847] -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of LD Sent: Sunday, October 02, 2011 7:47 AM To: linux-media@vger.kernel.org Subject: request information I would like to know which firmware and drivers are helpful to install and set this type of card: Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d0) Subsystem: ASUSTeK Computer Inc. Device [1043:8188] Control: I/O- Mem + BusMaster + SpecCycle-MemWINV-VGASnoop-ParErr-Stepping-SERR-FastB2B-DisINTx- Status: Cap + 66MHz-UDF-FastB2B + ParErr-DEVSEL = medium TAbort-TAbort-MAbort- SERR-PERR-intX- Latency: 64 (21000ns min, 8000ns max) Interrupt: pin A routed to IRQ 23 Region 0: Memory at dbedb800 (32-bit, non-prefetchable) [size = 2K] Capabilities:access denied Kernel driver in use: saa7134 Kernel modules: saa7134 Thank you for the answer LD -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with omap3isp resizing
On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
Hi Ivan,
On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
I've been having trouble getting the resizer to work, and
mainly because I don't know how to correctly configure it.
I'm using kernel 2.6.37 on arm DM37x board.
I've been able to configure the media links
sensor=ccdc=ccdc_output (all with 640x480
V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
/dev/video2.
But if I configure media links
sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON
fails on /dev/video6 (with pixelformat mismatch). I noticed
that the resizer driver only supports
V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16, so I
tried again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16
instead, but then ioctl VIDIOC_SUBDEV_S_FMT fails on
/dev/v4l-subdev8, because the sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed
with pixelformat mismatch or link pipeline mismatch, depending
on which pads were different.
Can someone please tell me what I need to do to make this work?
Long story short, I don't think that pipeline has ever been tested.
I'm unfortunately lacking hardware to work on that, as none of
my
OMAP3 hardware has a YUV input.
If i am not mistaken currently resizer sub device supports only:
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
};
Adding something like this [1] in ispresizer.c should add support
2X8 formats. Completely untested :-).
Regards,
iivanov
[1]
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct
v4l2_subdev *sd, struct v4l2_subdev_fh *fh, static const unsigned
int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
};
I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What
do you think ?
For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
But the original poster wants to use the sensor - ccdc - resizer -
resizer output
pipeline.
Also several sensor drivers that i have checked, usually define its
output as 2X8 output. I think is more natural to add 2X8 support to
CCDC and Resizer engines instead to modifying exiting drivers.
Sure, sensor drivers should not be modified. What I was talking about was to
configure the pipeline as
sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
[YUYV8_1X16]
--
Regards,
Laurent Pinchart
Thanks for your help. I've updated ispccdc.c to support the _1X16 codes
and the pipeline seems to work now. However, I needed to take out the
memcpy in ccdc_try_format(), because otherwise pad 0 format was being
copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm
not sure why it was done that way. I think it's better that the given code
gets checked to see if it's in the list and if so use it. Do you know of
any valid reason why this copy is done?
If I remember corretly, it's because there's nothing the CCDC may do to the
size of the image --- the driver doesn't either support cropping on the
CCDC. The sink format used to be always the same as the source format, the
assumption which no longer is valid when YUYV8_2X8 etc. formats are
supported. This must be taken into account, i.e. YUYV8_2X8 must be converted
to YUYV8_1X16 instead of just copying the format as such.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On Tue, Sep 6, 2011 at 10:49 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Monday 05 September 2011 18:37:04 you wrote: Yes that was the first thing i tried, anyway now i have it finally working. Well at least yavta doesn't hang, do you know some application to see raw yuv images? I made a typo since in fact it's uyvy ( so a tool to covert from yuv will not work ;) ), but if someone will ever need it: ffmpeg -f rawvideo -pix_fmt uyvy422 -s 720x628 -i frame-01.bin frame-1.png Enrico Enrico, Gary, I am in an identical situation to you both in that I am migrating to a newer kernel and am faced with the task of getting a driver for the tvp5150 working with the new MC framework and omap3 ISP. I understand from reading this thread that you have both had some success in modifying an existing / writing a driver and configuring a MC pipeline. If you are able to share your driver(s) or any insights, I would be very grateful and I am happy to help out with further testing or polishing as required. Best Regards Adam -- 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] af9013 frontend tuner bus lock
2011/10/5 Jason Hecker jwhec...@gmail.com: Which Firmware are your using? 4.95 Yes, because it is also happening with other duo devices on Myth TV 0.24.1 OK, well that is what I am using so I guess I am stuck until it's fixed. Josu what software and versions are you using? Hello, I am using this firmware: http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw The MythTV version is the 0.24.1-0.0squeeze1 version of debian-multimedia.org (stable) repository. This morning I get a little pixeled playback, less than a second. Best regards. -- Josu Lazkano -- 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] media_build: two fixes + one unresolved issue
Em 05-10-2011 06:23, Hans Verkuil escreveu:
Hi Mauro,
While doing a compatibility build I found three issues. I've got patches for
two,
but one issue is still unresolved.
The first is this small patch to get rid of this warning when doing 'make
install':
make -C firmware install
make[2]: Entering directory `/home/hve/work/media_build/v4l/firmware'
Installing firmwares at /lib/firmware: vicam/firmware.fw dabusb/firmware.fw
dabusb/bitstream.bin ttusb-budget/dspbootcode.bin
cpia2/stv0672_vp4.bin av7110/bootcode.bin *.fw* cp: target
`/lib/firmware/v4l-pvrusb2-29xxx-01.fw' is not a directory
make[2]: [install] Error 1 (ignored)
The fix is simply to remove '*.fw*' since it doesn't match any files.
diff --git a/v4l/firmware/Makefile b/v4l/firmware/Makefile
index fb53ef2..bcbc784 100644
--- a/v4l/firmware/Makefile
+++ b/v4l/firmware/Makefile
@@ -22,7 +22,7 @@ distclean: clean
install: default
@echo -n Installing firmwares at $(FW_DIR):
-@for i in $(DIRS); do if [ ! -d $(FW_DIR)/$$i ]; then mkdir -p
$(FW_DIR)/$$i; fi; done
- -@for i in $(TARGETS) *.fw*; do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done
+ -@for i in $(TARGETS); do echo -n $$i ; cp $$i $(FW_DIR)/$$i; done
@echo
I suspect that, for some unknown reason, you're not capable of downloading the
firmwares from
linuxtv.org, or maybe you never ran the build script. The build firmware
downloads the latest
version of the firmwares from:
http://www.linuxtv.org/downloads/firmware/
It should be noticed that the install procedure won't fail if you never
downloaded the firmwares,
due to the - signal. So, please don't apply this patch.
rminstall:
I think this fix is fine, unless this is something you want to have for the
future.
The other is a kernel naming issue: my aptosid distro (debian based) running
kernel v3.0.0 uses a different naming convention:
$ uname -r
3.0-4.slh.6-aptosid-amd64
So the sublevel is not shown.
This patch makes the sublevel optional (and assumes it to be 0 if absent):
diff --git a/linux/patches_for_kernel.pl b/linux/patches_for_kernel.pl
index c19b216..33348d9 100755
--- a/linux/patches_for_kernel.pl
+++ b/linux/patches_for_kernel.pl
@@ -13,8 +13,11 @@ my $file = ../backports/backports.txt;
open IN, $file or die can't find $file\n;
sub kernel_version($) {
- $_[0] =~ m/^(\d+)\.(\d+)\.(\d+)/;
- return ($1*65536 + $2*256 + $3);
+ my $sublevel;
+
+ $_[0] =~ m/^(\d+)\.(\d+)\.?(\d*)/;
+ $sublevel = $3 == ? 0 : $3;
+ return ($1*65536 + $2*256 + $sublevel);
}
my $kernel = kernel_version($version);
diff --git a/v4l/Makefile b/v4l/Makefile
index ab07a7a..311924e 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -248,7 +248,7 @@ ifneq ($(VER),)
@echo $(VER)|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n,$$1,$$2,$$3,$$1,$$2,$$3,$$4);
};' $(obj)/.version
else
@echo No version yet, using `uname -r`
- @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) { printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.
%s.%s%s\n,$$1,$$2,$$3,$$1,$$2,$$3,$$4); };' $(obj)/.version
+ @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.?([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s,$$1,$$2,$$3==?0:$$3,$$_);
};' $(obj)/.version
endif
endif
Seems OK to me. If you're willing to fix those distro-specific stuff, on Fedora
15,
the 3.0 kernel were renamed as 2.40, as they wanted to avoid touching on some
scripts
(that's what I got from a lwn discussion). Maybe other distros might have done
weird
things like that. The only practical consequence I noticed with F15 is that one
driver
were disabled (the firewire one).
The last issue I have is that the media.ko module isn't installed when I run
'make install'. I tried to fix it, but I got lost in the Makefile/perl magic
:-)
That's weird... I took a look here. My Makefile.media was generated with a line
to install it. See:
@n=0;for i in dvb-ttpci.ko budget-patch.ko ttpci-eeprom.ko budget-av.ko
budget.ko budget-core.ko budget-ci.ko;do if [ -f
$$i ]; then if [ $$n -eq 0 ]; then echo -n dvb/ttpci/: ; install -d
$(DESTDIR)$(KDIR26)/dvb/ttpci; fi; n=$$(($$n+1)); if [
$$n -eq 4 ]; then echo; echo -n ; n=1; fi; echo -n $$i ;
install -m 644 -c $$i $(DESTDIR)$(KDIR26)/dvb/ttpci;
fi; done; if [ $$n -ne 0 ]; then echo; strip --strip-debug
$(DESTDIR)$(KDIR26)/dvb/ttpci/*.ko; fi;
@n=0;for i in media.ko;do if [ -f $$i ]; then if [ $$n -eq 0 ]; then echo -n
../linux/drivers/media/: ; insta
ll -d $(DESTDIR)$(KDIR26)/../linux/drivers/media; fi; n=$$(($$n+1)); if [ $$n
-eq 4 ]; then echo; echo -n ; n=1; f
i; echo -n $$i ; install -m 644 -c $$i
$(DESTDIR)$(KDIR26)/../linux/drivers/media; fi; done; if [ $$n -ne 0 ]; then
echo; stri
p
Re: Help with omap3isp resizing
On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote: On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: Thanks for your help. I've updated ispccdc.c to support the _1X16 codes and the pipeline seems to work now. However, I needed to take out the memcpy in ccdc_try_format(), because otherwise pad 0 format was being copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm not sure why it was done that way. I think it's better that the given code gets checked to see if it's in the list and if so use it. Do you know of any valid reason why this copy is done? If I remember corretly, it's because there's nothing the CCDC may do to the size of the image --- the driver doesn't either support cropping on the CCDC. The sink format used to be always the same as the source format, the assumption which no longer is valid when YUYV8_2X8 etc. formats are supported. This must be taken into account, i.e. YUYV8_2X8 must be converted to YUYV8_1X16 instead of just copying the format as such. Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems possible to set some registers (start pixel horizontal/vertical and so on...) to crop the final image, but i never tested it. Enrico -- 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
holiday absence
Hi all I am on a holiday beginning tomorrow and until 16th October. Hopefully, my 3.2 push will get through, the rest might have to wait until 3.3, unless we manage to get them later in the 3.2 cycle. I'll try to check my mails from time to time, but I _definitely_ will not be able to do any work:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with omap3isp resizing
On Wed, Oct 05, 2011 at 03:09:48PM +0200, Enrico wrote: On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote: On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: Thanks for your help. I've updated ispccdc.c to support the _1X16 codes and the pipeline seems to work now. However, I needed to take out the memcpy in ccdc_try_format(), because otherwise pad 0 format was being copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm not sure why it was done that way. I think it's better that the given code gets checked to see if it's in the list and if so use it. Do you know of any valid reason why this copy is done? If I remember corretly, it's because there's nothing the CCDC may do to the size of the image --- the driver doesn't either support cropping on the CCDC. The sink format used to be always the same as the source format, the assumption which no longer is valid when YUYV8_2X8 etc. formats are supported. This must be taken into account, i.e. YUYV8_2X8 must be converted to YUYV8_1X16 instead of just copying the format as such. Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems possible to set some registers (start pixel horizontal/vertical and so on...) to crop the final image, but i never tested it. Yeah; cropping should work fine on the CCDC as well but the driver doesn't implement it. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] media_build: two fixes + one unresolved issue
On Wednesday 05 October 2011 14:46:16 Mauro Carvalho Chehab wrote:
Em 05-10-2011 06:23, Hans Verkuil escreveu:
Hi Mauro,
While doing a compatibility build I found three issues. I've got patches
for two, but one issue is still unresolved.
The first is this small patch to get rid of this warning when doing 'make
install':
make -C firmware install
make[2]: Entering directory `/home/hve/work/media_build/v4l/firmware'
Installing firmwares at /lib/firmware: vicam/firmware.fw
dabusb/firmware.fw dabusb/bitstream.bin ttusb-budget/dspbootcode.bin
cpia2/stv0672_vp4.bin av7110/bootcode.bin *.fw* cp: target
`/lib/firmware/v4l-pvrusb2-29xxx-01.fw' is not a directory make[2]:
[install] Error 1 (ignored)
The fix is simply to remove '*.fw*' since it doesn't match any files.
diff --git a/v4l/firmware/Makefile b/v4l/firmware/Makefile
index fb53ef2..bcbc784 100644
--- a/v4l/firmware/Makefile
+++ b/v4l/firmware/Makefile
@@ -22,7 +22,7 @@ distclean: clean
install: default
@echo -n Installing firmwares at $(FW_DIR):
-@for i in $(DIRS); do if [ ! -d $(FW_DIR)/$$i ]; then mkdir -p
$(FW_DIR)/$$i; fi; done
- -@for i in $(TARGETS) *.fw*; do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done + -@for i in $(TARGETS); do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done
@echo
I suspect that, for some unknown reason, you're not capable of downloading
the firmwares from linuxtv.org, or maybe you never ran the build script.
I never ran the build script. I'm just using 'make dir'.
The build firmware downloads the latest version of the firmwares from:
http://www.linuxtv.org/downloads/firmware/
It should be noticed that the install procedure won't fail if you never
downloaded the firmwares, due to the - signal. So, please don't apply
this patch.
I'll apply this patch instead:
- -@for i in $(TARGETS) *.fw*; do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done
+ -@for i in $(TARGETS) $(wildcard *.fw*); do echo -n $$i ; cp $$i
$(FW_DIR)/$$i; done
The make wildcard function resolves to nothing if the pattern can't be matched,
thus avoiding the error.
rminstall:
I think this fix is fine, unless this is something you want to have for
the future.
The other is a kernel naming issue: my aptosid distro (debian based)
running kernel v3.0.0 uses a different naming convention:
$ uname -r
3.0-4.slh.6-aptosid-amd64
So the sublevel is not shown.
This patch makes the sublevel optional (and assumes it to be 0 if
absent):
diff --git a/linux/patches_for_kernel.pl b/linux/patches_for_kernel.pl
index c19b216..33348d9 100755
--- a/linux/patches_for_kernel.pl
+++ b/linux/patches_for_kernel.pl
@@ -13,8 +13,11 @@ my $file = ../backports/backports.txt;
open IN, $file or die can't find $file\n;
sub kernel_version($) {
- $_[0] =~ m/^(\d+)\.(\d+)\.(\d+)/;
- return ($1*65536 + $2*256 + $3);
+ my $sublevel;
+
+ $_[0] =~ m/^(\d+)\.(\d+)\.?(\d*)/;
+ $sublevel = $3 == ? 0 : $3;
+ return ($1*65536 + $2*256 + $sublevel);
}
my $kernel = kernel_version($version);
diff --git a/v4l/Makefile b/v4l/Makefile
index ab07a7a..311924e 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -248,7 +248,7 @@ ifneq ($(VER),)
@echo $(VER)|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n,
$$1,$$2,$$3,$$1,$$2,$$3,$$4); };' $(obj)/.version
else
@echo No version yet, using `uname -r`
- @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) { printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.
%s.%s%s\n,$$1,$$2,$$3,$$1,$$2,$$3,$$4); };' $(obj)/.version
+ @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.?([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s,$$1,$$2,$
$3==?0:$$3,$$_); };' $(obj)/.version
endif
endif
Seems OK to me. If you're willing to fix those distro-specific stuff, on
Fedora 15, the 3.0 kernel were renamed as 2.40, as they wanted to avoid
touching on some scripts (that's what I got from a lwn discussion). Maybe
other distros might have done weird things like that. The only practical
consequence I noticed with F15 is that one driver were disabled (the
firewire one).
I'll see if I can make a patch for this.
The last issue I have is that the media.ko module isn't installed when I
run 'make install'. I tried to fix it, but I got lost in the
Makefile/perl magic :-)
That's weird... I took a look here. My Makefile.media was generated with a
line to install it. See:
@n=0;for i in dvb-ttpci.ko budget-patch.ko ttpci-eeprom.ko budget-av.ko
budget.ko budget-core.ko budget-ci.ko;do if [ -f $$i ]; then if [ $$n
-eq 0 ]; then echo -ndvb/ttpci/: ; install -d
$(DESTDIR)$(KDIR26)/dvb/ttpci; fi; n=$$(($$n+1)); if [ $$n -eq 4 ]; then
echo;
Re: [PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
Mauro:
With the line you've just added, then the = arg assignment in the
immediate prior line is effectively dead code. Try this instead:
case VIDIOC_QUERYSTD:
{
- v4l2_std_id *std = arg;
+ v4l2_std_id *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
-Mike
On Tue, 4 Oct 2011, Mauro Carvalho Chehab wrote:
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 0d029da..ce7ac45 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_QUERYSTD:
{
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with omap3isp resizing
On Wed, Oct 5, 2011 at 3:42 PM, Sakari Ailus sakari.ai...@iki.fi wrote: On Wed, Oct 05, 2011 at 03:09:48PM +0200, Enrico wrote: On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote: On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: Thanks for your help. I've updated ispccdc.c to support the _1X16 codes and the pipeline seems to work now. However, I needed to take out the memcpy in ccdc_try_format(), because otherwise pad 0 format was being copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm not sure why it was done that way. I think it's better that the given code gets checked to see if it's in the list and if so use it. Do you know of any valid reason why this copy is done? If I remember corretly, it's because there's nothing the CCDC may do to the size of the image --- the driver doesn't either support cropping on the CCDC. The sink format used to be always the same as the source format, the assumption which no longer is valid when YUYV8_2X8 etc. formats are supported. This must be taken into account, i.e. YUYV8_2X8 must be converted to YUYV8_1X16 instead of just copying the format as such. Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems possible to set some registers (start pixel horizontal/vertical and so on...) to crop the final image, but i never tested it. Yeah; cropping should work fine on the CCDC as well but the driver doesn't implement it. Hello, Yes, cropping with the CCDC is possible, we modified the driver to only get the active lines of a frame. This is a small part of our patch that configures the CCDC to decide what is the first line to output to memory for both even and odd fields. + if (pdata-is_bt656) + if (format-priv == V4L2_STD_PAL) + isp_reg_writel(isp, (PAL_NON_ACTIVE +ISPCCDC_VERT_START_SLV0_SHIFT | +PAL_NON_ACTIVE +ISPCCDC_VERT_START_SLV1_SHIFT), + OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START); + else if (format-priv == V4L2_STD_NTSC) + isp_reg_writel(isp, (NTSC_NON_ACTIVE +ISPCCDC_VERT_START_SLV0_SHIFT | +NTSC_NON_ACTIVE +ISPCCDC_VERT_START_SLV1_SHIFT), + OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START); As I told in a previous email [1] we are working to get add proper support for ITU-R BT656 video data using the ISP and a TVP5151 video encoder. We are kind of busy to get this working for our tree. But once it is done, I'll forward port to the last ISP driver and post for review. [1]: http://www.spinics.net/lists/linux-media/msg38715.html Best regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: omap3isp: remove redundant operation
Hi Guennadi, Thanks for the patch. On Thursday 29 September 2011 12:57:00 Guennadi Liakhovetski wrote: Trivial arithmetics clean up. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've applied it to my tree. --- drivers/media/video/omap3isp/ispccdc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c index 40b141c..65ae267 100644 --- a/drivers/media/video/omap3isp/ispccdc.c +++ b/drivers/media/video/omap3isp/ispccdc.c @@ -1834,7 +1834,7 @@ ccdc_try_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh, * callers to request an output size bigger than the input size * up to the nearest multiple of 16. */ - fmt-width = clamp_t(u32, width, 32, (fmt-width + 15) ~15); + fmt-width = clamp_t(u32, width, 32, fmt-width + 15); fmt-width = ~15; fmt-height = clamp_t(u32, height, 32, fmt-height); break; -- 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] media_build: two fixes + one unresolved issue
Em 05-10-2011 10:45, Hans Verkuil escreveu:
On Wednesday 05 October 2011 14:46:16 Mauro Carvalho Chehab wrote:
Em 05-10-2011 06:23, Hans Verkuil escreveu:
Hi Mauro,
While doing a compatibility build I found three issues. I've got patches
for two, but one issue is still unresolved.
The first is this small patch to get rid of this warning when doing 'make
install':
make -C firmware install
make[2]: Entering directory `/home/hve/work/media_build/v4l/firmware'
Installing firmwares at /lib/firmware: vicam/firmware.fw
dabusb/firmware.fw dabusb/bitstream.bin ttusb-budget/dspbootcode.bin
cpia2/stv0672_vp4.bin av7110/bootcode.bin *.fw* cp: target
`/lib/firmware/v4l-pvrusb2-29xxx-01.fw' is not a directory make[2]:
[install] Error 1 (ignored)
The fix is simply to remove '*.fw*' since it doesn't match any files.
diff --git a/v4l/firmware/Makefile b/v4l/firmware/Makefile
index fb53ef2..bcbc784 100644
--- a/v4l/firmware/Makefile
+++ b/v4l/firmware/Makefile
@@ -22,7 +22,7 @@ distclean: clean
install: default
@echo -n Installing firmwares at $(FW_DIR):
-@for i in $(DIRS); do if [ ! -d $(FW_DIR)/$$i ]; then mkdir -p
$(FW_DIR)/$$i; fi; done
- -@for i in $(TARGETS) *.fw*; do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done + -@for i in $(TARGETS); do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done
@echo
I suspect that, for some unknown reason, you're not capable of downloading
the firmwares from linuxtv.org, or maybe you never ran the build script.
I never ran the build script. I'm just using 'make dir'.
If you don't run the script, it won't download the firmwares ;) The build script
does some sanity checks. It also offers a --git and --main-git to make
easier
for developers that work with git trees.
The build firmware downloads the latest version of the firmwares from:
http://www.linuxtv.org/downloads/firmware/
It should be noticed that the install procedure won't fail if you never
downloaded the firmwares, due to the - signal. So, please don't apply
this patch.
I'll apply this patch instead:
- -@for i in $(TARGETS) *.fw*; do echo -n $$i ; cp $$i $(FW_DIR)/$$i;
done
+ -@for i in $(TARGETS) $(wildcard *.fw*); do echo -n $$i ; cp $$i
$(FW_DIR)/$$i; done
The make wildcard function resolves to nothing if the pattern can't be matched,
thus avoiding the error.
Seems fine for me.
rminstall:
I think this fix is fine, unless this is something you want to have for
the future.
The other is a kernel naming issue: my aptosid distro (debian based)
running kernel v3.0.0 uses a different naming convention:
$ uname -r
3.0-4.slh.6-aptosid-amd64
So the sublevel is not shown.
This patch makes the sublevel optional (and assumes it to be 0 if
absent):
diff --git a/linux/patches_for_kernel.pl b/linux/patches_for_kernel.pl
index c19b216..33348d9 100755
--- a/linux/patches_for_kernel.pl
+++ b/linux/patches_for_kernel.pl
@@ -13,8 +13,11 @@ my $file = ../backports/backports.txt;
open IN, $file or die can't find $file\n;
sub kernel_version($) {
- $_[0] =~ m/^(\d+)\.(\d+)\.(\d+)/;
- return ($1*65536 + $2*256 + $3);
+ my $sublevel;
+
+ $_[0] =~ m/^(\d+)\.(\d+)\.?(\d*)/;
+ $sublevel = $3 == ? 0 : $3;
+ return ($1*65536 + $2*256 + $sublevel);
}
my $kernel = kernel_version($version);
diff --git a/v4l/Makefile b/v4l/Makefile
index ab07a7a..311924e 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -248,7 +248,7 @@ ifneq ($(VER),)
@echo $(VER)|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n,
$$1,$$2,$$3,$$1,$$2,$$3,$$4); };' $(obj)/.version
else
@echo No version yet, using `uname -r`
- @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.([0-9]*)(.*)$$/) { printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.
%s.%s%s\n,$$1,$$2,$$3,$$1,$$2,$$3,$$4); };' $(obj)/.version
+ @uname -r|perl -ne 'if (/^([0-9]*)\.([0-9])*\.?([0-9]*)(.*)$$/) {
printf
(VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s,$$1,$$2,$
$3==?0:$$3,$$_); };' $(obj)/.version
endif
endif
Seems OK to me. If you're willing to fix those distro-specific stuff, on
Fedora 15, the 3.0 kernel were renamed as 2.40, as they wanted to avoid
touching on some scripts (that's what I got from a lwn discussion). Maybe
other distros might have done weird things like that. The only practical
consequence I noticed with F15 is that one driver were disabled (the
firewire one).
I'll see if I can make a patch for this.
Ok, thanks!
The last issue I have is that the media.ko module isn't installed when I
run 'make install'. I tried to fix it, but I got lost in the
Makefile/perl magic :-)
That's weird... I took a look here. My Makefile.media was generated with a
line to install it. See:
@n=0;for i in dvb-ttpci.ko budget-patch.ko ttpci-eeprom.ko budget-av.ko
budget.ko budget-core.ko budget-ci.ko;do if [ -f $$i ]; then if [
omap3-isp status
Hi all, since we are all interested in this driver (and tvp5150) i'll try to make a summary of the current situation and understand what is needed to finally get it into the main tree instead of having to apply a dozen patches manually. The current status of git repositories/branches is: - main tree: working (i suppose) but no support for bt656 input - pinchartl/media: * omap3isp-omap3isp-next: i think it's in sync with linuxtv master (for the omap3-isp parts) * omap3isp-omap3isp-yuv: like ..next but with some additional format patches Floating patches: - Deepthy: sent patches (against mainline) to add bt656 support Laurent made some comments, i haven't seen a v2 to be applied - Javier: sent patches for tvp5150, currently discussed on linux-media; possible patches/fixes for omap3-isp Now what can we all do to converge to a final solution? I think this is also blocking the possible development/test of missing features, like the recently-discussed resizer and cropping ones. Enrico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3-isp status
On Wed, Oct 5, 2011 at 6:28 PM, Enrico ebut...@users.berlios.de wrote: Hi all, since we are all interested in this driver (and tvp5150) i'll try to make a summary of the current situation and understand what is needed to finally get it into the main tree instead of having to apply a dozen patches manually. The current status of git repositories/branches is: - main tree: working (i suppose) but no support for bt656 input - pinchartl/media: * omap3isp-omap3isp-next: i think it's in sync with linuxtv master (for the omap3-isp parts) * omap3isp-omap3isp-yuv: like ..next but with some additional format patches Floating patches: - Deepthy: sent patches (against mainline) to add bt656 support Laurent made some comments, i haven't seen a v2 to be applied - Javier: sent patches for tvp5150, currently discussed on linux-media; possible patches/fixes for omap3-isp I will find some free time slots to resolve the issues called out by Sakari, Hans and Mauro and resend the patch-set for the tvp5151. Also I can send the patches of the modifications I made to the ISP driver. Right now I'm working on top of Deepthy patches. I can either send on top of that patch or rebase to mainline, whatever you think is better for reviewing. Now what can we all do to converge to a final solution? I think this is also blocking the possible development/test of missing features, like the recently-discussed resizer and cropping ones. Enrico Right now I have a working the tvp5151 with the ISP. I can capture ITU-R BT656 video both in PAL-M and NTSC standard. Also, the whole pipeline is configured automatically with the video standard detected by the tvp5151. Also, I'm using the CCDC to crop the frames and only capture the active lines for each standard (576 for PAL and 480 for NTSC) using the CCDC to crop the image. Tomorrow we will push our patches to one of our development trees so you can review it. Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Oct 5 19:00:15 CEST 2011 git hash:2f4cf2c3a971c4d5154def8ef9ce4811d702852d gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
Em 05-10-2011 11:00, Mike Isely escreveu:
Mauro:
With the line you've just added, then the = arg assignment in the
immediate prior line is effectively dead code. Try this instead:
Look better:
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
The above code is creating a pointer 'std' of the type 'v4l2_std_id', and
initializing the pointer with the void *arg.
Then, it is doing an indirect reference to the pointer, filling its
contents with V4L2_STD_ALL value.
The code above is sane (and, btw, it works). After those patches, the
detection code will detect PAL/M or NTSC/M depending on the channel I
tune here (my cable operator broadcasts some channels with one format,
and others with the other one). Before this patch and the msp3400, it
would return a mask with PAL/M and PAL/60 or a mask with all NTSC/M formats.
Regards,
Mauro.
case VIDIOC_QUERYSTD:
{
- v4l2_std_id *std = arg;
+ v4l2_std_id *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
-Mike
On Tue, 4 Oct 2011, Mauro Carvalho Chehab wrote:
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 0d029da..ce7ac45 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
case VIDIOC_QUERYSTD:
{
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
--
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
fm player for v4l2
hi all, After recent-ish kernel updates, fmtools no longer works. (I'm running gentoo currently on kernel 3.0.6) I believe the changes pertain to V4L1 vs L2 api changes. I am not a linux developer, however, and can't speak w/ authority. I've appended my v4l-info at the end of this email Example Failing Command == $fm 91.5 ioctl VIDIOCGAUDIO: Invalid argument Kernel V4L options == Here's my kernel configuration: CONFIG_VIDEO_V4L2_COMMON=y CONFIG_VIDEO_V4L2=y CONFIG_V4L_USB_DRIVERS=y # CONFIG_V4L_MEM2MEM_DRIVERS is not set Can anyone recommend: - any fm software that works w/ V4L2? - any kernel tweaks I can make to keep the old fmtools app working? - any other next steps thanks, will Appendix: V4L-info === ### v4l2 device info [/dev/video0] ### general info VIDIOC_QUERYCAP driver : bttv card: BT878 video (Hauppauge (bt878)) bus_info: PCI::05:0a.0 version : 0.9.18 capabilities: 0x5010015 [VIDEO_CAPTURE,VIDEO_OVERLAY,VBI_CAPTURE,TUNER,READWRITE,STREAMING] standards VIDIOC_ENUMSTD(0) index : 0 id : 0xb000 [NTSC_M,NTSC_M_JP,?] name: NTSC frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(1) index : 1 id : 0x1000 [NTSC_M] name: NTSC-M frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(2) index : 2 id : 0x2000 [NTSC_M_JP] name: NTSC-M-JP frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(3) index : 3 id : 0x8000 [?] name: NTSC-M-KR frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(4) index : 4 id : 0xff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K] name: PAL frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(5) index : 5 id : 0x7 [PAL_B,PAL_B1,PAL_G] name: PAL-BG frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(6) index : 6 id : 0x8 [PAL_H] name: PAL-H frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(7) index : 7 id : 0x10 [PAL_I] name: PAL-I frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(8) index : 8 id : 0xe0 [PAL_D,PAL_D1,PAL_K] name: PAL-DK frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(9) index : 9 id : 0x100 [PAL_M] name: PAL-M frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(10) index : 10 id : 0x200 [PAL_N] name: PAL-N frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(11) index : 11 id : 0x400 [PAL_Nc] name: PAL-Nc frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(12) index : 12 id : 0x800 [PAL_60] name: PAL-60 frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(13) index : 13 id : 0xff [SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] name: SECAM frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(14)
Re: fm player for v4l2
On Wed, Oct 5, 2011 at 2:32 PM, Will Milspec will.mils...@gmail.com wrote: hi all, After recent-ish kernel updates, fmtools no longer works. (I'm running gentoo currently on kernel 3.0.6) I believe the changes pertain to V4L1 vs L2 api changes. I am not a linux developer, however, and can't speak w/ authority. I've appended my v4l-info at the end of this email Example Failing Command == $fm 91.5 ioctl VIDIOCGAUDIO: Invalid argument Kernel V4L options == Here's my kernel configuration: CONFIG_VIDEO_V4L2_COMMON=y CONFIG_VIDEO_V4L2=y CONFIG_V4L_USB_DRIVERS=y # CONFIG_V4L_MEM2MEM_DRIVERS is not set Can anyone recommend: - any fm software that works w/ V4L2? - any kernel tweaks I can make to keep the old fmtools app working? - any other next steps Unfortunately, despite V4L1 having been deprecated almost a decade ago, essentially every application out there was still depending on it at the source code level. Once the kernel finally dropped the support entirely, changes were required to MythTV, tvtime, xawtv, for them to start working again (pretty much every project I know of went oh crap when it disappeared). Somebody will probably have to fix the fmtools source code to no longer depend on V4L1. 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: fm player for v4l2
Thanks for the summary. Any V4L2 fm-card app's working out there? Also, I apologize in advance for the size of my v4l-info section in the email. I didn't realize its size until after i emailed. will -- 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: fm player for v4l2
Em 05-10-2011 16:05, Will Milspec escreveu: Thanks for the summary. Any V4L2 fm-card app's working out there? xawtv radio application works. Also, gnomeradio (at least, the one shipped on Fedora - not sure if the V4L2 port were merged back upstream). fmtools version 2 says: 2.0: Sat Dec 12 21:18:52 PST 2009 / Ben Pfaff b...@cs.stanford.edu - Rewrite to use video4linux2 API. and a grep on its source code shows only V4L2 API ioctl's. So, all you need is probably to upgrade it to a newer version. Also, I apologize in advance for the size of my v4l-info section in the email. I didn't realize its size until after i emailed. will -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make use of media bus pixel codes in adv7175 driver
Hi Mauro
2011/9/30 Mauro Carvalho Chehab mche...@redhat.com:
Em 27-09-2011 16:16, Christian Gmeiner escreveu:
The ADV7175A/ADV7176A can operate in either 8-bit or 16-bit YCrCb mode.
* 8-Bit YCrCb Mode
This default mode accepts multiplexed YCrCb inputs through
the P7-P0 pixel inputs. The inputs follow the sequence Cb0, Y0
Cr0, Y1 Cb1, Y2, etc. The Y, Cb and Cr data are input on a
rising clock edge.
* 16-Bit YCrCb Mode
This mode accepts Y inputs through the P7–P0 pixel inputs and
multiplexed CrCb inputs through the P15–P8 pixel inputs. The
data is loaded on every second rising edge of CLOCK. The inputs
follow the sequence Cb0, Y0 Cr0, Y1 Cb1, Y2, etc.
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
diff --git a/drivers/media/video/adv7175.c b/drivers/media/video/adv7175.c
index d2327db..206078e 100644
--- a/drivers/media/video/adv7175.c
+++ b/drivers/media/video/adv7175.c
@@ -61,6 +61,11 @@ static inline struct adv7175 *to_adv7175(struct
v4l2_subdev *sd)
Patch looks ok, but it got truncated by your emailer [1]... Couldn't apply it
[1] http://patchwork.linuxtv.org/patch/7973/
Care to fix it and re-send?
sure... I switched to KMail now.. lets see if it works better now.
Thanks,
Christian
Thanks!
Mauro
static char *inputs[] = { pass_through, play_back, color_bar };
+static enum v4l2_mbus_pixelcode adv7175_codes[] = {
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_UYVY8_1X16,
+};
+
/* ---
*/
static inline int adv7175_write(struct v4l2_subdev *sd, u8 reg, u8 value)
@@ -296,6 +301,60 @@ static int adv7175_s_routing(struct v4l2_subdev *sd,
return 0;
}
+static int adv7175_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index = ARRAY_SIZE(adv7175_codes))
+ return -EINVAL;
+
+ *code = adv7175_codes[index];
+ return 0;
+}
+
+static int adv7175_g_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
+{
+ u8 val = adv7175_read(sd, 0x7);
+
+ if ((val 0x40) == (1 6))
+ mf-code = V4L2_MBUS_FMT_UYVY8_1X16;
+ else
+ mf-code = V4L2_MBUS_FMT_UYVY8_2X8;
+
+ mf-colorspace = V4L2_COLORSPACE_SMPTE170M;
+ mf-width = 0;
+ mf-height = 0;
+ mf-field = V4L2_FIELD_ANY;
+
+ return 0;
+}
+
+static int adv7175_s_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
+{
+ u8 val = adv7175_read(sd, 0x7);
+ int ret;
+
+ switch (mf-code) {
+ case V4L2_MBUS_FMT_UYVY8_2X8:
+ val = ~0x40;
+ break;
+
+ case V4L2_MBUS_FMT_UYVY8_1X16:
+ val |= 0x40;
+ break;
+
+ default:
+ v4l2_dbg(1, debug, sd,
+ illegal v4l2_mbus_framefmt code: %d\n, mf-code);
+ return -EINVAL;
+ }
+
+ ret = adv7175_write(sd, 0x7, val);
+
+ return ret;
+}
+
static int adv7175_g_chip_ident(struct v4l2_subdev *sd, struct
v4l2_dbg_chip_ident *chip)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -324,6 +383,9 @@ static const struct v4l2_subdev_core_ops
adv7175_core_ops = {
static const struct v4l2_subdev_video_ops adv7175_video_ops = {
.s_std_output = adv7175_s_std_output,
.s_routing = adv7175_s_routing,
+ .s_mbus_fmt = adv7175_s_fmt,
+ .g_mbus_fmt = adv7175_g_fmt,
+ .enum_mbus_fmt = adv7175_enum_fmt,
};
static const struct v4l2_subdev_ops adv7175_ops = {
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend] Make use of media bus pixel codes in adv7175 driver
The ADV7175A/ADV7176A can operate in either 8-bit or 16-bit YCrCb mode.
* 8-Bit YCrCb Mode
This default mode accepts multiplexed YCrCb inputs through
the P7-P0 pixel inputs. The inputs follow the sequence Cb0, Y0
Cr0, Y1 Cb1, Y2, etc. The Y, Cb and Cr data are input on a
rising clock edge.
* 16-Bit YCrCb Mode
This mode accepts Y inputs through the P7–P0 pixel inputs and
multiplexed CrCb inputs through the P15–P8 pixel inputs. The
data is loaded on every second rising edge of CLOCK. The inputs
follow the sequence Cb0, Y0 Cr0, Y1 Cb1, Y2, etc.
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
diff --git a/drivers/media/video/adv7175.c b/drivers/media/video/adv7175.c
index d2327db..206078e 100644
--- a/drivers/media/video/adv7175.c
+++ b/drivers/media/video/adv7175.c
@@ -61,6 +61,11 @@ static inline struct adv7175 *to_adv7175(struct v4l2_subdev
*sd)
static char *inputs[] = { pass_through, play_back, color_bar };
+static enum v4l2_mbus_pixelcode adv7175_codes[] = {
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_UYVY8_1X16,
+};
+
/* --- */
static inline int adv7175_write(struct v4l2_subdev *sd, u8 reg, u8 value)
@@ -296,6 +301,60 @@ static int adv7175_s_routing(struct v4l2_subdev *sd,
return 0;
}
+static int adv7175_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index = ARRAY_SIZE(adv7175_codes))
+ return -EINVAL;
+
+ *code = adv7175_codes[index];
+ return 0;
+}
+
+static int adv7175_g_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
+{
+ u8 val = adv7175_read(sd, 0x7);
+
+ if ((val 0x40) == (1 6))
+ mf-code = V4L2_MBUS_FMT_UYVY8_1X16;
+ else
+ mf-code = V4L2_MBUS_FMT_UYVY8_2X8;
+
+ mf-colorspace = V4L2_COLORSPACE_SMPTE170M;
+ mf-width = 0;
+ mf-height = 0;
+ mf-field = V4L2_FIELD_ANY;
+
+ return 0;
+}
+
+static int adv7175_s_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
+{
+ u8 val = adv7175_read(sd, 0x7);
+ int ret;
+
+ switch (mf-code) {
+ case V4L2_MBUS_FMT_UYVY8_2X8:
+ val = ~0x40;
+ break;
+
+ case V4L2_MBUS_FMT_UYVY8_1X16:
+ val |= 0x40;
+ break;
+
+ default:
+ v4l2_dbg(1, debug, sd,
+ illegal v4l2_mbus_framefmt code: %d\n, mf-code);
+ return -EINVAL;
+ }
+
+ ret = adv7175_write(sd, 0x7, val);
+
+ return ret;
+}
+
static int adv7175_g_chip_ident(struct v4l2_subdev *sd, struct
v4l2_dbg_chip_ident *chip)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -324,6 +383,9 @@ static const struct v4l2_subdev_core_ops adv7175_core_ops =
{
static const struct v4l2_subdev_video_ops adv7175_video_ops = {
.s_std_output = adv7175_s_std_output,
.s_routing = adv7175_s_routing,
+ .s_mbus_fmt = adv7175_s_fmt,
+ .g_mbus_fmt = adv7175_g_fmt,
+ .enum_mbus_fmt = adv7175_enum_fmt,
};
static const struct v4l2_subdev_ops adv7175_ops = {
--
1.7.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Media_build Issue with altera on cx23885
V4L-DVB was previously working correctly for me. I was experiencing some problems which had been solved before by recompiling v4l. So I cloned the latest media_build tree and ran the build process. Afterward, the driver does not load correctly and dmesg shows an error (cx23885: Unknown symbol altera_init (err 0)). I know there was a change to move altera from staging to misc but I see that the changes were propogated to media_build on 9/26/11. I ran menuconfig and made sure that MISC_DEVICES was set to 'y' to include altera-stapl but to no avail. Please advise. Some relevant information: Device: Hauppauge HVR-1250 Tuner Driver: cx23885 Environment: Ubuntu 11.04, 2.6.38-11-generic Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Hi Mauro, On Monday 03 October 2011 23:56:06 Mauro Carvalho Chehab wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] Laurent, I have a few questions about MCF and the OMAP3ISP driver if you are so kind to answer. 1- User-space programs that are not MCF aware negotiate the format with the V4L2 device (i.e: OMAP3 ISP CCDC output), which is a sink pad. But the real format is driven by the analog video format in the source pad (i.e: tvp5151). That's not different from existing systems using digital sensors, where the format is driven by the sensor. I modified the ISP driver to get the data format from the source pad and set the format for each pad on the pipeline accordingly but I've read from the documentation [1] that is not correct to propagate a data format from source pads to sink pads, that the correct thing is to do it from sink to source. So, in this case an administrator has to externally configure the format for each pad and to guarantee a coherent format on the whole pipeline?. That's correct (except you don't need to be an administrator to do so :-)). NACK. Double NACK :-D When userspace sends a VIDIOC_S_STD ioctl to the sink node, the subdevs that are handling the video/audio standard should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. The same could have been told for the format API: When userspace sends a VIDIOC_S_FMT ioctl to the sink node, the subdevs that are handling the video format should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. But we've introduced a pad-level format API. I don't see any reason to treat standard differently. Neither do I. The pad-level API should not replace the V4L2 API for standard, for controls and/or for format settings. The pad-level API doesn't replace the V4L2 API, it complements it. I'm of course not advocating modifying any driver to replace V4L2 ioctls by direct subdev access. However, the pad-level API needs to be exposed to userspace, as some harware simply can't be configured through a video node only. As Hans also mentionned in his reply, the pad-level API is made of two parts: an in-kernel API made of subdev operations, and a userspace API accessed through ioctls. As the userspace API is needed for some devices, the kernel API needs to be implemented by drivers. We should phase out the non pad-level format operations in favor of pad-level operations, as the former can be implemented using the later. That has absolutely no influence on the userspace API. Or does exist a way to do this automatic?. i.e: The output entity on the pipeline promotes the capabilities of the source pad so applications can select a data format and this format gets propagated all over the pipeline from the sink pad to the source? It can be automated in userspace (through a libv4l plugin for instance), but it's really not the kernel's job to do so. It is a kernel job to handle VIDIOC_S_STD, and not a task to be left to any userspace plugin. And VIDIOC_S_FMT is handled by userspace for the OMAP3 ISP today. Why are standards different ? All v4l media devices have sub-devices with either tv decoders or sensors connected into a sink. The sink implements the /dev/video? node. When an ioctl is sent to the v4l node, the sensors/decoders are controlled to implement whatever is requested: video standards, formats etc. But that simply doesn't work out with the OMAP3 ISP or similar hardware. If applications only set the format on the video node the driver has no way to know how to configure the individual subdevs in the pipeline. When more than a handful of subdevs are involved, the approach simply doesn't scale. On the other hand, when the TV decoder is connected to a bridge that is only capable of transferring the data to memory, there is no reason to require applications to configure subdevs directly. In that case the bridge driver can configure the subdevs itself. Changing it would be a major regression. If OMAP3 is not doing the right thing, it should be fixed, and not the opposite. The MC/subdev API is there to fill the blanks, e. g. to handle cases where the same function could be implemented on two different places of the pipeline, e. g. when both the sensor and the bridge could do scaling, and userspace wants to explicitly use one, or the other, but it were never meant to replace the V4L2 functionality. Isn't
Re: fm player for v4l2
fwiw, at the time of writing google finds two different fmtools web pages, one with 2.0.1 the other with 1.0.2 out of date: http://www.stanford.edu/~blp/fmtools/ up to date: http://benpfaff.org/fmtools/ gentoo portage still has 1.0.2 will -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Hi Javier, On Tuesday 04 October 2011 00:37:27 Javier Martinez Canillas wrote: Hello, Reading the last emails I understand that still isn't a consensus on the way this has to be made. If it has to be implemented at the video device node level or at the sub-device level. And if it has to be made in kernel or user-space. On Mon, Oct 3, 2011 at 11:56 PM, Mauro Carvalho Chehab wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] With the OMAP3 ISP, which is I believe what Javier was asking about, the application will set the format on the OMAP3 ISP resizer input and output pads to configure scaling. Yes, that was my question about. But still is not clear to me if configuring the ISP resizer input and output pads with different frame sizes automatically means that I have to do the scale or this has to be configured using a S_FMT ioctl to the /dev/video? node. The resizer is completely controlled through the formats at its sink and source pads. It will scale the image to achieve what is configured at its source pad (with x1/4..x4 limits in the zoom ratio). Basically what I don't know is when I have to modify the pipeline graph inside the ISP driver and when this has to be made from user-space via MCF. The pipeline needs to be configured before you start video capture. This means setting the links according to your use case, and configuring the formats on pads. You will then be able to use a pure V4L2 application to capture video. The V4L2 API doesn't tell where a function like scaler will be implemented. So, it is fine to implement it at tvp5151 or at the omap3 resizer, when a V4L2 call is sent. I don't think I can do the cropping and scaling in the tvp5151 driver since this is a dumb device, it only spits bytes via its parallel interface. The actual buffer is inside the ISP. Cropping might be possible (I'm not too familiar with the tvp5151), but scaling indeed isn't. That doesn't matter much though. -- 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 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Hi Hans, On Tuesday 04 October 2011 09:03:59 Hans Verkuil wrote: On Tuesday, October 04, 2011 07:31:27 Mauro Carvalho Chehab wrote: Em 03-10-2011 19:37, Javier Martinez Canillas escreveu: On Mon, Oct 3, 2011 at 11:56 PM, Mauro Carvalho Chehab wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] Laurent, I have a few questions about MCF and the OMAP3ISP driver if you are so kind to answer. 1- User-space programs that are not MCF aware negotiate the format with the V4L2 device (i.e: OMAP3 ISP CCDC output), which is a sink pad. But the real format is driven by the analog video format in the source pad (i.e: tvp5151). That's not different from existing systems using digital sensors, where the format is driven by the sensor. I modified the ISP driver to get the data format from the source pad and set the format for each pad on the pipeline accordingly but I've read from the documentation [1] that is not correct to propagate a data format from source pads to sink pads, that the correct thing is to do it from sink to source. So, in this case an administrator has to externally configure the format for each pad and to guarantee a coherent format on the whole pipeline?. That's correct (except you don't need to be an administrator to do so :-)). NACK. Double NACK :-D When userspace sends a VIDIOC_S_STD ioctl to the sink node, the subdevs that are handling the video/audio standard should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. The same could have been told for the format API: When userspace sends a VIDIOC_S_FMT ioctl to the sink node, the subdevs that are handling the video format should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. But we've introduced a pad-level format API. I don't see any reason to treat standard differently. Neither do I. The pad-level API should not replace the V4L2 API for standard, for controls and/or for format settings. Remember we are talking about the subdev driver here. It makes no sense to have both a s_mbus_fmt video op and a set_fmt pad op, which both do the same thing. Bridge drivers should be adapted to use set_fmt only, so we can drop s_mbus_fmt. BTW, the names 'set_fmt' and 'get_fmt' are very confusing to me. I always think these refer to v4l2_format. Can we please rename this to g/s_mbus_fmt? Shouldn't we do it the other way around, renaming the g/s_mbus_fmt video operations to g/s_fmt, now that we only have mbus formats left ? The operation names would be shorter. And set/get_crop to s/g_crop? This for consistent naming. set/get_crop will be replaced with set/get_selection (or s/g_selection if you like that better :-)). When it comes to S_STD I don't see the need for a pad version of this. It is an op that is used to configure subdevs to handle a specific standard. If you are configuring the pipelines manually, then after calling S_STD you have to set up the mbus formats yourself. Of course, I can generate scenarios where you would need to set the standard through the subdev node (i.e. two video receivers connected to a SoC, one receiving PAL, the other receiving NTSC, and both streams composed into a single new stream that's DMA-ed to memory), but frankly, those scenarios are very contrived :-) Unless I don't understand this correctly, I think those two paragraphs are not related. Regarding the pad-level standard operations, you're probably right. Subdevs that can handle two or more analog streams at the same time would need that, but we probably won't need to support them any time soon (if ever). So we could keep the subdev-level standard operations, with the implicit (or explicit) rule that they apply to the currently selected input of the subdev (I suppose TV decoders with an input mux are not uncommon). Regarding controlling standards directly on subdevs, I think that's the way to go for complex pipelines, but that doesn't require pad-level standard operations. The preset ioctls would be more realistic since I know that a scenario like the one above does exist for e.g. HDMI inputs, where each can receive a different format. In that case the preset ioctls would have to be exposed to the subdev nodes, allowing you to set it up for each HDMI receiver independently. But you still do not need pads to do this since this is a subdev-level operation, not
Re: [RFCv4 PATCH 0/6]: add poll_requested_events() function
On Wed, 5 Oct 2011 09:47:09 +0200 Hans Verkuil hverk...@xs4all.nl wrote: On Thursday 29 September 2011 09:44:06 Hans Verkuil wrote: This is the fourth version of this patch series, incorporating the comments from Andrew Morton: I've split up the multiple-assignment line and added a comment explaining the purpose of the new function in poll.h. It's also rebased to the current staging/for_v3.2 branch of the linux-media tree. There are no other changes compared to the RFCv3 patches. I'd very much like to get an Acked-by (or additional comments) from Al or Andrew! This patch series really should go into v3.2 which is getting close. Normally I would have posted this v4 3 weeks ago, but due to Real Life interference in the past few weeks I was unable to. But I'm back, and this is currently the highest priority for me. This is becoming annoying. Andrew, Al, can one of you please Ack this patch or review it? We *really* need this enhancement for our v4l drivers. I've been asking for an ack (or review) for ages and for the most part I got radio silence. Jon Corbet has already reviewed the code in early July (!), so I don't see why this is taking so long. Mauro needs an ack from one of you before he can merge it. It looks OK to me, but obviously it would be better if Al were to go through it also. If he doesn't then there isn't a lot we can do about it - I suggest that you proceed with the plan to merge it into -rc1. -- 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 7/9] V4L: soc-camera: add a Media Controller wrapper
Hi Guennadi,
On Tuesday 04 October 2011 19:34:36 Guennadi Liakhovetski wrote:
On Mon, 3 Oct 2011, Laurent Pinchart wrote:
On Monday 03 October 2011 17:29:23 Guennadi Liakhovetski wrote:
On Mon, 3 Oct 2011, Laurent Pinchart wrote:
On Thursday 29 September 2011 18:18:55 Guennadi Liakhovetski wrote:
This wrapper adds a Media Controller implementation to soc-camera
drivers. To really benefit from it individual host drivers should
implement support for values of enum soc_camera_target other than
SOCAM_TARGET_PIPELINE in their .set_fmt() and .try_fmt() methods.
[snip]
diff --git a/drivers/media/video/soc_entity.c
b/drivers/media/video/soc_entity.c new file mode 100644
index 000..3a04700
--- /dev/null
+++ b/drivers/media/video/soc_entity.c
@@ -0,0 +1,284 @@
[snip]
+static int bus_sd_pad_g_fmt(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *sd_fmt)
+{
+ struct soc_camera_device *icd = v4l2_get_subdevdata(sd);
+ struct v4l2_mbus_framefmt *f = sd_fmt-format;
+
+ if (sd_fmt-which == V4L2_SUBDEV_FORMAT_TRY) {
+ sd_fmt-format = *v4l2_subdev_get_try_format(fh,
sd_fmt-pad);
+ return 0;
+ }
+
+ if (sd_fmt-pad == SOC_HOST_BUS_PAD_SINK) {
+ f-width= icd-host_input_width;
+ f-height = icd-host_input_height;
+ } else {
+ f-width= icd-user_width;
+ f-height = icd-user_height;
+ }
+ f-field= icd-field;
+ f-code = icd-current_fmt-code;
+ f-colorspace = icd-colorspace;
Can soc-camera hosts perform format conversion ? If so you will
likely need to store the mbus code for the input and output
separately, possibly in v4l2_mbus_format fields. You could then
simplify the [gs]_fmt functions by implementing similar to the
__*_get_format functions in the OMAP3 ISP driver.
They can, yes. But, under soc-camera conversions are performed between
mediabus codes and fourcc formats. Upon pipeline construction (probing)
a table of format conversions is built, where hosts generate one or
more translation entries for all client formats, that they support.
The only example of a more complex translations so far is MIPI CSI-2,
but even there we have decided to identify CSI-2 formats using the
same media-bus codes, as what you get between the CSI-2 block and
the DMA engine. For the only CSI-2 capable soc-camera host so far -
the CEU driver - this is also a very natural representation, because
there the CSI-2 block is indeed an additional pipeline stage, uniquely
translating CSI-2 to media-bus codes, that are then fed to the CEU
parallel port.
How does that work with the MC API then ? If the bridge can, let's say,
convert between raw bayer and YUV, shouldn't the format at the bridge
input be raw bayer and at the bridge output YUV ?
Doesn't it depend on your definition? I define the conversion as taking
place on the DMA-engine entity. I.e., a media-bus code is transferred
unchanged all the way down to that entity and there it gets converted to
one of fourcc formats for storage in the memory. Isn't what you are
suggesting some kind of a t2o-stage conversion: first you convert one
media-bus code to another one, then you convert the latter one to some
fourcc, which is also not a one-to-one conversion.
t2o ?
An mbus code is converted to a fourcc by the DMA engine, but can't the bridge
subdev also perform conversion, such as interpolating raw bayer to RGB, and
possibly converting that to YUV ? In that case the bridge sink and source pads
would have different mbus formats.
--
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 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Em 05-10-2011 17:08, Laurent Pinchart escreveu: Hi Mauro, On Monday 03 October 2011 23:56:06 Mauro Carvalho Chehab wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] Laurent, I have a few questions about MCF and the OMAP3ISP driver if you are so kind to answer. 1- User-space programs that are not MCF aware negotiate the format with the V4L2 device (i.e: OMAP3 ISP CCDC output), which is a sink pad. But the real format is driven by the analog video format in the source pad (i.e: tvp5151). That's not different from existing systems using digital sensors, where the format is driven by the sensor. I modified the ISP driver to get the data format from the source pad and set the format for each pad on the pipeline accordingly but I've read from the documentation [1] that is not correct to propagate a data format from source pads to sink pads, that the correct thing is to do it from sink to source. So, in this case an administrator has to externally configure the format for each pad and to guarantee a coherent format on the whole pipeline?. That's correct (except you don't need to be an administrator to do so :-)). NACK. Double NACK :-D When userspace sends a VIDIOC_S_STD ioctl to the sink node, the subdevs that are handling the video/audio standard should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. The same could have been told for the format API: When userspace sends a VIDIOC_S_FMT ioctl to the sink node, the subdevs that are handling the video format should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. But we've introduced a pad-level format API. I don't see any reason to treat standard differently. Neither do I. The pad-level API should not replace the V4L2 API for standard, for controls and/or for format settings. The pad-level API doesn't replace the V4L2 API, it complements it. I'm of course not advocating modifying any driver to replace V4L2 ioctls by direct subdev access. However, the pad-level API needs to be exposed to userspace, as some harware simply can't be configured through a video node only. As Hans also mentionned in his reply, the pad-level API is made of two parts: an in-kernel API made of subdev operations, and a userspace API accessed through ioctls. As the userspace API is needed for some devices, the kernel API needs to be implemented by drivers. We should phase out the non pad-level format operations in favor of pad-level operations, as the former can be implemented using the later. That has absolutely no influence on the userspace API. What I'm seeing is that: - the drivers that are implementing the MC/pad API's aren't compatible with generic V4L2 applications; - there's no way to write a generic application that works with all drivers, even implementing MC/pad API's there as each driver is taking different a approach on how to map things at the different API's, and pipeline configuration is device-dependent; - there's no effort to publish patches to libv4l to match the changes at the kernel driver. At the time I tried to test the Samsung drivers, I failed to see how this would work, e. g. how an application like tvtime or xawtv could be used with such devices. I don't have here any omap3 hardware with cameras or tv tuners, but I don't see any patches at libv4l that allows using V4L2 to communicate with an omap3 hardware. So, in practice, there's no device abstraction that would expose those hardware to userspace in a manner that the application developer could write a generic application that would work for all hardware. I'm fine on providing raw interfaces, just like we have for some types of device (like the block raw interfaces used by CD-ROM drivers) as a bonus, but this should never replace an API where an application developed by a third party could work with all media hardware, without needing hardware specific details. So, let's take a more pragmatic approach: please provide me means where I test those drivers with a real hardware, using generic applications (xawtv, tvtime, camorama, qv4l2, etc), and being able to double check that they will behave just like any other existing driver. Or does exist a way to do this automatic?. i.e: The output entity on the pipeline promotes the capabilities of the source pad so applications can select a data format and this format gets propagated all over the pipeline from the sink pad to the source? It can be automated in userspace (through a libv4l plugin for instance), but it's really
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Em 05-10-2011 17:54, Laurent Pinchart escreveu: Hi Hans, On Tuesday 04 October 2011 09:03:59 Hans Verkuil wrote: On Tuesday, October 04, 2011 07:31:27 Mauro Carvalho Chehab wrote: Em 03-10-2011 19:37, Javier Martinez Canillas escreveu: On Mon, Oct 3, 2011 at 11:56 PM, Mauro Carvalho Chehab wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] Laurent, I have a few questions about MCF and the OMAP3ISP driver if you are so kind to answer. 1- User-space programs that are not MCF aware negotiate the format with the V4L2 device (i.e: OMAP3 ISP CCDC output), which is a sink pad. But the real format is driven by the analog video format in the source pad (i.e: tvp5151). That's not different from existing systems using digital sensors, where the format is driven by the sensor. I modified the ISP driver to get the data format from the source pad and set the format for each pad on the pipeline accordingly but I've read from the documentation [1] that is not correct to propagate a data format from source pads to sink pads, that the correct thing is to do it from sink to source. So, in this case an administrator has to externally configure the format for each pad and to guarantee a coherent format on the whole pipeline?. That's correct (except you don't need to be an administrator to do so :-)). NACK. Double NACK :-D When userspace sends a VIDIOC_S_STD ioctl to the sink node, the subdevs that are handling the video/audio standard should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. The same could have been told for the format API: When userspace sends a VIDIOC_S_FMT ioctl to the sink node, the subdevs that are handling the video format should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. But we've introduced a pad-level format API. I don't see any reason to treat standard differently. Neither do I. The pad-level API should not replace the V4L2 API for standard, for controls and/or for format settings. Remember we are talking about the subdev driver here. It makes no sense to have both a s_mbus_fmt video op and a set_fmt pad op, which both do the same thing. Bridge drivers should be adapted to use set_fmt only, so we can drop s_mbus_fmt. BTW, the names 'set_fmt' and 'get_fmt' are very confusing to me. I always think these refer to v4l2_format. Can we please rename this to g/s_mbus_fmt? Shouldn't we do it the other way around, renaming the g/s_mbus_fmt video operations to g/s_fmt, now that we only have mbus formats left ? The operation names would be shorter. And set/get_crop to s/g_crop? This for consistent naming. set/get_crop will be replaced with set/get_selection (or s/g_selection if you like that better :-)). When it comes to S_STD I don't see the need for a pad version of this. It is an op that is used to configure subdevs to handle a specific standard. If you are configuring the pipelines manually, then after calling S_STD you have to set up the mbus formats yourself. Of course, I can generate scenarios where you would need to set the standard through the subdev node (i.e. two video receivers connected to a SoC, one receiving PAL, the other receiving NTSC, and both streams composed into a single new stream that's DMA-ed to memory), but frankly, those scenarios are very contrived :-) Unless I don't understand this correctly, I think those two paragraphs are not related. Regarding the pad-level standard operations, you're probably right. Subdevs that can handle two or more analog streams at the same time would need that, but we probably won't need to support them any time soon (if ever). So we could keep the subdev-level standard operations, with the implicit (or explicit) rule that they apply to the currently selected input of the subdev (I suppose TV decoders with an input mux are not uncommon). Switching from one input to the other doesn't switch the TV format (except, of course, if autodetection is enabled). The driver should keep the last settings to the new input for resolution, format, fourcc and image controls. Regarding controlling standards directly on subdevs, I think that's the way to go for complex pipelines, but that doesn't require pad-level standard operations. The preset ioctls would be more realistic since I know that a scenario like the one above does exist for e.g. HDMI inputs, where each can receive a different format. In that case the preset ioctls would have to be exposed to the subdev nodes, allowing you to set it up for each HDMI receiver independently.
Re: [PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
On Wed, 5 Oct 2011, Mauro Carvalho Chehab wrote:
Em 05-10-2011 11:00, Mike Isely escreveu:
Mauro:
With the line you've just added, then the = arg assignment in the
immediate prior line is effectively dead code. Try this instead:
Look better:
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
The above code is creating a pointer 'std' of the type 'v4l2_std_id', and
initializing the pointer with the void *arg.
Oh yeah, you're absolutely right. I got visually tricked by the well
known confusing C initialization syntax when dealing with pointers!
I've got to not respond to stuff like this in the morning until I've
finished waking up. Duh...
Then, it is doing an indirect reference to the pointer, filling its
contents with V4L2_STD_ALL value.
The code above is sane (and, btw, it works). After those patches, the
detection code will detect PAL/M or NTSC/M depending on the channel I
tune here (my cable operator broadcasts some channels with one format,
and others with the other one). Before this patch and the msp3400, it
would return a mask with PAL/M and PAL/60 or a mask with all NTSC/M formats.
Regarding your first version of the patch:
Acked-By: Mike Isely is...@pobox.com
-Mike
Regards,
Mauro.
case VIDIOC_QUERYSTD:
{
- v4l2_std_id *std = arg;
+ v4l2_std_id *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
-Mike
On Tue, 4 Oct 2011, Mauro Carvalho Chehab wrote:
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 0d029da..ce7ac45 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_QUERYSTD:
{
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] af9013 frontend tuner bus lock
http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw 5.1? OK, I might eventually try that one too. This morning I get a little pixeled playback, less than a second. OK, mine was fine for a few days then the pixellation started up in earnest. At the moment my symptoms were always: TunerA: Tuned - picture good TunerB: Idle Tuner B gets tuned, Tuner A starts to pixellate badly. I am sure this is the case too: TunerA: Idle TunerB: Tuned - picture good Tuner A gets tuned and has a bad recording. *Never* has Tuner B suffered from the pixellation in spite of whatever Tuner A is doing! Anyway, Malcolm has suggested there is a bug lurking in MythTV too causing problems with dual tuners so it's a bit hard to isolate the issue. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Wed, Oct 5, 2011 at 11:48 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 05-10-2011 17:54, Laurent Pinchart escreveu: Hi Hans, On Tuesday 04 October 2011 09:03:59 Hans Verkuil wrote: On Tuesday, October 04, 2011 07:31:27 Mauro Carvalho Chehab wrote: Em 03-10-2011 19:37, Javier Martinez Canillas escreveu: On Mon, Oct 3, 2011 at 11:56 PM, Mauro Carvalho Chehab wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] Laurent, I have a few questions about MCF and the OMAP3ISP driver if you are so kind to answer. 1- User-space programs that are not MCF aware negotiate the format with the V4L2 device (i.e: OMAP3 ISP CCDC output), which is a sink pad. But the real format is driven by the analog video format in the source pad (i.e: tvp5151). That's not different from existing systems using digital sensors, where the format is driven by the sensor. I modified the ISP driver to get the data format from the source pad and set the format for each pad on the pipeline accordingly but I've read from the documentation [1] that is not correct to propagate a data format from source pads to sink pads, that the correct thing is to do it from sink to source. So, in this case an administrator has to externally configure the format for each pad and to guarantee a coherent format on the whole pipeline?. That's correct (except you don't need to be an administrator to do so :-)). NACK. Double NACK :-D When userspace sends a VIDIOC_S_STD ioctl to the sink node, the subdevs that are handling the video/audio standard should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. The same could have been told for the format API: When userspace sends a VIDIOC_S_FMT ioctl to the sink node, the subdevs that are handling the video format should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. But we've introduced a pad-level format API. I don't see any reason to treat standard differently. Neither do I. The pad-level API should not replace the V4L2 API for standard, for controls and/or for format settings. Remember we are talking about the subdev driver here. It makes no sense to have both a s_mbus_fmt video op and a set_fmt pad op, which both do the same thing. Bridge drivers should be adapted to use set_fmt only, so we can drop s_mbus_fmt. BTW, the names 'set_fmt' and 'get_fmt' are very confusing to me. I always think these refer to v4l2_format. Can we please rename this to g/s_mbus_fmt? Shouldn't we do it the other way around, renaming the g/s_mbus_fmt video operations to g/s_fmt, now that we only have mbus formats left ? The operation names would be shorter. And set/get_crop to s/g_crop? This for consistent naming. set/get_crop will be replaced with set/get_selection (or s/g_selection if you like that better :-)). When it comes to S_STD I don't see the need for a pad version of this. It is an op that is used to configure subdevs to handle a specific standard. If you are configuring the pipelines manually, then after calling S_STD you have to set up the mbus formats yourself. Of course, I can generate scenarios where you would need to set the standard through the subdev node (i.e. two video receivers connected to a SoC, one receiving PAL, the other receiving NTSC, and both streams composed into a single new stream that's DMA-ed to memory), but frankly, those scenarios are very contrived :-) Unless I don't understand this correctly, I think those two paragraphs are not related. Regarding the pad-level standard operations, you're probably right. Subdevs that can handle two or more analog streams at the same time would need that, but we probably won't need to support them any time soon (if ever). So we could keep the subdev-level standard operations, with the implicit (or explicit) rule that they apply to the currently selected input of the subdev (I suppose TV decoders with an input mux are not uncommon). Switching from one input to the other doesn't switch the TV format (except, of course, if autodetection is enabled). The driver should keep the last settings to the new input for resolution, format, fourcc and image controls. Regarding controlling standards directly on subdevs, I think that's the way to go for complex pipelines, but that doesn't require pad-level standard operations. The preset ioctls would be more realistic since I know that a scenario like the one above does exist for e.g. HDMI inputs, where each can receive a
Re: [PATCH] af9013 frontend tuner bus lock
2011/10/6 Jason Hecker jwhec...@gmail.com: http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw 5.1? OK, I might eventually try that one too. This morning I get a little pixeled playback, less than a second. OK, mine was fine for a few days then the pixellation started up in earnest. At the moment my symptoms were always: TunerA: Tuned - picture good TunerB: Idle Tuner B gets tuned, Tuner A starts to pixellate badly. I am sure this is the case too: TunerA: Idle TunerB: Tuned - picture good Tuner A gets tuned and has a bad recording. *Never* has Tuner B suffered from the pixellation in spite of whatever Tuner A is doing! Anyway, Malcolm has suggested there is a bug lurking in MythTV too causing problems with dual tuners so it's a bit hard to isolate the issue. Hello again, I am having more pixeled playback, I don't know how to explain so I record a video: http://dl.dropbox.com/u/1541853/VID_20111006_004447.3gp I get this I2C messages: # tail -f /var/log/messages Oct 5 20:16:44 htpc kernel: [ 534.168957] af9013: I2C read failed reg:d330 Oct 5 20:16:49 htpc kernel: [ 538.626152] af9013: I2C read failed reg:d330 Oct 5 21:22:15 htpc kernel: [ 4464.930734] af9013: I2C write failed reg:d2e2 len:1 Oct 5 21:40:46 htpc kernel: [ 5576.241897] af9013: I2C read failed reg:d2e6 Oct 5 23:07:33 htpc kernel: [10782.852522] af9013: I2C read failed reg:d2e6 Oct 5 23:20:11 htpc kernel: [11540.824515] af9013: I2C read failed reg:d07c Oct 6 00:11:41 htpc kernel: [14631.122384] af9013: I2C read failed reg:d2e6 Oct 6 00:26:13 htpc kernel: [15502.900549] af9013: I2C read failed reg:d2e6 Oct 6 00:39:58 htpc kernel: [16328.273015] af9013: I2C read failed reg:d330 My signal is this: (idle) $ femon -H -a 4 FE: Afatech AF9013 DVB-T (DVBT) status S | signal 75% | snr 0% | ber 0 | unc 0 | status S | signal 75% | snr 0% | ber 0 | unc 0 | status S | signal 75% | snr 0% | ber 0 | unc 0 | status S | signal 75% | snr 0% | ber 0 | unc 0 | status S | signal 74% | snr 0% | ber 0 | unc 0 | status S | signal 74% | snr 0% | ber 0 | unc 0 | (watching) $ femon -H -a 5 FE: Afatech AF9013 DVB-T (DVBT) status SCVYL | signal 74% | snr 0% | ber 142 | unc 319408 | FE_HAS_LOCK status SCVYL | signal 74% | snr 0% | ber 142 | unc 319408 | FE_HAS_LOCK status SCVYL | signal 74% | snr 0% | ber 31 | unc 319430 | FE_HAS_LOCK status SCVYL | signal 74% | snr 0% | ber 31 | unc 319430 | FE_HAS_LOCK status SCVYL | signal 74% | snr 0% | ber 56 | unc 319519 | FE_HAS_LOCK status SCVYL | signal 74% | snr 0% | ber 0 | unc 319519 | FE_HAS_LOCK status SCVYL | signal 74% | snr 0% | ber 0 | unc 319519 | FE_HAS_LOCK There are lots of ber and unc bits, I have connected the TV to the same wire and there is a good signal. Thanks for your help. Regards. -- Josu Lazkano -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Mon, Oct 03, 2011 at 11:39:31PM +0200, Laurent Pinchart wrote: Sorry ? We already have format setting at the pad level, and that's used by drivers and applications. It's one key feature of the V4L2/MC API. A tiny additional note: this feature is actuall necessary since e.g. OMAP 3 ISP CCDC provides images of different size at different outputs; one to memory and one to another ISP block. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Mon, Oct 03, 2011 at 04:36:44PM -0300, Mauro Carvalho Chehab wrote: Em 03-10-2011 16:01, Sakari Ailus escreveu: On Mon, Oct 03, 2011 at 03:53:54PM -0300, Mauro Carvalho Chehab wrote: Yes, you're right. I should not try to answer emails when I'm lazy enough to not look in to the code ;) Anyway, the thing is that V4L2 API has enough support for auto-detection. There's no need to duplicate stuff with MC API. It's not MC API but V4L2 subdev API. No-one has proposed to add video standard awareness to the Media controller API. There's no reason to export a video node in video decoder drivers... but I guess you didn't mean that. Would implementing ENUM/G/S_STD make sense for the camera ISP driver, that has nothing to do with any video standard? This is an old discussion, and we never agreed on that. Some webcam drivers implement those ioctls. Others don't. Both cases are compliant with the current specs. In the past, several userspace applications used to abort if those ioctl's weren't implemented, but I think that this were fixed already there. As I said, we should define a per-device type profile in order to enforce that all devices of the same type will do the same. We'll need man power to fix the ones that aren't compliant, and solve the userspace issues. Volunteers needed. There's one point to bold on it: devices that can have either an analog input or a digital input will likely need to implement ENUM/G/S_STD for both, as userspace applications may fail, if the ioctl's are disabled depending on the type of input. We had to implement them on several drivers, due to that. My disguised question behind this was actually that would a driver need to implement an ioctl that has no relevance to the driver itself at all but only to support another driver, yet the first driver might not have enough information to properly implement it? It may be sometimes necessary but I would like to avoid that if possible since it complicates even more drivers which already are very complex. If you have two video decoders connected to your system, then which one should the ioctls be redirected to? What if there's a sensor and a video decoder? And how could the user know about this? When an input is selected (either via the V4L2 way - S_INPUT or via the MC/subdev way, there's just one video decoder or sensor associated to the corresponding V4L2 node). It's the same old issues again... let's discuss this in the Multimedia summit. We can discuss more at the summit, but we should start discussing it here, as otherwise we may not be able to go into a consensus there, due to the limited amount of time we would have for each topic. Sounds good to me, but sometimes face-to-face discussion just is not replaceable. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Em 05-10-2011 20:14, Sakari Ailus escreveu: Hi Mauro, On Wed, Oct 05, 2011 at 06:41:27PM -0300, Mauro Carvalho Chehab wrote: Em 05-10-2011 17:08, Laurent Pinchart escreveu: [clip] The pad-level API doesn't replace the V4L2 API, it complements it. I'm of course not advocating modifying any driver to replace V4L2 ioctls by direct subdev access. However, the pad-level API needs to be exposed to userspace, as some harware simply can't be configured through a video node only. As Hans also mentionned in his reply, the pad-level API is made of two parts: an in-kernel API made of subdev operations, and a userspace API accessed through ioctls. As the userspace API is needed for some devices, the kernel API needs to be implemented by drivers. We should phase out the non pad-level format operations in favor of pad-level operations, as the former can be implemented using the later. That has absolutely no influence on the userspace API. What I'm seeing is that: - the drivers that are implementing the MC/pad API's aren't compatible with generic V4L2 applications; This is currently true up to a certain degree; you'll need to configure such devices using media-ctl at least. Even then, such embedded systems do often have automatic exposure and white balance algorithms above the V4L2 (often proprietary implementations). To be really useful for a regular user, such algorithms would also be needed. The two problems are separate but they still both need to be resolved to be able to use general purpose V4L2 applications on such systems in a meaningful way. That's true, and the MC/pad API's were added to offer support for those proprietary plugins via libv4l. That's fine, but the thing is that some developers seem to think that only the streaming should be done via the V4L2 API, and all the rest via pad configs, while others have different views. Also, I couldn't see a consense about input selection on drivers that implement MC: they could either implement S_INPUT, create one V4L device node for each input, or create just one devnode and let userspace (somehow) to discover the valid inputs and set the pipelines via MC/pad. With all those complex and different scenarios, writing a generic plugin/application that would cover all possible alternatives with a mix of V4L/MC/pad API's would be extremely complex, and will take years to do it right. In other words, we need to confine the possible solutions to the ones that will actually be supported. - there's no way to write a generic application that works with all drivers, even implementing MC/pad API's there as each driver is taking different a approach on how to map things at the different API's, and pipeline configuration is device-dependent; The pipeline configuration is device specific but the interfaces are not. Thus it's possible to write a generic plugin which configures the device. The static configuration can be kept in a text file in the first phase and later on hints may be added for synamic configuration on e.g. where digital gain, scaling and cropping should be performed and which resolutions to advertise in enum_framesizes. Assuming that all drivers do the same, this would be an alternative for such plugin. But we do not have such plugin yet. As several SoC developers showed on all opportunities we've met, the complexity for those devices is very high. The practical effect of adding a kernel driver without the corresponding required library support is that we ended by merging incomplete drivers and nobody, except for the manufacturers/developers whose submitted them could actually make an userspace application to work with. That would be ok if the drivers would be at /staging, but they aren't. This situation should be fixed as soon as possible. I'm seriously considering to not send the patches we have on our tree for those drivers upstream while we don't have a solution for that. - there's no effort to publish patches to libv4l to match the changes at the kernel driver. I'd prefer concentrating all efforts towards a single, generic plugin. As noted before, a plugin for OMAP 3 ISP exists, but I don't think it does anything a generic plugin couldn't do, so it hasn't been merged. I'm working on patches to move the text-based pipeline configuration to libmediactl and libv4l2subdev and will post them to the list in the coming few days, among with a few other improvements. This is one of the first required steps towards such generic plugin. That would be great, but it won't solve, as more mess is being proposed each day. One thing is to set the pipelines. Another thing is to not support things like S_FMT/S_STD/... ioctl's. The user knows what format he wants, and that's what S_FMT/S_STD tells to the driver. the extra formats at the pipeline could be handled by a policy either at the driver or at a libv4l, although I don't think that a generic libv4l plugin would be capable of doing it (see more about that
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Em 05-10-2011 20:41, Sakari Ailus escreveu:
On Mon, Oct 03, 2011 at 04:36:44PM -0300, Mauro Carvalho Chehab wrote:
Em 03-10-2011 16:01, Sakari Ailus escreveu:
On Mon, Oct 03, 2011 at 03:53:54PM -0300, Mauro Carvalho Chehab wrote:
Yes, you're right. I should not try to answer emails when I'm lazy enough to not
look in to the code ;)
Anyway, the thing is that V4L2 API has enough support for auto-detection.
There's
no need to duplicate stuff with MC API.
It's not MC API but V4L2 subdev API. No-one has proposed to add video
standard awareness to the Media controller API. There's no reason to export
a video node in video decoder drivers... but I guess you didn't mean that.
Would implementing ENUM/G/S_STD make sense for the camera ISP driver, that
has nothing to do with any video standard?
This is an old discussion, and we never agreed on that. Some webcam drivers
implement those ioctls. Others don't. Both cases are compliant with the
current specs. In the past, several userspace applications used to abort if
those
ioctl's weren't implemented, but I think that this were fixed already there.
As I said, we should define a per-device type profile in order to enforce that
all devices of the same type will do the same. We'll need man power to fix the
ones that aren't compliant, and solve the userspace issues. Volunteers needed.
There's one point to bold on it: devices that can have either an analog input
or a digital input will likely need to implement ENUM/G/S_STD for both, as
userspace applications may fail, if the ioctl's are disabled depending on the
type of input. We had to implement them on several drivers, due to that.
My disguised question behind this was actually that would a driver need to
implement an ioctl that has no relevance to the driver itself at all but
only to support another driver, yet the first driver might not have enough
information to properly implement it?
This is done a lot at the V4L2 drivers: basically, the code at the bridge
driver just forwards the request to the sub-devices, when it doesn't know
what to do, and return the information back to the userspace, acting like
a bridge between the userspace and the sub-devices.
For example, this is what the usbvision[1] driver does for all control ioctl's:
[1] usbvision is not an example of a modern driver. It is for some old
generations of USB 1.1 media devices. I'm just using it here as it contains
one of the simplest implementations among the drivers we have, as most of
the work is done by the saa7115 driver.
static int vidioc_s_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
struct usb_usbvision *usbvision = video_drvdata(file);
call_all(usbvision, core, s_ctrl, ctrl);
return 0;
}
In other words, it just forwards the call to the tv decoder or to the sensor
(the same driver is used with both webcams and tv decoders).
The implementation for S_STD is a little more complex, as it also sets the
input at the video muxer. Even so, it is trivial:
static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id *id)
{
struct usb_usbvision *usbvision = video_drvdata(file);
usbvision-tvnorm_id = *id;
call_all(usbvision, core, s_std, usbvision-tvnorm_id);
/* propagate the change to the decoder */
usbvision_muxsel(usbvision, usbvision-ctl_input);
return 0;
}
It may be sometimes necessary but I would like to avoid that if possible
since it complicates even more drivers which already are very complex.
As you can see from the two above examples, a code that will just bridge
the call to the subdevs is trivial to implement, and won't affect much
the drivers complexity.
On the other hand, Implementing the same at userspace can be much more complex,
as userspace
will need to know some details about the device. For example, userspace
would need to know what nodes are affected by a command like S_STD, and
what are the requirements for each pad, to avoid putting the device into
an unsupported configuration.
If you have two video decoders
connected to your system, then which one should the ioctls be redirected to?
What if there's a sensor and a video decoder? And how could the user know
about this?
When an input is selected (either via the V4L2 way - S_INPUT or via the
MC/subdev
way, there's just one video decoder or sensor associated to the corresponding
V4L2 node).
It's the same old issues again... let's discuss this in the Multimedia
summit.
We can discuss more at the summit, but we should start discussing it here, as
otherwise we may not be able to go into a consensus there, due to the limited
amount of time we would have for each topic.
Sounds good to me, but sometimes face-to-face discussion just is not
replaceable.
We've scheduled some time for discussing it there, and we may schedule more
discussions
a about that if needed during the rest of the week.
Regards,
Mauro
--
To unsubscribe
Re: [PATCH] af9013 frontend tuner bus lock
http://dl.dropbox.com/u/1541853/VID_20111006_004447.3gp That looks very familiar! Does it occur on tuner A or B? I get this I2C messages: # tail -f /var/log/messages Oct 5 20:16:44 htpc kernel: [ 534.168957] af9013: I2C read failed reg:d330 As far as I know I never had any such messages. Maybe though the debugging isn't enabled properly. There are lots of ber and unc bits, I have connected the TV to the same wire and there is a good signal. Yes, your TV might have a better receiver though - I have the same problem, if my TV decoding is OK but the signal is weak then my DVB cards have problems. I have solved this signal problem by using quad-shield cable and F-connectors and proper metal can splitters so now everything gets a good signal. I am pretty sure my issues are not signal related because Tuner A is fine until tuner B is enabled and tuner B always records a very low error signal (usually not even one visible error). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/media: fix dependencies in video mt9t001/mt9p031
Hi Mauro, On Fri, 30 Sep 2011 15:38:13 -0700 Randy Dunlap rdun...@xenotime.net wrote: On 09/30/11 14:34, Paul Gortmaker wrote: Both mt9t001.c and mt9p031.c have two identical issues, those being that they will need module.h inclusion for the upcoming cleanup going on there, and that their dependencies don't limit selection of configs that will fail to compile as follows: drivers/media/video/mt9p031.c:457: error: implicit declaration of function ‘v4l2_subdev_get_try_crop’ drivers/media/video/mt9t001.c:787: error: ‘struct v4l2_subdev’ has no member named ‘entity’ The related config options are CONFIG_MEDIA_CONTROLLER and CONFIG_VIDEO_V4L2_SUBDEV_API. Looking at the code, it appears that the driver was never intended to work without these enabled, so add a dependency on CONFIG_VIDEO_V4L2_SUBDEV_API, which in turn already has a dependency on CONFIG_MEDIA_CONTROLLER. Reported-by: Randy Dunlap rdun...@xenotime.net Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com Acked-by: Randy Dunlap rdun...@xenotime.net Ping? -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp3Pyk3Hv8Hm.pgp Description: PGP signature
Re: Help with omap3isp resizing
On Wednesday, 5 October 2011 9:55 PM Sakari Ailus wrote:
On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
Hi Ivan,
On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
I've been having trouble getting the resizer to work,
and
mainly because I don't know how to correctly configure
it.
I'm using kernel 2.6.37 on arm DM37x board.
I've been able to configure the media links
sensor=ccdc=ccdc_output (all with 640x480
V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
/dev/video2.
But if I configure media links
sensor=ccdc=resizer=resizer_output, then
VIDIOC_STREAMON fails on /dev/video6 (with pixelformat
mismatch). I noticed that the resizer driver only
supports
V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16,
so I
tried again with all the links set to
V4L2_MBUS_FMT_UYVY8_1X16 instead, but then ioctl
VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8, because
the
sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the
sensor
and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either
failed with pixelformat mismatch or link pipeline
mismatch, depending on which pads were different.
Can someone please tell me what I need to do to make
this work?
Long story short, I don't think that pipeline has ever
been tested.
I'm unfortunately lacking hardware to work on that, as
none
of my
OMAP3 hardware has a YUV input.
If i am not mistaken currently resizer sub device supports
only:
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
};
Adding something like this [1] in ispresizer.c should add
support
2X8 formats. Completely untested :-).
Regards,
iivanov
[1]
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct
v4l2_subdev *sd, struct v4l2_subdev_fh *fh, static const
unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
};
I'd rather modify ispccdc.c to output
V4L2_MBUS_FMT_YUYV8_1X16.
What do you think ?
For memory-Resizer-memory use cases, CCDC is no involved in
pipeline.
But the original poster wants to use the sensor - ccdc - resizer
- resizer output pipeline.
Also several sensor drivers that i have checked, usually define
its output as 2X8 output. I think is more natural to add 2X8
support to CCDC and Resizer engines instead to modifying exiting
drivers.
Sure, sensor drivers should not be modified. What I was talking
about was to configure the pipeline as
sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16],
resizer:0 [YUYV8_1X16]
--
Regards,
Laurent Pinchart
Thanks for your help. I've updated ispccdc.c to support the _1X16
codes and the pipeline seems to work now. However, I needed to take
out the memcpy in ccdc_try_format(), because otherwise pad 0 format
was being copied to pad 1 or 2, regardless of what pad 1 or 2 were
being set to. I'm not sure why it was done that way. I think it's
better that the given code gets checked to see if it's in the list
and
if so use it. Do you know of any valid reason why this copy is done?
If I remember corretly, it's because there's nothing the CCDC may do
to the size
of the image --- the driver doesn't either support cropping on the
CCDC. The sink
format used to be always the same as the source format, the assumption
which
no longer is valid when YUYV8_2X8 etc. formats are supported. This
must be
taken into account, i.e. YUYV8_2X8 must be converted to YUYV8_1X16
instead of
just copying the format as such.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
FYI ... here's the diff of the ISP CCDC changes I made to get the
sensor-ccdc-resizer pipeline to work.
Note: it's based on kernel 2.6.37.
--- drivers/media/video/isp/ispccdc.c
+++ drivers/media/video/isp/ispccdc.c
@@ -53,6 +53,10 @@
V4L2_MBUS_FMT_SGBRG12_1X12,
V4L2_MBUS_FMT_UYVY8_2X8,
V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_UYVY8_1X16,
+ V4L2_MBUS_FMT_VYUY8_1X16,
+ V4L2_MBUS_FMT_YUYV8_1X16,
