Re: [Linaro-mm-sig] [PATCHv16 0/9] Contiguous Memory Allocator

[Ohad Ben-Cohen]

On Fri, Oct 7, 2011 at 6:27 PM, Arnd Bergmann a...@arndb.de wrote:
 IMHO it would be good to merge the entire series into 3.2, since
 the ARM portion fixes an important bug (double mapping of memory
 ranges with conflicting attributes) that we've lived with for far
 too long, but it really depends on how everyone sees the risk
 for regressions here. If something breaks in unfixable ways before
 the 3.2 release, we can always revert the patches and have another
 try later.

I didn't thoroughly review the patches, but I did try them out (to be
precise, I tried v15) on an OMAP4 PandaBoard, and really liked the
result.

The interfaces seem clean and convenient and things seem to work (I
used a private CMA pool with rpmsg and remoteproc, but also noticed
that several other drivers were utilizing the global pool). And with
this in hand we can finally ditch the old reserve+ioremap approach.

So from a user perspective, I sure do hope this patch set gets into
3.2; hopefully we can just fix anything that would show up during the
3.2 cycle.

Marek, Michal (and everyone involved!), thanks so much for pushing
this! Judging from the history of this patch set and the areas that it
touches (and from the number of LWN articles ;) it looks like a
considerable feat.

FWIW, feel free to add my

Tested-by: Ohad Ben-Cohen o...@wizery.com

(small and optional comment: I think it'd be nice if
dma_declare_contiguous would fail if called too late, otherwise users
of that misconfigured device will end up using the global pool without
easily knowing that something went wrong)

Thanks,
Ohad.
--
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: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 1:00 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
 On Mon, Oct 10, 2011 at 12:35 AM, Enrico ebut...@users.berlios.de wrote:
 I made some tests and unfortunately there are some problems.

 Note: i made these tests picking some patches from omap3isp-yuv branch
 and applying to igep 3.1.0rc9 kernel (more or less like mainline +
 some bsp patches) so maybe i made some mistakes (the tvp5150 driver is
 patched too), but due to the nature of the problems i don't think this
 is the case.

 Javier patches v1: i can grab frames with yavta but i get only garbage.

 Javier patches v2: i cannot grab frames with yavta (it hangs). I see
 only 2 interrupts on the isp, then stops.

 I compared Javier-v2 registers setup with Deepthy's patches and there
 are some differences. Moreover i remember that in Deepthy patches vd1
 interrupt was not used (and in fact i had the same yavta-hanging
 problem before, and Deepthy patches solved it).

 I think Javier-v1 patches didn't hang the isp because they changed
 vd0/vd1 logic too, so maybe there were only some wrong isp registers
 but the logic was correct.

 Now i wonder if it could be easier/better to port Deepthy patches
 first and then add Javier fixes...

 Enrico


 Hi Enrico,

 Yes, you are right in interlaced mode the VD1 interrupt handler
 doesn't have to be executed. In v1 there is a conditional execution
 and that is why the ISP doesn't hang up.

 Could you please try changing this on ispccdc.c with v2 patches?

 diff --git a/drivers/media/video/omap3isp/ispccdc.c
 b/drivers/media/video/omap3isp/ispccdc.c
 index 9b40968..bfd3f46 100644
 --- a/drivers/media/video/omap3isp/ispccdc.c
 +++ b/drivers/media/video/omap3isp/ispccdc.c
 @@ -1658,7 +1658,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device
 *ccdc, u32 events)
        if (ccdc-state == ISP_PIPELINE_STREAM_STOPPED)
                return 0;

 -       if (events  IRQ0STATUS_CCDC_VD1_IRQ)
 +       if ((events  IRQ0STATUS_CCDC_VD1_IRQ) 
 +           !ccdc_input_is_fldmode(ccdc))
                ccdc_vd1_isr(ccdc);

        ccdc_lsc_isr(ccdc, events);

 With this change the ISP shouldn't hang but I don't know if you will
 get the right data.

I tried that but i only get this:

root@igep0020:~# yavta -c4 -f UYVY -s 720x625 -n 4 /dev/video2
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: UYVY (59565955) 720x625 buffer size 90
Video format: UYVY (59565955) 720x625 buffer size 90
4 buffers requested.
length: 90 offset: 0
Buffer 0 mapped at address 0x4027a000.
length: 90 offset: 901120
Buffer 1 mapped at address 0x403de000.
length: 90 offset: 1802240
Buffer 2 mapped at address 0x4059b000.
length: 90 offset: 2703360
Buffer 3 mapped at address 0x40748000.
[  952.675170] omap3isp omap3isp: CCDC won't become idle!
[  952.695159] omap3isp omap3isp: CCDC won't become idle!
[  952.715179] omap3isp omap3isp: CCDC won't become idle!
[  952.735137] omap3isp omap3isp: CCDC won't become idle!

and it continues forever saying that.

I'm going to try to apply Deepthy patches on omap3isp-yuv and hope it will work.

Enrico
--
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: omap3-isp status

[Javier Martinez Canillas]

On Mon, Oct 10, 2011 at 10:54 AM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 1:00 AM, Javier Martinez Canillas
 martinez.jav...@gmail.com wrote:
 On Mon, Oct 10, 2011 at 12:35 AM, Enrico ebut...@users.berlios.de wrote:
 I made some tests and unfortunately there are some problems.

 Note: i made these tests picking some patches from omap3isp-yuv branch
 and applying to igep 3.1.0rc9 kernel (more or less like mainline +
 some bsp patches) so maybe i made some mistakes (the tvp5150 driver is
 patched too), but due to the nature of the problems i don't think this
 is the case.

 Javier patches v1: i can grab frames with yavta but i get only garbage.

 Javier patches v2: i cannot grab frames with yavta (it hangs). I see
 only 2 interrupts on the isp, then stops.

 I compared Javier-v2 registers setup with Deepthy's patches and there
 are some differences. Moreover i remember that in Deepthy patches vd1
 interrupt was not used (and in fact i had the same yavta-hanging
 problem before, and Deepthy patches solved it).

 I think Javier-v1 patches didn't hang the isp because they changed
 vd0/vd1 logic too, so maybe there were only some wrong isp registers
 but the logic was correct.

 Now i wonder if it could be easier/better to port Deepthy patches
 first and then add Javier fixes...

 Enrico


 Hi Enrico,

 Yes, you are right in interlaced mode the VD1 interrupt handler
 doesn't have to be executed. In v1 there is a conditional execution
 and that is why the ISP doesn't hang up.

 Could you please try changing this on ispccdc.c with v2 patches?

 diff --git a/drivers/media/video/omap3isp/ispccdc.c
 b/drivers/media/video/omap3isp/ispccdc.c
 index 9b40968..bfd3f46 100644
 --- a/drivers/media/video/omap3isp/ispccdc.c
 +++ b/drivers/media/video/omap3isp/ispccdc.c
 @@ -1658,7 +1658,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device
 *ccdc, u32 events)
        if (ccdc-state == ISP_PIPELINE_STREAM_STOPPED)
                return 0;

 -       if (events  IRQ0STATUS_CCDC_VD1_IRQ)
 +       if ((events  IRQ0STATUS_CCDC_VD1_IRQ) 
 +           !ccdc_input_is_fldmode(ccdc))
                ccdc_vd1_isr(ccdc);

        ccdc_lsc_isr(ccdc, events);

 With this change the ISP shouldn't hang but I don't know if you will
 get the right data.

 I tried that but i only get this:

 root@igep0020:~# yavta -c4 -f UYVY -s 720x625 -n 4 /dev/video2
 Device /dev/video2 opened.
 Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
 Video format set: UYVY (59565955) 720x625 buffer size 90
 Video format: UYVY (59565955) 720x625 buffer size 90
 4 buffers requested.
 length: 90 offset: 0
 Buffer 0 mapped at address 0x4027a000.
 length: 90 offset: 901120
 Buffer 1 mapped at address 0x403de000.
 length: 90 offset: 1802240
 Buffer 2 mapped at address 0x4059b000.
 length: 90 offset: 2703360
 Buffer 3 mapped at address 0x40748000.
 [  952.675170] omap3isp omap3isp: CCDC won't become idle!
 [  952.695159] omap3isp omap3isp: CCDC won't become idle!
 [  952.715179] omap3isp omap3isp: CCDC won't become idle!
 [  952.735137] omap3isp omap3isp: CCDC won't become idle!

 and it continues forever saying that.

 I'm going to try to apply Deepthy patches on omap3isp-yuv and hope it will 
 work.

 Enrico


