Re: omap3isp device tree support

Re: omap3isp device tree support

[Laurent Pinchart]

Hi Alagan,

On Wednesday 06 August 2014 03:36:19 alaganraj sandhanam wrote:
> Hi Laurent,
> 
> I want to test mt9p031 with beagleboard-xm on 3.16 kernel.
> It seems device tree support for omap3isp is not upstreamed.
> can you please guide me to validate the same?

DT bindings for the OMAP3 ISP are unfortunately not available yet. Sakari is 
working on them, but I don't think he an commit to any date yet.

-- 
Regards,

Laurent Pinchart

Re: omap3isp device tree support

[Laurent Pinchart]

Hi Alagan,

On Wednesday 06 August 2014 04:07:58 alaganraj sandhanam wrote:
> Hi Laurent,
> 
> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git
> omap3isp/dt branch?
> I took 3 patches from this branch, fixed
> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’
> by changing to "of_graph_get_next_endpoint".
> 
> while booting i'm getting below msg
> [    1.558471] of_graph_get_next_endpoint(): no port node found in
> /ocp/omap3_isp@480bc000
> [    1.567169] omap3isp 480bc000.omap3_isp: no port node at
> /ocp/omap3_isp@480bc000
> 
> omap3isp/dt is not working branch?

The branch contains work in progress patches. If I'm not mistaken the code 
isn't complete and doesn't work yet.

-- 
Regards,

Laurent Pinchart

Re: omap3isp device tree support

[alaganraj sandhanam]

Thanks Laurent.

Regards,
Alagan

On Wed, Aug 6, 2014 at 4:11 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Alagan,
>
> On Wednesday 06 August 2014 04:07:58 alaganraj sandhanam wrote:
>> Hi Laurent,
>>
>> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git
>> omap3isp/dt branch?
>> I took 3 patches from this branch, fixed
>> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’
>> by changing to "of_graph_get_next_endpoint".
>>
>> while booting i'm getting below msg
>> [    1.558471] of_graph_get_next_endpoint(): no port node found in
>> /ocp/omap3_isp@480bc000
>> [    1.567169] omap3isp 480bc000.omap3_isp: no port node at
>> /ocp/omap3_isp@480bc000
>>
>> omap3isp/dt is not working branch?
>
> The branch contains work in progress patches. If I'm not mistaken the code
> isn't complete and doesn't work yet.
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: omap3isp device tree support

[Alaganraj Sandhanam]

Please send "unsubscribe linux-media" message with empty subject line
to majordomo@vger.kernel.org.

---------------------------------------------------------------------------------------
To: majordomo@vger.kernel.org
Subject:

unsubscribe linux-media
---------------------------------------------------------------------------------------

Regards,
Alagan

On Wed, Aug 6, 2014 at 5:59 AM, Raymond Jender <rayj00@yahoo.com> wrote:
> Why can't I get off this stinkin mail list?   The unsubscribe email does not work!
>
> Get me the heII off this list!
>
>
>
>
>
>
> On Tuesday, August 5, 2014 3:51 PM, alaganraj sandhanam <alaganraj.sandhanam@gmail.com> wrote:
>
>
>
> Thanks Laurent.
>
> Regards,
> Alagan
>
>
> On Wed, Aug 6, 2014 at 4:11 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> Hi Alagan,
>>
>> On Wednesday 06 August 2014 04:07:58 alaganraj sandhanam wrote:
>>> Hi Laurent,
>>>
>>> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git
>>> omap3isp/dt branch?
>>> I took 3 patches from this branch, fixed
>>> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’
>>> by changing to "of_graph_get_next_endpoint".
>>>
>>> while booting i'm getting below msg
>>> [    1.558471] of_graph_get_next_endpoint(): no port node found in
>>> /ocp/omap3_isp@480bc000
>>> [    1.567169] omap3isp 480bc000.omap3_isp: no port node at
>>> /ocp/omap3_isp@480bc000
>>>
>>> omap3isp/dt is not working branch?
>>
>> The branch contains work in progress patches. If I'm not mistaken the code
>> isn't complete and doesn't work yet.
>>
>> --
>> Regards,
>>
>> Laurent Pinchart
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3isp device tree support

[Sakari Ailus]

Hi Alaganraj,

On Wed, Aug 06, 2014 at 04:07:58AM +0530, alaganraj sandhanam wrote:
> Hi Laurent,
> 
> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git
> omap3isp/dt branch?
> I took 3 patches from this branch, fixed
> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’
> by changing to "of_graph_get_next_endpoint".
> 
> while booting i'm getting below msg
> [    1.558471] of_graph_get_next_endpoint(): no port node found in
> /ocp/omap3_isp@480bc000
> [    1.567169] omap3isp 480bc000.omap3_isp: no port node at
> /ocp/omap3_isp@480bc000
> 
> omap3isp/dt is not working branch?

My patches, while experimental, may be helpful for you. Perhaps. At the
moment the issue is IOMMU; Hiroshi Doyu had some patches to get that
attached to the ISP but for various reasons they didn't make it to the
mainline kernel.

You can find my patches here:

<URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-041-dt>

PLEASE do no clone the entire tree, but add that as a remote to an existing
tree. The patches are on top of the linux-omap master branch.

I think I've gotten through to sensor sub-device registration with these and
the smiapp driver. I'll try to send some of the omap3isp and possibly also
smiapp patches for review soon. It's unlikely to be a complete set, though.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: omap3isp device tree support

[Alaganraj Sandhanam]

Hi Sakari,

Thanks for the patches. I'll try this...

Thanks&Regards,
Alagan

On Thu, Aug 7, 2014 at 5:48 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> Hi Alaganraj,
>
> On Wed, Aug 06, 2014 at 04:07:58AM +0530, alaganraj sandhanam wrote:
>> Hi Laurent,
>>
>> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git
>> omap3isp/dt branch?
>> I took 3 patches from this branch, fixed
>> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’
>> by changing to "of_graph_get_next_endpoint".
>>
>> while booting i'm getting below msg
>> [    1.558471] of_graph_get_next_endpoint(): no port node found in
>> /ocp/omap3_isp@480bc000
>> [    1.567169] omap3isp 480bc000.omap3_isp: no port node at
>> /ocp/omap3_isp@480bc000
>>
>> omap3isp/dt is not working branch?
>
> My patches, while experimental, may be helpful for you. Perhaps. At the
> moment the issue is IOMMU; Hiroshi Doyu had some patches to get that
> attached to the ISP but for various reasons they didn't make it to the
> mainline kernel.
>
> You can find my patches here:
>
> <URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-041-dt>
>
> PLEASE do no clone the entire tree, but add that as a remote to an existing
> tree. The patches are on top of the linux-omap master branch.
>
> I think I've gotten through to sensor sub-device registration with these and
> the smiapp driver. I'll try to send some of the omap3isp and possibly also
> smiapp patches for review soon. It's unlikely to be a complete set, though.
>
> --
> Kind regards,
>
> Sakari Ailus
> e-mail: sakari.ailus@iki.fi     XMPP: sailus@retiisi.org.uk

Re: omap3isp device tree support

[Enrico]

