From: Archit Taneja <architt@codeaurora.org>
To: Rob Herring <robh@kernel.org>
Cc: robdclark@gmail.com, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>
Subject: Re: [PATCH 6/6] drm/msm/dsi: Parse DSI lanes via DT
Date: Mon, 22 Feb 2016 12:49:20 +0530 [thread overview]
Message-ID: <56CAB678.3080505@codeaurora.org> (raw)
In-Reply-To: <20160222025345.GB15973@rob-hp-laptop>
On 02/22/2016 08:23 AM, Rob Herring wrote:
> On Mon, Feb 15, 2016 at 06:30:59PM +0530, Archit Taneja wrote:
>> The DSI driver is currently unaware of how the DSI clock and data pins
>> are mapped to the logical lanes provided by the DSI controller.
>>
>> Use the generic 'lanes' DT binding provided for DSI lanes (used for DSI
>> in bindings/display/ti/ti,omap4-dss.txt) to get the desired mapping.
>>
>> The MSM DSI controller is restricted in terms of what all mappings
>> it can support. The lane polarity is fixed for all the lanes, the clock
>> lanes are fixed, and the data lanes can be swapped among each other only
>> for a few combinations. Apply these restrictions when we parse the DT
>> data.
>>
>> Cc: devicetree@vger.kernel.org
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>
>> Signed-off-by: Archit Taneja <architt@codeaurora.org>
>> ---
>> .../devicetree/bindings/display/msm/dsi.txt | 26 +++-
>> drivers/gpu/drm/msm/dsi/dsi_host.c | 146 ++++++++++++++++++---
>> 2 files changed, 149 insertions(+), 23 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
>> index e7423be..f0d8b6f 100644
>> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
>> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
>> @@ -44,9 +44,28 @@ Optional properties:
>> - pinctrl-names: the pin control state names; should contain "default"
>> - pinctrl-0: the default pinctrl state (active)
>> - pinctrl-n: the "sleep" pinctrl state
>> -- port: DSI controller output port. This contains one endpoint subnode, with its
>> - remote-endpoint set to the phandle of the connected panel's endpoint.
>> - See Documentation/devicetree/bindings/graph.txt for device graph info.
>> +- port: DSI controller output port, containing one endpoint subnode.
>> +
>> + DSI Endpoint properties:
>> + - remote-endpoint: set to phandle of the connected panel's endpoint.
>> + See Documentation/devicetree/bindings/graph.txt for device graph info.
>> + - lanes: list of pin numbers for the DSI lanes: CLKp, CLKn, DATA0p, DATA0n,
>> + DATA1p, DATA1n, ...
>> + This provides a physical to logical mapping of the DSI lanes. The CLKp and
>> + CLKn pins have to be mapped to pins 0 and 1. For data lanes, there are only
>
> Then why describe the clk pins?
I was trying to use a DT binding that is already used for DSI hosts in
TI SoCs.
SoCs give different flexibility over how we map the physical lines with
the actual data/clock lanes in the DSI controller. From what I know,
this flexibility varies. For example, TI SoCs lets us move clock lanes
too, and swap polarities.
If we want all DSI host controllers to use a common binding to describe
lanes, we'd need to go with the most flexible one, and the driver
restricts it to the subsets that we support.
>
>> + a limited number of physical to logical mappings possible:
>> +
>> + "0123": Logic 0->Phys 0; Logic 1->Phys 1; Logic 2->Phys 2; Logic 3->Phys 3;
>> + "3012": Logic 3->Phys 0; Logic 0->Phys 1; Logic 1->Phys 2; Logic 2->Phys 3;
>> + "2301": Logic 2->Phys 0; Logic 3->Phys 1; Logic 0->Phys 2; Logic 1->Phys 3;
>> + "1230": Logic 1->Phys 0; Logic 2->Phys 1; Logic 3->Phys 2; Logic 0->Phys 3;
>> + "0321": Logic 0->Phys 0; Logic 3->Phys 1; Logic 2->Phys 2; Logic 1->Phys 3;
>> + "1032": Logic 1->Phys 0; Logic 0->Phys 1; Logic 3->Phys 2; Logic 2->Phys 3;
>> + "2103": Logic 2->Phys 0; Logic 1->Phys 1; Logic 0->Phys 2; Logic 3->Phys 3;
>> + "3210": Logic 3->Phys 0; Logic 2->Phys 1; Logic 1->Phys 2; Logic 0->Phys 3;
>> +
>> + Here, a "3012" mapping will be represented by:
>> + lanes = <0 1 8 9 2 3 4 5 6 7>;
>
> I'm lost here. What does 8 mean for example. The index represents?
The numbers here describe the logical lanes. I.e, the way in which the
DSI controller pushes out data to the PHY. The ordering is as follows:
0 - CLKp
1 - CLKn
2 - DATA0p
3 - DATA0n
4 - DATA1p
5 - DATA1n
6 - DATA2p
7 - DATA2n
8 - DATA3p
9 - DATA3n
The indices corresponding to these values represent the actual
physical pins. The index 0 will always represent the pin CLKp,
index 8 will always represent the physical pin DATA3p. This is
something we would want to keep fixed across all SoCs.
The configuration in the example would provide the following
mapping:
L: CLKp CLKn DATA3p DATA3n ATA0p DATA0n DATA1p DATA1n DATA2p DATA2n
P: CLKp CLKn DATA0p DATA0n DATA1p DATA1n DATA2p DATA2n DATA3p DATA3n
L represents the logical lanes, and P represents the physical lanes.
L is what we provide in the DT property, and P are what the indices
represent. Here, the 3rd logical lane is mapped on to the 0th
physical data lane. The 0th logical lane to the 1st physical data
lane and so on.
Archit
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2016-02-22 7:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1455541259-8967-1-git-send-email-architt@codeaurora.org>
[not found] ` <1455541259-8967-1-git-send-email-architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-02-15 13:00 ` [PATCH 6/6] drm/msm/dsi: Parse DSI lanes via DT Archit Taneja
2016-02-22 2:53 ` Rob Herring
2016-02-22 7:19 ` Archit Taneja [this message]
2016-02-22 20:10 ` Rob Herring
2016-02-23 9:18 ` Tomi Valkeinen
2016-02-23 10:43 ` Archit Taneja
2016-02-23 11:11 ` Tomi Valkeinen
2016-02-23 20:04 ` Rob Herring
2016-02-24 5:02 ` Archit Taneja
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=56CAB678.3080505@codeaurora.org \
--to=architt@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=robh@kernel.org \
--cc=tomi.valkeinen@ti.com \
/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;
as well as URLs for NNTP newsgroup(s).