Hi Enrico,

Is your tree (igep 3.1.0rc9 kernel + omap3isp-yuv patches) accessible
so I can clone and give a try?

I can then make a patch-set on top on that, one that I can actually
test on real hardware and be sure that is working well.

If I can git clone your tree then it will be faster, otherwise I will
try omap3isp-yuv with igep board support added, but it would take me
more time to do so. I will find some free time late this afternoon to
try that.

Best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 11:02 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
 Is your tree (igep 3.1.0rc9 kernel + omap3isp-yuv patches) accessible
 so I can clone and give a try?

 I can then make a patch-set on top on that, one that I can actually
 test on real hardware and be sure that is working well.

 If I can git clone your tree then it will be faster, otherwise I will
 try omap3isp-yuv with igep board support added, but it would take me
 more time to do so. I will find some free time late this afternoon to
 try that.

I have updated my igep openembedded layer at [1] (testing branch) with:

current igep master kernel (3.1.0rc9) + omap3isp-yuv patches + your
patches v2 + tvp5150 patches + some tvp5150 and board files fixes.

All the patches (specified in the .bb file) are git am-able patches so
you can just clone the igep master repository and apply all the
patches (0001-0025).

This is the cover letter for the patches i applied, if someone can
review the omap3isp related patches to be sure i didn't forget
anything it would be very helpful:

Arnaud Lacombe (1):
  drivers/media: do not use EXTRA_CFLAGS

Enrico Butera (3):
  tvp5150: compile fixes and added missing entity_cleanup
  exp-igep0022: add tvp5151 support
  igep00x0: fix camera platform data

Guennadi Liakhovetski (1):
  omap3isp: ccdc: remove redundant operation

Ivaylo Petrov (1):
  omap3isp: csi2: Add V4L2_MBUS_FMT_YUYV8_2X8 support

Javier Martinez Canillas (6):
  omap3isp: ccdc: Add interlaced field mode to platform data
  omap3isp: ccdc: Add interlaced count field to isp_ccdc_device
  omap3isp: ccdc: Add support to ITU-R BT.656 video data format
  tvp5150: Add constants for PAL and NTSC video standards
  tvp5150: Add video format registers configuration values
  tvp5150: Migrate to media-controller framework and add video format
detection

Laurent Pinchart (12):
  omap3isp: Don't accept pipelines with no video source as valid
  omap3isp: Move platform data definitions from isp.h to
media/omap3isp.h
  omap3isp: Don't fail streamon when the sensor doesn't implement
s_stream
  omap3isp: video: Avoid crashes when pipeline set stream operation
fails
  omap3isp: Move media_entity_cleanup() from unregister() to cleanup()
  omap3isp: Move *_init_entities() functions to the init/cleanup
section
  omap3isp: Add missing mutex_destroy() calls
  omap3isp: Fix memory leaks in initialization error paths
  omap3isp: video: Split format info bpp field into width and bpp
  omap3isp: ccdc: Remove support for interlaced data and master HS/VS
mode
  omap3isp: ccdc: Remove ispccdc_syncif structure
  omap3isp: ccdc: Add YUV input formats support

Michael Jones (1):
  omap3isp: queue: fail QBUF if user buffer is too small

 arch/arm/mach-omap2/board-igep00x0.c   |   67 +
 arch/arm/mach-omap2/exp-igep0022.c |3 +
 drivers/media/video/omap3isp/Makefile  |4 +-
 drivers/media/video/omap3isp/isp.c |   13 +-
 drivers/media/video/omap3isp/isp.h |   87 +--
 drivers/media/video/omap3isp/ispccdc.c |  376 --
 drivers/media/video/omap3isp/ispccdc.h |   38 +---
 drivers/media/video/omap3isp/ispccp2.c |  129 +-
 drivers/media/video/omap3isp/ispcsi2.c |  118 +---
 drivers/media/video/omap3isp/isph3a_aewb.c |2 +-
 drivers/media/video/omap3isp/isph3a_af.c   |2 +-
 drivers/media/video/omap3isp/isphist.c |2 +-
 drivers/media/video/omap3isp/isppreview.c  |  108 
 drivers/media/video/omap3isp/ispqueue.c|4 +
 drivers/media/video/omap3isp/ispresizer.c  |  104 
 drivers/media/video/omap3isp/ispstat.c |   52 ++--
 drivers/media/video/omap3isp/ispstat.h |2 +-
 drivers/media/video/omap3isp/ispvideo.c|   77 --
 drivers/media/video/omap3isp/ispvideo.h|5 +-
 drivers/media/video/tvp5150.c  |  408 +++-
 drivers/media/video/tvp5150_reg.h  |   17 +-
 include/media/omap3isp.h   |  138 ++
 include/media/tvp5150.h|6 +
 23 files changed, 1215 insertions(+), 547 deletions(-)
 create mode 100644 include/media/omap3isp.h

Enrico
--
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: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote:
 I have updated my igep openembedded layer at [1] (testing branch) with:

Ops, forgot [1] !

[1]: https://github.com/ebutera/meta-igep

Enrico
--
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: omap3-isp status

[Javier Martinez Canillas]

On Mon, Oct 10, 2011 at 12:07 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote:
 I have updated my igep openembedded layer at [1] (testing branch) with:

 Ops, forgot [1] !

 [1]: https://github.com/ebutera/meta-igep

 Enrico


Perfect, thank you Enrico. I will try this latter today and let you
know. I'm sure I can get this working (with the ghosting effect of
course) so you can at least obtain 25 fps and once I have this working
I will resend the patch-set as v3 so Laurent can review it and
hopefully help us to fix the artifact on the video.

Best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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: make error

[Todor Tomov]

Hi,

On 10/08/2011 03:04 PM, Masaru Nomiya wrote:

Hello,

I tried to compile the very latest git of v4l-utils.
But, I got an error;

[...]
g++ -m64 -o qv4l2 qv4l2.o general-tab.o ctrl-tab.o v4l2-api.o capture-win.o 
moc_qv4l2.o moc_general-tab.o moc_capture-win.o qrc_qv4l2.o-L/usr/lib64 
-L../../lib/libv4l2 -lv4l2 -L../../lib/libv4lconvert -lv4lconvert -lrt 
-L../libv4l2util -lv4l2util -ldl -ljpeg -lQtGui -L/usr/lib64 -L/usr/X11R6/lib64 
-lQtCore -lpthread
qv4l2.o: In function `ApplicationWindow::setDevice(QString const, bool)':
/tmp/source/v4l-utils/utils/qv4l2/qv4l2.cpp:156: undefined reference to 
`libv4l2_default_dev_ops'
collect2: ld returned 1 exit status

Any hint?


This is discussed here:
http://www.spinics.net/lists/linux-media/msg38924.html


Thanks in advance.

PS. My system

1. OS : openSUSE 11.3
 3.0.6-1.1-default #1 SMP x86_64 GNU/Linux

2. gcc : gcc (SUSE Linux) 4.5.3 20110428 [gcc-4_5-branch revision 173117]
3. ld  : GNU ld (GNU Binutils; devel:gcc / openSUSE_11.3) 2.21.1

Regards,

---
┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp
┃＼／彡
┗━━┛ Bill! You married with Computers.
   Not with Me!
  No..., with money.
--
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



--
Best regards,
Todor Tomov

--
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: [Linaro-mm-sig] [PATCHv16 0/9] Contiguous Memory Allocator

[Clark, Rob]

On Mon, Oct 10, 2011 at 1:58 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Fri, Oct 7, 2011 at 6:27 PM, Arnd Bergmann a...@arndb.de wrote:
 IMHO it would be good to merge the entire series into 3.2, since
 the ARM portion fixes an important bug (double mapping of memory
 ranges with conflicting attributes) that we've lived with for far
 too long, but it really depends on how everyone sees the risk
 for regressions here. If something breaks in unfixable ways before
 the 3.2 release, we can always revert the patches and have another
 try later.

 I didn't thoroughly review the patches, but I did try them out (to be
 precise, I tried v15) on an OMAP4 PandaBoard, and really liked the
 result.

 The interfaces seem clean and convenient and things seem to work (I
 used a private CMA pool with rpmsg and remoteproc, but also noticed
 that several other drivers were utilizing the global pool). And with
 this in hand we can finally ditch the old reserve+ioremap approach.

 So from a user perspective, I sure do hope this patch set gets into
 3.2; hopefully we can just fix anything that would show up during the
 3.2 cycle.

 Marek, Michal (and everyone involved!), thanks so much for pushing
 this! Judging from the history of this patch set and the areas that it
 touches (and from the number of LWN articles ;) it looks like a
 considerable feat.

 FWIW, feel free to add my

 Tested-by: Ohad Ben-Cohen o...@wizery.com