On Fri, Jan 10, 2014 at 10:02 AM, Julien BERAUD
<julien.beraud@parrot.com> wrote:
>
> Le 09/01/2014 19:14, Enrico a écrit :
>
>> On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD <julien.beraud@parrot.com>
>> wrote:
>>>
>>> Le 07/01/2014 11:12, Enrico a écrit :
>>>
>>>> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD
>>>> <julien.beraud@parrot.com>
>>>> wrote:
>>>>>
>>>>> Le 03/01/2014 12:30, Enrico a écrit :
>>>>>>
>>>>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
>>>>>>> <florian.vaussard@epfl.ch> wrote:
>>>>>>>>
>>>>>>>> So I converted the iommu to DT (patches just sent), used pdata
>>>>>>>> quirks
>>>>>>>> for the isp / mtv9032 data, added a few patches from other people
>>>>>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a
>>>>>>>> few
>>>>>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony
>>>>>>>> Lindgren)
>>>>>>>> to boot on DT with a working MT9V032 camera. The missing part is the
>>>>>>>> DT
>>>>>>>> binding for the omap3isp, but I guess that we will have to wait a
>>>>>>>> bit
>>>>>>>> more for this.
>>>>>>>>
>>>>>>>> If you want to test, I have a development tree here [1]. Any
>>>>>>>> feedback
>>>>>>>> is
>>>>>>>> welcome.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Florian
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>>>>>>>
>>>>>>> Thanks Florian,
>>>>>>>
>>>>>>> i will report what i get with my setup.
>>>>>>
>>>>>> And here i am.
>>>>>>
>>>>>> I can confirm it works, video source is tvp5150 (with platform data in
>>>>>> pdata-quirks.c) in bt656 mode.
>>>>>>
>>>>>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
>>>>>> if you want to push it you can add a Tested-by me.
>>>>>>
>>>>>> There is only one problem, but it's unrelated to your DT work.
>>>>>>
>>>>>> It's an old problem (see for example [1] and [2]), seen by other
>>>>>> people too and it seems it's still there.
>>>>>> Basically if i capture with yavta while the system is idle then it
>>>>>> just waits without getting any frame.
>>>>>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
>>>>>> terminal) it starts capturing correctly.
>>>>>>
>>>>>> The strange thing is that i do get isp interrupts in the idle case, so
>>>>>> i don't know why they don't "propagate" to yavta.
>>>>>>
>>>>>> Any hints on how to debug this?
>>>>>>
>>>>>> Enrico
>>>>>>
>>>>>> [1]: https://linuxtv.org/patch/7836/
>>>>>> [2]:
>>>>>> a https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html
>>>>>
>>>>> I have had what looked a lot like these problems before and it was due
>>>>> to
>>>>> a
>>>>> wrong configuration of the ccdc cropping regarding to the blanking.
>>>>> Could
>>>>> you send me the configuration of the pipeline that you apply with
>>>>> media-ctl,
>>>>> just in case this is the same problem.
>>>>
>>>> i'm using:
>>>>
>>>> media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>>>> CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>>>> media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]'
>>>>
>>>> And then capture with yavta -s 720x625 (or 720x576, can't remember right
>>>> now).
>>>>
>>>> Thanks,
>>>>
>>>> Enrico
>>>
>>> I don't think this is sufficient, though I am no expert about omap3 isp,
>>> you
>>> should configure the format of the ccdc input and of the ccdc output too.
>>> When I had this problem, it was solved by adding cropping at the input of
>>> the CCDC, corresponding to the blanking period, which was :
>>> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]'
>>> or
>>> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]'
>>> respectively.
>>>
>>> I don't know if this can be of any help.
>>>
>>> Regards,
>>> Julien BERAUD
>>
>> It seems i can't set cropping at the CCDC input (sink), but i can on
>> output (source):
>>
>> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
>>              type V4L2 subdev subtype Unknown flags 0
>>              device node name /dev/v4l-subdev2
>>          pad0: Sink
>>                  [fmt:UYVY2X8/720x625]
>>                  <- "OMAP3 ISP CCP2":1 []
>>                  <- "OMAP3 ISP CSI2a":1 []
>>                  <- "tvp5150 1-005c":0 [ENABLED]
>>          pad1: Source
>>                  [fmt:UYVY2X8/720x576
>>                   crop.bounds:(0,0)/720x624
>>                   crop:(0,48)/720x576]
>>                  -> "OMAP3 ISP CCDC output":0 [ENABLED]
>>                  -> "OMAP3 ISP resizer":0 []
>>          pad2: Source
>>                  [fmt:unknown/720x624]
>>                  -> "OMAP3 ISP preview":0 []
>>                  -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE]
>>                  -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE]
>>                  -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE]
>>
>> The strange thing is that with these settings the situation is even
>> worse, i don't get any frames in yavta (while i see interrupts on
>> omap3isp) even with the "cat /dev/zero" trick.
>>
>> So you are right, playing with cropping can make it work or not, are
>> you sure you could set cropping at the ccdc input?
>>
>> Enrico
>
> Enrico,
>
> Sorry it didn't work. I just wanted to give a hint of what could be going
> wrong. I am sorry I don't have time to investigate, I am sure I could set
> the cropping at the input of ccdc, and that the result was to write register
> ISPCCDC_VERT_START in order to skip the vertical blanking period correctly.
> The branch I was on was a bit different though. If you want to investigate
> this issue, you will at least need to see what is written in the registers
> of the ISP.
>
> Regards,
> Julien

I think i nailed down the problem, the fix is really simple but a
better solution should be implemented:

i noticed that when the system is idle i was getting no frames with
yavta because FLDSTAT was always 0 and ccdc_isr_buffer was never
called.

In bt656 mode the VD0 interrupt is setup with (format->height/2 - 2),
probably when the system is idle it doesn't "react" and process the
interrupt soon enough so it will always get the FLDSTAT of the same
field (top or bottom).

Using (format->height/2 - 3) fix the problem (FLDSTAT toggles) BUT now
you have tons of "CCDC won't become idle.." because the default
ccdc_sbl_wait_idle(ccdc, 1000) is not enough to get the end of field.
Increasing it to 2ms helps but since we are in interrupt context i
suppose i'm delaying ALL the system so this is really ugly.

I think the real solution should be to use VD0 and VD1 interrupts, one
to get the current FLDSTAT and the other for ccdc_sbl_wait_idle.....

What do you think?

Enrico

Re: omap3isp device tree support

[Julien BERAUD]

