Re: [PATCH] Atmel IMAGE SENSOR INTERFACE (ISI) driver.
Hi Sedji, On Friday 11 June 2010 11:27:51 Sedji Gaouaou wrote: No comments about this patch? It's a big patch and it takes time to review it. I'll comment on it, but please give me a few days. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35] forget gspca for_2.6.35
Hi Mauro, Please forget about the previous pull request: it seems that people better like to have a monotonic time instead of the real wall time in the video buffer timestamp. Thanks. -- 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
Alternative for defconfig
Hi, 1. What is the alternative way of submitting defconfig changes/files to LO? 2. Can any of you give me examples? Regards, Rajkumar N. -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, June 09, 2010 3:57 PM To: Nagarajan, Rajkumar Cc: linux-media@vger.kernel.org Subject: Re: [PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 3630SDP Hi Rajkumar, On Wednesday 09 June 2010 11:51:45 Nagarajan, Rajkumar wrote: Defconfig changes to enable V4L2 on zoom2, zoom3 and 3630sdp boards. Defconfigs on ARM are going away. See the http://lkml.org/lkml/2010/6/2/472 thread on LKML. There's also a lengthy discussion about that on LAKML. Linus will not accept any change to the defconfig files anymore and currently plans to remove them completely for 2.6.36. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Atmel IMAGE SENSOR INTERFACE (ISI) driver.
Em 11-06-2010 06:27, Sedji Gaouaou escreveu: Hi, No comments about this patch? Most developers are preparing to travel abroad to the V4L mini-summit next week. So, it may take some time until we would be able to review it. 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: Alternative for defconfig
On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar x0133...@ti.com wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think we have any alternative yet. -- Felipe Contreras -- 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: Alternative for defconfig
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Friday, June 11, 2010 8:43 AM To: Nagarajan, Rajkumar Cc: Laurent Pinchart; linux-media@vger.kernel.org; Hiremath, Vaibhav; linux-o...@vger.kernel.org Subject: Re: Alternative for defconfig On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar x0133...@ti.com wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. Regards, Sergio I don't think we have any alternative yet. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Alternative for defconfig
Hi Sergio, On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Friday, June 11, 2010 8:43 AM To: Nagarajan, Rajkumar Cc: Laurent Pinchart; linux-media@vger.kernel.org; Hiremath, Vaibhav; linux-o...@vger.kernel.org Subject: Re: Alternative for defconfig On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Board-specific defconfigs won't be allowed anymore, the number of defconfigs needs to be reduced drastically (ideally to one or two only). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Alternative for defconfig
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, June 11, 2010 10:08 AM To: Aguirre, Sergio Cc: Felipe Contreras; Nagarajan, Rajkumar; linux-media@vger.kernel.org; Hiremath, Vaibhav; linux-o...@vger.kernel.org Subject: Re: Alternative for defconfig Hi Sergio, On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Friday, June 11, 2010 8:43 AM To: Nagarajan, Rajkumar Cc: Laurent Pinchart; linux-media@vger.kernel.org; Hiremath, Vaibhav; linux-o...@vger.kernel.org Subject: Re: Alternative for defconfig On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Board-specific defconfigs won't be allowed anymore, the number of defconfigs needs to be reduced drastically (ideally to one or two only). Hmm, Interesting... We will be now forced to resolve some potential hidden issues with ARM multibuilds (like the ones showing up when creating the omap3_defconfig), and that's a great motivation to nail down all possible portability problems. /me likes that :) Regards, Sergio -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Alternative for defconfig
Laurent Pinchart wrote: On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote: On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Board-specific defconfigs won't be allowed anymore, the number of defconfigs needs to be reduced drastically (ideally to one or two only). There is some good work going on on the linux-arm-kernel mailing list to cut down heavily the ARM defconfigs. Would be good to join that discussion. For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would suffice to cover all OMAPs? - Anand -- 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: Alternative for defconfig
Hi Anand, On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote: Laurent Pinchart wrote: On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote: On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Board-specific defconfigs won't be allowed anymore, the number of defconfigs needs to be reduced drastically (ideally to one or two only). There is some good work going on on the linux-arm-kernel mailing list to cut down heavily the ARM defconfigs. Would be good to join that discussion. For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would suffice to cover all OMAPs? I'm not sure what the exact roadmap will be. Linus is complaining about the defconfig changes taking up too much of the diffstat. I don't know if he will accept patches to solve the problem gradually, or if he will just remove all defconfig files in 2.6.36. In any case, all changes that make it possible to built more machine types and platform types in the same kernel are a step in the right direction. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Alternative for defconfig
-Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, June 11, 2010 10:26 AM To: Gadiyar, Anand Cc: Aguirre, Sergio; Felipe Contreras; Nagarajan, Rajkumar; linux- me...@vger.kernel.org; Hiremath, Vaibhav; linux-o...@vger.kernel.org Subject: Re: Alternative for defconfig Hi Anand, On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote: Laurent Pinchart wrote: On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote: On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Board-specific defconfigs won't be allowed anymore, the number of defconfigs needs to be reduced drastically (ideally to one or two only). There is some good work going on on the linux-arm-kernel mailing list to cut down heavily the ARM defconfigs. Would be good to join that discussion. For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would suffice to cover all OMAPs? I'm not sure what the exact roadmap will be. Linus is complaining about the defconfig changes taking up too much of the diffstat. I don't know if he will accept patches to solve the problem gradually, or if he will just remove all defconfig files in 2.6.36. In any case, all changes that make it possible to built more machine types and platform types in the same kernel are a step in the right direction. I definitely think that one important step to achieve a multi platform build is to detect the minimal arm_defconfig first, and then (most importantly IMHO) proceed with trying to generate kernel modules of almost all peripherals. Many boards tend to be tested with just monolithic single-platform kernels, and making things modular hasn't been addressed at all in some drivers (old OMAP DSS code, for example). Regards, Sergio -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] stb0899: Removed an extra byte sent at init on DiSEqC bus
Hi,
I noticed a stray 0x00 at init on DiSEqC bus (KNC1 DVB-S2) with a DiSEqC
tool analyzer.
I removed the register from initialization table and all seem to go well
(at least for my KNC board).
Regards,
Signed-off-by: Florent Audebert florent.audeb...@anevia.com
---
drivers/media/dvb/dvb-usb/az6027.c |1 -
drivers/media/dvb/mantis/mantis_vp1041.c |1 -
drivers/media/dvb/ttpci/budget-av.c |1 -
drivers/media/dvb/ttpci/budget-ci.c |1 -
4 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/az6027.c
b/drivers/media/dvb/dvb-usb/az6027.c
index 6681ac1..9710e7b 100644
--- a/drivers/media/dvb/dvb-usb/az6027.c
+++ b/drivers/media/dvb/dvb-usb/az6027.c
@@ -40,7 +40,6 @@ static const struct stb0899_s1_reg az6027_stb0899_s1_init_1[]
= {
{ STB0899_DISRX_ST0 , 0x04 },
{ STB0899_DISRX_ST1 , 0x00 },
{ STB0899_DISPARITY , 0x00 },
- { STB0899_DISFIFO , 0x00 },
{ STB0899_DISSTATUS , 0x20 },
{ STB0899_DISF22, 0x99 },
{ STB0899_DISF22RX , 0xa8 },
diff --git a/drivers/media/dvb/mantis/mantis_vp1041.c
b/drivers/media/dvb/mantis/mantis_vp1041.c
index d1aa2bc..7bb1f28 100644
--- a/drivers/media/dvb/mantis/mantis_vp1041.c
+++ b/drivers/media/dvb/mantis/mantis_vp1041.c
@@ -51,7 +51,6 @@ static const struct stb0899_s1_reg vp1041_stb0899_s1_init_1[]
= {
{ STB0899_DISRX_ST0 , 0x04 },
{ STB0899_DISRX_ST1 , 0x00 },
{ STB0899_DISPARITY , 0x00 },
- { STB0899_DISFIFO , 0x00 },
{ STB0899_DISSTATUS , 0x20 },
{ STB0899_DISF22, 0x99 },
{ STB0899_DISF22RX , 0xa8 },
diff --git a/drivers/media/dvb/ttpci/budget-av.c
b/drivers/media/dvb/ttpci/budget-av.c
index 983672a..b697af4 100644
--- a/drivers/media/dvb/ttpci/budget-av.c
+++ b/drivers/media/dvb/ttpci/budget-av.c
@@ -896,7 +896,6 @@ static const struct stb0899_s1_reg knc1_stb0899_s1_init_1[]
= {
{ STB0899_DISRX_ST0 , 0x04 },
{ STB0899_DISRX_ST1 , 0x00 },
{ STB0899_DISPARITY , 0x00 },
- { STB0899_DISFIFO , 0x00 },
{ STB0899_DISSTATUS , 0x20 },
{ STB0899_DISF22, 0x8c },
{ STB0899_DISF22RX , 0x9a },
diff --git a/drivers/media/dvb/ttpci/budget-ci.c
b/drivers/media/dvb/ttpci/budget-ci.c
index 13ac9e3..da5a72c 100644
--- a/drivers/media/dvb/ttpci/budget-ci.c
+++ b/drivers/media/dvb/ttpci/budget-ci.c
@@ -1046,7 +1046,6 @@ static const struct stb0899_s1_reg
tt3200_stb0899_s1_init_1[] = {
{ STB0899_DISRX_ST0 , 0x04 },
{ STB0899_DISRX_ST1 , 0x00 },
{ STB0899_DISPARITY , 0x00 },
- { STB0899_DISFIFO , 0x00 },
{ STB0899_DISSTATUS , 0x20 },
{ STB0899_DISF22, 0x8c },
{ STB0899_DISF22RX , 0x9a },
--
1.7.1
--
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: Alternative for defconfig
On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Huh? I thought he was only threatening to remove them[1]. I don't think he said he was going to do that without any alternative in place. My suggestion[2] was to have minimal defconfigs so that we could do $ cp arch/arm/configs/omap3_beagle_baseconfig .config $ echo | make ARCH=arm oldconfig [1] http://article.gmane.org/gmane.linux.kernel/994194 [2] http://article.gmane.org/gmane.linux.kernel/995412 -- Felipe Contreras -- 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 Jun 11 19:00:20 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14974:023a0048e6a8 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS 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
PXA320 camera support
Hi all, I have seen that the pxa27xx-camera is inside the devices for the PXA320 but I don't know if this support work for this cpu. Looking at the code for example the overrun condition check is wrong for the PXA320 because the bits of the overrun is different - camera_status = __raw_readl(pcdev-base + CISR); + camera_status = __raw_readl(pcdev-base + CIFSR); In the two implementation. Anyone has tried to use it on the pxa320? Michael Trimarchi -- 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] Fix av7110 driver name
This patch simply changes the name of the av7110 driver to AV7110
instead of the generic dvb it's set to currently. Although it's
somewhat trivial, it still seems appropriate to fix the name to be
descriptive of the driver.
Signed-off-by: Derek Kelly user@gmail.com
--
--- v4l-dvb/linux/drivers/media/dvb/ttpci/av7110.c 2010-06-11
13:24:29.0 -0700
+++ v4l-dvb.orig/linux/drivers/media/dvb/ttpci/av7110.c 2010-06-11
12:49:50.0 -0700
@@ -2893,7 +2893,7 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
static struct saa7146_extension av7110_extension_driver = {
- .name = AV7110,
+ .name = dvb,
.flags = SAA7146_USE_I2C_IRQ,
.module = THIS_MODULE,
--
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] Fix module dependency selection for Mantis driver
This patch adds missing module dependencies to the Mantis Kconfig file so that they are selected automatically when the user enables Mantis. Signed-off-by: Derek Kelly user@gmail.com -- --- v4l-dvb.orig/linux/drivers/media/dvb/mantis/Kconfig 2010-06-11 14:28:26.0 -0700 +++ v4l-dvb/linux/drivers/media/dvb/mantis/Kconfig 2010-06-11 14:32:44.0 -0700 @@ -10,6 +10,8 @@ config MANTIS_CORE config DVB_MANTIS tristate MANTIS based cards depends on MANTIS_CORE DVB_CORE PCI I2C + select DVB_STB0899 + select DVB_STB6100 select DVB_MB86A16 select DVB_ZL10353 select DVB_STV0299 -- 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