Marek, I guess I forgot to mention earlier, but I've been using CMA
for a couple of weeks now with omapdrm driver, so you can also add my:

Tested-by: Rob Clark r...@ti.com

BR,
-R

 (small and optional comment: I think it'd be nice if
 dma_declare_contiguous would fail if called too late, otherwise users
 of that misconfigured device will end up using the global pool without
 easily knowing that something went wrong)

 Thanks,
 Ohad.

 ___
 Linaro-mm-sig mailing list
 linaro-mm-...@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-mm-sig

--
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: [Linaro-mm-sig] [PATCHv16 0/9] Contiguous Memory Allocator

[Maxime Coquelin]

On 10/06/2011 03:54 PM, Marek Szyprowski wrote:

Welcome everyone again,

Once again I decided to post an updated version of the Contiguous Memory
Allocator patches.

This version provides mainly a bugfix for a very rare issue that might
have changed migration type of the CMA page blocks resulting in dropping
CMA features from the affected page block and causing memory allocation
to fail. Also the issue reported by Dave Hansen has been fixed.

This version also introduces basic support for x86 architecture, what
allows wide testing on KVM/QEMU emulators and all common x86 boxes. I
hope this will result in wider testing, comments and easier merging to
mainline.

I've also dropped an examplary patch for s5p-fimc platform device
private memory declaration and added the one from real life. CMA device
private memory regions are defined for s5p-mfc device to let it allocate
buffers from two memory banks.

ARM integration code has not been changed since last version, it
provides implementation of all the ideas that has been discussed during


Hello Marek,

We are currently testing CMA (v16) on Snowball platform.
This feature is very promising, thanks for pushing it!

During our stress tests, we encountered some problems :

1) Contiguous allocation lockup:
When system RAM is full of Anon pages, if we try to allocate a 
contiguous buffer greater than the min_free value, we face a 
dma_alloc_from_contiguous lockup.

The expected result would be dma_alloc_from_contiguous() to fail.
The problem is reproduced systematically on our side.

2) Contiguous allocation fail:
We have developed a small driver and a shell script to 
allocate/release contiguous buffers.
Sometimes, dma_alloc_from_contiguous() fails to allocate the 
contiguous buffer (about once every 30 runs).
We have 270MB Memory passed to the kernel in our configuration, 
and the CMA pool is 90MB large.
In this setup, the overall memory is either free or full of 
reclaimable pages.



For now, we didn't had time to investigate further theses problems.
Have you already faced this kind of issues?
Could someone testing CMA on other boards confirm/infirm theses 
problems?


Best regards,
Maxime




Patches in this patchset:

   mm: move some functions from memory_hotplug.c to page_isolation.c
   mm: alloc_contig_freed_pages() added

 Code stolen from Kamezawa.  The first patch just moves code
 around and the second provide function for allocates already
 freed memory.

   mm: alloc_contig_range() added

 This is what Kamezawa asked: a function that tries to migrate all
 pages from given range and then use alloc_contig_freed_pages()
 (defined by the previous commit) to allocate those pages.

   mm: MIGRATE_CMA migration type added
   mm: MIGRATE_CMA isolation functions added

 Introduction of the new migratetype and support for it in CMA.
 MIGRATE_CMA works similar to ZONE_MOVABLE expect almost any
 memory range can be marked as one.

   mm: cma: Contiguous Memory Allocator added

 The code CMA code. Manages CMA contexts and performs memory
 allocations.

   X86: integrate CMA with DMA-mapping subsystem
   ARM: integrate CMA with dma-mapping subsystem

 Main clients of CMA framework. CMA serves as a alloc_pages()
 replacement.

   ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device

 Use CMA device private memory regions instead of custom solution
 based on memblock_reserve() + dma_declare_coherent().


Patch summary:

KAMEZAWA Hiroyuki (2):
   mm: move some functions from memory_hotplug.c to page_isolation.c
   mm: alloc_contig_freed_pages() added

Marek Szyprowski (4):
   drivers: add Contiguous Memory Allocator
   ARM: integrate CMA with DMA-mapping subsystem
   ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device
   X86: integrate CMA with DMA-mapping subsystem

Michal Nazarewicz (3):
   mm: alloc_contig_range() added
   mm: MIGRATE_CMA migration type added
   mm: MIGRATE_CMA isolation functions added

  arch/Kconfig  |3 +
  arch/arm/Kconfig  |2 +
  arch/arm/include/asm/dma-contiguous.h |   16 ++
  arch/arm/include/asm/mach/map.h   |1 +
  arch/arm/mm/dma-mapping.c |  362 +--
  arch/arm/mm/init.c|8 +
  arch/arm/mm/mm.h  |3 +
  arch/arm/mm/mmu.c |   29 ++-
  arch/arm/plat-s5p/dev-mfc.c   |   51 +
  arch/x86/Kconfig  |1 +
  arch/x86/include/asm/dma-contiguous.h |   13 +
  arch/x86/include/asm/dma-mapping.h|4 +
  arch/x86/kernel/pci-dma.c |   18 ++-
  arch/x86/kernel/pci-nommu.c   |8 +-
  arch/x86/kernel/setup.c   |2 +
  drivers/base/Kconfig  |   79 +++
  drivers/base/Makefile |1 +
  drivers/base/dma-contiguous.c   

Re: make error

[Masaru Nomiya]

Hello,

In the Message; 

  Subject: Re: make error
  Message-ID : 4e92d0b1.1050...@mm-sol.com
  Date  Time:  Mon, 10 Oct 2011 14:02:09 +0300

Todor Tomov tto...@mm-sol.com has written:

 [...]
 g++ -m64 -o qv4l2 qv4l2.o general-tab.o ctrl-tab.o v4l2-api.o capture-win.o 
 moc_qv4l2.o moc_general-tab.o moc_capture-win.o qrc_qv4l2.o-L/usr/lib64 
 -L../../lib/libv4l2 -lv4l2 -L../../lib/libv4lconvert -lv4lconvert -lrt 
 -L../libv4l2util -lv4l2util -ldl -ljpeg -lQtGui -L/usr/lib64 
 -L/usr/X11R6/lib64 -lQtCore -lpthread
 qv4l2.o: In function `ApplicationWindow::setDevice(QString const, bool)':
 /tmp/source/v4l-utils/utils/qv4l2/qv4l2.cpp:156: undefined reference to 
 `libv4l2_default_dev_ops'
 collect2: ld returned 1 exit status

 This is discussed here:
 http://www.spinics.net/lists/linux-media/msg38924.html

Thanks! I could solve.

Regards,

---
┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp
┃＼／彡
┗━━┛ Bill! You married with Computers.
  Not with Me!
 No..., with money.
--
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: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
 On Mon, Oct 10, 2011 at 12:07 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote:
 I have updated my igep openembedded layer at [1] (testing branch) with:

 Ops, forgot [1] !

 [1]: https://github.com/ebutera/meta-igep

 Enrico


 Perfect, thank you Enrico. I will try this latter today and let you
 know. I'm sure I can get this working (with the ghosting effect of
 course) so you can at least obtain 25 fps and once I have this working
 I will resend the patch-set as v3 so Laurent can review it and
 hopefully help us to fix the artifact on the video.

Yes it must be something simple but not easy to spot.

And to add even more confusion i've attached two patches: one is a
port of two Deepthy patches, the other one just a board fix.

Just replace patches 0017-18-19 with the attached 0001 patch, and
after patch 0025 apply the attached 0002 patch.

With these i can succesfully grab frames with yavta BUT i only get
half-height frames. Disclaimer: i just made the patch monkey and gave
it a run without a review so it could be anything.

Enrico
From abb4d9df937ebda4f628d5b94ae02c60e7b06a7b Mon Sep 17 00:00:00 2001
From: Enrico Butera ebut...@users.berlios.de
Date: Mon, 10 Oct 2011 14:16:46 +0200
Subject: [PATCH] omap3isp: configure ccdc and add bt656 support

This is a port of the following Deepthy Ravi patches:

[PATCH 5/8] ispccdc: Configure CCDC registers
[PATCH 6/8] ispccdc: Add support for BT656 interface