Le 09/01/2014 19:14, Enrico a écrit :
> On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD <julien.beraud@parrot.com> wrote:
>> Le 07/01/2014 11:12, Enrico a écrit :
>>
>>> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com>
>>> wrote:
>>>> Le 03/01/2014 12:30, Enrico a écrit :
>>>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de>
>>>>> wrote:
>>>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
>>>>>> <florian.vaussard@epfl.ch> wrote:
>>>>>>> So I converted the iommu to DT (patches just sent), used pdata quirks
>>>>>>> for the isp / mtv9032 data, added a few patches from other people
>>>>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a
>>>>>>> few
>>>>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony
>>>>>>> Lindgren)
>>>>>>> to boot on DT with a working MT9V032 camera. The missing part is the
>>>>>>> DT
>>>>>>> binding for the omap3isp, but I guess that we will have to wait a bit
>>>>>>> more for this.
>>>>>>>
>>>>>>> If you want to test, I have a development tree here [1]. Any feedback
>>>>>>> is
>>>>>>> welcome.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Florian
>>>>>>>
>>>>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>>>>>> Thanks Florian,
>>>>>>
>>>>>> i will report what i get with my setup.
>>>>> And here i am.
>>>>>
>>>>> I can confirm it works, video source is tvp5150 (with platform data in
>>>>> pdata-quirks.c) in bt656 mode.
>>>>>
>>>>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
>>>>> if you want to push it you can add a Tested-by me.
>>>>>
>>>>> There is only one problem, but it's unrelated to your DT work.
>>>>>
>>>>> It's an old problem (see for example [1] and [2]), seen by other
>>>>> people too and it seems it's still there.
>>>>> Basically if i capture with yavta while the system is idle then it
>>>>> just waits without getting any frame.
>>>>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
>>>>> terminal) it starts capturing correctly.
>>>>>
>>>>> The strange thing is that i do get isp interrupts in the idle case, so
>>>>> i don't know why they don't "propagate" to yavta.
>>>>>
>>>>> Any hints on how to debug this?
>>>>>
>>>>> Enrico
>>>>>
>>>>> [1]: https://linuxtv.org/patch/7836/
>>>>> [2]:
>>>>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html
>>>> I have had what looked a lot like these problems before and it was due to
>>>> a
>>>> wrong configuration of the ccdc cropping regarding to the blanking. Could
>>>> you send me the configuration of the pipeline that you apply with
>>>> media-ctl,
>>>> just in case this is the same problem.
>>> i'm using:
>>>
>>> media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>>> CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>>> media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]'
>>>
>>> And then capture with yavta -s 720x625 (or 720x576, can't remember right
>>> now).
>>>
>>> Thanks,
>>>
>>> Enrico
>> I don't think this is sufficient, though I am no expert about omap3 isp, you
>> should configure the format of the ccdc input and of the ccdc output too.
>> When I had this problem, it was solved by adding cropping at the input of
>> the CCDC, corresponding to the blanking period, which was :
>> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]'
>> or
>> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]'
>> respectively.
>>
>> I don't know if this can be of any help.
>>
>> Regards,
>> Julien BERAUD
> It seems i can't set cropping at the CCDC input (sink), but i can on
> output (source):
>
> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
>              type V4L2 subdev subtype Unknown flags 0
>              device node name /dev/v4l-subdev2
>          pad0: Sink
>                  [fmt:UYVY2X8/720x625]
>                  <- "OMAP3 ISP CCP2":1 []
>                  <- "OMAP3 ISP CSI2a":1 []
>                  <- "tvp5150 1-005c":0 [ENABLED]
>          pad1: Source
>                  [fmt:UYVY2X8/720x576
>                   crop.bounds:(0,0)/720x624
>                   crop:(0,48)/720x576]
>                  -> "OMAP3 ISP CCDC output":0 [ENABLED]
>                  -> "OMAP3 ISP resizer":0 []
>          pad2: Source
>                  [fmt:unknown/720x624]
>                  -> "OMAP3 ISP preview":0 []
>                  -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE]
>                  -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE]
>                  -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE]
>
> The strange thing is that with these settings the situation is even
> worse, i don't get any frames in yavta (while i see interrupts on
> omap3isp) even with the "cat /dev/zero" trick.
>
> So you are right, playing with cropping can make it work or not, are
> you sure you could set cropping at the ccdc input?
>
> Enrico
Enrico,

Sorry it didn't work. I just wanted to give a hint of what could be 
going wrong. I am sorry I don't have time to investigate, I am sure I 
could set the cropping at the input of ccdc, and that the result was to 
write register ISPCCDC_VERT_START in order to skip the vertical blanking 
period correctly. The branch I was on was a bit different though. If you 
want to investigate this issue, you will at least need to see what is 
written in the registers of the ISP.

Regards,
Julien

Re: omap3isp device tree support

[Laurent Pinchart]

Hi Enrico,

On Friday 10 January 2014 00:14:47 Enrico wrote:
> On Tue, Jan 7, 2014 at 5:59 PM, Laurent Pinchart wrote:
> > On Friday 03 January 2014 12:30:33 Enrico wrote:
> >> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote:
> >> > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote:
> >> >> So I converted the iommu to DT (patches just sent),
> > 
> > Florian, I've used your patches as a base for OMAP3 ISP DT work and they
> > seem pretty good (although patch 1/7 will need to be reworked, but that's
> > not a blocker). I've just had to fix a problem with the OMAP3 IOMMU,
> > please see
> > 
> > http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912
> > b5d84550590d80b2
> > 
> > I'd appreciate your comments on that. I can post the patch already if you
> > think that would be helpful.
> > 
> > You can find my work-in-progress branch at
> > 
> > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt
> > 
> > (the last three patches are definitely not complete yet).
> > 
> >> >> used pdata quirks for the isp / mtv9032 data, added a few patches from
> >> >> other people (mainly clk to fix a crash when deferring the omap3isp
> >> >> probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part
> >> >> from Tony Lindgren) to boot on DT with a working MT9V032 camera. The
> >> >> missing part is the DT binding for the omap3isp, but I guess that we
> >> >> will have to wait a bit more for this.
> >> >> 
> >> >> If you want to test, I have a development tree here [1]. Any feedback
> >> >> is welcome.
> >> >> 
> >> >> Cheers,
> >> >> 
> >> >> Florian
> >> >> 
> >> >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
> >> > 
> >> > Thanks Florian,
> >> > 
> >> > i will report what i get with my setup.
> >> 
> >> And here i am.
> >> 
> >> I can confirm it works, video source is tvp5150 (with platform data in
> >> pdata-quirks.c) in bt656 mode.
> >> 
> >> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
> >> if you want to push it you can add a Tested-by me.
> > 
> > The second patch is not clean enough in my opinion. I need to find time to
> > work on it. I had set some time aside for OMAP3 ISP development last week
> > but I've ended up working on DT support (not done yet, I've worked with
> > Sakari and he might finish the job in the upcoming weeks) instead of
> > BT.656. I'm afraid this will have to wait for around three weeks.
> 
> Yes i know the history of those patches, and if i'm not wrong you
> didn't have the hardware to test them so i just wanted to confirm that
> they work (apart from the other problem).

That's correct, but thanks to a generous donator (who I'm not sure I can name) 
I now have the hardware, I just need to find time :-)

-- 
Regards,

Laurent Pinchart

Re: omap3isp device tree support

[Enrico]

On Tue, Jan 7, 2014 at 5:59 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Enrico,
>
> On Friday 03 January 2014 12:30:33 Enrico wrote:
>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote:
>> > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote:
>> >> So I converted the iommu to DT (patches just sent),
>
> Florian, I've used your patches as a base for OMAP3 ISP DT work and they seem
> pretty good (although patch 1/7 will need to be reworked, but that's not a
> blocker). I've just had to fix a problem with the OMAP3 IOMMU, please see
>
> http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912b5d84550590d80b2
>
> I'd appreciate your comments on that. I can post the patch already if you
> think that would be helpful.
>
> You can find my work-in-progress branch at
>
> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt
>
> (the last three patches are definitely not complete yet).
>
>> >> used pdata quirks for the isp / mtv9032 data, added a few patches from
>> >> other people (mainly clk to fix a crash when deferring the omap3isp
>> >> probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part
>> >> from Tony Lindgren) to boot on DT with a working MT9V032 camera. The
>> >> missing part is the DT binding for the omap3isp, but I guess that we will
>> >> have to wait a bit more for this.
>> >>
>> >> If you want to test, I have a development tree here [1]. Any feedback is
>> >> welcome.
>> >>
>> >> Cheers,
>> >>
>> >> Florian
>> >>
>> >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>> >
>> > Thanks Florian,
>> >
>> > i will report what i get with my setup.
>>
>> And here i am.
>>
>> I can confirm it works, video source is tvp5150 (with platform data in
>> pdata-quirks.c) in bt656 mode.
>>
>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
>> if you want to push it you can add a Tested-by me.
>
> The second patch is not clean enough in my opinion. I need to find time to
> work on it. I had set some time aside for OMAP3 ISP development last week but
> I've ended up working on DT support (not done yet, I've worked with Sakari and
> he might finish the job in the upcoming weeks) instead of BT.656. I'm afraid
> this will have to wait for around three weeks.

