| Message ID | 1392204688-4591-20-git-send-email-a.hajda@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 12/02/14 13:31, Andrzej Hajda wrote: > The patch adds bridge and panel nodes. > It adds also DSI properties specific for arndale board. > > Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> > --- > arch/arm/boot/dts/exynos5250-arndale.dts | 39 ++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) > > diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts > index a0a985d..7d666b1 100644 > --- a/arch/arm/boot/dts/exynos5250-arndale.dts > +++ b/arch/arm/boot/dts/exynos5250-arndale.dts > @@ -584,6 +584,45 @@ > }; > }; > > + panel: panel { > + compatible = "boe,hv070wsa-100"; > + power-supply = <&vcc_3v3_reg>; > + enable-gpios = <&gpd1 3 0>; > + port { > + panel_ep: endpoint { > + remote-endpoint = <&bridge_out_ep>; > + }; > + }; > + }; > + > + dsi_0: dsi@14500000 { > + vddcore-supply = <&ldo8_reg>; > + vddio-supply = <&ldo10_reg>; > + samsung,pll-clock-frequency = <24000000>; > + samsung,burst-clock-frequency = <320000000>; > + samsung,esc-clock-frequency = <10000000>; > + status = "okay"; > + > + bridge@0 { > + reg = <0>; > + compatible = "toshiba,tc358764"; > + vddc-supply = <&vcc_1v2_reg>; > + vddio-supply = <&vcc_1v8_reg>; > + vddmipi-supply = <&vcc_1v2_reg>; > + vddlvds133-supply = <&vcc_3v3_reg>; > + vddlvds112-supply = <&vcc_1v2_reg>; > + reset-gpio = <&gpd1 6 1>; > + #address-cells = <1>; > + #size-cells = <0>; > + port@1 { > + reg = <1>; > + bridge_out_ep: endpoint { > + remote-endpoint = <&panel_ep>; > + }; > + }; > + }; > + }; Compared to what I've done on OMAP, you don't seem to specify the video inputs for the tc358764 at all. In this case it's obvious, as the chip is a child of the DSI master. But the chip could as well be controlled via i2c, and so be placed as a child of the i2c nodes. So even if the driver doesn't use it, maybe it would be more future proof to have both input and output endpoints for the tc358764? Tomi
On 28/02/14 15:31, Tomi Valkeinen wrote: > Compared to what I've done on OMAP, you don't seem to specify the video > inputs for the tc358764 at all. In this case it's obvious, as the chip > is a child of the DSI master. But the chip could as well be controlled > via i2c, and so be placed as a child of the i2c nodes. > > So even if the driver doesn't use it, maybe it would be more future > proof to have both input and output endpoints for the tc358764? Oh, and one addition: how me and Laurent see the DSI case (and other similar ones), the child/parent relationship gives the control bus path, and the video ports give the video data path. So both are always needed. A DSI panel may be controlled via DSI, i2c, spi, but the video path will always go from DSI master to the panel. Or, as a theoretical panel, you could have a DSI controlled panel, being a child of the DSI master, but the video data would come via, say, parallel RGB. You can actually do that with some panels/encoders, even if the concept is silly. Tomi
On 02/28/2014 02:39 PM, Tomi Valkeinen wrote: > On 28/02/14 15:31, Tomi Valkeinen wrote: > >> Compared to what I've done on OMAP, you don't seem to specify the video >> inputs for the tc358764 at all. In this case it's obvious, as the chip >> is a child of the DSI master. But the chip could as well be controlled >> via i2c, and so be placed as a child of the i2c nodes. >> >> So even if the driver doesn't use it, maybe it would be more future >> proof to have both input and output endpoints for the tc358764? > Oh, and one addition: how me and Laurent see the DSI case (and other > similar ones), the child/parent relationship gives the control bus path, > and the video ports give the video data path. > > So both are always needed. A DSI panel may be controlled via DSI, i2c, > spi, but the video path will always go from DSI master to the panel. I have made video path binding optional, in case of video bus if the specific video path is not present driver uses the bus it is connected to. In case DSI panel is controlled via different bus the path should be specified explicitly. I have no strong feelings against making this binding required but as you have stated above "in this case it's obvious" and for me quite redundant. What is the gain in specifying explicitly video paths in such cases? > Or, as a theoretical panel, you could have a DSI controlled panel, being > a child of the DSI master, but the video data would come via, say, > parallel RGB. You can actually do that with some panels/encoders, even > if the concept is silly. In this case explicit binding will work also. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/03/14 14:00, Andrzej Hajda wrote: > I have made video path binding optional, in case of video bus > if the specific video path is not present driver uses the bus it is > connected to. > In case DSI panel is controlled via different bus the path should be > specified > explicitly. > > I have no strong feelings against making this binding required but as > you have > stated above "in this case it's obvious" and for me quite redundant. Yes, it's a good point. I didn't realize they were optional, I thought they were not defined at all. I hadn't even thought that they could be optional, I guess because in my uses there's always a reason to have them. Even for a simple DSI command mode panel, I have information in the DSI master's endpoint: dsi { ... dsi1_out_ep: endpoint { remote-endpoint = <&lcd0_in>; lanes = <0 1 2 3 4 5>; }; }; which forces to use an endpoint in the panel also. And, actually, I think in your case also you would need an endpoint for the dsi master, if you wanted to support multiple endpoints. You currently have, for example, PLL clock freq as the DSI master's property, but it should really be a property of the DSI master's endpoint. I.e. if you have two DSI panels connected to the same DSI master, in a way that only one can be enabled at a time (there would probably be a mux to select where the DSI lanes go, we have that on some development boards), you could well need different clock frequencies for the panels. > What is the gain in specifying explicitly video paths in such cases? - Until we (everyone interested in this) have thought about it fully and agreed that video paths in cases like this are optional, you would be safer to specify them explicitly. That way your bindings are valid in either case. - Uniformity. If in most cases we need to specify the video paths, either because the control path is different than the data path, or because there is need for endpoint specific information, having video paths as optional for some specific cases may needlessly complicate the code. Tomi
Sorry for interrupting, 2014-03-04 21:00 GMT+09:00 Andrzej Hajda <a.hajda@samsung.com>: > On 02/28/2014 02:39 PM, Tomi Valkeinen wrote: >> On 28/02/14 15:31, Tomi Valkeinen wrote: >> >>> Compared to what I've done on OMAP, you don't seem to specify the video >>> inputs for the tc358764 at all. In this case it's obvious, as the chip >>> is a child of the DSI master. But the chip could as well be controlled >>> via i2c, and so be placed as a child of the i2c nodes. >>> >>> So even if the driver doesn't use it, maybe it would be more future >>> proof to have both input and output endpoints for the tc358764? >> Oh, and one addition: how me and Laurent see the DSI case (and other >> similar ones), the child/parent relationship gives the control bus path, >> and the video ports give the video data path. >> >> So both are always needed. A DSI panel may be controlled via DSI, i2c, >> spi, but the video path will always go from DSI master to the panel. > I have made video path binding optional, in case of video bus > if the specific video path is not present driver uses the bus it is > connected to. You mean the case that video path isn't wrote in dt file for some machine? If so, shouldn't we always write video patch in the dt file correctly? I'm not sure the optional binding is needed because which bus and which panel are used depends on machine. And If I understood correctly the video interfaces document, it seems that you don't deal with the document. The below is simple dt binding I think in case that video path goes from MIPI-DSI to LVDS bridge, and then from LVDS bridge to LCD Panel, panel { ... port { ... panel_0: endpoint { remote-endpoint=<&lvds_1>; }; }; }; lvds { ... port@1 { ... lvds_0: endpoint { remote-endpoint=<&dsi_0>; }; }; port@2 { ... lvds_1: endpoint { remote-endpoint=<&panel_0>; }; }; }; dsi { ... port { dsi_0: endpoint { remote-endpoint=<&lvds_0>; }; }; }; panel and lvds node could be a child of other masters, maybe i2c or spi. Thanks, Inki Dae > In case DSI panel is controlled via different bus the path should be > specified > explicitly. > > I have no strong feelings against making this binding required but as > you have > stated above "in this case it's obvious" and for me quite redundant. > > What is the gain in specifying explicitly video paths in such cases? > > >> Or, as a theoretical panel, you could have a DSI controlled panel, being >> a child of the DSI master, but the video data would come via, say, >> parallel RGB. You can actually do that with some panels/encoders, even >> if the concept is silly. > > In this case explicit binding will work also. > > Regards > Andrzej > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/05/2014 01:06 PM, Inki Dae wrote: > Sorry for interrupting, > > > 2014-03-04 21:00 GMT+09:00 Andrzej Hajda <a.hajda@samsung.com>: >> On 02/28/2014 02:39 PM, Tomi Valkeinen wrote: >>> On 28/02/14 15:31, Tomi Valkeinen wrote: >>> >>>> Compared to what I've done on OMAP, you don't seem to specify the video >>>> inputs for the tc358764 at all. In this case it's obvious, as the chip >>>> is a child of the DSI master. But the chip could as well be controlled >>>> via i2c, and so be placed as a child of the i2c nodes. >>>> >>>> So even if the driver doesn't use it, maybe it would be more future >>>> proof to have both input and output endpoints for the tc358764? >>> Oh, and one addition: how me and Laurent see the DSI case (and other >>> similar ones), the child/parent relationship gives the control bus path, >>> and the video ports give the video data path. >>> >>> So both are always needed. A DSI panel may be controlled via DSI, i2c, >>> spi, but the video path will always go from DSI master to the panel. >> I have made video path binding optional, in case of video bus >> if the specific video path is not present driver uses the bus it is >> connected to. > You mean the case that video path isn't wrote in dt file for some > machine? If so, shouldn't we always write video patch in the dt file > correctly? I'm not sure the optional binding is needed because which > bus and which panel are used depends on machine. > > And If I understood correctly the video interfaces document, it seems > that you don't deal with the document. I have followed the document, I have even specified it in bridge bindings. I have just made those bindings optional in case control bus is the same as video bus - DSI master/slave case. > > The below is simple dt binding I think in case that video path goes > from MIPI-DSI to LVDS bridge, and then from LVDS bridge to LCD Panel, > > panel { > ... > port { > ... > panel_0: endpoint { > remote-endpoint=<&lvds_1>; > }; > }; > }; > > lvds { > ... > port@1 { > ... > lvds_0: endpoint { > remote-endpoint=<&dsi_0>; > }; > }; > port@2 { > ... > lvds_1: endpoint { > remote-endpoint=<&panel_0>; > }; > }; > }; > > dsi { > ... > port { > dsi_0: endpoint { > remote-endpoint=<&lvds_0>; > }; > }; > }; > I think we should even extend the bindings to fimd: dsi { port@0 { dsi_0: endpoint { remote-endpoint=<&fimd_0>; } } port@1 { dsi_1: endpoint { remote-endpoint=<&lvds_0>; } } } fimd { port@0 { fimd_0: endpoint { remote-endpoint=<&dsi_0>; } } } > panel and lvds node could be a child of other masters, maybe i2c or spi. As I mentioned earlier, in such cases bindings should be specified explicitly. My proposition of omitting obvious bindings was made to simplify a bit dts files, but as I stated earlier it is not something I want to die for :) Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/03/14 14:22, Andrzej Hajda wrote: > I think we should even extend the bindings to fimd: > dsi { > port@0 { > dsi_0: endpoint { > remote-endpoint=<&fimd_0>; > } > } > port@1 { > dsi_1: endpoint { > remote-endpoint=<&lvds_0>; > } > } > } > > fimd { > port@0 { > fimd_0: endpoint { > remote-endpoint=<&dsi_0>; > } > } > } If both fimd and dsi are SoC components, I don't see any strict need for that. I think the ports/endpoints are only important when dealing with external components, which can be used on any platform. For SoC internal components you can have relevant data directly in the drivers, as it is fixed (for that SoC). Of course, if using ports for SoC internal components makes things easier for you, I don't see any problems with it either. For OMAP, the SoC's display blocks are all inside one bigger DSS "container", so I have not seen need to represent the connections between the internal components in the DT data. If the display components were truly independent IPs on the SoC, then using ports might make things easier. Tomi
On 03/07/2014 01:32 PM, Tomi Valkeinen wrote: > On 07/03/14 14:22, Andrzej Hajda wrote: > >> I think we should even extend the bindings to fimd: >> dsi { >> port@0 { >> dsi_0: endpoint { >> remote-endpoint=<&fimd_0>; >> } >> } >> port@1 { >> dsi_1: endpoint { >> remote-endpoint=<&lvds_0>; >> } >> } >> } >> >> fimd { >> port@0 { >> fimd_0: endpoint { >> remote-endpoint=<&dsi_0>; >> } >> } >> } > If both fimd and dsi are SoC components, I don't see any strict need for > that. I think the ports/endpoints are only important when dealing with > external components, which can be used on any platform. For SoC internal > components you can have relevant data directly in the drivers, as it is > fixed (for that SoC). > > Of course, if using ports for SoC internal components makes things > easier for you, I don't see any problems with it either. There are many possible connections from FIMD, some of them: FIMD ---> RGB panel, external FIMD ---> DSI, on SoC FIMD ---> eDP, on SoC FIMD ---> ImageEnhacer, on SoC In the first case port should be created. In other cases connection could be determined by presence/absence of specific nodes, so in fact the port can be optional, almost like in my proposal :) > > For OMAP, the SoC's display blocks are all inside one bigger DSS > "container", so I have not seen need to represent the connections > between the internal components in the DT data. How do you deal with situation when IPs in SoC can be connected in different ways ? Andrzej > If the display components were truly independent IPs on the SoC, then > using ports might make things easier. > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/03/14 15:07, Andrzej Hajda wrote: > On 03/07/2014 01:32 PM, Tomi Valkeinen wrote: >> On 07/03/14 14:22, Andrzej Hajda wrote: >> >>> I think we should even extend the bindings to fimd: >>> dsi { >>> port@0 { >>> dsi_0: endpoint { >>> remote-endpoint=<&fimd_0>; >>> } >>> } >>> port@1 { >>> dsi_1: endpoint { >>> remote-endpoint=<&lvds_0>; >>> } >>> } >>> } >>> >>> fimd { >>> port@0 { >>> fimd_0: endpoint { >>> remote-endpoint=<&dsi_0>; >>> } >>> } >>> } >> If both fimd and dsi are SoC components, I don't see any strict need for >> that. I think the ports/endpoints are only important when dealing with >> external components, which can be used on any platform. For SoC internal >> components you can have relevant data directly in the drivers, as it is >> fixed (for that SoC). >> >> Of course, if using ports for SoC internal components makes things >> easier for you, I don't see any problems with it either. > There are many possible connections from FIMD, some of them: > FIMD ---> RGB panel, external > FIMD ---> DSI, on SoC > FIMD ---> eDP, on SoC > FIMD ---> ImageEnhacer, on SoC This sounds similar to OMAP, at least roughly. > In the first case port should be created. > In other cases connection could be determined by presence/absence > of specific nodes, so in fact the port can be optional, almost like in > my proposal :) Well, I think not. In the external encoder case, the ports are there, and they are used. You just didn't specify them, and thus make the driver deduce them from the DT. In the FIMD case, if the the RGB port is needed, you need to specify it in the DT data, and it's used. If you only need, say, DSI, the RGB port is not used and thus it doesn't need to be present in the DT data. It's fine to leave the port definition out if it is not used at all. >> For OMAP, the SoC's display blocks are all inside one bigger DSS >> "container", so I have not seen need to represent the connections >> between the internal components in the DT data. > How do you deal with situation when IPs in SoC can be connected in > different ways ? Basically so that (using exynos terms) if, say DSI panel is to be enabled, the DSI panel driver will reserve the DSI master for itself, and the DSI master will reserve the FIMD for itself, presuming FIMD has not already been reserved. When the DSI panel is disabled, FIMD is freed. Tomi
On 03/07/2014 02:28 PM, Tomi Valkeinen wrote: (...) > There are many possible connections from FIMD, some of them: > FIMD ---> RGB panel, external > FIMD ---> DSI, on SoC > FIMD ---> eDP, on SoC > FIMD ---> ImageEnhacer, on SoC > This sounds similar to OMAP, at least roughly. > >> In the first case port should be created. >> In other cases connection could be determined by presence/absence >> of specific nodes, so in fact the port can be optional, almost like in >> my proposal :) > Well, I think not. > > In the external encoder case, the ports are there, and they are used. > You just didn't specify them, and thus make the driver deduce them from > the DT. > > In the FIMD case, if the the RGB port is needed, you need to specify it > in the DT data, and it's used. If you only need, say, DSI, the RGB port > is not used and thus it doesn't need to be present in the DT data. > > It's fine to leave the port definition out if it is not used at all. On Exynos, DSI is in fact RGB/DSI encoder (or I80/DSI). DSI and RGB pins are connected to the same FIMD output. So from FIMD point of view RGB port is used in both cases. > >>> For OMAP, the SoC's display blocks are all inside one bigger DSS >>> "container", so I have not seen need to represent the connections >>> between the internal components in the DT data. >> How do you deal with situation when IPs in SoC can be connected in >> different ways ? > Basically so that (using exynos terms) if, say DSI panel is to be > enabled, the DSI panel driver will reserve the DSI master for itself, > and the DSI master will reserve the FIMD for itself, presuming FIMD has > not already been reserved. When the DSI panel is disabled, FIMD is freed. > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/03/14 16:17, Andrzej Hajda wrote: > On 03/07/2014 02:28 PM, Tomi Valkeinen wrote: > (...) >> There are many possible connections from FIMD, some of them: >> FIMD ---> RGB panel, external >> FIMD ---> DSI, on SoC >> FIMD ---> eDP, on SoC >> FIMD ---> ImageEnhacer, on SoC >> This sounds similar to OMAP, at least roughly. >> >>> In the first case port should be created. >>> In other cases connection could be determined by presence/absence >>> of specific nodes, so in fact the port can be optional, almost like in >>> my proposal :) >> Well, I think not. >> >> In the external encoder case, the ports are there, and they are used. >> You just didn't specify them, and thus make the driver deduce them from >> the DT. >> >> In the FIMD case, if the the RGB port is needed, you need to specify it >> in the DT data, and it's used. If you only need, say, DSI, the RGB port >> is not used and thus it doesn't need to be present in the DT data. >> >> It's fine to leave the port definition out if it is not used at all. > On Exynos, DSI is in fact RGB/DSI encoder (or I80/DSI). DSI and RGB pins > are connected to the same FIMD output. So from FIMD point of view > RGB port is used in both cases. I guessed as much, as it's the same on OMAP. But I think it's still fine to have a port only for RGB panel. For the RGB panel, you have pins on the SoC to which the RGB data goes to. The RGB port in DT represents these pins. You don't have pins for the FIMD->DSI case. But as I said, it's fine to use ports for internal connections also if it works for you. I still don't like the idea of having the port as optional in DT for cases where the port comes from the parent device. Sure, it removes some lines from the DT, but I think it makes it more confusing. Especially as I think it's a very rare case where you could use that optional format, as usually you will have some properties in the endpoint node. Tomi
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts index a0a985d..7d666b1 100644 --- a/arch/arm/boot/dts/exynos5250-arndale.dts +++ b/arch/arm/boot/dts/exynos5250-arndale.dts @@ -584,6 +584,45 @@ }; }; + panel: panel { + compatible = "boe,hv070wsa-100"; + power-supply = <&vcc_3v3_reg>; + enable-gpios = <&gpd1 3 0>; + port { + panel_ep: endpoint { + remote-endpoint = <&bridge_out_ep>; + }; + }; + }; + + dsi_0: dsi@14500000 { + vddcore-supply = <&ldo8_reg>; + vddio-supply = <&ldo10_reg>; + samsung,pll-clock-frequency = <24000000>; + samsung,burst-clock-frequency = <320000000>; + samsung,esc-clock-frequency = <10000000>; + status = "okay"; + + bridge@0 { + reg = <0>; + compatible = "toshiba,tc358764"; + vddc-supply = <&vcc_1v2_reg>; + vddio-supply = <&vcc_1v8_reg>; + vddmipi-supply = <&vcc_1v2_reg>; + vddlvds133-supply = <&vcc_3v3_reg>; + vddlvds112-supply = <&vcc_1v2_reg>; + reset-gpio = <&gpd1 6 1>; + #address-cells = <1>; + #size-cells = <0>; + port@1 { + reg = <1>; + bridge_out_ep: endpoint { + remote-endpoint = <&panel_ep>; + }; + }; + }; + }; + fimd: fimd@14400000 { status = "okay"; };
The patch adds bridge and panel nodes. It adds also DSI properties specific for arndale board. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> --- arch/arm/boot/dts/exynos5250-arndale.dts | 39 ++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)