From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Michael Jones <michael.jones@matrix-vision.de>,
linux-media@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: [PATCH v3 4/4] omap3isp: lane shifter support
Date: Wed, 16 Mar 2011 19:08:04 +0200 [thread overview]
Message-ID: <4D80EE74.3040703@maxwell.research.nokia.com> (raw)
In-Reply-To: <201103161727.43838.laurent.pinchart@ideasonboard.com>
Laurent Pinchart wrote:
> Hi Sakari,
Hi Laurent and Michael!
...
>>> + return in_info->bpp - out_info->bpp + additional_shift <= 6;
>>
>> Currently there are no formats that would behave badly in this check?
>> Perhaps it'd be good idea to take that into consideration. The shift
>> that can be done is even.
>
> I've asked Michael to remove the check because we have no misbehaving formats
> :-) Do you think we need to add a check back ?
I think it would be helpful in debugging if someone decides to attach a
sensor which supports a shift of non-even bits (8 and 9 bits, for
example). In any case an invalid configuration is possible in such case,
and I don't think that should be allowed, should it?
>>> @@ -247,6 +296,7 @@ static int isp_video_validate_pipeline(struct
>>> isp_pipeline *pipe)
>>>
>>> return -EPIPE;
>>>
>>> while (1) {
>>>
>>> + unsigned int link_has_shifter;
>>
>> link_has_shifter is only used in one place. Would it be cleaner to test
>> below if it's the CCDC? A comment there could be nice, too.
>
> I would like that better as well, but between the line where link_has_shifter
> is set and the line where it is checked, the subdev variable changes so we
> can't just check subdev == &isp->isp_ccdc.subdev there.
That's definitely valid. I take my comment back. The variable could be
called is_ccdc, though, since only the CCDC has that feature. No need to
generalise. :-)
Cheers,
--
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com
next prev parent reply other threads:[~2011-03-16 17:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 8:05 [PATCH v3 0/4] OMAP3-ISP lane shifter support Michael Jones
2011-03-11 8:05 ` [PATCH v3 1/4] v4l: add V4L2_PIX_FMT_Y12 format Michael Jones
2011-03-11 8:56 ` Laurent Pinchart
2011-03-11 9:21 ` Antonio Ospite
2011-03-11 9:38 ` Michael Jones
2011-03-11 11:15 ` Antonio Ospite
2011-03-11 8:05 ` [PATCH v3 2/4] media: add 8-bit bayer formats and Y12 Michael Jones
2011-03-11 8:05 ` [PATCH v3 3/4] omap3isp: ccdc: support Y10/12, 8-bit bayer fmts Michael Jones
2011-03-11 8:05 ` [PATCH v3 4/4] omap3isp: lane shifter support Michael Jones
2011-03-16 15:44 ` Sakari Ailus
2011-03-16 16:27 ` Laurent Pinchart
2011-03-16 17:08 ` Sakari Ailus [this message]
2011-03-16 17:46 ` Laurent Pinchart
2011-03-17 10:07 ` Michael Jones
2011-03-17 11:04 ` Laurent Pinchart
2011-03-17 15:40 ` Sakari Ailus
2011-03-17 15:51 ` Michael Jones
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=4D80EE74.3040703@maxwell.research.nokia.com \
--to=sakari.ailus@maxwell.research.nokia.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=michael.jones@matrix-vision.de \
/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.