Yes i know the history of those patches, and if i'm not wrong you
didn't have the hardware to test them so i just wanted to confirm that
they work (apart from the other problem).

Enrico

Re: omap3isp device tree support

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

Hi,

On Thu, Jan 09, 2014 at 09:49:09PM +0100, Laurent Pinchart wrote:
> > > You can find my work-in-progress branch at
> > > 
> > > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt
> > > 
> > > (the last three patches are definitely not complete yet).
> > 
> > Great news! A while ago, Sebastian Reichel (in CC) posted an RFC for the
> > binding [2]. Are you working with him on this?
> 
> No, I've replied to Sebastian's patch but haven't received any answer. My main 
> concern is that the proposal didn't use the V4L2 DT bindings to describe the 
> pipeline.

ah sorry I thought I replied to this mail. I acknowledge all
concerns, which I received in the reply. I have not yet found
time to continue on DT for omap3isp.

P.S.: I will continue this when I find time, but I definitely don't
feel offended if somebody else wants to continue ;)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: omap3isp device tree support

[Florian Vaussard]

Hi,

On 01/09/2014 09:49 PM, Laurent Pinchart wrote:
> Hi Florian,
> 
> On Thursday 09 January 2014 21:26:58 Florian Vaussard wrote:
>> On 01/07/2014 05:59 PM, Laurent Pinchart wrote:
>>> On Friday 03 January 2014 12:30:33 Enrico wrote:
>>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote:
>>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote:
>>>>>> So I converted the iommu to DT (patches just sent),
>>>
>>> Florian, I've used your patches as a base for OMAP3 ISP DT work and they
>>> seem pretty good (although patch 1/7 will need to be reworked, but that's
>>> not a blocker). I've just had to fix a problem with the OMAP3 IOMMU,
>>> please see
>>>
>>> http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912
>>> b5d84550590d80b2
>>
>> According to the comments on the IOMMU/DT patches [1], some work is still
>> needed to merge these patches, mainly to support other IOMMUs (OMAP4,
>> OMAP5).
> 
> Sure, the code need to be reworked, but I believe it's going in the right 
> direction and shouldn't be too complex to fix.
> 
>> So the current base is probably ok. I will resume my work on this soon.
> 
> Great, thanks.
> 
>> What are your comments on patch 1?
> 
> I just agree with Suman that there can be multiple IOMMUs and that the 
> bus_set_iommu() call should thus be kept in the init function. The current 
> infrastructure allows multiple IOMMUs to coexist as long as they're of the 
> same type (I'm pretty sure we'll have to fix that at some point). I believe 
> the problem that patch 1/7 tries to fix is actually the right behaviour.
> 

Yes I agree also with Suman, even if I do not really like the current
"trick". With the move to DT, we can probably use something like
<phandle> <-> consumer relations to improve this.

>> I briefly looked at your fix, seems ok to me. I do not figure out how it
>> worked for me.
> 
> I was puzzled by that as well :-)
> 

Will dig into this next week as well.

Regards,

Florian

Re: omap3isp device tree support

[Laurent Pinchart]

Hi Florian,

On Thursday 09 January 2014 21:26:58 Florian Vaussard wrote:
> On 01/07/2014 05:59 PM, Laurent Pinchart wrote:
> > On Friday 03 January 2014 12:30:33 Enrico wrote:
> >> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote:
> >>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote:
> >>>> So I converted the iommu to DT (patches just sent),
> > 
> > Florian, I've used your patches as a base for OMAP3 ISP DT work and they
> > seem pretty good (although patch 1/7 will need to be reworked, but that's
> > not a blocker). I've just had to fix a problem with the OMAP3 IOMMU,
> > please see
> > 
> > http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912
> > b5d84550590d80b2
>
> According to the comments on the IOMMU/DT patches [1], some work is still
> needed to merge these patches, mainly to support other IOMMUs (OMAP4,
> OMAP5).

Sure, the code need to be reworked, but I believe it's going in the right 
direction and shouldn't be too complex to fix.

> So the current base is probably ok. I will resume my work on this soon.

Great, thanks.

> What are your comments on patch 1?

I just agree with Suman that there can be multiple IOMMUs and that the 
bus_set_iommu() call should thus be kept in the init function. The current 
infrastructure allows multiple IOMMUs to coexist as long as they're of the 
same type (I'm pretty sure we'll have to fix that at some point). I believe 
the problem that patch 1/7 tries to fix is actually the right behaviour.

> I briefly looked at your fix, seems ok to me. I do not figure out how it
> worked for me.

I was puzzled by that as well :-)

> I will look at it closer next week.
> 
> > I'd appreciate your comments on that. I can post the patch already if you
> > think that would be helpful.
> 
> It is probably better to wait for the v2 of the iommu series. I can include
> your patch in it.

Please feel free to do so.

> > You can find my work-in-progress branch at
> > 
> > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt
> > 
> > (the last three patches are definitely not complete yet).
> 
> Great news! A while ago, Sebastian Reichel (in CC) posted an RFC for the
> binding [2]. Are you working with him on this?

No, I've replied to Sebastian's patch but haven't received any answer. My main 
concern is that the proposal didn't use the V4L2 DT bindings to describe the 
pipeline.

> [1] https://lkml.org/lkml/2013/12/17/197
> [2] http://thread.gmane.org/gmane.linux.drivers.devicetree/50580
-- 
Regards,

Laurent Pinchart

Re: omap3isp device tree support

[Florian Vaussard]

Hi Laurant,

On 01/07/2014 05:59 PM, Laurent Pinchart wrote:
> Hi Enrico,
> 
> On Friday 03 January 2014 12:30:33 Enrico wrote:
>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote:
>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote:
>>>> So I converted the iommu to DT (patches just sent),
> 
> Florian, I've used your patches as a base for OMAP3 ISP DT work and they seem 
> pretty good (although patch 1/7 will need to be reworked, but that's not a 
> blocker). I've just had to fix a problem with the OMAP3 IOMMU, please see
> 
> http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912b5d84550590d80b2
> 

According to the comments on the IOMMU/DT patches [1], some work is
still needed to merge these patches, mainly to support other IOMMUs
(OMAP4, OMAP5). So the current base is probably ok. I will resume my
work on this soon. What are your comments on patch 1?

I briefly looked at your fix, seems ok to me. I do not figure out how it
worked for me. I will look at it closer next week.

> I'd appreciate your comments on that. I can post the patch already if you 
> think that would be helpful.
> 

It is probably better to wait for the v2 of the iommu series. I can
include your patch in it.

> You can find my work-in-progress branch at
> 
> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt
> 
> (the last three patches are definitely not complete yet).
> 

Great news! A while ago, Sebastian Reichel (in CC) posted an RFC for the
binding [2]. Are you working with him on this?