Signed-off-by: Enrico Butera ebut...@users.berlios.de
---
 drivers/media/video/omap3isp/ispccdc.c  |  126 +--
 drivers/media/video/omap3isp/ispccdc.h  |1 +
 drivers/media/video/omap3isp/ispreg.h   |1 +
 drivers/media/video/omap3isp/ispvideo.c |2 +-
 drivers/media/video/omap3isp/ispvideo.h |4 +-
 5 files changed, 110 insertions(+), 24 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index ce0e57d..3903acf 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -60,8 +60,11 @@ static const unsigned int ccdc_fmts[] = {
 	V4L2_MBUS_FMT_SGBRG12_1X12,
 	V4L2_MBUS_FMT_YUYV8_2X8,
 	V4L2_MBUS_FMT_UYVY8_2X8,
+	V4L2_MBUS_FMT_YUYV8_2X8,
 };
 
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
+
 /*
  * ccdc_print_status - Print current CCDC Module register values.
  * @ccdc: Pointer to ISP CCDC device.
@@ -793,11 +796,16 @@ static void ccdc_apply_controls(struct isp_ccdc_device *ccdc)
 void omap3isp_ccdc_restore_context(struct isp_device *isp)
 {
 	struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+	struct v4l2_mbus_framefmt *format;
 
 	isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, ISPCCDC_CFG_VDLC);
 
-	ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
-		 | OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
+	/* CCDC_PAD_SINK */
+	format = ccdc-formats[CCDC_PAD_SINK];
+	if ((format-code != V4L2_MBUS_FMT_UYVY8_2X8) 
+			(format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+		ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
+| OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
 	ccdc_apply_controls(ccdc);
 	ccdc_configure_fpc(ccdc);
 }
@@ -1022,10 +1030,10 @@ static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
 
 	if (pdata  pdata-bt656)
 		isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
-			ISPCCDC_REC656IF_R656ON);
+			ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
 	else
 		isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
-			ISPCCDC_REC656IF_R656ON);
+			ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
 }
 
 /* CCDC formats descriptions */
@@ -1107,6 +1115,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
 	struct isp_parallel_platform_data *pdata = NULL;
 	struct v4l2_subdev *sensor;
 	struct v4l2_mbus_framefmt *format;
+	struct v4l2_pix_format pix;
 	const struct isp_format_info *fmt_info;
 	struct v4l2_subdev_format fmt_src;
 	unsigned int depth_out;
@@ -1165,6 +1174,9 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
 	/* CCDC_PAD_SINK */
 	format = ccdc-formats[CCDC_PAD_SINK];
 
+	if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
+		isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG,
+			ISPCCDC_CFG_Y8POS);
 	/* Mosaic filter */
 	switch (format-code) {
 	case V4L2_MBUS_FMT_SRGGB10_1X10:
@@ -1184,27 +1196,59 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
 		ccdc_pattern = ccdc_sgrbg_pattern;
 		break;
 	}
-	ccdc_config_imgattr(ccdc, ccdc_pattern);
 
-	/* Generate VD0 on the last line of the image and VD1 on the
-	 * 2/3 height line.
-	 */
-	isp_reg_writel(isp, ((format-height - 2)  ISPCCDC_VDINT_0_SHIFT) |
-		   ((format-height * 2 / 3)  ISPCCDC_VDINT_1_SHIFT),
-		   OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
+	if ((format-code != V4L2_MBUS_FMT_YUYV8_2X8) 
+			(format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+		

Re: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
 On Mon, Oct 10, 2011 at 12:07 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote:
 I have updated my igep openembedded layer at [1] (testing branch) with:

 Ops, forgot [1] !

 [1]: https://github.com/ebutera/meta-igep

 Enrico


 Perfect, thank you Enrico. I will try this latter today and let you
 know. I'm sure I can get this working (with the ghosting effect of
 course) so you can at least obtain 25 fps and once I have this working
 I will resend the patch-set as v3 so Laurent can review it and
 hopefully help us to fix the artifact on the video.

For your tests i suggest to add nohlt to the kernel cmdline, see [1]
for the reason.

Enrico

[1]: http://www.spinics.net/lists/linux-media/msg37795.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: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 2:46 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas
 martinez.jav...@gmail.com wrote:
 On Mon, Oct 10, 2011 at 12:07 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote:
 I have updated my igep openembedded layer at [1] (testing branch) with:

 Ops, forgot [1] !

 [1]: https://github.com/ebutera/meta-igep

 Enrico


 Perfect, thank you Enrico. I will try this latter today and let you
 know. I'm sure I can get this working (with the ghosting effect of
 course) so you can at least obtain 25 fps and once I have this working
 I will resend the patch-set as v3 so Laurent can review it and
 hopefully help us to fix the artifact on the video.

 Yes it must be something simple but not easy to spot.

 And to add even more confusion i've attached two patches: one is a
 port of two Deepthy patches, the other one just a board fix.

 Just replace patches 0017-18-19 with the attached 0001 patch, and
 after patch 0025 apply the attached 0002 patch.

 With these i can succesfully grab frames with yavta BUT i only get
 half-height frames. Disclaimer: i just made the patch monkey and gave
 it a run without a review so it could be anything.

My bad, i forgot a part about config_outlineoffset (ODDEVEN...), i
still have (different) half-green images though...

Side note: while making some tests i can confirm that the solution
adopted in Deepthy patches:

u32 syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
fid = syn_mode  ISPCCDC_SYN_MODE_FLDSTAT;
/* toggle the software maintained fid */

works as expected, i see fid switching correctly.

Enrico
--
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 3.2] cx23885 alsa cleaned and prepaired

[Igor M. Liplianin]

Hi Mauro and Steven,

It's been a long time since cx23885-alsa pull was requested.
To speed things up I created a git branch where I put the patches.
Some patches merged, like introduce then correct checkpatch compliance
or convert spinlock to mutex and back to spinlock, insert printk then remove 
printk as well.
Minor corrections from me was silently merged, for major I created additional 
patches.

Hope it helps.

The following changes since commit e30528854797f057aa6ffb6dc9f890e923c467fd:

  [media] it913x-fe changes to power up and down of tuner (2011-10-08 08:03:27 
-0300)

are available in the git repository at:
  git://linuxtv.org/liplianin/media_tree.git cx23885-alsa-clean-2

Igor M. Liplianin (2):
  cx23885: videobuf: Remove the videobuf_sg_dma_map/unmap functions
  cx25840-audio: fix missing state declaration

Mijhail Moreyra (6):
  cx23885: merge mijhail's header changes for alsa
  cx23885: ALSA support
  cx23885: core changes requireed for ALSA
  cx23885: add definitions for HVR1500 to support audio
  cx23885: correct the contrast, saturation and hue controls
  cx23885: hooks the alsa changes into the video subsystem

Steven Toth (31):
  cx23885: prepare the cx23885 makefile for alsa support
  cx23885: convert from snd_card_new() to snd_card_create()
  cx23885: convert call clients into subdevices
  cx23885: minor function renaming to ensure uniformity
  cx23885: setup the dma mapping for raw audio support
  cx23885: mute the audio during channel change
  cx23885: add two additional defines to simplify VBI register bitmap 
handling
  cx23885: initial support for VBI with the cx23885
  cx23885: initialize VBI support in the core, add IRQ support, register 
vbi device
  cx23885: minor printk cleanups and device registration
  cx25840: enable raw cc processing only for the cx23885 hardware
  cx23885: vbi line window adjustments
  cx23885: add vbi buffer formatting, window changes and video core changes
  cx23885: Ensure the VBI pixel format is established correctly.
  cx23885: ensure video is streaming before allowing vbi to stream
  cx23885: remove channel dump diagnostics when a vbi buffer times out.
  cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during 
