Re: [PATCH] Atmel IMAGE SENSOR INTERFACE (ISI) driver.

2010-06-11 Thread Laurent Pinchart
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

2010-06-11 Thread Jean-Francois Moine
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

2010-06-11 Thread Nagarajan, Rajkumar
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.

2010-06-11 Thread Mauro Carvalho Chehab
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

2010-06-11 Thread Felipe Contreras
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

2010-06-11 Thread Aguirre, Sergio


 -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

2010-06-11 Thread Laurent Pinchart
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

2010-06-11 Thread Aguirre, Sergio
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

2010-06-11 Thread Gadiyar, Anand
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

2010-06-11 Thread Laurent Pinchart
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

2010-06-11 Thread Aguirre, Sergio


 -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

2010-06-11 Thread Florent AUDEBERT
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

2010-06-11 Thread Felipe Contreras
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

2010-06-11 Thread Hans Verkuil
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

2010-06-11 Thread Michael Trimarchi

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

2010-06-11 Thread VDR User
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

2010-06-11 Thread VDR User
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