Regards,

Florian

[1] https://lkml.org/lkml/2013/12/17/197
[2] http://thread.gmane.org/gmane.linux.drivers.devicetree/50580

Re: omap3isp device tree support

[Enrico]

On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD <julien.beraud@parrot.com> wrote:
>
> Le 07/01/2014 11:12, Enrico a écrit :
>
>> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com>
>> wrote:
>>>
>>> Le 03/01/2014 12:30, Enrico a écrit :
>>>>
>>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de>
>>>> wrote:
>>>>>
>>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
>>>>> <florian.vaussard@epfl.ch> wrote:
>>>>>>
>>>>>> So I converted the iommu to DT (patches just sent), used pdata quirks
>>>>>> for the isp / mtv9032 data, added a few patches from other people
>>>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a
>>>>>> few
>>>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony
>>>>>> Lindgren)
>>>>>> to boot on DT with a working MT9V032 camera. The missing part is the
>>>>>> DT
>>>>>> binding for the omap3isp, but I guess that we will have to wait a bit
>>>>>> more for this.
>>>>>>
>>>>>> If you want to test, I have a development tree here [1]. Any feedback
>>>>>> is
>>>>>> welcome.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Florian
>>>>>>
>>>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>>>>>
>>>>> Thanks Florian,
>>>>>
>>>>> i will report what i get with my setup.
>>>>
>>>> And here i am.
>>>>
>>>> I can confirm it works, video source is tvp5150 (with platform data in
>>>> pdata-quirks.c) in bt656 mode.
>>>>
>>>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
>>>> if you want to push it you can add a Tested-by me.
>>>>
>>>> There is only one problem, but it's unrelated to your DT work.
>>>>
>>>> It's an old problem (see for example [1] and [2]), seen by other
>>>> people too and it seems it's still there.
>>>> Basically if i capture with yavta while the system is idle then it
>>>> just waits without getting any frame.
>>>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
>>>> terminal) it starts capturing correctly.
>>>>
>>>> The strange thing is that i do get isp interrupts in the idle case, so
>>>> i don't know why they don't "propagate" to yavta.
>>>>
>>>> Any hints on how to debug this?
>>>>
>>>> Enrico
>>>>
>>>> [1]: https://linuxtv.org/patch/7836/
>>>> [2]:
>>>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html
>>>
>>> I have had what looked a lot like these problems before and it was due to
>>> a
>>> wrong configuration of the ccdc cropping regarding to the blanking. Could
>>> you send me the configuration of the pipeline that you apply with
>>> media-ctl,
>>> just in case this is the same problem.
>>
>> i'm using:
>>
>> media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>> CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>> media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]'
>>
>> And then capture with yavta -s 720x625 (or 720x576, can't remember right
>> now).
>>
>> Thanks,
>>
>> Enrico
>
> I don't think this is sufficient, though I am no expert about omap3 isp, you
> should configure the format of the ccdc input and of the ccdc output too.
> When I had this problem, it was solved by adding cropping at the input of
> the CCDC, corresponding to the blanking period, which was :
> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]'
> or
> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]'
> respectively.
>
> I don't know if this can be of any help.
>
> Regards,
> Julien BERAUD

It seems i can't set cropping at the CCDC input (sink), but i can on
output (source):

- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev2
        pad0: Sink
                [fmt:UYVY2X8/720x625]
                <- "OMAP3 ISP CCP2":1 []
                <- "OMAP3 ISP CSI2a":1 []
                <- "tvp5150 1-005c":0 [ENABLED]
        pad1: Source
                [fmt:UYVY2X8/720x576
                 crop.bounds:(0,0)/720x624
                 crop:(0,48)/720x576]
                -> "OMAP3 ISP CCDC output":0 [ENABLED]
                -> "OMAP3 ISP resizer":0 []
        pad2: Source
                [fmt:unknown/720x624]
                -> "OMAP3 ISP preview":0 []
                -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE]
                -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE]
                -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE]

The strange thing is that with these settings the situation is even
worse, i don't get any frames in yavta (while i see interrupts on
omap3isp) even with the "cat /dev/zero" trick.

So you are right, playing with cropping can make it work or not, are
you sure you could set cropping at the ccdc input?

Enrico

Re: omap3isp device tree support

[Julien BERAUD]

Le 07/01/2014 11:12, Enrico a écrit :
> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com> wrote:
>> Le 03/01/2014 12:30, Enrico a écrit :
>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote:
>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
>>>> <florian.vaussard@epfl.ch> wrote:
>>>>> So I converted the iommu to DT (patches just sent), used pdata quirks
>>>>> for the isp / mtv9032 data, added a few patches from other people
>>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few
>>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
>>>>> to boot on DT with a working MT9V032 camera. The missing part is the DT
>>>>> binding for the omap3isp, but I guess that we will have to wait a bit
>>>>> more for this.
>>>>>
>>>>> If you want to test, I have a development tree here [1]. Any feedback is
>>>>> welcome.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Florian
>>>>>
>>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>>>> Thanks Florian,
>>>>
>>>> i will report what i get with my setup.
>>> And here i am.
>>>
>>> I can confirm it works, video source is tvp5150 (with platform data in
>>> pdata-quirks.c) in bt656 mode.
>>>
>>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
>>> if you want to push it you can add a Tested-by me.
>>>
>>> There is only one problem, but it's unrelated to your DT work.
>>>
>>> It's an old problem (see for example [1] and [2]), seen by other
>>> people too and it seems it's still there.
>>> Basically if i capture with yavta while the system is idle then it
>>> just waits without getting any frame.
>>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
>>> terminal) it starts capturing correctly.
>>>
>>> The strange thing is that i do get isp interrupts in the idle case, so
>>> i don't know why they don't "propagate" to yavta.
>>>
>>> Any hints on how to debug this?
>>>
>>> Enrico
>>>
>>> [1]: https://linuxtv.org/patch/7836/
>>> [2]:
>>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html
>> I have had what looked a lot like these problems before and it was due to a
>> wrong configuration of the ccdc cropping regarding to the blanking. Could
>> you send me the configuration of the pipeline that you apply with media-ctl,
>> just in case this is the same problem.
> i'm using:
>
> media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]'
>
> And then capture with yavta -s 720x625 (or 720x576, can't remember right now).
>
> Thanks,
>
> Enrico
I don't think this is sufficient, though I am no expert about omap3 isp, 
you should configure the format of the ccdc input and of the ccdc output 
too.
When I had this problem, it was solved by adding cropping at the input 
of the CCDC, corresponding to the blanking period, which was :
- media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]'
or
- media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]'
respectively.

I don't know if this can be of any help.

Regards,
Julien BERAUD

Re: omap3isp device tree support

[Laurent Pinchart]

Hi Enrico,

On Friday 03 January 2014 12:30:33 Enrico wrote:
> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote:
> > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote:
> >> So I converted the iommu to DT (patches just sent),

Florian, I've used your patches as a base for OMAP3 ISP DT work and they seem 
pretty good (although patch 1/7 will need to be reworked, but that's not a 
blocker). I've just had to fix a problem with the OMAP3 IOMMU, please see

http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912b5d84550590d80b2

I'd appreciate your comments on that. I can post the patch already if you 
think that would be helpful.

You can find my work-in-progress branch at

http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt

(the last three patches are definitely not complete yet).