streaming.
  cx23885: Name an internal i2c part and declare a bitfield by name
  cx25840: Enable support for non-tuner LR1/LR2 audio inputs
  cx23885: Enable audio line in support from the back panel
  cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use.
  cx23885: Initial support for the MPX-885 mini-card
  cx23885: fixes related to maximum number of inputs and range checking
  cx23885: add generic functions for dealing with audio input selection
  cx23885: hook the audio selection functions into the main driver
  cx23885: v4l2 api compliance, set the audioset field correctly
  cx23885: Removed a spurious function cx23885_set_scale().
  cx23885: Avoid stopping the risc engine during buffer timeout.
  cx23885: Avoid incorrect error handling and reporting
  cx23885: Stop the risc video fifo before reconfiguring it.
  cx23885: Allow the audio mux config to be specified on a per input basis.

 drivers/media/video/cx23885/Makefile|2 +-
 drivers/media/video/cx23885/cx23885-alsa.c  |  535 +++
 drivers/media/video/cx23885/cx23885-cards.c |   53 +++
 drivers/media/video/cx23885/cx23885-core.c  |   99 -
 drivers/media/video/cx23885/cx23885-i2c.c   |1 +
 drivers/media/video/cx23885/cx23885-reg.h   |3 +
 drivers/media/video/cx23885/cx23885-vbi.c   |   72 +++-
 drivers/media/video/cx23885/cx23885-video.c |  373 ---
 drivers/media/video/cx23885/cx23885.h   |   56 +++
 drivers/media/video/cx25840/cx25840-audio.c |   10 +-
 drivers/media/video/cx25840/cx25840-core.c  |   19 +
 11 files changed, 1144 insertions(+), 79 deletions(-)
 create mode 100644 drivers/media/video/cx23885/cx23885-alsa.c
--
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: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 4:17 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 2:46 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas
 Perfect, thank you Enrico. I will try this latter today and let you
 know. I'm sure I can get this working (with the ghosting effect of
 course) so you can at least obtain 25 fps and once I have this working
 I will resend the patch-set as v3 so Laurent can review it and
 hopefully help us to fix the artifact on the video.

 Yes it must be something simple but not easy to spot.

 And to add even more confusion i've attached two patches: one is a
 port of two Deepthy patches, the other one just a board fix.

 Just replace patches 0017-18-19 with the attached 0001 patch, and
 after patch 0025 apply the attached 0002 patch.

 With these i can succesfully grab frames with yavta BUT i only get
 half-height frames. Disclaimer: i just made the patch monkey and gave
 it a run without a review so it could be anything.

 My bad, i forgot a part about config_outlineoffset (ODDEVEN...), i
 still have (different) half-green images though...

 Side note: while making some tests i can confirm that the solution
 adopted in Deepthy patches:

 u32 syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
 fid = syn_mode  ISPCCDC_SYN_MODE_FLDSTAT;
 /* toggle the software maintained fid */

 works as expected, i see fid switching correctly.

Ok, i made it work. It was missing just the config_outlineoffset i
wrote before and a missing FLDMODE in SYNC registers.

Moreover it seems to me that the software-maintained field id
(interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
useless, i've tried to only use the FLDSTAT bit from isp register
(fid) in vd0_isr:

if (fid == 0) {
 restart = ccdc_isr_buffer(ccdc);
 goto done;
}

and it works. I've not tested very long frame sequences, only up to 16
frames. The only issue is that the first frame could be half-green
because a field is missing.

Enrico
--
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: omap3-isp status

[Javier Martinez Canillas]

On Mon, Oct 10, 2011 at 6:34 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 4:17 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 2:46 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas
 Perfect, thank you Enrico. I will try this latter today and let you
 know. I'm sure I can get this working (with the ghosting effect of
 course) so you can at least obtain 25 fps and once I have this working
 I will resend the patch-set as v3 so Laurent can review it and
 hopefully help us to fix the artifact on the video.

 Yes it must be something simple but not easy to spot.

 And to add even more confusion i've attached two patches: one is a
 port of two Deepthy patches, the other one just a board fix.

 Just replace patches 0017-18-19 with the attached 0001 patch, and
 after patch 0025 apply the attached 0002 patch.

 With these i can succesfully grab frames with yavta BUT i only get
 half-height frames. Disclaimer: i just made the patch monkey and gave
 it a run without a review so it could be anything.

 My bad, i forgot a part about config_outlineoffset (ODDEVEN...), i
 still have (different) half-green images though...

 Side note: while making some tests i can confirm that the solution
 adopted in Deepthy patches:

 u32 syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
 fid = syn_mode  ISPCCDC_SYN_MODE_FLDSTAT;
 /* toggle the software maintained fid */

 works as expected, i see fid switching correctly.

 Ok, i made it work. It was missing just the config_outlineoffset i
 wrote before and a missing FLDMODE in SYNC registers.


