From: Stefan Herbrechtsmeier <sherbrec@cit-ec.uni-bielefeld.de>
To: Boris Todorov <boris.st.todorov@gmail.com>
Cc: linux-media <linux-media@vger.kernel.org>
Subject: Re: omap3isp: BT.656 support
Date: Thu, 20 Oct 2011 16:36:45 +0200 [thread overview]
Message-ID: <4EA031FD.7020109@cit-ec.uni-bielefeld.de> (raw)
In-Reply-To: <CAFYgh7xhHTz9z8kqnmxRO2hBi_L-bnV-zpJESM4iBcZcftR5Eg@mail.gmail.com>
Am 20.10.2011 14:14, schrieb Boris Todorov:
> On Thu, Oct 20, 2011 at 12:03 PM, Stefan Herbrechtsmeier
> <sherbrec@cit-ec.uni-bielefeld.de> wrote:
>> Am 20.10.2011 08:56, schrieb Boris Todorov:
>>> On Wed, Oct 19, 2011 at 7:26 PM, Stefan Herbrechtsmeier
>>> <sherbrec@cit-ec.uni-bielefeld.de> wrote:
>>>> Am 18.10.2011 15:33, schrieb Boris Todorov:
>>>>> Hi
>>>>>
>>>>> I'm trying to run OMAP + TVP5151 in BT656 mode.
>>>>>
>>>>> I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git).
>>>>> Plus the following patches:
>>>>>
>>>>> TVP5151:
>>>>> https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150
>>>>>
>>>>> The latest RFC patches for BT656 support:
>>>>>
>>>>> Enrico Butera (2):
>>>>> omap3isp: ispvideo: export isp_video_mbus_to_pix
>>>>> omap3isp: ispccdc: configure CCDC registers and add BT656 support
>>>>>
>>>>> Javier Martinez Canillas (1):
>>>>> omap3isp: ccdc: Add interlaced field mode to platform data
>>>>>
>>>>>
>>>>> I'm able to configure with media-ctl:
>>>>>
>>>>> media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>>>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>>>>> media-ctl -v --set-format '"tvp5150 3-005c":0 [UYVY2X8 720x525]'
>>>>> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x525]'
>>>>> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x525]'
>>>>>
>>>>> But
>>>>> ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4
>>>>>
>>>>> sleeps after
>>>>> ...
>>>>> Buffer 1 mapped at address 0x4021d000.
>>>>> length: 756000 offset: 1515520
>>>>> Buffer 2 mapped at address 0x402d6000.
>>>>> length: 756000 offset: 2273280
>>>>> Buffer 3 mapped at address 0x4038f000.
>>>>>
>>>>> Anyone with the same issue??? This happens with every other v4l test app I used.
>>>> I had the same issue.
>>>>
>>>> Make sure that you disable the xclk when you remove your sensor driver.
>>>>
>>>> isp->platform_cb.set_xclk(isp, 0, ISP_XCLK_A)
>>> How exactly did you solved your problem? I don't see how XCLK in
>>> _remove will help. Pls explain.
>> Sorry, I mean deactive / power off your sensor.
>>> Btw I'm feeding TVP with external clock (not from xtal pins) -
>>> omap.cam_xclk -> tvp.clk_in
>> I mean the cam_xclk.
>>> And I'm using kind of hack to get it:
>>> isp_probe()
>>> + isp_set_xclk(isp, 27000000, 1);
>> This is your problem.
>>
>> You should control the clock via board / platform callback from your driver.
>> Example:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56627.html
>>
>> It is important that you set the clock to zero when your driver is not
>> in use.
>>
>> The problem is connected to the use count of the ISP and some
>> initialisation which only happen when the counter change between zero
>> and one.
>>
> tvp_probe() needs clock for i2c detected/config. tvp5150_s_power call
> happens when video starts streaming and if tvp is not configured ->
> kernel panic.
I use an other sensor and driver and this config the sensor during start
stream.
> And what about the case when TVP is used with OSC on XTAL pins and
> CLK_IN is not used at all?
Then your system will work, as you never call isp_set_xclk.
The problem is not the clock, but how the isp driver works.
It expects, that the sensor driver disable the cam_xclk, if the sensor
is not used.
> Maybe I don't fully understand what is happening...
> or isp_set_xclk() use is messing up with ISP
On my system I have the same issues as you if I don't set the cam_xclk
to zero
during stop streaming.
I haven't investigate in the real cause for the issue. I only released,
that this
issue stick together with an always enabled cam_xclk.
Regards,
Stefan
next prev parent reply other threads:[~2011-10-20 14:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-18 13:33 omap3isp: BT.656 support Boris Todorov
2011-10-18 14:07 ` Gary Thomas
2011-10-18 14:28 ` Boris Todorov
2011-10-18 14:49 ` Gary Thomas
2011-10-18 15:10 ` Boris Todorov
2011-10-18 15:24 ` Gary Thomas
2011-10-18 15:53 ` Boris Todorov
2011-10-18 16:04 ` Gary Thomas
2011-10-18 16:14 ` Boris Todorov
2011-10-18 16:24 ` Gary Thomas
2011-10-18 16:31 ` Enrico
2011-10-19 7:01 ` Boris Todorov
2011-10-19 8:28 ` Enrico
2011-10-19 9:03 ` Boris Todorov
2011-10-19 12:40 ` Enrico
2011-10-19 13:06 ` Boris Todorov
2011-10-19 15:56 ` Boris Todorov
2011-10-19 16:26 ` Stefan Herbrechtsmeier
[not found] ` <CAFYgh7xxCM0=hiU9+bFS+qA447wC4+OkCRxv1eonYMgTH7oeEw@mail.gmail.com>
2011-10-20 9:03 ` Stefan Herbrechtsmeier
2011-10-20 12:14 ` Boris Todorov
2011-10-20 14:36 ` Stefan Herbrechtsmeier [this message]
2011-10-23 19:15 ` Boris Todorov
2011-10-24 9:47 ` Gary Thomas
2011-10-24 10:33 ` Boris Todorov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EA031FD.7020109@cit-ec.uni-bielefeld.de \
--to=sherbrec@cit-ec.uni-bielefeld.de \
--cc=boris.st.todorov@gmail.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.