gmane.linux.davinci

can't get right data from ISP ISIF

achun liu — 2013-05-17T07:30:19

hi,all,

I use the OV8810 chip,the output formats is RAW 8bit bggr, my data flow is
'CSI2A->IPIPEIF->ISIF->SDRAM',but all of the data get from SDRAM is 0, the
data get from CSI2A is right when I use 'CSI2A->SDRAM', I don't know this
is why,the following is the register debug:

[   96.365966] : -------------IPIPEIF Register dump-------------
[   96.366027] : ###IPIPEIF CFG1=0x00000000
[   96.366027] : ###IPIPEIF CFG2=0x00000000

[   96.366027] : ###ISIF SYNCEN=0x00000001
[   96.366058] : ###ISIF CADU=0x00000000
[   96.366058] : ###ISIF CADL=0x00000000
[   96.366058] : ###ISIF MODESET=0x00002000
[   96.366088] : ###ISIF CCOLP=0x00000000
[   96.366088] : ###ISIF SPH=0x00000000
[   96.366088] : ###ISIF LNH=0x0000077f
[   96.366119] : ###ISIF LNV=0x00000437
[   96.366119] : ###ISIF VDINT0=0x00000437
[   96.366119] : ###ISIF HSIZE=0x0000003c
[   96.366149] : ###ISP5 SYSCONFIG=0x00000021
[   96.366149] : ###ISP5 CTRL=0x0190c7f8
[   96.366149] : ###ISP5 IRQSTATUS(0)=0x00000000
[   96.366180] : ###ISP5 IRQENABLE_SET(

二

Kaori Lee — 2013-05-16T13:20:17

(unknown)

Kaori Lee — 2013-05-16T13:20:17

[PATCH RFC v3 1/4] media: i2c: adv7343: add support for asynchronousprobing

Lad Prabhakar — 2013-05-14T06:47:33

From: Lad, Prabhakar <prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Both synchronous and asynchronous adv7343 subdevice probing is supported by
this patch.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
Cc: Guennadi Liakhovetski <g.liakhovetski-Mmb7MZpHnFY< at >public.gmane.org>
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw< at >public.gmane.org>
Cc: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw< at >public.gmane.org>
Cc: Sakari Ailus <sakari.ailus-X3B1VOXEql0< at >public.gmane.org>
Cc: Mauro Carvalho Chehab <mchehab-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
---
 drivers/media/i2c/adv7343.c |   16 ++++++++++++----
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index 9fc2b98..469e262 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
< at >< at > -27,6 +27,7 < at >< at >
 #include <linux/uaccess.h>
 
 #include <media/adv7343.h>
+#include <media/v4l2-async.h>
 #include <media/v4l2-

Re: Patch for vpfe_remove()

Jose Pablo Carballo — 2013-05-12T14:33:43

Hi Prabhakar,

"When the last user of the video device node exits, then the vdev->release()
callback is called and you can do the final cleanup there."

Got it, thanks,


On Sun, May 12, 2013 at 1:21 AM, Prabhakar Lad
<prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: Patch for vpfe_remove()

Prabhakar Lad — 2013-05-12T07:21:42

Hi Jose,

On Sat, May 11, 2013 at 8:00 AM, Jose Pablo Carballo
<jose.carballo-9uBrGCPFOa1Wk0Htik3J/w< at >public.gmane.org> wrote:

NACK, refer this link
https://www.kernel.org/doc/Documentation/video4linux/v4l2-framework.txt
for more details especially refer "video_device cleanup"  section.

Regards,
--Prabhakar Lad

Patch for vpfe_remove()

Jose Pablo Carballo — 2013-05-11T02:30:45

Hi,

In file drivers/media/platform/davinci/vpfe_capture.c, function
vpfe_remove():

diff --git a/drivers/media/platform/davinci/vpfe_capture.c
b/drivers/media/platform/davinci/vpfe_capture.c
index 28d019d..f0f272f 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
< at >< at > -2045,6 +2045,7 < at >< at > static int vpfe_remove(struct platform_device *pdev)
        kfree(vpfe_dev->sd);
        v4l2_device_unregister(&vpfe_dev->v4l2_dev);
        video_unregister_device(vpfe_dev->video_dev);
+       video_device_release(vpfe_dev->video_dev);
        kfree(vpfe_dev);
        kfree(ccdc_cfg);
        return 0;


According to my understanding, the story of vpfe_dev->video_dev is as
follows:

1. It starts to exist at vpfe_probe(), through the function
video_device_alloc():

vfd = video_device_alloc();
...
vfd->release = video_device_release;
...
vpfe_dev->video_dev = vfd;
...
ret = video_register_device(vpfe_dev->video_dev,
    VFL_TYPE_GRABBER, -1);


