Re: omap34xxcam question?
Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:39 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:25 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Hi, Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 6:01 AM To: linux-media@vger.kernel.org Cc: Aguirre, Sergio Subject: omap34xxcam question? Hi Is ok that it try only the first format and size? why does it not continue and find a matching? Actually, that was the intention, but I guess it was badly implemented. Thanks for the catch, and the contribution! Regards, Sergio @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; Is the patch good? or you are going to provide a better fix Yes. Sorry if I wasn't clear enough. Looks good to me, and I don't have a better fix on top of my head for the moment... I'm assuming you tested it in your environment, right? Ok, my enviroment is not pretty stable but for sure this is required. There is one problem: Suppose that the camera support this format: YUV and RAW10 The video4linux enumeration is done in this order. We know that if you want to use resizer and previewer we can't use the YUV (go straight to memory) but it is selected because is the first. So maybe the best thing is to find the one that is suggest in the csi configuration first. Hope that is clear. Hmm.. I see. So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile? Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :) Michael Regards, Sergio Michael If yes, then I'll take the patch in my queue for submission to Sakari's tree. Thanks for your time. Regards, Sergio Michael Michael -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DM1105: could not attach frontend 195d:1105
I bought a DVB-S card to attach to my mythtv setup. I knew it was perhaps not going to work, and I only spent $15 on it. However, based on the info the guy on eBay provided, it had a pci address of 195d:1105, which I could see some people had cards that were working. The card itself is a no-name jobby. I can see the DM1105 chip on it, I can't see any other chips with any significant pin count (lots with 3 - 8 pins, but nothing with enough to be important). There is a metal case around the connectors that might be hiding a frontend chip of some sort, but it doesn't seem to have enough connectors in and out to be doing much that is important beyond just providing connectivity to the LNB. I've got the latest kernel (2.6.33-rc4) and I've checked the code and it looks like the latest DM1105 code. When booting I get: [9.766188] dm1105 :06:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [ 10.047331] dm1105 :06:00.0: MAC 00:00:00:00:00:00 [ 12.464628] dm1105 :06:00.0: could not attach frontend [ 12.479830] dm1105 :06:00.0: PCI INT A disabled With lspci -vv I get: 06:00.0 Ethernet controller: Device 195d:1105 (rev 10) Subsystem: Device 195d:1105 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 20 Region 0: I/O ports at b000 [size=256] No DVB devices are created. I see from other people using a card with this chipset that there probably would be a tuner/frontend as well as the DM1105. I've also tried card=5 in the insmod parameters. It seems to me that the card probably has a tuner/frontend on id different from the Axess board, but I'm not sure how I'd work out what that is. Is it possible that it doesn't have any chips on it other than the DM1105? Should I take the board apart a bit to find out? Thanks, Paul -- 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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
I have bug-fix (tm6000.patch) my first problem, so that it loads the
tuner and demodulator (message). But I cannot find digital channels. It
was wrong with the tuner (xc3028) or demodulator (zl10353)? Under
windows xp it found digital channels (region Germany Berlin).
--
Stefan Ringel stefan.rin...@arcor.de
diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index 59fb505..334dea9 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -32,7 +32,7 @@
#include tm6000.h
#include tm6000-regs.h
#include tuner-xc2028.h
-#include tuner-xc5000.h
+#include xc5000.h
#define TM6000_BOARD_UNKNOWN 0
#define TM5600_BOARD_GENERIC 1
@@ -44,6 +44,10 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
#define TM6010_BOARD_HAUPPAUGE_900H 9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER 11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE 12
+
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -208,7 +212,21 @@ struct tm6000_board tm6000_boards[] = {
},
.gpio_addr_tun_reset = TM6000_GPIO_2,
},
-
+ [TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+ .name = Terratec Cinergy Hybrid XE,
+ .tuner_type = TUNER_XC2028, /* has a XC3028 */
+ .tuner_addr = 0xc2 1,
+ .demod_addr = 0x1e 1,
+ .type = TM6010,
+ .caps = {
+ .has_tuner= 1,
+ .has_dvb = 1,
+ .has_zl10353 = 1,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ },
+ .gpio_addr_tun_reset = TM6000_GPIO_2,
+ }
};
/* table of devices that work with this driver */
@@ -221,6 +239,7 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info = TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info = TM6010_BOARD_BEHOLD_WANDER },
{ USB_DEVICE(0x6000, 0xdec1), .driver_info = TM6010_BOARD_BEHOLD_VOYAGER },
+ { USB_DEVICE(0x0ccd, 0x0086), .driver_info = TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
@@ -305,12 +324,14 @@ static void tm6000_config_tuner (struct tm6000_core *dev)
ctl.mts = 1;
ctl.read_not_reliable = 1;
ctl.msleep = 10;
-
+ ctl.demod = XC3028_FE_ZARLINK456;
+
xc2028_cfg.tuner = TUNER_XC2028;
xc2028_cfg.priv = ctl;
switch(dev-model) {
case TM6010_BOARD_HAUPPAUGE_900H:
+ case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
ctl.fname = xc3028L-v36.fw;
break;
default:
@@ -402,6 +423,7 @@ static int tm6000_init_dev(struct tm6000_core *dev)
}
#endif
}
+ return 0;
err2:
v4l2_device_unregister(dev-v4l2_dev);
@@ -465,7 +487,7 @@ static int tm6000_usb_probe(struct usb_interface *interface,
}
/* Create and initialize dev struct */
- dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ dev = kzalloc(sizeof(*(dev)), GFP_KERNEL);
if (dev == NULL) {
printk (tm6000 : out of memory!\n);
usb_put_dev(usbdev);
diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
index d41af1d..74f9348 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -394,7 +394,15 @@ struct reg_init tm6010_init_tab[] = {
{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
-
+
+ /* additional from Terratec Cinergy Hybrid XE */
+ { REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
+ { REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
+ { REQ_07_SET_GET_AVREG, 0xde, 0x20 },
+ { REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
+ { REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
+ { REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
+
/* set remote wakeup key:any key wakeup */
{ REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
{ REQ_07_SET_GET_AVREG, 0xda, 0xff },
@@ -404,6 +412,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+ u8 buf[40];
if (dev-dev_type == TM6010) {
tab = tm6010_init_tab;
@@ -424,61 +433,129 @@ int tm6000_init (struct tm6000_core *dev)
}
}
- msleep(5); /* Just to be conservative */
-
- /* Check board version - maybe 10Moons specific */
- board=tm6000_get_reg16 (dev, 0x40, 0, 0);
- if (board =0) {
- printk (KERN_INFO Board version = 0x%04x\n,board);
- } else {
- printk (KERN_ERR Error %i while retrieving board version\n,board);
- }
-
+ /* hack */
if (dev-dev_type == TM6010) {
- /* Turn xceive 3028 on */
- tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01);
- msleep(11);
- }
-
- /* Reset GPIO1 and GPIO4. */
- for (i=0; i 2; i++) {
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-tuner_reset_gpio, 0x00);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
- return rc;
- }
-
- msleep(10); /* Just to be conservative */
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-tuner_reset_gpio, 0x01);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
- return rc;
- }
-
- msleep(10);
- rc=tm6000_set_reg (dev,
Fix for breakage caused by kfifo backport
Mauro, At http://linuxtv.org/hg/~awalls/cx23885-ir2 I have a change checked in to fix the v4l-dvb compilation breakage for kernels less than 2.6.33 cause by the kfifo API change. I have fixed both the cx23885 and meye driver so they compile again for older kernels. All the changes in this repo are OK to PULL as is, even though I haven't finished all the changes for the TeVii S470 IR (I was planning on a PULL request late this evening EST). You can also just cherry pick the one that fixes the kfifo problem if you want. [I was unaware of the timing of the backport, but since it was stopping me from working, I fixed it as I thought appropriate. Please feel free to contact me on any backport changes that have my fingerprints all over it, with which you would like help. I'd like to help minimize the impact to users, testers, and developers, who may not have the bleeding edge kernel - or at least the impact to me ;) ] Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] obsolete config in kernel source (FB_SOFT_CURSOR)
Hi all!
As part of the VAMOS[0] research project at the University of
Erlangen we're checking referential integrity between kernel KConfig
options and in-code Conditional blocks.
While probably not strictly a integrity violation (as
FB_SOFT_CURSOR can still be set as it is once mentioned in a KConfig
select statement this looks like a left-over of
c465e05a03209651078b95686158648fd7ed84c5
Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.
Regards
Christoph Egger
[0] http://vamos1.informatik.uni-erlangen.de/
From 5461c8d1ebc54e9f5c86233aa831cefc7c06a140 Mon Sep 17 00:00:00 2001
From: Christoph Egger sicce...@stud.informatik.uni-erlangen.de
Date: Fri, 15 Jan 2010 11:03:50 +0100
Subject: [PATCH 1/4] Clean missed bit of FB_SOFT_CURSOR
While the config Option FB_SOFT_BUFFER was removed in
c465e05a03209651078b95686158648fd7ed84c5 while moving to fbcon this
single driver has it left as a select in KConfig / #ifdef in
source. This last occurence is removed here so the option is really
gone
Signed-off-by: Christoph Egger sicce...@stud.informatik.uni-erlangen.de
---
drivers/video/Kconfig|1 -
drivers/video/sis/sis_main.c |3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 5a5c303..7fe1839 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1494,7 +1494,6 @@ config FB_VIA
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB_SOFT_CURSOR
select I2C_ALGOBIT
select I2C
help
diff --git a/drivers/video/sis/sis_main.c b/drivers/video/sis/sis_main.c
index 9d2b6bc..a531a0f 100644
--- a/drivers/video/sis/sis_main.c
+++ b/drivers/video/sis/sis_main.c
@@ -1891,9 +1891,6 @@ static struct fb_ops sisfb_ops = {
.fb_fillrect = fbcon_sis_fillrect,
.fb_copyarea = fbcon_sis_copyarea,
.fb_imageblit = cfb_imageblit,
-#ifdef CONFIG_FB_SOFT_CURSOR
- .fb_cursor = soft_cursor,
-#endif
.fb_sync = fbcon_sis_sync,
#ifdef SIS_NEW_CONFIG_COMPAT
.fb_compat_ioctl= sisfb_ioctl,
--
1.6.3.3
Re: Fix for breakage caused by kfifo backport
Hello Andy, On 01/15/2010 10:00 AM, Andy Walls wrote: Mauro, At http://linuxtv.org/hg/~awalls/cx23885-ir2 I have a change checked in to fix the v4l-dvb compilation breakage for kernels less than 2.6.33 cause by the kfifo API change. I have fixed both the cx23885 and meye driver so they compile again for older kernels. All the changes in this repo are OK to PULL as is, even though I haven't finished all the changes for the TeVii S470 IR (I was planning on a PULL request late this evening EST). You can also just cherry pick the one that fixes the kfifo problem if you want. [I was unaware of the timing of the backport, but since it was stopping me from working, I fixed it as I thought appropriate. Ouch, I was expecting to send the pull request for these changes before. I have created the exactly same patches. Anyway, good that we have these backports done. Please feel free to contact me on any backport changes that have my fingerprints all over it, with which you would like help. I'd like to help minimize the impact to users, testers, and developers, who may not have the bleeding edge kernel - or at least the impact to me ;) ] Cheers, Douglas -- 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
V4L/DVB ivtv-yuv.c: args-dst.left assigned to both nf-tru_x and nf-dst_x in ivtv_yuv_setup_frame()
vi drivers/media/video/ivtv/ivtv-yuv.c +971 and note that `args-dst.left' is assigned both to nf-tru_x and nf-dst_x, is that ok? Roel -- 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
videobuf cached user mapping
Hi, Is that possible to have user mapping cached in Memory Mapping mode ? This means buffer allocated by mmap in userspace, will have cache support, and it will be faster to work on it. But how the cache coherency can be done ? For a camera we should : - invalidate cache before dma operation (to have not old buffer data in the cache) - forbid the user to access the buffer during the dma operation (to not pollute the cache) Is it possible ? How can we achieve that ? I see sync method, that seems only called after frame capture ? Or user User Pointers is the solution ? But they should have the same problems. Is there some documentation of how user pointer are synchronised with dma ? Thanks, Matthieu -- 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: DM1105: could not attach frontend 195d:1105
On 15 января 2010 11:15:26 pau...@planar.id.au wrote: I bought a DVB-S card to attach to my mythtv setup. I knew it was perhaps not going to work, and I only spent $15 on it. However, based on the info the guy on eBay provided, it had a pci address of 195d:1105, which I could see some people had cards that were working. The card itself is a no-name jobby. I can see the DM1105 chip on it, I can't see any other chips with any significant pin count (lots with 3 - 8 pins, but nothing with enough to be important). There is a metal case around the connectors that might be hiding a frontend chip of some sort, but it doesn't seem to have enough connectors in and out to be doing much that is important beyond just providing connectivity to the LNB. I've got the latest kernel (2.6.33-rc4) and I've checked the code and it looks like the latest DM1105 code. When booting I get: [9.766188] dm1105 :06:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [ 10.047331] dm1105 :06:00.0: MAC 00:00:00:00:00:00 [ 12.464628] dm1105 :06:00.0: could not attach frontend [ 12.479830] dm1105 :06:00.0: PCI INT A disabled With lspci -vv I get: 06:00.0 Ethernet controller: Device 195d:1105 (rev 10) Subsystem: Device 195d:1105 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 20 Region 0: I/O ports at b000 [size=256] No DVB devices are created. I see from other people using a card with this chipset that there probably would be a tuner/frontend as well as the DM1105. I've also tried card=5 in the insmod parameters. It seems to me that the card probably has a tuner/frontend on id different from the Axess board, but I'm not sure how I'd work out what that is. Is it possible that it doesn't have any chips on it other than the DM1105? Should I take the board apart a bit to find out? Thanks, Paul Hi Paul, Frontend/tuner must lay under cover. Subsystem: Device 195d:1105 indicates that there is no EEPROM in card. If you send some links/pictures/photos then it would helped a lot. Is there a disk with drivers for Windows? Also I know about dm1105 based cards with tda10086 demod, those are not supported in the driver yet. BR Igor -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: V4L/DVB ivtv-yuv.c: args-dst.left assigned to both nf-tru_x and nf-dst_x in ivtv_yuv_setup_frame()
On Friday 15 January 2010, Roel Kluin wrote: vi drivers/media/video/ivtv/ivtv-yuv.c +971 and note that `args-dst.left' is assigned both to nf-tru_x and nf-dst_x, is that ok? It's fine. dst_x is used to set a hardware register and may be changed in ivtv_yuv_window_setup() tru_x is never altered is used in a special condition where the original unaltered value is required. -- Ian -- 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 - v4 1/4] V4L - vpfe_capture-remove clock and platform code
Mauro,
I know you are busy, but this patch is sitting too long for merge
and require your service. Could you at least respond to my email with
your plan so that I can work on the next patch set for your merge.
Thanks and regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Karicheri, Muralidharan
Sent: Thursday, January 14, 2010 4:24 PM
To: mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; mche...@infradead.org;
linux-media@vger.kernel.org
Subject: RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Mauro,
Could you add patches 1-3 to linux-next ASAP?
See the response from Kevin for the arch part.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl;
mche...@infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++--
-
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct
ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev =
Re: [PATCH] obsolete config in kernel source (FB_SOFT_CURSOR)
On Fri, 15 Jan 2010 13:27:56 +0100 Christoph Egger wrote: Hi all! As part of the VAMOS[0] research project at the University of Erlangen we're checking referential integrity between kernel KConfig options and in-code Conditional blocks. While probably not strictly a integrity violation (as FB_SOFT_CURSOR can still be set as it is once mentioned in a KConfig select statement this looks like a left-over of c465e05a03209651078b95686158648fd7ed84c5 Please keep me informed of this patch getting confirmed / merged so we can keep track of it. Regards Christoph Egger [0] http://vamos1.informatik.uni-erlangen.de/ Hi, This one should have gone to the linux-fb...@vger.kernel.org mailing list instead of linux-media. http://vger.kernel.org/vger-lists.html#linux-fbdev --- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jan 15 19:00:03 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13972:725c07a70453 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: ERRORS linux-2.6.31-i686: ERRORS linux-2.6.32-i686: ERRORS linux-2.6.33-rc2-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: OK linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.32-powerpc64: ERRORS linux-2.6.33-rc2-powerpc64: OK linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: ERRORS linux-2.6.27-x86_64: ERRORS linux-2.6.28-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30-x86_64: ERRORS linux-2.6.31-x86_64: ERRORS linux-2.6.32-x86_64: ERRORS linux-2.6.33-rc2-x86_64: OK spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for breakage caused by kfifo backport
Andy Walls wrote:
Mauro,
At
http://linuxtv.org/hg/~awalls/cx23885-ir2
I have a change checked in to fix the v4l-dvb compilation breakage for
kernels less than 2.6.33 cause by the kfifo API change. I have fixed
both the cx23885 and meye driver so they compile again for older
kernels.
As patches that do backports aren't applied upstream, they can't change any
line at the upstream code. However, your patch is changing two comments:
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ kfifo_reset(state-rx_kfifo);
+#else
unsigned long flags;
spin_lock_irqsave(state-rx_kfifo_lock, flags);
kfifo_reset(state-rx_kfifo);
- /* reset tx_fifo too if there is one... */
spin_unlock_irqrestore(state-rx_kfifo_lock, flags);
+#endif
@@ -977,6 +1000,7 @@
o-interrupt_enable = p-interrupt_enable;
o-enable = p-enable;
if (p-enable) {
+ /* reset tx_fifo here */
if (p-interrupt_enable)
irqenable_tx(dev, IRQEN_TSE);
control_tx_enable(dev, p-enable);
@@ -1256,8 +1280,15 @@
This means that upstream and your -hg will be different. Please, don't do that.
If you want to touch on comments or at the upstream code, please send a separate
patch.
All the changes in this repo are OK to PULL as is, even though I haven't
finished all the changes for the TeVii S470 IR (I was planning on a
PULL request late this evening EST). You can also just cherry pick the
one that fixes the kfifo problem if you want.
Yet, the series contains that issue I've already pointed:
+struct cx23885_ir_input {
...
+ charname[48];
+ charphys[48];
[I was unaware of the timing of the backport, but since it was stopping
me from working, I fixed it as I thought appropriate. Please feel free
to contact me on any backport changes that have my fingerprints all over
it, with which you would like help. I'd like to help minimize the
impact to users, testers, and developers, who may not have the bleeding
edge kernel - or at least the impact to me ;) ]
I do the backports when I'm about to prepare patches to submit upstream,
generally
after doing a large patch merge.
That's said, maintainng both upstream and the backports are consuming a lot
of my time. I'll probably pass the task of keeping the -hg tree with the
backports to somebody else receiving and applying patches directly on my
-git tree.
Douglas already offered to do it, so I'll likely pass him the task to maintain
the -hg tree soon. Then, all patches there will be simply a backport of what
we'll have on -git.
Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael Krufky wrote: The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Ok. Applied, thanks! Sorry about that. I typically cut/paste the link from my browser (and we support both http and https for the HG repo). I will be sure that future PULL requests are http only. No problem. Also, I haven't had a chance to rebase this tree against the tip yet, as I burned too much time over the weekend tracking down the regression you introduced into the with the ir-sysfs rework. Did that one line patch get merged yet? It's pretty embarrassing to have a situation for nearly a month where the mainline v4l-dvb causes an OOPS just because they happen to have IR support. In my case, I couldn't even get my PC to boot until I pulled the card from the machine. Yes, it were applied already. I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. What you call trunk, it not, really a trunk, but a tree where all patches got merged. I've been pointing it several times, but people doesn't seem to listen: that tree is were we'll expect problems to happen, since it is just an alpha staging before submitting things to linux-next, where all patches got merged. The bad thing is that people use it as if they were stable, when it weren't meant to be stable at all. That's why I decided to deprecate it. On the next few days, I intend to stop adding patches at -hg tree, passing its maintainance to another person. Douglas already offered to do it for us. The idea is that I'll apply patches directly into my git trees. And then, the hg maintainer will backport the patches into -hg. This also means that patch backports will need to be sent in separate, as those patches won't fit into -git. I'm finishing the details and I'll post an official announce about that soon. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. What you call trunk, it not, really a trunk, but a tree where all patches got merged. I've been pointing it several times, but people doesn't seem to listen: that tree is were we'll expect problems to happen, since it is just an alpha staging before submitting things to linux-next, where all patches got merged. The bad thing is that people use it as if they were stable, when it weren't meant to be stable at all. This is your *opinion* that you are stating. I think many (if not most) would disagree with you, in that the v4l-dvb tree should not be treated as alpha quality. It should be generally stable, and things should not be merged into it until they are of releasable quality. Every other developer operates this way *except you*. Every other developer does his work in a separate tree, and that tree is merged once the code is stable. You are the only one who is directly checking things into the trunk that are alpha quality. Many people rely on installing the v4l-dvb tree as a path to get new device support without having to wait for a full kernel to be released and for their distribution to incorporate that kernel. Your failure to work on a branch until code is stable like every other developer contributing to this project is damaging the project's reputation. As a project, we should be embarrassed when our trunk doesn't compile on every kernel version except one. And we should be embarrassed when for nearly a month it is in a state where every board that has IR support causes an OOPS on insertion. That's why I decided to deprecate it. On the next few days, I intend to stop adding patches at -hg tree, passing its maintainance to another person. Douglas already offered to do it for us. The idea is that I'll apply patches directly into my git trees. And then, the hg maintainer will backport the patches into -hg. This also means that patch backports will need to be sent in separate, as those patches won't fit into -git. I'm finishing the details and I'll post an official announce about that soon. Rather than making any announcement, I would strongly encourage you to consider actually soliciting the feedback on your proposed approach from all of the developers who are actually contributing the code to the project. There are many developers who have very strong feelings on how this project should operate, and would likely take considerable exception to any unilateral decision being thrust upon them that has serious implications to how developers will be expected to work in this project. Let's not forget that this is a community of volunteer developers working towards a common cause, and not a dictatorship. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for breakage caused by kfifo backport
On Fri, 2010-01-15 at 17:47 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
Mauro,
At
http://linuxtv.org/hg/~awalls/cx23885-ir2
I have a change checked in to fix the v4l-dvb compilation breakage for
kernels less than 2.6.33 cause by the kfifo API change. I have fixed
both the cx23885 and meye driver so they compile again for older
kernels.
As patches that do backports aren't applied upstream, they can't change any
line at the upstream code. However, your patch is changing two comments:
This means that upstream and your -hg will be different. Please, don't do
that.
If you want to touch on comments or at the upstream code, please send a
separate
patch.
Ooops. OK, I didn't consider that. Thanks. I guess Douglas' change
will be the fix then.
All the changes in this repo are OK to PULL as is, even though I haven't
finished all the changes for the TeVii S470 IR (I was planning on a
PULL request late this evening EST). You can also just cherry pick the
one that fixes the kfifo problem if you want.
Yet, the series contains that issue I've already pointed:
+struct cx23885_ir_input {
...
+ charname[48];
+ charphys[48];
Mauro Carvalho Chehab wrote in another thread:
Why are you creating a name[] and phys[] chars here? It should be using
the names already
defined at struct input_dev.
-ENOMEM
From linux/include/linux/input.h:
struct input_dev {
const char *name;
const char *phys;
[...]
My previous full response is here in case it got lost:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14745
Please advise if this is still an issue, or if there is some other
storage that you were thinking about.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Order of dvb devices
Devin Heitmueller wrote: On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote: yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? The driver does not 'search' for a card. The driver registers the ids of all supported cards with the pci subsystem of the kernel. When the pci subsystem detects a new card, it calls the 'probe' routine of the driver (for example saa7146_init_one for saa7146-based cards). So the ordering is determined by the pci subsystem. I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: Order of dvb devices
On Fri, Jan 15, 2010 at 6:00 PM, Oliver Endriss o.endr...@gmx.de wrote: I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. I suppose it's possible that udev does not process the events in the order in which they are received. Admittedly I have not done any real analysis as to how that part of the kernel works. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Order of dvb devices
On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss o.endr...@gmx.de wrote: Devin Heitmueller wrote: On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote: yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? The driver does not 'search' for a card. The driver registers the ids of all supported cards with the pci subsystem of the kernel. When the pci subsystem detects a new card, it calls the 'probe' routine of the driver (for example saa7146_init_one for saa7146-based cards). So the ordering is determined by the pci subsystem. I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. True, the ordering is not exactly the same everytime. One will need to provide PCI Bus related info also to a practical udev configuration to get things sorted out in a sane way, rather than anything else. Regards, Manu -- 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.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Am Freitag, den 15.01.2010, 17:22 -0500 schrieb Devin Heitmueller: On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. What you call trunk, it not, really a trunk, but a tree where all patches got merged. I've been pointing it several times, but people doesn't seem to listen: that tree is were we'll expect problems to happen, since it is just an alpha staging before submitting things to linux-next, where all patches got merged. The bad thing is that people use it as if they were stable, when it weren't meant to be stable at all. This is your *opinion* that you are stating. I think many (if not most) would disagree with you, in that the v4l-dvb tree should not be treated as alpha quality. It should be generally stable, and things should not be merged into it until they are of releasable quality. Every other developer operates this way *except you*. Every other developer does his work in a separate tree, and that tree is merged once the code is stable. You are the only one who is directly checking things into the trunk that are alpha quality. Many people rely on installing the v4l-dvb tree as a path to get new device support without having to wait for a full kernel to be released and for their distribution to incorporate that kernel. Your failure to work on a branch until code is stable like every other developer contributing to this project is damaging the project's reputation. As a project, we should be embarrassed when our trunk doesn't compile on every kernel version except one. And we should be embarrassed when for nearly a month it is in a state where every board that has IR support causes an OOPS on insertion. That's why I decided to deprecate it. On the next few days, I intend to stop adding patches at -hg tree, passing its maintainance to another person. Douglas already offered to do it for us. The idea is that I'll apply patches directly into my git trees. And then, the hg maintainer will backport the patches into -hg. This also means that patch backports will need to be sent in separate, as those patches won't fit into -git. I'm finishing the details and I'll post an official announce about that soon. Rather than making any announcement, I would strongly encourage you to consider actually soliciting the feedback on your proposed approach from all of the developers who are actually contributing the code to the project. There are many developers who have very strong feelings on how this project should operate, and would likely take considerable exception to any unilateral decision being thrust upon them that has serious implications to how developers will be expected to work in this project. Let's not forget that this is a community of volunteer developers working towards a common cause, and not a dictatorship. Devin Oh my. Sometimes it is good to allow breakages for a while. At least after such, you know who really is or can still be around. Nice to see you there. But I also still wait for some Pinnacle LNA explanations ... Cheers, Hermann -- 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: DM1105: could not attach frontend 195d:1105
On 15 января 2010 11:15:26 pau...@planar.id.au wrote: I bought a DVB-S card to attach to my mythtv setup. I knew it was perhaps not going to work, and I only spent $15 on it. However, based on the info the guy on eBay provided, it had a pci address of 195d:1105, which I could see some people had cards that were working. The card itself is a no-name jobby. I can see the DM1105 chip on it, I can't see any other chips with any significant pin count (lots with 3 - 8 pins, but nothing with enough to be important). There is a metal case around the connectors that might be hiding a frontend chip of some sort, but it doesn't seem to have enough connectors in and out to be doing much that is important beyond just providing connectivity to the LNB. Igor wrote: Hi Paul, Frontend/tuner must lay under cover. Subsystem: Device 195d:1105 indicates that there is no EEPROM in card. If you send some links/pictures/photos then it would helped a lot. Is there a disk with drivers for Windows? Also I know about dm1105 based cards with tda10086 demod, those are not supported in the driver yet. BR Igor Igor, Photos: 1. Front of card. You can see the DM1105 in the foreground. There are no other significant looking chips on the card. http://planar.id.au/Photos/img_1964.jpg 2. Back of card - as you can see, there aren't a lot of places where a lot of pins are connecting - mainly the DM1105 itself http://planar.id.au/Photos/img_1965.jpg 3. With the top metal plate removed, and with the other end of the card in better focus. http://planar.id.au/Photos/img_1966.jpg Is it likely that there is a tuner under the card labelled ERIT? To take it off I have to unsolder some stuff - I can do that, but I reckon it's only 50% chance the card will work again when I put it back together - my soldering isn't so good. Thanks heaps for the assistance. Paul -- 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: Order of dvb devices
Am Samstag, den 16.01.2010, 00:00 +0100 schrieb Oliver Endriss: Devin Heitmueller wrote: On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote: yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? The driver does not 'search' for a card. The driver registers the ids of all supported cards with the pci subsystem of the kernel. When the pci subsystem detects a new card, it calls the 'probe' routine of the driver (for example saa7146_init_one for saa7146-based cards). So the ordering is determined by the pci subsystem. I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. CU Oliver Agreed. Hermann -- 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.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: Rather than making any announcement, I would strongly encourage you to consider actually soliciting the feedback on your proposed approach from all of the developers who are actually contributing the code to the project. The point here is as simple as I don't have enough time to keep maintaining both -hg and -git trees anymore. So, I'll focus on handling patches at -git, passing the task to maintain the -hg building system to someone else. I don't mind if some or all developers keep using the -hg building system to develop their patches. For patches that come to me via -hg, I'll simply run my scripts that convert an -hg patch into a -git patch, so the patches that will be developed with the build system can be sent to me directly (even pull requests). The only difference is that I won't apply them anymore at -hg, nor I'll apply backport there. So, your demand to not touch on what you call trunk will be satisfied: a separate process will backport the patches from -git and apply them at the master (trunk) -hg tree. In order to avoid troubles, the only rule here is that a patch should be added first on -git, before going to the master -hg. A bonus for the new process is that the several developers that already asked to use git trees can send -git pull requests also. Of course, suggestions to improve the process are always welcome. 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
Avermedia A317
Wow! I see I need a flame retardant suit here after the last few emails from the list... but to the point: I have an HP HDX 18t with a PCI-E TV Card. Looks to be an Avermedia A317 based on the Windows .inf file and the PCI vendor/product and subsystem vendor/product ids. I've started to kick around the saa716x_hybrid.c file to support the card. I can sort-of see how to add support in saa716x_hybrid.c, but I'm not sure as to what is needed. 1) Looks like I need a separate MAKE_ENTRY for the combination of 7160 and 1055 product ids. 2) Looks like I need a separate config structure. However, I'm not sure of the I2C addresses - do all 7160 cards have things at the same I2C addresses? 3) Windows oem9.inf file suggests this card has a TDA18271 thingy - I assume this is the tuner chip. 4) I see the tda18271_attach routine - and I see that it can be called via dvb_attach, but I don't know where to get the frontend structure thingy. Details: (apologies if word wrap is messed up...) 05:00.0 0480: 1131:7160 (rev 03) Subsystem: 1461:1055 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at da00 (64-bit, non-prefetchable) [size=1M] Capabilities: access denied Pointers and/or hints are appreciated. Thanks, Chuck McCrobie -- 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: DM1105: could not attach frontend 195d:1105
On 16 января 2010 01:14:49 pau...@planar.id.au wrote: On 15 января 2010 11:15:26 pau...@planar.id.au wrote: I bought a DVB-S card to attach to my mythtv setup. I knew it was perhaps not going to work, and I only spent $15 on it. However, based on the info the guy on eBay provided, it had a pci address of 195d:1105, which I could see some people had cards that were working. The card itself is a no-name jobby. I can see the DM1105 chip on it, I can't see any other chips with any significant pin count (lots with 3 - 8 pins, but nothing with enough to be important). There is a metal case around the connectors that might be hiding a frontend chip of some sort, but it doesn't seem to have enough connectors in and out to be doing much that is important beyond just providing connectivity to the LNB. Igor wrote: Hi Paul, Frontend/tuner must lay under cover. Subsystem: Device 195d:1105 indicates that there is no EEPROM in card. If you send some links/pictures/photos then it would helped a lot. Is there a disk with drivers for Windows? Also I know about dm1105 based cards with tda10086 demod, those are not supported in the driver yet. BR Igor Igor, Photos: 1. Front of card. You can see the DM1105 in the foreground. There are no other significant looking chips on the card. http://planar.id.au/Photos/img_1964.jpg 2. Back of card - as you can see, there aren't a lot of places where a lot of pins are connecting - mainly the DM1105 itself http://planar.id.au/Photos/img_1965.jpg 3. With the top metal plate removed, and with the other end of the card in better focus. http://planar.id.au/Photos/img_1966.jpg Is it likely that there is a tuner under the card labelled ERIT? To take it off I have to unsolder some stuff - I can do that, but I reckon it's only 50% chance the card will work again when I put it back together - my soldering isn't so good. No need to unsolder. I see a Serit can tuner. There is a sticked paper with a label on right side of the tuner. It must contain something like sp2636lhb or sp2633chb. Please provide me text of label. Thanks heaps for the assistance. Paul -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: Avermedia A317
Am Freitag, den 15.01.2010, 15:28 -0800 schrieb Chuck McCrobie: Wow! I see I need a flame retardant suit here after the last few emails from the list... but to the point: Maybe some fish is around ;) -- 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: DM1105: could not attach frontend 195d:1105
On 16 января 2010 01:14:49 pau...@planar.id.au wrote: On 15 января 2010 11:15:26 pau...@planar.id.au wrote: I bought a DVB-S card to attach to my mythtv setup. I knew it was perhaps not going to work, and I only spent $15 on it. However, based on the info the guy on eBay provided, it had a pci address of 195d:1105, which I could see some people had cards that were working. The card itself is a no-name jobby. I can see the DM1105 chip on it, I can't see any other chips with any significant pin count (lots with 3 - 8 pins, but nothing with enough to be important). There is a metal case around the connectors that might be hiding a frontend chip of some sort, but it doesn't seem to have enough connectors in and out to be doing much that is important beyond just providing connectivity to the LNB. Igor wrote: Hi Paul, Frontend/tuner must lay under cover. Subsystem: Device 195d:1105 indicates that there is no EEPROM in card. If you send some links/pictures/photos then it would helped a lot. Is there a disk with drivers for Windows? Also I know about dm1105 based cards with tda10086 demod, those are not supported in the driver yet. BR Igor Igor, Photos: 1. Front of card. You can see the DM1105 in the foreground. There are no other significant looking chips on the card. http://planar.id.au/Photos/img_1964.jpg 2. Back of card - as you can see, there aren't a lot of places where a lot of pins are connecting - mainly the DM1105 itself http://planar.id.au/Photos/img_1965.jpg 3. With the top metal plate removed, and with the other end of the card in better focus. http://planar.id.au/Photos/img_1966.jpg Is it likely that there is a tuner under the card labelled ERIT? To take it off I have to unsolder some stuff - I can do that, but I reckon it's only 50% chance the card will work again when I put it back together - my soldering isn't so good. Thanks heaps for the assistance. Paul Example of decipher :) SP2636SVb Company Name Model Number Size Input Option Demodulator Chip Chip Solution Chassis Type Remark Serit Platform 1: DVB-S 2: DVB-S2 0 : 10cc 4 : 14cc 5 : 16cc 6 : 16cc 0 : Without Loop Thru 1 : 2 : 3 : Loop Thru 0 : Half NIM 1 : WJCE6313 2 : STV0288 3 : CX24116 4 : Si2109 5 : CX24123 6 : STV0903 C : Conaxent L : Silabs M : Montage N : Half NIM S : ST Micro. Z : Intel V : Vertical H : Horizontal b : Pb Fre -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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
s2-liplianin, mantis: kobject_add_internal failed for irrcv with -EEXIST, don't try to register things with the same name in the same directory.
Using kernel 2.6.30.10-105.fc11.x86_64, sasc-ng-0.0.2-77.x86_64 and the mantis driver from http://mercurial.intuxication.org/hg/s2-liplianin, I get the following when I boot my machine (TerraTec Cinergy C HD DVB-C, VP-2040 PCI DVB-C: sysfs: cannot create duplicate filename '/devices/virtual/irrcv' Relevant parts of dmesg below. Otherwise the driver seems to work. Version of the mantis driver: $ hg log|head changeset: 14125:cc01851735c3 tag: tip parent: 14061:cc46bddbd1c8 parent: 14124:d490d84a64ac user:Igor M. Liplianin liplia...@me.by date:Wed Jan 13 17:25:36 2010 +0200 summary: merge http://linuxtv.org/hg/v4l-dvb I'd be happy to test stuff in order to solve this, please let me know (CC me directly) Thanks, MartinG Relevant parts of dmesg: eth0: no IPv6 routers present mantis_core_exit (0): DMA engine stopping mantis_dma_exit (0): DMA=0xcf06 cpu=0x8800cf06 size=65536 mantis_dma_exit (0): RISC=0xcf028000 cpu=0x8800cf028000 size=1000 mantis_hif_exit (0): Adapter(0) Exiting Mantis Host Interface mantis_ca_exit (0): Unregistering EN50221 device mantis_pci_remove (0): Removing --Mantis irq: 16, latency: 64 memory: 0xfdfff000, mmio: 0xc200111fc000 Mantis :04:00.0: PCI INT A disabled Mantis :04:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 irq: 16, latency: 64 memory: 0xfdfff000, mmio: 0xc20023da2000 found a VP-2040 PCI DVB-C device on (04:00.0), Mantis Rev 1 [153b:1178], irq: 16, latency: 64 memory: 0xfdfff000, mmio: 0xc20023da2000 MAC Address=[00:08:ca:1d:bd:a6] mantis_alloc_buffers (0): DMA=0xcf06 cpu=0x8800cf06 size=65536 mantis_alloc_buffers (0): RISC=0xcf033000 cpu=0x8800cf033000 size=1000 DVB: registering new adapter (Mantis dvb adapter) mantis_frontend_init (0): Probing for CU1216 (DVB-C) TDA10023: i2c-addr = 0x0c, id = 0x7d mantis_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... mantis_ca_init (0): Registering EN50221 device mantis_ca_init (0): Registered EN50221 device mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input9 [ cut here ] WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0xd9/0xf3() (Not tainted) Hardware name: P5E-VM HDMI sysfs: cannot create duplicate filename '/devices/virtual/irrcv' Modules linked in: mantis(+) lnbp21 mb86a16 ir_common stb6100 tda10021 tda10023 stb0899 stv0299 dvb_core ir_core nfsd nfs_acl auth_rpcgss exportfs sco bridge stp llc bnep l2cap bluetooth lockd sunrpc autofs4 w83627ehf hwmon_vid coretemp ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table jfs dm_multipath lirc_serial uinput snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device firewire_ohci snd_pcm snd_timer firewire_core snd soundcore lirc_imon lirc_dev crc_itu_t snd_page_alloc atl1 pata_jmicron i2c_i801 pcspkr mii iTCO_wdt asus_atk0110 iTCO_vendor_support serio_raw hwmon ata_generic pata_acpi i915 drm i2c_algo_bit video output i2c_core [last unloaded: ir_core] Pid: 2693, comm: work_for_cpu Not tainted 2.6.30.10-105.fc11.x86_64 #1 Call Trace: [81049505] warn_slowpath_common+0x84/0x9c [81049574] warn_slowpath_fmt+0x41/0x43 [8113564b] sysfs_add_one+0xd9/0xf3 [811356c2] create_dir+0x5d/0x8d [8113572f] sysfs_create_dir+0x3d/0x50 [811c94f6] kobject_add_internal+0x116/0x1f3 [811c96a9] kobject_add_varg+0x41/0x50 [811c9773] kobject_add+0x64/0x66 [811c8ffc] ? kobject_init+0x43/0x83 [8126f4f5] get_device_parent+0x11e/0x14a [81270430] device_add+0x100/0x599 [811d0aef] ? kvasprintf+0x5e/0x6e [812708e7] device_register+0x1e/0x23 [812709ab] device_create_vargs+0xbf/0xf0 [81270a0d] device_create+0x31/0x33 [a040182e] ir_register_class+0x62/0xc5 [ir_core] [a04012f6] ir_input_register+0x1e8/0x23d [ir_core] [a045ac69] mantis_rc_init+0x173/0x1c8 [mantis] [a045b2d9] mantis_core_init+0x2f8/0x35d [mantis] [a045b61c] mantis_pci_probe+0x2b9/0x3d4 [mantis] [813d994c] ? schedule+0xe/0x22 [811ddbf1] local_pci_probe+0x17/0x1b [81059d2c] do_work_for_cpu+0x18/0x2a [81059d14] ? do_work_for_cpu+0x0/0x2a [8105d32c] kthread+0x5a/0x85 [81011d0a] child_rip+0xa/0x20 [8105d2d2] ? kthread+0x0/0x85 [81011d00] ? child_rip+0x0/0x20 ---[ end trace 00809ea120621562 ]--- kobject_add_internal failed for irrcv with -EEXIST, don't try to register things with the same name in the same directory. Pid: 2693, comm: work_for_cpu Tainted: GW 2.6.30.10-105.fc11.x86_64 #1 Call Trace: [811c9587]
Re: How to use saa7134 gpio via gpio-sysfs?
Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: Hi! Am Montag, den 11.01.2010, 11:59 -0700 schrieb Gordon Smith: I need to bit twiddle saa7134 gpio pins from userspace. To use gpio-sysfs, I need a GPIO number to export each pin, but I do not know how to find such a number. Card is RTD Embedded Technologies VFG7350 [card=72,autodetected]. GPIO uses pcf8574 chip. Kernel is 2.6.30. gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. From dmesg (gpiotracking=1) saa7133[0]: board init: gpio is 1 saa7133[0]: gpio: mode=0x000 in=0x4011000 out=0x000 [pre-init] saa7133[1]: board init: gpio is 1 saa7133[1]: gpio: mode=0x000 in=0x4010f00 out=0x000 [pre-init] How may I find each GPIO number for this board? Thanks in advance for any help. There are 28 (0-27) gpio pins on each saa713x chip. Documentation about possible use cases is publicly available via nxp.com. You can do what ever you want with them, but to export them to userland seems to be a very bad idea to me. Likely soon some advanced hackers will damage ;) all kind of hardware around and others will claim it as being a GNU/Linux problem within the same time such stuff appears, and of course it will. In fact these days, only one to three users are involved hacking on a board. It is much cheaper for all involved to give the serial number of those than to imagine every day, what all could happen. For all others not yet active, avoiding any worst case through contributing is the way to go. For the rest, we likely should have some fund, for worst cases, payed by themselves. Cheers, Hermann Hi Trent, thought there would be straight PROs too, but no reply so far. If you ever want, could you elaborate a little, what for userspace gpios can be useful at all and why people eventually also can run into problems with such pins, since they are somehow also under control of manufacturers. Means they do use them all different within _some_ rules. Given all the different use cases of gpio pins, for example on the saa7134 driver, which ones should we eventually export to gpio-sysfs to try to understand that approach better? Do we have such pins at all? Cheers, Hermann -- 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
How can I add IR remote to this new device (DIKOM DK300)?
Hi to all,
I'm trying to use my Dikom DK300, my old notebook and an external
monitor to create a media centre (I'm mostly interested in TV and TV
recording).
The problem is that, even if I have managed to have the device working
with the following patch, I can't still use the IR remote control
shipped with it.
Can you give me some suggestion in order to have also the remote
controller working? Otherwise is it easier to buy another remote with a
dedicated receiver?
Moreover, since the digital demodulator remains activated when the tuner
is switched from digital to analogue mode or when kaffeine (which
actually I'm using to see digital tv) is closed, I wonder if someone can
explain me how to verify the gpio settings using the usbsnoop (which
I've done some times ago under win XP) to solve the issue.
If it is not possible, is there any way to deactivate the usb port and
reactivate it when the device is in needed?
Meantime this it the patch that fixes the Dikom DK300 hybrid USB card
which is recognized as a Kworld VS-DVB-T 323UR (card=54).
The patch adds digital TV and solves analogue TV audio bad quality issue.
Moreover it removes the composite and s-video analogue inputs which are
not present on the board.
Not working: remote controller
Signed-off-by: Andrea Amorosi andrea.amoros...@gmail.com
diff -r 59e746a1c5d1 linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Wed Dec 30 09:10:33
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Tue Jan 12 21:58:30
2010 +0100
@@ -1447,19 +1447,25 @@
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
.decoder = EM28XX_TVP5150,
+ .mts_firmware = 1,
+ .has_dvb = 1,
+ .dvb_gpio = kworld_330u_digital,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
.amux = EM28XX_AMUX_VIDEO,
- }, {
+ .gpio = default_analog,
+ },/* {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = TVP5150_COMPOSITE1,
.amux = EM28XX_AMUX_LINE_IN,
+ .gpio = kworld_330u_analog,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = TVP5150_SVIDEO,
.amux = EM28XX_AMUX_LINE_IN,
- } },
+ .gpio = kworld_330u_analog,
+ } */},
},
[EM2882_BOARD_TERRATEC_HYBRID_XS] = {
.name = Terratec Hybrid XS (em2882),
@@ -2168,6 +2174,7 @@
ctl-demod = XC3028_FE_DEFAULT;
break;
case EM2883_BOARD_KWORLD_HYBRID_330U:
+ case EM2882_BOARD_KWORLD_VS_DVBT:
ctl-demod = XC3028_FE_CHINA;
ctl-fname = XC2028_DEFAULT_FIRMWARE;
break;
diff -r 59e746a1c5d1 linux/drivers/media/video/em28xx/em28xx-dvb.c
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c Wed Dec 30 09:10:33
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c Tue Jan 12 21:58:30
2010 +0100
@@ -504,6 +504,7 @@
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
+ case EM2882_BOARD_KWORLD_VS_DVBT:
dvb-frontend = dvb_attach(zl10353_attach,
em28xx_zl10353_xc3028_no_i2c_gate,
dev-i2c_adap);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
On Sat, 16 Jan 2010, hermann pitton wrote: Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. You have to explictly export the GPIO lines to get them to appear. Either in the kernel with gpio_export() or from sysfs. You also can't export GPIOs that something in the kernel is using. My original design didn't have this restriction. I felt there were valid debug and development reasons for doing so, having used them myself for debug and development of embedded systems, but David Brownell felt otherwise. I didn't even have the concept of export originally, all the gpios would show up. After all, all your PCI and USB devices, I2C chips or busses, etc. show up in sysfs. Nothing else does this must be exported to show up business. You can memory map the saa7133 PCI address space and modify the gpios, and anything else, with direct register access from userspace, and that's just fine. But being able to observe and modify the gpios with a gpio-only interface is just way too dangerous. Doesn't make sense. But I'm digressing. This sysfs interface only works with the gpio using the generic gpio layer. This was designed for generic gpios on SoCs that would be providing by some kind of platform driver or I2C gpio extenders. The gpios get and used by various other drivers. Like say write protects on memory cards, or system LEDs. I wrote a JTAG driver that used it. The point of the gpio layer is to interface drivers the provide gpios with other, different, drivers that use the gpio. It was introduced in the mid 2.6.20s IIRC. The saa713x driver predates the generic gpio layer by years and years, so it doesn't use it. It also doesn't need to use it. Since the gpios are managed by the saa713x driver, and they also used by the saa713x driver, there is no need to interface two different drivers together. There are tons of drivers for devices that have gpios like this, but they don't use the gpio layer. But with gpio access via sysfs for generic gpios, there is something useful about having the saa713x driver support generic gpios. IIRC, somehow wrote a gpio only bt848 driver that didn't do anything but export gpios. In order to do this, you'll have to write code for the saa7134 driver to have it register with the gpio layer. I think you could still have the saa7134 driver itself use its gpio directly. That would avoid a performance penalty in the driver. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DM1105: could not attach frontend 195d:1105
Paul wrote: Is it likely that there is a tuner under the card labelled ERIT? To take it off I have to unsolder some stuff - I can do that, but I reckon it's only 50% chance the card will work again when I put it back together - my soldering isn't so good. Igor wrote: No need to unsolder. I see a Serit can tuner. There is a sticked paper with a label on right side of the tuner. It must contain something like sp2636lhb or sp2633chb. Please provide me text of label. Ah, I see. The whole thing is a tuner, and the label that I thought said ERIT actually says SERIT. Yes, it does have a label on it, I should have given you that up front. I had searched for it on the internet and decided that it didn't mean anything. Thanks so much for your help. The label reads SP1514LHb D0943B If I follow your decipher instructions that means: 1: DVB-S 5: 16cc 1: Unsure, but it has an LNB in and an LNB out, so I guess it does have loop through? 4: Si2109 L: Si labs H: Horizontal b: Lead free So I'm looking for some code to enable an Si2109 tuner? Thanks again, Paul -- 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: DM1105: could not attach frontend 195d:1105
On Sat, 16 Jan 2010 02:49:52 +, pau...@planar.id.au wrote: Ah, I see. The whole thing is a tuner, and the label that I thought said ERIT actually says SERIT. Yes, it does have a label on it, I should have given you that up front. I had searched for it on the internet and decided that it didn't mean anything. Thanks so much for your help. The label reads SP1514LHb D0943B If I follow your decipher instructions that means: 1: DVB-S 5: 16cc 1: Unsure, but it has an LNB in and an LNB out, so I guess it does have loop through? 4: Si2109 L: Si labs H: Horizontal b: Lead free So I'm looking for some code to enable an Si2109 tuner? Thanks again, Paul I'm looking through the dm1105 code that I have in 2.6.33-rc4. I have a block that reads: dm1105dvb-fe = dvb_attach( si21xx_attach, serit_config, dm1105dvb-i2c_adap); if (dm1105dvb-fe) dm1105dvb-fe-ops.set_voltage = dm1105dvb_set_voltage; I have looked through the code for si21xx.c, and I see that you wrote that as well. You have been very busy!! I did rmmod si21xx, then insmod si21xx debug=1. I then rmmod dm1105, insmod dm1105. dmesg reports: [191712.426735] dm1105 :06:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [191712.426898] DVB: registering new adapter (dm1105) [191712.674945] dm1105 :06:00.0: MAC 00:00:00:00:00:00 [191714.072172] si21xx: si21xx_attach [191714.320219] si21xx: si21_readreg: readreg error (reg == 0x01, ret == -1) [191714.568266] si21xx: si21_writereg: writereg error (reg == 0x01, data == 0x40, ret == -1) [191715.020067] si21xx: si21_readreg: readreg error (reg == 0x00, ret == -1) [191715.020125] dm1105 :06:00.0: could not attach frontend [191715.020297] dm1105 :06:00.0: PCI INT A disabled Does this shed any light on the matter for you? Thanks, Paul -- 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://jusst.de/hg/stv090x
Oliver Endriss wrote: Manu Abraham wrote: On Mon, Jan 11, 2010 at 12:17 AM, Manu Abraham abraham.m...@gmail.com wrote: Mauro, Following the changesets 13830 - 13894 from my earlier pull request, Correction, 13880 - 13894 inclusive of both. Please pull the following changeset as well http://jusst.de/hg/stv090x/rev/80c74966d955 It fixes a nasty bug as described at http://osdir.com/ml/linux-media/2009-11/msg00643.html Regards, Manu Mauro, when will you pull-in these changesets? You are blocking the submission of the ngene driver. Hi Oliver, Since I returned from vacations this week, I had a pile of tasks to handle, both at the subsystem and at the work. Unfortunately, having to deal with both -hg and -git eats lot of my time, to be sure that nothing is missed. This time, I had to re-generate all my local -git trees that somehow had loose some patches in the process. Due to that, the patch merge is taking longer than I've expected. I still have a few issues pending at the subsystem, including this stv090x pull request, the omap pull (that it is very complex, as it requires both -hg and -git patch insertions), lnbh24 fix, my own proposals to dvb-apps, and two upstream submissions. My intention is to finish those tasks during this weekend if time allows me to do everything. In the specific case of stv090x, I intend to review again the locks, in the light of your comments. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL http://jusst.de/hg/stv090x
Manu Abraham wrote: On Mon, Jan 11, 2010 at 12:17 AM, Manu Abraham abraham.m...@gmail.com wrote: Mauro, Following the changesets 13830 - 13894 from my earlier pull request, Correction, 13880 - 13894 inclusive of both. Please pull the following changeset as well http://jusst.de/hg/stv090x/rev/80c74966d955 It fixes a nasty bug as described at http://osdir.com/ml/linux-media/2009-11/msg00643.html Regards, Manu Mauro, when will you pull-in these changesets? You are blocking the submission of the ngene driver. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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
Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250
Hi, I've got reworked changes for the IR for the TeVii S470 and the HVR-1250 at http://linuxtv.org/hg/~awalls/cx23885-ir2 Thanks to loaner HVR-1250 hardware from Devin Heitmueller, I've solved the infinite interrupt problem with the CX23885 AV core and have reworked the change set against the latest v4l-dvb. Please test. Note 1. the parameters for the IR controller setup in linux/drivers/video/cx23885-input.c may need to be tweaked to set the proper params.modulation and params.invert_level before you get keypresses decoded. 2. I guessed at a reasonable set of remote keycodes for the TeVii S470, so don't be surprised if the button mapping isn't quite right. 3. These module settings may be helpful for debug and test: # modprobe cx25840 debug=2 ir_debug=2 # modprobe cx23885 debug=7 Also directing kern.* messages to /var/log/messages in /etc/rsyslogd.conf and giving rsyslod a SIGHUP may be helpful for capturing the messages. 4. In case I didn't fix the infinite interrupts problem for the TeVii S470: Before testing, blacklist the cx23885 module in /etc/modprobe.d/blacklist, so that when you reboot, the module doesn't automatically load. If your system seems to be very busy with inifinite interrupts upon cx23885 module load, stop testing (and let me know). Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho: On Sat, 16 Jan 2010, hermann pitton wrote: Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. You have to explictly export the GPIO lines to get them to appear. Either in the kernel with gpio_export() or from sysfs. You also can't export GPIOs that something in the kernel is using. My original design didn't have this restriction. I felt there were valid debug and development reasons for doing so, having used them myself for debug and development of embedded systems, but David Brownell felt otherwise. I didn't even have the concept of export originally, all the gpios would show up. After all, all your PCI and USB devices, I2C chips or busses, etc. show up in sysfs. Nothing else does this must be exported to show up business. You can memory map the saa7133 PCI address space and modify the gpios, and anything else, with direct register access from userspace, and that's just fine. But being able to observe and modify the gpios with a gpio-only interface is just way too dangerous. Doesn't make sense. But I'm digressing. This sysfs interface only works with the gpio using the generic gpio layer. This was designed for generic gpios on SoCs that would be providing by some kind of platform driver or I2C gpio extenders. The gpios get and used by various other drivers. Like say write protects on memory cards, or system LEDs. I wrote a JTAG driver that used it. The point of the gpio layer is to interface drivers the provide gpios with other, different, drivers that use the gpio. It was introduced in the mid 2.6.20s IIRC. The saa713x driver predates the generic gpio layer by years and years, so it doesn't use it. It also doesn't need to use it. Since the gpios are managed by the saa713x driver, and they also used by the saa713x driver, there is no need to interface two different drivers together. There are tons of drivers for devices that have gpios like this, but they don't use the gpio layer. But with gpio access via sysfs for generic gpios, there is something useful about having the saa713x driver support generic gpios. IIRC, somehow wrote a gpio only bt848 driver that didn't do anything but export gpios. In order to do this, you'll have to write code for the saa7134 driver to have it register with the gpio layer. I think you could still have the saa7134 driver itself use its gpio directly. That would avoid a performance penalty in the driver. Thanks for more details, but I'm still wondering what pins ever could be interesting in userland, given that they are all treated such different per device, and we count up to 200 different boards these days. For now, we should only allow user control over such pins above any count from 0 to 27, what the m$ driver does rounding up nothing ;) Or is there one single pin, potentially useful in userland? They can all be ambiguous, multi purpose per device, for what I can see. Cheers, Hermann -- 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: Order of dvb devices
True, the ordering is not exactly the same everytime. One will need to
provide PCI Bus related info also to a practical udev configuration to
get things sorted out in a sane way, rather than anything else.
At least in Mandriva, the order and naming of network adapters are
handled by using a this kind of udev rule which prevents for example eth0
and eth1 to swap between boots:
[lam...@iiris rules.d]$ cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# Drakx-net rule for eth0 (00:24:e8:9e:66:13)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:11:22:33:44:55, ATTR{type}==1, KERNEL==eth*,
NAME=eth0
# PCI device 0x8086:0x4232 (iwlagn)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==11:22:33:44:55:66, ATTR{type}==1, KERNEL==wlan*,
NAME=wlan0
I am not sure whether udev rules itself can originally generate this file
or whether it's mandriva's own tools/scripts that will generate this file
and add all new adapters it finds that are not yet in the file.
Mika
--
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