Great, do you get the ghosting effect or do you have a clean video?

 Moreover it seems to me that the software-maintained field id
 (interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
 useless, i've tried to only use the FLDSTAT bit from isp register
 (fid) in vd0_isr:

 if (fid == 0) {
     restart = ccdc_isr_buffer(ccdc);
     goto done;
 }

 and it works. I've not tested very long frame sequences, only up to 16
 frames. The only issue is that the first frame could be half-green
 because a field is missing.

 Enrico


Yes, when I tried Deepthy patches I realized that the fldstat was not
in sync with the frames, but probably I made something wrong.

We had the same problem with the hal-green frame. Our solution was to
synchronize the CCDC with the first even field looking at fdstat on
the VD1 interrupt handler and forcing to start processing from an ODD
sub-frame.

Best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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: omap3-isp status

[Enrico]

On Mon, Oct 10, 2011 at 6:53 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
 On Mon, Oct 10, 2011 at 6:34 PM, Enrico ebut...@users.berlios.de wrote:
 Ok, i made it work. It was missing just the config_outlineoffset i
 wrote before and a missing FLDMODE in SYNC registers.


 Great, do you get the ghosting effect or do you have a clean video?


Unfortunately i always get the ghosting effect. But this is something
we will try to fix later.


 Moreover it seems to me that the software-maintained field id
 (interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
 useless, i've tried to only use the FLDSTAT bit from isp register
 (fid) in vd0_isr:

 if (fid == 0) {
     restart = ccdc_isr_buffer(ccdc);
     goto done;
 }

 and it works. I've not tested very long frame sequences, only up to 16
 frames. The only issue is that the first frame could be half-green
 because a field is missing.


 Yes, when I tried Deepthy patches I realized that the fldstat was not
 in sync with the frames, but probably I made something wrong.


I had noticed the same thing, but now i tested it and it is ok, maybe
my fault too.


 We had the same problem with the hal-green frame. Our solution was to
 synchronize the CCDC with the first even field looking at fdstat on
 the VD1 interrupt handler and forcing to start processing from an ODD
 sub-frame.

Thinking more about it, it's ugly to have that half-green video frame
even if it's just one. It's better to keep your or Deepthy solution.

Enrico
--
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: media_tree daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Mon Oct 10 19:00:18 CEST 2011
git hash:e30528854797f057aa6ffb6dc9f890e923c467fd
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.0-4.slh.7-amd64

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: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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

UK Digital Switchover - w_scan results for Mendip transmitter

[Rupert Plumridge]

Hi

As part of the UK's digital switchover, it seems some of the pre-set
mux information is now out of date. I don't know the technicals here,
but for example adding channels to tvheadend git version now fails as
the mux information at my location is out of date.

I used w_scan to check the current situaiton and it gave me the
following for the Mendip Transmitter (since that is where my antennae
is pointed):

dumping lists (193 services)
#--
# file automatically generated by w_scan
#
#! w_scan 20101001 1 0 OFDM GB /w_scan
#--
# location and provider: UK - Mendip
# date (-mm-dd)    : 2011-10-09
# provided by (opt)    : prupert
#
# T[2] freq bw fec_hi fec_lo mod tm guard hi [# comment]
#--
T 47400 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 49000 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 49800 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 50600 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 51400 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 52200 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 53000 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 634167000 8MHz  2/3 NONE    QAM64   8k 1/32 NONE # Wales
T 69800 8MHz  3/4 NONE    QAM64   8k 1/32 NONE # Wales
T 65800 8MHz  2/3 NONE    QAM64   8k 1/32 NONE # Wales
T 642167000 8MHz  2/3 NONE    QAM64   8k 1/32 NONE
T 66600 8MHz  2/3 NONE    QAM64   8k 1/32 NONE
T 65000 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 69000 8MHz  2/3 NONE    QAM64   8k 1/32 NONE # West
T 79400 8MHz  2/3 NONE    QAM64   8k 1/32 NONE # West
T 73800 8MHz  2/3 NONE    QAM64   8k 1/32 NONE # West
T 72200 8MHz  2/3 NONE    QAM64   8k 1/32 NONE # West
T 75400 8MHz  2/3 NONE    QAM64   8k 1/32 NONE
T 70600 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 73000 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO # West
T 76200 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 78600 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO
T 84200 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO # West

The #West settings seem to work for me on tvheadend, ignore the #Wales
ones, unless you want all the welsh channels, which you don't.

Hope this is useful. It is all beyond me.
Rupert
--
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: omap3-isp status

[Javier Martinez Canillas]

On Mon, Oct 10, 2011 at 7:09 PM, Enrico ebut...@users.berlios.de wrote:
 On Mon, Oct 10, 2011 at 6:53 PM, Javier Martinez Canillas
 martinez.jav...@gmail.com wrote:
 On Mon, Oct 10, 2011 at 6:34 PM, Enrico ebut...@users.berlios.de wrote:
 Ok, i made it work. It was missing just the config_outlineoffset i
 wrote before and a missing FLDMODE in SYNC registers.


 Great, do you get the ghosting effect or do you have a clean video?


 Unfortunately i always get the ghosting effect. But this is something
 we will try to fix later.



Agree, we should try to get some code upstream to add interlaced video
and bt.656 support and fix the artifact later.

 Moreover it seems to me that the software-maintained field id
 (interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
 useless, i've tried to only use the FLDSTAT bit from isp register
 (fid) in vd0_isr:

 if (fid == 0) {
     restart = ccdc_isr_buffer(ccdc);
     goto done;
 }

 and it works. I've not tested very long frame sequences, only up to 16
 frames. The only issue is that the first frame could be half-green
 because a field is missing.


 Yes, when I tried Deepthy patches I realized that the fldstat was not
 in sync with the frames, but probably I made something wrong.


 I had noticed the same thing, but now i tested it and it is ok, maybe
 my fault too.


 We had the same problem with the hal-green frame. Our solution was to
 synchronize the CCDC with the first even field looking at fdstat on
 the VD1 interrupt handler and forcing to start processing from an ODD
 sub-frame.

 Thinking more about it, it's ugly to have that half-green video frame
 even if it's just one. It's better to keep your or Deepthy solution.

 Enrico


Well, that is something that can be fixed later also. Can you send to
the list your patches? So, Laurent, Sakari and others than know more
about the ISP can review it. I hope they can find the cause for the
artifact.

Thank you and best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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: UK Digital Switchover - w_scan results for Mendip transmitter

[Steve Kerrison]

Hi Rupert,

It looks like you're picking up more than just Mendip there; Mendip only
has 6 muxes: http://www.ukfree.tv/txdetail.php?a=ST564488

Unless it's announcing other frequencies? I'll do a rescan in MythTV and
see what happens.

As the switchover progresses and transmit powers are increased, however,
some antennae will pick up signals from more than one transmitter. So we
should be careful not to assume that the muxes we see are necessarily
from the transmitter we think we're pointing at!

Cheers,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Mon, 2011-10-10 at 18:49 +0100, Rupert Plumridge wrote:
 Hi
 
 As part of the UK's digital switchover, it seems some of the pre-set
 mux information is now out of date. I don't know the technicals here,
 but for example adding channels to tvheadend git version now fails as
 the mux information at my location is out of date.
 
 I used w_scan to check the current situaiton and it gave me the
 following for the Mendip Transmitter (since that is where my antennae
 is pointed):
 
 dumping lists (193 services)
 #--
 # file automatically generated by w_scan
 #
 #! w_scan 20101001 1 0 OFDM GB /w_scan
 #--
 # location and provider: UK - Mendip
 # date (-mm-dd): 2011-10-09
 # provided by (opt): prupert
 #
 # T[2] freq bw fec_hi fec_lo mod tm guard hi [# comment]
 #--
 T 47400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 49000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 49800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 50600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 51400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 52200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 53000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 634167000 8MHz  2/3 NONEQAM64   8k 1/32 NONE # Wales
 T 69800 8MHz  3/4 NONEQAM64   8k 1/32 NONE # Wales
 T 65800 8MHz  2/3 NONEQAM64   8k 1/32 NONE # Wales
 T 642167000 8MHz  2/3 NONEQAM64   8k 1/32 NONE
 T 66600 8MHz  2/3 NONEQAM64   8k 1/32 NONE
 T 65000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 69000 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 79400 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 73800 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 72200 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 75400 8MHz  2/3 NONEQAM64   8k 1/32 NONE
 T 70600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 73000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # West
 T 76200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 78600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 84200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # West
 
 The #West settings seem to work for me on tvheadend, ignore the #Wales
 ones, unless you want all the welsh channels, which you don't.
 
 Hope this is useful. It is all beyond me.
 Rupert
 --
 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

Cannot configure second Kodicom 4400R

[Allan Macdonald]

Hi to all,

I am new to this list.

I have been successfully using a Kodicom 4400R with zoneminder but I
wanted to expand so I bought a second card and installed it.  The
problem with this card is that I cannot seem to be able to get the
second card to work.  I tried using xawtv with the following command:

xawtv -d /dev/video1

The result is that I get images from /dev/video0

I also tried:

xawtv -d /dev/video4

with the same result.

I obviously don't understand what's going on.

I tried following the instructions here, to no avail:

http://www.zoneminder.com/wiki/index.php/Kodicom_4400r

I also looked here:

http://linuxtv.org/wiki/index.php/Kodicom_4400R

but, unfortunately, the following page does not explain what happens
with more than one card installed.

Here's my bttv.conf:

[code]
options bttv gbuffers=32 card=133,132,133,133,133,132,133,133 tuner=4
chroma_agc=1
[/code]

I have attached a dmesg output and an lsmod output.

I would greatly appreciate some help.  Many thanks in advance.

Regards,

Allan Macdonald
[1789815.240043] bttv7: unloading
[1789815.240543] bttv6: unloading
[1789815.241957] bttv5: unloading
[1789815.242712] bttv4: unloading
[1789815.243791] bttv3: unloading
[1789815.245141] bttv2: unloading
[1789815.245911] bttv1: unloading
[1789815.246630] bttv0: unloading
[1789825.453780] bttv: driver version 0.9.18 loaded
[1789825.453783] bttv: using 32 buffers with 2080k (520 pages) each for capture
[1789825.454079] bttv: Bt8xx card found (0).
[1789825.454098] bttv0: Bt878 (rev 17) at :04:0c.0, irq: 17, latency: 64, 
mmio: 0xfbefe000
[1789825.454194] bttv0: using: Kodicom 4400R (slave) [card=133,insmod option]
[1789825.454197] IRQ 17/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
[1789825.454226] bttv0: gpio: en=, out= in=00ff [init]
[1789825.454324] bttv0: tuner absent
[1789825.454930] bttv0: registered device video0
[1789825.455328] bttv0: registered device vbi0
[1789825.455351] bttv0: PLL: 28636363 = 35468950 .
[1789825.455735] bttv0: PLL: 28636363 = 35468950 .
[1789825.455759] bttv0: PLL: 28636363 = 35468950 .. ok
[1789825.477567] bttv: Bt8xx card found (1).
[1789825.477590] bttv1: Bt878 (rev 17) at :04:0d.0, irq: 18, latency: 64, 
mmio: 0xfbefc000
[1789825.477748] bttv1: using: Kodicom 4400R (master) [card=132,insmod option]
[1789825.477751] IRQ 18/bttv1: IRQF_DISABLED is not guaranteed on shared IRQs
[1789825.477787] bttv1: gpio: en=, out= in=00ff [init]
[1789825.477953] bttv1: tuner absent
[1789825.478309] bttv1: registered device video1
[1789825.478408] bttv1: registered device vbi1
[1789825.478430] bttv1: PLL: 28636363 = 35468950 .
[1789825.479521] bttv1: PLL: 28636363 = 35468950 .
[1789825.479788] bttv1: PLL: 28636363 = 35468950 . ok
[1789857.668538] bttv: Bt8xx card found (2).
[1789857.668558] bttv2: Bt878 (rev 17) at :04:0e.0, irq: 19, latency: 64, 
mmio: 0xfbefa000
[1789857.668702] bttv2: using: Kodicom 4400R (slave) [card=133,insmod option]
[1789857.668705] IRQ 19/bttv2: IRQF_DISABLED is not guaranteed on shared IRQs
[1789857.668742] bttv2: gpio: en=, out= in=00ff [init]
[1789857.668804] bttv2: tuner absent
[1789857.668893] bttv2: registered device video2
[1789857.668923] bttv2: registered device vbi2
[1789857.668951] bttv2: PLL: 28636363 = 35468950 .
[1789857.670200] bttv2: PLL: 28636363 = 35468950 .
[1789857.670643] bttv2: PLL: 28636363 = 35468950 .. ok
[1789889.860537] bttv: Bt8xx card found (3).
[1789889.860558] bttv3: Bt878 (rev 17) at :04:0f.0, irq: 16, latency: 64, 
mmio: 0xfbef8000
[1789889.860702] bttv3: using: Kodicom 4400R (slave) [card=133,insmod option]
[1789889.860705] IRQ 16/bttv3: IRQF_DISABLED is not guaranteed on shared IRQs
[1789889.860742] bttv3: gpio: en=, out= in=00ff [init]
[1789889.860807] bttv3: tuner absent
[1789889.860899] bttv3: registered device video3
[1789889.860935] bttv3: registered device vbi3
[1789889.860960] bttv3: PLL: 28636363 = 35468950 .
[1789889.862152] bttv3: PLL: 28636363 = 35468950 .
[1789889.862871] bttv3: PLL: 28636363 = 35468950 .. ok
[1789922.052539] bttv: Bt8xx card found (4).
[1789922.052560] bttv4: Bt878 (rev 17) at :05:0c.0, irq: 18, latency: 64, 
mmio: 0xfbffe000
[1789922.052704] bttv4: using: Kodicom 4400R (slave) [card=133,insmod option]
[1789922.052707] IRQ 18/bttv4: IRQF_DISABLED is not guaranteed on shared IRQs
[1789922.052737] bttv4: gpio: en=, out= in=00ff [init]
[1789922.052801] bttv4: tuner absent
[1789922.052894] bttv4: registered device video4
[1789922.052926] bttv4: registered device vbi4
[1789922.052947] bttv4: PLL: 28636363 = 35468950 .
[1789922.054120] bttv4: PLL: 28636363 = 35468950 .
[1789922.054816] bttv4: PLL: 28636363 = 35468950 .. ok
[1789922.087532] bttv: Bt8xx card found (5).
[1789922.087550] bttv5: Bt878 (rev 17) at :05:0d.0, irq: 19, latency: 64, 
mmio: 0xfbffc000
[1789922.087695] bttv5: using: Kodicom 4400R (master) [card=132,insmod option]
[1789922.087699] IRQ 

Re: Cypress EZ-USB FX2 firmware development

[Antti Palosaari]

On 10/06/2011 04:10 PM, Antti Palosaari wrote:

On 10/06/2011 03:47 PM, Johannes Stezenbach wrote:

On Tue, Oct 04, 2011 at 11:29:01PM +0200, Johannes Stezenbach wrote:

On Tue, Oct 04, 2011 at 10:43:59PM +0300, Antti Palosaari wrote:

I would like to made own firmware for Cypress FX2 based DVB device.
Is there any sample to look example?


http://linuxtv.org/cgi-bin/viewvc.cgi/dvb-hw/dvbusb-fx2/termini/


PS: If you haven't found it already, there is also fx2lib:
https://github.com/mulicheng/fx2lib
http://sourceforge.net/projects/fx2lib/

Johannes


Thank you! I already looked those termini project files and it was kinda
jackpot. Much more than I ever imagined. I will try to compile it next
weekend and upload to my FX2 device to see if I can get at least control
for I2C-bus.


After very long hack sessions during weekend I got it working. I2C was 
easy stuff, streaming video was more challenging.


Antti
--
http://palosaari.fi/
--
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] af9013 Extended monitoring in set_frontend.

[Antti Palosaari]

On 10/08/2011 11:05 PM, Jason Hecker wrote:

Which kernels are you all running?


2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04)


Have you tried other USB-cable or connect it directly to the mobo USB port.

I just used one af9015 + 2x mxl5007t and got some streaming corruptions. 
I was WTF. Switched to af9015 + 2x mxl5005s since it is device I usually 
have used. Still errors. Then I commented out remote controller polling 
and all status polling from drivers. Still some stream corruptions. 
Finally I realized I have other USB-cable than normally. Plugged device 
directly to the mobo USB and now both tuners are streaming same time 
without errors.


Antti


--
http://palosaari.fi/
--
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: Cannot configure second Kodicom 4400R

[Patrick Dickey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there Allan,

I'm not familiar with the card (so you'll want to defer to someone else
if their answer differs from mine).  It looks like video0 and video1 are
assigned to the first card, and video2 and video3 are assigned to the
second card.  So, you might want to try

xawtv -d /dev/video2'

or

xawtv -d /dev/video3

and see if one of those uses the second card (you could try video4 or
video5 also, since they're assigned to cards).

Have a great day:)
Patrick.

On 10/10/2011 01:45 PM, Allan Macdonald wrote:
 Hi to all,
 
 I am new to this list.
 
 I have been successfully using a Kodicom 4400R with zoneminder but I
 wanted to expand so I bought a second card and installed it.  The
 problem with this card is that I cannot seem to be able to get the
 second card to work.  I tried using xawtv with the following command:
 
 xawtv -d /dev/video1
 
 The result is that I get images from /dev/video0
 
 I also tried:
 
 xawtv -d /dev/video4
 
 with the same result.
 
 I obviously don't understand what's going on.
 
 I tried following the instructions here, to no avail:
 
 http://www.zoneminder.com/wiki/index.php/Kodicom_4400r
 
 I also looked here:
 
 http://linuxtv.org/wiki/index.php/Kodicom_4400R
 
 but, unfortunately, the following page does not explain what happens
 with more than one card installed.
 
 Here's my bttv.conf:
 
 [code]
 options bttv gbuffers=32 card=133,132,133,133,133,132,133,133 tuner=4
 chroma_agc=1
 [/code]
 
 I have attached a dmesg output and an lsmod output.
 
 I would greatly appreciate some help.  Many thanks in advance.
 
 Regards,
 
 Allan Macdonald

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6TUuUACgkQMp6rvjb3CAT9VwCfTyqoIrlUS+IszJIQWpyYD7j9
NlsAnRFpxHKQT+p7Hem+D2SpUWiDkxu2
=l16i
-END PGP SIGNATURE-
--
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] af9013 Extended monitoring in set_frontend.

