public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"laurent.pinchart@ideasonboard.com"
	<laurent.pinchart@ideasonboard.com>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	Pawel Moll <Pawel.Moll@arm.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>
Subject: Re: [PATCH v7] s5k5baf: add camera sensor driver
Date: Mon, 02 Sep 2013 18:21:58 +0200	[thread overview]
Message-ID: <5224BB26.9090902@samsung.com> (raw)
In-Reply-To: <20130827091448.GA19893@e106331-lin.cambridge.arm.com>

Hi Mark,

On 08/27/2013 11:14 AM, Mark Rutland wrote:
>> +endpoint node
>> +-------------
>> +
>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
>> +  video-interfaces.txt. This property can be only used to specify number
>> +  of data lanes, i.e. the array's content is unused, only its length is
>> +  meaningful. When this property is not specified default value of 1 lane
>> +  will be used.
> 
> Apologies for having not replied to the last posting, but having looked
> at the documentation I was provided last time [1], I don't think the
> values in the data-lanes property should be described as unused. That
> may be the way the Linux driver functions at present, but it's not how
> the generic video-interfaces binding documentation describes the
> property.
> 
> If the CSI transmitter hardware doesn't support logical remapping of
> lanes, then the only valid values for data-lanes would be a contiguous
> list of lane IDs starting at 1, ending at 4 at most. Valid values for
> the property would be one of:
> 
> data-lanes = <1>;
> data-lanes = <1>, <2>;
> data-lanes = <1>, <2>, <3>;
> data-lanes = <1>, <2>, <3>, <4>;
> 
> We can mention the fact the hardware doesn't support remapping of lanes,
> and therefore the list must start with lane 1 and end with (at most)
> lane 4. That way a dts will match the generic binding and actually
> describe the hardware, and it's possible for Linux (or any other OS) to
> factor out the parsing of data-lanes later as desired.
> 
> I don't think we should offer freedom to encode garbage in the dt when
> we can just as easily encourage more standard use of bindings that will
> make our lives easier in the long-term.

I entirely agree, that's a very accurate analysis.

Presumably the data-lanes property's descriptions could be improved so
it is said explicitly that array elements 0...N - 1, where N = 4, 
correspond to logical data lanes 1...N.

Then considering the values in the data-lanes property, I didn't make
the description terribly specific about the fact that pool of indexes
0...4 is used for the clock lane and 4 data lanes. The values could well
be H/W specific, but it seems more sensible to enforce common range.
It may not match exactly with documentation of various hardware. E.g.
OMAP, see page 1661, register CSI2_COMPLEXIO_CFG [1], uses indexes 
1..5 to indicate position of a data lane and 0 is used to mark a lane 
as unused.

I think we should have similarly defined value 0 to indicate an unused 
lane. None of drivers in mainline uses this line remapping feature, so 
changing meaning of the array values wouldn't presumably have any bad 
side effects. I'm not sure if it's OK to make a change like this now. 
IIUC the MIPI CSI-2 standard requires consecutive data lane indexes, 
so valid set of data lanes could be only: <1>, <1, 2>, <1, 2, 3>, 
<1, 2, 3, 4>. So there seems to be no issue for MIPI CSI-2. But for 
future protocols the current convention might not have been flexible 
enough.

> [1] http://www.mipi.org/specifications/camera-interface#CSI2

[2] http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=swpu231ao&fileType=pdf

--
Regards,
Sylwester

  reply	other threads:[~2013-09-02 16:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-21 14:41 [PATCH v7] s5k5baf: add camera sensor driver Andrzej Hajda
2013-08-22 20:01 ` Stephen Warren
2013-08-22 22:39 ` Tomasz Figa
2013-08-23  9:23   ` Sylwester Nawrocki
2013-08-23  9:48     ` Sylwester Nawrocki
2013-08-23  9:48 ` Pawel Moll
2013-08-23 12:53 ` Laurent Pinchart
2013-08-26 12:34   ` Andrzej Hajda
2013-08-27 11:52     ` Laurent Pinchart
2013-08-27  9:14 ` Mark Rutland
2013-09-02 16:21   ` Sylwester Nawrocki [this message]
2013-09-02 16:55     ` Mark Rutland

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=5224BB26.9090902@samsung.com \
    --to=s.nawrocki@samsung.com \
    --cc=Pawel.Moll@arm.com \
    --cc=a.hajda@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@wwwdotorg.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