Re: small regression in mediatree/for_v3.7-3 - media_build
On Tue, Aug 14, 2012 at 4:51 PM, Antti Palosaari wrote: >> There seems to be a small regression on mediatree/for_v3.7-3 >> - dmesg/klog get flooded with these: >> >> [201145.140260] dvb_frontend_poll: 15 callbacks suppressed >> [201145.586405] usb_urb_complete: 88 callbacks suppressed >> [201150.587308] usb_urb_complete: 3456 callbacks suppressed >> >> [201468.630197] usb_urb_complete: 3315 callbacks suppressed >> [201473.632978] usb_urb_complete: 3529 callbacks suppressed >> [201478.635400] usb_urb_complete: 3574 callbacks suppressed >> >> It seems to be every 5 seconds, but I think that's just klog skipping >> repeats and collapsing duplicate entries. This does not happen the last time >> I tried playing with the TV stick :-). > > That's because you has dynamic debugs enabled! > modprobe dvb_core; echo -n 'module dvb_core +p' > > /sys/kernel/debug/dynamic_debug/control > modprobe dvb_usbv2; echo -n 'module dvb_usbv2 +p' > > /sys/kernel/debug/dynamic_debug/control > > If you don't add dvb_core and dvb_usbv2 modules to > /sys/kernel/debug/dynamic_debug/control you will not see those. I'm getting massive amounts of "dvb_frontend_poll: 20 callbacks suppressed" messages in dmesg also and I definitely did not put dvb_core or anything else in /sys/kernel/debug/dynamic_debug/control. For that matter I don't even have a /sys/kernel/debug/dynamic_debug/control file. > I have added ratelimited version for those few debugs that are flooded > normally. This suppressed is coming from ratelimit - it does not print all > those similar debugs. I'm using kernel 3.6.3 with media_build from Oct. 21, 2012. How I can disable those messages? I'd rather not see hundreds, possibly thousands or millions of those messages. :) -- 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] stkwebcam: Fix sparse warning on undeclared symbol
> If you have the time to test it and stamp a "Tested-by" on it, I would
> appreciate it.
>
> Thanks,
>
> Ezequiel
I applied and tested on 3.7.0-rc3 - everything is ok.
Signed patch is bellow.
Signed-off-by: Ezequiel Garcia
Tested-by: Arvydas Sidorenko
---
drivers/media/usb/stkwebcam/stk-webcam.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c
b/drivers/media/usb/stkwebcam/stk-webcam.c
index 86a0fc5..e4839d8 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -55,9 +55,6 @@ MODULE_AUTHOR("Jaime Velasco Juan
and Nicolas VIVIEN");
MODULE_DESCRIPTION("Syntek DC1125 webcam driver");
-/* bool for webcam LED management */
-int first_init = 1;
-
/* Some cameras have audio interfaces, we aren't interested in those */
static struct usb_device_id stkwebcam_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x174f, 0xa311, 0xff, 0xff, 0xff) },
@@ -554,6 +551,7 @@ static void stk_free_buffers(struct stk_camera *dev)
static int v4l_stk_open(struct file *fp)
{
+static int first_init = 1; /* webcam LED management */
struct stk_camera *dev;
struct video_device *vdev;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Nov 2 19:00:23 CET 2012 git hash:8f7e91a31fb95c50880c76505b416630c0326d93 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Looks like the iommu framework does not have generic functions
exported for all the needs yet. The hardware specific functions
are defined in files like intel-iommu.h and amd-iommu.h. Follow
the same standard for omap-iommu.h.
This is needed because we are removing plat and mach includes
for ARM common zImage support. Further work should continue
in the iommu framework context as only pure platform data will
be communicated from arch/arm/*omap*/* code to the iommu
framework.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Omar Ramirez Luna
Cc: linux-media@vger.kernel.org
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/iommu2.c |1
arch/arm/plat-omap/include/plat/iommu.h| 10 +--
arch/arm/plat-omap/include/plat/iovmm.h| 89
drivers/iommu/omap-iommu-debug.c |2 -
drivers/iommu/omap-iommu.c |1
drivers/iommu/omap-iovmm.c | 46 ++
drivers/media/platform/omap3isp/isp.c |1
drivers/media/platform/omap3isp/isp.h |4 -
drivers/media/platform/omap3isp/ispccdc.c |1
drivers/media/platform/omap3isp/ispstat.c |1
drivers/media/platform/omap3isp/ispvideo.c |2 -
include/linux/omap-iommu.h | 52
12 files changed, 107 insertions(+), 103 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
create mode 100644 include/linux/omap-iommu.h
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..e8116cf 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 7e8c7b6..a4b71b1 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -216,13 +216,10 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define MMU_RAM_PADDR_SHIFT12
#define MMU_RAM_PADDR_MASK \
((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
-#define MMU_RAM_ENDIAN_SHIFT 9
+
#define MMU_RAM_ENDIAN_MASK(1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ELSZ_SHIFT 7
#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+
#define MMU_RAM_ELSZ_16(1 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_32(2 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
@@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
void *priv),
void *isr_priv);
-extern void omap_iommu_save_ctx(struct device *dev);
-extern void omap_iommu_restore_ctx(struct device *dev);
-
extern int omap_install_iommu_arch(const struct iommu_functions *ops);
extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/arch/arm/plat-omap/include/plat/iovmm.h
deleted file mode 100644
index 498e57c..000
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * omap iommu: simple virtual address space management
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __IOMMU_MMAP_H
-#define __IOMMU_MMAP_H
-
-#include
-
-struct iovm_struct {
- struct omap_iommu *iommu; /* iommu object which this belongs to */
- u32 da_start; /* area definition */
- u32 da_end;
- u32 flags; /* IOVMF_: see below */
- struct list_headlist; /* linked in ascending order */
- const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
- void*va; /* mpu side mapped address */
-};
-
-/*
- * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
- *
- * lower 16 bit is used for h/w and upper 16 bit is for s/w.
- */
-#define IOVMF_SW_SHIFT 16
-
-/*
- * iovma: h/w flags derived from cam and ram attribute
- */
-#define IOVMF_CAM_MASK (~((1 << 10) - 1))
-#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
-
-#define IOVMF_PGSZ_MASK(3 << 0)
-#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
-#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
-#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
-#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
-
-#define IOVMF_ENDIAN_MASK (1 << 9)
-#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIA
[PATCH 4/6] ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c
This file should not be in arch/arm. Move it to drivers/iommu
to allow making most of the header local to drivers/iommu.
This is needed as we are removing plat and mach includes
from drivers for ARM common zImage support.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile|2
arch/arm/plat-omap/include/plat/iommu.h | 272 ++-
drivers/iommu/Makefile |1
drivers/iommu/omap-iommu-debug.c|1
drivers/iommu/omap-iommu.c | 19 ++
drivers/iommu/omap-iommu.h | 255 +
drivers/iommu/omap-iommu2.c |2
drivers/iommu/omap-iopgtable.h | 22 ---
drivers/iommu/omap-iovmm.c |1
9 files changed, 293 insertions(+), 282 deletions(-)
create mode 100644 drivers/iommu/omap-iommu.h
rename arch/arm/mach-omap2/iommu2.c => drivers/iommu/omap-iommu2.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..d6721a7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -184,8 +184,6 @@ obj-$(CONFIG_HW_PERF_EVENTS)+= pmu.o
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
-obj-$(CONFIG_OMAP_IOMMU) += iommu2.o
-
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index a4b71b1..c677b9f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -10,103 +10,21 @@
* published by the Free Software Foundation.
*/
-#ifndef __MACH_IOMMU_H
-#define __MACH_IOMMU_H
-
-#include
-
-#if defined(CONFIG_ARCH_OMAP1)
-#error "iommu for this processor not implemented yet"
-#endif
-
-struct iotlb_entry {
- u32 da;
- u32 pa;
- u32 pgsz, prsvd, valid;
- union {
- u16 ap;
- struct {
- u32 endian, elsz, mixed;
- };
- };
-};
-
-struct omap_iommu {
- const char *name;
- struct module *owner;
- struct clk *clk;
- void __iomem*regbase;
- struct device *dev;
- void*isr_priv;
- struct iommu_domain *domain;
-
- unsigned intrefcount;
- spinlock_t iommu_lock; /* global for this whole object */
-
- /*
-* We don't change iopgd for a situation like pgd for a task,
-* but share it globally for each iommu.
-*/
- u32 *iopgd;
- spinlock_t page_table_lock; /* protect iopgd */
-
- int nr_tlb_entries;
-
- struct list_headmmap;
- struct mutexmmap_lock; /* protect mmap */
-
- void *ctx; /* iommu context: registres saved area */
- u32 da_start;
- u32 da_end;
-};
-
-struct cr_regs {
- union {
- struct {
- u16 cam_l;
- u16 cam_h;
- };
- u32 cam;
- };
- union {
- struct {
- u16 ram_l;
- u16 ram_h;
- };
- u32 ram;
- };
-};
-
-struct iotlb_lock {
- short base;
- short vict;
-};
-
-/* architecture specific functions */
-struct iommu_functions {
- unsigned long version;
-
- int (*enable)(struct omap_iommu *obj);
- void (*disable)(struct omap_iommu *obj);
- void (*set_twl)(struct omap_iommu *obj, bool on);
- u32 (*fault_isr)(struct omap_iommu *obj, u32 *ra);
-
- void (*tlb_read_cr)(struct omap_iommu *obj, struct cr_regs *cr);
- void (*tlb_load_cr)(struct omap_iommu *obj, struct cr_regs *cr);
-
- struct cr_regs *(*alloc_cr)(struct omap_iommu *obj,
- struct iotlb_entry *e);
- int (*cr_valid)(struct cr_regs *cr);
- u32 (*cr_to_virt)(struct cr_regs *cr);
- void (*cr_to_e)(struct cr_regs *cr, struct iotlb_entry *e);
- ssize_t (*dump_cr)(struct omap_iommu *obj, struct cr_regs *cr,
- char *buf);
-
- u32 (*get_pte_attr)(struct iotlb_entry *e);
+#define MMU_REG_SIZE 256
- void (*save_ctx)(struct omap_iommu *obj);
- void (*restore_ctx)(struct omap_iommu *obj);
- ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
+/**
+ * struct iommu_arch_data - omap iommu private data
+ * @name: name of the iommu device
+ * @iommu_dev: handle of the iommu device
+ *
+ * This is an omap iommu private data object, which binds an iommu user
+ * to its io
Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Tony Lindgren [121030 09:31]: > > OK so are people happy with the patches in this series? > > Please everybody ack if no more comments so we can move on > towards getting CONFIG_MULTIPLATFORM to work for omaps. Looks like Joerg has a new email address, I'll send this series out one more time. Regards, Tony -- 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: Skeleton LinuxDVB framework
Thanks Mauro, for pointing out and clarifying. -- Charlie -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab Sent: Friday, November 02, 2012 5:48 AM To: Charlie X. Liu Cc: 'Richard'; linux-media@vger.kernel.org Subject: Re: Skeleton LinuxDVB framework Em Thu, 1 Nov 2012 16:15:41 -0700 "Charlie X. Liu" escreveu: > You could check or refer to the following links, for start: > > http://linuxtv.org/wiki/index.php/Main_Page > http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps Be careful with the docs below: > http://www.linuxtv.org/docs/dvbapi/dvbapi.html > http://linuxtv.org/downloads/legacy/linux-dvb-api-v4/linux-dvb-api-v4- > 0-1.pdf http://elinux.org/images/1/13/Celf_linux_dvb_v4.pdf As DVB version 3 or below is outdated, and v4 was never finished/merged. The DVBv5 (currently, on version 5.8) is the one you should use: > http://linuxtv.org/downloads/v4l-dvb-apis/dvbapi.html > -Original Message- > From: linux-media-ow...@vger.kernel.org > [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Richard > Sent: Thursday, November 01, 2012 6:35 AM > To: linux-media@vger.kernel.org > Subject: Skeleton LinuxDVB framework > > Hi all, > > As a newbie to the LinuxDVB Device drivers, I am wondering if there is > a framework template to get a quick start in to DVB device drivers. I > currently have a SOC chip and an manufacturers API that I would like > to make in to a LinuxDVB compliant device. (Tuners/Demods/CA/MPEG > output hardware > etc) It is probably easier to get one driver of each type as an example and change it to fill your needs. > > Any information is greatly appreciated. > Richard > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" > in the body of a message to majord...@vger.kernel.org More majordomo > info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" > in the body of a message to majord...@vger.kernel.org More majordomo > info at http://vger.kernel.org/majordomo-info.html Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v7 2/8] of: add helper to parse display timings
Hello Steffen,
On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
wrote:
> Signed-off-by: Steffen Trumtrar
> ---
> .../devicetree/bindings/video/display-timings.txt | 139 +++
> drivers/of/Kconfig |6 +
> drivers/of/Makefile|1 +
> drivers/of/of_display_timings.c| 185
>
> include/linux/of_display_timings.h | 20 +++
> 5 files changed, 351 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/display-timings.txt
> create mode 100644 drivers/of/of_display_timings.c
> create mode 100644 include/linux/of_display_timings.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 000..04c94a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,139 @@
> +display-timings 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.
> +
> +timings-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: displayclock 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/non-inverted/ignored
> + - interlaced (bool)
> + - doublescan (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
> +
> +struct display_timing
> +===
> +
> +
> +--+-+--+---+
> + | |↑| |
> |
> + | ||vback_porch | |
> |
> + | |↓| |
> |
> +
> +--###--+---+
> + | #↑# |
> |
> + | #|# |
> |
> + | hback #|# hfront |
> hsync |
> + | porch #| hactive # porch | len
> |
> +
> |<>#<---+--->#<>|<->|
> + | #|# |
> |
> + | #|vactive # |
> |
> + | #|# |
> |
> + | #↓# |
> |
> +
> +--###--+---+
> + | |↑| |
> |
> + | ||vfront_porch| |
> |
> + | |↓| |
> |
> +
> +--+-+--+---+
> + | |↑| |
> |
> + | ||vsync_len | |
> |
> + | |↓| |
> |
> +
> +--+-+--+---+
> +
> +
> +Example:
> +
> + display-timings {
> + native-mode = <&timing0>;
> + timing0: 1920p24 {
> + /* 1920x1080p24 */
> + clock = <5200>;
> + hactive = <1920>;
> + vactive = <1080>;
> + hfront-porch = <25>;
> + hback-porch = <25>;
> + hsync-len = <25>;
> + vback-porch = <2>;
> +
Re: [PATCH v3] [media] vivi: Teach it to tune FPS
On Fri, Nov 02, 2012 at 03:42:21PM +0100, Hans Verkuil wrote:
> Thanks for the ping, I forgot about this patch...
Thanks for the reply. Have to run now - will try to rework it in several
days.
Thanks again,
Kirill
> On Tue October 23 2012 15:35:21 Kirill Smelkov wrote:
> > On Tue, Oct 23, 2012 at 08:40:04AM +0200, Hans Verkuil wrote:
> > > On Mon October 22 2012 19:01:40 Kirill Smelkov wrote:
> > > > On Mon, Oct 22, 2012 at 04:16:14PM +0200, Hans Verkuil wrote:
> > > > > On Mon October 22 2012 15:54:44 Kirill Smelkov wrote:
> > > > > > I was testing my video-over-ethernet subsystem today, and vivi
> > > > > > seemed to
> > > > > > be perfect video source for testing when one don't have lots of
> > > > > > capture
> > > > > > boards and cameras. Only its framerate was hardcoded to NTSC's
> > > > > > 30fps,
> > > > > > while in my country we usually use PAL (25 fps). That's why the
> > > > > > patch.
> > > > > > Thanks.
> > > > >
> > > > > Rather than introducing a module option, it's much nicer if you can
> > > > > implement enum_frameintervals and g/s_parm. This can be made quite
> > > > > flexible
> > > > > allowing you to also support 50/59.94/60 fps.
> > > >
> > > > Thanks for feedback. I've reworked the patch for FPS to be set via
> > > > ->{g,s}_parm(), and yes now it is more flexble, because one can set
> > > > different FPS on different vivi devices. Only I don't know V4L2 ioctls
> > > > details well enough and various drivers do things differently. The patch
> > > > is below. Is it ok?
> > >
> > > Close, but it's not quite there.
> > >
> > > You should run the v4l2-compliance tool from the v4l-utils.git repository
> > > (take the master branch). That will report any errors in your
> > > implementation.
> > >
> > > In this case g/s_parm doesn't set readbuffers (set it to 1) and if
> > > timeperframe
> > > equals { 0, 0 }, then you should get a nominal framerate (let's stick to
> > > 29.97
> > > for that). I would set the nominal framerate whenever the denominator ==
> > > 0.
> > >
> > > For vidioc_enum_frameintervals you need to check the IN fields and fill
> > > in the
> > > stepwise struct.
> >
> > Thanks for pointers and info about v4l2-compliance handy-tool. I've
> > tried to correct all the issues you mentioned above and here is the
> > patch.
> >
> > (Only requirement to set stepwise.step to 1.0 for
> > V4L2_FRMIVAL_TYPE_CONTINUOUS seems a bit illogical to me, but anyway,
> > that's what the V4L2 spec requires...)
> >
> > Thanks,
> > Kirill
> >
> > 8<
> > From: Kirill Smelkov
> > Date: Tue, 23 Oct 2012 16:56:59 +0400
> > Subject: [PATCH v3] [media] vivi: Teach it to tune FPS
> >
> > I was testing my video-over-ethernet subsystem yesterday, and vivi
> > seemed to be perfect video source for testing when one don't have lots
> > of capture boards and cameras. Only its framerate was hardcoded to
> > NTSC's 30fps, while in my country we usually use PAL (25 fps) and I
> > needed that to precisely simulate bandwidth.
> >
> > That's why here is this patch with ->enum_frameintervals() and
> > ->{g,s}_parm() implemented as suggested by Hans Verkuil which passes
> > v4l2-compliance and manual testing through v4l2-ctl -P / -p .
> >
> > Regarding newly introduced __get_format(u32 pixelformat) I decided not
> > to convert original get_format() to operate on fourcc codes, since >= 3
> > places in driver need to deal with v4l2_format and otherwise it won't be
> > handy.
> >
> > Thanks.
> >
> > Signed-off-by: Kirill Smelkov
> > ---
> > drivers/media/platform/vivi.c | 84
> > ++-
> > 1 file changed, 75 insertions(+), 9 deletions(-)
> >
> > V3:
> > - corrected issues with V4L2 spec compliance as pointed by Hans
> > Verkuil.
> >
> > V2:
> >
> > - reworked FPS setting from module param to via ->{g,s}_parm() as
> > suggested
> > by Hans Verkuil.
> >
> >
> > diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> > index 3e6902a..3adea58 100644
> > --- a/drivers/media/platform/vivi.c
> > +++ b/drivers/media/platform/vivi.c
> > @@ -36,10 +36,6 @@
> >
> > #define VIVI_MODULE_NAME "vivi"
> >
> > -/* Wake up at about 30 fps */
> > -#define WAKE_NUMERATOR 30
> > -#define WAKE_DENOMINATOR 1001
> > -
> > #define MAX_WIDTH 1920
> > #define MAX_HEIGHT 1200
> >
> > @@ -69,6 +65,9 @@ MODULE_PARM_DESC(vid_limit, "capture memory limit in
> > megabytes");
> > /* Global font descriptor */
> > static const u8 *font8x16;
> >
> > +/* default to NTSC timeperframe */
> > +static const struct v4l2_fract TPF_DEFAULT = {.numerator = 1001,
> > .denominator = 3};
>
> Keep the name lower case: tpf_default. Upper case is for defines only.
>
> > +
> > #define dprintk(dev, level, fmt, arg...) \
> > v4l2_dbg(level, debug, &dev->v4l2_dev, fmt, ## arg)
> >
> > @@ -150,14 +149,14 @@ static struct vivi_fmt formats[] = {
> > },
> > };
> >
> > -static struct vivi_fmt *get_format(struct v
RE: [media-workshop] drivers without explicit MAINTAINERS entry - was: Re: Tentative Agenda for the November workshop
Thanks Hans and Mauro. On any of the CX drivers, if we do not have any "maintainer" or "odd fixer", you could add me to the "odd fixer" list. Rgds, Palash -Original Message- From: media-workshop-boun...@linuxtv.org [mailto:media-workshop-boun...@linuxtv.org] On Behalf Of Mauro Carvalho Chehab Sent: Friday, November 02, 2012 7:35 AM To: Hans Verkuil Cc: media-works...@linuxtv.org; linux-media Subject: Re: [media-workshop] drivers without explicit MAINTAINERS entry - was: Re: Tentative Agenda for the November workshop 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 or may > > > > > stay for a long time queued; > > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > > any maintainer[1]. > > > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. > > > > > Letting it would delay a lot the patch review process, if > > > > > applied for every patch, with unreliable and doubtful results. > > > > > I don't do it, due to the large volume of patches, and because >
Re: [PATCH v3] [media] vivi: Teach it to tune FPS
Thanks for the ping, I forgot about this patch...
On Tue October 23 2012 15:35:21 Kirill Smelkov wrote:
> On Tue, Oct 23, 2012 at 08:40:04AM +0200, Hans Verkuil wrote:
> > On Mon October 22 2012 19:01:40 Kirill Smelkov wrote:
> > > On Mon, Oct 22, 2012 at 04:16:14PM +0200, Hans Verkuil wrote:
> > > > On Mon October 22 2012 15:54:44 Kirill Smelkov wrote:
> > > > > I was testing my video-over-ethernet subsystem today, and vivi seemed
> > > > > to
> > > > > be perfect video source for testing when one don't have lots of
> > > > > capture
> > > > > boards and cameras. Only its framerate was hardcoded to NTSC's 30fps,
> > > > > while in my country we usually use PAL (25 fps). That's why the patch.
> > > > > Thanks.
> > > >
> > > > Rather than introducing a module option, it's much nicer if you can
> > > > implement enum_frameintervals and g/s_parm. This can be made quite
> > > > flexible
> > > > allowing you to also support 50/59.94/60 fps.
> > >
> > > Thanks for feedback. I've reworked the patch for FPS to be set via
> > > ->{g,s}_parm(), and yes now it is more flexble, because one can set
> > > different FPS on different vivi devices. Only I don't know V4L2 ioctls
> > > details well enough and various drivers do things differently. The patch
> > > is below. Is it ok?
> >
> > Close, but it's not quite there.
> >
> > You should run the v4l2-compliance tool from the v4l-utils.git repository
> > (take the master branch). That will report any errors in your
> > implementation.
> >
> > In this case g/s_parm doesn't set readbuffers (set it to 1) and if
> > timeperframe
> > equals { 0, 0 }, then you should get a nominal framerate (let's stick to
> > 29.97
> > for that). I would set the nominal framerate whenever the denominator == 0.
> >
> > For vidioc_enum_frameintervals you need to check the IN fields and fill in
> > the
> > stepwise struct.
>
> Thanks for pointers and info about v4l2-compliance handy-tool. I've
> tried to correct all the issues you mentioned above and here is the
> patch.
>
> (Only requirement to set stepwise.step to 1.0 for
> V4L2_FRMIVAL_TYPE_CONTINUOUS seems a bit illogical to me, but anyway,
> that's what the V4L2 spec requires...)
>
> Thanks,
> Kirill
>
> 8<
> From: Kirill Smelkov
> Date: Tue, 23 Oct 2012 16:56:59 +0400
> Subject: [PATCH v3] [media] vivi: Teach it to tune FPS
>
> I was testing my video-over-ethernet subsystem yesterday, and vivi
> seemed to be perfect video source for testing when one don't have lots
> of capture boards and cameras. Only its framerate was hardcoded to
> NTSC's 30fps, while in my country we usually use PAL (25 fps) and I
> needed that to precisely simulate bandwidth.
>
> That's why here is this patch with ->enum_frameintervals() and
> ->{g,s}_parm() implemented as suggested by Hans Verkuil which passes
> v4l2-compliance and manual testing through v4l2-ctl -P / -p .
>
> Regarding newly introduced __get_format(u32 pixelformat) I decided not
> to convert original get_format() to operate on fourcc codes, since >= 3
> places in driver need to deal with v4l2_format and otherwise it won't be
> handy.
>
> Thanks.
>
> Signed-off-by: Kirill Smelkov
> ---
> drivers/media/platform/vivi.c | 84
> ++-
> 1 file changed, 75 insertions(+), 9 deletions(-)
>
> V3:
> - corrected issues with V4L2 spec compliance as pointed by Hans
> Verkuil.
>
> V2:
>
> - reworked FPS setting from module param to via ->{g,s}_parm() as
> suggested
> by Hans Verkuil.
>
>
> diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> index 3e6902a..3adea58 100644
> --- a/drivers/media/platform/vivi.c
> +++ b/drivers/media/platform/vivi.c
> @@ -36,10 +36,6 @@
>
> #define VIVI_MODULE_NAME "vivi"
>
> -/* Wake up at about 30 fps */
> -#define WAKE_NUMERATOR 30
> -#define WAKE_DENOMINATOR 1001
> -
> #define MAX_WIDTH 1920
> #define MAX_HEIGHT 1200
>
> @@ -69,6 +65,9 @@ MODULE_PARM_DESC(vid_limit, "capture memory limit in
> megabytes");
> /* Global font descriptor */
> static const u8 *font8x16;
>
> +/* default to NTSC timeperframe */
> +static const struct v4l2_fract TPF_DEFAULT = {.numerator = 1001,
> .denominator = 3};
Keep the name lower case: tpf_default. Upper case is for defines only.
> +
> #define dprintk(dev, level, fmt, arg...) \
> v4l2_dbg(level, debug, &dev->v4l2_dev, fmt, ## arg)
>
> @@ -150,14 +149,14 @@ static struct vivi_fmt formats[] = {
> },
> };
>
> -static struct vivi_fmt *get_format(struct v4l2_format *f)
> +static struct vivi_fmt *__get_format(u32 pixelformat)
> {
> struct vivi_fmt *fmt;
> unsigned int k;
>
> for (k = 0; k < ARRAY_SIZE(formats); k++) {
> fmt = &formats[k];
> - if (fmt->fourcc == f->fmt.pix.pixelformat)
> + if (fmt->fourcc == pixelformat)
> break;
> }
>
> @@ -167,6 +166,11 @@ static struct vivi_fmt *get_format(struct v4l2_fo
Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop
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 or may > > > > > stay for a long time queued; > > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > > any maintainer[1]. > > > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it > > > > > would > > > > > delay a lot the patch review process, if applied for every patch, with > > > > > unreliable and doubtful results. I don't do it, due to the large > > > > > volume > > > > > of patches, and because the 'other' results aren't typically the > > > > > driver > > > > > maintainer. > > > > > > > > > > An example of this is the results for a patch I just applied > > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > > > Mauro Carvalho Chehab (maintainer:MEDIA > > > > > INPUT INFRA...,commit_signer:7/7=100%) > > > > > Hans Verkuil (co
Re: [PATCH 0/4] Speedup vivi
On Fri, Nov 02, 2012 at 02:48:43PM +0100, Hans Verkuil wrote: > On Fri November 2 2012 14:10:29 Kirill Smelkov wrote: > > Hello up there. I was trying to use vivi to generate multiple video streams > > for > > my test-lab environment on atom system and noticed it wastes a lot of cpu. > > > > Please apply some optimization patches. > > Looks good! > > For the whole series: > > Acked-by: Hans Verkuil Thanks a lot! -- 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 v3] [media] vivi: Teach it to tune FPS
On Tue, Oct 23, 2012 at 05:35:21PM +0400, Kirill Smelkov wrote:
> On Tue, Oct 23, 2012 at 08:40:04AM +0200, Hans Verkuil wrote:
> > On Mon October 22 2012 19:01:40 Kirill Smelkov wrote:
> > > On Mon, Oct 22, 2012 at 04:16:14PM +0200, Hans Verkuil wrote:
> > > > On Mon October 22 2012 15:54:44 Kirill Smelkov wrote:
> > > > > I was testing my video-over-ethernet subsystem today, and vivi seemed
> > > > > to
> > > > > be perfect video source for testing when one don't have lots of
> > > > > capture
> > > > > boards and cameras. Only its framerate was hardcoded to NTSC's 30fps,
> > > > > while in my country we usually use PAL (25 fps). That's why the patch.
> > > > > Thanks.
> > > >
> > > > Rather than introducing a module option, it's much nicer if you can
> > > > implement enum_frameintervals and g/s_parm. This can be made quite
> > > > flexible
> > > > allowing you to also support 50/59.94/60 fps.
> > >
> > > Thanks for feedback. I've reworked the patch for FPS to be set via
> > > ->{g,s}_parm(), and yes now it is more flexble, because one can set
> > > different FPS on different vivi devices. Only I don't know V4L2 ioctls
> > > details well enough and various drivers do things differently. The patch
> > > is below. Is it ok?
> >
> > Close, but it's not quite there.
> >
> > You should run the v4l2-compliance tool from the v4l-utils.git repository
> > (take the master branch). That will report any errors in your
> > implementation.
> >
> > In this case g/s_parm doesn't set readbuffers (set it to 1) and if
> > timeperframe
> > equals { 0, 0 }, then you should get a nominal framerate (let's stick to
> > 29.97
> > for that). I would set the nominal framerate whenever the denominator == 0.
> >
> > For vidioc_enum_frameintervals you need to check the IN fields and fill in
> > the
> > stepwise struct.
>
> Thanks for pointers and info about v4l2-compliance handy-tool. I've
> tried to correct all the issues you mentioned above and here is the
> patch.
>
> (Only requirement to set stepwise.step to 1.0 for
> V4L2_FRMIVAL_TYPE_CONTINUOUS seems a bit illogical to me, but anyway,
> that's what the V4L2 spec requires...)
>
> Thanks,
> Kirill
>
> 8<
> From: Kirill Smelkov
> Date: Tue, 23 Oct 2012 16:56:59 +0400
> Subject: [PATCH v3] [media] vivi: Teach it to tune FPS
>
> I was testing my video-over-ethernet subsystem yesterday, and vivi
> seemed to be perfect video source for testing when one don't have lots
> of capture boards and cameras. Only its framerate was hardcoded to
> NTSC's 30fps, while in my country we usually use PAL (25 fps) and I
> needed that to precisely simulate bandwidth.
>
> That's why here is this patch with ->enum_frameintervals() and
> ->{g,s}_parm() implemented as suggested by Hans Verkuil which passes
> v4l2-compliance and manual testing through v4l2-ctl -P / -p .
>
> Regarding newly introduced __get_format(u32 pixelformat) I decided not
> to convert original get_format() to operate on fourcc codes, since >= 3
> places in driver need to deal with v4l2_format and otherwise it won't be
> handy.
>
> Thanks.
>
> Signed-off-by: Kirill Smelkov
> ---
> drivers/media/platform/vivi.c | 84
> ++-
> 1 file changed, 75 insertions(+), 9 deletions(-)
>
> V3:
> - corrected issues with V4L2 spec compliance as pointed by Hans
> Verkuil.
>
> V2:
>
> - reworked FPS setting from module param to via ->{g,s}_parm() as
> suggested
> by Hans Verkuil.
>
>
> diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> index 3e6902a..3adea58 100644
> --- a/drivers/media/platform/vivi.c
> +++ b/drivers/media/platform/vivi.c
> @@ -36,10 +36,6 @@
>
> #define VIVI_MODULE_NAME "vivi"
>
> -/* Wake up at about 30 fps */
> -#define WAKE_NUMERATOR 30
> -#define WAKE_DENOMINATOR 1001
> -
> #define MAX_WIDTH 1920
> #define MAX_HEIGHT 1200
>
> @@ -69,6 +65,9 @@ MODULE_PARM_DESC(vid_limit, "capture memory limit in
> megabytes");
> /* Global font descriptor */
> static const u8 *font8x16;
>
> +/* default to NTSC timeperframe */
> +static const struct v4l2_fract TPF_DEFAULT = {.numerator = 1001,
> .denominator = 3};
> +
> #define dprintk(dev, level, fmt, arg...) \
> v4l2_dbg(level, debug, &dev->v4l2_dev, fmt, ## arg)
>
> @@ -150,14 +149,14 @@ static struct vivi_fmt formats[] = {
> },
> };
>
> -static struct vivi_fmt *get_format(struct v4l2_format *f)
> +static struct vivi_fmt *__get_format(u32 pixelformat)
> {
> struct vivi_fmt *fmt;
> unsigned int k;
>
> for (k = 0; k < ARRAY_SIZE(formats); k++) {
> fmt = &formats[k];
> - if (fmt->fourcc == f->fmt.pix.pixelformat)
> + if (fmt->fourcc == pixelformat)
> break;
> }
>
> @@ -167,6 +166,11 @@ static struct vivi_fmt *get_format(struct v4l2_format *f)
> return &formats[k];
> }
>
> +static struct vivi_fmt *get_format(struct v4l2_format *f)
> +{
>
Re: [PATCH 0/4] Speedup vivi
On Fri November 2 2012 14:10:29 Kirill Smelkov wrote: > Hello up there. I was trying to use vivi to generate multiple video streams > for > my test-lab environment on atom system and noticed it wastes a lot of cpu. > > Please apply some optimization patches. Looks good! For the whole series: Acked-by: Hans Verkuil Regards, Hans > > Thanks, > Kirill > > Kirill Smelkov (4): > [media] vivi: Optimize gen_text() > [media] vivi: vivi_dev->line[] was not aligned > [media] vivi: Move computations out of vivi_fillbuf linecopy loop > [media] vivi: Optimize precalculate_line() > > drivers/media/platform/vivi.c | 94 > ++- > 1 file changed, 65 insertions(+), 29 deletions(-) > > -- 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
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 or may > > > > stay for a long time queued; > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > any maintainer[1]. > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it > > > > would > > > > delay a lot the patch review process, if applied for every patch, with > > > > unreliable and doubtful results. I don't do it, due to the large volume > > > > of patches, and because the 'other' results aren't typically the driver > > > > maintainer. > > > > > > > > An example of this is the results for a patch I just applied > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > > Mauro Carvalho Chehab (maintainer:MEDIA > > > > INPUT INFRA...,commit_signer:7/7=100%) > > > > Hans Verkuil (commit_signer:4/7=57%) > > > > Anatolij Gustschin (commit_signer:1/7=14%) > > > > Wei Yongjun > > > > (commit_signer:1/7=14%) > > > > Hans de Goede (commit_signer:1/7=14%) > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > > >
Re: [PATCH] stkwebcam: Fix sparse warning on undeclared symbol
Hi Arvydas, On Fri, Nov 2, 2012 at 4:35 AM, Arvydas Sidorenko wrote: >> why the heck do we need this first_init? > > first_init was introduced in 7b1c8f58fcdbed75 for turning off LED when > the cam finishes > the capture. > Andrea Anacleto claimed that the change > broke his webcam > on the same laptop, so he introduced that variable to fix the issue. > It didn't have any > impact to my cam so I merged it's patch and resent my fix to the maintainer. I understand. It sounds a bit weird to me. However, I can't argue since I don't have a device to test. This patch doesn't change the functionality in any way. If you have the time to test it and stamp a "Tested-by" on it, I would appreciate it. Thanks, Ezequiel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] rc: Call rc_register_device before irq setup
This should fix a potential race condition, when the irq handler
triggers while rc_register_device is still setting up the rdev->raw
device.
This crash has not been observed in practice, but there should be a very
small window where it could occur. Since ir_raw_event_store_with_filter
checks if rdev->raw is not NULL before using it, this bug is not
triggered if the request_irq triggers a pending irq directly (since
rdev->raw will still be NULL then).
This commit was tested on nuvoton-cir only.
Signed-off-by: Matthijs Kooijman
Cc: Jarod Wilson
Cc: Maxim Levitsky
Cc: David Härdeman
---
drivers/media/rc/ene_ir.c | 14 +++---
drivers/media/rc/ite-cir.c | 14 +++---
drivers/media/rc/nuvoton-cir.c | 14 +++---
drivers/media/rc/winbond-cir.c | 14 +++---
4 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index f7fdfea..e601166 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1075,10 +1075,14 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
device_set_wakeup_capable(&pnp_dev->dev, true);
device_set_wakeup_enable(&pnp_dev->dev, true);
+ error = rc_register_device(rdev);
+ if (error < 0)
+ goto exit_free_dev_rdev;
+
/* claim the resources */
error = -EBUSY;
if (!request_region(dev->hw_io, ENE_IO_SIZE, ENE_DRIVER_NAME)) {
- goto exit_free_dev_rdev;
+ goto exit_unregister_device;
}
dev->irq = pnp_irq(pnp_dev, 0);
@@ -1087,17 +1091,13 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
goto exit_release_hw_io;
}
- error = rc_register_device(rdev);
- if (error < 0)
- goto exit_free_irq;
-
pr_notice("driver has been successfully loaded\n");
return 0;
-exit_free_irq:
- free_irq(dev->irq, dev);
exit_release_hw_io:
release_region(dev->hw_io, ENE_IO_SIZE);
+exit_unregister_device:
+ rc_unregister_device(rdev);
exit_free_dev_rdev:
rc_free_device(rdev);
kfree(dev);
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index 8e0e661..e810846 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1591,28 +1591,28 @@ static int ite_probe(struct pnp_dev *pdev, const struct
pnp_device_id
rdev->driver_name = ITE_DRIVER_NAME;
rdev->map_name = RC_MAP_RC6_MCE;
+ ret = rc_register_device(rdev);
+ if (ret)
+ goto exit_free_dev_rdev;
+
ret = -EBUSY;
/* now claim resources */
if (!request_region(itdev->cir_addr,
dev_desc->io_region_size, ITE_DRIVER_NAME))
- goto exit_free_dev_rdev;
+ goto exit_unregister_device;
if (request_irq(itdev->cir_irq, ite_cir_isr, IRQF_SHARED,
ITE_DRIVER_NAME, (void *)itdev))
goto exit_release_cir_addr;
- ret = rc_register_device(rdev);
- if (ret)
- goto exit_free_irq;
-
ite_pr(KERN_NOTICE, "driver has been successfully loaded\n");
return 0;
-exit_free_irq:
- free_irq(itdev->cir_irq, itdev);
exit_release_cir_addr:
release_region(itdev->cir_addr, itdev->params.io_region_size);
+exit_unregister_device:
+ rc_unregister_device(rdev);
exit_free_dev_rdev:
rc_free_device(rdev);
kfree(itdev);
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index c6441e6..6cf43cc 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -1067,11 +1067,15 @@ static int nvt_probe(struct pnp_dev *pdev, const struct
pnp_device_id *dev_id)
#endif
nvt->rdev = rdev;
+ ret = rc_register_device(rdev);
+ if (ret)
+ goto exit_free_dev_rdev;
+
ret = -EBUSY;
/* now claim resources */
if (!request_region(nvt->cir_addr,
CIR_IOREG_LENGTH, NVT_DRIVER_NAME))
- goto exit_free_dev_rdev;
+ goto exit_unregister_device;
if (request_irq(nvt->cir_irq, nvt_cir_isr, IRQF_SHARED,
NVT_DRIVER_NAME, (void *)nvt))
@@ -1085,10 +1089,6 @@ static int nvt_probe(struct pnp_dev *pdev, const struct
pnp_device_id *dev_id)
NVT_DRIVER_NAME, (void *)nvt))
goto exit_release_cir_wake_addr;
- ret = rc_register_device(rdev);
- if (ret)
- goto exit_free_wake_irq;
-
device_init_wakeup(&pdev->dev, true);
nvt_pr(KERN_NOTICE, "driver has been successfully loaded\n");
@@ -1099,14 +1099,14 @@ static int nvt_probe(struct pnp_dev *pdev, const struct
pnp_device_id *dev_id)
return 0;
-exit_free_wake_irq:
- free_irq(nvt->cir_wake_irq, nvt);
exit_release_cir_wake_add
[PATCH 2/3] [media] rc: Set rdev before irq setup
This fixes a problem in fintek-cir and nuvoton-cir where the
irq handler would trigger during module load before the rdev member was
set, causing a NULL pointer crash.
It seems this crash is very reproducible (just bombard the receiver with
IR signals during module load), probably because when request_irq is
called, any pending intterupt is handled immediately, before
request_irq returns and rdev can be set.
This same crash was supposed to be fixed by commit
9ef449c6b31bb6a8e6dedc24de475a3b8c79be20 ("[media] rc: Postpone ISR
registration"), but the crash was still observed on the nuvoton-cir
driver.
This commit was tested on nuvoton-cir only.
Signed-off-by: Matthijs Kooijman
Cc: Jarod Wilson
---
drivers/media/rc/fintek-cir.c |4 +++-
drivers/media/rc/nuvoton-cir.c |3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index 3d5e57c..5eefe65 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -557,6 +557,8 @@ static int fintek_probe(struct pnp_dev *pdev, const struct
pnp_device_id *dev_id
/* rx resolution is hardwired to 50us atm, 1, 25, 100 also possible */
rdev->rx_resolution = US_TO_NS(CIR_SAMPLE_PERIOD);
+ fintek->rdev = rdev;
+
ret = -EBUSY;
/* now claim resources */
if (!request_region(fintek->cir_addr,
@@ -572,7 +574,7 @@ static int fintek_probe(struct pnp_dev *pdev, const struct
pnp_device_id *dev_id
goto exit_free_irq;
device_init_wakeup(&pdev->dev, true);
- fintek->rdev = rdev;
+
fit_pr(KERN_NOTICE, "driver has been successfully loaded\n");
if (debug)
cir_dump_regs(fintek);
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 3477e23..c6441e6 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -1065,6 +1065,7 @@ static int nvt_probe(struct pnp_dev *pdev, const struct
pnp_device_id *dev_id)
/* tx bits */
rdev->tx_resolution = XYZ;
#endif
+ nvt->rdev = rdev;
ret = -EBUSY;
/* now claim resources */
@@ -1089,7 +1090,7 @@ static int nvt_probe(struct pnp_dev *pdev, const struct
pnp_device_id *dev_id)
goto exit_free_wake_irq;
device_init_wakeup(&pdev->dev, true);
- nvt->rdev = rdev;
+
nvt_pr(KERN_NOTICE, "driver has been successfully loaded\n");
if (debug) {
cir_dump_regs(nvt);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] rc: Make probe cleanup goto labels more verbose
Before, labels were simply numbered. Now, the labels are named after the
cleanup action they'll perform (first), based on how the winbond-cir
driver does it. This makes the code a bit more clear and makes changes
in the ordering of labels easier to review.
This change is applied only to the rc drivers that do significant
cleanup in their probe functions: ati-remote, ene-ir, fintek-cir,
gpio-ir-recv, ite-cir, nuvoton-cir.
This commit should not change any code, it just renames goto labels.
Signed-off-by: Matthijs Kooijman
Cc: Maxim Levitsky
Cc: Jarod Wilson
---
drivers/media/rc/ati_remote.c | 27 ---
drivers/media/rc/ene_ir.c | 20 ++--
drivers/media/rc/fintek-cir.c | 20 ++--
drivers/media/rc/gpio-ir-recv.c | 19 +--
drivers/media/rc/ite-cir.c | 18 +-
drivers/media/rc/nuvoton-cir.c | 30 +++---
6 files changed, 69 insertions(+), 65 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 2d6fb26..4d6a63f 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -872,11 +872,11 @@ static int ati_remote_probe(struct usb_interface
*interface,
ati_remote = kzalloc(sizeof (struct ati_remote), GFP_KERNEL);
rc_dev = rc_allocate_device();
if (!ati_remote || !rc_dev)
- goto fail1;
+ goto exit_free_dev_rdev;
/* Allocate URB buffers, URBs */
if (ati_remote_alloc_buffers(udev, ati_remote))
- goto fail2;
+ goto exit_free_buffers;
ati_remote->endpoint_in = endpoint_in;
ati_remote->endpoint_out = endpoint_out;
@@ -924,12 +924,12 @@ static int ati_remote_probe(struct usb_interface
*interface,
/* Device Hardware Initialization - fills in ati_remote->idev from
udev. */
err = ati_remote_initialize(ati_remote);
if (err)
- goto fail3;
+ goto exit_kill_urbs;
/* Set up and register rc device */
err = rc_register_device(ati_remote->rdev);
if (err)
- goto fail3;
+ goto exit_kill_urbs;
/* use our delay for rc_dev */
ati_remote->rdev->input_dev->rep[REP_DELAY] = repeat_delay;
@@ -939,7 +939,7 @@ static int ati_remote_probe(struct usb_interface *interface,
input_dev = input_allocate_device();
if (!input_dev) {
err = -ENOMEM;
- goto fail4;
+ goto exit_unregister_device;
}
ati_remote->idev = input_dev;
@@ -947,19 +947,24 @@ static int ati_remote_probe(struct usb_interface
*interface,
err = input_register_device(input_dev);
if (err)
- goto fail5;
+ goto exit_free_input_device;
}
usb_set_intfdata(interface, ati_remote);
return 0;
- fail5:input_free_device(input_dev);
- fail4:rc_unregister_device(rc_dev);
+ exit_free_input_device:
+ input_free_device(input_dev);
+ exit_unregister_device:
+ rc_unregister_device(rc_dev);
rc_dev = NULL;
- fail3:usb_kill_urb(ati_remote->irq_urb);
+ exit_kill_urbs:
+ usb_kill_urb(ati_remote->irq_urb);
usb_kill_urb(ati_remote->out_urb);
- fail2:ati_remote_free_buffers(ati_remote);
- fail1:rc_free_device(rc_dev);
+ exit_free_buffers:
+ ati_remote_free_buffers(ati_remote);
+ exit_free_dev_rdev:
+rc_free_device(rc_dev);
kfree(ati_remote);
return err;
}
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index 22231dd..f7fdfea 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1003,7 +1003,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL);
rdev = rc_allocate_device();
if (!dev || !rdev)
- goto failure;
+ goto exit_free_dev_rdev;
/* validate resources */
error = -ENODEV;
@@ -1014,10 +1014,10 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
if (!pnp_port_valid(pnp_dev, 0) ||
pnp_port_len(pnp_dev, 0) < ENE_IO_SIZE)
- goto failure;
+ goto exit_free_dev_rdev;
if (!pnp_irq_valid(pnp_dev, 0))
- goto failure;
+ goto exit_free_dev_rdev;
spin_lock_init(&dev->hw_lock);
@@ -1033,7 +1033,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
/* detect hardware version and features */
error = ene_hw_detect(dev);
if (error)
- goto failure;
+ goto exit_free_dev_rdev;
if (!dev->hw_learning_and_tx_capable && txsim) {
dev-
Updated patches for (potential) NULL pointer crashes in cir drivers
(Please keep me CC'd, I'm not subscribed to the list) Hi folks, I've updated my patches to apply against Mauro's staging/for_v3.8 branch. The patches have only been modified to apply against recent changes in some of the drivers. Like before, these patches have been really tested only on nuvoton_cir, the others received compile-testing only. Gr. Matthijs -- 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
drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop
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 or may > > > stay for a long time queued; > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > any maintainer[1]. > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it > > > would > > > delay a lot the patch review process, if applied for every patch, with > > > unreliable and doubtful results. I don't do it, due to the large volume > > > of patches, and because the 'other' results aren't typically the driver > > > maintainer. > > > > > > An example of this is the results for a patch I just applied > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > Mauro Carvalho Chehab (maintainer:MEDIA INPUT > > > INFRA...,commit_signer:7/7=100%) > > > Hans Verkuil (commit_signer:4/7=57%) > > > Anatolij Gustschin (commit_signer:1/7=14%) > > > Wei Yongjun (commit_signer:1/7=14%) > > > Hans de Goede (commit_signer:1/7=14%) > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > > linux-ker...@vger.kernel.org (open list) > > > > > > According with this driver's copyrights: > > > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > > > * > > > * Freescale VIU video driver > > > * > > > * Authors: Hongjun Chen > > > * Porting to 2.6.35 by DENX Software Engineering, > > > * Anatolij Gustschin > > > > > > T
[PATCH 4/4] [media] vivi: Optimize precalculate_line()
precalculate_line() is not very high on profile, but it calls expensive
gen_twopix(), so let's polish it too:
call gen_twopix() only once for every color bar and then distribute
the result.
before:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
#
# Samples: 46K of event 'cycles'
# Event count (approx.): 15574200568
#
# Overhead Command Shared Object
# ...
#
27.99% rawv libc-2.13.so [.] __memcpy_ssse3
23.29% vivi-* [kernel.kallsyms] [k] memcpy
10.30% Xorg [unknown] [.] 0xa75c98f8
5.34% vivi-* [vivi][k] gen_text.constprop.6
4.61% rawv [vivi][k] gen_twopix
2.64% rawv [vivi][k] precalculate_line
1.37% swapper [kernel.kallsyms] [k] read_hpet
after:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
#
# Samples: 45K of event 'cycles'
# Event count (approx.): 15561769214
#
# Overhead Command Shared Object
# ...
#
30.73% rawv libc-2.13.so [.] __memcpy_ssse3
26.78% vivi-* [kernel.kallsyms] [k] memcpy
10.68% Xorg [unknown] [.] 0xa73015e9
5.55% vivi-* [vivi][k] gen_text.constprop.6
1.36% swapper [kernel.kallsyms] [k] read_hpet
0.96% Xorg [kernel.kallsyms] [k] read_hpet
...
0.16% rawv [vivi][k] precalculate_line
...
0.14% rawv [vivi][k] gen_twopix
(i.e. gen_twopix and precalculate_line overheads are almost gone)
Signed-off-by: Kirill Smelkov
---
drivers/media/platform/vivi.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 0272d07..37d0af8 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -517,12 +517,22 @@ static void gen_twopix(struct vivi_dev *dev, u8 *buf, int
colorpos, bool odd)
static void precalculate_line(struct vivi_dev *dev)
{
- int w;
-
- for (w = 0; w < dev->width * 2; w++) {
- int colorpos = w / (dev->width / 8) % 8;
-
- gen_twopix(dev, dev->line + w * dev->pixelsize, colorpos, w &
1);
+ unsigned pixsize = dev->pixelsize;
+ unsigned pixsize2 = 2*pixsize;
+ int colorpos;
+ u8 *pos;
+
+ for (colorpos = 0; colorpos < 16; ++colorpos) {
+ u8 pix[8];
+ int wstart = colorpos* dev->width / 8;
+ int wend = (colorpos+1) * dev->width / 8;
+ int w;
+
+ gen_twopix(dev, &pix[0],colorpos % 8, 0);
+ gen_twopix(dev, &pix[pixsize], colorpos % 8, 1);
+
+ for (w = wstart/2*2, pos = dev->line + w*pixsize; w < wend; w
+= 2, pos += pixsize2)
+ memcpy(pos, pix, pixsize2);
}
}
--
1.8.0.316.g291341c
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] [media] vivi: Move computations out of vivi_fillbuf linecopy loop
The "dev->mvcount % wmax" thing was showing high in profiles (we do it
for each line which ~ 500 per frame)
│ 10c0 :
...
0,39 │ 70:┌─→mov0x3ff4(%edi),%esi
0,22 │ 76:│ mov0x2a0(%edi),%eax
0,30 ││ mov-0x84(%ebp),%ebx
0,35 ││ mov%eax,%edx
0,04 ││ mov-0x7c(%ebp),%ecx
0,35 ││ sar$0x1f,%edx
0,44 ││ idivl -0x7c(%ebp)
21,68 ││ imul %esi,%ecx
0,70 ││ imul %esi,%ebx
0,52 ││ add-0x88(%ebp),%ebx
1,65 ││ mov%ebx,%eax
0,22 ││ imul %edx,%esi
0,04 ││ lea0x3f4(%edi,%esi,1),%edx
2,18 ││→ call vivi_fillbuff+0xa6
0,74 ││ addl $0x1,-0x80(%ebp)
62,69 ││ mov-0x7c(%ebp),%edx
1,18 ││ mov-0x80(%ebp),%ecx
0,35 ││ add%edx,-0x84(%ebp)
0,61 ││ cmp%ecx,-0x8c(%ebp)
0,22 │└──jne70
so since all variables stay the same for all iterations let's move
computations out of the loop: the abovementioned division and
"width*pixelsize" too
before:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
#
# Samples: 49K of event 'cycles'
# Event count (approx.): 16475832370
#
# Overhead Command Shared Object
# ... ..
#
29.07% rawv libc-2.13.so[.] __memcpy_ssse3
20.57% vivi-* [kernel.kallsyms] [k] memcpy
10.20% Xorg [unknown] [.] 0xa7301494
5.16% vivi-* [vivi] [k]
gen_text.constprop.6
4.43% rawv [vivi] [k] gen_twopix
4.36% vivi-* [vivi] [k] vivi_fillbuff
2.42% rawv [vivi] [k] precalculate_line
1.33% swapper [kernel.kallsyms] [k] read_hpet
after:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
#
# Samples: 46K of event 'cycles'
# Event count (approx.): 15574200568
#
# Overhead Command Shared Object
# ...
#
27.99% rawv libc-2.13.so [.] __memcpy_ssse3
23.29% vivi-* [kernel.kallsyms] [k] memcpy
10.30% Xorg [unknown] [.] 0xa75c98f8
5.34% vivi-* [vivi][k] gen_text.constprop.6
4.61% rawv [vivi][k] gen_twopix
2.64% rawv [vivi][k] precalculate_line
1.37% swapper [kernel.kallsyms] [k] read_hpet
0.79% Xorg [kernel.kallsyms] [k] read_hpet
0.64% Xorg [kernel.kallsyms] [k] unix_poll
0.45% Xorg [kernel.kallsyms] [k] fget_light
0.43% rawv libxcb.so.1.1.0 [.] 0xaae9
0.40%runsv [kernel.kallsyms] [k] ext2_try_to_allocate
0.36% Xorg [kernel.kallsyms] [k]
_raw_spin_lock_irqsave
0.31% vivi-* [vivi][k] vivi_fillbuff
(i.e. vivi_fillbuff own overhead is almost gone)
Signed-off-by: Kirill Smelkov
---
drivers/media/platform/vivi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index ddcc712..0272d07 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -579,22 +579,23 @@ static void gen_text(struct vivi_dev *dev, char *basep,
static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
{
- int wmax = dev->width;
+ int stride = dev->width * dev->pixelsize;
int hmax = dev->height;
struct timeval ts;
void *vbuf = vb2_plane_vaddr(&buf->vb, 0);
unsigned ms;
char str[100];
int h, line = 1;
+ u8 *linestart;
s32 gain;
if (!vbuf)
return;
+ linestart = dev->line + (dev->mv_count % dev->width) * dev->pixelsize;
+
for (h = 0; h < hmax; h++)
- memcpy(vbuf + h * wmax * dev->pixelsize,
- dev->line + (dev->mv_count % wmax) * dev->pixelsize,
- wmax * dev->pixelsize);
+ memcpy(vbuf + h * stride, linestart, stride);
/* Updates stream time */
--
1.8.0.316.g291341c
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] [media] vivi: vivi_dev->line[] was not aligned
Though dev->line[] is u8 array we work with it as with u16, u24 or u32
pixels, and also pass it to memcpy() and it's better to align it to at
least 4.
Before the patch, on x86 offsetof(vivi_dev, line) was 1003 and after
patch it is 1004.
There is slight performance increase, but I think is is slight, only
because we start copying not from line[0]:
8< drivers/media/platform/vivi.c
static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
{
...
for (h = 0; h < hmax; h++)
memcpy(vbuf + h * wmax * dev->pixelsize,
dev->line + (dev->mv_count % wmax) * dev->pixelsize,
wmax * dev->pixelsize);
before:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
#
# Samples: 49K of event 'cycles'
# Event count (approx.): 16799780016
#
# Overhead Command Shared Object
# ...
#
27.51% rawv libc-2.13.so [.] __memcpy_ssse3
23.77% vivi-* [kernel.kallsyms] [k] memcpy
9.96% Xorg [unknown] [.] 0xa76f5e12
4.94% vivi-* [vivi][k] gen_text.constprop.6
4.44% rawv [vivi][k] gen_twopix
3.17% vivi-* [vivi][k] vivi_fillbuff
2.45% rawv [vivi][k] precalculate_line
1.20% swapper [kernel.kallsyms] [k] read_hpet
23.77% vivi-* [kernel.kallsyms] [k] memcpy
|
--- memcpy
|
|--99.28%-- vivi_fillbuff
| vivi_thread
| kthread
| ret_from_kernel_thread
--0.72%-- [...]
after:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
#
# Samples: 49K of event 'cycles'
# Event count (approx.): 16475832370
#
# Overhead Command Shared Object
# ... ..
#
29.07% rawv libc-2.13.so[.] __memcpy_ssse3
20.57% vivi-* [kernel.kallsyms] [k] memcpy
10.20% Xorg [unknown] [.] 0xa7301494
5.16% vivi-* [vivi] [k]
gen_text.constprop.6
4.43% rawv [vivi] [k] gen_twopix
4.36% vivi-* [vivi] [k] vivi_fillbuff
2.42% rawv [vivi] [k] precalculate_line
1.33% swapper [kernel.kallsyms] [k] read_hpet
Signed-off-by: Kirill Smelkov
---
drivers/media/platform/vivi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index cb2337e..ddcc712 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -242,7 +242,7 @@ struct vivi_dev {
unsigned int field_count;
u8 bars[9][3];
- u8 line[MAX_WIDTH * 8];
+ u8 line[MAX_WIDTH * 8]
__attribute__((__aligned__(4)));
unsigned int pixelsize;
u8 alpha_component;
u32textfg, textbg;
--
1.8.0.316.g291341c
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] [media] vivi: Optimize gen_text()
I've noticed that vivi takes a lot of CPU to produce its frames. For example for 8 devices and 8 simple programs running, where each captures YUY2 640x480 and displays it to X via SDL, profile timing is as follows: # cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20 # Samples: 82K of event 'cycles' # Event count (approx.): 31551930117 # # Overhead Command Shared Object Symbol # ... # 49.48% vivi-* [vivi][k] gen_twopix 10.79% vivi-* [kernel.kallsyms] [k] memcpy 10.02% rawv libc-2.13.so [.] __memcpy_ssse3 8.35% vivi-* [vivi][k] gen_text.constprop.6 5.06% Xorg [unknown] [.] 0xa73015f8 2.32% rawv [vivi][k] gen_twopix 1.22% rawv [vivi][k] precalculate_line 1.20% vivi-* [vivi][k] vivi_fillbuff (rawv is display program, vivi-* is a combination of vivi-000 through vivi-007) so a lot of time is spent in gen_twopix() which as the follwing call-graph profile shows ... 49.48% vivi-* [vivi][k] gen_twopix | --- gen_twopix | |--96.30%-- gen_text.constprop.6 | vivi_fillbuff | vivi_thread | kthread | ret_from_kernel_thread | --3.70%-- vivi_fillbuff vivi_thread kthread ret_from_kernel_thread ... is called mostly from gen_text(). If we'll look at gen_text(), in the inner loop, we'll see if (chr & (1 << (7 - i))) gen_twopix(dev, pos + j * dev->pixelsize, WHITE, (x+y) & 1); else gen_twopix(dev, pos + j * dev->pixelsize, TEXT_BLACK, (x+y) & 1); which calls gen_twopix() for every character pixel, and that is very expensive, because gen_twopix() branches several times. Now, let's note, that we operate on only two colors - WHITE and TEXT_BLACK, and that pixel for that colors could be precomputed and gen_twopix() moved out of the inner loop. Also note, that for black and white colors even/odd does not make a difference for all supported pixel formats, so we could stop doing that `odd` gen_twopix() parameter game. So the first thing we are doing here is 1) moving gen_twopix() calls out of gen_text() into vivi_fillbuff(), to pregenerate black and white colors, just before printing starts. what we have next is that gen_text's font rendering loop, even with gen_twopix() calls moved out, was inefficient and branchy, so let's 2) rewrite gen_text() loop so it uses less variables + unroll char horizontal-rendering loop + instantiate 3 code paths for pixelsizes 2,3 and 4 so that in all inner loops we don't have to branch or make indirections (*). Done all above reworks, for gen_text() we get nice, non-branchy streamlined code (showing loop for pixelsize=2): │ cmp$0x2,%eax │ ↑ jne26 │ mov-0x18(%ebp),%eax │ mov-0x20(%ebp),%edi │ imul -0x20(%ebp),%eax │ movzwl 0x3ffc(%ebx),%esi 0,08 │ movzwl 0x4000(%ebx),%ecx 0,04 │ add%edi,%edi │ mov0x0,%ebx 0,51 │ mov%edi,-0x1c(%ebp) │ mov%ebx,-0x14(%ebp) │ movl $0x0,-0x10(%ebp) │ lea0x20(%edx,%eax,2),%eax │ mov%eax,-0x18(%ebp) │ xchg %ax,%ax 0,04 │ a0: mov0x8(%ebp),%ebx │ mov-0x18(%ebp),%eax 0,04 │ movzbl (%ebx),%edx 0,16 │ test %dl,%dl 0,04 │ ↓ je 128 0,08 │ lea0x0(%esi),%esi 1,61 │ b0:┌─→shl$0x4,%edx 1,02 ││ mov-0x14(%ebp),%edi 2,04 ││ add-0x10(%ebp),%edx 2,24 ││ lea0x1(%ebx),%ebx 0,27 ││ movzbl (%edi,%edx,1),%edx 9,92 ││ mov%esi,%edi 0,39 ││ test %dl,%dl 2,04 ││ cmovns %ecx,%edi 4,63 ││ test $0x40,%dl 0,55 ││ mov%di,(%eax) 3,76 ││ mov%esi,%edi 0,71 ││ cmove %ecx,%edi 3,41 ││ test $0x20,%dl 0,75 ││ mov%di,0x2(%eax) 2,43 ││ mov%esi,%edi 0,59 ││ cmove %ecx,%edi 4,59 ││ test $0x10,%dl 0,67 ││ mov%di,0x4(%eax) 2,55 ││ mov%esi,%edi 0,78 ││ cmove %ecx,%edi 4,
[PATCH 0/4] Speedup vivi
Hello up there. I was trying to use vivi to generate multiple video streams for my test-lab environment on atom system and noticed it wastes a lot of cpu. Please apply some optimization patches. Thanks, Kirill Kirill Smelkov (4): [media] vivi: Optimize gen_text() [media] vivi: vivi_dev->line[] was not aligned [media] vivi: Move computations out of vivi_fillbuf linecopy loop [media] vivi: Optimize precalculate_line() drivers/media/platform/vivi.c | 94 ++- 1 file changed, 65 insertions(+), 29 deletions(-) -- 1.8.0.316.g291341c -- 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] staging/media: Use dev_ printks in cxd2099/cxd2099.[ch]
On Fri, Nov 2, 2012 at 9:48 AM, YAMANE Toshiaki wrote:
> fixed below checkpatch warnings.
> - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then
> pr_err(... to printk(KERN_ERR ...
> - WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
> pr_info(... to printk(KERN_INFO ...
> - WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then
> pr_warn(... to printk(KERN_WARNING ...
>
> Signed-off-by: YAMANE Toshiaki
Tested-by: Peter Senna Tschudin
> ---
> drivers/staging/media/cxd2099/cxd2099.c | 29 +++--
> drivers/staging/media/cxd2099/cxd2099.h |2 +-
> 2 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/staging/media/cxd2099/cxd2099.c
> b/drivers/staging/media/cxd2099/cxd2099.c
> index 0ff1972..822c487 100644
> --- a/drivers/staging/media/cxd2099/cxd2099.c
> +++ b/drivers/staging/media/cxd2099/cxd2099.c
> @@ -66,8 +66,9 @@ static int i2c_write_reg(struct i2c_adapter *adapter, u8
> adr,
> struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, .len = 2};
>
> if (i2c_transfer(adapter, &msg, 1) != 1) {
> - printk(KERN_ERR "Failed to write to I2C register
> %02x@%02x!\n",
> - reg, adr);
> + dev_err(&adapter->dev,
> + "Failed to write to I2C register %02x@%02x!\n",
> + reg, adr);
> return -1;
> }
> return 0;
> @@ -79,7 +80,7 @@ static int i2c_write(struct i2c_adapter *adapter, u8 adr,
> struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len =
> len};
>
> if (i2c_transfer(adapter, &msg, 1) != 1) {
> - printk(KERN_ERR "Failed to write to I2C!\n");
> + dev_err(&adapter->dev, "Failed to write to I2C!\n");
> return -1;
> }
> return 0;
> @@ -94,7 +95,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
>.buf = val, .len = 1} };
>
> if (i2c_transfer(adapter, msgs, 2) != 2) {
> - printk(KERN_ERR "error in i2c_read_reg\n");
> + dev_err(&adapter->dev, "error in i2c_read_reg\n");
> return -1;
> }
> return 0;
> @@ -109,7 +110,7 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
> .buf = data, .len = n} };
>
> if (i2c_transfer(adapter, msgs, 2) != 2) {
> - printk(KERN_ERR "error in i2c_read\n");
> + dev_err(&adapter->dev, "error in i2c_read\n");
> return -1;
> }
> return 0;
> @@ -277,7 +278,7 @@ static void cam_mode(struct cxd *ci, int mode)
> #ifdef BUFFER_MODE
> if (!ci->en.read_data)
> return;
> - printk(KERN_INFO "enable cam buffer mode\n");
> + dev_info(&ci->i2c->dev, "enable cam buffer mode\n");
> /* write_reg(ci, 0x0d, 0x00); */
> /* write_reg(ci, 0x0e, 0x01); */
> write_regm(ci, 0x08, 0x40, 0x40);
> @@ -524,7 +525,7 @@ static int slot_reset(struct dvb_ca_en50221 *ca, int slot)
> msleep(10);
> #if 0
> read_reg(ci, 0x06, &val);
> - printk(KERN_INFO "%d:%02x\n", i, val);
> + dev_info(&ci->i2c->dev, "%d:%02x\n", i, val);
> if (!(val&0x10))
> break;
> #else
> @@ -542,7 +543,7 @@ static int slot_shutdown(struct dvb_ca_en50221 *ca, int
> slot)
> {
> struct cxd *ci = ca->data;
>
> - printk(KERN_INFO "slot_shutdown\n");
> + dev_info(&ci->i2c->dev, "slot_shutdown\n");
> mutex_lock(&ci->lock);
> write_regm(ci, 0x09, 0x08, 0x08);
> write_regm(ci, 0x20, 0x80, 0x80); /* Reset CAM Mode */
> @@ -578,10 +579,10 @@ static int campoll(struct cxd *ci)
>
> if (istat&0x40) {
> ci->dr = 1;
> - printk(KERN_INFO "DR\n");
> + dev_info(&ci->i2c->dev, "DR\n");
> }
> if (istat&0x20)
> - printk(KERN_INFO "WC\n");
> + dev_info(&ci->i2c->dev, "WC\n");
>
> if (istat&2) {
> u8 slotstat;
> @@ -597,7 +598,7 @@ static int campoll(struct cxd *ci)
> if (ci->slot_stat) {
> ci->slot_stat = 0;
> write_regm(ci, 0x03, 0x00, 0x08);
> - printk(KERN_INFO "NO CAM\n");
> + dev_info(&ci->i2c->dev, "NO CAM\n");
> ci->ready = 0;
> }
> }
> @@ -634,7 +635,7 @@ static int read_data(struct dvb_ca_en50221 *ca, int slot,
> u8 *ebuf, int ecount)
> campoll(ci);
> mutex_unlock(&ci->lock);
>
> - printk(KERN_INFO "read_data\n");
> + dev_info(&ci->i2c->dev, "r
Re: [PATCH 2/2] Staging/media: Use dev_ printks in go7007/wis-ov7640.c
On Fri, Nov 2, 2012 at 1:09 PM, YAMANE Toshiaki wrote:
> fixed below checkpatch warnings.
> - WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
> pr_debug(... to printk(KERN_DEBUG ...
> - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then
> pr_err(... to printk(KERN_ERR ...
>
> Signed-off-by: YAMANE Toshiaki
Tested-by: Peter Senna Tschudin
> ---
> drivers/staging/media/go7007/wis-ov7640.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/go7007/wis-ov7640.c
> b/drivers/staging/media/go7007/wis-ov7640.c
> index eb5efc9..fe46374 100644
> --- a/drivers/staging/media/go7007/wis-ov7640.c
> +++ b/drivers/staging/media/go7007/wis-ov7640.c
> @@ -59,12 +59,12 @@ static int wis_ov7640_probe(struct i2c_client *client,
>
> client->flags = I2C_CLIENT_SCCB;
>
> - printk(KERN_DEBUG
> + dev_dbg(&client->dev,
> "wis-ov7640: initializing OV7640 at address %d on %s\n",
> client->addr, adapter->name);
>
> if (write_regs(client, initial_registers) < 0) {
> - printk(KERN_ERR "wis-ov7640: error initializing OV7640\n");
> + dev_err(&client->dev, "wis-ov7640: error initializing
> OV7640\n");
> return -ENODEV;
> }
>
> --
> 1.7.9.5
>
> --
> 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
--
Peter
--
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: Skeleton LinuxDVB framework
Em Thu, 1 Nov 2012 16:15:41 -0700 "Charlie X. Liu" escreveu: > You could check or refer to the following links, for start: > > http://linuxtv.org/wiki/index.php/Main_Page > http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps Be careful with the docs below: > http://www.linuxtv.org/docs/dvbapi/dvbapi.html > http://linuxtv.org/downloads/legacy/linux-dvb-api-v4/linux-dvb-api-v4-0-1.pdf > http://elinux.org/images/1/13/Celf_linux_dvb_v4.pdf As DVB version 3 or below is outdated, and v4 was never finished/merged. The DVBv5 (currently, on version 5.8) is the one you should use: > http://linuxtv.org/downloads/v4l-dvb-apis/dvbapi.html > -Original Message- > From: linux-media-ow...@vger.kernel.org > [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Richard > Sent: Thursday, November 01, 2012 6:35 AM > To: linux-media@vger.kernel.org > Subject: Skeleton LinuxDVB framework > > Hi all, > > As a newbie to the LinuxDVB Device drivers, I am wondering if there is a > framework template to get a quick start in to DVB device drivers. I > currently have a SOC chip and an manufacturers API that I would like to make > in to a LinuxDVB compliant device. (Tuners/Demods/CA/MPEG output hardware > etc) It is probably easier to get one driver of each type as an example and change it to fill your needs. > > Any information is greatly appreciated. > Richard > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Staging/media: fixed spacing coding style in go7007/wis-ov7640.c
On Fri, Nov 2, 2012 at 1:08 PM, YAMANE Toshiaki wrote:
> fixed below checkpatch error.
> - ERROR: that open brace { should be on the previous line
>
> Signed-off-by: YAMANE Toshiaki
Tested-by: Peter Senna Tschudin
> ---
> drivers/staging/media/go7007/wis-ov7640.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/go7007/wis-ov7640.c
> b/drivers/staging/media/go7007/wis-ov7640.c
> index 6bc9470..eb5efc9 100644
> --- a/drivers/staging/media/go7007/wis-ov7640.c
> +++ b/drivers/staging/media/go7007/wis-ov7640.c
> @@ -29,8 +29,7 @@ struct wis_ov7640 {
> int hue;
> };
>
> -static u8 initial_registers[] =
> -{
> +static u8 initial_registers[] = {
> 0x12, 0x80,
> 0x12, 0x54,
> 0x14, 0x24,
> --
> 1.7.9.5
>
> --
> 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
--
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Staging/media: Use dev_ printks in go7007/wis-ov7640.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/wis-ov7640.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/go7007/wis-ov7640.c
b/drivers/staging/media/go7007/wis-ov7640.c
index eb5efc9..fe46374 100644
--- a/drivers/staging/media/go7007/wis-ov7640.c
+++ b/drivers/staging/media/go7007/wis-ov7640.c
@@ -59,12 +59,12 @@ static int wis_ov7640_probe(struct i2c_client *client,
client->flags = I2C_CLIENT_SCCB;
- printk(KERN_DEBUG
+ dev_dbg(&client->dev,
"wis-ov7640: initializing OV7640 at address %d on %s\n",
client->addr, adapter->name);
if (write_regs(client, initial_registers) < 0) {
- printk(KERN_ERR "wis-ov7640: error initializing OV7640\n");
+ dev_err(&client->dev, "wis-ov7640: error initializing
OV7640\n");
return -ENODEV;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Staging/media: fixed spacing coding style in go7007/wis-ov7640.c
fixed below checkpatch error.
- ERROR: that open brace { should be on the previous line
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/wis-ov7640.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/go7007/wis-ov7640.c
b/drivers/staging/media/go7007/wis-ov7640.c
index 6bc9470..eb5efc9 100644
--- a/drivers/staging/media/go7007/wis-ov7640.c
+++ b/drivers/staging/media/go7007/wis-ov7640.c
@@ -29,8 +29,7 @@ struct wis_ov7640 {
int hue;
};
-static u8 initial_registers[] =
-{
+static u8 initial_registers[] = {
0x12, 0x80,
0x12, 0x54,
0x14, 0x24,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging/media: Use dev_ printks in cxd2099/cxd2099.[ch]
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then
pr_warn(... to printk(KERN_WARNING ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/cxd2099/cxd2099.c | 29 +++--
drivers/staging/media/cxd2099/cxd2099.h |2 +-
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 0ff1972..822c487 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -66,8 +66,9 @@ static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, .len = 2};
if (i2c_transfer(adapter, &msg, 1) != 1) {
- printk(KERN_ERR "Failed to write to I2C register %02x@%02x!\n",
- reg, adr);
+ dev_err(&adapter->dev,
+ "Failed to write to I2C register %02x@%02x!\n",
+ reg, adr);
return -1;
}
return 0;
@@ -79,7 +80,7 @@ static int i2c_write(struct i2c_adapter *adapter, u8 adr,
struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len = len};
if (i2c_transfer(adapter, &msg, 1) != 1) {
- printk(KERN_ERR "Failed to write to I2C!\n");
+ dev_err(&adapter->dev, "Failed to write to I2C!\n");
return -1;
}
return 0;
@@ -94,7 +95,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
.buf = val, .len = 1} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- printk(KERN_ERR "error in i2c_read_reg\n");
+ dev_err(&adapter->dev, "error in i2c_read_reg\n");
return -1;
}
return 0;
@@ -109,7 +110,7 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
.buf = data, .len = n} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- printk(KERN_ERR "error in i2c_read\n");
+ dev_err(&adapter->dev, "error in i2c_read\n");
return -1;
}
return 0;
@@ -277,7 +278,7 @@ static void cam_mode(struct cxd *ci, int mode)
#ifdef BUFFER_MODE
if (!ci->en.read_data)
return;
- printk(KERN_INFO "enable cam buffer mode\n");
+ dev_info(&ci->i2c->dev, "enable cam buffer mode\n");
/* write_reg(ci, 0x0d, 0x00); */
/* write_reg(ci, 0x0e, 0x01); */
write_regm(ci, 0x08, 0x40, 0x40);
@@ -524,7 +525,7 @@ static int slot_reset(struct dvb_ca_en50221 *ca, int slot)
msleep(10);
#if 0
read_reg(ci, 0x06, &val);
- printk(KERN_INFO "%d:%02x\n", i, val);
+ dev_info(&ci->i2c->dev, "%d:%02x\n", i, val);
if (!(val&0x10))
break;
#else
@@ -542,7 +543,7 @@ static int slot_shutdown(struct dvb_ca_en50221 *ca, int
slot)
{
struct cxd *ci = ca->data;
- printk(KERN_INFO "slot_shutdown\n");
+ dev_info(&ci->i2c->dev, "slot_shutdown\n");
mutex_lock(&ci->lock);
write_regm(ci, 0x09, 0x08, 0x08);
write_regm(ci, 0x20, 0x80, 0x80); /* Reset CAM Mode */
@@ -578,10 +579,10 @@ static int campoll(struct cxd *ci)
if (istat&0x40) {
ci->dr = 1;
- printk(KERN_INFO "DR\n");
+ dev_info(&ci->i2c->dev, "DR\n");
}
if (istat&0x20)
- printk(KERN_INFO "WC\n");
+ dev_info(&ci->i2c->dev, "WC\n");
if (istat&2) {
u8 slotstat;
@@ -597,7 +598,7 @@ static int campoll(struct cxd *ci)
if (ci->slot_stat) {
ci->slot_stat = 0;
write_regm(ci, 0x03, 0x00, 0x08);
- printk(KERN_INFO "NO CAM\n");
+ dev_info(&ci->i2c->dev, "NO CAM\n");
ci->ready = 0;
}
}
@@ -634,7 +635,7 @@ static int read_data(struct dvb_ca_en50221 *ca, int slot,
u8 *ebuf, int ecount)
campoll(ci);
mutex_unlock(&ci->lock);
- printk(KERN_INFO "read_data\n");
+ dev_info(&ci->i2c->dev, "read_data\n");
if (!ci->dr)
return 0;
@@ -687,7 +688,7 @@ struct dvb_ca_en50221 *cxd2099_attach(struct cxd2099_cfg
*cfg,
u8 val;
if (i2c_read_reg(i2c, cfg->adr, 0, &val) < 0) {
- printk(KERN_INFO "No CXD2099 detected at %02x\n", cfg->adr);
+
Re: [PATCH] stkwebcam: Fix sparse warning on undeclared symbol
> why the heck do we need this first_init? first_init was introduced in 7b1c8f58fcdbed75 for turning off LED when the cam finishes the capture. Andrea Anacleto claimed that the change broke his webcam on the same laptop, so he introduced that variable to fix the issue. It didn't have any impact to my cam so I merged it's patch and resent my fix to the maintainer. -- 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
