Re: [PATCH] Fix the issue with audio module correction of Names
On Saturday 14 March 2009 04:08:26 Sri Deevi wrote: Mauro and Hans, Please see the attached mailbox attachment created with 'hg email..' I still need some more time to setup the email a/c with linux box that I am using. Sri, I got a Recipient address rejected: User unknown in relay recipient table after mailing this reply to you. I'm CC-ing this to the list as well in the hope that you'll see it here. This patch corrects the following: 1. Wrong PID for RDU250 board 2. Audio module was missing as driver was expecting in different name as cx231xx-alsa.ko 3. Fixed some names in printk 3. Fixed v4l2_sub_dev issue with the driver. Hi Sri, Can you use normal attachments in the future rather than a mailbox attachment? My mailer had some problems with that. I've reviewed the v4l2_subdev patch and there are still a few things that need to be done: 1) In cx231xx_usb_probe() you need to unregister the just registered v4l2_device before you return with an error. It's part of the cleanup, just like the kfree(dev). 2) cx231xx_vdev_init should assign vfd-v4l2_dev rather than assigning vfd-parent. That way the video_device struct has a pointer to the top-level v4l2_device struct. 3) the attach_inform and detach_inform should be removed as these are only relevant to the old i2c autoprobing behavior. BTW, you asked me before why I thought that the Hammerhead could also be on address 0x80. That's from the attach_inform function that reports a Hammerhead on both 0x80 and 0x88. 4) There is still a request_module(tuner) that has to be replaced by a v4l2_i2c_new_subdev() call as well. 5) cx231xx_i2c_call_clients must be removed as well. Instead use the new v4l2_device_call_all() macro (see the framework doc). The big advantage of using this is that the command goes to all subdevices, regardless of the i2c adapter they are on (in fact, they don't have to be i2c devices at all!). If you need to send a command to a specific device then you can either store the v4l2_subdev pointer in your main cx231xx struct and use v4l2_subdev_call, or set the grp_id field of the v4l2_subdev and use that to direct where the command will go to (again, see the framework doc). I tend to just store the subdev pointer if there is only one or two subdevs that need this treatment, and I use grp_id if it gets more complicated than that. For example, ivtv makes full use of the grp_id since it has to juggle so many different i2c devices. I think this is all that it needed to have it fully comply to the new API. Thanks for the quick work! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
Fw: [PATCH 1/1 re-submit 1] sdio: add low level i/o functions for workarounds
Hi Pierre,
Uri sent me this patchset, as part of the changes for supporting some devices
from Siano.
The changeset looks fine, although I have no experiences with MMC. Are you
applying it on your tree, or do you prefer if I apply here?
If you're applying on yours, this is my ack:
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
Cheers,
Mauro.
Forwarded message:
Date: Thu, 12 Mar 2009 06:01:26 -0700 (PDT)
From: Uri Shkolnik uri...@yahoo.com
To: Mauro Carvalho Chehab mche...@infradead.org
Cc: Michael Krufky mkru...@linuxtv.org, linux-media@vger.kernel.org
Subject: [PATCH 1/1 re-submit 1] sdio: add low level i/o functions for
workarounds
sdio: add low level i/o functions for workarounds
From: Pierre Ossman drz...@drzeus.cx
Some shoddy hardware doesn't properly adhere to the register model
of SDIO, but treats the system like a series of transaction. That means
that the drivers must have full control over what goes the bus (and the
core cannot optimize transactions or work around problems in host
controllers).
This commit adds some low level functions that gives SDIO drivers the
ability to send specific register access commands. They should only be
used when the hardware is truly broken though.
The patch has been done against 2.6.29-rc7 .
Signed-off-by: Pierre Ossman drz...@drzeus.cx
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -uNr linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c
linux-2.6.29-rc7_sdio_patch/drivers/mmc/core/sdio_io.c
--- linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c2009-03-04
03:05:22.0 +0200
+++ linux-2.6.29-rc7_sdio_patch/drivers/mmc/core/sdio_io.c 2009-03-12
12:22:42.0 +0200
@@ -635,3 +635,252 @@
*err_ret = ret;
}
EXPORT_SYMBOL_GPL(sdio_f0_writeb);
+
+/**
+ * sdio_read_bytes - low level byte mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func-card, 0, func-num, addr, 1,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes);
+
+/**
+ * sdio_read_bytes_noincr - low level byte mode transfer from an SDIO
function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is NOT increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes_noincr(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func-card, 0, func-num, addr, 0,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes_noincr);
+
+/**
+ * sdio_read_blocks - low level block mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @block: number of blocks to read
+ *
+ * Performs a block mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * The block size needs to be explicitly changed by calling
+ * sdio_set_block_size().
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_blocks(struct sdio_func *func, void *dst,
+ unsigned int addr, int blocks)
+{
+ if (!func-card-cccr.multi_block)
+ return -EINVAL;
+
+ if (blocks func-card-host-max_blk_count)
+ return -EINVAL;
+ if (blocks (func-card-host-max_seg_size / func-cur_blksize))
+ return -EINVAL;
+ if (blocks 511)
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func-card, 0, func-num,
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
Hi Uri,
The patch looks sane, but I'd like to have a better picture of the Siano
device, to better understand this interface.
The basic question is: why do we need an SDIO interface for a DVB device? For
what reason this interface is needed?
It helps if you could forward me some information about the
architecture of Siano, to help me to understand the requirements.
Cheers,
Mauro.
On Thu, 12 Mar 2009 06:52:59 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com wrote:
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1236865697 -7200
# Node ID 7352ee1288f651d19d58c7bb479a98f070ad98e6
# Parent 3392722cc5b687586c4d898b73050ab6e59bf401
siano: add high level SDIO interface driver for SMS based cards
From: Uri Shkolnik u...@siano-ms.com
This patch provides SDIO interface driver for
SMS (Siano Mobile Silicon) based devices.
The patch includes SMS high level SDIO driver and
requires patching the kernel SDIO stack,
those stack patches had been provided previously.
I would like to thank Pierre Ossman, MMC maintainer,
who wrote this driver.
Priority: normal
Signed-off-by: Pierre Ossman drz...@drzeus.cx
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 3392722cc5b6 -r 7352ee1288f6 linux/drivers/media/dvb/siano/smssdio.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smssdio.c Thu Mar 12 15:48:17 2009 +0200
@@ -0,0 +1,356 @@
+/*
+ * smssdio.c - Siano 1xxx SDIO interface driver
+ *
+ * Copyright 2008 Pierre Ossman
+ *
+ * Based on code by Siano Mobile Silicon, Inc.,
+ * Copyright (C) 2006-2008, Uri Shkolnik
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ *
+ * This hardware is a bit odd in that all transfers should be done
+ * to/from the SMSSDIO_DATA register, yet the increase address bit
+ * always needs to be set.
+ *
+ * Also, buffers from the card are always aligned to 128 byte
+ * boundaries.
+ */
+
+/*
+ * General cleanup notes:
+ *
+ * - only typedefs should be name *_t
+ *
+ * - use ERR_PTR and friends for smscore_register_device()
+ *
+ * - smscore_getbuffer should zero fields
+ *
+ * Fix stop command
+ */
+
+#include linux/moduleparam.h
+#include linux/firmware.h
+#include linux/delay.h
+#include linux/mmc/card.h
+#include linux/mmc/sdio_func.h
+#include linux/mmc/sdio_ids.h
+
+#include smscoreapi.h
+#include sms-cards.h
+
+/* Registers */
+
+#define SMSSDIO_DATA 0x00
+#define SMSSDIO_INT 0x04
+
+static const struct sdio_device_id smssdio_ids[] = {
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_STELLAR),
+ .driver_data = SMS1XXX_BOARD_SIANO_STELLAR},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_A0),
+ .driver_data = SMS1XXX_BOARD_SIANO_NOVA_A},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_B0),
+ .driver_data = SMS1XXX_BOARD_SIANO_NOVA_B},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VEGA_A0),
+ .driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VENICE),
+ .driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ { /* end: all zeroes */ },
+};
+
+MODULE_DEVICE_TABLE(sdio, smssdio_ids);
+
+struct smssdio_device {
+ struct sdio_func *func;
+
+ struct smscore_device_t *coredev;
+
+ struct smscore_buffer_t *split_cb;
+};
+
+/***/
+/* Siano core callbacks*/
+/***/
+
+static int smssdio_sendrequest(void *context, void *buffer, size_t size)
+{
+ int ret;
+ struct smssdio_device *smsdev;
+
+ smsdev = context;
+
+ sdio_claim_host(smsdev-func);
+
+ while (size = smsdev-func-cur_blksize) {
+ ret = sdio_write_blocks(smsdev-func, SMSSDIO_DATA, buffer, 1);
+ if (ret)
+ goto out;
+
+ buffer += smsdev-func-cur_blksize;
+ size -= smsdev-func-cur_blksize;
+ }
+
+ if (size) {
+ ret = sdio_write_bytes(smsdev-func, SMSSDIO_DATA,
+buffer, size);
+ if (ret)
+ goto out;
+ }
+
+out:
+ sdio_release_host(smsdev-func);
+
+ return ret;
+}
+
+/***/
+/* SDIO callbacks */
+/***/
+
+static void smssdio_interrupt(struct sdio_func *func)
+{
+ int ret, isr;
+
+ struct smssdio_device *smsdev;
+ struct smscore_buffer_t
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
Hi Mauro, (sorry for hijacking) (since when do we like top-posts ? ;) ) On Sat, 14 Mar 2009, Mauro Carvalho Chehab wrote: Hi Uri, The patch looks sane, but I'd like to have a better picture of the Siano device, to better understand this interface. The basic question is: why do we need an SDIO interface for a DVB device? For what reason this interface is needed? The answer is relatively easy: Some hosts only have a SDIO interface, so no USB, no PCI, no I2C, no MPEG2-streaming interface. So, the device has to provide a SDIO interface in order to read and write register and to make DMAs to get the data to the host. Think of your cell-phone, or your PDA. There are some/a lot of vendors who use Linux in their commercial mobile-TV product and there are some component-makers like Siano, who are supporting those vendors through GPL drivers. regards, Patrick. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
On Thu, 12 Mar 2009 07:25:29 -0700 (PDT) Uri Shkolnik uri...@yahoo.com wrote: Mauro and all, I submitted 3 patches, two modifications for the SDIO generic stack, and one new high level SDIO interface driver for Siano based devices. This concludes SDIO related changes, with one exception, which is explained below. However this explanation requires some overview about Siano's module inner architecture. The Siano kernel module architecture is composed from: 1) SMS Core - This main component holds all Siano's host-device protocol logic, and any logic needed to bind the other module's components, interface and adapters. 2) Interfaces drivers (SDIO, USB, TS, SPP, HIF, ...) - At lease one interface driver must be compiled and linked, but multiple interfaces are supported. This feature enables platforms like the Asus UMPC series to use SMS based USB dongle and SMS based SDIO dongle simultaneously. 3) Client adapters (DVB API v3, DVB API v5, others) - Similar to the interfaces drivers, at least one client adapter must be linked, but multiple are supported. 4) SMS cards - This component contains any hardware target specific information (like LEDs locations, antenna configuration, alternative firmware names, and much more), leaving any other component target-independent. Ok, now I have some info about the architecture. Unfortunately, it is still not clear to me how the different interfaces will work together with the DVB API. What I'm trying to understand is: what the Siano devices are? They are a DVB demod, a memory card, a usb bridge, ..., so we need different interfaces because the chip has completely different functions inside? Or it is a bridge to DVB functions, where the bridge can use different buses? And now back to SDIO True all SDIO related sources files are now updated (after these 3 patches), but since the build system (Kconfig Makefile) and smscore component are yet to be updated, the SDIO interface driver can not be linked into the module. Yes. I've sent an email to Pierre to be sure about the better way for we handle it. After having his return, I'll do the adjustments at the building system to allow us to build it inside the tree. The option to link and use the SDIO interface driver, will be available after those files will be updated (hope it'll happen shortly). One question: Should I continue submit patches (I have them ready), or should I wait till the 3 previous submission will be reviewed and committed? Better to hold them for a while, until I get a better picture. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
On Sat, 14 Mar 2009 12:02:02 +0100 (CET) Patrick Boettcher patrick.boettc...@desy.de wrote: Hi Mauro, (sorry for hijacking) (since when do we like top-posts ? ;) ) You're welcome. On Sat, 14 Mar 2009, Mauro Carvalho Chehab wrote: Hi Uri, The patch looks sane, but I'd like to have a better picture of the Siano device, to better understand this interface. The basic question is: why do we need an SDIO interface for a DVB device? For what reason this interface is needed? The answer is relatively easy: Some hosts only have a SDIO interface, so no USB, no PCI, no I2C, no MPEG2-streaming interface. So, the device has to provide a SDIO interface in order to read and write register and to make DMAs to get the data to the host. Think of your cell-phone, or your PDA. There are some/a lot of vendors who use Linux in their commercial mobile-TV product and there are some component-makers like Siano, who are supporting those vendors through GPL drivers. Ok, so, if I understand well, the SDIO interface will be used just like we currently use the I2C or USB bus, right? So, we should create some glue between DVB and SDIO bus just like we have with PCI, USB, I2C, etc. Ideally something like (using the design we currently have with dvb-usb): ++ | DVB driver | ++ | V +--+ | DVB SDIO | +--+ | V +--+ | DVB Core | +--+ Is that what you're thinking? Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-api: update documentation, chapter1
Hi wk,
Let's commit what we currently have. Could you please re-submit the patch
again, this time providing a proper description, and your SOB?
Cheers,
Mauro.
On Thu, 26 Feb 2009 20:19:41 +0100
wk handygewinnsp...@gmx.de wrote:
Mauro Carvalho Chehab wrote:
+
+For this API documentation applies an even/odd versioning scheme, stating
+unstable or stable versions of that API. Only stable API versions should
+be used for developing drivers and applications.
Hmm... I wouldn't add the above. I don't think we should use such
versioning scheme for docs.
I removed that lines.
Can you please comment, how the dvb-developers want to deal with in
future with the transition to a updated documentation?
By looking at the differences between headers and doc, it will take at
least one year or even longer to finish.
Only a comment currently under review is probably not sufficient here.
Would it help to add a extra page Revision History like its done on
v4l api? If so, please suggest a format for the page.
+In 2003 Convergence and Toshiba Electronics Europe GmbH started the
development
+of
+\href
{http://www.linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf}{DVB
API Version 4}
+with public discussion on the linux-dvb mailing list. The goal was a
complete
+new API, reflecting that PCs and embedded platforms are diverging. On a PC
+usually a budget card provides the full raw transport stream and decoding
+and processing is main CPU's task. On embedded platforms, however, data is
+multiplexed by specialized hardware or firmware for direct application use
+which relieves the main CPU from these tasks. Therefore, Linux DVB
+API Version 4 was suggested, but unfortunally never completed.
It seems better to say, instead, that Version 4 was suggested, but it
weren't completed nor implemented.
I put in here as suggested by Derek:
Version 4 was suggested but neither completed, nor implemented
+Today, the LinuxTV project is an independend and non-profit community
project
s/independend/independent/
Changed.
+by DVB/V4L enthusiasts and developers interested in Digital TV and
Analog TV,
+sharing the same hg tree.
+
+However, this document describes only the digital TV part.
I would replace the last paragraph by:
This document describes the digital TV API. For Analog TV and radio,
please consult V4L2 API.
IMO, we should also add such cross-reference at the V4L2 API, and point
both to
linuxtv.org website (so, adding the corresponding \href pointers), for those
interested on getting the other API to know here both are available.
Changed and linked to
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/v4l2spec/v4l2.pdf
+
+
+With the further development of newer DTV standards, the existing version
+3 of the Linux DVB API was no longer able to support all DTV standards and
+newer hardware. Two concurrent approaches to overcome the problem where
+proposed, \texttt{Multiproto} and \texttt{S2API}.
+
+At
+\href {http://www.linuxtv.org/news.php?entry=2008-09-19.mchehab}{Linux
Plumbers Conference 2008}
+the decision was made towards to S2API, basically an extension to
+\texttt{DVB API Version 3} called \texttt{DVB API Version 5}.
+
+
+This Linux DVB API documentation will be extended to reflect these
additions.
While we don't finish adding the S2API parts, maybe we should say instead:
This document is currently under review to reflect the S2API additions.
Changed, but please answer the question above.
Also changed: dvb card - dvb device as suggested by Derek.
updated patch below.
-- Winfried
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex2009-02-26
18:40:35.008186330 +0100
@@ -1,4 +1,4 @@
-\documentclass[a4paper,10pt]{book}
+\documentclass[a4paper,10pt,oneside]{book}
\usepackage[dvips,colorlinks=true]{hyperref}
\usepackage{times}
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex2009-02-26
20:04:57.245819770 +0100
@@ -7,49 +7,84 @@
The reader of this document is required to have some knowledge in the
area of digital video broadcasting (DVB) and should be familiar with
part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222),
-i.e you should know what a program/transport stream
Re: OMAP3 ISP and camera drivers (update)
Hi Sakari and other OMAP developers, In order to better organize the OMAP stuff, I've created an account for Sakari at linuxtv.org. It is simply too much for me to review all those stuff again and again. So I want to concentrate the process with Sakari, letting him do the review of OMAP patches and coordinating the OMAP merge process. I expect that Sakari will send me periodic pull requests, after finishing the discussions, for me to do a final review and merge upstream. In order to reduce my pending list at patchwork, I'm marking all OMAP there patches as RFC, trusting that Sakari will properly handle they. Sakari, thanks for your help! Cheers, Mauro. On Fri, 06 Mar 2009 17:32:06 +0200 Sakari Ailus sakari.ai...@maxwell.research.nokia.com wrote: Hi, I've updated the patchset in Gitorious. URL:http://www.gitorious.org/projects/omap3camera Changes include - Power management support. ISP suspend/resume should work now. - Reindented and cleaned up everything. There are still some warnings from checkpatch.pl from the CSI2 code. - Fix for crash in device registration, posted to list already. (Thanks, Vaibhav, Alexey!) - LSC errors should be handled properly now. I won't post the modified patches to the list this time since I guess it wouldn't be much of use, I guess. Or does someone want that? :) Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] LED control
On Sat, 14 Mar 2009 12:59:23 +0100 Jean-Francois Moine moin...@free.fr wrote: + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LEDs or illuminators of the device. +In the control value, each LED may be coded in one bit (0: off, 1: on) or in +many bits (light intensity)./entry + /row + row The idea of having some sort of control over the LEDs is interesting, but we should have a better way of controlling it. If the LED may have more than one bit, maybe the better would be to create more than one CID entry. Something like: V4L2_CID_LED_POWER - for showing that the camera is being used V4L2_CID_LED_LIGHT - for normal white light V4L2_CID_LED_INFRARED - for dark light, using infrared ... This way a driver can enumberate what kind of leds are available, and get the power intensity range for each individual one. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/7] ARM: DaVinci: DM646x Video: THS7303 video amplifier driver
Hi Chaithrika,
This is the first pass of this i2c driver. Note that several of the comments
here also apply to adv7343.
On Friday 13 March 2009 10:01:06 chaithr...@ti.com wrote:
From: Chaithrika U S chaithr...@ti.com
THS7303 video amplifier driver code
This patch implements driver for TI THS7303 video amplifier . This driver is
implemented as a v4l2-subdev.
---
Applies to v4l-dvb repository located at
http://linuxtv.org/hg/v4l-dvb/rev/1fd54a62abde
drivers/media/video/Kconfig |9 ++
drivers/media/video/Makefile |1 +
drivers/media/video/ths7303.c | 179
+
include/media/ths7303.h | 26 ++
4 files changed, 215 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ths7303.c
create mode 100644 include/media/ths7303.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 16019e9..b3b591d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -435,6 +435,15 @@ config VIDEO_ADV7343
To compile this driver as a module, choose M here: the
module will be called adv7473.
+config VIDEO_THS7303
+ tristate THS7303 Video Amplifier
+ depends on I2C
+ help
+ Support for TI THS7303 video amplifier
+
+ To compile this driver as a module, choose M here: the
+ module will be called ths7303.
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7f9fc62..1ed9c2c 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_VIDEO_BT819) += bt819.o
obj-$(CONFIG_VIDEO_BT856) += bt856.o
obj-$(CONFIG_VIDEO_BT866) += bt866.o
obj-$(CONFIG_VIDEO_KS0127) += ks0127.o
+obj-$(CONFIG_VIDEO_THS7303) += ths7303.o
obj-$(CONFIG_VIDEO_ZORAN) += zoran/
diff --git a/drivers/media/video/ths7303.c b/drivers/media/video/ths7303.c
new file mode 100644
index 000..a78b450
--- /dev/null
+++ b/drivers/media/video/ths7303.c
@@ -0,0 +1,179 @@
+/*
+ * ths7303- THS7303 Video Amplifier driver
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/i2c.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/module.h
+#include linux/uaccess.h
+#include linux/videodev2.h
+
+#include media/v4l2-device.h
+#include media/v4l2-i2c-drv.h
Don't use v4l2-i2c-drv.h: that's for legacy kernel support only (e.g. when
the i2c driver has to run on pre-2.6.22 kernels as well). You can just
write this as a normal i2c driver.
I hope that this header can be removed in the near future to prevent this
confusion.
+#include media/v4l2-subdev.h
+#include media/ths7303.h
+
+static int debug;
Hmm, debug is not setup as a module option, so this doesn't do a lot.
You need to add something like this:
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Debug level (0-1));
+
+struct ths7303_state {
+ struct i2c_client *client;
Don't store the i2c_client pointer here. It can be obtained from v4l2_subdev.
In this case that reduces the state information to just struct v4l2_subdev...
+ struct v4l2_subdev sd;
+};
+
+static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ths7303_state, sd);
+}
...and that means that this function is not needed for this driver.
+
+/* following function is used to set ths7303 */
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ int err = 0;
+ u8 val;
+ struct ths7303_state *state;
+ struct i2c_client *client;
+
+ state = to_state(sd);
+ client = state-client;
+
+ if (client == NULL) {
+ printk(KERN_ERR THS7303 Client not found\n);
+ return -ENODEV;
+ }
Just use:
struct i2c_client *client = v4l2_get_subdevdata(sd);
There is no need to check for a valid client pointer. If you have a subdev,
then you have by definition an i2c_client pointer.
+
+ if ((std == V4L2_STD_NTSC) || (std == V4L2_STD_PAL))
+ val = 0x02;
Use 'std V4L2_STD_NTSC' since v4l2_std_id is a bitmask. I suspect that what
you really want is to AND with '(V4L2_STD_525_60 | V4L2_STD_625_50)'.
+ else if ((std == V4L2_STD_480P_60) || (std == V4L2_STD_576P_50))
+ val = 0x4A;
+
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
--- On Sat, 3/14/09, Mauro Carvalho Chehab mche...@infradead.org wrote: From: Mauro Carvalho Chehab mche...@infradead.org Subject: Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards To: Patrick Boettcher patrick.boettc...@desy.de Cc: Uri Shkolnik uri...@yahoo.com, Michael Krufky mkru...@linuxtv.org, linux-media@vger.kernel.org Date: Saturday, March 14, 2009, 1:29 PM On Sat, 14 Mar 2009 12:02:02 +0100 (CET) Patrick Boettcher patrick.boettc...@desy.de wrote: Hi Mauro, (sorry for hijacking) (since when do we like top-posts ? ;) ) You're welcome. On Sat, 14 Mar 2009, Mauro Carvalho Chehab wrote: Hi Uri, The patch looks sane, but I'd like to have a better picture of the Siano device, to better understand this interface. The basic question is: why do we need an SDIO interface for a DVB device? For what reason this interface is needed? The answer is relatively easy: Some hosts only have a SDIO interface, so no USB, no PCI, no I2C, no MPEG2-streaming interface. So, the device has to provide a SDIO interface in order to read and write register and to make DMAs to get the data to the host. Think of your cell-phone, or your PDA. There are some/a lot of vendors who use Linux in their commercial mobile-TV product and there are some component-makers like Siano, who are supporting those vendors through GPL drivers. Ok, so, if I understand well, the SDIO interface will be used just like we currently use the I2C or USB bus, right? So, we should create some glue between DVB and SDIO bus just like we have with PCI, USB, I2C, etc. Ideally something like (using the design we currently have with dvb-usb): ++ | DVB driver | ++ | V +--+ | DVB SDIO | +--+ | V +--+ | DVB Core | +--+ Is that what you're thinking? Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi all, Patrick, thanks for helping me, you can write stuff I can't (at least in public channels). Ignoring for a moment DTV and Siano - most application processors which are used for portable devices (cellular phones, PDA, others), either do not have USB port at all, or it is strongly preferred not to use it for inner device communication (due high power consumption and electrical noise from the 480MHz USB bus). In those devices, if there is a USB port, it is used mostly to connect the device externally to a PC or other external entity (than the power comes from the PC). Regarding the rough Siano's architecture (I can't extend too much) - The device interface driver (USB, SDIO, SPP) is on the bottom, used for control and data (CD) exchanged with the SMS chip-set based device. The Siano's core component is in the middle - it is a kind of an hub that routes the CD from the device(s) interface(s) to the selected adapter. The core also responsible for various common (for all interfaces and adapters) logic stuff (like firmware download, IR, ). The top component in the Siano's architecture, is the adapter. This component is responsible for the connectivity (and abstraction) toward the selected sub-system API (such as DVB-API v3, or S2/DVB-API v5, or other). Hope I made it little clearer. Regards, Uri -- 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 4/7] ARM: DaVinci: DM646x Video: Defintions for standards supported by display
On Friday 13 March 2009 10:01:37 chaithr...@ti.com wrote:
From: Chaithrika U S chaithr...@ti.com
Add defintions for Digital TV Standards supported by display driver
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to v4l-dvb repository located at
http://linuxtv.org/hg/v4l-dvb/rev/1fd54a62abde
include/linux/videodev2.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7a8eafd..df4a622 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -704,6 +704,18 @@ typedef __u64 v4l2_std_id;
#define V4L2_STD_ALL(V4L2_STD_525_60 |\
V4L2_STD_625_50)
+#define V4L2_STD_720P_60((v4l2_std_id)(0x0001ULL))
+#define V4L2_STD_1080I_30 ((v4l2_std_id)(0x0002ULL))
+#define V4L2_STD_1080I_25 ((v4l2_std_id)(0x0004ULL))
+#define V4L2_STD_480P_60((v4l2_std_id)(0x0008ULL))
+#define V4L2_STD_576P_50((v4l2_std_id)(0x0010ULL))
+#define V4L2_STD_720P_25((v4l2_std_id)(0x0020ULL))
+#define V4L2_STD_720P_30((v4l2_std_id)(0x0040ULL))
+#define V4L2_STD_720P_50((v4l2_std_id)(0x0080ULL))
+#define V4L2_STD_1080P_25 ((v4l2_std_id)(0x0100ULL))
+#define V4L2_STD_1080P_30 ((v4l2_std_id)(0x0200ULL))
+#define V4L2_STD_1080P_24 ((v4l2_std_id)(0x0400ULL))
+
struct v4l2_standard {
__u32index;
v4l2_std_id id;
This requires an RFC. I'm not convinced that using v4l2_std_id is the best
approach. If you look at the CEA-861-D you see a lot more standards (and E
adds even more). Not to mention that when the DM646x is used in combination
with e.g. an FPGA then it should be possible to supply the driver with
custom timings as well. The v4l2_std_id type was never designed for that.
My gut feeling is that v4l2_std_id should be effectively frozen and used for
the old TV broadcast standards only, and that a new API should be created
to setup these digital formats.
I've discussed this with Manju in the past, and I suggest that TI should make
a proposal in the form of an RFC that we can then discuss on the mailinglists.
One of the disadvantages of being the first who needs these HDTV formats. The
advantage of being the first is that you can design it yourself, of course!
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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] LED control
On Sat, 14 Mar 2009 09:17:47 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Sat, 14 Mar 2009 12:59:23 +0100 Jean-Francois Moine moin...@free.fr wrote: + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LEDs or illuminators of the device. +In the control value, each LED may be coded in one bit (0: off, 1: on) or in +many bits (light intensity)./entry + /row + row The idea of having some sort of control over the LEDs is interesting, but we should have a better way of controlling it. If the LED may have more than one bit, maybe the better would be to create more than one CID entry. Something like: V4L2_CID_LED_POWER- for showing that the camera is being used V4L2_CID_LED_LIGHT- for normal white light V4L2_CID_LED_INFRARED - for dark light, using infrared ... This way a driver can enumberate what kind of leds are available, and get the power intensity range for each individual one. OK for V4L2_CID_LED_INFRARED: I already know a webcam type which needs such a control, but I don't know if it is associated to a LED or to a sensor capability. I heard of some webcams with many LEDs (up to 6) and some of these last ones may be independently switched on or off. But, actually, I don't heard about individual or global LED power. So, as I understand your controls, V4L2_CID_LED_LIGHT would contain a bit array, one bit for each LED, and V4L2_CID_LED_POWER would give the light intensity for all LEDs. This last control might be added later if needed. Am I right? Cheers. -- 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: Fw: [PATCH 1/1 re-submit 1] sdio: add low level i/o functions for workarounds
Hi Mauro and Pierre,
The second patch, which add devices IDs to the SDIO' header file
(include/linux/mmc/sdio_ids.h), is also external to the Media kernel sub-tree
and falls under the domain of MMC.
Pierre - I hope that at last, after so long time, those patches will be
committed, and again, thank you very much for your help :-)
Regards,
Uri
sdio: add cards id for sms (Siano Mobile Silicon) MDTV receivers
From: Uri Shkolnik u...@siano-ms.com
Add SDIO vendor ID, and multiple device IDs for
various SMS-based MDTV SDIO adapters.
The patch has been done against 2.6.29-rc7 .
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -uNr linux-2.6.29-rc7.prestine/include/linux/mmc/sdio_ids.h
linux-2.6.29-rc7_sdio_patch/include/linux/mmc/sdio_ids.h
--- linux-2.6.29-rc7.prestine/include/linux/mmc/sdio_ids.h2009-03-04
03:05:22.0 +0200
+++ linux-2.6.29-rc7_sdio_patch/include/linux/mmc/sdio_ids.h2009-03-12
12:24:14.0 +0200
@@ -24,6 +24,14 @@
*/
#define SDIO_VENDOR_ID_MARVELL0x02df
+#define SDIO_VENDOR_ID_SIANO0x039a
+
#define SDIO_DEVICE_ID_MARVELL_LIBERTAS0x9103
+#define SDIO_DEVICE_ID_SIANO_STELLAR 0x5347
+#define SDIO_DEVICE_ID_SIANO_NOVA_A00x1100
+#define SDIO_DEVICE_ID_SIANO_NOVA_B00x0201
+#define SDIO_DEVICE_ID_SIANO_NICE0x0202
+#define SDIO_DEVICE_ID_SIANO_VEGA_A00x0300
+#define SDIO_DEVICE_ID_SIANO_VENICE0x0301
#endif
--- On Sat, 3/14/09, Mauro Carvalho Chehab mche...@infradead.org wrote:
From: Mauro Carvalho Chehab mche...@infradead.org
Subject: Fw: [PATCH 1/1 re-submit 1] sdio: add low level i/o functions for
workarounds
To: Pierre Ossman drz...@drzeus.cx
Cc: Uri Shkolnik u...@siano-ms.com, Linux Media Mailing List
linux-media@vger.kernel.org
Date: Saturday, March 14, 2009, 12:42 PM
Hi Pierre,
Uri sent me this patchset, as part of the changes for
supporting some devices
from Siano.
The changeset looks fine, although I have no experiences
with MMC. Are you
applying it on your tree, or do you prefer if I apply
here?
If you're applying on yours, this is my ack:
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
Cheers,
Mauro.
Forwarded message:
Date: Thu, 12 Mar 2009 06:01:26 -0700 (PDT)
From: Uri Shkolnik uri...@yahoo.com
To: Mauro Carvalho Chehab mche...@infradead.org
Cc: Michael Krufky mkru...@linuxtv.org,
linux-media@vger.kernel.org
Subject: [PATCH 1/1 re-submit 1] sdio: add low level i/o
functions for workarounds
sdio: add low level i/o functions for workarounds
From: Pierre Ossman drz...@drzeus.cx
Some shoddy hardware doesn't properly adhere to the
register model
of SDIO, but treats the system like a series of
transaction. That means
that the drivers must have full control over what goes the
bus (and the
core cannot optimize transactions or work around problems
in host
controllers).
This commit adds some low level functions that gives SDIO
drivers the
ability to send specific register access commands. They
should only be
used when the hardware is truly broken though.
The patch has been done against 2.6.29-rc7 .
Signed-off-by: Pierre Ossman drz...@drzeus.cx
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -uNr
linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c
linux-2.6.29-rc7_sdio_patch/drivers/mmc/core/sdio_io.c
---
linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c
2009-03-04 03:05:22.0 +0200
+++
linux-2.6.29-rc7_sdio_patch/drivers/mmc/core/sdio_io.c
2009-03-12 12:22:42.0 +0200
@@ -635,3 +635,252 @@
*err_ret = ret;
}
EXPORT_SYMBOL_GPL(sdio_f0_writeb);
+
+/**
+ * sdio_read_bytes - low level byte mode
transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from
the address space of the given
+ * SDIO function. The address is
increased for each byte. Return
+ * value indicates if the transfer
succeeded or not.
+ *
+ * Note: This is a low level function
that should only be used as a
+ * workaround when the hardware has a
crappy register abstraction
+ * that relies on specific SDIO
operations.
+ */
+int sdio_read_bytes(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes
sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return
mmc_io_rw_extended(func-card, 0, func-num, addr, 1,
+
dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes);
+
+/**
+ * sdio_read_bytes_noincr - low level
byte mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ *
Re: [PATCH] LED control
On Sat, 2009-03-14 at 09:17 -0300, Mauro Carvalho Chehab wrote: On Sat, 14 Mar 2009 12:59:23 +0100 Jean-Francois Moine moin...@free.fr wrote: + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LEDs or illuminators of the device. +In the control value, each LED may be coded in one bit (0: off, 1: on) or in +many bits (light intensity)./entry + /row + row The idea of having some sort of control over the LEDs is interesting, but we should have a better way of controlling it. If the LED may have more than one bit, maybe the better would be to create more than one CID entry. Something like: V4L2_CID_LED_POWER- for showing that the camera is being used V4L2_CID_LED_LIGHT- for normal white light V4L2_CID_LED_INFRARED - for dark light, using infrared ... This way a driver can enumberate what kind of leds are available, and get the power intensity range for each individual one. Just some random thought of mine of the subject of LED control: I have an EVK board that has 4 LED's on it. They are red and of the on/off type. (Although I suppose someday someone might install a dual color LED unit (red green) or tri-color LED unit (red yellow green) on a piece of equipment.) They are controlled by GPIOs. Right now the cx18 driver implicitly controls them when switching between audio inputs, tuner, and radio. However, I was going to internally make an LED Controller v4l2_subdevice to handle them. So I agree that *if* giving control of LEDs to the user application supports valid use cases, then the API spec needs some more thought. There are at least these uses for LED's in devices: 1. Simple indicator/display 2. Subject matter illumination for video/image capture (I'm guessing) 3. Area illimunation to provide a reference level to an on board sensor (i.e. IR motion detection?) 4. Transmission of data (e.g IR remotes) The first questions to answer in all of these cases 1. Should this be controllable from userspace? 2. Should it be a user control? (When the whole sensor orientation feedback thing came up and Hans spoke of a good fit in the API for sensor feedback, I concluded that there isn't a terribly good place in the V4L2 API for sensor feedback, miscellaneous input, or indicator status. Nor is there a good way to enumerate them. Maybe I'm missing something.) For a subcase of a display indicator to indicate device power on, if the driver can control that at all (they should be tied to the output of a voltage regulator really) why would you want a use app to lie to the user and say power is off? OK. That's the end of my random thoughts. Regards, Andy Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-device: add v4l2_device_disconnect - v4l2: call v4l2_device_disconnect in USB drivers. - tvaudio: add tda9875 support. - bttv: convert to v4l2_device. - cx88: convert to v4l2_device. These patches prepare the bttv and cx88 drivers for the v4l2_subdev conversion. Note that this is not the actual conversion, it just prepares these drivers by introducing v4l2_device. The v4l2_device_disconnect was added thanks to Mike Isely who pointed out to me that the parent device can disappear after a disconnect. The tda9875 support in tvaudio is also needed before the bttv driver can be converted to v4l2_subdev as it is otherwise impossible to correctly probe for a tda9875 or tda9874. Mauro, I don't think I'll merge the tda7432 support into tvaudio. It is a nice-to-have, but not a requirement since there are no probing conflicts with that device. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt| 11 + drivers/media/dvb/bt8xx/dvb-bt8xx.c |2 drivers/media/video/bt8xx/bttv-driver.c | 47 +++-- drivers/media/video/bt8xx/bttv-i2c.c| 10 - drivers/media/video/bt8xx/bttv.h|3 drivers/media/video/bt8xx/bttvp.h |5 drivers/media/video/cx88/cx88-cards.c |8 drivers/media/video/cx88/cx88-core.c|4 drivers/media/video/cx88/cx88-i2c.c |8 drivers/media/video/cx88/cx88.h |8 drivers/media/video/tvaudio.c | 202 +--- drivers/media/video/usbvision/usbvision-video.c |2 drivers/media/video/v4l2-device.c | 15 + drivers/media/video/w9968cf.c |4 include/media/v4l2-device.h |6 15 files changed, 279 insertions(+), 56 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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/1] siano: add high level SDIO interface driver for SMS based cards
On Sat, 14 Mar 2009, Mauro Carvalho Chehab wrote: The answer is relatively easy: Some hosts only have a SDIO interface, so no USB, no PCI, no I2C, no MPEG2-streaming interface. So, the device has to provide a SDIO interface in order to read and write register and to make DMAs to get the data to the host. Think of your cell-phone, or your PDA. Ok, so, if I understand well, the SDIO interface will be used just like we currently use the I2C or USB bus, right? So, we should create some glue between DVB and SDIO bus just like we have with PCI, USB, I2C, etc. Ideally something like (using the design we currently have with dvb-usb): [...] Actually, when I created dvb-usb with the help of a lot of contributors, it served the purpose (and still serves) that there is a lot of different USB-based DVB devices which are delivering data. Bascially every DVB-USB-box/card-vendor is using a generic or specific USB-device-controller which implements some kind of high-level interface to do e.g. I2C and streaming. Those implementations, the USB protocol and its Linux-HAL requires some overhead to implement a driver. It was useful to create some common module and interface. With SDIO I can't really see the same right now. First of all, SDIO should be much simpler as USB from the HAL point of view. Correct me if I'm wrong, but the SDIO-host controller should give simple DMA access to the device?. Another thing for me is, there isn't many SDIO DVB devices out there right now, where Linux support is required (the latter is a pity ;) ). Also, the major part of supported DVB devices in Linux is PC-based and for PC (as of today) there is PCI(e) and USB working quite well, no one needs a SDIO device. Having an SDIO device filling in to the DVB-API is rather straight forward, which makes me think that right now there is no need for a dvb-sdio.ko . Patrick. PS: please check the date of this email, when reading it in an archive in 2 years ;) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Saturday 14 March 2009 17:13:27 Mike Isely wrote: On Sat, 14 Mar 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-device: add v4l2_device_disconnect Any chance this is going to get into 2.6.29? I need to know. No, this won't go to 2.6.29. None of the drivers in 2.6.29 using this framework are USB drivers, so it's not needed there. Regards, Hans -Mike - v4l2: call v4l2_device_disconnect in USB drivers. - tvaudio: add tda9875 support. - bttv: convert to v4l2_device. - cx88: convert to v4l2_device. These patches prepare the bttv and cx88 drivers for the v4l2_subdev conversion. Note that this is not the actual conversion, it just prepares these drivers by introducing v4l2_device. The v4l2_device_disconnect was added thanks to Mike Isely who pointed out to me that the parent device can disappear after a disconnect. The tda9875 support in tvaudio is also needed before the bttv driver can be converted to v4l2_subdev as it is otherwise impossible to correctly probe for a tda9875 or tda9874. Mauro, I don't think I'll merge the tda7432 support into tvaudio. It is a nice-to-have, but not a requirement since there are no probing conflicts with that device. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt| 11 + drivers/media/dvb/bt8xx/dvb-bt8xx.c |2 drivers/media/video/bt8xx/bttv-driver.c | 47 +++-- drivers/media/video/bt8xx/bttv-i2c.c| 10 - drivers/media/video/bt8xx/bttv.h|3 drivers/media/video/bt8xx/bttvp.h |5 drivers/media/video/cx88/cx88-cards.c |8 drivers/media/video/cx88/cx88-core.c|4 drivers/media/video/cx88/cx88-i2c.c |8 drivers/media/video/cx88/cx88.h |8 drivers/media/video/tvaudio.c | 202 +--- drivers/media/video/usbvision/usbvision-video.c |2 drivers/media/video/v4l2-device.c | 15 + drivers/media/video/w9968cf.c |4 include/media/v4l2-device.h |6 15 files changed, 279 insertions(+), 56 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sat, 14 Mar 2009, Hans Verkuil wrote: On Saturday 14 March 2009 17:13:27 Mike Isely wrote: On Sat, 14 Mar 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-device: add v4l2_device_disconnect Any chance this is going to get into 2.6.29? I need to know. No, this won't go to 2.6.29. None of the drivers in 2.6.29 using this framework are USB drivers, so it's not needed there. I was going to configure the standalone version of the pvrusb2 driver to use the new framework for 2.6.29. That's why I needed to know. So I'll either configure the driver to not do this until it is built under 2.6.30 or just continue poking the structure directly for 2.6.29. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] add new frequency table for Strasbourg, France
Hi, Attached patch updates the current dvb-t/fr-Strasbourg file with relevant transponders frequency values. Please commit, Ben # HG changeset patch # User Benjamin Zores b...@geexbox.org # Date 1237053058 -3600 # Node ID 492ed381071e5aeffbbde990a069f3beb46e5dc7 # Parent fe5a6f79468e5317e394f78ccf98dbe63a83e004 new frequency table for Strasbourg, France diff -r fe5a6f79468e -r 492ed381071e util/scan/dvb-t/fr-Strasbourg --- a/util/scan/dvb-t/fr-Strasbourg Fri Mar 13 14:35:20 2009 +0100 +++ b/util/scan/dvb-t/fr-Strasbourg Sat Mar 14 18:50:58 2009 +0100 @@ -1,30 +1,17 @@ -# Strasbourg - France (DVB-T transmitter of Strasbourg ( Nondéfini ) ) -# Strasbourg - France (signal DVB-T transmis depuis l'émetteur de Nondéfini ) +# Strasbourg - France (DVB-T transmitter of Strasbourg (Nordheim)) +# contributed by Benjamin Zores b...@geexbox.org # -# ATTENTION ! Ce fichier a ete construit automatiquement a partir -# des frequences obtenues sur : http://www.tvnt.net/multiplex_frequences.htm -# en Avril 2006. Si vous constatez des problemes et voulez apporter des -# modifications au fichier, envoyez le fichier modifie a -# l'adresse linux-...@linuxtv.org (depot des fichiers d'init dvb) -# ou a l'auteur du fichier : -# Nicolas Estre n_es...@yahoo.fr +# Strasbourg - Nordheim: 22 47 48 51 61 69 +# See http://www.tvnt.net/V2/pages/342/medias/pro-bo-doc-tk-frequences_tnt.pdf # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy - Strasbourg - Nondéfini -#R1 -#T FREQ1 8MHz AUTO NONE QAM64 8k AUTO NONE -#R2 -#T FREQ2 8MHz AUTO NONE QAM64 8k AUTO NONE -#R3 -#T FREQ3 8MHz AUTO NONE QAM64 8k AUTO NONE -#R4 -#T FREQ4 8MHz AUTO NONE QAM64 8k AUTO NONE -#R5 -#T FREQ5 8MHz AUTO NONE QAM64 8k AUTO NONE -#R6 -#T FREQ6 8MHz AUTO NONE QAM64 8k AUTO NONE -## -# en Avril 2006, l'emetteur pour Strasbourg n'etait pas defini -# Vous devez donc modifier les frequences manuellement. -# SVP Renvoyez le fichier mis a jour aux contacts ci-dessus. -## +T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 570167000 8MHz 2/3 NONE QAM16 8k 1/32 NONE +T 618167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 682167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 690167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 698167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 714167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 722167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 786167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 794167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
[PATCH] MAINTAINERS: Drop references to deprecated video4linux list
Mailing list video4linux-l...@redhat.com is deprecated, so drop references to it in MAINTAINERS. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Mauro Carvalho Chehab mche...@infradead.org --- MAINTAINERS |2 -- 1 file changed, 2 deletions(-) --- linux-2.6.29-rc8.orig/MAINTAINERS 2009-03-13 08:39:30.0 +0100 +++ linux-2.6.29-rc8/MAINTAINERS2009-03-14 19:17:56.0 +0100 @@ -1040,7 +1040,6 @@ BTTV VIDEO4LINUX DRIVER P: Mauro Carvalho Chehab M: mche...@infradead.org L: linux-media@vger.kernel.org -L: video4linux-l...@redhat.com W: http://linuxtv.org T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git S: Maintained @@ -4739,7 +4738,6 @@ VIDEO FOR LINUX (V4L) P: Mauro Carvalho Chehab M: mche...@infradead.org L: linux-media@vger.kernel.org -L: video4linux-l...@redhat.com W: http://linuxtv.org T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git S: Maintained -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 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:Sat Mar 14 19:00:07 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11038:626c136ec221 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc7-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc7-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc7-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-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc7-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc7-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc7-powerpc64: OK 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-rc7-x86_64: WARNINGS fw/apps: WARNINGS sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc7): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build 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
Re: [PATCH] LED control
On Sat, 14 Mar 2009, Mauro Carvalho Chehab wrote: On Sat, 14 Mar 2009 12:59:23 +0100 Jean-Francois Moine moin...@free.fr wrote: + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LEDs or illuminators of the device. +In the control value, each LED may be coded in one bit (0: off, 1: on) or in +many bits (light intensity)./entry + /row + row The idea of having some sort of control over the LEDs is interesting, but we should have a better way of controlling it. If the LED may have more than one bit, maybe the better would be to create more than one CID entry. Something like: V4L2_CID_LED_POWER- for showing that the camera is being used V4L2_CID_LED_LIGHT- for normal white light V4L2_CID_LED_INFRARED - for dark light, using infrared ... This way a driver can enumberate what kind of leds are available, and get the power intensity range for each individual one. There is already a sysfs led interface, you could just have the driver export the leds to the led subsystem and use that. -- 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
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from: http://linuxtv.org/hg/~awalls/v4l-dvb for the following: v4l2-api: Add definitions for V4L2_MPEG_STREAM_VBI_FMT_IVTV payloads v4l2-spec: Added data formats used for Sliced VBI data in MPEG streams Regards, Andy diffstat linux/include/linux/ivtv.h | 10 - linux/include/linux/videodev2.h | 47 + v4l2-spec/Makefile |1 v4l2-spec/dev-sliced-vbi.sgml | 315 +++- v4l2-spec/v4l2.sgml | 17 +- 5 files changed, 382 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Update remaining references to old video4linux list
The video4linux-l...@redhat.com list is deprecated, point the users to the new linux-media list instead. Signed-off-by: Jean Delvare kh...@linux-fr.org --- linux/Documentation/video4linux/bttv/README |4 ++-- linux/drivers/media/radio/radio-si470x.c |4 ++-- linux/drivers/media/video/bt8xx/bttv-cards.c |2 +- v4l/scripts/make_kconfig.pl |4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) --- v4l-dvb.orig/linux/Documentation/video4linux/bttv/README2009-03-01 16:09:08.0 +0100 +++ v4l-dvb/linux/Documentation/video4linux/bttv/README 2009-03-14 22:13:43.0 +0100 @@ -63,8 +63,8 @@ If you have some knowledge and spare tim yourself (patches very welcome of course...) You know: The linux slogan is Do it yourself. -There is a mailing list: video4linux-l...@redhat.com. -https://listman.redhat.com/mailman/listinfo/video4linux-list +There is a mailing list: linux-me...@vger.kernel.org. +http://vger.kernel.org/vger-lists.html#linux-media If you have trouble with some specific TV card, try to ask there instead of mailing me directly. The chance that someone with the --- v4l-dvb.orig/linux/drivers/media/radio/radio-si470x.c 2009-03-04 09:52:51.0 +0100 +++ v4l-dvb/linux/drivers/media/radio/radio-si470x.c2009-03-14 22:12:55.0 +0100 @@ -1713,8 +1713,8 @@ static int si470x_usb_driver_probe(struc printk(KERN_WARNING DRIVER_NAME : If you have some trouble using this driver,\n); printk(KERN_WARNING DRIVER_NAME - : please report to V4L ML at - video4linux-l...@redhat.com\n); + : please report to linux-media ML at + linux-me...@vger.kernel.org\n); } /* set initial frequency */ --- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-cards.c 2009-03-13 09:59:49.0 +0100 +++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-cards.c2009-03-14 22:13:08.0 +0100 @@ -2953,7 +2953,7 @@ void __devinit bttv_idcard(struct bttv * btv-c.nr, btv-cardid 0x, (btv-cardid 16) 0x); printk(KERN_DEBUG please mail id, board name and - the correct card= insmod option to video4linux-l...@redhat.com\n); + the correct card= insmod option to linux-me...@vger.kernel.org\n); } } --- v4l-dvb.orig/v4l/scripts/make_kconfig.pl2009-03-14 19:57:47.0 +0100 +++ v4l-dvb/v4l/scripts/make_kconfig.pl 2009-03-14 22:14:28.0 +0100 @@ -576,8 +576,8 @@ config VIDEO_KERNEL_VERSION requiring a newer kernel is that no one has tested them with an older one yet. - If the driver works, please post a report at V4L mailing list: - video4linux-li...@redhat.com. + If the driver works, please post a report at linux-media mailing + list: linux-med...@vger.kernel.org. Unless you know what you are doing, you should answer N. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Update remaining references to old video4linux list
On Saturday 14 March 2009 22:25:14 Jean Delvare wrote: The video4linux-l...@redhat.com list is deprecated, point the users to the new linux-media list instead. Signed-off-by: Jean Delvare kh...@linux-fr.org --- linux/Documentation/video4linux/bttv/README |4 ++-- linux/drivers/media/radio/radio-si470x.c |4 ++-- linux/drivers/media/video/bt8xx/bttv-cards.c |2 +- v4l/scripts/make_kconfig.pl |4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) --- v4l-dvb.orig/linux/Documentation/video4linux/bttv/README 2009-03-01 16:09:08.0 +0100 +++ v4l-dvb/linux/Documentation/video4linux/bttv/README 2009-03-14 22:13:43.0 +0100 @@ -63,8 +63,8 @@ If you have some knowledge and spare tim yourself (patches very welcome of course...) You know: The linux slogan is Do it yourself. -There is a mailing list: video4linux-l...@redhat.com. -https://listman.redhat.com/mailman/listinfo/video4linux-list +There is a mailing list: linux-me...@vger.kernel.org. +http://vger.kernel.org/vger-lists.html#linux-media If you have trouble with some specific TV card, try to ask there instead of mailing me directly. The chance that someone with the --- v4l-dvb.orig/linux/drivers/media/radio/radio-si470x.c 2009-03-04 09:52:51.0 +0100 +++ v4l-dvb/linux/drivers/media/radio/radio-si470x.c 2009-03-14 22:12:55.0 +0100 @@ -1713,8 +1713,8 @@ static int si470x_usb_driver_probe(struc printk(KERN_WARNING DRIVER_NAME : If you have some trouble using this driver,\n); printk(KERN_WARNING DRIVER_NAME - : please report to V4L ML at - video4linux-l...@redhat.com\n); + : please report to linux-media ML at + linux-me...@vger.kernel.org\n); } /* set initial frequency */ --- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-cards.c 2009-03-13 09:59:49.0 +0100 +++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-cards.c 2009-03-14 22:13:08.0 +0100 @@ -2953,7 +2953,7 @@ void __devinit bttv_idcard(struct bttv * btv-c.nr, btv-cardid 0x, (btv-cardid 16) 0x); printk(KERN_DEBUG please mail id, board name and -the correct card= insmod option to video4linux-l...@redhat.com\n); +the correct card= insmod option to linux-me...@vger.kernel.org\n); } } --- v4l-dvb.orig/v4l/scripts/make_kconfig.pl 2009-03-14 19:57:47.0 +0100 +++ v4l-dvb/v4l/scripts/make_kconfig.pl 2009-03-14 22:14:28.0 +0100 @@ -576,8 +576,8 @@ config VIDEO_KERNEL_VERSION requiring a newer kernel is that no one has tested them with an older one yet. -If the driver works, please post a report at V4L mailing list: - video4linux-li...@redhat.com. + If the driver works, please post a report at linux-media mailing + list: linux-med...@vger.kernel.org. Unless you know what you are doing, you should answer N. I've already done this in my tree. It's probably easier for Mauro to just pull from my v4l-dvb tree. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] Update remaining references to old video4linux list
Hi Hans, On Sat, 14 Mar 2009 22:39:35 +0100, Hans Verkuil wrote: On Saturday 14 March 2009 22:25:14 Jean Delvare wrote: The video4linux-l...@redhat.com list is deprecated, point the users to the new linux-media list instead. Signed-off-by: Jean Delvare kh...@linux-fr.org --- linux/Documentation/video4linux/bttv/README |4 ++-- linux/drivers/media/radio/radio-si470x.c |4 ++-- linux/drivers/media/video/bt8xx/bttv-cards.c |2 +- v4l/scripts/make_kconfig.pl |4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) (...) I've already done this in my tree. It's probably easier for Mauro to just pull from my v4l-dvb tree. Sure, no problem. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 6/7] ARM: DaVinci: DM646x Video: Add VPIF driver
Phew, the last review.
First a comment on the vpif.h header (and the dm646x.h header as well, for
that matter): no need to use #ifdef __KERNEL__. You are by definition inside
the kernel and it isn't a public header either.
I also think that these headers belong next to the driver and not in
include/media: headers in that directory are for the use of other drivers and
not for a header that is only used by the driver itself.
My only other comment basically comes back to the same issue I've raised
before in that we need a better generic API to specify formats for digital
video timings. I don't like the timing tables in the vpif.c source. They
seem out of place to me.
Most of these tables just contain the timing specs from the CEA standard
and as such are really generic. Something like that certainly belongs in
a separate source and should probably be part of the generic v4l core.
What I would find a more logical organization is that the main dm646x
source looks up a specified video standard in this timing table and
just gives vpif.c those timings. That will also make it very natural
to have the user specify those timings explicitly since that just
bypasses the table lookup and allows the user to give the timings
directly to the vpif.
I admit that in my day time job I've had to edit these tables a lot
to get it to use my own custom timings, so I am probably biased. But I doubt
I am the only one who is going outside the box with this device. You need
to be able to set these timings explicitly in order to be reasonably future
proof, IMHO.
Regards,
Hans
On Friday 13 March 2009 10:02:23 chaithr...@ti.com wrote:
From: Chaithrika U S chaithr...@ti.com
Video Port Interface driver
Add VPIF driver for DM646x. This code be used by the display and
capture drivers.
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to v4l-dvb repository located at
http://linuxtv.org/hg/v4l-dvb/rev/1fd54a62abde
drivers/media/video/davinci/vpif.c | 362 +++
include/media/davinci/vpif.h | 672
2 files changed, 1034 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpif.c
create mode 100644 include/media/davinci/vpif.h
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
new file mode 100644
index 000..8dbe5a4
--- /dev/null
+++ b/drivers/media/video/davinci/vpif.c
@@ -0,0 +1,362 @@
+/*
+ * vpif - DM646x Video Port driver
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/kernel.h
+#include media/davinci/vpif.h
+
+#define VPIF_CH0_MAX_MODES (22)
+#define VPIF_CH1_MAX_MODES (02)
+#define VPIF_CH2_MAX_MODES (15)
+#define VPIF_CH3_MAX_MODES (02)
+
+/* This structure is used to keep track of VPIF size register's offsets */
+struct vpif_registers {
+ u32 h_cfg, v_cfg_00, v_cfg_01, v_cfg_02, v_cfg, ch_ctrl;
+ u32 line_offset, vanc0_strt, vanc0_size, vanc1_strt;
+ u32 vanc1_size, width_mask, len_mask;
+ u8 max_modes;
+};
+
+static struct vpif_registers vpifregs[VPIF_NUM_CHANNELS] = {
+ /* Channel0 */
+ {VPIF_CH0_H_CFG, VPIF_CH0_V_CFG_00, VPIF_CH0_V_CFG_01,
+ VPIF_CH0_V_CFG_02, VPIF_CH0_V_CFG_03, VPIF_CH0_CTRL,
+ VPIF_CH0_IMG_ADD_OFST, 0, 0, 0, 0, 0x1FFF, 0xFFF, VPIF_CH0_MAX_MODES},
+ /* Channel1 */
+ {VPIF_CH1_H_CFG, VPIF_CH1_V_CFG_00, VPIF_CH1_V_CFG_01,
+ VPIF_CH1_V_CFG_02, VPIF_CH1_V_CFG_03, VPIF_CH1_CTRL,
+ VPIF_CH1_IMG_ADD_OFST, 0, 0, 0, 0, 0x1FFF, 0xFFF, VPIF_CH1_MAX_MODES},
+ /* Channel2 */
+ {VPIF_CH2_H_CFG, VPIF_CH2_V_CFG_00, VPIF_CH2_V_CFG_01,
+ VPIF_CH2_V_CFG_02, VPIF_CH2_V_CFG_03, VPIF_CH2_CTRL,
+ VPIF_CH2_IMG_ADD_OFST, VPIF_CH2_VANC0_STRT, VPIF_CH2_VANC0_SIZE,
+ VPIF_CH2_VANC1_STRT, VPIF_CH2_VANC1_SIZE, 0x7FF, 0x7FF,
+ VPIF_CH2_MAX_MODES},
+ /* Channel3 */
+ {VPIF_CH3_H_CFG, VPIF_CH3_V_CFG_00, VPIF_CH3_V_CFG_01,
+ VPIF_CH3_V_CFG_02, VPIF_CH3_V_CFG_03, VPIF_CH3_CTRL,
+ VPIF_CH3_IMG_ADD_OFST, VPIF_CH3_VANC0_STRT, VPIF_CH3_VANC0_SIZE,
+ VPIF_CH3_VANC1_STRT, VPIF_CH3_VANC1_SIZE, 0x7FF, 0x7FF,
+ VPIF_CH3_MAX_MODES}
+};
+
+static struct vpif_channel_config_params ch0_params[VPIF_CH0_MAX_MODES] = {
+ {NTSC, 720, 480, 30, 0, 1, 268, 1440, 1, 23, 263, 266,
+ 286, 525, 525, 0, 1, 0, V4L2_STD_NTSC},
+ {PAL, 720, 576, 25, 0, 1, 280, 1440,
Pinnacle PCTV Hybrid Pro Card (310c)... once again...
Hello readers, Amazon just had this card transported to me today... and of course I gave the in-kernel 2.6.28.7 drivers a shot, but it didn't work out at all, so I thought giving the repo provided in the wiki article (for reference: http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_Hybrid_Pro_Card_%28310c%29) would be a good idea. Thus, I removed every in-kernel tuner and DVB module, checked the repo out, build the new modules and had them installed. This, however, yielded following results (dmesg extract): [ 1988.812035] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 [ 1988.812102] pci :07:00.0: reg 10 32bit mmio: [0x00-0xff] [ 1988.812225] pci :07:00.1: reg 10 32bit mmio: [0x00-0xff] [ 1988.812341] pci :07:00.2: reg 10 32bit mmio: [0x00-0xff] [ 2003.326837] cx25843.c: starting probe for adapter SMBus I801 adapter at 18e0 (0x40004) [ 2003.328060] cx25843.c: detecting cx25843 client on address 0x88 [ 2003.328090] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.328511] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.328961] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.335211] em28xx: Unknown symbol v4l_compat_translate_ioctl [ 2003.335404] em28xx: Unknown symbol v4l2_video_std_construct [ 2003.335850] em28xx: Unknown symbol v4l2_type_names [ 2003.339965] em28xx: Unknown symbol v4l_printk_ioctl [ 2003.340663] em28xx: Unknown symbol video_unregister_device [ 2003.340851] em28xx: Unknown symbol video_device_alloc [ 2003.340948] em28xx: Unknown symbol video_register_device [ 2003.342372] em28xx: Unknown symbol video_usercopy [ 2003.342470] em28xx: Unknown symbol video_device_release [ 2003.352874] em28xx_audio: Unknown symbol em28xx_i2c_call_clients [ 2003.353305] em28xx_audio: Unknown symbol snd_pcm_new [ 2003.353407] em28xx_audio: Unknown symbol snd_card_register [ 2003.353508] em28xx_audio: Unknown symbol snd_card_free [ 2003.353683] em28xx_audio: Unknown symbol snd_component_add [ 2003.353873] em28xx_audio: Unknown symbol snd_card_new [ 2003.353977] em28xx_audio: Unknown symbol snd_pcm_lib_ioctl [ 2003.354280] em28xx_audio: Unknown symbol em28xx_unregister_extension [ 2003.354465] em28xx_audio: Unknown symbol snd_pcm_set_ops [ 2003.354570] em28xx_audio: Unknown symbol snd_pcm_hw_constraint_integer [ 2003.354691] em28xx_audio: Unknown symbol em28xx_register_extension [ 2003.354910] em28xx_audio: Unknown symbol snd_pcm_period_elapsed [ 2003.357625] em28xx_aad: Unknown symbol em28xx_unregister_extension [ 2003.357753] em28xx_aad: Unknown symbol em28xx_register_extension [ 2003.358895] em28xx_dvb: Unknown symbol dvb_dmxdev_init [ 2003.359262] em28xx_dvb: Unknown symbol dvb_register_adapter [ 2003.359506] em28xx_dvb: Unknown symbol dvb_dmx_release [ 2003.359602] em28xx_dvb: Unknown symbol em28xx_unregister_extension [ 2003.359787] em28xx_dvb: Unknown symbol dvb_net_init [ 2003.359886] em28xx_dvb: Unknown symbol dvb_dmx_swfilter [ 2003.360514] em28xx_dvb: Unknown symbol dvb_dmxdev_release [ 2003.360638] em28xx_dvb: Unknown symbol dvb_frontend_detach [ 2003.360737] em28xx_dvb: Unknown symbol dvb_net_release [ 2003.360898] em28xx_dvb: Unknown symbol em28xx_register_extension [ 2003.361189] em28xx_dvb: Unknown symbol dvb_unregister_frontend [ 2003.361455] em28xx_dvb: Unknown symbol dvb_register_frontend [ 2003.361554] em28xx_dvb: Unknown symbol dvb_unregister_adapter [ 2003.361653] em28xx_dvb: Unknown symbol dvb_dmx_init [ 2003.362770] em28xx_audioep: Unknown symbol snd_pcm_new [ 2003.362872] em28xx_audioep: Unknown symbol snd_card_register [ 2003.362973] em28xx_audioep: Unknown symbol snd_card_free [ 2003.363375] em28xx_audioep: Unknown symbol snd_card_new [ 2003.363479] em28xx_audioep: Unknown symbol snd_pcm_lib_ioctl [ 2003.363659] em28xx_audioep: Unknown symbol snd_pcm_set_ops [ 2003.363843] em28xx_audioep: Unknown symbol snd_pcm_hw_constraint_integer [ 2003.364044] em28xx_audioep: Unknown symbol snd_pcm_period_elapsed [ 2038.162200] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 As you can see, there were several problems, I'll explain them a little bit further: first of all a lot of unresolved symbols which are part of ALSA itself (snd_* ones.) This is perfectly valid and true since I don't use ALSA but OSS, however, using the provided modules seems not to be working without ALSA - bummer deal... I'd appreciate any help here (other than switch to ALSA rants, of course, which are not very productive!) Secondly, there are a lot of unresolved dvb* symbol errors personally I can not explain. After this episode of failing I wanted to give LinuxTV.org's v4l-dvb tree a shot... once again had all installed v4l and dvb modules removed (module-wise out of the Kernel as well as file-wise on the harddisk of course), checked out the other repo, built the modules, installed them, re-inserted the card. This time I got the following new errors, but at least not the old
Re: Pinnacle PCTV Hybrid Pro Card (310c)... once again...
On Sun, Mar 15, 2009 at 12:29 AM, Mihai Moldovan io...@ionic.de wrote: Hello readers, Amazon just had this card transported to me today... and of course I gave the in-kernel 2.6.28.7 drivers a shot, but it didn't work out at all, so I thought giving the repo provided in the wiki article (for reference: http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_Hybrid_Pro_Card_%28310c%29) would be a good idea. Thus, I removed every in-kernel tuner and DVB module, checked the repo out, build the new modules and had them installed. This, however, yielded following results (dmesg extract): [ 1988.812035] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 [ 1988.812102] pci :07:00.0: reg 10 32bit mmio: [0x00-0xff] [ 1988.812225] pci :07:00.1: reg 10 32bit mmio: [0x00-0xff] [ 1988.812341] pci :07:00.2: reg 10 32bit mmio: [0x00-0xff] [ 2003.326837] cx25843.c: starting probe for adapter SMBus I801 adapter at 18e0 (0x40004) [ 2003.328060] cx25843.c: detecting cx25843 client on address 0x88 [ 2003.328090] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.328511] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.328961] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.335211] em28xx: Unknown symbol v4l_compat_translate_ioctl [ 2003.335404] em28xx: Unknown symbol v4l2_video_std_construct [ 2003.335850] em28xx: Unknown symbol v4l2_type_names [ 2003.339965] em28xx: Unknown symbol v4l_printk_ioctl [ 2003.340663] em28xx: Unknown symbol video_unregister_device [ 2003.340851] em28xx: Unknown symbol video_device_alloc [ 2003.340948] em28xx: Unknown symbol video_register_device [ 2003.342372] em28xx: Unknown symbol video_usercopy [ 2003.342470] em28xx: Unknown symbol video_device_release [ 2003.352874] em28xx_audio: Unknown symbol em28xx_i2c_call_clients [ 2003.353305] em28xx_audio: Unknown symbol snd_pcm_new [ 2003.353407] em28xx_audio: Unknown symbol snd_card_register [ 2003.353508] em28xx_audio: Unknown symbol snd_card_free [ 2003.353683] em28xx_audio: Unknown symbol snd_component_add [ 2003.353873] em28xx_audio: Unknown symbol snd_card_new [ 2003.353977] em28xx_audio: Unknown symbol snd_pcm_lib_ioctl [ 2003.354280] em28xx_audio: Unknown symbol em28xx_unregister_extension [ 2003.354465] em28xx_audio: Unknown symbol snd_pcm_set_ops [ 2003.354570] em28xx_audio: Unknown symbol snd_pcm_hw_constraint_integer [ 2003.354691] em28xx_audio: Unknown symbol em28xx_register_extension [ 2003.354910] em28xx_audio: Unknown symbol snd_pcm_period_elapsed [ 2003.357625] em28xx_aad: Unknown symbol em28xx_unregister_extension [ 2003.357753] em28xx_aad: Unknown symbol em28xx_register_extension [ 2003.358895] em28xx_dvb: Unknown symbol dvb_dmxdev_init [ 2003.359262] em28xx_dvb: Unknown symbol dvb_register_adapter [ 2003.359506] em28xx_dvb: Unknown symbol dvb_dmx_release [ 2003.359602] em28xx_dvb: Unknown symbol em28xx_unregister_extension [ 2003.359787] em28xx_dvb: Unknown symbol dvb_net_init [ 2003.359886] em28xx_dvb: Unknown symbol dvb_dmx_swfilter [ 2003.360514] em28xx_dvb: Unknown symbol dvb_dmxdev_release [ 2003.360638] em28xx_dvb: Unknown symbol dvb_frontend_detach [ 2003.360737] em28xx_dvb: Unknown symbol dvb_net_release [ 2003.360898] em28xx_dvb: Unknown symbol em28xx_register_extension [ 2003.361189] em28xx_dvb: Unknown symbol dvb_unregister_frontend [ 2003.361455] em28xx_dvb: Unknown symbol dvb_register_frontend [ 2003.361554] em28xx_dvb: Unknown symbol dvb_unregister_adapter [ 2003.361653] em28xx_dvb: Unknown symbol dvb_dmx_init [ 2003.362770] em28xx_audioep: Unknown symbol snd_pcm_new [ 2003.362872] em28xx_audioep: Unknown symbol snd_card_register [ 2003.362973] em28xx_audioep: Unknown symbol snd_card_free [ 2003.363375] em28xx_audioep: Unknown symbol snd_card_new [ 2003.363479] em28xx_audioep: Unknown symbol snd_pcm_lib_ioctl [ 2003.363659] em28xx_audioep: Unknown symbol snd_pcm_set_ops [ 2003.363843] em28xx_audioep: Unknown symbol snd_pcm_hw_constraint_integer [ 2003.364044] em28xx_audioep: Unknown symbol snd_pcm_period_elapsed [ 2038.162200] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 As you can see, there were several problems, I'll explain them a little bit further: first of all a lot of unresolved symbols which are part of ALSA itself (snd_* ones.) This is perfectly valid and true since I don't use ALSA but OSS, however, using the provided modules seems not to be working without ALSA - bummer deal... I'd appreciate any help here (other than switch to ALSA rants, of course, which are not very productive!) Secondly, there are a lot of unresolved dvb* symbol errors personally I can not explain. After this episode of failing I wanted to give LinuxTV.org's v4l-dvb tree a shot... once again had all installed v4l and dvb modules removed (module-wise out of the Kernel as well as file-wise on the harddisk of course),
Re: Pinnacle PCTV Hybrid Pro Card (310c)... once again...
* On 15.03.2009 00:41, Markus Rechberger wrote: On Sun, Mar 15, 2009 at 12:29 AM, Mihai Moldovan io...@ionic.de wrote: Hello readers, Amazon just had this card transported to me today... and of course I gave the in-kernel 2.6.28.7 drivers a shot, but it didn't work out at all, so I thought giving the repo provided in the wiki article (for reference: http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_Hybrid_Pro_Card_%28310c%29) would be a good idea. Thus, I removed every in-kernel tuner and DVB module, checked the repo out, build the new modules and had them installed. This, however, yielded following results (dmesg extract): [ 1988.812035] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 [ 1988.812102] pci :07:00.0: reg 10 32bit mmio: [0x00-0xff] [ 1988.812225] pci :07:00.1: reg 10 32bit mmio: [0x00-0xff] [ 1988.812341] pci :07:00.2: reg 10 32bit mmio: [0x00-0xff] [ 2003.326837] cx25843.c: starting probe for adapter SMBus I801 adapter at 18e0 (0x40004) [ 2003.328060] cx25843.c: detecting cx25843 client on address 0x88 [ 2003.328090] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.328511] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.328961] cx25843.c: starting probe for adapter NVIDIA i2c adapter (0x0) [ 2003.335211] em28xx: Unknown symbol v4l_compat_translate_ioctl [ 2003.335404] em28xx: Unknown symbol v4l2_video_std_construct [ 2003.335850] em28xx: Unknown symbol v4l2_type_names [ 2003.339965] em28xx: Unknown symbol v4l_printk_ioctl [ 2003.340663] em28xx: Unknown symbol video_unregister_device [ 2003.340851] em28xx: Unknown symbol video_device_alloc [ 2003.340948] em28xx: Unknown symbol video_register_device [ 2003.342372] em28xx: Unknown symbol video_usercopy [ 2003.342470] em28xx: Unknown symbol video_device_release [ 2003.352874] em28xx_audio: Unknown symbol em28xx_i2c_call_clients [ 2003.353305] em28xx_audio: Unknown symbol snd_pcm_new [ 2003.353407] em28xx_audio: Unknown symbol snd_card_register [ 2003.353508] em28xx_audio: Unknown symbol snd_card_free [ 2003.353683] em28xx_audio: Unknown symbol snd_component_add [ 2003.353873] em28xx_audio: Unknown symbol snd_card_new [ 2003.353977] em28xx_audio: Unknown symbol snd_pcm_lib_ioctl [ 2003.354280] em28xx_audio: Unknown symbol em28xx_unregister_extension [ 2003.354465] em28xx_audio: Unknown symbol snd_pcm_set_ops [ 2003.354570] em28xx_audio: Unknown symbol snd_pcm_hw_constraint_integer [ 2003.354691] em28xx_audio: Unknown symbol em28xx_register_extension [ 2003.354910] em28xx_audio: Unknown symbol snd_pcm_period_elapsed [ 2003.357625] em28xx_aad: Unknown symbol em28xx_unregister_extension [ 2003.357753] em28xx_aad: Unknown symbol em28xx_register_extension [ 2003.358895] em28xx_dvb: Unknown symbol dvb_dmxdev_init [ 2003.359262] em28xx_dvb: Unknown symbol dvb_register_adapter [ 2003.359506] em28xx_dvb: Unknown symbol dvb_dmx_release [ 2003.359602] em28xx_dvb: Unknown symbol em28xx_unregister_extension [ 2003.359787] em28xx_dvb: Unknown symbol dvb_net_init [ 2003.359886] em28xx_dvb: Unknown symbol dvb_dmx_swfilter [ 2003.360514] em28xx_dvb: Unknown symbol dvb_dmxdev_release [ 2003.360638] em28xx_dvb: Unknown symbol dvb_frontend_detach [ 2003.360737] em28xx_dvb: Unknown symbol dvb_net_release [ 2003.360898] em28xx_dvb: Unknown symbol em28xx_register_extension [ 2003.361189] em28xx_dvb: Unknown symbol dvb_unregister_frontend [ 2003.361455] em28xx_dvb: Unknown symbol dvb_register_frontend [ 2003.361554] em28xx_dvb: Unknown symbol dvb_unregister_adapter [ 2003.361653] em28xx_dvb: Unknown symbol dvb_dmx_init [ 2003.362770] em28xx_audioep: Unknown symbol snd_pcm_new [ 2003.362872] em28xx_audioep: Unknown symbol snd_card_register [ 2003.362973] em28xx_audioep: Unknown symbol snd_card_free [ 2003.363375] em28xx_audioep: Unknown symbol snd_card_new [ 2003.363479] em28xx_audioep: Unknown symbol snd_pcm_lib_ioctl [ 2003.363659] em28xx_audioep: Unknown symbol snd_pcm_set_ops [ 2003.363843] em28xx_audioep: Unknown symbol snd_pcm_hw_constraint_integer [ 2003.364044] em28xx_audioep: Unknown symbol snd_pcm_period_elapsed [ 2038.162200] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 As you can see, there were several problems, I'll explain them a little bit further: first of all a lot of unresolved symbols which are part of ALSA itself (snd_* ones.) This is perfectly valid and true since I don't use ALSA but OSS, however, using the provided modules seems not to be working without ALSA - bummer deal... I'd appreciate any help here (other than switch to ALSA rants, of course, which are not very productive!) Secondly, there are a lot of unresolved dvb* symbol errors personally I can not explain. After this episode of failing I wanted to give LinuxTV.org's v4l-dvb tree a shot... once again had all installed v4l and dvb modules removed (module-wise out of the
Re: Pinnacle PCTV Hybrid Pro Card (310c)... once again...
Hi Markus, that's cool... but which tree is the one you actually do speak about? v4l-dvb-experimental? As stated... I've already tried it without any success. :( this tree doesn't exist anymore it's just a symlink to the split out em28xx driver on mcentral.de you should try your luck with the linuxtv.org/hg/v4l-dvb repository Other than this I am out of ideas... but you could mean userspace-drivers though, is this the tree to go? The page the README file points to is outdated by the way... those things are not relevant for your device, no drivers on mcentral.de are relevant for your device. read your first dmesg log carefully and try to obtain the xc3028 firmware and put it to /lib/firmware regards, Markus When trying to compile all the stuff, I am getting this error messages: sui userspace-drivers # ./build.sh found kernel version (2.6.28.7-tuxonice-squashFS3.4-OSS4.1) make -C /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/build M=/usr/src/Pinnacle/userspace-drivers/kernel modules -Wall make[1]: Entering directory `/usr/src/linux-2.6.28.7' CC [M] /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.o /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.c: In Funktion »tuner_request_module«: /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.c:1466: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.c: In Funktion »tuner_init«: /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.c:2208: Fehler: Implizite Deklaration der Funktion »class_device_create« /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.c:2208: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.c: In Funktion »tuner_exit«: /usr/src/Pinnacle/userspace-drivers/kernel/media-stub.c:2218: Fehler: Implizite Deklaration der Funktion »class_device_destroy« make[2]: *** [/usr/src/Pinnacle/userspace-drivers/kernel/media-stub.o] Fehler 1 make[1]: *** [_module_/usr/src/Pinnacle/userspace-drivers/kernel] Fehler 2 make[1]: Leaving directory `/usr/src/linux-2.6.28.7' make: *** [all] Fehler 2 make INSTALL_MOD_PATH= INSTALL_MOD_DIR=kernel/drivers/media/userspace \ -C /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/build M=/usr/src/Pinnacle/userspace-drivers/kernel modules_install make[1]: Entering directory `/usr/src/linux-2.6.28.7' DEPMOD 2.6.28.7-tuxonice-squashFS3.4-OSS4.1 WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol em28xx_i2c_call_clients WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_pcm_new WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_card_register WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_card_free WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_component_add WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_card_new WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_pcm_lib_ioctl WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_pcm_set_ops WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_pcm_hw_constraint_integer WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audio.ko needs unknown symbol snd_pcm_period_elapsed WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_pcm_new WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_card_register WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_card_free WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_card_new WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_pcm_lib_ioctl WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_pcm_set_ops WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_pcm_hw_constraint_integer WARNING: /lib/modules/2.6.28.7-tuxonice-squashFS3.4-OSS4.1/empia/em28xx-audioep.ko needs unknown symbol snd_pcm_period_elapsed make[1]: Leaving directory `/usr/src/linux-2.6.28.7' depmod -a gcc -c media-core.c -I/lib/modules/`uname -r`/source/include gcc media-core.o tuner-qt1010.c -o tuner-qt1010 -I/lib/modules/`uname -r`/source/include -g gcc media-core.o tuner-mt2060.c -o tuner-mt2060
Re: Pinnacle PCTV Hybrid Pro Card (310c)... once again...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * On 15.03.2009 01:25, Markus Rechberger wrote: Hi Markus, that's cool... but which tree is the one you actually do speak about? v4l-dvb-experimental? As stated... I've already tried it without any success. :( this tree doesn't exist anymore it's just a symlink to the split out em28xx driver on mcentral.de you should try your luck with the linuxtv.org/hg/v4l-dvb repository Okay, thank you! Other than this I am out of ideas... but you could mean userspace-drivers though, is this the tree to go? The page the README file points to is outdated by the way... those things are not relevant for your device, no drivers on mcentral.de are relevant for your device. Interesting... thought they'd be the right drivers to get the device working due to the (possibly outdated) information on it's wiki page... read your first dmesg log carefully and try to obtain the xc3028 firmware and put it to /lib/firmwar Well, that seems to be some sort of problem. I found this site (and several others during March, 14th) http://lists-archives.org/video4linux/20835-extract-tool-for-xc3028-firmware.html which shows how to extract the firmware file in question. It doesn't seem to fit my card though... I've done it anyways though. No error messages printed by the drivers anymore, just the normal output: [16398.130540] Linux video capture interface: v2.00 [16398.176622] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded [16398.177500] cx88[0]: subsystem: 12ab:1788, board: Pinnacle Hybrid PCTV [card=60,autodetected], frontend(s): 1 [16398.177504] cx88[0]: TV tuner type 71, Radio tuner type 71 [16398.185553] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [16398.326195] tveeprom 4-0050: Huh, no eeprom present (err=-6)? [16398.326200] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [16398.326207] cx88[0]/2: cx2388x 8802 Driver Manager [16398.326221] cx88-mpeg driver manager :07:00.2: enabling device ( - 0002) [16398.326231] cx88-mpeg driver manager :07:00.2: PCI INT A - GSI 22 (level, low) - IRQ 22 [16398.326240] cx88-mpeg driver manager :07:00.2: setting latency timer to 64 [16398.326249] cx88[0]/2: found at :07:00.2, rev: 5, irq: 22, latency: 64, mmio: 0x8e00 [16398.330880] cx8800 :07:00.0: enabling device ( - 0002) [16398.330890] cx8800 :07:00.0: PCI INT A - GSI 22 (level, low) - - IRQ 22 [16398.330899] cx88[0]/0: found at :07:00.0, rev: 5, irq: 22, latency: 0, mmio: 0x8c00 [16398.330908] cx8800 :07:00.0: setting latency timer to 64 [16398.331217] cx88[0]/0: registered device video0 [v4l2] [16398.331249] cx88[0]/0: registered device vbi0 [16398.331284] cx88[0]/0: registered device radio0 [16398.353479] cx88/2: cx2388x dvb driver version 0.0.6 loaded [16398.353483] cx88/2: registering cx8802 driver, type: dvb access: shared [16398.353486] cx88[0]/2: subsystem: 12ab:1788, board: Pinnacle Hybrid PCTV [card=60] [16398.353489] cx88[0]/2: cx2388x based DVB/ATSC card [16398.353491] cx8802_alloc_frontends() allocating 1 frontend(s) [16398.362618] xc2028 4-0061: creating new instance [16398.362621] xc2028 4-0061: type set to XCeive xc2028/xc3028 tuner [16398.362624] cx88[0]/2: xc3028 attached [16398.362628] DVB: registering new adapter (cx88[0]) [16398.362632] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... Here comes the interesting part, though: radio -s is finding no stations (this is not critical for me, but indicates some misbehavior) and dvbscan does only output Unable to query frontend status (Exit code 1.) After running dvbcan, dmesg grows by following messages: [16485.369819] i2c-adapter i2c-4: firmware: requesting xc3028-v27.fw [16485.374523] xc2028 4-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [16485.374629] cx88[0]: Calling XC2028/3028 callback [16485.374632] cx88[0]: setting GPIO to radio! [16487.371046] xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id . [16487.371053] cx88[0]: Calling XC2028/3028 callback [16487.371055] cx88[0]: setting GPIO to radio! [16491.995176] xc2028 4-0061: Loading firmware for type=D2633 DTV8 (210), id . [16492.039958] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . [16492.080028] cx88[0]: Calling XC2028/3028 callback I've also been curious about analog TV (which is my premier want to get it working aim)... with no luck. tvtime-scanner scanned and scanned and scanned without finding any station. New messages after running tvtime-scanner: [16491.995176] xc2028 4-0061: Loading firmware for type=D2633 DTV8 (210), id . [16492.039958] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . [16492.080028] cx88[0]: Calling XC2028/3028 callback So... I guess nothing is working sadly... I'm really not sure
Re: Pinnacle PCTV Hybrid Pro Card (310c)... once again...
Please don't cc-flood (is that the correct way to name it?:)) your recipients ;) To answer any questions that were posed at me, I have not been using the card much, but were able to get analog picture (no sound) with it using Ubuntu 8.10 stock kernel - I'm guessing 2.6.27 at the time. I might give it a try some time, once dvb becomes more popular over here I believe. Stay tuned. Dnia 2009-03-15, nie o godzinie 02:19 +0100, Ionic pisze: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * On 15.03.2009 01:25, Markus Rechberger wrote: Hi Markus, that's cool... but which tree is the one you actually do speak about? v4l-dvb-experimental? As stated... I've already tried it without any success. :( this tree doesn't exist anymore it's just a symlink to the split out em28xx driver on mcentral.de you should try your luck with the linuxtv.org/hg/v4l-dvb repository Okay, thank you! Other than this I am out of ideas... but you could mean userspace-drivers though, is this the tree to go? The page the README file points to is outdated by the way... those things are not relevant for your device, no drivers on mcentral.de are relevant for your device. Interesting... thought they'd be the right drivers to get the device working due to the (possibly outdated) information on it's wiki page... read your first dmesg log carefully and try to obtain the xc3028 firmware and put it to /lib/firmwar Well, that seems to be some sort of problem. I found this site (and several others during March, 14th) http://lists-archives.org/video4linux/20835-extract-tool-for-xc3028-firmware.html which shows how to extract the firmware file in question. It doesn't seem to fit my card though... I've done it anyways though. No error messages printed by the drivers anymore, just the normal output: [16398.130540] Linux video capture interface: v2.00 [16398.176622] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded [16398.177500] cx88[0]: subsystem: 12ab:1788, board: Pinnacle Hybrid PCTV [card=60,autodetected], frontend(s): 1 [16398.177504] cx88[0]: TV tuner type 71, Radio tuner type 71 [16398.185553] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [16398.326195] tveeprom 4-0050: Huh, no eeprom present (err=-6)? [16398.326200] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [16398.326207] cx88[0]/2: cx2388x 8802 Driver Manager [16398.326221] cx88-mpeg driver manager :07:00.2: enabling device ( - 0002) [16398.326231] cx88-mpeg driver manager :07:00.2: PCI INT A - GSI 22 (level, low) - IRQ 22 [16398.326240] cx88-mpeg driver manager :07:00.2: setting latency timer to 64 [16398.326249] cx88[0]/2: found at :07:00.2, rev: 5, irq: 22, latency: 64, mmio: 0x8e00 [16398.330880] cx8800 :07:00.0: enabling device ( - 0002) [16398.330890] cx8800 :07:00.0: PCI INT A - GSI 22 (level, low) - - IRQ 22 [16398.330899] cx88[0]/0: found at :07:00.0, rev: 5, irq: 22, latency: 0, mmio: 0x8c00 [16398.330908] cx8800 :07:00.0: setting latency timer to 64 [16398.331217] cx88[0]/0: registered device video0 [v4l2] [16398.331249] cx88[0]/0: registered device vbi0 [16398.331284] cx88[0]/0: registered device radio0 [16398.353479] cx88/2: cx2388x dvb driver version 0.0.6 loaded [16398.353483] cx88/2: registering cx8802 driver, type: dvb access: shared [16398.353486] cx88[0]/2: subsystem: 12ab:1788, board: Pinnacle Hybrid PCTV [card=60] [16398.353489] cx88[0]/2: cx2388x based DVB/ATSC card [16398.353491] cx8802_alloc_frontends() allocating 1 frontend(s) [16398.362618] xc2028 4-0061: creating new instance [16398.362621] xc2028 4-0061: type set to XCeive xc2028/xc3028 tuner [16398.362624] cx88[0]/2: xc3028 attached [16398.362628] DVB: registering new adapter (cx88[0]) [16398.362632] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... Here comes the interesting part, though: radio -s is finding no stations (this is not critical for me, but indicates some misbehavior) and dvbscan does only output Unable to query frontend status (Exit code 1.) After running dvbcan, dmesg grows by following messages: [16485.369819] i2c-adapter i2c-4: firmware: requesting xc3028-v27.fw [16485.374523] xc2028 4-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [16485.374629] cx88[0]: Calling XC2028/3028 callback [16485.374632] cx88[0]: setting GPIO to radio! [16487.371046] xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id . [16487.371053] cx88[0]: Calling XC2028/3028 callback [16487.371055] cx88[0]: setting GPIO to radio! [16491.995176] xc2028 4-0061: Loading firmware for type=D2633 DTV8 (210), id . [16492.039958] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . [16492.080028] cx88[0]: Calling XC2028/3028 callback I've also been curious about analog TV
