From: Michael Jones <michael.jones@matrix-vision.de>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: [RFC] ISP lane shifter support
Date: Wed, 02 Feb 2011 11:36:04 +0100 [thread overview]
Message-ID: <4D493394.4010302@matrix-vision.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1101262218090.6179@axis700.grange>
Hi Guennadi, Laurent,
On 01/27/2011 12:46 AM, Guennadi Liakhovetski wrote:
<snip>
>>
>>> I didn't realize the video port can further shift the data. Where can I
>>> find this in the TRM?
>>
>> VPIN field of the CCDC_FMTCFG register.
>
> This only plays a role, if cam_d is set to 10 bits raw in
> CCDC_SYN_MODE.DATSIZ, right?
>
I didn't understand from the TRM that this is the case. I also didn't
see that VPIN is only relevant with parallel data. Is it so?
<snip>
>> It could be, yes. The other option is to modify the format at the CCDC input.
>> I agree that both options have drawbacks.
>>
>> Hans, Guennadi, any opinion on this ?
>
> Looking at the "Data-Lane Shifter" table (12.27 in my datasheet, in the
> "Bridge-Lane Shifter" chapter), I think, the first two columns are fixed
> by the board design, right? So, our freedom lies only in one line there
> and is a single parameter - the shift value. The output shifter (VPIN) is
> independent from this one, but not unrelated. It seems logical to me to
> relate the former one to CCDC's input pad, and the latter one to CCDC's
> output pad. AFAIU, Laurent, your implementation in what concerns pad
> configuration is: let the user configure all interfaces independently, and
> first when we have to actually activate the pipeline (start streaming or
> configure video buffers) we can verify, whether all parts fit together.
> So, why don't we stay consistent and do the same here? Give the user both
> parameters and see how clever they were in the end;) I also think, if we
> later decide to add some consistency checks, we can always do it.
>
Are you proposing having different formats on each end of the link
between the sensor and the CCDC? Or do you agree with my favored
approach that the lane shift value be determined by the difference
between the CCDC input format and the CCDC output format(s)?
I assume the VPIN value will always just select the upper 10 bits of the
format which the CCDC is outputting on its other output pad.
I understand that Laurent is out until Monday, so I'll wait for him to
weigh in on this again before moving forward.
> Thanks
> Guennadi
>
thanks,
Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
next prev parent reply other threads:[~2011-02-02 10:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-21 8:40 [RFC] ISP lane shifter support Michael Jones
2011-01-24 0:10 ` Laurent Pinchart
2011-01-24 13:47 ` Michael Jones
2011-01-24 13:57 ` Laurent Pinchart
2011-01-24 14:16 ` Michael Jones
2011-01-24 19:45 ` Laurent Pinchart
2011-01-25 9:10 ` Michael Jones
2011-01-25 9:20 ` Laurent Pinchart
2011-01-26 23:46 ` Guennadi Liakhovetski
2011-02-02 10:36 ` Michael Jones [this message]
2011-02-11 12:07 ` Michael Jones
2011-02-11 13:06 ` Laurent Pinchart
2011-02-22 12:36 ` Michael Jones
2011-02-24 11:57 ` Hans Verkuil
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=4D493394.4010302@matrix-vision.de \
--to=michael.jones@matrix-vision.de \
--cc=g.liakhovetski@gmx.de \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.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