All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Enrico <ebutera@users.berlios.de>
Cc: linux-media@vger.kernel.org
Subject: Re: OMAP3 ISP and UYVY422
Date: Thu, 08 Sep 2011 07:43:01 -0600	[thread overview]
Message-ID: <4E68C665.8010508@mlbassoc.com> (raw)
In-Reply-To: <4E68C5DF.1040405@mlbassoc.com>

On 2011-09-08 07:40, Gary Thomas wrote:
> On 2011-09-08 07:22, Enrico wrote:
>> On Wed, Sep 7, 2011 at 5:55 PM, Gary Thomas<gary@mlbassoc.com> wrote:
>>> My UYVY422 data looks like this (raw-3.0):
>>> 0000000: 0080 0080 007f 0080 007f 0080 007f 0080 ................
>>> 0000010: 0080 0080 0080 0080 0080 0080 0080 0080 ................
>>> 0000020: 0080 0080 0080 0080 007f 0080 0080 0080 ................
>>> 0000030: 0080 007f 0080 007f 0080 007f 0080 007f ................
>>>
>>> It should look more like this (raw-2.6.32):
>>> 0000000: 8034 8033 8034 8034 8034 8034 8034 8034 .4.3.4.4.4.4.4.4
>>> 0000010: 8034 8033 8034 8034 8034 8034 8034 8033 .4.3.4.4.4.4.4.3
>>> 0000020: 8034 8034 8034 8034 8034 8034 8033 8032 .4.4.4.4.4.4.3.2
>>> 0000030: 8034 8035 8033 8034 8033 8034 8033 8034 .4.5.3.4.3.4.3.4
>>>
>>> n.b. these are grabbed from the same image on the camera, on the same
>>> board - either running the new media controller code (3.0+) or old TI
>>> PSP code (2.6.32)
>>>
>>> I've compared the CCDC registers between the two systems and they look
>>> pretty good to me (none of the differences explain the behaviour above)
>>>
>>> It looks to me like the 8 bit data coming into the CCDC is not being
>>> packed properly, as well as the second byte of each pair is being
>>> dropped.
>>>
>>> Any hints on where to look, what might be mis-configured, etc?
>>
>> Apart from that (i have the same issue) do you get the full 720
>> horizontal pixels?
>>
>> Because this is what i get:
>>
>> http://imageshack.us/f/215/newkernel0.png/
>>
>> It's not simply "stretched", the right part is missing. Did you change
>> some ccdc parameters in the files i sent you?
>
> This is precisely what I see. If you look at the raw UYVY data as
> I did, you'll see that 1/2 of the data is being lost. It looks like
> there is some setup wrong in how the data is being moved from the CCDC
> to memory but I don't know enough about the code to know where that
> might be configured.
>

Note: I just saw a set of patches for exactly this CCDC with BT656
support on the Linux-OMAP mailing list.  I'll look at them to see
if they are anything different from what Laurent provided.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

      reply	other threads:[~2011-09-08 13:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-07 15:55 OMAP3 ISP and UYVY422 Gary Thomas
2011-09-08 13:22 ` Enrico
2011-09-08 13:40   ` Gary Thomas
2011-09-08 13:43     ` Gary Thomas [this message]

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=4E68C665.8010508@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=ebutera@users.berlios.de \
    --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.