| Message ID | 1455541259-8967-7-git-send-email-architt@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? > + 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? Rob
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
On Mon, Feb 22, 2016 at 1:19 AM, Archit Taneja <architt@codeaurora.org> wrote: > > > 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. Okay, so the confusing part is the description is all about lanes (0-3) but the binding (index and value) is all about pin/signal numbers. Either simplify the binding to be lanes or describe the binding in terms of pins. Rob
On 22/02/16 22:10, Rob Herring wrote: >> 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. True, but I wonder if that's necessary. The lane property for the SoC should be read by the SoC specific driver, right? So the DT property can be anything. I'm not sure if there's ever a reason for a generic code to observe the DSI lane setup. That said, if we do have a common binding, it's perhaps easier for people to understand the setups for different SoCs. >>>> + 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: If I read you right, I think that's vice versa. At least the OMAP version. The OMAP doc says: "- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, DATA1+, DATA1-, ..." This means that the first value in the array is the pin number for CLK+. In other words, CLK+ wire going to the panel/encoder is connected to pin number X. What the pin number means is SoC specific. CLK+ could be connected to, say, SoC pin number 123, and then you'd enter 123 as the first value. On OMAP we use DSI block specific pin numbers, so they start at 0. > Okay, so the confusing part is the description is all about lanes > (0-3) but the binding (index and value) is all about pin/signal > numbers. Either simplify the binding to be lanes or describe the > binding in terms of pins. Perhaps "lane-pins" or something would be more descriptive. If we want to make the description common, I could change the OMAP implementation to accept the new property name too. But, I'm not sure if a common description helps much. Any thoughts? Tomi
On 02/23/2016 02:48 PM, Tomi Valkeinen wrote: > > On 22/02/16 22:10, Rob Herring wrote: > >>> 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. > > True, but I wonder if that's necessary. The lane property for the SoC > should be read by the SoC specific driver, right? So the DT property can > be anything. I'm not sure if there's ever a reason for a generic code to > observe the DSI lane setup. Yeah, it is very SoC specific. The only place where it might matter is if a panel/bridge ever needs to know what pins implement what lanes on the platform. A common binding there might help us keep the panel driver generic. Although, this need itself is a bit hypothetical. > > That said, if we do have a common binding, it's perhaps easier for > people to understand the setups for different SoCs. > >>>>> + 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: > > If I read you right, I think that's vice versa. At least the OMAP > version. The OMAP doc says: > > "- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, > DATA0-, DATA1+, DATA1-, ..." > > This means that the first value in the array is the pin number for CLK+. > In other words, CLK+ wire going to the panel/encoder is connected to pin > number X. > > What the pin number means is SoC specific. CLK+ could be connected to, > say, SoC pin number 123, and then you'd enter 123 as the first value. On > OMAP we use DSI block specific pin numbers, so they start at 0. You're right. I have it the other way round. Yours describes the hardware better. I'll change to yours if we decide to have a common binding. > >> Okay, so the confusing part is the description is all about lanes >> (0-3) but the binding (index and value) is all about pin/signal >> numbers. Either simplify the binding to be lanes or describe the >> binding in terms of pins. > > Perhaps "lane-pins" or something would be more descriptive. If we want > to make the description common, I could change the OMAP implementation > to accept the new property name too. > > But, I'm not sure if a common description helps much. Any thoughts? If having a common binding doesn't bring any benefit, then a common description doesn't help much. I could then move to a simpler binding too. Archit
On 23/02/16 12:43, Archit Taneja wrote: > > > On 02/23/2016 02:48 PM, Tomi Valkeinen wrote: >> >> On 22/02/16 22:10, Rob Herring wrote: >> >>>> 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. >> >> True, but I wonder if that's necessary. The lane property for the SoC >> should be read by the SoC specific driver, right? So the DT property can >> be anything. I'm not sure if there's ever a reason for a generic code to >> observe the DSI lane setup. > > Yeah, it is very SoC specific. > > The only place where it might matter is if a panel/bridge ever needs to > know what pins implement what lanes on the platform. A common binding > there might help us keep the panel driver generic. Although, this need > itself is a bit hypothetical. My opinion here is that if the panel/bridge needs to know something about the DSI lanes/pins, we should have that data in the panel's/bridge's endpoint data. So if both SoC and the DSI peripheral need complex DSI pin/lane setup, you might have very similar data on both sides. There's possibly some duplication there, but I think it keeps things much simpler. For example, if the SoC needs OMAP style DSI pin data, and the DSI peripheral needs to know the amount of DSI lanes used (but nothing else), you might think it's nice if the DSI peripheral would peek at the SoC side data, finding out about the DSI lanes. But I think in that case you should just add a "num-lanes" property to the DSI peripheral. The DT data for a device should be private to the driver handling the device, except for some special cases like following the graph. Tomi
On Tue, Feb 23, 2016 at 01:11:24PM +0200, Tomi Valkeinen wrote: > > > On 23/02/16 12:43, Archit Taneja wrote: > > > > > > On 02/23/2016 02:48 PM, Tomi Valkeinen wrote: > >> > >> On 22/02/16 22:10, Rob Herring wrote: > >> > >>>> 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. > >> > >> True, but I wonder if that's necessary. The lane property for the SoC > >> should be read by the SoC specific driver, right? So the DT property can > >> be anything. I'm not sure if there's ever a reason for a generic code to > >> observe the DSI lane setup. > > > > Yeah, it is very SoC specific. Agreed. > > The only place where it might matter is if a panel/bridge ever needs to > > know what pins implement what lanes on the platform. A common binding > > there might help us keep the panel driver generic. Although, this need > > itself is a bit hypothetical. > > My opinion here is that if the panel/bridge needs to know something > about the DSI lanes/pins, we should have that data in the > panel's/bridge's endpoint data. > > So if both SoC and the DSI peripheral need complex DSI pin/lane setup, > you might have very similar data on both sides. There's possibly some > duplication there, but I think it keeps things much simpler. > > For example, if the SoC needs OMAP style DSI pin data, and the DSI > peripheral needs to know the amount of DSI lanes used (but nothing > else), you might think it's nice if the DSI peripheral would peek at the > SoC side data, finding out about the DSI lanes. > > But I think in that case you should just add a "num-lanes" property to > the DSI peripheral. The DT data for a device should be private to the > driver handling the device, except for some special cases like following > the graph. num-lanes might not be enough. You could need to have a mask instead. Not sure if there is really any h/w like that though. Also, I think it is fine for a parent to look at standard properties in a child. Rob
On 02/24/2016 01:34 AM, Rob Herring wrote: > On Tue, Feb 23, 2016 at 01:11:24PM +0200, Tomi Valkeinen wrote: >> >> >> On 23/02/16 12:43, Archit Taneja wrote: >>> >>> >>> On 02/23/2016 02:48 PM, Tomi Valkeinen wrote: >>>> >>>> On 22/02/16 22:10, Rob Herring wrote: >>>> >>>>>> 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. >>>> >>>> True, but I wonder if that's necessary. The lane property for the SoC >>>> should be read by the SoC specific driver, right? So the DT property can >>>> be anything. I'm not sure if there's ever a reason for a generic code to >>>> observe the DSI lane setup. >>> >>> Yeah, it is very SoC specific. > > Agreed. Okay. We probably don't need to go with a generic binding, then. I'll simplify the msm/dsi lane bindings (i.e, drop the clock lanes, and represent things in lanes instead of pins). Thanks, Archit
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 + 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>; DSI PHY: Required properties: @@ -131,6 +150,7 @@ Example: port { dsi0_out: endpoint { remote-endpoint = <&panel_in>; + lanes = <0 1 2 3 4 5 6 7 8 9>; }; }; }; diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 69bac59..5dc58bb 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -163,6 +163,10 @@ struct msm_dsi_host { enum mipi_dsi_pixel_format format; unsigned long mode_flags; + /* lane data parsed via DT */ + int dlane_swap; + int num_data_lanes; + u32 dma_cmd_ctrl_restore; bool registered; @@ -845,19 +849,10 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool enable, data = DSI_CTRL_CLK_EN; DBG("lane number=%d", msm_host->lanes); - if (msm_host->lanes == 2) { - data |= DSI_CTRL_LANE1 | DSI_CTRL_LANE2; - /* swap lanes for 2-lane panel for better performance */ - dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL, - DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(LANE_SWAP_1230)); - } else { - /* Take 4 lanes as default */ - data |= DSI_CTRL_LANE0 | DSI_CTRL_LANE1 | DSI_CTRL_LANE2 | - DSI_CTRL_LANE3; - /* Do not swap lanes for 4-lane panel */ - dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL, - DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(LANE_SWAP_0123)); - } + data |= ((DSI_CTRL_LANE0 << msm_host->lanes) - DSI_CTRL_LANE0); + + dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL, + DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(msm_host->dlane_swap)); if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) dsi_write(msm_host, REG_DSI_LANE_CTRL, @@ -1479,6 +1474,9 @@ static int dsi_host_attach(struct mipi_dsi_host *host, struct msm_dsi_host *msm_host = to_msm_dsi_host(host); int ret; + if (dsi->lanes > msm_host->num_data_lanes) + return -EINVAL; + msm_host->channel = dsi->channel; msm_host->lanes = dsi->lanes; msm_host->format = dsi->format; @@ -1532,6 +1530,105 @@ static struct mipi_dsi_host_ops dsi_host_ops = { .transfer = dsi_host_transfer, }; +/* + * List of supported physical to logical lane mappings. + * For example, the 2nd entry represents the following mapping: + * + * "3012": Logic 3->Phys 0; Logic 0->Phys 1; Logic 1->Phys 2; Logic 2->Phys 3; + */ +static const int supported_data_lane_swaps[][4] = { + { 0, 1, 2, 3 }, + { 3, 0, 1, 2 }, + { 2, 3, 0, 1 }, + { 1, 2, 3, 0 }, + { 0, 3, 2, 1 }, + { 1, 0, 3, 2 }, + { 2, 1, 0, 3 }, + { 3, 2, 1, 0 }, +}; + +static int dsi_host_parse_lane_data(struct msm_dsi_host *msm_host, + struct device_node *ep) +{ + struct device *dev = &msm_host->pdev->dev; + struct property *prop; + u32 pins[10]; + int logic_pos[4]; + int ret, i, len, num_pins, num_data; + + prop = of_find_property(ep, "lanes", &len); + if (!prop) { + dev_dbg(dev, "failed to find lane data, setting defaults\n"); + msm_host->num_data_lanes = 4; + msm_host->dlane_swap = 0; + return -EINVAL; + } + + num_pins = len / sizeof(u32); + + if (num_pins < 4 || num_pins > 10 || num_pins % 2 != 0) { + dev_err(dev, "bad number of lanes\n"); + return -EINVAL; + } + + ret = of_property_read_u32_array(ep, "lanes", pins, num_pins); + if (ret) { + dev_err(dev, "failed to read lane data\n"); + return ret; + } + + /* parse CLK pins */ + if (pins[0] != 0 || pins[1] != 1) { + dev_err(dev, "clkp and clkn have to be at positions 0 and 1\n"); + return -EINVAL; + } + + /* parse DATA pins */ + num_data = 0; + + for (i = 2; i < num_pins; i += 2) { + int dp, dn; + + dp = pins[i]; + dn = pins[i + 1]; + + if ((dp < 0 || dp > 9) || (dn < 0 || dn > 9)) + return -EINVAL; + + if (dn & 1) { + if (dn != dp + 1) + return -EINVAL; + } else { + return -EINVAL; + } + + logic_pos[num_data++] = dp / 2 - 1; + } + + msm_host->num_data_lanes = num_data; + + /* + * compare DT specified physical-logical lane mappings with the ones + * supported by hardware + */ + for (i = 0; i < ARRAY_SIZE(supported_data_lane_swaps); i++) { + const int *swap = supported_data_lane_swaps[i]; + int j; + + for (j = 0; j < num_data; j++) { + if (swap[j] != logic_pos[j]) + break; + } + + if (j == num_data) { + msm_host->dlane_swap = i; + return 0; + } + } + + return -EINVAL; +} + static int dsi_host_parse_dt(struct msm_dsi_host *msm_host) { struct device *dev = &msm_host->pdev->dev; @@ -1558,17 +1655,21 @@ static int dsi_host_parse_dt(struct msm_dsi_host *msm_host) return 0; } + ret = dsi_host_parse_lane_data(msm_host, endpoint); + if (ret) { + dev_err(dev, "%s: invalid lane configuration %d\n", + __func__, ret); + goto err; + } + /* Get panel node from the output port's endpoint data */ device_node = of_graph_get_remote_port_parent(endpoint); if (!device_node) { dev_err(dev, "%s: no valid device\n", __func__); - of_node_put(endpoint); - return -ENODEV; + ret = -ENODEV; + goto err; } - of_node_put(endpoint); - of_node_put(device_node); - msm_host->device_node = device_node; if (of_property_read_bool(np, "syscon-sfpb")) { @@ -1577,11 +1678,16 @@ static int dsi_host_parse_dt(struct msm_dsi_host *msm_host) if (IS_ERR(msm_host->sfpb)) { dev_err(dev, "%s: failed to get sfpb regmap\n", __func__); - return PTR_ERR(msm_host->sfpb); + ret = PTR_ERR(msm_host->sfpb); } } - return 0; + of_node_put(device_node); + +err: + of_node_put(endpoint); + + return ret; } int msm_dsi_host_init(struct msm_dsi *msm_dsi)
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(-)