[Malcolm Priestley]

On Mon, 2011-10-10 at 22:31 +0300, Antti Palosaari wrote:
 On 10/08/2011 11:05 PM, Jason Hecker wrote:
  Which kernels are you all running?
 
  2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04)
 
 Have you tried other USB-cable or connect it directly to the mobo USB port.
 
 I just used one af9015 + 2x mxl5007t and got some streaming corruptions. 
 I was WTF. Switched to af9015 + 2x mxl5005s since it is device I usually 
 have used. Still errors. Then I commented out remote controller polling 
 and all status polling from drivers. Still some stream corruptions. 
 Finally I realized I have other USB-cable than normally. Plugged device 
 directly to the mobo USB and now both tuners are streaming same time 
 without errors.

I have just been testing af9015s both 399U and single, along with other
devices on Mythbuntu 11.04 on 2.6.38-11 and getting the same corruption.

Playing with Kaffeine or Mplayer all the devices are fine on the same
system.

This is very strange!

At the moment, I am going step by step what Myth TV is sending to the
devices.

Regards 

Malcolm

--
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

saa7164[0]: can't get MMIO memory @ 0x0 or 0x0

[Lyle Sigurdson]

Hi all, and thanks for all your work.  But, I'm having a problem.

Tuner card: Hauppauge! HVR-2250
Mainboard: MSNV-939
Distro: Slackware64 13.1 (kernel 2.6.33.4)

When I modprobe saa7164:
bowman kernel: saa7164[0]: can't get MMIO memory @ 0x0 or 0x0
bowman kernel: CORE saa7164[0] No more PCIe resources for subsystem: 0070:8851
bowman kernel: saa7164: probe of :04:00.0 failed with   error -22

It turns out that pci_resource_start and pci_resource_len are both returning 
null.

What could be the cause of this?  Is there a solution? 

   Lyle.
--
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] af9013 Extended monitoring in set_frontend.

[Jason Hecker]

 Playing with Kaffeine or Mplayer all the devices are fine on the same
 system.

Right, admittedly most of my testing has been done with MythTV.  I
recall about a month ago I could also get corruption with mplayer.

 At the moment, I am going step by step what Myth TV is sending to the
 devices.

Great.  If you want I can replicate your tests here to see what I get.

Antti, my AF9015 chips are integrated on PCI so I can't swap cables
(alas, if only this was my problem!)

Cheers
Jason
--
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: [3.1-rc9] kernel tried to execute NX-protected... w/ page fault