Note that video_devi

Re: Patch for vpfe_probe()

Prabhakar Lad — 2013-05-10T04:52:03

Hi Jose,

On Thu, May 9, 2013 at 10:58 PM, Jose Pablo Carballo
<jose.carballo-9uBrGCPFOa1Wk0Htik3J/w< at >public.gmane.org> wrote:
Thanks for the finding, but the better fix would have been to just
change the go label
to probe_free_dev_mem, I have posted a patch
https://patchwork.linuxtv.org/patch/18367/
with it.

Regards,
--Prabhakar Lad

Patch for vpfe_probe()

Jose Pablo Carballo — 2013-05-09T17:28:17

Hi,

On file drivers/media/platform/davinci/vpfe_capture.c, function
vpfe_probe():

diff --git a/drivers/media/platform/davinci/vpfe_capture.c
b/drivers/media/platform/davinci/vpfe_capture.c
index 28d019d..1d9a12d 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
< at >< at > -1866,6 +1866,8 < at >< at > static int vpfe_probe(struct platform_device *pdev)
                goto probe_free_dev_mem;
        }

+       mutex_lock(&ccdc_lock);
+
        /* Allocate memory for ccdc configuration */
        ccdc_cfg = kmalloc(sizeof(struct ccdc_config), GFP_KERNEL);
        if (NULL == ccdc_cfg) {
< at >< at > -1874,8 +1876,6 < at >< at > static int vpfe_probe(struct platform_device *pdev)
                goto probe_free_lock;
        }

-       mutex_lock(&ccdc_lock);
-
        strncpy(ccdc_cfg->name, vpfe_cfg->ccdc, 32);
        /* Get VINT0 irq resource */
        res1 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);


The check NULL == ccdc_cfg takes the function to probe_free_lock on error

Re: video processing front end mutex usage and parameter passing

Prabhakar Lad — 2013-05-07T05:19:58

Hi Todd,

On Tue, May 7, 2013 at 3:58 AM, Todd Fischer <todd.fischer-9uBrGCPFOa1Wk0Htik3J/w< at >public.gmane.org> wrote:

To which function are you referring to ?

This is not required this is something similar to read, so while
reading the lock isn’t
required.


This change also doesn’t make sense as it is one and the same.

Regards,
--Prabhakar Lad

video processing front end mutex usage and parameter passing

Todd Fischer — 2013-05-06T22:28:32

Hi,

In reviewing vpfe_capture.c, we are seeing some code that seems wrong.  
We don't fully understand when the VPFE device lock needs to be held, 
but it seems the lock is not used consistently.  Also in some cases we 
found a pointer to a structure was passed in as a parameter and instead 
of accessing the contents of the structure the value of the pointer 
parameter that is local to the function was modified (effectively doing 
nothing).   The code has been in the kernel for 3+ years.

Below is an example of what we think needs to be changed.   We haven't 
tested the changes as we are still trying to verify the mutex usage.

Can someone familiar with the VPFE code give us some feedback if we are 
on the right track?

Todd

diff --git a/drivers/media/platform/davinci/vpfe_capture.c 
b/drivers/media/platform/davinci/vpfe_capture.c
index 28d019d..dc050b5 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
< at >< at > -945,7 +945,9 < at >< at > static int vpfe_g_fmt_vi

Re: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform

Sekhar Nori — 2013-05-03T09:55:32

But I doubt you will be able to sneak a new fbdev driver through. Last
time I heard, Andrew is only taking in fixes not new features.

Thanks,
Sekhar

Re: [PATCH] media: i2c: tvp7002: enable TVP7002 decoder for mediacontroller based usage

Prabhakar Lad — 2013-04-29T17:50:24

Hi Laurent,

On Mon, Apr 29, 2013 at 11:06 PM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw< at >public.gmane.org> wrote:
[snip]

not sure if exposing get and set DV timings at the pad level would be a better
idea, timings for pad's would be the same always and anyways we get DV timings
on video node. I cant think of usecase where we require get and set DV
timings at the pad level.

Regards,
--Prabhakar Lad

[PATCH] media: i2c: tvp7002: enable TVP7002 decoder for mediacontroller based usage

Prabhakar Lad — 2013-04-26T08:05:35

From: Lad, Prabhakar <prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

This patch enables tvp7002 decoder driver for media controller
based usage by adding v4l2_subdev_pad_ops  operations support
for enum_mbus_code, set_pad_format, get_pad_format and media_entity_init()
on probe and media_entity_cleanup() on remove.

The device supports 1 output pad and no input pads.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
---
 drivers/media/i2c/tvp7002.c |  125 +++++++++++++++++++++++++++++++++++++++++--
 include/media/tvp7002.h     |    2 +
 2 files changed, 122 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 027809c..b212d41 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