> >> used pdata quirks for the isp / mtv9032 data, added a few patches from
> >> other people (mainly clk to fix a crash when deferring the omap3isp
> >> probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part
> >> from Tony Lindgren) to boot on DT with a working MT9V032 camera. The
> >> missing part is the DT binding for the omap3isp, but I guess that we will
> >> have to wait a bit more for this.
> >> 
> >> If you want to test, I have a development tree here [1]. Any feedback is
> >> welcome.
> >> 
> >> Cheers,
> >> 
> >> Florian
> >> 
> >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
> > 
> > Thanks Florian,
> > 
> > i will report what i get with my setup.
> 
> And here i am.
> 
> I can confirm it works, video source is tvp5150 (with platform data in
> pdata-quirks.c) in bt656 mode.
> 
> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
> if you want to push it you can add a Tested-by me.

The second patch is not clean enough in my opinion. I need to find time to 
work on it. I had set some time aside for OMAP3 ISP development last week but 
I've ended up working on DT support (not done yet, I've worked with Sakari and 
he might finish the job in the upcoming weeks) instead of BT.656. I'm afraid 
this will have to wait for around three weeks.

> There is only one problem, but it's unrelated to your DT work.
> 
> It's an old problem (see for example [1] and [2]), seen by other
> people too and it seems it's still there.
> Basically if i capture with yavta while the system is idle then it
> just waits without getting any frame.
> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
> terminal) it starts capturing correctly.
> 
> The strange thing is that i do get isp interrupts in the idle case, so
> i don't know why they don't "propagate" to yavta.
> 
> Any hints on how to debug this?
> 
> Enrico
> 
> [1]: https://linuxtv.org/patch/7836/
> [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html
-- 
Regards,

Laurent Pinchart

Re: omap3isp device tree support

[Enrico]

On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com> wrote:
>
> Le 03/01/2014 12:30, Enrico a écrit :
>>
>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote:
>>>
>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
>>> <florian.vaussard@epfl.ch> wrote:
>>>>
>>>> So I converted the iommu to DT (patches just sent), used pdata quirks
>>>> for the isp / mtv9032 data, added a few patches from other people
>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few
>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
>>>> to boot on DT with a working MT9V032 camera. The missing part is the DT
>>>> binding for the omap3isp, but I guess that we will have to wait a bit
>>>> more for this.
>>>>
>>>> If you want to test, I have a development tree here [1]. Any feedback is
>>>> welcome.
>>>>
>>>> Cheers,
>>>>
>>>> Florian
>>>>
>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>>>
>>> Thanks Florian,
>>>
>>> i will report what i get with my setup.
>>
>> And here i am.
>>
>> I can confirm it works, video source is tvp5150 (with platform data in
>> pdata-quirks.c) in bt656 mode.
>>
>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
>> if you want to push it you can add a Tested-by me.
>>
>> There is only one problem, but it's unrelated to your DT work.
>>
>> It's an old problem (see for example [1] and [2]), seen by other
>> people too and it seems it's still there.
>> Basically if i capture with yavta while the system is idle then it
>> just waits without getting any frame.
>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
>> terminal) it starts capturing correctly.
>>
>> The strange thing is that i do get isp interrupts in the idle case, so
>> i don't know why they don't "propagate" to yavta.
>>
>> Any hints on how to debug this?
>>
>> Enrico
>>
>> [1]: https://linuxtv.org/patch/7836/
>> [2]:
>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html
>
> I have had what looked a lot like these problems before and it was due to a
> wrong configuration of the ccdc cropping regarding to the blanking. Could
> you send me the configuration of the pipeline that you apply with media-ctl,
> just in case this is the same problem.

i'm using:

media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
CCDC":1->"OMAP3 ISP CCDC output":0[1]'
media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]'