[Jiri Kosina]

On Sat, 8 Oct 2011, Matthias Dahl wrote:

  First, please inline the text into your e-mails next time, it's much more 
  convenient to look at them as such rather than having to process gzipped 
  attachments.
 
 Ok, will do. Just thought because of the text size this was inappropriate  or
 would cause trouble with some restricitions of the list.
 
  Is it nvidia gfx driver? If so, does the problem appear also with it not 
  loaded?
 
 Yes, nvidia 285.05.09 _but_ I just went through  the  trouble to  get nouveau
 up and running and tested with that and I ran into the same problems as well,
 so this is not related to the nvidia blob.
 
 Here three more incidents.   The first one again with the nvidia blob and the
 following two with nouveau. The last one caused a partial hang up btw.  Don't
 mind the tainted mark on the last one.By accident I modprobe'd the nvidia
 blob which simply said it found no devices because nouveau was already active
 and did nothing (exited).
 
 Last but not least, I am now on 3.0.6 and I do not see anything alike at all.

The BUGs below seem different to what you originally reported (execution 
attempt in NX-protected area).

I believe the ones below would be interesting for V4L people. Adding some 
more CCs.

 
 [ 7353.662147] BUG: unable to handle kernel paging request at a00d7040
 [ 7353.662152] IP: [a00d7040] 0xa00d703f
 [ 7353.662159] PGD 1561067 PUD 1565063 PMD 21cf28067 PTE 0
 [ 7353.662163] Oops: 0010 [#1] PREEMPT SMP 
 [ 7353.662166] CPU 1 
 [ 7353.662167] Modules linked in: nvidia(P) it87 hwmon_vid coretemp xt_time 
 xt_connlimit xt_realm xt_addrtype iptable_raw xt_comment xt_policy ipt_ULOG 
 ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn 
 ipt_ah nf_nat_tftp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc 
 nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda 
 nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp 
 nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink 
 nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc 
 nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_recent xt_pkttype xt_owner 
 xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit 
 xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp 
 xt_conntrack xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat 
 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink 
 iptable_filter ip_tables x_tables snd_pcm_oss snd_mixer_oss xts g
 f1
  28mul usblp isl6421 cx24116 cx88_vp3054_i2c videobuf_dvb dvb_core 
 snd_hda_codec_hdmi rc_hauppauge tuner cx8800 cx8802 cx88xx ir_lirc_codec 
 lirc_dev snd_hda_codec_realtek ir_mce_kbd_decoder ir_sony_decoder 
 ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder snd_hda_intel 
 rc_core snd_hda_codec i2c_algo_bit snd_virtuoso snd_oxygen_lib tveeprom 
 snd_hwdep v4l2_common snd_pcm videodev v4l2_compat_ioctl32 snd_mpu401_uart 
 btcx_risc snd_rawmidi videobuf_dma_sg snd_timer snd videobuf_core joydev 
 evdev xpad snd_page_alloc soundcore fuse ext2 mbcache dm_snapshot dm_mirror 
 dm_region_hash dm_log scsi_wait_scan usb_storage
 [ 7353.662246] 
 [ 7353.662249] Pid: 20362, comm: knotify4 Tainted: P3.1.0-rc9 #1 
 Gigabyte Technology Co., Ltd. P55-UD5/P55-UD5
 [ 7353.662253] RIP: 0010:[a00d7040]  [a00d7040] 
 0xa00d703f
 [ 7353.662261] RSP: 0018:880100c7de70  EFLAGS: 00010282
 [ 7353.662262] RAX: a00d7040 RBX: 88021d9e7000 RCX: 
 0048e1c1
 [ 7353.662265] RDX: 0048e1b9 RSI: 0001 RDI: 
 88021d119000
 [ 7353.662267] RBP: 880100c7dea8 R08:  R09: 
 
 [ 7353.662269] R10: 8801eaba5310 R11: 0246 R12: 
 8801fe815800
 [ 7353.662271] R13: 8801eaba5300 R14: 88021d9e7218 R15: 
 88021d9e7070
 [ 7353.662274] FS:  7f8123191780() GS:880227c4() 
 knlGS:
 [ 7353.662276] CS:  0010 DS:  ES:  CR0: 80050033
 [ 7353.662278] CR2: a00d7040 CR3: 0001c0c8b000 CR4: 
 06e0
 [ 7353.662281] DR0:  DR1:  DR2: 
 
 [ 7353.662283] DR3:  DR6: 0ff0 DR7: 
 0400
 [ 7353.662286] Process knotify4 (pid: 20362, threadinfo 880100c7c000, 
 task 88021d884e00)
 [ 7353.662287] Stack:
 [ 7353.662289]  a00bfc6a 88020a3accf0 88021d112000 
 8801eaba5300
 [ 7353.662293]  8802007742a8 880201c64d80 88021d16cd00 
 880100c7dec8
 [ 7353.662296]  a01171eb 8801eaba5300 0008 
 880100c7df18
 [ 7353.662300] Call Trace:
 [ 7353.662307]  [a00bfc6a] ? video_release+0xda/0x1e0 [cx8800]
 [ 7353.662315]  [a01171eb] v4l2_release+0x4b/0x70 [videodev]
 [ 7353.662320]  [810d81e2] fput+0xd2/0x200
 [ 7353.662324]  [810d4a21] filp_close+0x61/0x90
 [ 7353.662327]  

Re: saa7164[0]: can't get MMIO memory @ 0x0 or 0x0

[Andy Walls]

Lyle Sigurdson l...@sent.com wrote:

Hi all, and thanks for all your work.  But, I'm having a problem.

Tuner card: Hauppauge! HVR-2250
Mainboard: MSNV-939
Distro: Slackware64 13.1 (kernel 2.6.33.4)

When I modprobe saa7164:
bowman kernel: saa7164[0]: can't get MMIO memory @ 0x0 or 0x0
bowman kernel: CORE saa7164[0] No more PCIe resources for subsystem:
0070:8851
bowman kernel: saa7164: probe of :04:00.0 failed with  error -22

It turns out that pci_resource_start and pci_resource_len are both
returning 
null.

What could be the cause of this?  Is there a solution? 

   Lyle.   
--
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

Try upping your kernel's vmalloc space

1. cat /proc/meminfo | grep -i vmalloc

Observe the vmalloctotal you have and convert from kB to MB.

2. Add a vmalloc=NNN to your kernel commandline on boot.  NNN should be the 
number of megabytes of address space to allow.  Try 64 or 128 megabytes more 
than your current setting.

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: [PATCHv16 0/9] Contiguous Memory Allocator

[Andrew Morton]

On Fri, 7 Oct 2011 18:27:06 +0200
Arnd Bergmann a...@arndb.de wrote:

 On Thursday 06 October 2011, Marek Szyprowski wrote:
  Once again I decided to post an updated version of the Contiguous Memory
  Allocator patches.
  
  This version provides mainly a bugfix for a very rare issue that might
  have changed migration type of the CMA page blocks resulting in dropping
  CMA features from the affected page block and causing memory allocation
  to fail. Also the issue reported by Dave Hansen has been fixed.
  
  This version also introduces basic support for x86 architecture, what
  allows wide testing on KVM/QEMU emulators and all common x86 boxes. I
  hope this will result in wider testing, comments and easier merging to
  mainline.
 
 Hi Marek,
 
 I think we need to finally get this into linux-next now, to get some
 broader testing. Having the x86 patch definitely helps here becauses
 it potentially exposes the code to many more testers.
 
 IMHO it would be good to merge the entire series into 3.2, since
 the ARM portion fixes an important bug (double mapping of memory
 ranges with conflicting attributes) that we've lived with for far
 too long, but it really depends on how everyone sees the risk
 for regressions here. If something breaks in unfixable ways before
 the 3.2 release, we can always revert the patches and have another
 try later.
 
 It's also not clear how we should merge it. Ideally the first bunch
 would go through linux-mm, and the architecture specific patches
 through the respective architecture trees, but there is an obvious
 inderdependency between these sets.
 
 Russell, Andrew, are you both comfortable with putting the entire
 set into linux-mm to solve this? Do you see this as 3.2 or rather
 as 3.3 material?
 

Russell's going to hate me, but...

I do know that he had substantial objections to at least earlier
versions of this, and he is a guy who knows of what he speaks.

So I would want to get a nod from rmk on this work before proceeding. 
If that nod isn't available then let's please identify the issues and
see what we can do about them.

--
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