Re: [PATCH] Multifrontend support for saa7134
Hi Herman
I analyse related dvb code today and I'm totally confused that your card
dosn't work. So, it is handled like MEDION_MD8800_QUADRO yes?
Could you send me full log with enabled i2c debug please?
With and without my patch, using DVB-S part.
Thank you for your time.
Lukas
Dne Ne 1. listopadu 2009 03:40:50 jste napsal(a):
Hi Lukas, Petr and Eddi,
thanks for working on it.
Am Samstag, den 31.10.2009, 21:21 +0100 schrieb Lukáš Karas:
Hi all,
here is patch for multifrontend support in saa7134 driver. It is derived
from patches on page http://tux.dpeddi.com/lr319sta/
This patch has effect on these cards:
* FlyDVB Trio
* Medion MD8800 Quadro
* ASUSTeK Tiger 3in1
The a little bit hidden low profile triple CTX948 is also involved, just
to have it mentioned. We treat it like the Medion MD8800 Quadro, CTX944,
with subsystem 16be:0007.
It was tested with FlyDVB Trio card.
If you could, please test it with other cards too.
Some first tests on the CTX944 don't look such promising yet.
On DVB-T only one transponder remains and even that one is heavily
disturbed.
On DVB-S only about one third of the previous services is still
available. Lots of such.
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=0) returns 0
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=1)
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=1) returns 0
tda10086_diseqc_wait: diseqc queue not ready, command may be lost.
tda10086_diseqc_wait: diseqc queue not ready, command may be lost.
tda10086_diseqc_wait: diseqc queue not ready, command may be lost.
tda10086_diseqc_wait: diseqc queue not ready, command may be lost.
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=0)
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=0) returns 0
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=1)
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=1) returns 0
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=0)
I do have the Asus Tiger 3in1 and the triple CTX948 too, but can't
promise when I get time to test on those less complicated devices.
Cheers,
Hermann
Regards,
Lukas
Signed-off-by: Lukas Karas lukas.ka...@centrum.cz
Tested-by: Petr Fiala petr.fi...@gmail.com
diff -uprN
./linux-a76d06e9ff9b/drivers/media/video/saa7134/saa7134-cards.c
./linux/drivers/media/video/saa7134/saa7134- cards.c
---
./linux-a76d06e9ff9b/drivers/media/video/saa7134/saa7134-cards.c2009-10-
31 10:40:46.0 +0100 +++
./linux/drivers/media/video/saa7134/saa7134-cards.c 2009-10-31
17:47:51.0 +0100 @@ -614,6 +614,7 @@ struct saa7134_board
saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 1,
@@ -1352,6 +1353,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+.num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 1,
@@ -1895,6 +1897,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT | TDA9887_INTERCARRIER |
TDA9887_PORT2_INACTIVE, .mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -1987,6 +1990,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.gpiomask = 0x0020,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 1,
@@ -2020,6 +2024,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_comp1,
.vmux = 0,
@@ -2126,6 +2131,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.gpiomask = 0x0020,
.inputs = {{
.name = name_tv,
@@ -2426,6 +2432,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT | TDA9887_PORT1_ACTIVE,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
Re: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
On Thu, 5 Nov 2009, Hans Verkuil wrote: On Thursday 05 November 2009 17:51:50 Guennadi Liakhovetski wrote: On Thu, 5 Nov 2009, Hans Verkuil wrote: On Friday 30 October 2009 15:01:27 Guennadi Liakhovetski wrote: Video subdevices, like cameras, decoders, connect to video bridges over specialised busses. Data is being transferred over these busses in various formats, which only loosely correspond to fourcc codes, describing how video data is stored in RAM. This is not a one-to-one correspondence, therefore we cannot use fourcc codes to configure subdevice output data formats. This patch adds codes for several such on-the-bus formats and an API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those codes. After all users of the old API in struct v4l2_subdev_video_ops are converted, the API will be removed. OK, this seems to completely disregard points raised in my earlier bus and data format negotiation RFC which is available here once www.mail-archive.org is working again: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg09644.html BTW, ignore the 'Video timings' section of that RFC. That part is wrong. The big problem I have with this proposal is the unholy mixing of bus and memory formatting. That should be completely separated. Only the bridge knows how a bus format can be converted into which memory (pixel) formats. Please, explain why only the bridge knows about that. My model is the following: 1. we define various data formats on the bus. Each such format variation gets a unique identification. 2. given a data format ID the data format is perfectly defined. This means, you do not have to have a special knowledge about this specific format to be able to handle it in some _generic_ way. A typical such generic handling on a bridge is, for instance, copying the data into memory one-to-one. For example, if a sensor delivers 10 bit monochrome data over an eight bit bus as follows y7 y6 y5 y4 y3 y2 y1 y0 xx xx xx xx xx xx y9 y8 ... then _any_ bridge, capable of just copying data from the bus bytewise into RAM will be able to produce little-endian 10-bit grey pixel format in RAM. This handling is _not_ bridge specific. This is what I call packing. Of course it is bridge dependent. It is the bridge that takes data from the bus and puts it in memory. In many cases that is done very simply by bytewise copying. Other bridges can do RGB to YUV or vice versa conversions or can do endianness conversion or can do JPEG/MPEG compression on the fly or whatever else hardware designers will think of. It's no doubt true for the SoCs you have been working with, but it is not so simple in general. Ok, I forgot to mention one more point in the model: 4. Each bridge has _two_ ways to process data: data-format-specific and generic (pass-through). It's the _former_ one that is bridge specific, quite right! For a bridge to be able to process a data format, that it can process in a _special_ way, it doesn't need v4l2_imgbus_pixelfmt, it's only for data-formats, that bridges do _not_ know specifically they need it. In that _generic_ case it is not bridge-specific and a bridge driver can just look into the respective v4l2_imgbus_pixelfmt descriptor. Consider the following: a bridge can process N formats in a specific way. It knows which bits in which order represent which colours, etc. In such a case you just tell the driver format X and that's all it has to know about it to be able to handle it. The sensor, connected to the bridge, can also provide format Y, which the bridge doesn't know about. So what, there's then no way to use that format? Or do we have to add a _special_ handling rule for each format to each bridge driver?... 3. Therefore, each bridge, capable of handling of some generic data using some specific packing, can perfectly look through data-format descriptors, see if it finds any with the supported packing, and if so, it _then_ knows, that it can use that specific data format and the specific packing to produce the resulting pixel format from the format descriptor. A bus format is also separate from the colorspace: that is an independent piece of data. Sure. TBH, I do not quite how enum v4l2_colorspace is actually used. Is it uniquely defined by each pixel format? So, it can be derived from that? Then it is indeed redundant. Can drop, don't care about it that much. It's independent from the pixel format. So the same pixel (or bus) format can have different colorspaces. Then I do not understand what a colourspace means in v4l context. You mean a yuv format can belong to a jpeg, or an srgb space?... Personally I would just keep using v4l2_pix_format, except that the fourcc field refers to a busimg format rather
Re: [PATCH 0/4 v6] Support for TVP7002 in DM365
My apologies, found that I had the wrong mailing list email for linux-media. Sending patches (hopefully) for the last time. Santiago. Hans Verkuil wrote: On Wednesday 04 November 2009 18:23:40 Santiago Nunez-Corrales wrote: This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application and video output in 480P, 576P, 720P and 1080I. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri. Erm, where is the rest of the series? :-) Regards, Hans -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Nov 5 19:00:08 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13316:c57f47cfb0e8 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc3-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc3-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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
Make file request: default adddepmod instead of allyesmod
I tried to guide a newbie through compiling v4l. v4l did not compile right away, because of a problem in one of the drivers http://ubuntuforums.org/showthread.php?p=8241469#post8241469 a workaroudn was proposed: http://ubuntuforums.org/showthread.php?t=1305228 I myself have not experienced this problem as I have used make alldepmod, where the offending driver was not selected. Can the default config be reprogrammed from all yes (which might easily fail on certain kernel versions) to the all dep config ? That way, new users have more chance to have a succesful make right away. -- 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: Capturing video and still images using one driver
(forwarding to the new v4l list) --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Forwarded message -- Date: Thu, 5 Nov 2009 21:37:46 +0100 (CET) From: Guennadi Liakhovetski ly...@axis700.grange To: Robert Jarzmik robert.jarz...@free.fr Cc: Neil Johnson realdealn...@gmail.com, video4linux-l...@redhat.com Subject: Re: Capturing video and still images using one driver On Wed, 4 Nov 2009, Robert Jarzmik wrote: Guennadi Liakhovetski g.liakhovet...@gmx.de writes: I came across the same problem when working on the rj54n1cb0c driver. What's even more exciting with that sensor, is that it has separate frame-size settings for preview (video) and still capture. It seems this behaviour is generic across several sensors. As far as I know, the mt9m111 has 2 modes : low power low resolution, and high power high resolution, and both are programmable apart (in terms of resolution, zoom, etc ...) What this makes me think is that a sensor could provide several contexts of use, as : - full resolution still image context - low resolution still image context - full resolution video context - low resolution video context Why fixed resolutions? Just make it possible to issue S_FMT for video or for still imaging... That would work seamlessly with several inputs (S_INPUT, S_FMT...). Then, a new/existing v4l2 call would switch the context (perhaps based on buffer type ?) of the sensor. ...on a second thought, it doesn't seem that smart to me any more to tie the streaming vs. still mode distinction to a specific buffer type... Well, that's just some junk I've been thinking over lately. 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
I have one of these too.
lsusb:
Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
In addition I have a DViCO Dual Digital Express which is a PCIe card
based on Conexant, with the Zarlink frontend.
lspci:
04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
Subsystem: DViCO Corporation Device [18ac:db78]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
Capabilities: access denied
Kernel driver in use: cx23885
Kernel modules: cx23885
More detail, including dmesg etc, at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/459523
On 11/6/09, Devin Heitmueller dheitmuel...@kernellabs.com wrote:
On Thu, Nov 5, 2009 at 12:23 AM, Robert Lowery rglow...@exemail.com.au
wrote:
Hi Devin,
Thanks for your reply.
I don't think your suggestion to use disable_power_mgmt will work as I
already tried setting the no_poweroff=1 kernel module without success (and
even tried recompiling with xc2028_sleep returning 0 immediately, but
until I stopped the .sleep being set at all in xc2028_dvb_tuner_ops, the
problem kept happening.
The only thing that fixed it without code change was to set
dvb_powerdown_on_sleep=0.
Looking at the below code from dvb_frontend.c, the only difference I could
see between setting no_poweroff=1 and not setting .sleep is the latter
stops i2c_gate_ctrl being called.
if (dvb_powerdown_on_sleep) {
if (fe-ops.set_voltage)
fe-ops.set_voltage(fe, SEC_VOLTAGE_OFF);
if (fe-ops.tuner_ops.sleep) {
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
fe-ops.tuner_ops.sleep(fe);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
}
if (fe-ops.sleep)
fe-ops.sleep(fe);
}
I'm not very familiar with this code. Am I missing something?
-Rob
Could you please clarify exactly which card you have (PCI/USB ID)?
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
--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Thu, Nov 5, 2009 at 3:57 PM, Vincent McIntyre vincent.mcint...@gmail.com wrote: I have one of these too. lsusb: Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 (ZL10353+xc2028/xc3028) (initialized) Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 (ZL10353+xc2028/xc3028) (initialized) In addition I have a DViCO Dual Digital Express which is a PCIe card based on Conexant, with the Zarlink frontend. lspci: 04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02) Subsystem: DViCO Corporation Device [18ac:db78] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M] Capabilities: access denied Kernel driver in use: cx23885 Kernel modules: cx23885 Crap. This is the price I pay for not having noticed Robert included a launchpad ticket with the dmesg output. Yeah, it's a zl10353, so I know what the problem is. Let me look at the code and send you a patch for testing. If you don't hear back from me within 24 hours, ping me again. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v2] ezx: Add camera support for A780 and A910 EZX phones
On Thu, 5 Nov 2009 00:53:46 +0100 (CET)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Wed, 4 Nov 2009, Antonio Ospite wrote:
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
Signed-off-by: Bart Visscher ba...@thisnet.nl
Is this patch going via Bart? Or should this be an Acked-by?
Bart did the initial research and wrote a first, partially working,
version of the patch for A780, then I made it work and refactored it,
adding code for A910. So I put two SOBs here as we are both the
authors, in a sense.
Changes since previous version:
Addressed all the comments from Eric and Guennadi.
I said I still wanted to have a better look at it, so, basically, I just
think you have a typo in two comments:
Or the code is wrong, even if it works :)
Let's sort this out.
[...]
+/* camera */
+static int a780_pxacamera_init(struct device *dev)
+{
+ int err;
+
+ /*
+* GPIO50_nCAM_EN is active low
+* GPIO19_GEN1_CAM_RST is active high
+*/
+ err = gpio_request(GPIO50_nCAM_EN, nCAM_EN);
+ if (err) {
+ pr_err(%s: Failed to request nCAM_EN\n, __func__);
+ goto fail;
+ }
+
+ err = gpio_request(GPIO19_GEN1_CAM_RST, CAM_RST);
+ if (err) {
+ pr_err(%s: Failed to request CAM_RST\n, __func__);
+ goto fail_gpio_cam_rst;
+ }
+
+ gpio_direction_output(GPIO50_nCAM_EN, 0);
+ gpio_direction_output(GPIO19_GEN1_CAM_RST, 1);
Don't understand this, are you sure your comments are correct? This would
mean, that in init() you enable the camera and hold it in reset.
I am pretty confident the comments are right,
they came from runtime analysis with gpiotool on original firmware.
The reset happens when bringing the signal from low to high, so
holding it high or low it's basically the same here, and given how
a780_pxacamera_reset() works I decided to keep it high.
I also need to put CAM_EN active in init(), because of how
soc_camera_probe() works, adding some debug I get this call sequence
(with CAM_EN not active):
Linux video capture interface: v2.00
pxa27x-camera pxa27x-camera.0: Limiting master clock to 2600
pxa27x-camera pxa27x-camera.0: LCD clock 10400Hz, target freq 2600Hz,
divisor 1
pxa27x-camera pxa27x-camera.0: got DMA channel 1
pxa27x-camera pxa27x-camera.0: got DMA channel (U) 2
pxa27x-camera pxa27x-camera.0: got DMA channel (V) 3
camera 0-0: Probing 0-0
camera 0-0: soc_camera_probe: power 1
-- a780_pxacamera_power: called. on: 1 !on: 0
camera 0-0: soc_camera_probe: reset
-- a780_pxacamera_reset: called
pxa27x-camera pxa27x-camera.0: Registered platform device at cc8a5380 data
c03a40a8
pxa27x-camera pxa27x-camera.0: pxa_camera_activate: Init gpios
-- a780_pxacamera_init: called
pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to camera 0
camera 0-0: mt9m111_video_probe: called
i2c: error: exhausted retries
i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0
i2c: ICR: 07e0 ISR: 0002
i2c: log: [0446:07e0]
mt9m111 0-005d: read reg.00d - ff87
mt9m111 0-005d: mt9m11x init failed: -121
mt9m111: probe of 0-005d failed with error -121
pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0
camera 0-0: soc_camera_probe: power 0
a780_pxacamera_power: called. on: 0 !on: 1
camera: probe of 0-0 failed with error -12
See? It's power(), reset(), init().
Maybe the problem is in soc_camera_probe()?
+
+ return 0;
+
+fail_gpio_cam_rst:
+ gpio_free(GPIO50_nCAM_EN);
+fail:
+ return err;
+}
+
+static int a780_pxacamera_power(struct device *dev, int on)
+{
+ gpio_set_value(GPIO50_nCAM_EN, !on);
This agrees with the comment above, but then why do you enable it
immediately in init?
See above.
+ return 0;
+}
+
+static int a780_pxacamera_reset(struct device *dev)
+{
+ gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
+ msleep(10);
+ gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
This, however, seems to contradict the comment and confirm the code above
- looks like your reset pin is active low too?
Well, reset happens when bringing the GPIO to HIGH but only after some
time it was LOW, so I consider it active high but maybe I am messing up
with terminology here?
[...]
+static struct soc_camera_link a780_iclink = {
+ .bus_id = 0,
+ .flags = SOCAM_SENSOR_INVERT_PCLK,
Do you have schematics or have you found this out experimentally? What
happens if you don't invert pclk?
I've found this experimentally, and I think I was the reason why you
introduced SOCAM_SENSOR_INVERT_PCLK, see
http://thread.gmane.org/gmane.comp.video.video4linux/40592
If I don't invert pixelclock I get a picture like this:
http://people.openezx.org/ao2/a780-not-yet.jpg
[...]
A general question for the ezx.c: wouldn't it be better to convert that
full-of-ifdef's file to a mach-pxa/ezx/ directory?
Actually we are fine using a single file, there are many parts shared
between different
Re: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Thu, Nov 5, 2009 at 3:57 PM, Vincent McIntyre
vincent.mcint...@gmail.com wrote:
I have one of these too.
lsusb:
Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
In addition I have a DViCO Dual Digital Express which is a PCIe card
based on Conexant, with the Zarlink frontend.
lspci:
04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
Subsystem: DViCO Corporation Device [18ac:db78]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
Capabilities: access denied
Kernel driver in use: cx23885
Kernel modules: cx23885
Crap. This is the price I pay for not having noticed Robert included
a launchpad ticket with the dmesg output.
Yeah, it's a zl10353, so I know what the problem is. Let me look at
the code and send you a patch for testing. If you don't hear back
from me within 24 hours, ping me again.
Do you mean something like this (untested) patch? I'll try it out tonight.
diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Sun Nov 01 07:17:46 2009
-0200
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Fri Nov 06 10:39:38 2009
+1100
@@ -666,6 +666,14 @@
.parallel_ts = 1,
};
+static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate = {
+ .demod_address = 0x0f,
+ .if2 = 45600,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+ .disable_i2c_gate_ctrl = 1,
+};
+
static struct mt352_config cxusb_mt352_xc3028_config = {
.demod_address = 0x0f,
.if2 = 4560,
@@ -897,7 +905,7 @@
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
if ((adap-fe = dvb_attach(zl10353_attach,
- cxusb_zl10353_xc3028_config,
+ cxusb_zl10353_xc3028_config_no_i2c_gate,
adap-dev-i2c_adap)) == NULL)
return -EIO;
Cheers,
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
--
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
pac7311
Hello! I'm using a webcam which identifies itself as 093a:2603 Pixart Imaging, Inc. PAC7312 Camera and is sort-of supported by the gspca_pac7311 module. sort-of because the image alternates quickly between having a red tint or a green tint (using the gspca driver from http://linuxtv.org/hg/~jfrancois/gspca/ on a 2.6.31 kernel; occurs also with plain 2.6.31). Is there something I can do to debug/fix this problem? - Lars -- 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Thu, Nov 5, 2009 at 6:45 PM, Robert Lowery rglow...@exemail.com.au wrote:
Do you mean something like this (untested) patch? I'll try it out tonight.
diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Sun Nov 01 07:17:46 2009
-0200
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Fri Nov 06 10:39:38 2009
+1100
@@ -666,6 +666,14 @@
.parallel_ts = 1,
};
+static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate = {
+ .demod_address = 0x0f,
+ .if2 = 45600,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+ .disable_i2c_gate_ctrl = 1,
+};
+
static struct mt352_config cxusb_mt352_xc3028_config = {
.demod_address = 0x0f,
.if2 = 4560,
@@ -897,7 +905,7 @@
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
if ((adap-fe = dvb_attach(zl10353_attach,
- cxusb_zl10353_xc3028_config,
+ cxusb_zl10353_xc3028_config_no_i2c_gate,
adap-dev-i2c_adap)) == NULL)
return -EIO;
Wow, that looks shockingly similar to the patch I did for an em28xx
boards a couple of months ago, even down to the part where you added
_no_i2c_gate to the end! :-)
Yeah, that's the fix, although from the diff I can't tell if you're
doing it for all zl10353 boards in cxusb.c or just yours. I would
have to see the source to know for sure.
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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Thu, Nov 5, 2009 at 6:45 PM, Robert Lowery rglow...@exemail.com.au
wrote:
Do you mean something like this (untested) patch? I'll try it out
tonight.
diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Sun Nov 01 07:17:46 2009
-0200
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Fri Nov 06 10:39:38 2009
+1100
@@ -666,6 +666,14 @@
.parallel_ts = 1,
};
+static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate =
{
+ .demod_address = 0x0f,
+ .if2 = 45600,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+ .disable_i2c_gate_ctrl = 1,
+};
+
static struct mt352_config cxusb_mt352_xc3028_config = {
.demod_address = 0x0f,
.if2 = 4560,
@@ -897,7 +905,7 @@
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
if ((adap-fe = dvb_attach(zl10353_attach,
- cxusb_zl10353_xc3028_config,
+
cxusb_zl10353_xc3028_config_no_i2c_gate,
adap-dev-i2c_adap)) == NULL)
return -EIO;
Wow, that looks shockingly similar to the patch I did for an em28xx
boards a couple of months ago, even down to the part where you added
_no_i2c_gate to the end! :-)
I might have got some inspiration from somewhere :)
Yeah, that's the fix, although from the diff I can't tell if you're
doing it for all zl10353 boards in cxusb.c or just yours. I would
have to see the source to know for sure.
I only changed cxusb_dualdig4_frontend_attach() so it should be just my
board. The only other board that was using cxusb_zl10353_xc3028_config
was cxusb_nano2_frontend_attach(), but I left that as is since I don't
know if that board is similarily affected.
I'l try it out tonight and confirm it fixes the problem
Thanks for your help
-Rob
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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Thu, Nov 5, 2009 at 6:45 PM, Robert Lowery rglow...@exemail.com.au
wrote:
Do you mean something like this (untested) patch? I'll try it out
tonight.
diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Sun Nov 01 07:17:46
2009
-0200
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Fri Nov 06 10:39:38
2009
+1100
@@ -666,6 +666,14 @@
.parallel_ts = 1,
};
+static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate =
{
+ .demod_address = 0x0f,
+ .if2 = 45600,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+ .disable_i2c_gate_ctrl = 1,
+};
+
static struct mt352_config cxusb_mt352_xc3028_config = {
.demod_address = 0x0f,
.if2 = 4560,
@@ -897,7 +905,7 @@
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
if ((adap-fe = dvb_attach(zl10353_attach,
- cxusb_zl10353_xc3028_config,
+
cxusb_zl10353_xc3028_config_no_i2c_gate,
adap-dev-i2c_adap)) == NULL)
return -EIO;
Wow, that looks shockingly similar to the patch I did for an em28xx
boards a couple of months ago, even down to the part where you added
_no_i2c_gate to the end! :-)
I might have got some inspiration from somewhere :)
Yeah, that's the fix, although from the diff I can't tell if you're
doing it for all zl10353 boards in cxusb.c or just yours. I would
have to see the source to know for sure.
I only changed cxusb_dualdig4_frontend_attach() so it should be just my
board. The only other board that was using cxusb_zl10353_xc3028_config
was cxusb_nano2_frontend_attach(), but I left that as is since I don't
know if that board is similarily affected.
I'll try it out tonight and confirm it fixes the problem
Devin,
I have confirmed the patch below fixes my issue. Could you please merge
it for me?
Thanks
-Rob
Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1)
Signed Off: Robert Lowery rglow...@exemail.com.au
diff -r c57f47cfb0e8 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Wed Nov 04 18:21:15 2009
-0200
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Fri Nov 06 13:28:07 2009
+1100
@@ -666,6 +666,14 @@
.parallel_ts = 1,
};
+static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate = {
+ .demod_address = 0x0f,
+ .if2 = 45600,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+ .disable_i2c_gate_ctrl = 1,
+};
+
static struct mt352_config cxusb_mt352_xc3028_config = {
.demod_address = 0x0f,
.if2 = 4560,
@@ -897,7 +905,7 @@
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
if ((adap-fe = dvb_attach(zl10353_attach,
- cxusb_zl10353_xc3028_config,
+ cxusb_zl10353_xc3028_config_no_i2c_gate,
adap-dev-i2c_adap)) == NULL)
return -EIO;
--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Thu, Nov 5, 2009 at 9:31 PM, Robert Lowery rglow...@exemail.com.au wrote: Devin, I have confirmed the patch below fixes my issue. Could you please merge it for me? Thanks -Rob Sure. I'm putting together a patch series for this weekend with a few different misc fixes. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2] Davinci VPFE Capture: Add support for Control ioctls
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Thursday, November 05, 2009 9:48 PM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH V2] Davinci VPFE Capture: Add support for
Control ioctls
On Thursday 29 October 2009 07:51:04 hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Added support for Control IOCTL,
- s_ctrl
- g_ctrl
- queryctrl
Change from last patch:
- added room for error return in queryctrl function.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 43
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index abe21e4..8275d02 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1368,6 +1368,46 @@ static int vpfe_g_std(struct file *file,
void *priv, v4l2_std_id *std_id)
return 0;
}
+static int vpfe_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+ int ret = 0;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ ret = v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+core, queryctrl, qctrl);
+
+ if (ret)
+ qctrl-flags |= V4L2_CTRL_FLAG_DISABLED;
Please remove this bogus flag. Just do:
[Hiremath, Vaibhav] Hans, while implementing this ioctl I was also thinking the
same, but v4l2_ctrl_check do check this flag and also in V4L2 spec it has been
mentioned that
This control is permanently disabled and should be ignored by the application.
So I thought this may be useful for standard applications, we still have some
drivers do use this flag actually.
Thanks,
Vaibhav
return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
core, queryctrl, qctrl);
Simple and effective.
Regards,
Hans
+
+ return ret;
+}
+
+static int vpfe_g_ctrl(struct file *file, void *priv, struct
v4l2_control *ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+core, g_ctrl, ctrl);
+}
+
+static int vpfe_s_ctrl(struct file *file, void *priv, struct
v4l2_control *ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+core, s_ctrl, ctrl);
+}
+
/*
* Videobuf operations
*/
@@ -1939,6 +1979,9 @@ static const struct v4l2_ioctl_ops
vpfe_ioctl_ops = {
.vidioc_querystd = vpfe_querystd,
.vidioc_s_std= vpfe_s_std,
.vidioc_g_std= vpfe_g_std,
+ .vidioc_queryctrl= vpfe_queryctrl,
+ .vidioc_g_ctrl = vpfe_g_ctrl,
+ .vidioc_s_ctrl = vpfe_s_ctrl,
.vidioc_reqbufs = vpfe_reqbufs,
.vidioc_querybuf = vpfe_querybuf,
.vidioc_qbuf = vpfe_qbuf,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-
media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-
media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4 v6] Support for TVP7002 in DM365
On Thursday 05 November 2009 20:03:26 Santiago Nunez-Corrales wrote: My apologies, found that I had the wrong mailing list email for linux-media. Sending patches (hopefully) for the last time. Sorry, but I still do not see any patches on either linux-media or davinci-linux-open-source... Regards, Hans Santiago. Hans Verkuil wrote: On Wednesday 04 November 2009 18:23:40 Santiago Nunez-Corrales wrote: This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application and video output in 480P, 576P, 720P and 1080I. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri. Erm, where is the rest of the series? :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] Davinci VPFE Capture: Add support for Control ioctls
On Friday 06 November 2009 06:30:42 Hiremath, Vaibhav wrote:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Thursday, November 05, 2009 9:48 PM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH V2] Davinci VPFE Capture: Add support for
Control ioctls
On Thursday 29 October 2009 07:51:04 hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Added support for Control IOCTL,
- s_ctrl
- g_ctrl
- queryctrl
Change from last patch:
- added room for error return in queryctrl function.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 43
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index abe21e4..8275d02 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1368,6 +1368,46 @@ static int vpfe_g_std(struct file *file,
void *priv, v4l2_std_id *std_id)
return 0;
}
+static int vpfe_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+ int ret = 0;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ ret = v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+ core, queryctrl, qctrl);
+
+ if (ret)
+ qctrl-flags |= V4L2_CTRL_FLAG_DISABLED;
Please remove this bogus flag. Just do:
[Hiremath, Vaibhav] Hans, while implementing this ioctl I was also thinking
the same, but v4l2_ctrl_check do check this flag and also in V4L2 spec it has
been mentioned that
This control is permanently disabled and should be ignored by the
application.
So I thought this may be useful for standard applications, we still have some
drivers do use this flag actually.
The use of this flag is for very specific cases as is documented in a footnote
in the v4l2 spec:
V4L2_CTRL_FLAG_DISABLED was intended for two purposes: Drivers can skip
predefined
controls not supported by the hardware (although returning EINVAL would do as
well),
or disable predefined and private controls after hardware detection without the
trouble of reordering control arrays and indices (EINVAL cannot be used to skip
private controls because it would prematurely end the enumeration).
In both cases you would only check for this flag if queryctrl returns 0, so
setting the flag AND returning an error is unnecessary.
Regards,
Hans
Thanks,
Vaibhav
return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
core, queryctrl, qctrl);
Simple and effective.
Regards,
Hans
+
+ return ret;
+}
+
+static int vpfe_g_ctrl(struct file *file, void *priv, struct
v4l2_control *ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+ core, g_ctrl, ctrl);
+}
+
+static int vpfe_s_ctrl(struct file *file, void *priv, struct
v4l2_control *ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+ core, s_ctrl, ctrl);
+}
+
/*
* Videobuf operations
*/
@@ -1939,6 +1979,9 @@ static const struct v4l2_ioctl_ops
vpfe_ioctl_ops = {
.vidioc_querystd = vpfe_querystd,
.vidioc_s_std= vpfe_s_std,
.vidioc_g_std= vpfe_g_std,
+ .vidioc_queryctrl= vpfe_queryctrl,
+ .vidioc_g_ctrl = vpfe_g_ctrl,
+ .vidioc_s_ctrl = vpfe_s_ctrl,
.vidioc_reqbufs = vpfe_reqbufs,
.vidioc_querybuf = vpfe_querybuf,
.vidioc_qbuf = vpfe_qbuf,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-
media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-
media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line
Re: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
On Thursday 05 November 2009 19:56:04 Guennadi Liakhovetski wrote: On Thu, 5 Nov 2009, Hans Verkuil wrote: On Thursday 05 November 2009 17:51:50 Guennadi Liakhovetski wrote: On Thu, 5 Nov 2009, Hans Verkuil wrote: On Friday 30 October 2009 15:01:27 Guennadi Liakhovetski wrote: Video subdevices, like cameras, decoders, connect to video bridges over specialised busses. Data is being transferred over these busses in various formats, which only loosely correspond to fourcc codes, describing how video data is stored in RAM. This is not a one-to-one correspondence, therefore we cannot use fourcc codes to configure subdevice output data formats. This patch adds codes for several such on-the-bus formats and an API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those codes. After all users of the old API in struct v4l2_subdev_video_ops are converted, the API will be removed. OK, this seems to completely disregard points raised in my earlier bus and data format negotiation RFC which is available here once www.mail-archive.org is working again: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg09644.html BTW, ignore the 'Video timings' section of that RFC. That part is wrong. The big problem I have with this proposal is the unholy mixing of bus and memory formatting. That should be completely separated. Only the bridge knows how a bus format can be converted into which memory (pixel) formats. Please, explain why only the bridge knows about that. My model is the following: 1. we define various data formats on the bus. Each such format variation gets a unique identification. 2. given a data format ID the data format is perfectly defined. This means, you do not have to have a special knowledge about this specific format to be able to handle it in some _generic_ way. A typical such generic handling on a bridge is, for instance, copying the data into memory one-to-one. For example, if a sensor delivers 10 bit monochrome data over an eight bit bus as follows y7 y6 y5 y4 y3 y2 y1 y0 xx xx xx xx xx xx y9 y8 ... then _any_ bridge, capable of just copying data from the bus bytewise into RAM will be able to produce little-endian 10-bit grey pixel format in RAM. This handling is _not_ bridge specific. This is what I call packing. Of course it is bridge dependent. It is the bridge that takes data from the bus and puts it in memory. In many cases that is done very simply by bytewise copying. Other bridges can do RGB to YUV or vice versa conversions or can do endianness conversion or can do JPEG/MPEG compression on the fly or whatever else hardware designers will think of. It's no doubt true for the SoCs you have been working with, but it is not so simple in general. Ok, I forgot to mention one more point in the model: 4. Each bridge has _two_ ways to process data: data-format-specific and generic (pass-through). It's the _former_ one that is bridge specific, quite right! For a bridge to be able to process a data format, that it can process in a _special_ way, it doesn't need v4l2_imgbus_pixelfmt, it's only for data-formats, that bridges do _not_ know specifically they need it. In that _generic_ case it is not bridge-specific and a bridge driver can just look into the respective v4l2_imgbus_pixelfmt descriptor. Consider the following: a bridge can process N formats in a specific way. It knows which bits in which order represent which colours, etc. In such a case you just tell the driver format X and that's all it has to know about it to be able to handle it. The sensor, connected to the bridge, can also provide format Y, which the bridge doesn't know about. So what, there's then no way to use that format? Or do we have to add a _special_ handling rule for each format to each bridge driver?... 3. Therefore, each bridge, capable of handling of some generic data using some specific packing, can perfectly look through data-format descriptors, see if it finds any with the supported packing, and if so, it _then_ knows, that it can use that specific data format and the specific packing to produce the resulting pixel format from the format descriptor. A bus format is also separate from the colorspace: that is an independent piece of data. Sure. TBH, I do not quite how enum v4l2_colorspace is actually used. Is it uniquely defined by each pixel format? So, it can be derived from that? Then it is indeed redundant. Can drop, don't care about it that much. It's independent from the pixel format. So the same pixel (or bus) format can have different colorspaces. Then I do not understand what a
RE: Finished my email backlog, let me know if I missed anything
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Thursday, November 05, 2009 10:01 PM To: linux-media@vger.kernel.org Subject: Finished my email backlog, let me know if I missed anything Hi all, As I've been away/busy for a few weeks I had a large pile of pending emails. I went through it all today, but if I missed anything then please remind me. [Hiremath, Vaibhav] Hans, there are some patches which I posted which need to be merged. Can you have look at it? VPFE - 6 patches - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev-ccdc_irq1 - Davinci VPFE Capture: Add support for Control ioctls[note: posting again] - TVP514x:Switch to automode for s_input/querystd - Davinci VPFE Capture: Take i2c adapter id through platform data OMAP - 2 patches - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR - v4l2 doc: Added S/G_ROTATE, S/G_BG_COLOR information - V4L2: Add Capability and Flag field for Croma Key - OMAP2/3 V4L2:Add support for OMAP2/3 V4L2 driver ontop of DSS2[Note: need to repost again] Thanks, Vaibhav Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux- media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Finished my email backlog, let me know if I missed anything
On Friday 06 November 2009 07:49:47 Hiremath, Vaibhav wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Thursday, November 05, 2009 10:01 PM To: linux-media@vger.kernel.org Subject: Finished my email backlog, let me know if I missed anything Hi all, As I've been away/busy for a few weeks I had a large pile of pending emails. I went through it all today, but if I missed anything then please remind me. [Hiremath, Vaibhav] Hans, there are some patches which I posted which need to be merged. Can you have look at it? Sure, I'll go through them this weekend. Thanks for reminding me! Regards, Hans VPFE - 6 patches - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev-ccdc_irq1 - Davinci VPFE Capture: Add support for Control ioctls[note: posting again] - TVP514x:Switch to automode for s_input/querystd - Davinci VPFE Capture: Take i2c adapter id through platform data OMAP - 2 patches - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR - v4l2 doc: Added S/G_ROTATE, S/G_BG_COLOR information - V4L2: Add Capability and Flag field for Croma Key - OMAP2/3 V4L2:Add support for OMAP2/3 V4L2 driver ontop of DSS2[Note: need to repost again] Thanks, Vaibhav Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux- media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pac7311
On Fri, 6 Nov 2009 00:38:43 +0100 Lars Noschinski l...@public.noschinski.de wrote: I'm using a webcam which identifies itself as 093a:2603 Pixart Imaging, Inc. PAC7312 Camera and is sort-of supported by the gspca_pac7311 module. sort-of because the image alternates quickly between having a red tint or a green tint (using the gspca driver from http://linuxtv.org/hg/~jfrancois/gspca/ on a 2.6.31 kernel; occurs also with plain 2.6.31). Is there something I can do to debug/fix this problem? Hello Lars, First, which viewer do you run and does it use the v4l2 library? Then, a bug in the pac7311 driver has been found yesterday. Did you get/try this last one? Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
On Fri, 6 Nov 2009, Hans Verkuil wrote: On Thursday 05 November 2009 19:56:04 Guennadi Liakhovetski wrote: On Thu, 5 Nov 2009, Hans Verkuil wrote: On Thursday 05 November 2009 17:51:50 Guennadi Liakhovetski wrote: On Thu, 5 Nov 2009, Hans Verkuil wrote: On Friday 30 October 2009 15:01:27 Guennadi Liakhovetski wrote: Video subdevices, like cameras, decoders, connect to video bridges over specialised busses. Data is being transferred over these busses in various formats, which only loosely correspond to fourcc codes, describing how video data is stored in RAM. This is not a one-to-one correspondence, therefore we cannot use fourcc codes to configure subdevice output data formats. This patch adds codes for several such on-the-bus formats and an API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those codes. After all users of the old API in struct v4l2_subdev_video_ops are converted, the API will be removed. OK, this seems to completely disregard points raised in my earlier bus and data format negotiation RFC which is available here once www.mail-archive.org is working again: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg09644.html BTW, ignore the 'Video timings' section of that RFC. That part is wrong. The big problem I have with this proposal is the unholy mixing of bus and memory formatting. That should be completely separated. Only the bridge knows how a bus format can be converted into which memory (pixel) formats. Please, explain why only the bridge knows about that. My model is the following: 1. we define various data formats on the bus. Each such format variation gets a unique identification. 2. given a data format ID the data format is perfectly defined. This means, you do not have to have a special knowledge about this specific format to be able to handle it in some _generic_ way. A typical such generic handling on a bridge is, for instance, copying the data into memory one-to-one. For example, if a sensor delivers 10 bit monochrome data over an eight bit bus as follows y7 y6 y5 y4 y3 y2 y1 y0 xx xx xx xx xx xx y9 y8 ... then _any_ bridge, capable of just copying data from the bus bytewise into RAM will be able to produce little-endian 10-bit grey pixel format in RAM. This handling is _not_ bridge specific. This is what I call packing. Of course it is bridge dependent. It is the bridge that takes data from the bus and puts it in memory. In many cases that is done very simply by bytewise copying. Other bridges can do RGB to YUV or vice versa conversions or can do endianness conversion or can do JPEG/MPEG compression on the fly or whatever else hardware designers will think of. It's no doubt true for the SoCs you have been working with, but it is not so simple in general. Ok, I forgot to mention one more point in the model: 4. Each bridge has _two_ ways to process data: data-format-specific and generic (pass-through). It's the _former_ one that is bridge specific, quite right! For a bridge to be able to process a data format, that it can process in a _special_ way, it doesn't need v4l2_imgbus_pixelfmt, it's only for data-formats, that bridges do _not_ know specifically they need it. In that _generic_ case it is not bridge-specific and a bridge driver can just look into the respective v4l2_imgbus_pixelfmt descriptor. Consider the following: a bridge can process N formats in a specific way. It knows which bits in which order represent which colours, etc. In such a case you just tell the driver format X and that's all it has to know about it to be able to handle it. The sensor, connected to the bridge, can also provide format Y, which the bridge doesn't know about. So what, there's then no way to use that format? Or do we have to add a _special_ handling rule for each format to each bridge driver?... 3. Therefore, each bridge, capable of handling of some generic data using some specific packing, can perfectly look through data-format descriptors, see if it finds any with the supported packing, and if so, it _then_ knows, that it can use that specific data format and the specific packing to produce the resulting pixel format from the format descriptor. A bus format is also separate from the colorspace: that is an independent piece of data. Sure. TBH, I do not quite how enum v4l2_colorspace is actually used. Is it uniquely defined by each pixel format? So, it can be derived from that? Then it is indeed redundant. Can
