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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox