Re: [PATCH] media: mx2_camera: Add YUYV output format.
Hi Fabio, On 7 June 2012 19:35, Fabio Estevam wrote: > Hi Javier, > > On Thu, Jun 7, 2012 at 5:30 AM, javier Martin > wrote: > >> As i stated, the driver is still in an early development stage, it >> doesn't do anything useful yet. But this is the public git repository >> if you want to take a look: >> >> git repo: https://github.com/jmartinc/video_visstrim.git >> branch: mx27-codadx6 > > Thanks, I will take a look at your tree when I am back to the office next > week. > > I also see that Linaro's tree has support for VPU for mx5/mx6: > http://git.linaro.org/gitweb?p=landing-teams/working/freescale/kernel.git;a=summary > > ,so we should probably think in unifying it with mx27 support there too. > >> >> FYI we are only interested on adding support for the encoding path of >> the VPU, but we are trying our best to make it modular (as it is done >> in Samsung's [1]), so that anyone can add decoding support later. > > Ok, sounds good. > >> By the way, you work for Freescale, don't you? > > Yes, correct. > >> We have a couple of issues with the i.MX27 VPU: >> >> 1- Firmware for the VPU is provided as a table of binary values inside >> a source file which is licensed as GPL, however software is packaged >> in a .tar.gz file that is marked as NDA. Do we have the right to >> distribute this firmware with our products? To address this issue it would be great if you, as a Freescale employee, could send VPU firmware binary file to linux-firmware with a LICENSE. file as well: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree >> 2- There is a BUG in the firmware that marks P frames as IDR when it >> should only be done to I frames. Would it be possible to have access >> to the source code of the firmware in order to fix that problem? > > I will need to check this next week when I am back to the office. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-uvc-devel] [RFC] Media controller entity information ioctl [was "Re: [patch] suggestion for media framework"]
Hi Robert, On Monday 04 June 2012 10:11:33 Robert Krakora wrote: > When you say "static" you mean items that are "well known" by the system by > reading a registry at initialization? By static I mean items that are initialized at driver initialization time and not modified afterwards. I don't think we should support adding/removing items at runtime, at least in the first version. > When a new device exposes functionality that necessitates the creation of a > new "static" item then how does the registry get updated to reflect this or > am I misunderstanding? Item types should be defined in a kernel header and documented. If a driver needs a new item types, the driver developer should add the new type to the header and document it. -- 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] make VIDEO_MEDIA depends on DVB_CORE only (removing depends VIDEO_DEV)
I think the root cause is VIDEO_MEDIA depending on VIDEO_DEV or DVB_CORE; since MEDIA_TUNER is depending on VIDEO_MEDIA; I have VIDEO_DEV but not DVB_CORE, hence should be no VIDEO_MEDIA, config MEDIA_TUNER tristate default VIDEO_MEDIA && I2C depends on VIDEO_MEDIA && I2C diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 9575db4..1b35dae 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -99,7 +99,7 @@ config DVB_NET config VIDEO_MEDIA tristate - default (DVB_CORE && (VIDEO_DEV = n)) || (VIDEO_DEV && (DVB_CORE = n)) || (DVB_CORE && VIDEO_DEV) + default DVB_CORE comment "Multimedia drivers" On Thu, Jun 7, 2012 at 4:09 PM, VDR User wrote: > On Thu, Jun 7, 2012 at 2:53 PM, cheng renquan wrote: >> till recently I found that also chosen those media tuner modules, >> >> $ grep MEDIA_TUNER /boot/config >> CONFIG_MEDIA_TUNER=m >> # CONFIG_MEDIA_TUNER_CUSTOMISE is not set >> CONFIG_MEDIA_TUNER_SIMPLE=m >> CONFIG_MEDIA_TUNER_TDA8290=m >> CONFIG_MEDIA_TUNER_TDA827X=m >> CONFIG_MEDIA_TUNER_TDA18271=m >> CONFIG_MEDIA_TUNER_TDA9887=m >> CONFIG_MEDIA_TUNER_TEA5761=m >> CONFIG_MEDIA_TUNER_TEA5767=m >> CONFIG_MEDIA_TUNER_MT20XX=m >> CONFIG_MEDIA_TUNER_XC2028=m >> CONFIG_MEDIA_TUNER_XC5000=m >> CONFIG_MEDIA_TUNER_XC4000=m >> CONFIG_MEDIA_TUNER_MC44S803=m >> >> as I understand, MEDIA_TUNER is for some tv adapters but I don't have >> such hardware, >> to disable them I need to enable MEDIA_TUNER_CUSTOMISE, then >> a menu "Customize TV tuners" becomes visible then I need to enter that >> menu and disable all the tuners one-by-one; >> this looks not convenient, > > I hate that too so you're not alone. I've just gotten into the habit > of having to manually disabling everything I don't need as opposed to > only needing to enable what I do need. :\ -- 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: hdpvr lockup with audio dropouts
On Thu, Jun 7, 2012 at 7:53 PM, wrote: > Apparently there is a known issue where the HD-PVR cannot handle the loss of > audio signal over SPDIF while recording. If this happens, the unit locks up > requiring it to be power cycled before it can be used again. This behavior > can easily be reproduced by pulling the SPDIF cable during recording. My > question is this: are there any changes that could be made to the hdpvr > driver that would make it more tolerant of brief audio dropouts? Does it do this under Windows? If it does, then call Hauppauge and get them to fix it (and if that results in a firmware fix, then it will help Linux too). If it works under Windows, then we know it's some sort of driver issue which would be needed. It's always good when it's readily reproducible. :-) Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hdpvr lockup with audio dropouts
Apparently there is a known issue where the HD-PVR cannot handle the loss of audio signal over SPDIF while recording. If this happens, the unit locks up requiring it to be power cycled before it can be used again. This behavior can easily be reproduced by pulling the SPDIF cable during recording. My question is this: are there any changes that could be made to the hdpvr driver that would make it more tolerant of brief audio dropouts? -- 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: what are the media tuners / can we make them not default selected?
On Thu, Jun 7, 2012 at 2:53 PM, cheng renquan wrote: > till recently I found that also chosen those media tuner modules, > > $ grep MEDIA_TUNER /boot/config > CONFIG_MEDIA_TUNER=m > # CONFIG_MEDIA_TUNER_CUSTOMISE is not set > CONFIG_MEDIA_TUNER_SIMPLE=m > CONFIG_MEDIA_TUNER_TDA8290=m > CONFIG_MEDIA_TUNER_TDA827X=m > CONFIG_MEDIA_TUNER_TDA18271=m > CONFIG_MEDIA_TUNER_TDA9887=m > CONFIG_MEDIA_TUNER_TEA5761=m > CONFIG_MEDIA_TUNER_TEA5767=m > CONFIG_MEDIA_TUNER_MT20XX=m > CONFIG_MEDIA_TUNER_XC2028=m > CONFIG_MEDIA_TUNER_XC5000=m > CONFIG_MEDIA_TUNER_XC4000=m > CONFIG_MEDIA_TUNER_MC44S803=m > > as I understand, MEDIA_TUNER is for some tv adapters but I don't have > such hardware, > to disable them I need to enable MEDIA_TUNER_CUSTOMISE, then > a menu "Customize TV tuners" becomes visible then I need to enter that > menu and disable all the tuners one-by-one; > this looks not convenient, I hate that too so you're not alone. I've just gotten into the habit of having to manually disabling everything I don't need as opposed to only needing to enable what I do need. :\ -- 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
what are the media tuners / can we make them not default selected?
when I was compiling default minimum kernel for my laptop, I started with "make x86_64_defconfig" then menuconfig to enable only a few kernel features or device drivers those I have, including the USB_VIDEO_CLASS for webcam; with this I enabled VIDEO_DEV but disable DVB_CORE; till recently I found that also chosen those media tuner modules, $ grep MEDIA_TUNER /boot/config CONFIG_MEDIA_TUNER=m # CONFIG_MEDIA_TUNER_CUSTOMISE is not set CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_XC4000=m CONFIG_MEDIA_TUNER_MC44S803=m as I understand, MEDIA_TUNER is for some tv adapters but I don't have such hardware, to disable them I need to enable MEDIA_TUNER_CUSTOMISE, then a menu "Customize TV tuners" becomes visible then I need to enter that menu and disable all the tuners one-by-one; this looks not convenient, config MEDIA_TUNER tristate default VIDEO_MEDIA && I2C depends on VIDEO_MEDIA && I2C select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC4000 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MT20XX if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_TDA8290 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_TEA5761 if !MEDIA_TUNER_CUSTOMISE && EXPERIMENTAL select MEDIA_TUNER_TEA5767 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_SIMPLE if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_TDA9887 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE menu "Customize TV tuners" visible if MEDIA_TUNER_CUSTOMISE -- cheng renquan (程任全) -- 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
[Q] Why is it needed to add an alsa module to v4l audio capture devices?
Hi all, (I hope this is a genuine question, and I'm not avoiding my own homework here.) I'm trying to support the audio part of the stk1160 usb bridge (similar to em28xx). Currently, the snd-usb-audio module is being loaded when I physically plug my device, but I can't seem to capture any sound with vlc. I still have to research and work a lot to understand the connection between my device and alsa, and altough I could write a working module similar to em28xx-alsa.ko, I still can't figure out why do I need to write one in the first place. Why is this module suffficient for gspca microphone devices (gspca, to name one) and why is a new alsa driver needed for em28xx (or stk1160)? Hope my question is clear enough, Thanks in advance, Ezequiel. -- 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
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:Thu Jun 7 19:00:17 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.3-6.slh.2-amd64 linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS 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-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-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-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Synchronization framework
Hey Erik, Op 07-06-12 19:35, Erik Gilling schreef: > On Thu, Jun 7, 2012 at 1:55 AM, Maarten Lankhorst > wrote: >> I haven't looked at intel and amd, but from a quick glance >> it seems like they already implement fencing too, so just >> some way to synch up the fences on shared buffers seems >> like it could benefit all graphics drivers and the whole >> userspace synching could be done away with entirely. > It's important to have some level of userspace API so that GPU > generated graphics can participate in the graphics pipeline. Think of > the case where you have a software video codec streaming textures into > the GPU. It needs to know when the GPU is done with those textures so > it can reuse the buffer. > In the graphics case this problem already has to be handled without dma-buf, so adding any extra synchronization api for userspace that is only used when the bo is shared is a waste. I do agree you need some way to synch userspace though, but I think adding a new api for userspace is not the way to go. Cheers, Maarten PS: re-added cc's that seem to have fallen off from your mail. -- 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] media: mx2_camera: Add YUYV output format.
Hi Javier, On Thu, Jun 7, 2012 at 5:30 AM, javier Martin wrote: > As i stated, the driver is still in an early development stage, it > doesn't do anything useful yet. But this is the public git repository > if you want to take a look: > > git repo: https://github.com/jmartinc/video_visstrim.git > branch: mx27-codadx6 Thanks, I will take a look at your tree when I am back to the office next week. I also see that Linaro's tree has support for VPU for mx5/mx6: http://git.linaro.org/gitweb?p=landing-teams/working/freescale/kernel.git;a=summary ,so we should probably think in unifying it with mx27 support there too. > > FYI we are only interested on adding support for the encoding path of > the VPU, but we are trying our best to make it modular (as it is done > in Samsung's [1]), so that anyone can add decoding support later. Ok, sounds good. > By the way, you work for Freescale, don't you? Yes, correct. > We have a couple of issues with the i.MX27 VPU: > > 1- Firmware for the VPU is provided as a table of binary values inside > a source file which is licensed as GPL, however software is packaged > in a .tar.gz file that is marked as NDA. Do we have the right to > distribute this firmware with our products? > 2- There is a BUG in the firmware that marks P frames as IDR when it > should only be done to I frames. Would it be possible to have access > to the source code of the firmware in order to fix that problem? I will need to check this next week when I am back to the office. Thanks, Fabio Estevam -- 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 for v3.5] And another regression :-(
Now query/enum_dv_timings finally work again. The timings API patches and the core ioctl changes clearly sailed right past each other without realizing that both needed to adapt to the other. Regards, Hans Signed-off-by: Hans Verkuil diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 5ccbd46..1500208 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -679,6 +679,8 @@ static void determine_valid_ioctls(struct video_device *vdev) SET_VALID_IOCTL(ops, VIDIOC_QUERY_DV_PRESET, vidioc_query_dv_preset); SET_VALID_IOCTL(ops, VIDIOC_S_DV_TIMINGS, vidioc_s_dv_timings); SET_VALID_IOCTL(ops, VIDIOC_G_DV_TIMINGS, vidioc_g_dv_timings); + SET_VALID_IOCTL(ops, VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings); + SET_VALID_IOCTL(ops, VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings); /* yes, really vidioc_subscribe_event */ SET_VALID_IOCTL(ops, VIDIOC_DQEVENT, vidioc_subscribe_event); SET_VALID_IOCTL(ops, VIDIOC_SUBSCRIBE_EVENT, vidioc_subscribe_event); -- 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 for v3.5] Fix regression in ioctl numbering
Yuck. The VIDIOC_(TRY_)DECODER_CMD ioctls already had ioctl numbers 96 and 97,
and after merging the timings API I forgot to continue numbering from 98. So
now we have two ioctls with number 96 and two with 97.
With the new table-driver ioctl handling in v4l2-ioctl.c it is essential that
each ioctl has its own unique number, so let's fix this quickly for 3.5.
Regards,
Hans
Signed-off-by: Hans Verkuil
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 370d111..2039c5d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2640,9 +2640,9 @@ struct v4l2_create_buffers {
/* Experimental, these three ioctls may change over the next couple of kernel
versions. */
-#define VIDIOC_ENUM_DV_TIMINGS _IOWR('V', 96, struct v4l2_enum_dv_timings)
-#define VIDIOC_QUERY_DV_TIMINGS _IOR('V', 97, struct v4l2_dv_timings)
-#define VIDIOC_DV_TIMINGS_CAP _IOWR('V', 98, struct v4l2_dv_timings_cap)
+#define VIDIOC_ENUM_DV_TIMINGS _IOWR('V', 98, struct v4l2_enum_dv_timings)
+#define VIDIOC_QUERY_DV_TIMINGS _IOR('V', 99, struct v4l2_dv_timings)
+#define VIDIOC_DV_TIMINGS_CAP _IOWR('V', 100, struct v4l2_dv_timings_cap)
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
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 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers
Hello Tomasz,
On 06/07/2012 06:06 AM, Laurent Pinchart wrote:
Hi Tomasz,
On Wednesday 06 June 2012 13:56:42 Tomasz Stanislawski wrote:
On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
This patch adds the setup of sglist list for MMAP buffers.
It is needed for buffer exporting via DMABUF mechanism.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 70 +-
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index 52b4f59..ae656be
100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
[snip]
+static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
+ struct page **pages, unsigned int n_pages)
+{
+ unsigned int i;
+ unsigned long pfn;
+ struct vm_area_struct vma = {
+ .vm_flags = VM_IO | VM_PFNMAP,
+ .vm_mm = current->mm,
+ };
+
+ for (i = 0; i< n_pages; ++i, kaddr += PAGE_SIZE) {
The follow_pfn() kerneldoc mentions that it looks up a PFN for a user
address. The only users I've found in the kernel sources pass a user
address. Is it legal to use it for kernel addresses ?
It is not completely legal :). As I understand the mm code, the follow_pfn
works only for IO/PFN mappings. This is the typical case (every case?) of
mappings created by dma_alloc_coherent.
In order to make this function work for a kernel pointer, one has to create
an artificial VMA that has IO/PFN bits on.
This solution is a hack-around for dma_get_pages (aka dma_get_sgtable). This
way the dependency on dma_get_pages was broken giving a small hope of
merging vb2 exporting.
Marek prepared a patchset 'ARM: DMA-mapping: new extensions for buffer
sharing' that adds dma buffers with no kernel mappings and dma_get_sgtable
function.
However this patchset is still in a RFC state.
That's totally understood :-) I'm fine with keeping the hack for now until the
dma_get_sgtable() gets in a usable/mergeable state, please just mention it in
the code with something like
/* HACK: This is a temporary workaround until the dma_get_sgtable() function
becomes available. */
I have prepared a patch that removes vb2_dc_kaddr_to_pages and substitutes
it with dma_get_pages. It will become a part of vb2-exporter patches just
after dma_get_sgtable is merged (or at least acked by major maintainers).
The above function call (because of follow_pfn) doesn't succeed for all
the allocated pages. Hence I created a patch(attached) which is based on
[1] series. One can apply it for using your present patch-set in the
meantime.
Regards,
Subash
[1] http://www.spinics.net/lists/kernel/msg1343092.html
>From f9b2eace2eef0038a1830e5e6dd55f3bb6017e1a Mon Sep 17 00:00:00 2001
From: Subash Patel
Date: Thu, 7 Jun 2012 19:49:10 +0530
Subject: [PATCH] v4l2: vb2: use dma_get_sgtable
This is patch to remove vb2_dc_kaddr_to_pages() function with dma_get_sgtable()
in the patch set posted by Tomasz. It was observed that the former function
fails to get the pages, as follow_pfn() can fail for remapped kernel va provided
by the dma-mapping sub-system.
As Tomasz mentioned, the later call was temporary patch until dma-mapping author
finalizes the implementation of dma_get_sgtable(). One can use this patch to use
this vb2 patch-set for his/her work in the meantime.
Signed-off-by: Subash Patel
---
drivers/media/video/videobuf2-dma-contig.c | 53 ++-
1 files changed, 4 insertions(+), 49 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c
index e8da7f1..1b9023a 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -143,32 +143,11 @@ static void vb2_dc_put(void *buf_priv)
kfree(buf);
}
-static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
- struct page **pages, unsigned int n_pages)
-{
- unsigned int i;
- unsigned long pfn;
- struct vm_area_struct vma = {
- .vm_flags = VM_IO | VM_PFNMAP,
- .vm_mm = current->mm,
- };
-
- for (i = 0; i < n_pages; ++i, kaddr += PAGE_SIZE) {
- if (follow_pfn(&vma, kaddr, &pfn))
- break;
- pages[i] = pfn_to_page(pfn);
- }
-
- return i;
-}
-
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
int ret = -ENOMEM;
- int n_pages;
- struct page **pages = NULL;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -183,35 +162,14 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
WARN_ON(buf->dma_addr & ~PAGE_MASK);
- n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ ret = dma_get_sgtable(dev, &buf->sgt_base, buf->vaddr,
+ buf->dma_addr, size, NULL);
- pages = kmalloc(n_pages * sizeof pages[0],
RE: [PATCH v2 01/13] davinci: vpif: add check for genuine interrupts in the isr
Hi Laurent,
On Mon, May 14, 2012 at 13:19:40, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Friday 11 May 2012 05:32:13 Hadli, Manjunath wrote:
> > On Tue, Apr 17, 2012 at 15:36:16, Laurent Pinchart wrote:
> > > On Tuesday 17 April 2012 14:22:59 Manjunath Hadli wrote:
> > > > As the same interrupt is shared between capture and display devices,
> > > > sometimes we get isr calls where the interrupt might not genuinely
> > > > belong to capture or display. Hence, add a condition in the isr to
> > > > check for interrupt ownership and channel number to make sure we do
> > > > not service wrong interrupts.
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > ---
> > > >
> > > > drivers/media/video/davinci/vpif_capture.c |5 +
> > > > drivers/media/video/davinci/vpif_display.c |5 +
> > > > include/media/davinci/vpif_types.h |2 ++
> > > > 3 files changed, 12 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/media/video/davinci/vpif_capture.c
> > > > b/drivers/media/video/davinci/vpif_capture.c index 6504e40..33d865d
> > > > 100644
> > > > --- a/drivers/media/video/davinci/vpif_capture.c
> > > > +++ b/drivers/media/video/davinci/vpif_capture.c
> > > > @@ -333,6 +333,7 @@ static void vpif_schedule_next_buffer(struct
> > > > common_obj
> > > > *common) */
> > > >
> > > > static irqreturn_t vpif_channel_isr(int irq, void *dev_id) {
> > > >
> > > > + struct vpif_capture_config *config = vpif_dev->platform_data;
> > > >
> > > > struct vpif_device *dev = &vpif_obj;
> > > > struct common_obj *common;
> > > > struct channel_obj *ch;
> > > >
> > > > @@ -341,6 +342,10 @@ static irqreturn_t vpif_channel_isr(int irq, void
> > > > *dev_id) int fid = -1, i;
> > > >
> > > > channel_id = *(int *)(dev_id);
> > > >
> > > > + if (!config->intr_status ||
> > > > + !config->intr_status(vpif_base, channel_id))
> > > > + return IRQ_NONE;
> > > > +
> > >
> > > I don't think this is the right way to handle the situation. You should
> > > instead read the interrupt source register for the VPIF capture device,
> > > and return IRQ_NONE if you find that no interrupt source has been flagged
> > > (and similarly for the display device below).
> >
> > Agreed, and this is what is being done in intr_status() function, which
> > is implemented in the board file. This function checks the interrupt source
> > register for VPIF capture and display devices the way you mentioned.
>
> Why do you need to do that in board code ? You can just check whether the
> VPIF
> capture hardware has generated an interrupt here exactly the same way as you
> do in your board code, and return IRQ_NONE if it hasn't. There's no need for
> the VPIF capture driver to be aware of the VPIF display driver (and vice
> versa).
>
Ok I'll add this in the driver itself.
Thx,
--Manju
> > > > ch = dev->dev[channel_id];
> > > >
> > > > field = ch->common[VPIF_VIDEO_INDEX].fmt.fmt.pix.field;
>
> --
> 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 v2 05/13] davinci: vpif display: declare contiguous region of memory handled by dma_alloc_coherent
Hi Laurent,
On Mon, May 14, 2012 at 13:16:27, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Friday 11 May 2012 05:30:43 Hadli, Manjunath wrote:
> > On Tue, Apr 17, 2012 at 15:32:55, Laurent Pinchart wrote:
> > > On Tuesday 17 April 2012 14:23:03 Manjunath Hadli wrote:
> > > > add support to declare contiguous region of memory to be handled when
> > > > requested by dma_alloc_coherent call. The user can specify the size of
> > > > the buffers with an offset from the kernel image using cont_bufsize
> > > > and cont_bufoffset module parameters respectively.
>
> [snip]
>
> > > > @@ -1686,12 +1710,14 @@ static __init int vpif_probe(struct
> > > > platform_device *pdev) struct vpif_subdev_info *subdevdata;
> > > >
> > > > struct vpif_display_config *config;
> > > > int i, j = 0, k, q, m, err = 0;
> > > >
> > > > + unsigned long phys_end_kernel;
> > > >
> > > > struct i2c_adapter *i2c_adap;
> > > > struct common_obj *common;
> > > > struct channel_obj *ch;
> > > > struct video_device *vfd;
> > > > struct resource *res;
> > > > int subdev_count;
> > > >
> > > > + size_t size;
> > > >
> > > > vpif_dev = &pdev->dev;
> > > >
> > > > @@ -1749,6 +1775,41 @@ static __init int vpif_probe(struct
> > > > platform_device
> > > > *pdev) ch->video_dev = vfd;
> > > >
> > > > }
> > > >
> > > > + /* Initialising the memory from the input arguments file for
> > > > +* contiguous memory buffers and avoid defragmentation
> > > > +*/
> > > > + if (cont_bufsize) {
> > > > + /* attempt to determine the end of Linux kernel memory
> > > > */
> > > > + phys_end_kernel = virt_to_phys((void *)PAGE_OFFSET) +
> > > > + (num_physpages << PAGE_SHIFT);
> > > > + phys_end_kernel += cont_bufoffset;
> > > > + size = cont_bufsize;
> > > > +
> > > > + err = dma_declare_coherent_memory(&pdev->dev,
> > > > phys_end_kernel,
> > > > + phys_end_kernel, size,
> > > > + DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> > >
> > > This is a pretty dangerous hack. You should compute the memory address and
> > > size in board code, and pass it to the driver through a device resource
> > > (don't forget to call request_mem_region on the resource). I think the
> > > dma_declare_coherent_memory() call should be moved to board code as well.
> >
> > I don't think it is a hack. Since the device does not support scatter gather
> > MMU, we need to make sure that the requirement of memory scucceeds for the
> > Driver buffers.
>
> If two drivers attempt to do the same you're screwed. That's why this should
> be moved to board code, where memory reservation for all devices that need it
> can be coordinated. You should call dma_declare_coherent_memory() there, not
> in the VPIF driver.
>
Ok I'll move dma_declare_coherent_memory() to board file.
> > Here the size is taken as part of module parameters, which If I am right,
> > cannot be moved to board file.
>
> Depending on how early you need the information in board code you can use
> early_param(), __setup() or normal module parameter macros in the board code.
>
Ok I'll fix this.
Thx,
--Manju
> > > > + if (!err) {
> > > > + dev_err(&pdev->dev, "Unable to declare MMAP
> > > > memory.\n");
> > > > + err = -ENOMEM;
> > > > + goto probe_out;
> > > > + }
> > > > +
> > > > + /* The resources are divided into two equal memory and
> > > > when
> > > > +* we have HD output we can add them together
> > > > +*/
> > > > + for (j = 0; j < VPIF_DISPLAY_MAX_DEVICES; j++) {
> > > > + ch = vpif_obj.dev[j];
> > > > + ch->channel_id = j;
> > > > +
> > > > + /* only enabled if second resource exists */
> > > > + config_params.video_limit[ch->channel_id] = 0;
> > > > + if (cont_bufsize)
> > > > +
> > > > config_params.video_limit[ch->channel_id] =
> > > > +
> > > > size/2;
> > > > + }
> > > > + }
> > > > +
> > > >
> > > > for (j = 0; j < VPIF_DISPLAY_MAX_DEVICES; j++) {
> > > >
> > > > ch = vpif_obj.dev[j];
> > > > /* Initialize field of the channel objects */ diff --git
>
> --
> 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: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
Hi, On 06/07/2012 08:43 AM, Hans Verkuil wrote: > On Thu June 7 2012 02:52:06 Laurent Pinchart wrote: >> On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote: >>> On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote: On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote: > I have a system where the data is planar, but the kernel drivers > expect to get one allocation with offsets for the planes. I can't > figure out how to do that with the current dma_buf implementation. I > thought I could pass the same dma_buf several times and use the > data_offset field of the v4l2_plane struct but it looks like that's > only for output. Am I missing something? Is this supported? data_offset is indeed for video output only at the moment, and doesn't seem to be used by any driver in mainline for now. >>> >>> Actually, data_offset may be set by capture drivers. For output buffers it >>> is set by userspace, for capture buffers it is set by the driver. This >>> data_offset typically contains meta data. >> >> Is that documented somewhere ? I wasn't aware of this use case. > > It is documented in the proposal that Pawel sent, but very poorly if at all in > the spec. That needs to be improved. > I can't really see a reason why data_offset couldn't be used for video capture devices as well. Sanity checks are currently missing. For output devices we should check that data_offset + bytesused< length in the vb2 core. For input devices the check will have to be performed by drivers. Taking data_offset into account automatically would also be useful. I think most of that should be possible to implement in the allocators. >>> >>> See this proposal of how to solve this: >>> >>> http://www.spinics.net/lists/linux-media/msg40376.html >> >> This requires more discussions regarding how the app_offset and data_offset >> fields should be used for the different memory types we support. >> >> For instance app_offset would not make that much sense for the USERPTR memory >> type, as we can include the offset in the user pointer already (using >> app_offset there would only make the code more complex without any added >> benefit). >> >> For the MMAP memory type adding an app_offset would require allocating >> buffers >> large enough to accomodate the offset, and would thus only be useful with >> CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer >> to another device that requires that app_offset) wouldn't be better addressed >> by the DMABUF memory type anyway. I think what is needed is a more flexible support for multi-planar data formats. Currently each plane involves separate memory allocation, which is not convenient in some use cases, at the least. For each plane a separate DMABUF object is needed. Single allocation for several data planes could be also useful for some still image capture use cases, where an image sensor device outputs multiple data at once, which can only be written into single memory region. There is currently no standard way to retrieve data offsets and sizes in such cases. It likely won't be trivial to cleanly integrate support for this with current V4L2 multi-plane API though. > I'm not going to pursue this unless Google indicates that they need this. And > actually I would suggest that they ask Pawel to work on this, after all he > made > the proposal AND he works for Google :-) -- Regards, Sylwester -- 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: What should CREATE_BUFS do if count == 0?
Hi Hans
On Thu, 7 Jun 2012, Hans Verkuil wrote:
> Hi all,
>
> I'm extending v4l2-compliance with support for VIDIOC_REQBUFS and
> VIDIOC_CREATE_BUFS,
> and I ran into an undefined issue: what happens if VIDIOC_CREATE_BUFS is
> called with
> count set to 0?
>
> I think there should be a separate test for that. Right now queue_setup will
> receive
> a request for 0 buffers, and I don't know if drivers expect a zero value
> there.
>
> I suggest that CREATE_BUFS with a count of 0 will only check whether memory
> and
> format.type are valid, and if they are it will just return 0 and do nothing.
Sounds good to me.
> Also note that this code in vb2_create_bufs is wrong:
>
> ret = __vb2_queue_alloc(q, create->memory, num_buffers,
> num_planes);
> if (ret < 0) {
> dprintk(1, "Memory allocation failed with error: %d\n", ret);
> return ret;
> }
>
> It should be:
>
> if (ret == 0) {
Indeed you're right. But then the return above should be "return -ENOMEM,"
shouldn't it?
>
> __vb2_queue_alloc() returns the number of buffers it managed to allocate,
> which is never < 0.
>
> I propose to add the patch included below.
>
> Comments are welcome!
>
> Regards,
>
> Hans
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c
> index a0702fd..01a8312 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -647,6 +647,9 @@ int vb2_create_bufs(struct vb2_queue *q, struct
> v4l2_create_buffers *create)
> return -EINVAL;
> }
>
> + if (create->count == 0)
> + return 0;
> +
> if (q->num_buffers == VIDEO_MAX_FRAME) {
> dprintk(1, "%s(): maximum number of buffers already
> allocated\n",
> __func__);
> @@ -675,7 +678,7 @@ int vb2_create_bufs(struct vb2_queue *q, struct
> v4l2_create_buffers *create)
> /* Finally, allocate buffers and video memory */
> ret = __vb2_queue_alloc(q, create->memory, num_buffers,
> num_planes);
> - if (ret < 0) {
> + if (ret == 0) {
> dprintk(1, "Memory allocation failed with error: %d\n", ret);
> return ret;
See above, should return an error code here.
> }
>
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] [media] videobuf2: correct the #ifndef text mistake in videobuf2-dma-contig.h
It should be a mistake due to copy & paste in header file Correct it in videobuf2-dma-config.h for avoiding duplicate include it Change-Id: I1f71fcec2889c033c7db380c58d9a1369c5afb35 Signed-off-by: Albert Wang --- include/media/videobuf2-dma-contig.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/media/videobuf2-dma-contig.h b/include/media/videobuf2-dma-contig.h index 19ae1e3..8197f87 100755 --- a/include/media/videobuf2-dma-contig.h +++ b/include/media/videobuf2-dma-contig.h @@ -1,5 +1,5 @@ /* - * videobuf2-dma-coherent.h - DMA coherent memory allocator for videobuf2 + * videobuf2-dma-contig.h - DMA contig memory allocator for videobuf2 * * Copyright (C) 2010 Samsung Electronics * @@ -10,8 +10,8 @@ * the Free Software Foundation. */ -#ifndef _MEDIA_VIDEOBUF2_DMA_COHERENT_H -#define _MEDIA_VIDEOBUF2_DMA_COHERENT_H +#ifndef _MEDIA_VIDEOBUF2_DMA_CONTIG_H +#define _MEDIA_VIDEOBUF2_DMA_CONTIG_H #include #include -- 1.7.0.4 -- 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 for v3.5] V4L2 spec fix
Thanks for the patch, Hans On Wed, 6 Jun 2012, Hans Verkuil wrote: > Two small docbook fixes: > > - prepare-buf was not positioned in alphabetical order, moved to the right > place. > - the format field in create_bufs had the wrong type in the documentation > > Regards, > > Hans > > Signed-off-by: Hans Verkuil Reviewed-by: Guennadi Liakhovetski Thanks Guennadi > > diff --git a/Documentation/DocBook/media/v4l/v4l2.xml > b/Documentation/DocBook/media/v4l/v4l2.xml > index 015c561..008c2d7 100644 > --- a/Documentation/DocBook/media/v4l/v4l2.xml > +++ b/Documentation/DocBook/media/v4l/v4l2.xml > @@ -560,6 +560,7 @@ and discussions on the V4L mailing list. > &sub-g-tuner; > &sub-log-status; > &sub-overlay; > +&sub-prepare-buf; > &sub-qbuf; > &sub-querybuf; > &sub-querycap; > @@ -567,7 +568,6 @@ and discussions on the V4L mailing list. > &sub-query-dv-preset; > &sub-query-dv-timings; > &sub-querystd; > -&sub-prepare-buf; > &sub-reqbufs; > &sub-s-hw-freq-seek; > &sub-streamon; > diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > index 765549f..6cd2bc3 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > @@ -108,7 +108,7 @@ information. > /> > > > - __u32 > + struct v4l2_format > format > Filled in by the application, preserved by the driver. > See . > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] media: mx2_camera: Add YUYV output format.
Hi Fabio, On 5 June 2012 16:17, Fabio Estevam wrote: > On Tue, Jun 5, 2012 at 11:14 AM, javier Martin > wrote: > >> No, I'm still working on it in my spare time. Progress is rather slow. > > Ok, great. If you want to collaborate on this task, I will be glad to help. > > Let me know if you have a git tree with your work in progress. As i stated, the driver is still in an early development stage, it doesn't do anything useful yet. But this is the public git repository if you want to take a look: git repo: https://github.com/jmartinc/video_visstrim.git branch: mx27-codadx6 FYI we are only interested on adding support for the encoding path of the VPU, but we are trying our best to make it modular (as it is done in Samsung's [1]), so that anyone can add decoding support later. By the way, you work for Freescale, don't you? We have a couple of issues with the i.MX27 VPU: 1- Firmware for the VPU is provided as a table of binary values inside a source file which is licensed as GPL, however software is packaged in a .tar.gz file that is marked as NDA. Do we have the right to distribute this firmware with our products? 2- There is a BUG in the firmware that marks P frames as IDR when it should only be done to I frames. Would it be possible to have access to the source code of the firmware in order to fix that problem? Regards. [1] http://lxr.linux.no/#linux+v3.4.1/drivers/media/video/s5p-mfc/ -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