< at >< at > -424,6 +424,8 < at >< at > struct tvp7002 {
 int streaming;
 
 const struct tvp7002_timings_definition *current_timings;
+struct media_pad pad;
+struct v4l2_mbus_framefmt format;
 };
 
 /*
< at >< at > -880,6 +882,93 < at >< at > s

Re: dm365 linux 2.6.37 network performance

Ben Wang — 2013-04-24T10:20:39

Hi Mugunthan,

Thanks for your feed.

Can you provide the detail steps for interrupt pacing test? I can do
the test, and feed result back to you.

And I will try the fix also.

thanks
Ben

2013/4/24 Mugunthan V N <mugunthanvnm< at >ti.com>:
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source< at >linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: dm365 linux 2.6.37 network performance

Mugunthan V N — 2013-04-24T07:54:08

I don't have the board for testing. Did you tried interrupt pacing and
I don't know whether 2.6.37 has interrupt pacing. Recently there
was a fix in Davinci EMAC driver.
http://patchwork.ozlabs.org/patch/231721/

Regards
Mugunthan V N

Re: dm365 linux 2.6.37 network performance

Ben Wang — 2013-04-24T05:51:51

Hi Lad,

Thanks for your reply anyway.


Do you know who's maintainer for dm365 emac part? I want to see if I can
get anything from him.


Thanks
Ben

在 2013年4月24日星期三，Prabhakar Lad 写道：

Re: dm365 linux 2.6.37 network performance

Prabhakar Lad — 2013-04-24T04:56:12

Ccing Dlos and Mugunthan

Hi Ben,

On Tue, Apr 23, 2013 at 4:31 PM, Ben Wang <benfounder-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

I would have loved to help you but unfortunately I am not a
network driver expert I am good at multimedia only.

Regards,
--Prabhakar

davinci and camera

Darryl — 2013-04-18T13:22:19

We are on Linux-2.6.33.9 with real-time patches and attempting to add 
the Aptina MT9M131 (which seems to look mostly match the MT9M111 driver 
in that version of the kernel, so I'm using it) so that we can capture 
images on the CPU's VPIF (there is also a vpif_capture driver in these 
kernel sources.

QUESTION:  The 'Documentation/video4linux/soc-camera.txt' file 
references two required drivers: a host driver and a sensor driver. Do 
mt9m111 and vpif_capture correspond to these, respectively?

Toward the end of this email, I discuss the changes I have made to the 
board file and kernel configuration to allow usage of these drivers.

QUESTION:  Assuming a 'yes' to the previous question, in what order will 
I need to probe these drivers?

I have observed that when I "modprobe mt9m111", the "soc_camera" module 
(dependency) is loaded and "soc_camera_pdrv_probe" is successful, using 
the camera link and and platform devices from the board file.  However, 
when the mt9m111 probe runs, it expects platform data

[GIT PULL v2 3/3] ARM: davinci: board updates for v3.10 (part 2)

Sekhar Nori — 2013-04-17T17:45:58

Hi Arnd, Olof,

Please pull the following board updates for v3.10. This
depends on SoC updates in previous request.

Thanks,
Sekhar

The following changes since commit 215a084dc5cb8d814aeb7a2b5192af20aec8209f:

  ARM: davinci: ensure global variables are declared (2013-04-17 19:26:41 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/board-2-v2

for you to fetch changes up to 58b6c5a133297e0154a085cc73e832222c57729c:

  ARM: davinci: da850 evm: fix const qualifier placement (2013-04-17 22:00:09 +0530)

----------------------------------------------------------------
v3.10 board updates for DaVinci

This set of patches enables remoteproc support
on DA850 EVM and fixes some sparse warnings for
the same board.

----------------------------------------------------------------
Robert Tivy (1):
      ARM: davinci: da850 board: add remoteproc support

Sekhar Nori (1):
      ARM: davinci: da850 evm: fix const qualifier pla

Re: [GIT PULL 2/3] ARM: davinci: SoC updates for v3.10 (part 2)

Olof Johansson — 2013-04-16T16:48:38

Oh! Looking at that branch, and the new branch from you, I don't actually see
a dependency between them. Sure, the Davinci mach-side code registers a new
device, but until the driver has the corresponding changes, there's no breakage
caused by the new registration. There are no new data structures introduced
either, so there's no build-time dependency added.

So it would be just as easy to just merge this as a nondependent branch. When
both sides of the change land, remoteproc will work. But until then, nothing
existing will be broken.

Sound ok? If so, please just rebase your 4 patches on top of the old SoC branch
without the dependency and send a fresh pull request, please. :)

-Olof