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 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