And then capture with yavta -s 720x625 (or 720x576, can't remember right now).

Thanks,

Enrico

Re: omap3isp device tree support

[Julien BERAUD]

Le 03/01/2014 12:30, Enrico a écrit :
> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote:
>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
>> <florian.vaussard@epfl.ch> wrote:
>>> So I converted the iommu to DT (patches just sent), used pdata quirks
>>> for the isp / mtv9032 data, added a few patches from other people
>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few
>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
>>> to boot on DT with a working MT9V032 camera. The missing part is the DT
>>> binding for the omap3isp, but I guess that we will have to wait a bit
>>> more for this.
>>>
>>> If you want to test, I have a development tree here [1]. Any feedback is
>>> welcome.
>>>
>>> Cheers,
>>>
>>> Florian
>>>
>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>> Thanks Florian,
>>
>> i will report what i get with my setup.
> And here i am.
>
> I can confirm it works, video source is tvp5150 (with platform data in
> pdata-quirks.c) in bt656 mode.
>
> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
> if you want to push it you can add a Tested-by me.
>
> There is only one problem, but it's unrelated to your DT work.
>
> It's an old problem (see for example [1] and [2]), seen by other
> people too and it seems it's still there.
> Basically if i capture with yavta while the system is idle then it
> just waits without getting any frame.
> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
> terminal) it starts capturing correctly.
>
> The strange thing is that i do get isp interrupts in the idle case, so
> i don't know why they don't "propagate" to yavta.
>
> Any hints on how to debug this?
>
> Enrico
>
> [1]: https://linuxtv.org/patch/7836/
> [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
I have had what looked a lot like these problems before and it was due 
to a wrong configuration of the ccdc cropping regarding to the blanking. 
Could you send me the configuration of the pipeline that you apply with 
media-ctl, just in case this is the same problem.

Regards,
Julien BERAUD

Re: omap3isp device tree support

[Enrico]

On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote:
> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
> <florian.vaussard@epfl.ch> wrote:
>> So I converted the iommu to DT (patches just sent), used pdata quirks
>> for the isp / mtv9032 data, added a few patches from other people
>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few
>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
>> to boot on DT with a working MT9V032 camera. The missing part is the DT
>> binding for the omap3isp, but I guess that we will have to wait a bit
>> more for this.
>>
>> If you want to test, I have a development tree here [1]. Any feedback is
>> welcome.
>>
>> Cheers,
>>
>> Florian
>>
>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>
> Thanks Florian,
>
> i will report what i get with my setup.

And here i am.

I can confirm it works, video source is tvp5150 (with platform data in
pdata-quirks.c) in bt656 mode.

Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so
if you want to push it you can add a Tested-by me.

There is only one problem, but it's unrelated to your DT work.

It's an old problem (see for example [1] and [2]), seen by other
people too and it seems it's still there.
Basically if i capture with yavta while the system is idle then it
just waits without getting any frame.
If i add some cpu load (usually i do a "cat /dev/zero" in a ssh
terminal) it starts capturing correctly.

The strange thing is that i do get isp interrupts in the idle case, so
i don't know why they don't "propagate" to yavta.

Any hints on how to debug this?

Enrico

[1]: https://linuxtv.org/patch/7836/
[2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html

Re: omap3isp device tree support

[Enrico]

On Mon, Dec 23, 2013 at 6:45 PM, Enrico <ebutera@users.berlios.de> wrote:
> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote:
>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
>> <florian.vaussard@epfl.ch> wrote:
>>> So I converted the iommu to DT (patches just sent), used pdata quirks
>>> for the isp / mtv9032 data, added a few patches from other people
>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few
>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
>>> to boot on DT with a working MT9V032 camera. The missing part is the DT
>>> binding for the omap3isp, but I guess that we will have to wait a bit
>>> more for this.
>>>
>>> If you want to test, I have a development tree here [1]. Any feedback is
>>> welcome.
>>>
>>> Cheers,
>>>
>>> Florian
>>>
>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>>
>> Thanks Florian,
>>
>> i will report what i get with my setup.
>
> Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe:

Sorry for the noise, it was a stupid problem with DT.

Enrico

Re: omap3isp device tree support

[Enrico]

On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote:
> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
> <florian.vaussard@epfl.ch> wrote:
>> So I converted the iommu to DT (patches just sent), used pdata quirks
>> for the isp / mtv9032 data, added a few patches from other people
>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few
>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
>> to boot on DT with a working MT9V032 camera. The missing part is the DT
>> binding for the omap3isp, but I guess that we will have to wait a bit
>> more for this.
>>
>> If you want to test, I have a development tree here [1]. Any feedback is
>> welcome.
>>
>> Cheers,
>>
>> Florian
>>
>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt
>
> Thanks Florian,
>
> i will report what i get with my setup.

Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe:

[    1.575225] console [ttyO2] enabled
[    1.581268] Unhandled fault: external abort on non-linefetch
(0x1028) at 0xfb042050
[    1.589324] Internal error: : 1028 [#1] ARM
[    1.593719] Modules linked in:
[    1.596954] CPU: 0 PID: 1 Comm: swapper Tainted: G        W    3.13.0-rc3+ #2
[    1.604461] task: de870000 ti: de86c000 task.ti: de86c000
[    1.610137] PC is at serial_omap_probe+0x3a8/0x644
[    1.615203] LR is at trace_hardirqs_on_caller+0x104/0x1dc
[    1.620849] pc : [<c028c0a4>]    lr : [<c006411c>]    psr: 20000153
[    1.620849] sp : de86de30  ip : c06f8784  fp : 00000000
[    1.632934] r10: 00000000  r9 : dea931ad  r8 : c0b7e144
[    1.638397] r7 : dea75c50  r6 : de8e4c00  r5 : de8e4c10  r4 : dea93010
[    1.645263] r3 : fb042000  r2 : fb042050  r1 : 00000014  r0 : 00000000
[    1.652130] Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM
Segment kernel
[    1.659912] Control: 10c5387d  Table: 80004019  DAC: 00000015
[    1.665924] Process swapper (pid: 1, stack limit = 0xde86c240)
[    1.672058] Stack: (0xde86de30 to 0xde86e000)
[    1.676635] de20:                                     c053bd40
dea931ad 00000000 00000000
[    1.685241] de40: de8e4c10 00000000 de8e4c10 c0636340 00000000
00000000 c0636340 0000006e
[    1.693847] de60: de86c030 c029414c c0294134 c0b7e618 de8e4c10
c0292c98 de8e4c10 c0636340
[    1.702453] de80: de8e4c44 00000000 c05eb8ac c0292e90 00000000
c0636340 c0292dfc c02912a8
[    1.711029] dea0: de803aa8 de8c8050 c0636340 de9e4900 c0636ec0
c029246c c0559bec c0636340
[    1.719635] dec0: 00000006 c0636340 00000006 c064e500 c064e500
c0293254 00000000 c05fddf8
[    1.728240] dee0: 00000006 c05eb8cc c05fddf8 c00087e4 de870000
c0620438 60000153 c0068fcc
[    1.736816] df00: c064e500 00001480 c0620434 c05f72e0 c05f72b8
c0439170 00000002 de86c000
[    1.745422] df20: c0f9e9f5 c04568d4 0000006e c004be2c c05ab990
00000006 c0f9ea08 00000006
[    1.754028] df40: 60000153 c05fddf8 00000006 c064e500 c064e500
c05d1480 0000006e c05f72e0
[    1.762634] df60: c05f72d4 c05d1c68 00000006 00000006 c05d1480
00000000 c00550a0 052d1144
[    1.771209] df80: 08010820 00000000 c04310f4 00000000 00000000
00000000 00000000 00000000
[    1.779815] dfa0: 00000000 c04310fc 00000000 c000e048 00000000
00000000 00000000 00000000
[    1.788421] dfc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[    1.796997] dfe0: 00000000 00000000 00000000 00000000 00000013
00000000 41001412 44300082
[    1.805633] [<c028c0a4>] (serial_omap_probe+0x3a8/0x644) from
[<c029414c>] (platform_drv_probe+0x18/0x48)
[    1.815673] [<c029414c>] (platform_drv_probe+0x18/0x48) from
[<c0292c98>] (driver_probe_device+0x114/0x234)
[    1.825927] [<c0292c98>] (driver_probe_device+0x114/0x234) from
[<c0292e90>] (__driver_attach+0x94/0x98)
[    1.835906] [<c0292e90>] (__driver_attach+0x94/0x98) from
[<c02912a8>] (bus_for_each_dev+0x60/0x94)
[    1.845428] [<c02912a8>] (bus_for_each_dev+0x60/0x94) from
[<c029246c>] (bus_add_driver+0x148/0x1f0)
[    1.855010] [<c029246c>] (bus_add_driver+0x148/0x1f0) from
[<c0293254>] (driver_register+0x78/0xf8)
[    1.864532] [<c0293254>] (driver_register+0x78/0xf8) from
[<c05eb8cc>] (serial_omap_init+0x20/0x44)
[    1.874053] [<c05eb8cc>] (serial_omap_init+0x20/0x44) from
[<c00087e4>] (do_one_initcall+0x100/0x150)
[    1.883758] [<c00087e4>] (do_one_initcall+0x100/0x150) from
[<c05d1c68>] (kernel_init_freeable+0x1fc/0x29c)
[    1.894012] [<c05d1c68>] (kernel_init_freeable+0x1fc/0x29c) from
[<c04310fc>] (kernel_init+0x8/0x120)
[    1.903717] [<c04310fc>] (kernel_init+0x8/0x120) from [<c000e048>]
(ret_from_fork+0x14/0x2c)
[    1.912567] Code: e5d42051 e5943024 e3a01014 e0832211 (e5923000)


is it a known bug? something i should check in my config/dts?

Enrico

Re: omap3isp device tree support

[Enrico]

On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> So I converted the iommu to DT (patches just sent), used pdata quirks
> for the isp / mtv9032 data, added a few patches from other people
> (mainly clk to fix a crash when deferring the omap3isp probe), and a few
> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
> to boot on DT with a working MT9V032 camera. The missing part is the DT
> binding for the omap3isp, but I guess that we will have to wait a bit
> more for this.
>
> If you want to test, I have a development tree here [1]. Any feedback is
> welcome.
>
> Cheers,
>
> Florian
>
> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt

Thanks Florian,

i will report what i get with my setup.

Enrico

Re: omap3isp device tree support

[Florian Vaussard]

Hello Enrico,

On 12/06/2013 11:54 AM, Enrico wrote:
> On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard
> <florian.vaussard@epfl.ch> wrote:
>> Hello,
>>
>> On 12/06/2013 11:13 AM, Enrico wrote:
>>> Hi,
>>>
>>> i know there is some work going on for omap3isp device tree support,
>>> but right now is it possible to enable it in some other way in a DT
>>> kernel?
>>>
>>
>> The DT support is not yet ready, but an RFC binding has been proposed.
>> It won't be ready for 3.14.
>>
>>> I've tried enabling it in board-generic.c (omap3_init_camera(...) with
>>> proper platform data) but it hangs early at boot, do someone know if
>>> it's possible and how to do it?
>>>
>>
>> I did the same a few days ago, and went through several problems
>> (panics, half DT support,...). Now I am able to probe the ISP, I still
>> have one kernel panic to fix. Hope to send the patches in 1 or 2 days.
>> We are still in a transition period, but things should calm down in the
>> coming releases.
>>

So I converted the iommu to DT (patches just sent), used pdata quirks
for the isp / mtv9032 data, added a few patches from other people
(mainly clk to fix a crash when deferring the omap3isp probe), and a few
small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren)
to boot on DT with a working MT9V032 camera. The missing part is the DT
binding for the omap3isp, but I guess that we will have to wait a bit
more for this.

If you want to test, I have a development tree here [1]. Any feedback is
welcome.

Cheers,

Florian

[1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt

Re: omap3isp device tree support

[Laurent Pinchart]

Hi Enrico,

On Friday 06 December 2013 11:13:50 Enrico wrote:
> Hi,
> 
> i know there is some work going on for omap3isp device tree support,
> but right now is it possible to enable it in some other way in a DT
> kernel?
> 
> I've tried enabling it in board-generic.c (omap3_init_camera(...) with
> proper platform data) but it hangs early at boot, do someone know if
> it's possible and how to do it?

Here's what I currently use to test the mt9v032 driver on my Beagleboard-xM
with a mainline kernel. If you need proper regulators support it will get more
complex.

commit 9184392db932be81ea9d33080c1740c3a20f5132
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Mon Jun 20 13:21:17 2011 +0200

    board-omap3beagle: Add support for the MT9V034 sensor module
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1f25f3e..8bc8695 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -239,7 +239,8 @@ obj-$(CONFIG_SOC_OMAP2420)		+= msdi.o
 obj-$(CONFIG_MACH_OMAP_GENERIC)		+= board-generic.o pdata-quirks.o
 obj-$(CONFIG_MACH_OMAP_H4)		+= board-h4.o
 obj-$(CONFIG_MACH_OMAP_2430SDP)		+= board-2430sdp.o
-obj-$(CONFIG_MACH_OMAP3_BEAGLE)		+= board-omap3beagle.o
+obj-$(CONFIG_MACH_OMAP3_BEAGLE)		+= board-omap3beagle.o \
+					   board-omap3beagle-camera.o
 obj-$(CONFIG_MACH_DEVKIT8000)     	+= board-devkit8000.o
 obj-$(CONFIG_MACH_OMAP_LDP)		+= board-ldp.o
 obj-$(CONFIG_MACH_OMAP3530_LV_SOM)      += board-omap3logic.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 0000000..c927c23
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,93 @@
+/*
+ * arch/arm/mach-omap2/board-omap3beagle-camera.c
+ *
+ * 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.
+ */
+
+#include <asm/mach-types.h>
+#include <linux/clk.h>
+#include <linux/i2c.h>
+#include <linux/regulator/fixed.h>
+#include <linux/regulator/machine.h>
+#include <plat/cpu.h>
+#include <plat/i2c.h>
+
+#include <media/mt9v032.h>
+#include <media/omap3isp.h>
+
+#include "devices.h"
+
+#define MT9V034_RESET_GPIO	98
+
+static struct regulator_consumer_supply mt9v034_dummy_supplies[] = {
+	REGULATOR_SUPPLY("vaa", "3-0048"),
+	REGULATOR_SUPPLY("vdd", "3-0048"),
+	REGULATOR_SUPPLY("vdd_io", "3-0048"),
+};
+
+static const s64 mt9v034_link_freqs[] = {
+	13000000,
+	26600000,
+	27000000,
+	0,
+};
+
+static struct mt9v032_platform_data beagle_mt9v034_platform_data = {
+	.clk_pol	= 0,
+	.link_freqs	= mt9v034_link_freqs,
+	.link_def_freq	= 26600000,
+};
+
+static struct i2c_board_info mt9v034_camera_i2c_device = {
+	I2C_BOARD_INFO("mt9v034", 0x48),
+	.platform_data = &beagle_mt9v034_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9v034_camera_subdevs[] = {
+	{
+		.board_info = &mt9v034_camera_i2c_device,
+		.i2c_adapter_id = 3,
+	},
+	{ NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+	{
+		.subdevs = mt9v034_camera_subdevs,
+		.interface = ISP_INTERFACE_PARALLEL,
+		.bus = {
+			.parallel = {
+				.data_lane_shift = ISP_LANE_SHIFT_2,
+				.clk_pol = 0,
+			}
+		},
+	},
+	{ },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+	.xclks = {
+		[0] = {
+			.dev_id = "3-0048",
+		},
+	},
+	.subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+	if (!of_machine_is_compatible("ti,omap3-beagle-xm"))
+		return 0;
+
+	clk_add_alias(NULL, "3-0048", "cam_xclka", NULL);
+
+	regulator_register_fixed(0, mt9v034_dummy_supplies,
+				 ARRAY_SIZE(mt9v034_dummy_supplies));
+
+	omap3_init_camera(&beagle_isp_platform_data);
+
+	return 0;
+}
+late_initcall(beagle_camera_init);

-- 
Regards,

Laurent Pinchart

Re: omap3isp device tree support

[Enrico]

On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> Hello,
>
> On 12/06/2013 11:13 AM, Enrico wrote:
>> Hi,
>>
>> i know there is some work going on for omap3isp device tree support,
>> but right now is it possible to enable it in some other way in a DT
>> kernel?
>>
>
> The DT support is not yet ready, but an RFC binding has been proposed.
> It won't be ready for 3.14.
>
>> I've tried enabling it in board-generic.c (omap3_init_camera(...) with
>> proper platform data) but it hangs early at boot, do someone know if
>> it's possible and how to do it?
>>
>
> I did the same a few days ago, and went through several problems
> (panics, half DT support,...). Now I am able to probe the ISP, I still
> have one kernel panic to fix. Hope to send the patches in 1 or 2 days.
> We are still in a transition period, but things should calm down in the
> coming releases.
>
> Cheers,
>
> Florian
>
> [1] http://www.spinics.net/lists/linux-media/msg69424.html

Thanks Florian, i will gladly help in testing.

Enrico

Re: omap3isp device tree support

[Florian Vaussard]

Hello,

On 12/06/2013 11:13 AM, Enrico wrote:
> Hi,
> 
> i know there is some work going on for omap3isp device tree support,
> but right now is it possible to enable it in some other way in a DT
> kernel?
> 

The DT support is not yet ready, but an RFC binding has been proposed.
It won't be ready for 3.14.

> I've tried enabling it in board-generic.c (omap3_init_camera(...) with
> proper platform data) but it hangs early at boot, do someone know if
> it's possible and how to do it?
> 

I did the same a few days ago, and went through several problems
(panics, half DT support,...). Now I am able to probe the ISP, I still
have one kernel panic to fix. Hope to send the patches in 1 or 2 days.
We are still in a transition period, but things should calm down in the
coming releases.

Cheers,

Florian

[1] http://www.spinics.net/lists/linux-media/msg69424.html

omap3isp device tree support

[Enrico]

Hi,

i know there is some work going on for omap3isp device tree support,
but right now is it possible to enable it in some other way in a DT
kernel?

I've tried enabling it in board-generic.c (omap3_init_camera(...) with
proper platform data) but it hangs early at boot, do someone know if
it's possible and how to do it?

Thanks,

Enrico