Re: [PATCH] media: fix a typo CONFIG_HAVE_GENERIC_DMA_COHERENT in videobuf2-dma-contig.c
Hello, On 11/27/2012 8:39 AM, Prabhakar Lad wrote: Hi Marek, On Tue, Nov 27, 2012 at 12:53 PM, Marek Szyprowski wrote: > Hello, > > > On 11/27/2012 6:59 AM, Prabhakar Lad wrote: >> >> From: Lad, Prabhakar >> >> from commit 93049b9368a2e257ace66252ab2cc066f3399cad, which adds >> a check HAVE_GENERIC_DMA_COHERENT for dma ops, the check was wrongly >> made it should have been HAVE_GENERIC_DMA_COHERENT but it was >> CONFIG_HAVE_GENERIC_DMA_COHERENT. >> This patch fixes the typo, which was causing following build error: >> >> videobuf2-dma-contig.c:743: error: 'vb2_dc_get_dmabuf' undeclared here >> (not in a function) >> make[3]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1 >> >> Signed-off-by: Lad, Prabhakar >> Signed-off-by: Manjunath Hadli > > > The CONFIG_HAVE_GENERIC_DMA_COHERENT based patch was a quick workaround > for the build problem in linux-next and should be reverted now. The > correct patch has been posted for drivers/base/dma-mapping.c to LKML, > see http://www.spinics.net/lists/linux-next/msg22890.html I was referring to this patch from Mauro, http://git.linuxtv.org/media_tree.git/commitdiff/93049b9368a2e257ace66252ab2cc066f3399cad which introduced this build error. I know, with my patch the workaround introduced by Mauro is not needed at all. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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: fix a typo CONFIG_HAVE_GENERIC_DMA_COHERENT in videobuf2-dma-contig.c
Hi Marek,
On Tue, Nov 27, 2012 at 12:53 PM, Marek Szyprowski
wrote:
> Hello,
>
>
> On 11/27/2012 6:59 AM, Prabhakar Lad wrote:
>>
>> From: Lad, Prabhakar
>>
>> from commit 93049b9368a2e257ace66252ab2cc066f3399cad, which adds
>> a check HAVE_GENERIC_DMA_COHERENT for dma ops, the check was wrongly
>> made it should have been HAVE_GENERIC_DMA_COHERENT but it was
>> CONFIG_HAVE_GENERIC_DMA_COHERENT.
>> This patch fixes the typo, which was causing following build error:
>>
>> videobuf2-dma-contig.c:743: error: 'vb2_dc_get_dmabuf' undeclared here
>> (not in a function)
>> make[3]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1
>>
>> Signed-off-by: Lad, Prabhakar
>> Signed-off-by: Manjunath Hadli
>
>
> The CONFIG_HAVE_GENERIC_DMA_COHERENT based patch was a quick workaround
> for the build problem in linux-next and should be reverted now. The
> correct patch has been posted for drivers/base/dma-mapping.c to LKML,
> see http://www.spinics.net/lists/linux-next/msg22890.html
>
I was referring to this patch from Mauro,
http://git.linuxtv.org/media_tree.git/commitdiff/93049b9368a2e257ace66252ab2cc066f3399cad
which introduced this build error.
Regards,
--Prabhakar Lad
>
>> ---
>> drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> index 5729450..dfea692 100644
>> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> @@ -739,7 +739,7 @@ static void *vb2_dc_attach_dmabuf(void *alloc_ctx,
>> struct dma_buf *dbuf,
>> const struct vb2_mem_ops vb2_dma_contig_memops = {
>> .alloc = vb2_dc_alloc,
>> .put= vb2_dc_put,
>> -#ifdef CONFIG_HAVE_GENERIC_DMA_COHERENT
>> +#ifdef HAVE_GENERIC_DMA_COHERENT
>> .get_dmabuf = vb2_dc_get_dmabuf,
>> #endif
>> .cookie = vb2_dc_cookie,
>
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
--
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: fix a typo CONFIG_HAVE_GENERIC_DMA_COHERENT in videobuf2-dma-contig.c
Hi,
On Tue, Nov 27, 2012 at 12:47 PM, Kyungmin Park
wrote:
> Hi,
>
> Does it right to use CONFIG_HAVE_GENERIC_DMA_COHERENT?
> it defined at init/Kconfig
>
> config HAVE_GENERIC_DMA_COHERENT
> bool
> default n
> and use at C file or header file as CONFIG_ prefix?
> e.g., include/asm-generic/dma-coherent.h:#ifdef
> CONFIG_HAVE_GENERIC_DMA_COHERENT
>
My Bad right fix should have been this:
--x---
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 5729450..083b065 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -226,7 +226,7 @@ static int vb2_dc_mmap(void *buf_priv, struct
vm_area_struct *vma)
/* DMABUF ops for exporters */
/*/
-#ifdef HAVE_GENERIC_DMA_COHERENT
+#ifdef CONFIG_HAVE_GENERIC_DMA_COHERENT
struct vb2_dc_attachment {
struct sg_table sgt;
Regards,
--Prabhakar
> Thank you,
> Kyungmin Park
>
> On 11/27/12, Prabhakar Lad wrote:
>> From: Lad, Prabhakar
>>
>> from commit 93049b9368a2e257ace66252ab2cc066f3399cad, which adds
>> a check HAVE_GENERIC_DMA_COHERENT for dma ops, the check was wrongly
>> made it should have been HAVE_GENERIC_DMA_COHERENT but it was
>> CONFIG_HAVE_GENERIC_DMA_COHERENT.
>> This patch fixes the typo, which was causing following build error:
>>
>> videobuf2-dma-contig.c:743: error: 'vb2_dc_get_dmabuf' undeclared here (not
>> in a function)
>> make[3]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1
>>
>> Signed-off-by: Lad, Prabhakar
>> Signed-off-by: Manjunath Hadli
>> ---
>> drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> index 5729450..dfea692 100644
>> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>> @@ -739,7 +739,7 @@ static void *vb2_dc_attach_dmabuf(void *alloc_ctx,
>> struct dma_buf *dbuf,
>> const struct vb2_mem_ops vb2_dma_contig_memops = {
>> .alloc = vb2_dc_alloc,
>> .put= vb2_dc_put,
>> -#ifdef CONFIG_HAVE_GENERIC_DMA_COHERENT
>> +#ifdef HAVE_GENERIC_DMA_COHERENT
>> .get_dmabuf = vb2_dc_get_dmabuf,
>> #endif
>> .cookie = vb2_dc_cookie,
>> --
>> 1.7.0.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
--
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: fix a typo CONFIG_HAVE_GENERIC_DMA_COHERENT in videobuf2-dma-contig.c
Hello,
On 11/27/2012 6:59 AM, Prabhakar Lad wrote:
From: Lad, Prabhakar
from commit 93049b9368a2e257ace66252ab2cc066f3399cad, which adds
a check HAVE_GENERIC_DMA_COHERENT for dma ops, the check was wrongly
made it should have been HAVE_GENERIC_DMA_COHERENT but it was
CONFIG_HAVE_GENERIC_DMA_COHERENT.
This patch fixes the typo, which was causing following build error:
videobuf2-dma-contig.c:743: error: 'vb2_dc_get_dmabuf' undeclared here (not in
a function)
make[3]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
The CONFIG_HAVE_GENERIC_DMA_COHERENT based patch was a quick workaround
for the build problem in linux-next and should be reverted now. The
correct patch has been posted for drivers/base/dma-mapping.c to LKML,
see http://www.spinics.net/lists/linux-next/msg22890.html
---
drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 5729450..dfea692 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -739,7 +739,7 @@ static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct
dma_buf *dbuf,
const struct vb2_mem_ops vb2_dma_contig_memops = {
.alloc = vb2_dc_alloc,
.put= vb2_dc_put,
-#ifdef CONFIG_HAVE_GENERIC_DMA_COHERENT
+#ifdef HAVE_GENERIC_DMA_COHERENT
.get_dmabuf = vb2_dc_get_dmabuf,
#endif
.cookie = vb2_dc_cookie,
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
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: fix a typo CONFIG_HAVE_GENERIC_DMA_COHERENT in videobuf2-dma-contig.c
Hi,
Does it right to use CONFIG_HAVE_GENERIC_DMA_COHERENT?
it defined at init/Kconfig
config HAVE_GENERIC_DMA_COHERENT
bool
default n
and use at C file or header file as CONFIG_ prefix?
e.g., include/asm-generic/dma-coherent.h:#ifdef CONFIG_HAVE_GENERIC_DMA_COHERENT
Thank you,
Kyungmin Park
On 11/27/12, Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> from commit 93049b9368a2e257ace66252ab2cc066f3399cad, which adds
> a check HAVE_GENERIC_DMA_COHERENT for dma ops, the check was wrongly
> made it should have been HAVE_GENERIC_DMA_COHERENT but it was
> CONFIG_HAVE_GENERIC_DMA_COHERENT.
> This patch fixes the typo, which was causing following build error:
>
> videobuf2-dma-contig.c:743: error: 'vb2_dc_get_dmabuf' undeclared here (not
> in a function)
> make[3]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1
>
> Signed-off-by: Lad, Prabhakar
> Signed-off-by: Manjunath Hadli
> ---
> drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 5729450..dfea692 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -739,7 +739,7 @@ static void *vb2_dc_attach_dmabuf(void *alloc_ctx,
> struct dma_buf *dbuf,
> const struct vb2_mem_ops vb2_dma_contig_memops = {
> .alloc = vb2_dc_alloc,
> .put= vb2_dc_put,
> -#ifdef CONFIG_HAVE_GENERIC_DMA_COHERENT
> +#ifdef HAVE_GENERIC_DMA_COHERENT
> .get_dmabuf = vb2_dc_get_dmabuf,
> #endif
> .cookie = vb2_dc_cookie,
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
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: Fw: [PATCH] dma-mapping: fix dma_common_get_sgtable() conditional compilation
On Mon, Nov 26, 2012 at 06:18:37PM -0200, Mauro Carvalho Chehab wrote: > Hi Greg, > > Are you maintaining drivers/base/dma-mapping.c? The enclosed path is needed to > enable DMABUF handling on V4L2 on some architectures, like x86_64, as we need > dma_common_get_sgtable() on drivers/media/v4l2-core/videobuf2-dma-contig.c. > > Would you mind acking it, in order to let this patch flow via my tree? This > way, > I can revert a workaround I had to apply there, in order to avoid linux-next > compilation breakage. > > Thanks! > Mauro > > - > > From: Marek Szyprowski > Date: Mon, 26 Nov 2012 14:41:48 +0100 > > dma_common_get_sgtable() function doesn't depend on > ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY, so it must not be compiled > conditionally. > > Reported-by: Stephen Rothwell > Signed-off-by: Marek Szyprowski Acked-by: Greg Kroah-Hartman -- 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
Fw: [PATCH] dma-mapping: fix dma_common_get_sgtable() conditional compilation
Hi Greg, Are you maintaining drivers/base/dma-mapping.c? The enclosed path is needed to enable DMABUF handling on V4L2 on some architectures, like x86_64, as we need dma_common_get_sgtable() on drivers/media/v4l2-core/videobuf2-dma-contig.c. Would you mind acking it, in order to let this patch flow via my tree? This way, I can revert a workaround I had to apply there, in order to avoid linux-next compilation breakage. Thanks! Mauro - From: Marek Szyprowski Date: Mon, 26 Nov 2012 14:41:48 +0100 dma_common_get_sgtable() function doesn't depend on ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY, so it must not be compiled conditionally. Reported-by: Stephen Rothwell Signed-off-by: Marek Szyprowski --- drivers/base/dma-mapping.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index 3fbedc7..0ce39a3 100644 --- a/drivers/base/dma-mapping.c +++ b/drivers/base/dma-mapping.c @@ -218,6 +218,8 @@ void dmam_release_declared_memory(struct device *dev) } EXPORT_SYMBOL(dmam_release_declared_memory); +#endif + /* * Create scatter-list for the already allocated DMA buffer. */ @@ -236,8 +238,6 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt, } EXPORT_SYMBOL(dma_common_get_sgtable); -#endif - /* * Create userspace mapping for the DMA-coherent memory. */ -- 1.7.9.5 -- Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
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 Nov 26 19:00:24 CET 2012 git hash:93049b9368a2e257ace66252ab2cc066f3399cad gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: ERRORS linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: WARNINGS linux-3.4-i686: ERRORS linux-3.5-i686: ERRORS linux-3.6-i686: ERRORS linux-3.7-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: ERRORS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: 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
Re: Tuning problems with em28xx-dvb & tda10071 on MIPS-based router board
On 11/26/2012 07:50 PM, Ingo Kofler wrote: Hi, I am trying to get my PCTV DVB-S2 stick running on my TP-Link TL-WR1043ND that runs OpenWrt (Attitude Adjustment Beta, Kernel 3.3.8). I have cross-compiled the corresponding kernel modules and deployed them on the router. I have also deployed the firmware on the device. After loading the corresponding modules the /dev/dvb/... devices show up and the dmesg output seems to be fine. Then I tried to test the device using szap and a channels.conf file. Unfortunately, the device cannot tune to most of the transponders except of two. Both are located in the vertical high band of the Astra 19E. For all other transponders I do not get a lock of the frontend. Tuning works fine on my PC using kernel verions 3.2 and 3.5 (the ones that ship with Ubuntu) and using the same channels.conf file and stick. So I conclude that both the stick, the satellite dish and the channels.conf is working. I've also tested it on the router board with an external powered USB Hub (I though that maybe the power of the router's USB port wasn't good enough). Now I have no further ideas. Before I start to debug the C code and try to figure out the difference between the PC and the router - Are there any known issues with this driver? Does it work on MIPS and different endianess? No idea if it works or not any other than AMD64 (and i386). I use AMD64 Kernel on my computer and I cannot test easily any other arch's as I don't have suitable hardware. i386 is so common which means bug reports are got very quickly and fixed. Generally speaking I am a little bit surprised these drivers seems to just work from arch to arch quite often. regards 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] gspca - ov534: Fix the light frequency filter
On Mon, 26 Nov 2012 18:12:41 +0100 Antonio Ospite wrote: > BTW the documentation might also be wrong or inaccurate. The ov7670 documentation has exactly the same description of the register 0x2b, and I don't think that the manufacturer would greatly change the meaning of such low registers in so close sensors. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tuning problems with em28xx-dvb & tda10071 on MIPS-based router board
Hi, I am trying to get my PCTV DVB-S2 stick running on my TP-Link TL-WR1043ND that runs OpenWrt (Attitude Adjustment Beta, Kernel 3.3.8). I have cross-compiled the corresponding kernel modules and deployed them on the router. I have also deployed the firmware on the device. After loading the corresponding modules the /dev/dvb/... devices show up and the dmesg output seems to be fine. Then I tried to test the device using szap and a channels.conf file. Unfortunately, the device cannot tune to most of the transponders except of two. Both are located in the vertical high band of the Astra 19E. For all other transponders I do not get a lock of the frontend. Tuning works fine on my PC using kernel verions 3.2 and 3.5 (the ones that ship with Ubuntu) and using the same channels.conf file and stick. So I conclude that both the stick, the satellite dish and the channels.conf is working. I've also tested it on the router board with an external powered USB Hub (I though that maybe the power of the router's USB port wasn't good enough). Now I have no further ideas. Before I start to debug the C code and try to figure out the difference between the PC and the router - Are there any known issues with this driver? Does it work on MIPS and different endianess? Best regards, Ingo -- 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] gspca - ov534: Fix the light frequency filter
On Mon, 26 Nov 2012 16:23:18 +0100
Jean-Francois Moine wrote:
> On Mon, 26 Nov 2012 14:08:06 +0100
> Antonio Ospite wrote:
>
> > For now I'd NAK the patch since it is a regression for users
> > with 50Hz power sources and it looks like it does not _always_ work for
> > 60Hz either.
> >
> > Should I remove it from patchwork as well?
> >
> > As I have the webcam and can perform actual tests I'll coordinate with
> > Fabian to have more details about why light frequency filter is not
> > working for him with the current code, it works fine for me at 640x480,
> > even if I can see that its effect is weaker at 320x240.
>
> I wonder how it could work. Look at the actual code:
>
> val = val ? 0x9e : 0x00;
> if (sd->sensor == SENSOR_OV767x) {
> sccb_reg_write(gspca_dev, 0x2a, 0x00);
> if (val)
> val = 0x9d; /* insert dummy to 25fps for 50Hz */
> }
> sccb_reg_write(gspca_dev, 0x2b, val);
>
> According to the ov7720/ov7221 documentation, the register 2b is:
>
> 2B EXHCL 00 RW Dummy Pixel Insert LSB
> 8 LSB for dummy pixel insert in horizontal direction
>
> How could it act on the light frequency filter?
Warning: guess-work follows.
When the light filter (i.e. from the v4l2 POV) is ON, the frame rate is
actually lower than the one expected; that could be the effect of the
insertion of dummy pixels in the data processed by the sensor (the
streamed data keeps always the same size tho), maybe it is just a trick
but the fact is that the flickering goes away.
The weaker result at 320x240 could be due to the amount of dummy pixels
tailored for the higher resolution, IIRC the PS3 dumps were performed
only at 640x480.
BTW the documentation might also be wrong or inaccurate.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
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: [PATCHv15 3/7] video: add of helper for display timings/videomode
On 2012-11-26 18:10, Steffen Trumtrar wrote: > Hi, > > On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote: >>> +optional properties: >>> + - hsync-active: hsync pulse is active low/high/ignored >>> + - vsync-active: vsync pulse is active low/high/ignored >>> + - de-active: data-enable pulse is active low/high/ignored >>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/ >>> + non-inverted (active on rising edge)/ >>> +ignored (ignore property) >> >> I think hsync-active and vsync-active are clear, and commonly used, and >> they are used for both drm and fb mode conversions in later patches. >> >> de-active is not used in drm and fb mode conversions, but I think it's >> also clear. >> >> pixelclk-inverted is not used in the mode conversions. It's also a bit >> unclear to me. What does it mean that pix clock is "active on rising >> edge"? The pixel data is driven on rising edge? How about the sync >> signals and DE, when are they driven? Does your HW have any settings >> related to those? >> > > Those are properties commonly found in display specs. That is why they are > here. > If the GPU does not support the property it can be omitted. So what does the pixelclk-inverted mean? Normally the SoC drives pixel data on rising edge, and the panel samples it at falling edge? And vice-versa for inverted? Or the other way around? When is hsync/vsync set? On rising or falling edge of pclk? My point here is that the pixelclk-inverted is not crystal clear thing, like the hsync/vsync/de-active values are. And while thinking about this, I realized that the meaning of pixelclk-inverted depends on what component is it applied to. Presuming normal pixclk means "pixel data on rising edge", the meaning of that depends on do we consider the SoC or the panel. The panel needs to sample the data on the other edge from the one the SoC uses to drive the data. Does the videomode describe the panel, or does it describe the settings programmed to the SoC? >> OMAP has the invert pclk setting, but it also has a setting to define >> when the sync signals are driven. The options are: >> - syncs are driven on rising edge of pclk >> - syncs are driven on falling edge of pclk >> - syncs are driven on the opposite edge of pclk compared to the pixel data >> >> For DE there's no setting, except the active high/low. >> >> And if I'm not mistaken, if the optional properties are not defined, >> they are not ignored, but left to the default 0. Which means active low, >> or active on rising edge(?). I think it would be good to have a >> "undefined" value for the properties. >> > > Yes. As mentioned in my other mail, the intention of the omitted properties do > not propagate properly. Omitted must be a value < 0, so it is clear in a later > stage, that this property shall not be used. And isn't unintentionally > considered > to be active low. Ok. Just note that the values are currently stored into u32, and I don't think using negative error values with u32 is a good idea. >> I have some of the same concerns for this series than with the >> interpreted power sequences (on fbdev): when you publish the DT >> bindings, it's somewhat final version then, and fixing it later will be >> difficult. Of course, video modes are much clearer than the power >> sequences, so it's possible there won't be any problems with the DT >> bindings. >> > > The binding is pretty much at the bare minimum after a lot of discussion about > the properties. Even if the binding changes, I think it will rather grow than > shrink. Take the doubleclock property for example. It got here mistakingly, > because we had a display that has this feature. Right. That's why I would leave the pixelclock-inverted out for now, if we're not totally sure how it's defined. Of course, it could be just me who is not understanding the pixclk-inverted =). >> However, I'd still feel safer if the series would be split to non-DT and >> DT parts. The non-DT parts could be merged quite easily, and people >> could start using them in their kernels. This should expose >> bugs/problems related to the code. >> >> The DT part could be merged later, when there's confidence that the >> timings are good for all platforms. >> >> Or, alternatively, all the non-common bindings (de-active, pck >> invert,...) that are not used for fbdev or drm currently could be left >> out for now. But I'd stil prefer merging it in two parts. > > I don't say that I'm against it, but the whole reason for the series was > getting the display timings from a DT into a graphics driver. And I think > I remember seeing some other attempts at achieving this, but all specific > to one special case. There is even already a mainline driver that uses an > older > version of the DT bindings (vt8500-fb). I think it'd be very useful even without DT bindings. But yes, I understand your need for it. You're now in v15 of the series. Are you s
Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
Hi, On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote: > Hi, > > On 2012-11-26 11:07, Steffen Trumtrar wrote: > > This adds support for reading display timings from DT into a struct > > display_timings. The of_display_timing implementation supports multiple > > subnodes. All children are read into an array, that can be queried. > > > > If no native mode is specified, the first subnode will be used. > > > > For cases where the graphics driver knows there can be only one > > mode description or where the driver only supports one mode, a helper > > function of_get_videomode is added, that gets a struct videomode from DT. > > > > Signed-off-by: Steffen Trumtrar > > Signed-off-by: Philipp Zabel > > Acked-by: Stephen Warren > > Reviewed-by: Thierry Reding > > Acked-by: Thierry Reding > > Tested-by: Thierry Reding > > Tested-by: Philipp Zabel > > Reviewed-by: Laurent Pinchart > > Acked-by: Laurent Pinchart > > --- > > .../devicetree/bindings/video/display-timing.txt | 107 ++ > > drivers/video/Kconfig | 15 ++ > > drivers/video/Makefile |2 + > > drivers/video/of_display_timing.c | 219 > > > > drivers/video/of_videomode.c | 54 + > > include/linux/of_display_timing.h | 20 ++ > > include/linux/of_videomode.h | 18 ++ > > 7 files changed, 435 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/video/display-timing.txt > > create mode 100644 drivers/video/of_display_timing.c > > create mode 100644 drivers/video/of_videomode.c > > create mode 100644 include/linux/of_display_timing.h > > create mode 100644 include/linux/of_videomode.h > > > > diff --git a/Documentation/devicetree/bindings/video/display-timing.txt > > b/Documentation/devicetree/bindings/video/display-timing.txt > > new file mode 100644 > > index 000..e238f27 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/video/display-timing.txt > > @@ -0,0 +1,107 @@ > > +display-timing bindings > > +=== > > + > > +display-timings node > > + > > + > > +required properties: > > + - none > > + > > +optional properties: > > + - native-mode: The native mode for the display, in case multiple modes are > > + provided. When omitted, assume the first node is the native. > > + > > +timing subnode > > +-- > > + > > +required properties: > > + - hactive, vactive: display resolution > > + - hfront-porch, hback-porch, hsync-len: horizontal display timing > > parameters > > + in pixels > > + vfront-porch, vback-porch, vsync-len: vertical display timing > > parameters in > > + lines > > + - clock-frequency: display clock in Hz > > + > > +optional properties: > > + - hsync-active: hsync pulse is active low/high/ignored > > + - vsync-active: vsync pulse is active low/high/ignored > > + - de-active: data-enable pulse is active low/high/ignored > > + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/ > > + non-inverted (active on rising edge)/ > > +ignored (ignore property) > > I think hsync-active and vsync-active are clear, and commonly used, and > they are used for both drm and fb mode conversions in later patches. > > de-active is not used in drm and fb mode conversions, but I think it's > also clear. > > pixelclk-inverted is not used in the mode conversions. It's also a bit > unclear to me. What does it mean that pix clock is "active on rising > edge"? The pixel data is driven on rising edge? How about the sync > signals and DE, when are they driven? Does your HW have any settings > related to those? > Those are properties commonly found in display specs. That is why they are here. If the GPU does not support the property it can be omitted. > OMAP has the invert pclk setting, but it also has a setting to define > when the sync signals are driven. The options are: > - syncs are driven on rising edge of pclk > - syncs are driven on falling edge of pclk > - syncs are driven on the opposite edge of pclk compared to the pixel data > > For DE there's no setting, except the active high/low. > > And if I'm not mistaken, if the optional properties are not defined, > they are not ignored, but left to the default 0. Which means active low, > or active on rising edge(?). I think it would be good to have a > "undefined" value for the properties. > Yes. As mentioned in my other mail, the intention of the omitted properties do not propagate properly. Omitted must be a value < 0, so it is clear in a later stage, that this property shall not be used. And isn't unintentionally considered to be active low. > > + - interlaced (bool): boolean to enable interlaced mode > > + - doublescan (bool): boolean to enable doublescan mode > > + - doubleclk (bool) > > As I mentioned in the other ma
Re: [GIT PULL FOR v3.7-rc] Samsung SoC media driver fixes
Hi Mauro, On 11/22/2012 07:15 PM, Sylwester Nawrocki wrote: > The following changes since commit 30677fd9ac7b9a06555318ec4f9a0db39804f9b2: > > s5p-fimc: Fix potential NULL pointer dereference (2012-11-22 10:15:40 +0100) > > are available in the git repository at: > > git://git.infradead.org/users/kmpark/linux-samsung media_fixes_for_v3.7 > > for you to fetch changes up to 28f497f26c67ab734bdb923b457016122368f69a: > > s5p-mfc: Handle multi-frame input buffer (2012-11-22 15:13:53 +0100) > > This is a bunch of quite important fixes for the Exynos SoC drivers, > please apply for v3.7 if possible. This depends on my previous pull > request (I've applied the patches you indicated you take for v3.7 > previously to the media_fixes_for_v3.7 branch as well). I have fixed 2 build warnings caused by patch "s5p-fimc: Prevent race conditions during subdevs registration". Here is an updated pull request: The following changes since commit 30677fd9ac7b9a06555318ec4f9a0db39804f9b2: s5p-fimc: Fix potential NULL pointer dereference (2012-11-22 10:15:40 +0100) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung media_fixes_for_v3.7 for you to fetch changes up to ffc64574688e1d6f110ca91cef2573f7eca1dbab: s5p-mfc: Handle multi-frame input buffer (2012-11-26 15:55:04 +0100) Arun Kumar K (2): s5p-mfc: Bug fix of timestamp/timecode copy mechanism s5p-mfc: Handle multi-frame input buffer Shaik Ameer Basha (1): exynos-gsc: Fix settings for input and output image RGB type Sylwester Nawrocki (5): s5p-fimc: Prevent race conditions during subdevs registration s5p-fimc: Don't use mutex_lock_interruptible() in device release() fimc-lite: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Add missing video device vfl_dir flag initialization drivers/media/platform/exynos-gsc/gsc-m2m.c |4 ++-- drivers/media/platform/exynos-gsc/gsc-regs.h| 16 drivers/media/platform/s5p-fimc/fimc-capture.c | 10 +++--- drivers/media/platform/s5p-fimc/fimc-lite.c |6 -- drivers/media/platform/s5p-fimc/fimc-m2m.c |3 +-- drivers/media/platform/s5p-fimc/fimc-mdevice.c |4 ++-- drivers/media/platform/s5p-mfc/s5p_mfc.c|7 ++- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |2 +- 8 files changed, 27 insertions(+), 25 deletions(-) Regards, -- Sylwester Nawrocki Samsung Poland R&D Center -- 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: [PATCHv15 2/7] video: add display_timing and videomode
On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
> On 2012-11-26 11:07, Steffen Trumtrar wrote:
>
> > +/*
> > + * Subsystem independent description of a videomode.
> > + * Can be generated from struct display_timing.
> > + */
> > +struct videomode {
> > + u32 pixelclock; /* pixelclock in Hz */
>
> I don't know if this is of any importance, but the linux clock framework
> manages clock rates with unsigned long. Would it be better to use the
> same type here?
>
Hm, I don't know. Anyone? u32 should be large enough for a pixelclock.
> > + u32 hactive;
> > + u32 hfront_porch;
> > + u32 hback_porch;
> > + u32 hsync_len;
> > +
> > + u32 vactive;
> > + u32 vfront_porch;
> > + u32 vback_porch;
> > + u32 vsync_len;
> > +
> > + u32 hah;/* hsync active high */
> > + u32 vah;/* vsync active high */
> > + u32 de; /* data enable */
> > + u32 pixelclk_pol;
>
> What values will these 4 have? Aren't these booleans?
>
> The data enable comment should be "data enable active high".
>
> The next patch says in the devtree binding documentation that the values
> may be on/off/ignored. Is that represented here somehow, i.e. values are
> 0/1/2 or so? If not, what does it mean if the value is left out from
> devtree data, meaning "not used on hardware"?
>
Hm, I think you might be right here. It is no problem in the DT part of the
code.
The properties are optional, left out means "not used on hardware".
But this does not propagate correctly to the videomode. I should set the fields
to -EINVAL in case they are omitted, than everything should work nicely.
> There's also a "doubleclk" value mentioned in the devtree bindings doc,
> but not shown here.
>
Argh. That slipped through. I have patches that add this property to all
structs and the devicetree binding. But it is not supposed to be in this
series, because I want to at least have the binding stable for now.
> I think this videomode struct is the one that display drivers are going
> to use (?), in addition to the display_timing, so it would be good to
> document it well.
>
Yes. Maybe I have to put more of the devicetree documentation in the code.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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] gspca - ov534: Fix the light frequency filter
On Mon, 26 Nov 2012 14:08:06 +0100
Antonio Ospite wrote:
> For now I'd NAK the patch since it is a regression for users
> with 50Hz power sources and it looks like it does not _always_ work for
> 60Hz either.
>
> Should I remove it from patchwork as well?
>
> As I have the webcam and can perform actual tests I'll coordinate with
> Fabian to have more details about why light frequency filter is not
> working for him with the current code, it works fine for me at 640x480,
> even if I can see that its effect is weaker at 320x240.
I wonder how it could work. Look at the actual code:
val = val ? 0x9e : 0x00;
if (sd->sensor == SENSOR_OV767x) {
sccb_reg_write(gspca_dev, 0x2a, 0x00);
if (val)
val = 0x9d; /* insert dummy to 25fps for 50Hz */
}
sccb_reg_write(gspca_dev, 0x2b, val);
According to the ov7720/ov7221 documentation, the register 2b is:
2B EXHCL 00 RW Dummy Pixel Insert LSB
8 LSB for dummy pixel insert in horizontal direction
How could it act on the light frequency filter?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OV5642: fix VIDIOC_S_GROP ioctl
Hi Anatolij Sorry for a delay On Tue, 6 Nov 2012, Anatolij Gustschin wrote: > On Tue, 6 Nov 2012 12:45:51 +0100 (CET) > Guennadi Liakhovetski wrote: > > > On Tue, 6 Nov 2012, Anatolij Gustschin wrote: > > > > > VIDIOC_S_GROP ioctl doesn't work, soc-camera driver reports: > > > > > > soc-camera-pdrv soc-camera-pdrv.0: S_CROP denied: getting current crop > > > failed > > > > > > The issue is caused by checking for V4L2_BUF_TYPE_VIDEO_CAPTURE type > > > in driver's g_crop callback. This check should be in s_crop instead, > > > g_crop should just set the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE > > > as other drivers do. Move the V4L2_BUF_TYPE_VIDEO_CAPTURE type check > > > to s_crop callback. > > > > I'm not sure this is correct: > > > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-crop.html > > > > Or is the .g_crop() subdev operation using a different semantics? Where is > > that documented? > > I do not know if it is documented somewhere. But it seems natural to me > that a sensor driver sets the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE > in its .g_crop(). A sensor is a capture device, not an output or overlay > device. And this ioctl is a query operation. > > OTOH I'm fine with this type checking in .g_crop() and it can help > to discover bugs in user space apps. The VIDIOC_G_CROP documentation > states that the type field needs to be set to the respective buffer type > when querying, so the check in .g_crop() is perfectly valid. But then > I need following patch to fix the observed issue: > > --- a/drivers/media/platform/soc_camera/soc_camera.c > +++ b/drivers/media/platform/soc_camera/soc_camera.c > @@ -902,6 +902,8 @@ static int soc_camera_s_crop(struct file *file, void *fh, > dev_dbg(icd->pdev, "S_CROP(%ux%u@%u:%u)\n", > rect->width, rect->height, rect->left, rect->top); > > + current_crop.type = a->type; > + > /* If get_crop fails, we'll let host and / or client drivers decide */ > ret = ici->ops->get_crop(icd, ¤t_crop); > > What do you think? Yes, this makes sense. Please, submit a patch. > And the type field should be checked in .s_crop() anyway, I think. It is checked in soc_camera_s_crop() just a couple of lines above the snippet above. Or what do you mean? 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
Poor HVR 1600 Video Quality - Feedback for Andy Walls 2012-11-26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2012 07:54 PM, Andy Walls wrote: > So here's what you need to do: > > 1. provide the output of v4l2-ctl -d /dev/video2 --log-status, so I > can see the analog tuner assembly that your unit has. > Here is the output with the S-Video Input in use. If I need to snapshot with the coax input in use that will take a little more time. Status Log: cx18-0: = START STATUS CARD #0 = cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600 tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 5267091 tveeprom 4-0050: MAC address is 00:0d:fe:50:5e:93 tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 4-0050: audio processor is CX23418 (idx 38) tveeprom 4-0050: decoder processor is CX23418 (idx 31) tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter cx18-0 843: Video signal: present cx18-0 843: Detected format: NTSC-M cx18-0 843: Specified standard:NTSC-M cx18-0 843: Specified video input: S-Video (Luma In1, Chroma In5) cx18-0 843: Specified audioclock freq: 48000 Hz cx18-0 843: Detected audio mode: mono cx18-0 843: Detected audio standard: BTSC cx18-0 843: Audio muted: no cx18-0 843: Audio microcontroller: stopped cx18-0 843: Configured audio standard: automatic detection cx18-0 843: Configured audio system: BTSC cx18-0 843: Specified audio input: External cx18-0 843: Preferred audio mode: stereo cx18-0 gpio-reset-ctrl: GPIO: direction 0x3001, value 0x3001 tuner 5-0061: Tuner mode: analog TV tuner 5-0061: Frequency: 67.25 MHz tuner 5-0061: Standard:0xb000 cs5345 4-004c: Input: 2 cs5345 4-004c: Volume: 0 dB cx18-0: Video Input: S-Video 1 cx18-0: Audio Input: Line In 1 cx18-0: GPIO: direction 0x3001, value 0x3001 cx18-0: Tuner: TV cx18-0: Stream: MPEG-2 Program Stream cx18-0: VBI Format: Private packet, IVTV format cx18-0: Video: 720x480, 30 fps cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 440, Peak 660 cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0 cx18-0: Temporal Filter: Manual, 8 cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255] cx18-0: Status flags: 0x0021 cx18-0: Stream encoder MPEG: status 0x, 0% of 2048 KiB (64 buffers) in use cx18-0: Stream encoder YUV: status 0x, 0% of 2025 KiB (20 buffers) in use cx18-0: Stream encoder VBI: status 0x, 0% of 1015 KiB (20 buffers) in use cx18-0: Stream encoder PCM audio: status 0x, 0% of 1024 KiB (256 buffers) in use cx18-0: Read MPEG/VBI: 0/0 bytes cx18-0: == END STATUS CARD #0 == > 2. Test the unit under the previous Linux kernel version with which > you were *sure* the unit worked properly. Or test with Windows as > Devin suggested. We're trying to eliminate a bad HVR-1600 card > here, so if you can test it in that very same machine, all the > better. > > Also, if you can provide us with the two kernel versions, working > and non-working, we can narrow down if a kernel change caused the > problem for you. > I do not have the ability to revert to a known working state without potentially messing thigns up in a serious way. I know the last known good working state was prior to 2012-08-10. I've tried reverting to kernels that were current at that time and the problem still persist. It also is worth noting that the "good" video at that time still had the occaisional artifact along the edges which does not happen using the SVideo portion of the card now. > 3. Test with as few cards in the PC chassis as possible. This > will eliminate some EMI and power supply problems. It's a shot in > the dark, but easy enough for you to try. > I just finished a weeks vacation and after the honey-do list had Friday, Saturday and Sunday to play on the video tower. Pulled everything apart and cleaned it all. The pictures I took involved removing and reseating all the cards so this did not help. It will be December before I have time to pull cards and try this as you suggest. Must earn a paycheck. > 4. If you do decide to much around in the PC, pull out all the PCI > cards, blow the dust out of all the slots, reseat the cards, and > retest. I am amazed at how often that actually helps with various > problems. > > > > I would point you to an email where I added all sorts of extra > controls to the cx18 driver in a patchset, for the express purpose > of debugging sync problems: > > http://www.gossamer-threads.com/lists/ivtv/users/40227?do=post_view_threaded#40227 > > and ask you to fiddle around with them. > > Un
Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
Hi, On 2012-11-26 11:07, Steffen Trumtrar wrote: > This adds support for reading display timings from DT into a struct > display_timings. The of_display_timing implementation supports multiple > subnodes. All children are read into an array, that can be queried. > > If no native mode is specified, the first subnode will be used. > > For cases where the graphics driver knows there can be only one > mode description or where the driver only supports one mode, a helper > function of_get_videomode is added, that gets a struct videomode from DT. > > Signed-off-by: Steffen Trumtrar > Signed-off-by: Philipp Zabel > Acked-by: Stephen Warren > Reviewed-by: Thierry Reding > Acked-by: Thierry Reding > Tested-by: Thierry Reding > Tested-by: Philipp Zabel > Reviewed-by: Laurent Pinchart > Acked-by: Laurent Pinchart > --- > .../devicetree/bindings/video/display-timing.txt | 107 ++ > drivers/video/Kconfig | 15 ++ > drivers/video/Makefile |2 + > drivers/video/of_display_timing.c | 219 > > drivers/video/of_videomode.c | 54 + > include/linux/of_display_timing.h | 20 ++ > include/linux/of_videomode.h | 18 ++ > 7 files changed, 435 insertions(+) > create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt > create mode 100644 drivers/video/of_display_timing.c > create mode 100644 drivers/video/of_videomode.c > create mode 100644 include/linux/of_display_timing.h > create mode 100644 include/linux/of_videomode.h > > diff --git a/Documentation/devicetree/bindings/video/display-timing.txt > b/Documentation/devicetree/bindings/video/display-timing.txt > new file mode 100644 > index 000..e238f27 > --- /dev/null > +++ b/Documentation/devicetree/bindings/video/display-timing.txt > @@ -0,0 +1,107 @@ > +display-timing bindings > +=== > + > +display-timings node > + > + > +required properties: > + - none > + > +optional properties: > + - native-mode: The native mode for the display, in case multiple modes are > + provided. When omitted, assume the first node is the native. > + > +timing subnode > +-- > + > +required properties: > + - hactive, vactive: display resolution > + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters > + in pixels > + vfront-porch, vback-porch, vsync-len: vertical display timing parameters > in > + lines > + - clock-frequency: display clock in Hz > + > +optional properties: > + - hsync-active: hsync pulse is active low/high/ignored > + - vsync-active: vsync pulse is active low/high/ignored > + - de-active: data-enable pulse is active low/high/ignored > + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/ > + non-inverted (active on rising edge)/ > + ignored (ignore property) I think hsync-active and vsync-active are clear, and commonly used, and they are used for both drm and fb mode conversions in later patches. de-active is not used in drm and fb mode conversions, but I think it's also clear. pixelclk-inverted is not used in the mode conversions. It's also a bit unclear to me. What does it mean that pix clock is "active on rising edge"? The pixel data is driven on rising edge? How about the sync signals and DE, when are they driven? Does your HW have any settings related to those? OMAP has the invert pclk setting, but it also has a setting to define when the sync signals are driven. The options are: - syncs are driven on rising edge of pclk - syncs are driven on falling edge of pclk - syncs are driven on the opposite edge of pclk compared to the pixel data For DE there's no setting, except the active high/low. And if I'm not mistaken, if the optional properties are not defined, they are not ignored, but left to the default 0. Which means active low, or active on rising edge(?). I think it would be good to have a "undefined" value for the properties. > + - interlaced (bool): boolean to enable interlaced mode > + - doublescan (bool): boolean to enable doublescan mode > + - doubleclk (bool) As I mentioned in the other mail, doubleclk is not used nor documented here. > +All the optional properties that are not bool follow the following logic: > +<1>: high active > +<0>: low active > +omitted: not used on hardware > + > +There are different ways of describing the capabilities of a display. The > devicetree > +representation corresponds to the one commonly found in datasheets for > displays. > +If a display supports multiple signal timings, the native-mode can be > specified. I have some of the same concerns for this series than with the interpreted power sequences (on fbdev): when you publish the DT bindings, it's somewhat final version then, and fixing it later will be difficult. Of c
Re: [RFC v2 0/5] Common Display Framework
On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote: > On 2012-11-23 21:56, Thierry Reding wrote: > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > > [...] > >> Display entities are accessed by driver using notifiers. Any driver can > >> register a display entity notifier with the CDF, which then calls the > >> notifier > >> when a matching display entity is registered. The framebuffer layer has some similar 'anyone can' type notifier behaviour and its not a good thing. That kind of "any one can" behaviour leads to some really horrible messes unless the connections and the locking are well defined IMHO. Alan -- 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: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop
Hi Hans, On Mon, Nov 26, 2012 at 6:15 PM, Hans Verkuil wrote: > On Mon 26 November 2012 00:18:30 Alexey Klimov wrote: >> Hi Hans, >> >> On Fri, Nov 23, 2012 at 2:31 PM, Hans Verkuil wrote: >> > Hi Alexey, >> > >> > On Mon November 12 2012 19:41:57 Alexey Klimov wrote: >> >> Hi Mauro, Hans, all, >> >> >> >> On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab >> >> wrote: >> >> > Em Fri, 2 Nov 2012 14:47:49 +0100 >> >> > Hans Verkuil escreveu: >> >> > >> >> >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: >> >> >> > Em Thu, 1 Nov 2012 14:12:44 -0200 >> >> >> > Mauro Carvalho Chehab escreveu: >> >> >> > >> >> >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 >> >> >> > > Hans Verkuil escreveu: >> >> >> > > >> >> >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: >> >> >> > > > > Hi Hans, >> >> >> > > > > >> >> >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 >> >> >> > > > > Hans Verkuil escreveu: >> >> >> > > > > >> >> >> > > > > > Hi all, >> >> >> > > > > > >> >> >> > > > > > This is the tentative agenda for the media workshop on >> >> >> > > > > > November 8, 2012. >> >> >> > > > > > If you have additional things that you want to discuss, or >> >> >> > > > > > something is wrong >> >> >> > > > > > or incomplete in this list, please let me know so I can >> >> >> > > > > > update the list. >> >> >> > > > > >> >> >> > > > > Thank you for taking care of it. >> >> >> > > > > >> >> >> > > > > > - Explain current merging process (Mauro) >> >> >> > > > > > - Open floor for discussions on how to improve it (Mauro) >> >> >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) >> >> >> > > > > > drivers, both for >> >> >> > > > > > staging and mainline acceptance: which frameworks to use, >> >> >> > > > > > v4l2-compliance, >> >> >> > > > > > etc. (Hans Verkuil) >> >> >> > > > > > - V4L2 ambiguities (Hans Verkuil) >> >> >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat >> >> >> > > > > > - dmabuf status, esp. with regards to being able to test >> >> >> > > > > > (Mauro/Samsung) >> >> >> > > > > > - Device tree support (Guennadi, not known yet whether this >> >> >> > > > > > topic is needed) >> >> >> > > > > > - Creating/selecting contexts for hardware that supports >> >> >> > > > > > this (Samsung, only >> >> >> > > > > > if time is available) >> >> >> > > > > >> >> >> > > > > I have an extra theme for discussions there: what should we do >> >> >> > > > > with the drivers >> >> >> > > > > that don't have any MAINTAINERS entry. >> >> >> > > > >> >> >> > > > I've added this topic to the list. >> >> >> > > >> >> >> > > Thanks! >> >> >> > > >> >> >> > > > > It probably makes sense to mark them as "Orphan" (or, at >> >> >> > > > > least, have some >> >> >> > > > > criteria to mark them as such). Perhaps before doing that, we >> >> >> > > > > could try >> >> >> > > > > to see if are there any developer at the community with time >> >> >> > > > > and patience >> >> >> > > > > to handle them. >> >> >> > > > > >> >> >> > > > > This could of course be handled as part of the discussions >> >> >> > > > > about how to improve >> >> >> > > > > the merge process, but I suspect that this could generate >> >> >> > > > > enough discussions >> >> >> > > > > to be handled as a separate theme. >> >> >> > > > >> >> >> > > > Do we have a 'Maintainer-Light' category? I have a lot of >> >> >> > > > hardware that I can >> >> >> > > > test. So while I wouldn't like to be marked as 'The Maintainer >> >> >> > > > of driver X' >> >> >> > > > (since I simply don't have the time for that), I wouldn't mind >> >> >> > > > being marked as >> >> >> > > > someone who can at least test patches if needed. >> >> >> > > >> >> >> > > There are several "maintainance" status there: >> >> >> > > >> >> >> > > S: Status, one of the following: >> >> >> > > Supported: Someone is actually paid to look after this. >> >> >> > > Maintained: Someone actually looks after it. >> >> >> > > Odd Fixes: It has a maintainer but they don't have time to >> >> >> > > do >> >> >> > > much other than throw the odd patch in. See >> >> >> > > below.. >> >> >> > > Orphan: No current maintainer [but maybe you could take >> >> >> > > the >> >> >> > > role as you write your new code]. >> >> >> > > Obsolete:Old code. Something tagged obsolete generally >> >> >> > > means >> >> >> > > it has been replaced by a better system and you >> >> >> > > should be using that. >> >> >> > > >> >> >> > > (btw, I just realized that I should be changing the EDAC drivers I >> >> >> > > maintain >> >> >> > > to Supported; the media drivers I maintain should be kept as >> >> >> > > Maintained). >> >> >> > > >> >> >> > > I suspect that the "maintainer-light" category for those radio and >> >> >> > > similar >> >> >> > > old stuff is likely "Odd Fixes". >> >> >> > > >> >> >> > > > > There are some issu
Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop
On Mon 26 November 2012 00:18:30 Alexey Klimov wrote: > Hi Hans, > > On Fri, Nov 23, 2012 at 2:31 PM, Hans Verkuil wrote: > > Hi Alexey, > > > > On Mon November 12 2012 19:41:57 Alexey Klimov wrote: > >> Hi Mauro, Hans, all, > >> > >> On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab > >> wrote: > >> > Em Fri, 2 Nov 2012 14:47:49 +0100 > >> > Hans Verkuil escreveu: > >> > > >> >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: > >> >> > Em Thu, 1 Nov 2012 14:12:44 -0200 > >> >> > Mauro Carvalho Chehab escreveu: > >> >> > > >> >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 > >> >> > > Hans Verkuil escreveu: > >> >> > > > >> >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > >> >> > > > > Hi Hans, > >> >> > > > > > >> >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > >> >> > > > > Hans Verkuil escreveu: > >> >> > > > > > >> >> > > > > > Hi all, > >> >> > > > > > > >> >> > > > > > This is the tentative agenda for the media workshop on > >> >> > > > > > November 8, 2012. > >> >> > > > > > If you have additional things that you want to discuss, or > >> >> > > > > > something is wrong > >> >> > > > > > or incomplete in this list, please let me know so I can > >> >> > > > > > update the list. > >> >> > > > > > >> >> > > > > Thank you for taking care of it. > >> >> > > > > > >> >> > > > > > - Explain current merging process (Mauro) > >> >> > > > > > - Open floor for discussions on how to improve it (Mauro) > >> >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) > >> >> > > > > > drivers, both for > >> >> > > > > > staging and mainline acceptance: which frameworks to use, > >> >> > > > > > v4l2-compliance, > >> >> > > > > > etc. (Hans Verkuil) > >> >> > > > > > - V4L2 ambiguities (Hans Verkuil) > >> >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > >> >> > > > > > - dmabuf status, esp. with regards to being able to test > >> >> > > > > > (Mauro/Samsung) > >> >> > > > > > - Device tree support (Guennadi, not known yet whether this > >> >> > > > > > topic is needed) > >> >> > > > > > - Creating/selecting contexts for hardware that supports this > >> >> > > > > > (Samsung, only > >> >> > > > > > if time is available) > >> >> > > > > > >> >> > > > > I have an extra theme for discussions there: what should we do > >> >> > > > > with the drivers > >> >> > > > > that don't have any MAINTAINERS entry. > >> >> > > > > >> >> > > > I've added this topic to the list. > >> >> > > > >> >> > > Thanks! > >> >> > > > >> >> > > > > It probably makes sense to mark them as "Orphan" (or, at least, > >> >> > > > > have some > >> >> > > > > criteria to mark them as such). Perhaps before doing that, we > >> >> > > > > could try > >> >> > > > > to see if are there any developer at the community with time > >> >> > > > > and patience > >> >> > > > > to handle them. > >> >> > > > > > >> >> > > > > This could of course be handled as part of the discussions > >> >> > > > > about how to improve > >> >> > > > > the merge process, but I suspect that this could generate > >> >> > > > > enough discussions > >> >> > > > > to be handled as a separate theme. > >> >> > > > > >> >> > > > Do we have a 'Maintainer-Light' category? I have a lot of > >> >> > > > hardware that I can > >> >> > > > test. So while I wouldn't like to be marked as 'The Maintainer of > >> >> > > > driver X' > >> >> > > > (since I simply don't have the time for that), I wouldn't mind > >> >> > > > being marked as > >> >> > > > someone who can at least test patches if needed. > >> >> > > > >> >> > > There are several "maintainance" status there: > >> >> > > > >> >> > > S: Status, one of the following: > >> >> > > Supported: Someone is actually paid to look after this. > >> >> > > Maintained: Someone actually looks after it. > >> >> > > Odd Fixes: It has a maintainer but they don't have time to do > >> >> > > much other than throw the odd patch in. See > >> >> > > below.. > >> >> > > Orphan: No current maintainer [but maybe you could take > >> >> > > the > >> >> > > role as you write your new code]. > >> >> > > Obsolete:Old code. Something tagged obsolete generally > >> >> > > means > >> >> > > it has been replaced by a better system and you > >> >> > > should be using that. > >> >> > > > >> >> > > (btw, I just realized that I should be changing the EDAC drivers I > >> >> > > maintain > >> >> > > to Supported; the media drivers I maintain should be kept as > >> >> > > Maintained). > >> >> > > > >> >> > > I suspect that the "maintainer-light" category for those radio and > >> >> > > similar > >> >> > > old stuff is likely "Odd Fixes". > >> >> > > > >> >> > > > > There are some issues by not having a MAINTAINERS entry: > >> >> > > > > - patches may not flow into the driver maintainer; > >> >> > > > > - patches will likely be applied without tests/reviews o
Re: [patch review 01/02] add driver for Masterkit MA901 usb radio
On Mon 26 November 2012 13:47:36 Alexey Klimov wrote:
> Hi Hans,
>
> On Fri, Nov 23, 2012 at 3:42 PM, Hans Verkuil wrote:
> > Hi Alexey,
> >
> > Some (small) comments below...
> >
> > On Mon October 29 2012 02:41:10 Alexey Klimov wrote:
> >> This patch creates a new usb-radio driver, radio-ma901.c, that supports
> >> Masterkit MA 901 USB FM radio devices. This device plugs into both the
> >> USB and an analog audio input or headphones, so this thing only deals
> >> with initialization and frequency setting.
> >>
> >> Signed-off-by: Alexey Klimov
> >>
> >>
> >> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> >> index 8090b87..ead9928 100644
> >> --- a/drivers/media/radio/Kconfig
> >> +++ b/drivers/media/radio/Kconfig
> >> @@ -124,6 +124,18 @@ config USB_KEENE
> >> To compile this driver as a module, choose M here: the
> >> module will be called radio-keene.
> >>
> >> +config USB_MA901
> >> + tristate "Masterkit MA901 USB FM radio support"
> >> + depends on USB && VIDEO_V4L2
> >> + ---help---
> >> + Say Y here if you want to connect this type of radio to your
> >> + computer's USB port. Note that the audio is not digital, and
> >> + you must connect the line out connector to a sound card or a
> >> + set of speakers or headphones.
> >> +
> >> + To compile this driver as a module, choose M here: the
> >> + module will be called radio-ma901.
> >> +
> >> config RADIO_TEA5764
> >> tristate "TEA5764 I2C FM radio support"
> >> depends on I2C && VIDEO_V4L2
> >> diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
> >> index c03ce4f..303eaeb 100644
> >> --- a/drivers/media/radio/Makefile
> >> +++ b/drivers/media/radio/Makefile
> >> @@ -24,6 +24,7 @@ obj-$(CONFIG_USB_DSBR) += dsbr100.o
> >> obj-$(CONFIG_RADIO_SI470X) += si470x/
> >> obj-$(CONFIG_USB_MR800) += radio-mr800.o
> >> obj-$(CONFIG_USB_KEENE) += radio-keene.o
> >> +obj-$(CONFIG_USB_MA901) += radio-ma901.o
> >> obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
> >> obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
> >> obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
> >> diff --git a/drivers/media/radio/radio-ma901.c
> >> b/drivers/media/radio/radio-ma901.c
> >> new file mode 100644
> >> index 000..987e4db
> >> --- /dev/null
> >> +++ b/drivers/media/radio/radio-ma901.c
> >> @@ -0,0 +1,461 @@
> >> +/*
> >> + * Driver for the MasterKit MA901 USB FM radio. This device plugs
> >> + * into the USB port and an analog audio input or headphones, so this
> >> thing
> >> + * only deals with initialization, frequency setting, volume.
> >> + *
> >> + * Copyright (c) 2012 Alexey Klimov
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, write to the Free Software
> >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#define DRIVER_AUTHOR "Alexey Klimov "
> >> +#define DRIVER_DESC "Masterkit MA901 USB FM radio driver"
> >> +#define DRIVER_VERSION "0.0.1"
> >> +
> >> +MODULE_AUTHOR(DRIVER_AUTHOR);
> >> +MODULE_DESCRIPTION(DRIVER_DESC);
> >> +MODULE_LICENSE("GPL");
> >> +MODULE_VERSION(DRIVER_VERSION);
> >> +
> >> +#define USB_MA901_VENDOR 0x16c0
> >> +#define USB_MA901_PRODUCT 0x05df
> >> +
> >> +/* dev_warn macro with driver name */
> >> +#define MA901_DRIVER_NAME "radio-ma901"
> >> +#define ma901radio_dev_warn(dev, fmt, arg...)
> >>\
> >> + dev_warn(dev, MA901_DRIVER_NAME " - " fmt, ##arg)
> >> +
> >> +#define ma901radio_dev_err(dev, fmt, arg...) \
> >> + dev_err(dev, MA901_DRIVER_NAME " - " fmt, ##arg)
> >> +
> >> +/* Probably USB_TIMEOUT should be modified in module parameter */
> >> +#define BUFFER_LENGTH 8
> >> +#define USB_TIMEOUT 500
> >> +
> >> +#define FREQ_MIN 87.5
> >> +#define FREQ_MAX 108.0
> >> +#define FREQ_MUL 16000
> >> +
> >> +#define MA901_VOLUME_MAX 16
> >> +#define MA901_VOLUME_MIN 0
> >> +
> >> +/* Commands that device should understand
> >> + * List isn't full and will be updated with implementation of new
> >> functions
> >> + */
> >> +#define MA901_RADIO_SET_FREQ 0x03
> >> +#define MA901_RADIO_
Re: [PATCH] gspca - ov534: Fix the light frequency filter
On Fri, 23 Nov 2012 19:12:32 +0100
Jean-Francois Moine wrote:
> On Fri, 23 Nov 2012 18:09:09 +0100
> Antonio Ospite wrote:
[...]
> > In the datasheet I have for ov772x, bit[6] of register 0x13 is described
> > as:
> >
> > Bit[6]: AEC - Step size limit
> > 0: Step size is limited to vertical blank
> > 1: Unlimited step size
>
> Right, but I don't use the bit 6, it is the bit 5:
>
Ouch, right! :)
> > > + sccb_reg_write(gspca_dev, 0x13, /* auto */
> > > + sccb_reg_read(gspca_dev, 0x13) | 0x20);
>
> which is described as:
>
>Bit[5]: Banding filter ON/OFF
>
> > And the patch makes Light Frequency _NOT_ work with the PS3 eye (based
> > on ov772x).
> >
> > What does the ov767x datasheet say?
>
> Quite the same thing:
>
>Bit[5]: Banding filter ON/OFF - In order to turn ON the banding
>filter, BD50ST (0x9D) or BD60ST (0x9E) must be set to a
>non-zero value.
>0: OFF
>1: ON
>
> (the registers 9d and 9e are non zero for the ov767x in ov534.c)
>
In the ov767x datasheet I also see that selecting _what_ filter to
apply is done in Bit[3] of register 0x3B, but I couldn't find such info
for ov772x. (FYI a datasheet for ov7740 can be found on the web with
some theory but resisters are not always the same as ov772x).
> > Maybe we should use the new values only when
> > sd->sensor == SENSOR_OV767x
> >
> > What sensor does Alexander's webcam use?
>
> He has exactly the same webcam as yours: 1415:2000 (ps eye) with
> sensor ov772x.
>
> > > Note: The light frequency filter is either off or automatic.
> > > The application will see either off or "50Hz" only.
> > >
> > > Tested-by: alexander calderon
> > > Signed-off-by: Jean-François Moine
> > >
> > > --- a/drivers/media/usb/gspca/ov534.c
> > > +++ b/drivers/media/usb/gspca/ov534.c
> > > @@ -1038,13 +1038,12 @@
> > > {
> > > struct sd *sd = (struct sd *) gspca_dev;
> > >
> >
> > drivers/media/usb/gspca/ov534.c: In function ‘setlightfreq’:
> > drivers/media/usb/gspca/ov534.c:1039:13: warning: unused variable ‘sd’
> > [-Wunused-variable]
>
> Thanks.
>
> Well, here is one of the last message I received from Alexander (in
> fact, his first name is Fabian):
>
> > Thanks for all your help, it is very kind of you, I used the code below,the
> > 60 Hz filter appear to work even at 100fps, but when I used 125 fps it
> > didnt work :( , i guess it is something of detection speed. If you have any
> > other idea I'll be very thankful.
> >
> > Sincerely Fabian Calderon
>
So he is in a place where a 60Hz power source is used?.
> So, how may we advance?
For now I'd NAK the patch since it is a regression for users
with 50Hz power sources and it looks like it does not _always_ work for
60Hz either.
Should I remove it from patchwork as well?
As I have the webcam and can perform actual tests I'll coordinate with
Fabian to have more details about why light frequency filter is not
working for him with the current code, it works fine for me at 640x480,
even if I can see that its effect is weaker at 320x240.
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
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 review 01/02] add driver for Masterkit MA901 usb radio
Hi Hans,
On Fri, Nov 23, 2012 at 3:42 PM, Hans Verkuil wrote:
> Hi Alexey,
>
> Some (small) comments below...
>
> On Mon October 29 2012 02:41:10 Alexey Klimov wrote:
>> This patch creates a new usb-radio driver, radio-ma901.c, that supports
>> Masterkit MA 901 USB FM radio devices. This device plugs into both the
>> USB and an analog audio input or headphones, so this thing only deals
>> with initialization and frequency setting.
>>
>> Signed-off-by: Alexey Klimov
>>
>>
>> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
>> index 8090b87..ead9928 100644
>> --- a/drivers/media/radio/Kconfig
>> +++ b/drivers/media/radio/Kconfig
>> @@ -124,6 +124,18 @@ config USB_KEENE
>> To compile this driver as a module, choose M here: the
>> module will be called radio-keene.
>>
>> +config USB_MA901
>> + tristate "Masterkit MA901 USB FM radio support"
>> + depends on USB && VIDEO_V4L2
>> + ---help---
>> + Say Y here if you want to connect this type of radio to your
>> + computer's USB port. Note that the audio is not digital, and
>> + you must connect the line out connector to a sound card or a
>> + set of speakers or headphones.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called radio-ma901.
>> +
>> config RADIO_TEA5764
>> tristate "TEA5764 I2C FM radio support"
>> depends on I2C && VIDEO_V4L2
>> diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
>> index c03ce4f..303eaeb 100644
>> --- a/drivers/media/radio/Makefile
>> +++ b/drivers/media/radio/Makefile
>> @@ -24,6 +24,7 @@ obj-$(CONFIG_USB_DSBR) += dsbr100.o
>> obj-$(CONFIG_RADIO_SI470X) += si470x/
>> obj-$(CONFIG_USB_MR800) += radio-mr800.o
>> obj-$(CONFIG_USB_KEENE) += radio-keene.o
>> +obj-$(CONFIG_USB_MA901) += radio-ma901.o
>> obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
>> obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
>> obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
>> diff --git a/drivers/media/radio/radio-ma901.c
>> b/drivers/media/radio/radio-ma901.c
>> new file mode 100644
>> index 000..987e4db
>> --- /dev/null
>> +++ b/drivers/media/radio/radio-ma901.c
>> @@ -0,0 +1,461 @@
>> +/*
>> + * Driver for the MasterKit MA901 USB FM radio. This device plugs
>> + * into the USB port and an analog audio input or headphones, so this thing
>> + * only deals with initialization, frequency setting, volume.
>> + *
>> + * Copyright (c) 2012 Alexey Klimov
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRIVER_AUTHOR "Alexey Klimov "
>> +#define DRIVER_DESC "Masterkit MA901 USB FM radio driver"
>> +#define DRIVER_VERSION "0.0.1"
>> +
>> +MODULE_AUTHOR(DRIVER_AUTHOR);
>> +MODULE_DESCRIPTION(DRIVER_DESC);
>> +MODULE_LICENSE("GPL");
>> +MODULE_VERSION(DRIVER_VERSION);
>> +
>> +#define USB_MA901_VENDOR 0x16c0
>> +#define USB_MA901_PRODUCT 0x05df
>> +
>> +/* dev_warn macro with driver name */
>> +#define MA901_DRIVER_NAME "radio-ma901"
>> +#define ma901radio_dev_warn(dev, fmt, arg...)
>> \
>> + dev_warn(dev, MA901_DRIVER_NAME " - " fmt, ##arg)
>> +
>> +#define ma901radio_dev_err(dev, fmt, arg...) \
>> + dev_err(dev, MA901_DRIVER_NAME " - " fmt, ##arg)
>> +
>> +/* Probably USB_TIMEOUT should be modified in module parameter */
>> +#define BUFFER_LENGTH 8
>> +#define USB_TIMEOUT 500
>> +
>> +#define FREQ_MIN 87.5
>> +#define FREQ_MAX 108.0
>> +#define FREQ_MUL 16000
>> +
>> +#define MA901_VOLUME_MAX 16
>> +#define MA901_VOLUME_MIN 0
>> +
>> +/* Commands that device should understand
>> + * List isn't full and will be updated with implementation of new functions
>> + */
>> +#define MA901_RADIO_SET_FREQ 0x03
>> +#define MA901_RADIO_SET_VOLUME 0x04
>> +#define MA901_RADIO_SET_MONO_STEREO 0x05
>> +
>> +/* Comfortable defines for ma901radio_set_stereo */
>> +#define MA901_WANT_STEREO0x50
>> +#define MA901_WANT_MONO 0xd0
>> +
>> +/* module parameter */
>> +static int radio_nr = -1;
>> +module_param(radio_nr,
Re: [PATCHv15 2/7] video: add display_timing and videomode
On 2012-11-26 11:07, Steffen Trumtrar wrote:
> +/*
> + * Subsystem independent description of a videomode.
> + * Can be generated from struct display_timing.
> + */
> +struct videomode {
> + u32 pixelclock; /* pixelclock in Hz */
I don't know if this is of any importance, but the linux clock framework
manages clock rates with unsigned long. Would it be better to use the
same type here?
> + u32 hactive;
> + u32 hfront_porch;
> + u32 hback_porch;
> + u32 hsync_len;
> +
> + u32 vactive;
> + u32 vfront_porch;
> + u32 vback_porch;
> + u32 vsync_len;
> +
> + u32 hah;/* hsync active high */
> + u32 vah;/* vsync active high */
> + u32 de; /* data enable */
> + u32 pixelclk_pol;
What values will these 4 have? Aren't these booleans?
The data enable comment should be "data enable active high".
The next patch says in the devtree binding documentation that the values
may be on/off/ignored. Is that represented here somehow, i.e. values are
0/1/2 or so? If not, what does it mean if the value is left out from
devtree data, meaning "not used on hardware"?
There's also a "doubleclk" value mentioned in the devtree bindings doc,
but not shown here.
I think this videomode struct is the one that display drivers are going
to use (?), in addition to the display_timing, so it would be good to
document it well.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCHv15 0/7] of: add display helper
Hi! Changes since v14: - fix "const struct *" warning (reported by: Leela Krishna Amudala ) - return -EINVAL when htotal or vtotal are zero - remove unreachable code in of_get_display_timings - include headers in .c files and not implicit in .h - sort includes alphabetically - fix lower/uppercase in binding documentation - rebase onto v3.7-rc7 Changes since v13: - fix "const struct *" warning (reported by: Laurent Pinchart ) - prevent division by zero in fb_videomode_from_videomode Changes since v12: - rename struct display_timing to via_display_timing in via subsystem - fix refreshrate calculation - fix "const struct *" warnings (reported by: Manjunathappa, Prakash ) - some CodingStyle fixes - rewrite parts of commit messages and display-timings.txt - let display_timing_get_value get all values instead of just typical Changes since v11: - make pointers const where applicable - add reviewed-by Laurent Pinchart Changes since v10: - fix function name (drm_)display_mode_from_videomode - add acked-by, reviewed-by, tested-by Changes since v9: - don't leak memory when previous timings were correct - CodingStyle fixes - move blank lines around Changes since v8: - fix memory leaks - change API to be more consistent (foo_from_bar(struct bar, struct foo)) - include headers were necessary - misc minor bufixe Changes since v7: - move of_xxx to drivers/video - remove non-binding documentation from display-timings.txt - squash display_timings and videomode in one patch - misc minor fixes Changes since v6: - get rid of some empty lines etc. - move functions to their subsystems - split of_ from non-of_ functions - add at least some kerneldoc to some functions Changes since v5: - removed all display stuff and just describe timings Changes since v4: - refactored functions Changes since v3: - print error messages - free alloced memory - general cleanup Changes since v2: - use hardware-near property-names - provide a videomode structure - allow ranges for all properties () - functions to get display_mode or fb_videomode Steffen Trumtrar (7): viafb: rename display_timing to via_display_timing video: add display_timing and videomode video: add of helper for display timings/videomode fbmon: add videomode helpers fbmon: add of_videomode helpers drm_modes: add videomode helpers drm_modes: add of_videomode helpers .../devicetree/bindings/video/display-timing.txt | 107 ++ drivers/gpu/drm/drm_modes.c| 70 +++ drivers/video/Kconfig | 21 ++ drivers/video/Makefile |4 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 93 + drivers/video/of_display_timing.c | 219 drivers/video/of_videomode.c | 54 + drivers/video/via/hw.c |6 +- drivers/video/via/hw.h |2 +- drivers/video/via/lcd.c|2 +- drivers/video/via/share.h |2 +- drivers/video/via/via_modesetting.c|8 +- drivers/video/via/via_modesetting.h|6 +- drivers/video/videomode.c | 44 include/drm/drmP.h | 13 ++ include/linux/display_timing.h | 104 ++ include/linux/fb.h | 12 ++ include/linux/of_display_timing.h | 20 ++ include/linux/of_videomode.h | 18 ++ include/linux/videomode.h | 54 + 21 files changed, 870 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/display_timing.h create mode 100644 include/linux/of_display_timing.h create mode 100644 include/linux/of_videomode.h create mode 100644 include/linux/videomode.h -- 1.7.10.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
[PATCHv15 1/7] viafb: rename display_timing to via_display_timing
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, that is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar
---
drivers/video/via/hw.c |6 +++---
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c |2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c |8
drivers/video/via/via_modesetting.h |6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct
fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var->xres, cyres ? cyres : var->yres);
if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo
*var, u16 cxres,
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include "debug.h"
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total / 8 - 5;
raw.hor_addr = timing->hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total - 1;
raw.hor_addr = timing->hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing *timing);
void vi
[PATCHv15 7/7] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/drm_modes.c | 33 +
include/drm/drmP.h |6 ++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 8263ea1..3568f0a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_videomode(&vm, dmode);
+
+ pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+ vm.vactive, np->name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2194e97..1784e55 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
struct drm_file;
struct drm_device;
+struct device_node;
struct videomode;
#include
@@ -1460,6 +1461,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
+#endif
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.7.10.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
[PATCHv15 3/7] video: add of helper for display timings/videomode
This adds support for reading display timings from DT into a struct display_timings. The of_display_timing implementation supports multiple subnodes. All children are read into an array, that can be queried. If no native mode is specified, the first subnode will be used. For cases where the graphics driver knows there can be only one mode description or where the driver only supports one mode, a helper function of_get_videomode is added, that gets a struct videomode from DT. Signed-off-by: Steffen Trumtrar Signed-off-by: Philipp Zabel Acked-by: Stephen Warren Reviewed-by: Thierry Reding Acked-by: Thierry Reding Tested-by: Thierry Reding Tested-by: Philipp Zabel Reviewed-by: Laurent Pinchart Acked-by: Laurent Pinchart --- .../devicetree/bindings/video/display-timing.txt | 107 ++ drivers/video/Kconfig | 15 ++ drivers/video/Makefile |2 + drivers/video/of_display_timing.c | 219 drivers/video/of_videomode.c | 54 + include/linux/of_display_timing.h | 20 ++ include/linux/of_videomode.h | 18 ++ 7 files changed, 435 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 include/linux/of_display_timing.h create mode 100644 include/linux/of_videomode.h diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt new file mode 100644 index 000..e238f27 --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timing.txt @@ -0,0 +1,107 @@ +display-timing bindings +=== + +display-timings node + + +required properties: + - none + +optional properties: + - native-mode: The native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +timing subnode +-- + +required properties: + - hactive, vactive: display resolution + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: vertical display timing parameters in + lines + - clock-frequency: display clock in Hz + +optional properties: + - hsync-active: hsync pulse is active low/high/ignored + - vsync-active: vsync pulse is active low/high/ignored + - de-active: data-enable pulse is active low/high/ignored + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/ + non-inverted (active on rising edge)/ +ignored (ignore property) + - interlaced (bool): boolean to enable interlaced mode + - doublescan (bool): boolean to enable doublescan mode + - doubleclk (bool) + +All the optional properties that are not bool follow the following logic: +<1>: high active +<0>: low active +omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The devicetree +representation corresponds to the one commonly found in datasheets for displays. +If a display supports multiple signal timings, the native-mode can be specified. + +The parameters are defined as + + +--+-+--+---+ + | |↑| | | + | ||vback_porch | | | + | |↓| | | + +--###--+---+ + | #↑# | | + | #|# | | + | hback #|# hfront | hsync | + | porch #| hactive # porch | len | + |<>#<---+--->#<>|<->| + | #|# | | + | #|vactive # | | + | #|# | | + | #↓# | | + +--###--+---+ + | |↑| | | + | ||vfront_porch| | | + | |↓| | | + +--+-+--+---+ + | |↑
[PATCHv15 5/7] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Signed-off-by: Steffen Trumtrar
---
drivers/video/fbmon.c | 42 ++
include/linux/fb.h|6 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 733553b..4a8484d 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -28,6 +28,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -1424,6 +1425,47 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u
%u\n",
+m->xres, m->yres, m->refresh, m->pixclock, m->left_margin,
+m->right_margin, m->upper_margin, m->lower_margin,
+m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_videomode(&vm, fb);
+
+ pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+ vm.vactive, np->name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 4404ec2..c2d933d 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ int index);
+#endif
#if IS_ENABLED(CONFIG_VIDEOMODE)
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
1.7.10.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
[PATCHv15 4/7] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Signed-off-by: Steffen Trumtrar
---
drivers/video/fbmon.c | 51 +
include/linux/fb.h|6 ++
2 files changed, 57 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..733553b 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PPC_OF
#include
@@ -1373,6 +1374,56 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ fbmode->xres = vm->hactive;
+ fbmode->left_margin = vm->hback_porch;
+ fbmode->right_margin = vm->hfront_porch;
+ fbmode->hsync_len = vm->hsync_len;
+
+ fbmode->yres = vm->vactive;
+ fbmode->upper_margin = vm->vback_porch;
+ fbmode->lower_margin = vm->vfront_porch;
+ fbmode->vsync_len = vm->vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode->pixclock = vm->pixelclock ? KHZ2PICOS(vm->pixelclock / 1000) :
0;
+
+ fbmode->sync = 0;
+ fbmode->vmode = 0;
+ if (vm->hah)
+ fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm->vah)
+ fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm->interlaced)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+ if (vm->doublescan)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+ fbmode->flag = 0;
+
+ htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
+vm->hsync_len;
+ vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
+vm->vsync_len;
+ /* prevent division by zero */
+ if (htotal && vtotal)
+ fbmode->refresh = vm->pixelclock / (htotal * vtotal);
+ /* a mode must have htotal and vtotal != 0 or it is invalid */
+ else {
+ fbmode->refresh = 0;
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..4404ec2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode);
+#endif
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
1.7.10.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
[PATCHv15 2/7] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off
As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.
Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.
The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.
This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/video/Kconfig |6 +++
drivers/video/Makefile |2 +
drivers/video/display_timing.c | 24 ++
drivers/video/videomode.c | 44 +
include/linux/display_timing.h | 104
include/linux/videomode.h | 54 +
6 files changed, 234 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/linux/display_timing.h
create mode 100644 include/linux/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool
+
+config VIDEOMODE
+ bool
+
menuconfig FB
tristate "Support for frame buffer devices"
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..ac9bbbc
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include
+#include
+#include
+
+void display_timings_release(struct display_timings *disp)
+{
+ if (disp->timings) {
+ unsigned int i;
+
+ for (i = 0; i < disp->num_timings; i++)
+ kfree(disp->timings[i]);
+ kfree(disp->timings);
+ }
+ kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..784eaad
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,44 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include
+#include
+#include
+#include
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+ struct display_timing *dt;
+
+ dt = display_timings_get(disp, index);
+ if (!dt)
+ return -EINVAL;
+
+ vm->pixelclock = display_timing_get_value(&dt->pixelclock, TE_TYP);
+ vm->hactive = display_timing_get_value(&dt->hactive, TE_TYP);
+ vm->hfront_porch = display_timing_get_value(&dt->hfront_porch, TE_TYP);
+ vm->hback_porch = display_timing_get_value(&dt->hback_porch, TE_TYP);
+ vm->hsync_len = display_timing_get_value(&dt->hsync_len, TE_TYP);
+
+ vm->vactive = display_timing_get_value(&dt->vactive, TE_TYP);
+ vm->vfront_porch = display_timing_get_value(&dt->vfront_
[PATCHv15 6/7] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Signed-off-by: Steffen Trumtrar
---
drivers/gpu/drm/drm_modes.c | 37 +
include/drm/drmP.h |7 +++
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..8263ea1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode)
+{
+ dmode->hdisplay = vm->hactive;
+ dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+ dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+ dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+ dmode->vdisplay = vm->vactive;
+ dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+ dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+ dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+ dmode->clock = vm->pixelclock / 1000;
+
+ dmode->flags = 0;
+ if (vm->hah)
+ dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm->vah)
+ dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm->interlaced)
+ dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm->doublescan)
+ dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..2194e97 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
struct drm_file;
struct drm_device;
+struct videomode;
+
#include
#include
#include
@@ -1454,6 +1456,11 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode);
+#endif
+
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
--
1.7.10.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: DMABUF V4L2 patches got merged
Hi Aditya. FYI, just in case you have not seen this email. Thanks, Thomas. On 26 November 2012 01:32, Mauro Carvalho Chehab wrote: > Hi all, > > Today, I finally merged the DMABUF V4L2 patches from Tomasz. > > The DMABUF allows replacing the old V4L2 Overlay method by something more > robust and safer. > > It was a long road to get them ready for their upstream inclusion, and to > be able to test on both embedded and personal computers. > > Along this weekend, I was able to test it using 4 different test scenarios: > > - vivi + s5p-tv; > - uvcvideo + fimc (m2m) + s5p-tv; > - s5k4ecgx + fimc (m2m) + s5p-tv; > - uvcvideo + i915. > > The first 3 tests ran on a Samsung Origen Rev. A board; the 4th one on a > notebook, with a Sandy Bridge i5core processor with GPU, and an embedded > UVC camera. > > While testing the s5k4ecgx sensor driver, I also added support for multiplane > at libv4l, via its plugin interface: > > > http://git.linuxtv.org/v4l-utils.git/commit/ced1be346fe4f61c864cba9d81f66089d4e32a56 > > Such tests wouldn't be possible without the help of Linaro and Samsung, > with donated me some hardware for the tests, and Ideas on Board for making > uvcvideo + i915 driver to work especially for this test. > > Thank you all for your support! > > In particular, Sylwester helped me a lot to fix several non-related issues > with > the Origen board, that was not running with an upstream Kernel. > > There are a number of patches required to make the Origen board to work with > an > Upstream Kernel. Also, its sensor driver (s5k4ecgx) was not submitted upstream > yet. In order to help others that may need to do similar tests, I added the > needed patches on my experimental tree, at branch origen+dmabuf: > > > http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/origen%2Bdmabuf > > Still missing there are the wireless/bluetooth support. It seems that there > are > some patches for it already, but they aren't submitted upstream, nor I didn't > test they. > > I expect that Linaro and Samsung will be able to submit real soon the pending > patches needed by Origen in time for its addition on 3.8. > > Thank you all! > Mauro > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > 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
