Re: [PATCH 4/4] media: pxa_camera: conversion to dmaengine
Hi Robert,
On Sun, 22 Mar 2015, Robert Jarzmik wrote:
From: Robert Jarzmik robert.jarz...@intel.com
Convert pxa_camera to dmaengine. This removes all DMA registers
manipulation in favor of the more generic dmaengine API.
The functional level should be the same as before. The biggest change is
in the videobuf_sg_splice() function, which splits a videobuf-dma into
As also commented below, I'm not sure splice is a good word for
splitting.
several scatterlists for 3 planes captures (Y, U, V).
Several is actually exactly 3, isn't it?
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/media/platform/soc_camera/pxa_camera.c | 428
-
1 file changed, 211 insertions(+), 217 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 8b39f44..8644022 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -28,6 +28,9 @@
#include linux/clk.h
#include linux/sched.h
#include linux/slab.h
+#include linux/dmaengine.h
+#include linux/dma-mapping.h
+#include linux/dma/pxa-dma.h
#include media/v4l2-common.h
#include media/v4l2-dev.h
@@ -38,7 +41,6 @@
#include linux/videodev2.h
-#include mach/dma.h
#include linux/platform_data/camera-pxa.h
#define PXA_CAM_VERSION 0.0.6
@@ -175,21 +177,16 @@ enum pxa_camera_active_dma {
DMA_V = 0x4,
};
-/* descriptor needed for the PXA DMA engine */
-struct pxa_cam_dma {
- dma_addr_t sg_dma;
- struct pxa_dma_desc *sg_cpu;
- size_t sg_size;
- int sglen;
-};
-
/* buffer for one video frame */
struct pxa_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
u32 code;
/* our descriptor lists for Y, U and V channels */
- struct pxa_cam_dma dmas[3];
+ struct dma_async_tx_descriptor *descs[3];
+ dma_cookie_tcookie[3];
+ struct scatterlist *sg[3];
+ int sg_len[3];
int inwork;
enum pxa_camera_active_dma active_dma;
};
@@ -207,7 +204,7 @@ struct pxa_camera_dev {
void __iomem*base;
int channels;
- unsigned intdma_chans[3];
+ struct dma_chan *dma_chans[3];
struct pxacamera_platform_data *pdata;
struct resource *res;
@@ -222,7 +219,6 @@ struct pxa_camera_dev {
spinlock_t lock;
struct pxa_buffer *active;
- struct pxa_dma_desc *sg_tail[3];
struct tasklet_struct task_eof;
u32 save_cicr[5];
@@ -259,7 +255,6 @@ static int pxa_videobuf_setup(struct videobuf_queue *vq,
unsigned int *count,
static void free_buffer(struct videobuf_queue *vq, struct pxa_buffer *buf)
{
struct soc_camera_device *icd = vq-priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct videobuf_dmabuf *dma = videobuf_to_dma(buf-vb);
int i;
@@ -276,41 +271,82 @@ static void free_buffer(struct videobuf_queue *vq,
struct pxa_buffer *buf)
if (buf-vb.state == VIDEOBUF_NEEDS_INIT)
return;
- for (i = 0; i ARRAY_SIZE(buf-dmas); i++) {
- if (buf-dmas[i].sg_cpu)
- dma_free_coherent(ici-v4l2_dev.dev,
- buf-dmas[i].sg_size,
- buf-dmas[i].sg_cpu,
- buf-dmas[i].sg_dma);
- buf-dmas[i].sg_cpu = NULL;
+ for (i = 0; i 3 buf-descs[i]; i++) {
+ async_tx_ack(buf-descs[i]);
+ dmaengine_tx_release(buf-descs[i]);
+ kfree(buf-sg[i]);
+ buf-descs[i] = NULL;
+ buf-sg[i] = NULL;
+ buf-sg_len[i] = 0;
}
videobuf_dma_unmap(vq-dev, dma);
videobuf_dma_free(dma);
buf-vb.state = VIDEOBUF_NEEDS_INIT;
+
+ dev_dbg(icd-parent, %s end (vb=0x%p) 0x%08lx %d\n, __func__,
+ buf-vb, buf-vb.baddr, buf-vb.bsize);
}
-static int calculate_dma_sglen(struct scatterlist *sglist, int sglen,
-int sg_first_ofs, int size)
+static struct scatterlist *videobuf_sg_splice(struct scatterlist *sglist,
+ int sglen, int offset, int size,
+ int *new_sg_len)
{
- int i, offset, dma_len, xfer_len;
- struct scatterlist *sg;
+ struct scatterlist *sg0, *sg, *sg_first = NULL;
+ int i, dma_len, dropped_xfer_len, dropped_remain, remain;
+ int nfirst = -1, nfirst_offset = 0, xfer_len;
- offset = sg_first_ofs;
+ *new_sg_len = 0;
+
Re: [PATCH 02/14] sh-veu: don't use COLORSPACE_JPEG.
Hi Hans, I'm not maintaining this driver, so, just On Mon, 15 Jun 2015, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com COLORSPACE_JPEG should only be used for JPEGs. Use SMPTE170M instead, which is how YCbCr images are usually encoded. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- drivers/media/platform/sh_veu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c index 77a74d3..f5e3eb3a 100644 --- a/drivers/media/platform/sh_veu.c +++ b/drivers/media/platform/sh_veu.c @@ -211,7 +211,7 @@ static enum v4l2_colorspace sh_veu_4cc2cspace(u32 fourcc) case V4L2_PIX_FMT_NV12: case V4L2_PIX_FMT_NV16: case V4L2_PIX_FMT_NV24: - return V4L2_COLORSPACE_JPEG; + return V4L2_COLORSPACE_SMPTE170M; case V4L2_PIX_FMT_RGB332: case V4L2_PIX_FMT_RGB444: case V4L2_PIX_FMT_RGB565: -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in
randconfig build error with next-20150621, in drivers/media/v4l2-core/v4l2-flash-led-class.c
Building with the attached random configuration file, drivers/built-in.o: In function `v4l2_flash_open': v4l2-flash-led-class.c:(.text+0x27f495): undefined reference to `v4l2_fh_is_singular' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x27fe35): undefined reference to `v4l2_subdev_init' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x280554): undefined reference to `v4l2_ctrl_handler_init_class' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x2805c0): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x2806a3): undefined reference to `v4l2_ctrl_new_std_menu' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x2806f3): undefined reference to `v4l2_ctrl_handler_setup' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x280732): undefined reference to `v4l2_async_register_subdev' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x280785): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x2807a9): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `v4l2_flash_release': (.text+0x280815): undefined reference to `v4l2_async_unregister_subdev' drivers/built-in.o: In function `v4l2_flash_release': (.text+0x28084a): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `v4l2_flash_close': v4l2-flash-led-class.c:(.text+0x2808c5): undefined reference to `v4l2_fh_is_singular' v4l2-flash-led-class.c:(.text+0x28093b): undefined reference to `__v4l2_ctrl_s_ctrl' drivers/built-in.o: In function `board_staging_register_clock': (.init.text+0x10ba1): undefined reference to `clk_add_alias' drivers/built-in.o:(.rodata+0xe3110): undefined reference to `v4l2_subdev_queryctrl' drivers/built-in.o:(.rodata+0xe3140): undefined reference to `v4l2_subdev_querymenu' # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.1.0-rc8 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y
Re: [PATCH 01/14] sh-veu: initialize timestamp_flags and copy timestamp info
On Mon, 15 Jun 2015, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This field wasn't set, causing WARN_ON's from the vb2 core. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- drivers/media/platform/sh_veu.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c index 2554f37..77a74d3 100644 --- a/drivers/media/platform/sh_veu.c +++ b/drivers/media/platform/sh_veu.c @@ -958,6 +958,7 @@ static int sh_veu_queue_init(void *priv, struct vb2_queue *src_vq, src_vq-ops = sh_veu_qops; src_vq-mem_ops = vb2_dma_contig_memops; src_vq-lock = veu-fop_lock; + src_vq-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(src_vq); if (ret 0) @@ -971,6 +972,7 @@ static int sh_veu_queue_init(void *priv, struct vb2_queue *src_vq, dst_vq-ops = sh_veu_qops; dst_vq-mem_ops = vb2_dma_contig_memops; dst_vq-lock = veu-fop_lock; + dst_vq-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; return vb2_queue_init(dst_vq); } @@ -1103,6 +1105,12 @@ static irqreturn_t sh_veu_isr(int irq, void *dev_id) if (!src || !dst) return IRQ_NONE; + dst-v4l2_buf.timestamp = src-v4l2_buf.timestamp; + dst-v4l2_buf.flags = ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK; + dst-v4l2_buf.flags |= + src-v4l2_buf.flags V4L2_BUF_FLAG_TSTAMP_SRC_MASK; + dst-v4l2_buf.timecode = src-v4l2_buf.timecode; + spin_lock(veu-lock); v4l2_m2m_buf_done(src, VB2_BUF_STATE_DONE); v4l2_m2m_buf_done(dst, VB2_BUF_STATE_DONE); -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in
Hello
I need your assistance to transfer $22,500,000.00 Dollars from Hong Kong -- To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [RFC PATCH 2/2] v4l2-utils: extend set-dv-timing options for RB version
Thanks for your comments Hans.
On 19/06/15 11:37 am, Hans Verkuil hverk...@xs4all.nl wrote:
utils/v4l2-ctl/v4l2-ctl-stds.cpp | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/utils/v4l2-ctl/v4l2-ctl-stds.cpp
b/utils/v4l2-ctl/v4l2-ctl-stds.cpp
index c0e919b..9734c80 100644
--- a/utils/v4l2-ctl/v4l2-ctl-stds.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-stds.cpp
@@ -41,7 +41,10 @@ void stds_usage(void)
index=index: use the index as provided
by --list-dv-timings\n
or specify timings using cvt/gtf options
as follows:\n
cvt/gtf,width=width,height=height,fps=frames per sec\n
-
interlaced=0/1,reduced-blanking=0/1\n
+
interlaced=0/1,reduced-blanking=0/1,use-rb-v2=0/1\n
+use-rb-v2 indicates whether to use
reduced blanking version 2\n
+or not. This flag is relevant only for
cvt timings and has\n
+effect only if reduced-blanking=1\n
Why not just allow a value of 2 for the reduced-blanking argument instead
of introducing a new argument? For gtf 1 and 2 mean the same thing, for
cvt 1
will use the standard RB and 2 RBv2.
The only reason for which I added another flag is to make control
parameters same as cvt spreadsheet. But, yes, we could accept
reduced-blanking = 2. I will post version 2 with this change.
Seems simpler to me. It also means that calc_cvt_modeline doesn't need a
new
argument, just that bool reduced_blanking becomes int reduced_blanking.
Other than this it looks good to me.
Regards,
Hans
or give a fully specified timings:\n
width=width,height=height,interlaced=0/1,\n
polarities=polarities
mask,pixelclock=pixelclock Hz,\n
@@ -148,6 +151,7 @@ enum timing_opts {
GTF,
FPS,
REDUCED_BLANK,
+USE_RB_V2,
};
static int parse_timing_subopt(char **subopt_str, int *value)
@@ -175,6 +179,7 @@ static int parse_timing_subopt(char **subopt_str,
int *value)
gtf,
fps,
reduced-blanking,
+use-rb-v2,
NULL
};
@@ -205,6 +210,7 @@ static void get_cvt_gtf_timings(char *subopt, int
standard,
int fps = 0;
int r_blank = 0;
int interlaced = 0;
+int use_rb_v2 = 0;
bool timings_valid = false;
@@ -231,6 +237,8 @@ static void get_cvt_gtf_timings(char *subopt, int
standard,
case INTERLACED:
interlaced = opt_val;
break;
+case USE_RB_V2:
+use_rb_v2 = opt_val;
default:
break;
}
@@ -240,7 +248,8 @@ static void get_cvt_gtf_timings(char *subopt, int
standard,
timings_valid = calc_cvt_modeline(width, height, fps,
r_blank == 1 ? true : false,
interlaced == 1 ? true : false,
- false, bt);
+ use_rb_v2 == 1 ? true : false,
+ bt);
} else {
timings_valid = calc_gtf_modeline(width, height, fps,
r_blank == 1 ? true : false,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [PATCH 4/4] media: pxa_camera: conversion to dmaengine
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:
Hi Robert,
On Sun, 22 Mar 2015, Robert Jarzmik wrote:
From: Robert Jarzmik robert.jarz...@intel.com
Convert pxa_camera to dmaengine. This removes all DMA registers
manipulation in favor of the more generic dmaengine API.
The functional level should be the same as before. The biggest change is
in the videobuf_sg_splice() function, which splits a videobuf-dma into
As also commented below, I'm not sure splice is a good word for
splitting.
Ok. I'm all ears for your best candidate :)
several scatterlists for 3 planes captures (Y, U, V).
Several is actually exactly 3, isn't it?
Yup, it's 3, definitely. I can amend the commit message accordingly.
+static struct scatterlist *videobuf_sg_splice(struct scatterlist *sglist,
+ int sglen, int offset, int size,
+ int *new_sg_len)
{
-int i, offset, dma_len, xfer_len;
-struct scatterlist *sg;
+struct scatterlist *sg0, *sg, *sg_first = NULL;
+int i, dma_len, dropped_xfer_len, dropped_remain, remain;
+int nfirst = -1, nfirst_offset = 0, xfer_len;
-offset = sg_first_ofs;
+*new_sg_len = 0;
+dropped_remain = offset;
+remain = size;
for_each_sg(sglist, sg, sglen, i) {
Ok, after something-that-felt-like-hours of looking at this code, I think,
I understand now, that first you calculate what sg elements have been used
for offset bytes, which is either 0, or the size of the Y plain, or size
of Y + U plains.
You can say it that way. I'd say that I calculate how to malloc and fill a new
scatter-gather to represent [offset, offset + size [ interval of the original
sglist.
dma_len = sg_dma_len(sg);
-
/* PXA27x Developer's Manual 27.4.4.1: round up to 8 bytes */
-xfer_len = roundup(min(dma_len - offset, size), 8);
+dropped_xfer_len = roundup(min(dma_len, dropped_remain), 8);
+if (dropped_remain)
+dropped_remain -= dropped_xfer_len;
+xfer_len = dma_len - dropped_xfer_len;
+
+if ((nfirst 0) (xfer_len 0)) {
Superfluous parentheses
Got it.
+sg_first = sg;
+nfirst = i;
+nfirst_offset = dropped_xfer_len;
+}
+if (xfer_len 0) {
+*new_sg_len = *new_sg_len + 1;
make it
+ (*new_sg_len)++;
Got it.
static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
enum pxa_camera_active_dma act_dma);
@@ -343,93 +379,59 @@ static void pxa_camera_dma_irq_v(void *data)
* @channel: dma channel (0 = 'Y', 1 = 'U', 2 = 'V')
* @cibr: camera Receive Buffer Register
* @size: bytes to transfer
- * @sg_first: first element of sg_list
- * @sg_first_ofs: offset in first element of sg_list
+ * @offset: offset in videobuffer of the first byte to transfer
*
* Prepares the pxa dma descriptors to transfer one camera channel.
- * Beware sg_first and sg_first_ofs are both input and output parameters.
*
- * Returns 0 or -ENOMEM if no coherent memory is available
+ * Returns 0 if success or -ENOMEM if no memory is available
*/
static int pxa_init_dma_channel(struct pxa_camera_dev *pcdev,
struct pxa_buffer *buf,
struct videobuf_dmabuf *dma, int channel,
-int cibr, int size,
-struct scatterlist **sg_first, int
*sg_first_ofs)
+int cibr, int size, int offset)
{
Hmm, ok, can you, please, explain, why you have to change this so much?
IIUC, the functionality, that you're implementing now is rather similar to
the present one - you split the global videobuf SG list into 3 SG lists
for YUV formats. Of course, details are different, you don't use
pxa_dma_desc and all the low-level values directly, you prepare a standard
SG list for your dmaengine driver. But the splitting is the same, isn't
it?
The overall splitting is the same, yes : split one global SG list into 3 SG
lists.
And the current one seems rather good to me, because it preserves and
re-uses partially consumed pointers instead of recalculating them every
time, like you do it in your new version. What's the reason for that? Is
the current version buggy or the current approach unsuitable for your new
version?
Let's say unsuitable, or to be more correct, let's say that I didn't found any
better idea yet. As I find that piece of code a bit complicated too, I'll tell
you what was my need for doing it, and maybe you'll/we'll come up with a better
idea.
The previous version had the good fortune to rely on a _single_ scatter-gather
list. Only the DMA descriptors list was computed to be 3 lists
(dma[channe].sg_cpu[0..n]).
The new version must have 3 separated SG lists, each
Re: [PATCH 3/4] media: pxa_camera: trivial move of dma irq functions
On Sat, 20 Jun 2015, Robert Jarzmik wrote: Guennadi Liakhovetski g.liakhovet...@gmx.de writes: +static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev, + enum pxa_camera_active_dma act_dma); + +static void pxa_camera_dma_irq_y(void *data) Wait, how is this patch trivial? You change pxa_camera_dma_irq_?() prototypes, which are used as PXA DMA callbacks. Does this mean, that either before or after this patch compilation is broken? Jeez you're right. So I can either fold that with patch 4, or try to rework it somehow ... How about letting that patch do exactly what it says it does? Just move functions up in the file if you need them there, without changing them, and only change them when it's needed? Thanks Guennadi -- To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [PATCH 04/14] tw9910: init priv-scale and update standard
On Mon, 15 Jun 2015, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
When the standard changes the VACTIVE and VDELAY values need to be updated.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/soc_camera/tw9910.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/soc_camera/tw9910.c
b/drivers/media/i2c/soc_camera/tw9910.c
index df66417..e939c24 100644
--- a/drivers/media/i2c/soc_camera/tw9910.c
+++ b/drivers/media/i2c/soc_camera/tw9910.c
@@ -510,13 +510,39 @@ static int tw9910_s_std(struct v4l2_subdev *sd,
v4l2_std_id norm)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct tw9910_priv *priv = to_tw9910(client);
+ const unsigned hact = 720;
+ const unsigned hdelay = 15;
+ unsigned vact;
+ unsigned vdelay;
+ int ret;
if (!(norm (V4L2_STD_NTSC | V4L2_STD_PAL)))
return -EINVAL;
priv-norm = norm;
+ if (norm V4L2_STD_525_60) {
+ vact = 240;
+ vdelay = 18;
+ ret = tw9910_mask_set(client, VVBI, 0x10, 0x10);
+ } else {
+ vact = 288;
+ vdelay = 24;
+ ret = tw9910_mask_set(client, VVBI, 0x10, 0x00);
+ }
+ if (!ret)
+ ret = i2c_smbus_write_byte_data(client, CROP_HI,
+ ((vdelay 2) 0xc0) |
+ ((vact 4) 0x30) |
+ ((hdelay 6) 0x0c) |
+ ((hact 8) 0x03));
I personally would find ((x 0xc0) {2,4,6,8}) a bit easier for the
eyes, but this works as well for me:)
+ if (!ret)
+ ret = i2c_smbus_write_byte_data(client, VDELAY_LO,
+ vdelay 0xff);
+ if (!ret)
+ ret = i2c_smbus_write_byte_data(client, VACTIVE_LO,
+ vact 0xff);
- return 0;
+ return ret;
}
#ifdef CONFIG_VIDEO_ADV_DEBUG
@@ -820,6 +846,7 @@ static int tw9910_video_probe(struct i2c_client *client)
tw9910 Product ID %0x:%0x\n, id, priv-revision);
priv-norm = V4L2_STD_NTSC;
+ priv-scale = tw9910_ntsc_scales[0];
Why do you need this? So far everywhere in the code priv-scale is either
checked or set before use. Don't see why an additional initialisation is
needed.
Thanks
Guennadi
done:
tw9910_s_power(priv-subdev, 0);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sun, Jun 21, 2015 at 10:41:20PM +0200, Borislav Petkov wrote: On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote: Nope, well the driver requires huge amounts of work to work with PAT, that work will likely never be done, so hence the warning. Its our compromise as only 2 drivers will live on Linux like this and they are both old and rare. Hmm, so wasn't the possibility discussed to fail loading It will fail load. instead and issue a single-line pr_warn() when PAT is enabled? During review no one opposed the idea of having the warn as its a load thing, not a compile thing, and a user that does not get their driver loaded should know why, otherwise its not clear. Those big WARN() splats will only confuse people... We can certainly replace the WARN() with pr_warn(), I don't see how its confusing though as its a run time real issue. Either way whatever you recommend is fine by me. Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Jun 22 04:00:13 CEST 2015 git branch: test git hash: 6f32a8c97f11eb074027052b6b507891e5c9d8b1 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API 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
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sat, Jun 20, 2015 at 01:08:44PM +0200, Borislav Petkov wrote: On Sat, Jun 20, 2015 at 03:17:56PM +0800, Fengguang Wu wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master commit 1bf1735b478008c30acaff18ec6f4a3ff211c28a Author: Luis R. Rodriguez mcg...@suse.com AuthorDate: Mon Jun 15 10:28:16 2015 +0200 Commit: Ingo Molnar mi...@kernel.org CommitDate: Thu Jun 18 11:23:41 2015 +0200 x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled ... [ 12.956506] ivtv: Start initialization, version 1.4.3 [ 12.958238] ivtv: End initialization [ 12.959438] [ cut here ] [ 12.974076] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init+0x32/0xa3() [ 12.978017] ivtvfb needs PAT disabled, boot with nopat kernel parameter Warning says it all. You need to boot with nopat. Apparently, those devices are very seldom now and users should boot with nopat. Indeed. Luis, what is the plan, is this driver supposed to be converted to reserve_memtype(..., _PAGE_CACHE_MODE_WC, ...) at some point? Nope, well the driver requires huge amounts of work to work with PAT, that work will likely never be done, so hence the warning. Its our compromise as only 2 drivers will live on Linux like this and they are both old and rare. Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [PATCH] [media] mantis: cleanup a warning
Hi Mauro,
my bad.
On Thu, Jun 18, 2015 at 02:32:39PM -0300, Mauro Carvalho Chehab wrote:
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
drivers/media/pci/mantis/mantis_i2c.c: In function 'mantis_i2c_init':
drivers/media/pci/mantis/mantis_i2c.c:222:15: warning: variable 'intmask' set
but not used [-Wunused-but-set-variable]
u32 intstat, intmask;
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/pci/mantis/mantis_i2c.c
b/drivers/media/pci/mantis/mantis_i2c.c
index a93823490a43..d72ee47dc6e4 100644
--- a/drivers/media/pci/mantis/mantis_i2c.c
+++ b/drivers/media/pci/mantis/mantis_i2c.c
@@ -219,7 +219,7 @@ static struct i2c_algorithm mantis_algo = {
int mantis_i2c_init(struct mantis_pci *mantis)
{
- u32 intstat, intmask;
+ u32 intstat;
struct i2c_adapter *i2c_adapter = mantis-adapter;
struct pci_dev *pdev= mantis-pdev;
@@ -242,7 +242,7 @@ int mantis_i2c_init(struct mantis_pci *mantis)
dprintk(MANTIS_DEBUG, 1, Initializing I2C ..);
intstat = mmread(MANTIS_INT_STAT);
- intmask = mmread(MANTIS_INT_MASK);
+ mmread(MANTIS_INT_MASK);
I'm not sure if the mmread() is still needed. But as I don't have any
docs about the chipset I would keep it because that's how it has been
tested. I could re-test without it but I guess nobody cares about the
extra mmread() in the init path anyway.
Acked-by: Jan Klötzke j...@kloetzke.net
Regards,
Jan
mmwrite(intstat, MANTIS_INT_STAT);
dprintk(MANTIS_DEBUG, 1, Disabling I2C interrupt);
mantis_mask_ints(mantis, MANTIS_INT_I2CDONE);
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
ivtv - firmware - v4l-cx2341x*.fw - Upstream Fedora
Háu kola $ lspci -d :0016 -knn 01:08.0 Multimedia video controller [0400]: Internext Compression Inc iTVC16 (CX23416) Video Decoder [:0016] (rev 01) Subsystem: Hauppauge computer works Inc. WinTV PVR 150 [0070:8801] Kernel driver in use: ivtv Kernel modules: ivtv $ dmesg | grep ivtv [ 10.082881] ivtv: Start initialization, version 1.4.3 [ 10.085644] ivtv0: Initializing card 0 [ 10.088287] ivtv0: Autodetected Hauppauge card (cx23416 based) [ 10.094502] ivtv0: Unreasonably low latency timer, setting to 64 (was 32) [ 10.183374] ivtv0: Autodetected Hauppauge WinTV PVR-150 [ 10.240409] cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0) [ 10.380617] wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0) [ 10.431991] ivtv0: Registered device video0 for encoder MPG (4096 kB) [ 10.432151] ivtv0: Registered device video32 for encoder YUV (2048 kB) [ 10.432256] ivtv0: Registered device vbi0 for encoder VBI (1024 kB) [ 10.432358] ivtv0: Registered device video24 for encoder PCM (320 kB) [ 10.432459] ivtv0: Registered device radio0 for encoder radio [ 10.432473] ivtv0: Initialized card: Hauppauge WinTV PVR-150 [ 10.433869] ivtv: End initialization [ 11.820105] ivtv :01:08.0: Direct firmware load for v4l-cx2341x-enc.fw failed with error -2 [ 11.820119] ivtv0: Unable to open firmware v4l-cx2341x-enc.fw (must be 376836 bytes) [ 11.820124] ivtv0: Did you put the firmware in the hotplug firmware directory? [ 11.820129] ivtv0: Retry loading firmware [ 12.439735] ivtv :01:08.0: Direct firmware load for v4l-cx2341x-enc.fw failed with error -2 [ 12.439747] ivtv0: Unable to open firmware v4l-cx2341x-enc.fw (must be 376836 bytes) [ 12.439752] ivtv0: Did you put the firmware in the hotplug firmware directory? [ 12.439757] ivtv0: Failed to initialize on device video32 [ 12.439788] ivtv0: Failed to initialize on device video0 [ 12.439953] ivtv0: Failed to initialize on device vbi0 [ 12.439968] ivtv0: Failed to initialize on device video24 [ 12.440110] ivtv0: Failed to initialize on device radio0 $ modinfo ivtv | grep 'author\|firmware' author: Kevin Thayer, Chris Kennedy, Hans Verkuil firmware: v4l-cx2341x-init.mpg firmware: v4l-cx2341x-dec.fw firmware: v4l-cx2341x-enc.fw $ rpm -qi linux-firmware ... Packager: Fedora Project Vendor : Fedora Project ... Summary : Firmware files used by the Linux kernel Description : This package includes firmware files required for some devices to operate. ~~~ $ rpm -ql linux-firmware | grep v4l-cx2341x $ ~~~ # yum install ivtv-firmware ... No package ivtv-firmware available. Error: Nothing to do $ rpm -qilp https://kojipkgs.fedoraproject.org/packages/ivtv-firmware/20080701/26/noarch/ivtv-firmware-20080701-26.noarch.rpm Name: ivtv-firmware Epoch : 2 Version : 20080701 Release : 26 Architecture: noarch Install Date: (not installed) Group : System Environment/Kernel Size: 857256 License : Redistributable, no modification permitted Signature : (none) Source RPM : ivtv-firmware-20080701-26.src.rpm Build Date : Sun 08 Jun 2014 05:38:45 AM CEST Build Host : buildvm-11.phx2.fedoraproject.org Relocations : (not relocatable) Packager: Fedora Project Vendor : Fedora Project URL : http://dl.ivtvdriver.org/ivtv/firmware/ Summary : Firmware for the Hauppauge PVR 250/350/150/500/USB2 model series Description : This package contains the firmware for WinTV Hauppauge PVR 250/350/150/500/USB2 cards. /lib/firmware/ivtv-firmware-license-end-user.txt /lib/firmware/ivtv-firmware-license-oemihvisv.txt /lib/firmware/v4l-cx2341x-dec.fw /lib/firmware/v4l-cx2341x-enc.fw /lib/firmware/v4l-cx2341x-init.mpg /lib/firmware/v4l-cx25840.fw /lib/firmware/v4l-pvrusb2-24xxx-01.fw /lib/firmware/v4l-pvrusb2-29xxx-01.fw /usr/share/doc/ivtv-firmware /usr/share/doc/ivtv-firmware/license-end-user.txt /usr/share/doc/ivtv-firmware/license-oemihvisv.txt ~ Why these firmwares are not included upstream http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ ? Why these firmwares are obsoleted(?) downstream http://pkgs.fedoraproject.org/cgit/ivtv-firmware.git ? Why these firmware are not included downstream http://pkgs.fedoraproject.org/cgit/linux-firmware.git ? -- To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote: Nope, well the driver requires huge amounts of work to work with PAT, that work will likely never be done, so hence the warning. Its our compromise as only 2 drivers will live on Linux like this and they are both old and rare. Hmm, so wasn't the possibility discussed to fail loading instead and issue a single-line pr_warn() when PAT is enabled? Those big WARN() splats will only confuse people... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-media in
cx23885 risc op code error with DvbSKY T982
I have dvbsky T982. The firmware is up to date from openelec site. Nothing on the CI slot Linux xpc 4.1.0-rc8 #2 SMP Sun Jun 21 11:16:21 EEST 2015 x86_64 x86_64 x86_64 GNU/Linux I run the kernel in ubuntu dmesg from the startup [ 16.427634] CORE cx23885[0]: subsystem: 4254:0982, board: DVBSky T982 [card=51,autodetected] [ 17.275820] cx23885_dvb_register() allocating 1 frontend(s) [ 17.275822] cx23885[0]: cx23885 based dvb card [ 17.281850] DVB: registering new adapter (cx23885[0]) [ 17.281853] cx23885 :01:00.0: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... [ 17.308303] DVBSky T982 port 1 MAC address: 00:17:42:54:09:87 [ 17.308304] cx23885_dvb_register() allocating 1 frontend(s) [ 17.308305] cx23885[0]: cx23885 based dvb card [ 17.310640] DVB: registering new adapter (cx23885[0]) And /var/log/kern.log from the event. Jun 21 16:44:03 xpc kernel: [ 9793.748543] cx23885[0]: mpeg risc op code error Jun 21 16:44:03 xpc kernel: [ 9793.748548] cx23885[0]: TS2 C - dma channel status dump Jun 21 16:44:03 xpc kernel: [ 9793.748550] cx23885[0]: cmds: init risc lo : 0x78b76000 Jun 21 16:44:03 xpc kernel: [ 9793.748552] cx23885[0]: cmds: init risc hi : 0x Jun 21 16:44:03 xpc kernel: [ 9793.748554] cx23885[0]: cmds: cdt base : 0x000105e0 Jun 21 16:44:03 xpc kernel: [ 9793.748556] cx23885[0]: cmds: cdt size : 0x000a Jun 21 16:44:03 xpc kernel: [ 9793.748558] cx23885[0]: cmds: iq base: 0x00010440 Jun 21 16:44:03 xpc kernel: [ 9793.748560] cx23885[0]: cmds: iq size: 0x0010 Jun 21 16:44:03 xpc kernel: [ 9793.748562] cx23885[0]: cmds: risc pc lo : 0x78b76004 Jun 21 16:44:03 xpc kernel: [ 9793.748564] cx23885[0]: cmds: risc pc hi : 0x Jun 21 16:44:03 xpc kernel: [ 9793.748566] cx23885[0]: cmds: iq wr ptr : 0x4111 Jun 21 16:44:03 xpc kernel: [ 9793.748568] cx23885[0]: cmds: iq rd ptr : 0x4110 Jun 21 16:44:03 xpc kernel: [ 9793.748570] cx23885[0]: cmds: cdt current: 0x00010628 Jun 21 16:44:03 xpc kernel: [ 9793.748572] cx23885[0]: cmds: pci target lo : 0x4b9a42f0 Jun 21 16:44:03 xpc kernel: [ 9793.748574] cx23885[0]: cmds: pci target hi : 0x Jun 21 16:44:03 xpc kernel: [ 9793.748576] cx23885[0]: cmds: line / byte: 0x0261 Jun 21 16:44:03 xpc kernel: [ 9793.748578] cx23885[0]: risc0: 0x1c0002f0 [ write sol eol count=752 ] Jun 21 16:44:03 xpc kernel: [ 9793.748582] cx23885[0]: risc1: 0x4b9a42f0 [ INVALID sol irq2 irq1 23 20 19 cnt1 14 count=752 ] Jun 21 16:44:03 xpc kernel: [ 9793.748587] cx23885[0]: risc2: 0x [ INVALID count=0 ] Jun 21 16:44:03 xpc kernel: [ 9793.748589] cx23885[0]: risc3: 0x1c0002f0 [ write sol eol count=752 ] Jun 21 16:44:03 xpc kernel: [ 9793.748592] cx23885[0]: (0x00010440) iq 0: 0x003fb002 [ INVALID 21 20 19 18 cnt1 cnt0 resync 13 12 count=2 ] Jun 21 16:44:03 xpc kernel: [ 9793.748597] cx23885[0]: (0x00010444) iq 1: 0x4b9a4000 [ INVALID sol irq2 irq1 23 20 19 cnt1 14 count=0 ] Jun 21 16:44:03 xpc kernel: [ 9793.748601] cx23885[0]: (0x00010448) iq 2: 0x [ INVALID count=0 ] Jun 21 16:44:03 xpc kernel: [ 9793.748603] cx23885[0]: (0x0001044c) iq 3: 0x1c0002f0 [ write sol eol count=752 ] Jun 21 16:44:03 xpc kernel: [ 9793.748606] cx23885[0]: iq 4: 0x4b9a42f0 [ arg #1 ] Jun 21 16:44:03 xpc kernel: [ 9793.748608] cx23885[0]: iq 5: 0x [ arg #2 ] Jun 21 16:44:03 xpc kernel: [ 9793.748610] cx23885[0]: (0x00010458) iq 6: 0x1c0002f0 [ write sol eol count=752 ] Jun 21 16:44:03 xpc kernel: [ 9793.748613] cx23885[0]: iq 7: 0x4b9a45e0 [ arg #1 ] Jun 21 16:44:03 xpc kernel: [ 9793.748615] cx23885[0]: iq 8: 0x [ arg #2 ] Jun 21 16:44:03 xpc kernel: [ 9793.748617] cx23885[0]: (0x00010464) iq 9: 0x1c0002f0 [ write sol eol count=752 ] Jun 21 16:44:03 xpc kernel: [ 9793.748620] cx23885[0]: iq a: 0x4b9a48d0 [ arg #1 ] Jun 21 16:44:03 xpc kernel: [ 9793.748623] cx23885[0]: iq b: 0x [ arg #2 ] Jun 21 16:44:03 xpc kernel: [ 9793.748625] cx23885[0]: (0x00010470) iq c: 0x1c0002f0 [ write sol eol count=752 ] Jun 21 16:44:03 xpc kernel: [ 9793.748628] cx23885[0]: iq d: 0x4b9a4bc0 [ arg #1 ] Jun 21 16:44:03 xpc kernel: [ 9793.748629] cx23885[0]: iq e: 0x [ arg #2 ] Jun 21 16:44:03 xpc kernel: [ 9793.748631] cx23885[0]: (0x0001047c) iq f: 0x7100 [ jump irq1 count=0 ] Jun 21 16:44:03 xpc kernel: [ 9793.748634] cx23885[0]: iq 10: 0x0af829b7 [ arg #1 ] Jun 21 16:44:03 xpc kernel: [ 9793.748636] cx23885[0]: iq 11: 0x7bf7a9f0 [ arg #2 ] Jun 21 16:44:03 xpc kernel: [ 9793.748637] cx23885[0]: fifo: 0x6000 - 0x7000 Jun 21 16:44:03 xpc kernel: [ 9793.748638] cx23885[0]: ctrl: 0x00010440 - 0x104a0 Jun 21 16:44:03 xpc kernel: [ 9793.748640] cx23885[0]: ptr1_reg: 0x6be0 Jun 21 16:44:03 xpc kernel: [ 9793.748642] cx23885[0]: ptr2_reg: 0x00010628 Jun 21 16:44:03 xpc kernel: [ 9793.748643] cx23885[0]: cnt1_reg: 0x0002 Jun 21
Re: [PATCH 3/4] media: pxa_camera: trivial move of dma irq functions
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: On Sat, 20 Jun 2015, Robert Jarzmik wrote: Guennadi Liakhovetski g.liakhovet...@gmx.de writes: +static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev, +enum pxa_camera_active_dma act_dma); + +static void pxa_camera_dma_irq_y(void *data) Wait, how is this patch trivial? You change pxa_camera_dma_irq_?() prototypes, which are used as PXA DMA callbacks. Does this mean, that either before or after this patch compilation is broken? Jeez you're right. So I can either fold that with patch 4, or try to rework it somehow ... How about letting that patch do exactly what it says it does? Just move functions up in the file if you need them there, without changing them, and only change them when it's needed? Deal, for next iteration. Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in
