Re: [PATCH v3 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Wednesday 11 July 2018 09:18 PM, Rob Herring wrote: On Mon, Jul 09, 2018 at 02:37:51PM +0530, Archit Taneja wrote: Add binding info for peripherals that support dual-channel DSI. Add corresponding optional bindings for DSI host controllers that may be configured in this mode. Add an example of an I2C controlled device operating in dual-channel DSI mode. Reviewed-by: Philippe Cornu Reviewed-by: Sean Paul Reviewed-by: Heiko Stuebner Signed-off-by: Archit Taneja --- .../devicetree/bindings/display/mipi-dsi-bus.txt | 80 ++ 1 file changed, 80 insertions(+) Reviewed-by: Rob Herring queued to drm-misc-next. Thanks, Archit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Mon, Jul 09, 2018 at 02:37:51PM +0530, Archit Taneja wrote: > Add binding info for peripherals that support dual-channel DSI. Add > corresponding optional bindings for DSI host controllers that may > be configured in this mode. Add an example of an I2C controlled > device operating in dual-channel DSI mode. > > Reviewed-by: Philippe Cornu > Reviewed-by: Sean Paul > Reviewed-by: Heiko Stuebner > Signed-off-by: Archit Taneja > --- > .../devicetree/bindings/display/mipi-dsi-bus.txt | 80 > ++ > 1 file changed, 80 insertions(+) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] dt-bindings: mipi-dsi: dual-channel DSI bindings
DSI host controllers these days can be ganged together to drive larger displays. Every SoC vendor supporting this is trying to add their own DT property so that the corresponding drivers can identify that they need to operate in the dual DSI mode. If we use the graph bindings, we don't really need an additional DT property in the DSI host controller to tell it that it's operating in dual-channel mode. It's something that can be inferred from the bindings itself. The first patch adds some explanation on how to deal with peripherals that do DSI, but have a different control bus. This is something we've already started using, but didn't have properly documented anywhere. The second patch proposes bindings for DSI hosts/peripherals that implement dual-channel DSI. Changes in v3: - Fixed a minor typo. - Added Reviewed-by tags. - Changed from RFC to PATCH. Changes in v2: - Incorported Rob's comments. Archit Taneja (2): dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus dt-bindings: mipi-dsi: Add dual-channel DSI related info .../devicetree/bindings/display/mipi-dsi-bus.txt | 153 +++-- 1 file changed, 145 insertions(+), 8 deletions(-) -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.
Reviewed-by: Philippe Cornu
Reviewed-by: Sean Paul
Reviewed-by: Heiko Stuebner
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/mipi-dsi-bus.txt | 80 ++
1 file changed, 80 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index b7c5bf47403c..a336599f6c03 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
- #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
+Optional properties:
+- clock-master: boolean. Should be enabled if the host is being used in
+ conjunction with another DSI host to drive the same peripheral. Hardware
+ supporting such a configuration generally requires the data on both the
busses
+ to be driven by the same clock. Only the DSI host instance controlling this
+ clock should contain this property.
+
DSI peripheral
==
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus
(mostly for the data
path). Connections between such peripherals and a DSI host can be represented
using the graph bindings [1], [2].
+Peripherals that support dual channel DSI
+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -71,6 +88,8 @@ Examples
with different virtual channel configurations.
- (4) is an example of a peripheral on a I2C control bus connected to a
DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+ which uses I2C as its primary control bus.
1)
dsi-host {
@@ -153,3 +172,64 @@ Examples
};
};
};
+
+5)
+ i2c-host {
+ dsi-bridge@35 {
+ compatible = "...";
+ reg = <0x35>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+ };
+
+ dsi0-host {
+ ...
+
+ /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+ clock-master;
+
+ ports {
+ ...
+
+ port {
+ dsi0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ dsi1-host {
+ ...
+
+ ports {
+ ...
+
+ port {
+ dsi1_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Hi Andrzej et all, just so we don't discuss in a theoretic way much longer I've just sent a RFC with my current state of work for the dw-mipi-dsi dual-dsi support - aka the old "let code speak" ;-) I've found a somewhat nice way to get from one dsi-controller node to the node of the other dual-dsi part via separate ports as well. So no more hackery with endpoints and I can just follow Archit's dual-dsi binding text. Am Freitag, 8. Juni 2018, 10:47:05 CEST schrieb Andrzej Hajda: > On 08.06.2018 00:50, Heiko Stuebner wrote: > > Am Donnerstag, 7. Juni 2018, 23:10:20 CEST schrieb Brian Norris: > >> Hi, > >> > >> I only have a little bit to add, but Heiko did solicit my opinion. > > yep ... and I realized that I am/was way to attached to my (working) > > endpoint-based thingy to really appreciate the other arguments ;-) > > > > And your DSI-related writings below, did provide some new thought- > > directions for me, so thanks for that. [...] > >> On Thu, Jun 07, 2018 at 03:25:18PM +0200, Heiko Stuebner wrote: > >>> Am Donnerstag, 7. Juni 2018, 12:39:03 CEST schrieb Andrzej Hajda: > On 07.06.2018 01:08, Heiko Stuebner wrote: > >>> Also the crtc<->dsi interaction is quite a bit of handling-different > >>> between > >>> one crtc talking to 2 DSIs or 2 crtc talking to the 2 DSIs separately. > >> That's probably the bigger key: to treat them as completely separate > >> ports means that you get separate CRTCs, IIUC (I'll admit, I'm still a > >> bit rusty on navigating some DRM concepts). > > One thing I realized with your mention of DSI maxing out at 4 lanes is, > > that this makes it easy to detect the existence of a dual-dsi situation ... > > simply when the device reports 8 lanes. > > (via of_find_mipi_dsi_device_by_node presumably) > > Hmm, device has two DSI interfaces, on each it has 4 lanes, so it report > 4 lanes. Ok ... that is what Tegra seems to do as well. The panel reporting 4 lanes, and this gettings assigned to each of the two dsi controllers. So I'll need to change that in my v2 as well. > There is different problem with current implementation of panel lookup > code - drm_panel is identified by device_node of physical device, as a > result there can be only one panel per device. > I think proper identification should be by device_node of OF graph port, > or by pair: device_node of physical device and port number (practically > it is the same). > I think fixing it should not be a big deal. Right now in my RFC it seems to work without needing changes to panel types or identification, so I guess we can discuss changes you would like to see over there. Heiko > > As a dual-dsi situation requires a clock-master property in one, > > both master and slave also would be able to determine their > > master or slave status, thus the global dual-dsi config could be > > done by the master (GRF stuff in the Rockchip case) > > > > > > The only thing that makes my head explode now, is how to > > make the slave actually react to settings sent to the master > > in a sane way. > > Wouldn't be enough if the panel passes different bus info on DSI0 and DSI1? > > Regards > Andrzej > > > > > But that is a drm-specific implementation-detail, I guess ;-) . > > And hopefully someone might have a great idea how this > > could be done better than in my current implementation. > > > > > > Heiko > > > > > > > > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On 08.06.2018 00:50, Heiko Stuebner wrote: > Am Donnerstag, 7. Juni 2018, 23:10:20 CEST schrieb Brian Norris: >> Hi, >> >> I only have a little bit to add, but Heiko did solicit my opinion. > yep ... and I realized that I am/was way to attached to my (working) > endpoint-based thingy to really appreciate the other arguments ;-) > > And your DSI-related writings below, did provide some new thought- > directions for me, so thanks for that. > >> On Thu, Jun 07, 2018 at 03:25:18PM +0200, Heiko Stuebner wrote: >>> Am Donnerstag, 7. Juni 2018, 12:39:03 CEST schrieb Andrzej Hajda: >>>> On 07.06.2018 01:08, Heiko Stuebner wrote: >>>>> Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja: >>>>>> On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: >>>>>>> Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: >>>>>>>> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: >>>>>>>>> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: >>>>>>>>>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: >>>>>>>>>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja: >>>>>>>>>>>> Add binding info for peripherals that support dual-channel DSI. Add >>>>>>>>>>>> corresponding optional bindings for DSI host controllers that may >>>>>>>>>>>> be configured in this mode. Add an example of an I2C controlled >>>>>>>>>>>> device operating in dual-channel DSI mode. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Archit Taneja >>>>>>>>>>> Looks like a great solution for that problem, so >>>>>>>>>>> Reviewed-by: Heiko Stuebner >>>>>>>>>>> >>>>>>>>>>> As I'm looking into that for my rk3399-scarlet device right now and >>>>>>>>>>> couldn't find this patchset in the kernel yet, is it planned to >>>>>>>>>>> merge or refresh these binding changes or were problems encountered. >>>>>>>>>>> >>>>>>>>>>> At least an Ack/Review from Rob seems to be missing. >>>>>>>>>> I forgot about these patches. Rob had reviewed the first one in >>>>>>>>>> the set the second one still needed an Ack. I'll post a v3 >>>>>>>>>> that adds the Reviewed-bys and fixes a small typo. >>>>>>>>> very nice ... because it looks like yesterday I managed to make the >>>>>>>>> Rockchip dsi work in dual mode following this. >>>>>>>>> >>>>>>>>> But one question came up, do you really want two input ports on the >>>>>>>>> panel >>>>>>>>> side? I.e. hardware-wise, I guess the panel will have one 8-lane or so >>>>>>>>> input thatonly gets split up on the soc side onto 2 dsi controllers? >>>>>>>> I think all dual DSI panels actually have 2 DSI controllers/parsers >>>>>>>> within them, one on each port. The MIPI DSI spec doesn't support 8 >>>>>>>> lanes. Also, the pixels coming out of the host are distributed among >>>>>>>> the lanes differently than what would have been the case with a >>>>>>>> 'theoretical' 8 lane receiver. >>>>>>>> >>>>>>>> Other than that, some dual DSI panels only accept DSI commands on the >>>>>>>> 'master' port, where as others expect the same command to be sent >>>>>>>> across >>>>>>>> both the ports. >>>>>>>> >>>>>>>> Therefore, I think it's better to represent dual DSI panels having 2 >>>>>>>> DSI input ports. >>>>>>>> >>>>>>>> Your DT looks good to me. >>>>>>> Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints >>>>>>> in one port for the dsi-links. >>>>>> Sorry, I didn't notice you'd created two endpoints within a single port. >>>>>> >>>>>> I don't think I'm particular about 2 ports vs 1 port with 2 endpoints. >>>>>> They both seem okay to me as long a
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Am Donnerstag, 7. Juni 2018, 23:10:20 CEST schrieb Brian Norris: > Hi, > > I only have a little bit to add, but Heiko did solicit my opinion. yep ... and I realized that I am/was way to attached to my (working) endpoint-based thingy to really appreciate the other arguments ;-) And your DSI-related writings below, did provide some new thought- directions for me, so thanks for that. > On Thu, Jun 07, 2018 at 03:25:18PM +0200, Heiko Stuebner wrote: > > Am Donnerstag, 7. Juni 2018, 12:39:03 CEST schrieb Andrzej Hajda: > > > On 07.06.2018 01:08, Heiko Stuebner wrote: > > > > Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja: > > > >> On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: > > > >>> Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: > > > >>>> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: > > > >>>>> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: > > > >>>>>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: > > > >>>>>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit > > > >>>>>>> Taneja: > > > >>>>>>>> Add binding info for peripherals that support dual-channel DSI. > > > >>>>>>>> Add > > > >>>>>>>> corresponding optional bindings for DSI host controllers that may > > > >>>>>>>> be configured in this mode. Add an example of an I2C controlled > > > >>>>>>>> device operating in dual-channel DSI mode. > > > >>>>>>>> > > > >>>>>>>> Signed-off-by: Archit Taneja > > > >>>>>>> > > > >>>>>>> Looks like a great solution for that problem, so > > > >>>>>>> Reviewed-by: Heiko Stuebner > > > >>>>>>> > > > >>>>>>> As I'm looking into that for my rk3399-scarlet device right now > > > >>>>>>> and > > > >>>>>>> couldn't find this patchset in the kernel yet, is it planned to > > > >>>>>>> merge or refresh these binding changes or were problems > > > >>>>>>> encountered. > > > >>>>>>> > > > >>>>>>> At least an Ack/Review from Rob seems to be missing. > > > >>>>>> > > > >>>>>> I forgot about these patches. Rob had reviewed the first one in > > > >>>>>> the set the second one still needed an Ack. I'll post a v3 > > > >>>>>> that adds the Reviewed-bys and fixes a small typo. > > > >>>>> > > > >>>>> very nice ... because it looks like yesterday I managed to make the > > > >>>>> Rockchip dsi work in dual mode following this. > > > >>>>> > > > >>>>> But one question came up, do you really want two input ports on the > > > >>>>> panel > > > >>>>> side? I.e. hardware-wise, I guess the panel will have one 8-lane or > > > >>>>> so > > > >>>>> input thatonly gets split up on the soc side onto 2 dsi controllers? > > > >>>> > > > >>>> I think all dual DSI panels actually have 2 DSI controllers/parsers > > > >>>> within them, one on each port. The MIPI DSI spec doesn't support 8 > > > >>>> lanes. Also, the pixels coming out of the host are distributed among > > > >>>> the lanes differently than what would have been the case with a > > > >>>> 'theoretical' 8 lane receiver. > > > >>>> > > > >>>> Other than that, some dual DSI panels only accept DSI commands on the > > > >>>> 'master' port, where as others expect the same command to be sent > > > >>>> across > > > >>>> both the ports. > > > >>>> > > > >>>> Therefore, I think it's better to represent dual DSI panels having 2 > > > >>>> DSI input ports. > > > >>>> > > > >>>> Your DT looks good to me. > > > >>> > > > >>> Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints > > > >>> in one port for the dsi-links. >
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Hi, I only have a little bit to add, but Heiko did solicit my opinion. On Thu, Jun 07, 2018 at 03:25:18PM +0200, Heiko Stuebner wrote: > Am Donnerstag, 7. Juni 2018, 12:39:03 CEST schrieb Andrzej Hajda: > > On 07.06.2018 01:08, Heiko Stuebner wrote: > > > Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja: > > >> On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: > > >>> Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: > > >>>> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: > > >>>>> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: > > >>>>>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: > > >>>>>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja: > > >>>>>>>> Add binding info for peripherals that support dual-channel DSI. Add > > >>>>>>>> corresponding optional bindings for DSI host controllers that may > > >>>>>>>> be configured in this mode. Add an example of an I2C controlled > > >>>>>>>> device operating in dual-channel DSI mode. > > >>>>>>>> > > >>>>>>>> Signed-off-by: Archit Taneja > > >>>>>>> > > >>>>>>> Looks like a great solution for that problem, so > > >>>>>>> Reviewed-by: Heiko Stuebner > > >>>>>>> > > >>>>>>> As I'm looking into that for my rk3399-scarlet device right now and > > >>>>>>> couldn't find this patchset in the kernel yet, is it planned to > > >>>>>>> merge or refresh these binding changes or were problems encountered. > > >>>>>>> > > >>>>>>> At least an Ack/Review from Rob seems to be missing. > > >>>>>> > > >>>>>> I forgot about these patches. Rob had reviewed the first one in > > >>>>>> the set the second one still needed an Ack. I'll post a v3 > > >>>>>> that adds the Reviewed-bys and fixes a small typo. > > >>>>> > > >>>>> very nice ... because it looks like yesterday I managed to make the > > >>>>> Rockchip dsi work in dual mode following this. > > >>>>> > > >>>>> But one question came up, do you really want two input ports on the > > >>>>> panel > > >>>>> side? I.e. hardware-wise, I guess the panel will have one 8-lane or so > > >>>>> input thatonly gets split up on the soc side onto 2 dsi controllers? > > >>>> > > >>>> I think all dual DSI panels actually have 2 DSI controllers/parsers > > >>>> within them, one on each port. The MIPI DSI spec doesn't support 8 > > >>>> lanes. Also, the pixels coming out of the host are distributed among > > >>>> the lanes differently than what would have been the case with a > > >>>> 'theoretical' 8 lane receiver. > > >>>> > > >>>> Other than that, some dual DSI panels only accept DSI commands on the > > >>>> 'master' port, where as others expect the same command to be sent > > >>>> across > > >>>> both the ports. > > >>>> > > >>>> Therefore, I think it's better to represent dual DSI panels having 2 > > >>>> DSI input ports. > > >>>> > > >>>> Your DT looks good to me. > > >>> > > >>> Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints > > >>> in one port for the dsi-links. > > >> > > >> Sorry, I didn't notice you'd created two endpoints within a single port. > > >> > > >> I don't think I'm particular about 2 ports vs 1 port with 2 endpoints. > > >> They both seem okay to me as long as we follow it consistently. I'm > > >> myself not 100% sure of how to figure where one should prefer endpoints > > >> over ports. Maybe someone more familiar with the of graph bindings > > >> could comment here. > > > > Port should describe physical port, endpoint are used to describe > > multiple links to the same port. If the panel has two physical DSI > > interfaces it should use two ports. > > That again leaves a bit of space for interpretation ;-) . Does it really? DSI maxes ou
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Hi Andrzej, Am Donnerstag, 7. Juni 2018, 12:39:03 CEST schrieb Andrzej Hajda: > On 07.06.2018 01:08, Heiko Stuebner wrote: > > Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja: > >> On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: > >>> Hi Archit, > >>> > >>> Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: > >>>> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: > >>>>> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: > >>>>>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: > >>>>>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja: > >>>>>>>> Add binding info for peripherals that support dual-channel DSI. Add > >>>>>>>> corresponding optional bindings for DSI host controllers that may > >>>>>>>> be configured in this mode. Add an example of an I2C controlled > >>>>>>>> device operating in dual-channel DSI mode. > >>>>>>>> > >>>>>>>> Signed-off-by: Archit Taneja > >>>>>>> > >>>>>>> Looks like a great solution for that problem, so > >>>>>>> Reviewed-by: Heiko Stuebner > >>>>>>> > >>>>>>> As I'm looking into that for my rk3399-scarlet device right now and > >>>>>>> couldn't find this patchset in the kernel yet, is it planned to > >>>>>>> merge or refresh these binding changes or were problems encountered. > >>>>>>> > >>>>>>> At least an Ack/Review from Rob seems to be missing. > >>>>>> > >>>>>> I forgot about these patches. Rob had reviewed the first one in > >>>>>> the set the second one still needed an Ack. I'll post a v3 > >>>>>> that adds the Reviewed-bys and fixes a small typo. > >>>>> > >>>>> very nice ... because it looks like yesterday I managed to make the > >>>>> Rockchip dsi work in dual mode following this. > >>>>> > >>>>> But one question came up, do you really want two input ports on the > >>>>> panel > >>>>> side? I.e. hardware-wise, I guess the panel will have one 8-lane or so > >>>>> input thatonly gets split up on the soc side onto 2 dsi controllers? > >>>> > >>>> I think all dual DSI panels actually have 2 DSI controllers/parsers > >>>> within them, one on each port. The MIPI DSI spec doesn't support 8 > >>>> lanes. Also, the pixels coming out of the host are distributed among > >>>> the lanes differently than what would have been the case with a > >>>> 'theoretical' 8 lane receiver. > >>>> > >>>> Other than that, some dual DSI panels only accept DSI commands on the > >>>> 'master' port, where as others expect the same command to be sent > >>>> across > >>>> both the ports. > >>>> > >>>> Therefore, I think it's better to represent dual DSI panels having 2 > >>>> DSI input ports. > >>>> > >>>> Your DT looks good to me. > >>> > >>> Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints > >>> in one port for the dsi-links. > >> > >> Sorry, I didn't notice you'd created two endpoints within a single port. > >> > >> I don't think I'm particular about 2 ports vs 1 port with 2 endpoints. > >> They both seem okay to me as long as we follow it consistently. I'm > >> myself not 100% sure of how to figure where one should prefer endpoints > >> over ports. Maybe someone more familiar with the of graph bindings > >> could comment here. > > Port should describe physical port, endpoint are used to describe > multiple links to the same port. If the panel has two physical DSI > interfaces it should use two ports. That again leaves a bit of space for interpretation ;-) . A dual-dsi display is probably pretty useless with only one controller connected to it, as its 4 lanes cannot satisfy the required 8 lanes of the panel. See [0] for current WIP panel addition. [Was already on the lists but needs cleanup] [0] https://github.com/mmind/linux-rockchip/commit/459bc1a1599377c2c5408724e82619a4602a953d#diff-5d6d6ddab4fd282102d23d2c02e835f8R381 > >>> The issue I see with using ports and not endpoints
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On 07.06.2018 01:08, Heiko Stuebner wrote: > Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja: >> On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: >>> Hi Archit, >>> >>> Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: >>>> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: >>>>> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: >>>>>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: >>>>>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja: >>>>>>>> Add binding info for peripherals that support dual-channel DSI. Add >>>>>>>> corresponding optional bindings for DSI host controllers that may >>>>>>>> be configured in this mode. Add an example of an I2C controlled >>>>>>>> device operating in dual-channel DSI mode. >>>>>>>> >>>>>>>> Signed-off-by: Archit Taneja >>>>>>> Looks like a great solution for that problem, so >>>>>>> Reviewed-by: Heiko Stuebner >>>>>>> >>>>>>> As I'm looking into that for my rk3399-scarlet device right now and >>>>>>> couldn't find this patchset in the kernel yet, is it planned to >>>>>>> merge or refresh these binding changes or were problems encountered. >>>>>>> >>>>>>> At least an Ack/Review from Rob seems to be missing. >>>>>> I forgot about these patches. Rob had reviewed the first one in >>>>>> the set the second one still needed an Ack. I'll post a v3 >>>>>> that adds the Reviewed-bys and fixes a small typo. >>>>> very nice ... because it looks like yesterday I managed to make the >>>>> Rockchip dsi work in dual mode following this. >>>>> >>>>> But one question came up, do you really want two input ports on the panel >>>>> side? I.e. hardware-wise, I guess the panel will have one 8-lane or so >>>>> input thatonly gets split up on the soc side onto 2 dsi controllers? >>>> I think all dual DSI panels actually have 2 DSI controllers/parsers >>>> within them, one on each port. The MIPI DSI spec doesn't support 8 >>>> lanes. Also, the pixels coming out of the host are distributed among >>>> the lanes differently than what would have been the case with a >>>> 'theoretical' 8 lane receiver. >>>> >>>> Other than that, some dual DSI panels only accept DSI commands on the >>>> 'master' port, where as others expect the same command to be sent across >>>> both the ports. >>>> >>>> Therefore, I think it's better to represent dual DSI panels having 2 >>>> DSI input ports. >>>> >>>> Your DT looks good to me. >>> Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints >>> in one port for the dsi-links. >>> >> Sorry, I didn't notice you'd created two endpoints within a single port. >> >> I don't think I'm particular about 2 ports vs 1 port with 2 endpoints. >> They both seem okay to me as long as we follow it consistently. I'm >> myself not 100% sure of how to figure where one should prefer endpoints >> over ports. Maybe someone more familiar with the of graph bindings >> could comment here. Port should describe physical port, endpoint are used to describe multiple links to the same port. If the panel has two physical DSI interfaces it should use two ports. >> >> >>> The issue I see with using ports and not endpoints for dual-dsi links >>> is with distinguishing between input and output ports. >>> >>> For a panel that's easy, as you every port will be an input port and if >>> you have 2, it's supposed dual-dsi. But for example I guess there might >>> exist some dual-dsi-to-something bridges, where you would end up >>> with say 3 (or even more) ports ... two dual-dsi inputs and 1 or more >>> outputs. >> Okay, I get your point here. Although, even if the remote device had >> exactly 2 ports. Is it safe to assume that port #0 is an input port and >> port #1 is an output port? Is that the norm? > I don't think that anything like that is specified anywhere, so you cannot > assume anything about what a port contains. Ports are defined per device-node and port number assignment should be described in particular device bindings. So device driver knows well which functions should be assigned to which port. But it is pr
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja: > > On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: > > Hi Archit, > > > > Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: > >> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: > >>> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: > >>>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: > >>>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja: > >>>>>> Add binding info for peripherals that support dual-channel DSI. Add > >>>>>> corresponding optional bindings for DSI host controllers that may > >>>>>> be configured in this mode. Add an example of an I2C controlled > >>>>>> device operating in dual-channel DSI mode. > >>>>>> > >>>>>> Signed-off-by: Archit Taneja > >>>>> > >>>>> Looks like a great solution for that problem, so > >>>>> Reviewed-by: Heiko Stuebner > >>>>> > >>>>> As I'm looking into that for my rk3399-scarlet device right now and > >>>>> couldn't find this patchset in the kernel yet, is it planned to > >>>>> merge or refresh these binding changes or were problems encountered. > >>>>> > >>>>> At least an Ack/Review from Rob seems to be missing. > >>>> > >>>> I forgot about these patches. Rob had reviewed the first one in > >>>> the set the second one still needed an Ack. I'll post a v3 > >>>> that adds the Reviewed-bys and fixes a small typo. > >>> > >>> very nice ... because it looks like yesterday I managed to make the > >>> Rockchip dsi work in dual mode following this. > >>> > >>> But one question came up, do you really want two input ports on the panel > >>> side? I.e. hardware-wise, I guess the panel will have one 8-lane or so > >>> input thatonly gets split up on the soc side onto 2 dsi controllers? > >> > >> I think all dual DSI panels actually have 2 DSI controllers/parsers > >> within them, one on each port. The MIPI DSI spec doesn't support 8 > >> lanes. Also, the pixels coming out of the host are distributed among > >> the lanes differently than what would have been the case with a > >> 'theoretical' 8 lane receiver. > >> > >> Other than that, some dual DSI panels only accept DSI commands on the > >> 'master' port, where as others expect the same command to be sent across > >> both the ports. > >> > >> Therefore, I think it's better to represent dual DSI panels having 2 > >> DSI input ports. > >> > >> Your DT looks good to me. > > > > Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints > > in one port for the dsi-links. > > > > Sorry, I didn't notice you'd created two endpoints within a single port. > > I don't think I'm particular about 2 ports vs 1 port with 2 endpoints. > They both seem okay to me as long as we follow it consistently. I'm > myself not 100% sure of how to figure where one should prefer endpoints > over ports. Maybe someone more familiar with the of graph bindings > could comment here. > > > > The issue I see with using ports and not endpoints for dual-dsi links > > is with distinguishing between input and output ports. > > > > For a panel that's easy, as you every port will be an input port and if > > you have 2, it's supposed dual-dsi. But for example I guess there might > > exist some dual-dsi-to-something bridges, where you would end up > > with say 3 (or even more) ports ... two dual-dsi inputs and 1 or more > > outputs. > > Okay, I get your point here. Although, even if the remote device had > exactly 2 ports. Is it safe to assume that port #0 is an input port and > port #1 is an output port? Is that the norm? I don't think that anything like that is specified anywhere, so you cannot assume anything about what a port contains. > I've at least seen one device (toshiba,tc358767 bridge) that can > actually take either DPI as input or DSI based on how you configure it. > There are 2 input ports here, port #0 for DSI and port #1 for DPI. Would > it have made sense here to have a single port and 2 endpoints here too? Nope, I guess having a port for DPI input, one port for DSI input makes quite a lot of sense. And then you can have the input-specifics living in the endpoints like dual links or so. > > While the following argument m
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: Hi Archit, Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja: Add binding info for peripherals that support dual-channel DSI. Add corresponding optional bindings for DSI host controllers that may be configured in this mode. Add an example of an I2C controlled device operating in dual-channel DSI mode. Signed-off-by: Archit Taneja Looks like a great solution for that problem, so Reviewed-by: Heiko Stuebner As I'm looking into that for my rk3399-scarlet device right now and couldn't find this patchset in the kernel yet, is it planned to merge or refresh these binding changes or were problems encountered. At least an Ack/Review from Rob seems to be missing. I forgot about these patches. Rob had reviewed the first one in the set the second one still needed an Ack. I'll post a v3 that adds the Reviewed-bys and fixes a small typo. very nice ... because it looks like yesterday I managed to make the Rockchip dsi work in dual mode following this. But one question came up, do you really want two input ports on the panel side? I.e. hardware-wise, I guess the panel will have one 8-lane or so input thatonly gets split up on the soc side onto 2 dsi controllers? I think all dual DSI panels actually have 2 DSI controllers/parsers within them, one on each port. The MIPI DSI spec doesn't support 8 lanes. Also, the pixels coming out of the host are distributed among the lanes differently than what would have been the case with a 'theoretical' 8 lane receiver. Other than that, some dual DSI panels only accept DSI commands on the 'master' port, where as others expect the same command to be sent across both the ports. Therefore, I think it's better to represent dual DSI panels having 2 DSI input ports. Your DT looks good to me. Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints in one port for the dsi-links. Sorry, I didn't notice you'd created two endpoints within a single port. I don't think I'm particular about 2 ports vs 1 port with 2 endpoints. They both seem okay to me as long as we follow it consistently. I'm myself not 100% sure of how to figure where one should prefer endpoints over ports. Maybe someone more familiar with the of graph bindings could comment here. The issue I see with using ports and not endpoints for dual-dsi links is with distinguishing between input and output ports. For a panel that's easy, as you every port will be an input port and if you have 2, it's supposed dual-dsi. But for example I guess there might exist some dual-dsi-to-something bridges, where you would end up with say 3 (or even more) ports ... two dual-dsi inputs and 1 or more outputs. Okay, I get your point here. Although, even if the remote device had exactly 2 ports. Is it safe to assume that port #0 is an input port and port #1 is an output port? Is that the norm? I've at least seen one device (toshiba,tc358767 bridge) that can actually take either DPI as input or DSI based on how you configure it. There are 2 input ports here, port #0 for DSI and port #1 for DPI. Would it have made sense here to have a single port and 2 endpoints here too? While the following argument might not be 100% valid from a dt-purity standpoint implementing this might get hairy for _any_ operating system, as you will need each panel/bridge to tell what the ports are used for. Yeah. I.e. in my endpoint based mapping, right now I have this nice and generic WIP function to parse the of_graph and get the master+slave nodes: https://github.com/mmind/linux-rockchip/blob/tmp/rk3399-gru-bob-scarlet/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#L697 [0] I'd tried out something locally before posting this patch, I don't have the code for it, but I can describe the steps I took. This code expects the panel/bridge to have 2 input ports. 1. DSI0 host driver looks up its output port, gets the remote endpoint, and get this endpoint's parent (using of_graph_get_remote_port_parent()). Keeps the parent device node in a temp variable. 2. DSI1 host driver does the same thing. 3. DSI0 and DSI1 check whether their outputs are connected to the same device. If so, they're in dual DSI mode. If not, they are operating independently. The positive of this approach is that we don't need to make any assumptions about the panel/bridge's port numbers, which is great. The negative is that our DSI controller instances now need to query each other, which can be messy, but not too hard to implement. I think the choice finally boils down to what makes more sense w.r.t representing the HW correctly. We'd need Rob's comment on that. Thanks, Archit So I guess my proposal would be to have one port for inputs
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Hi Archit,
Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja:
> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
> > Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
> >> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> >>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
> >>>> Add binding info for peripherals that support dual-channel DSI. Add
> >>>> corresponding optional bindings for DSI host controllers that may
> >>>> be configured in this mode. Add an example of an I2C controlled
> >>>> device operating in dual-channel DSI mode.
> >>>>
> >>>> Signed-off-by: Archit Taneja
> >>>
> >>> Looks like a great solution for that problem, so
> >>> Reviewed-by: Heiko Stuebner
> >>>
> >>> As I'm looking into that for my rk3399-scarlet device right now and
> >>> couldn't find this patchset in the kernel yet, is it planned to
> >>> merge or refresh these binding changes or were problems encountered.
> >>>
> >>> At least an Ack/Review from Rob seems to be missing.
> >>
> >> I forgot about these patches. Rob had reviewed the first one in
> >> the set the second one still needed an Ack. I'll post a v3
> >> that adds the Reviewed-bys and fixes a small typo.
> >
> > very nice ... because it looks like yesterday I managed to make the
> > Rockchip dsi work in dual mode following this.
> >
> > But one question came up, do you really want two input ports on the panel
> > side? I.e. hardware-wise, I guess the panel will have one 8-lane or so
> > input thatonly gets split up on the soc side onto 2 dsi controllers?
>
> I think all dual DSI panels actually have 2 DSI controllers/parsers
> within them, one on each port. The MIPI DSI spec doesn't support 8
> lanes. Also, the pixels coming out of the host are distributed among
> the lanes differently than what would have been the case with a
> 'theoretical' 8 lane receiver.
>
> Other than that, some dual DSI panels only accept DSI commands on the
> 'master' port, where as others expect the same command to be sent across
> both the ports.
>
> Therefore, I think it's better to represent dual DSI panels having 2
> DSI input ports.
>
> Your DT looks good to me.
Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints
in one port for the dsi-links.
The issue I see with using ports and not endpoints for dual-dsi links
is with distinguishing between input and output ports.
For a panel that's easy, as you every port will be an input port and if
you have 2, it's supposed dual-dsi. But for example I guess there might
exist some dual-dsi-to-something bridges, where you would end up
with say 3 (or even more) ports ... two dual-dsi inputs and 1 or more
outputs.
While the following argument might not be 100% valid from a dt-purity
standpoint implementing this might get hairy for _any_ operating system,
as you will need each panel/bridge to tell what the ports are used for.
I.e. in my endpoint based mapping, right now I have this nice and generic
WIP function to parse the of_graph and get the master+slave nodes:
https://github.com/mmind/linux-rockchip/blob/tmp/rk3399-gru-bob-scarlet/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#L697
[0]
So I guess my proposal would be to have one port for inputs
and one port for outputs for dsi peripherals, with possibly
multiple endpoints in each.
Heiko
[0] github seems to have reliability problems, so for reference my
parsing function:
static int dw_mipi_dsi_is_dual(struct dw_mipi_dsi_rockchip *dsi,
struct device_node **master, struct device_node **slave)
{
struct device_node *local_ep, *remote_port, *ep;
struct device_node *ctrls[2] = { NULL, NULL };
int num = 0, ret = 0, idx;
/* get local panel endpoint of the dsi controller */
local_ep = of_graph_get_endpoint_by_regs(dsi->dev->of_node, 1, 0);
if (!local_ep) {
DRM_DEV_ERROR(dsi->dev, "couldn't find local panel endpoint\n");
return -ENXIO;
}
/* get panel port */
remote_port = of_graph_get_remote_port_parent(local_ep);
of_node_put(local_ep);
if (!remote_port) {
DRM_DEV_ERROR(dsi->dev, "couldn't find panel port\n");
return -ENXIO;
}
/* check other endpoints */
for_each_endpoint_of_node(remote_port, ep) {
struct device_node *np = of_graph_get_remote_port_parent(ep);
if (!np)
continue;
idx = of_property_read_bool(np, "clock-master");
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.
Signed-off-by: Archit Taneja
Looks like a great solution for that problem, so
Reviewed-by: Heiko Stuebner
As I'm looking into that for my rk3399-scarlet device right now and
couldn't find this patchset in the kernel yet, is it planned to
merge or refresh these binding changes or were problems encountered.
At least an Ack/Review from Rob seems to be missing.
I forgot about these patches. Rob had reviewed the first one in
the set the second one still needed an Ack. I'll post a v3
that adds the Reviewed-bys and fixes a small typo.
very nice ... because it looks like yesterday I managed to make the Rockchip
dsi work in dual mode following this.
But one question came up, do you really want two input ports on the panel
side? I.e. hardware-wise, I guess the panel will have one 8-lane or so input
thatonly gets split up on the soc side onto 2 dsi controllers?
I think all dual DSI panels actually have 2 DSI controllers/parsers
within them, one on each port. The MIPI DSI spec doesn't support 8
lanes. Also, the pixels coming out of the host are distributed among
the lanes differently than what would have been the case with a
'theoretical' 8 lane receiver.
Other than that, some dual DSI panels only accept DSI commands on the
'master' port, where as others expect the same command to be sent across
both the ports.
Therefore, I think it's better to represent dual DSI panels having 2
DSI input ports.
Your DT looks good to me.
Thanks,
Archit
So right now I'm operating with a devicetree like
_dsi {
status = "okay";
clock-master;
ports {
mipi_out: port@1 {
reg = <1>;
mipi_out_panel: endpoint {
remote-endpoint = <_in_panel>;
};
};
};
mipi_panel: panel@0 {
compatible = "innolux,p097pfg";
reg = <0>;
backlight = <>;
enable-gpios = < 25 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_rst_l>;
port {
#address-cells = <1>;
#size-cells = <0>;
mipi_in_panel: endpoint@0 {
reg = <0>;
remote-endpoint = <_out_panel>;
};
mipi1_in_panel: endpoint@1 {
reg = <1>;
remote-endpoint = <_out_panel>;
};
};
};
};
_dsi1 {
status = "okay";
ports {
mipi1_out: port@1 {
reg = <1>;
mipi1_out_panel: endpoint {
remote-endpoint = <_in_panel>;
};
};
};
};
I guess it is a matter of preference on what reflects the hardware
best, so maybe that's Robs call?
Heiko
---
v2:
- Specify that clock-master is a boolean property.
- Drop/add unit-address and #*-cells where applicable.
.../devicetree/bindings/display/mipi-dsi-bus.txt | 80
++ 1 file changed, 80 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
94fb72cb916f..7a3abbedb3fa 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
- #size-cells: Should be 0. There are cases where it makes sense to use
a
different value here. See below.
+Optional properties:
+- clock-master: boolean. Should be enabled if the host is being used in
+ conjunction with another DSI host to drive the same peripheral.
Hardware
+ supporting such a configuration generally requires the data on both
the busses + to be driven by the same clock. Only the DSI host instance
controlling this + clock should contain this property.
+
DSI peripheral
==
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
bus (mostly for the data>>
path). Connections between su
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> > Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
> >> Add binding info for peripherals that support dual-channel DSI. Add
> >> corresponding optional bindings for DSI host controllers that may
> >> be configured in this mode. Add an example of an I2C controlled
> >> device operating in dual-channel DSI mode.
> >>
> >> Signed-off-by: Archit Taneja
> >
> > Looks like a great solution for that problem, so
> > Reviewed-by: Heiko Stuebner
> >
> > As I'm looking into that for my rk3399-scarlet device right now and
> > couldn't find this patchset in the kernel yet, is it planned to
> > merge or refresh these binding changes or were problems encountered.
> >
> > At least an Ack/Review from Rob seems to be missing.
>
> I forgot about these patches. Rob had reviewed the first one in
> the set the second one still needed an Ack. I'll post a v3
> that adds the Reviewed-bys and fixes a small typo.
very nice ... because it looks like yesterday I managed to make the Rockchip
dsi work in dual mode following this.
But one question came up, do you really want two input ports on the panel
side? I.e. hardware-wise, I guess the panel will have one 8-lane or so input
thatonly gets split up on the soc side onto 2 dsi controllers?
So right now I'm operating with a devicetree like
_dsi {
status = "okay";
clock-master;
ports {
mipi_out: port@1 {
reg = <1>;
mipi_out_panel: endpoint {
remote-endpoint = <_in_panel>;
};
};
};
mipi_panel: panel@0 {
compatible = "innolux,p097pfg";
reg = <0>;
backlight = <>;
enable-gpios = < 25 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_rst_l>;
port {
#address-cells = <1>;
#size-cells = <0>;
mipi_in_panel: endpoint@0 {
reg = <0>;
remote-endpoint = <_out_panel>;
};
mipi1_in_panel: endpoint@1 {
reg = <1>;
remote-endpoint = <_out_panel>;
};
};
};
};
_dsi1 {
status = "okay";
ports {
mipi1_out: port@1 {
reg = <1>;
mipi1_out_panel: endpoint {
remote-endpoint = <_in_panel>;
};
};
};
};
I guess it is a matter of preference on what reflects the hardware
best, so maybe that's Robs call?
Heiko
> >> ---
> >> v2:
> >> - Specify that clock-master is a boolean property.
> >> - Drop/add unit-address and #*-cells where applicable.
> >>
> >> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
> >> ++ 1 file changed, 80 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
> >> 94fb72cb916f..7a3abbedb3fa 100644
> >> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >>
> >> @@ -29,6 +29,13 @@ Required properties:
> >> - #size-cells: Should be 0. There are cases where it makes sense to use
> >> a
> >>
> >> different value here. See below.
> >>
> >> +Optional properties:
> >> +- clock-master: boolean. Should be enabled if the host is being used in
> >> + conjunction with another DSI host to drive the same peripheral.
> >> Hardware
> >> + supporting such a configuration generally requires the data on both
> >> the busses + to be driven by the same clock. Only the DSI host instance
> >> controlling this + clock should contain this property.
> >> +
> >>
> >> DSI peripheral
> >> ==
> >>
> >> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
> >> bus (mostly for the data>>
> >> path). Connections between such peripherals and a DSI host can be
> >&
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.
Signed-off-by: Archit Taneja
Looks like a great solution for that problem, so
Reviewed-by: Heiko Stuebner
As I'm looking into that for my rk3399-scarlet device right now and
couldn't find this patchset in the kernel yet, is it planned to
merge or refresh these binding changes or were problems encountered.
At least an Ack/Review from Rob seems to be missing.
I forgot about these patches. Rob had reviewed the first one in
the set the second one still needed an Ack. I'll post a v3
that adds the Reviewed-bys and fixes a small typo.
Archit
Heiko
---
v2:
- Specify that clock-master is a boolean property.
- Drop/add unit-address and #*-cells where applicable.
.../devicetree/bindings/display/mipi-dsi-bus.txt | 80 ++
1 file changed, 80 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 94fb72cb916f..7a3abbedb3fa 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
- #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
+Optional properties:
+- clock-master: boolean. Should be enabled if the host is being used in
+ conjunction with another DSI host to drive the same peripheral. Hardware
+ supporting such a configuration generally requires the data on both the
busses
+ to be driven by the same clock. Only the DSI host instance controlling this
+ clock should contain this property.
+
DSI peripheral
==
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus (mostly for the data
path). Connections between such peripherals and a DSI host can be represented
using the graph bindings [1], [2].
+Peripherals that support dual channel DSI
+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -71,6 +88,8 @@ Examples
with different virtual channel configurations.
- (4) is an example of a peripheral on a I2C control bus connected with to
a DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+ which uses I2C as its primary control bus.
1)
dsi-host {
@@ -153,3 +172,64 @@ Examples
};
};
};
+
+5)
+ i2c-host {
+ dsi-bridge@35 {
+ compatible = "...";
+ reg = <0x35>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+ };
+
+ dsi0-host {
+ ...
+
+ /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+ clock-master;
+
+ ports {
+ ...
+
+ port {
+ dsi0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ dsi1-host {
+ ...
+
+ ports {
+ ...
+
+
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode. Add an example of an I2C controlled
> device operating in dual-channel DSI mode.
>
> Signed-off-by: Archit Taneja
Looks like a great solution for that problem, so
Reviewed-by: Heiko Stuebner
As I'm looking into that for my rk3399-scarlet device right now and
couldn't find this patchset in the kernel yet, is it planned to
merge or refresh these binding changes or were problems encountered.
At least an Ack/Review from Rob seems to be missing.
Heiko
> ---
> v2:
> - Specify that clock-master is a boolean property.
> - Drop/add unit-address and #*-cells where applicable.
>
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
> ++
> 1 file changed, 80 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 94fb72cb916f..7a3abbedb3fa 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,13 @@ Required properties:
> - #size-cells: Should be 0. There are cases where it makes sense to use a
>different value here. See below.
>
> +Optional properties:
> +- clock-master: boolean. Should be enabled if the host is being used in
> + conjunction with another DSI host to drive the same peripheral. Hardware
> + supporting such a configuration generally requires the data on both the
> busses
> + to be driven by the same clock. Only the DSI host instance controlling this
> + clock should contain this property.
> +
> DSI peripheral
> ==
>
> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus
> (mostly for the data
> path). Connections between such peripherals and a DSI host can be represented
> using the graph bindings [1], [2].
>
> +Peripherals that support dual channel DSI
> +-
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the
> display).
> +The graph bindings should be used to represent the multiple DSI busses that
> are
> +connected to this peripheral. Each DSI host's output endpoint can be linked
> to
> +an input endpoint of the DSI peripheral.
> +
> [1] Documentation/devicetree/bindings/graph.txt
> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> @@ -71,6 +88,8 @@ Examples
>with different virtual channel configurations.
> - (4) is an example of a peripheral on a I2C control bus connected with to
>a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> + which uses I2C as its primary control bus.
>
> 1)
> dsi-host {
> @@ -153,3 +172,64 @@ Examples
> };
> };
> };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> + * this DSI instance drives the clock for both the host
> + * controllers
> + */
> + clock-master;
> +
> + ports {
> + ...
> +
> + port {
> + dsi0_out: endpoint {
> +
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Thu, Jan 18, 2018 at 10:23:55AM +0530, Archit Taneja wrote:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode. Add an example of an I2C controlled
> device operating in dual-channel DSI mode.
>
> Signed-off-by: Archit Taneja <arch...@codeaurora.org>
Reviewed-by: Sean Paul <seanp...@chromium.org>
> ---
> v2:
> - Specify that clock-master is a boolean property.
> - Drop/add unit-address and #*-cells where applicable.
>
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
> ++
> 1 file changed, 80 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 94fb72cb916f..7a3abbedb3fa 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,13 @@ Required properties:
> - #size-cells: Should be 0. There are cases where it makes sense to use a
>different value here. See below.
>
> +Optional properties:
> +- clock-master: boolean. Should be enabled if the host is being used in
> + conjunction with another DSI host to drive the same peripheral. Hardware
> + supporting such a configuration generally requires the data on both the
> busses
> + to be driven by the same clock. Only the DSI host instance controlling this
> + clock should contain this property.
> +
> DSI peripheral
> ==
>
> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus
> (mostly for the data
> path). Connections between such peripherals and a DSI host can be represented
> using the graph bindings [1], [2].
>
> +Peripherals that support dual channel DSI
> +-
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the
> display).
> +The graph bindings should be used to represent the multiple DSI busses that
> are
> +connected to this peripheral. Each DSI host's output endpoint can be linked
> to
> +an input endpoint of the DSI peripheral.
> +
> [1] Documentation/devicetree/bindings/graph.txt
> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> @@ -71,6 +88,8 @@ Examples
>with different virtual channel configurations.
> - (4) is an example of a peripheral on a I2C control bus connected with to
>a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> + which uses I2C as its primary control bus.
>
> 1)
> dsi-host {
> @@ -153,3 +172,64 @@ Examples
> };
> };
> };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> + * this DSI instance drives the clock for both the host
> + * controllers
> + */
> + clock-master;
> +
> + ports {
> + ...
> +
> + port {
> + dsi0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + dsi1-host {
> + ...
> +
> + ports {
> + ...
> +
> + port {
> +
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Hi Archit,
Many thanks for this documentation add-on.
I wonder if an extra example of "2 DSI hosts driving a dual-channel DSI
peripheral controlled by the mipi bus" could be useful? well, I am not
really convinced it is necessary and maybe this extra example could be
added later when someone will meet the case... and I should have sent
this comment on v1 (sorry for the delay).
Reviewed-by: Philippe Cornu <philippe.co...@st.com>
Philippe :-)
On 01/18/2018 05:53 AM, Archit Taneja wrote:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode. Add an example of an I2C controlled
> device operating in dual-channel DSI mode.
>
> Signed-off-by: Archit Taneja <arch...@codeaurora.org>
> ---
> v2:
> - Specify that clock-master is a boolean property.
> - Drop/add unit-address and #*-cells where applicable.
>
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
> ++
> 1 file changed, 80 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 94fb72cb916f..7a3abbedb3fa 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,13 @@ Required properties:
> - #size-cells: Should be 0. There are cases where it makes sense to use a
> different value here. See below.
>
> +Optional properties:
> +- clock-master: boolean. Should be enabled if the host is being used in
> + conjunction with another DSI host to drive the same peripheral. Hardware
> + supporting such a configuration generally requires the data on both the
> busses
> + to be driven by the same clock. Only the DSI host instance controlling this
> + clock should contain this property.
> +
> DSI peripheral
> ==
>
> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus
> (mostly for the data
> path). Connections between such peripherals and a DSI host can be
> represented
> using the graph bindings [1], [2].
>
> +Peripherals that support dual channel DSI
> +-
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the
> display).
> +The graph bindings should be used to represent the multiple DSI busses that
> are
> +connected to this peripheral. Each DSI host's output endpoint can be linked
> to
> +an input endpoint of the DSI peripheral.
> +
> [1] Documentation/devicetree/bindings/graph.txt
> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> @@ -71,6 +88,8 @@ Examples
> with different virtual channel configurations.
> - (4) is an example of a peripheral on a I2C control bus connected with to
> a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> + which uses I2C as its primary control bus.
>
> 1)
> dsi-host {
> @@ -153,3 +172,64 @@ Examples
> };
> };
> };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> + * this DSI instance drives the clock for both the host
> + * controllers
> + */
> + clock-master;
> +
> + ports {
> + ...
> +
> +
[RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
v2:
- Specify that clock-master is a boolean property.
- Drop/add unit-address and #*-cells where applicable.
.../devicetree/bindings/display/mipi-dsi-bus.txt | 80 ++
1 file changed, 80 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 94fb72cb916f..7a3abbedb3fa 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
- #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
+Optional properties:
+- clock-master: boolean. Should be enabled if the host is being used in
+ conjunction with another DSI host to drive the same peripheral. Hardware
+ supporting such a configuration generally requires the data on both the
busses
+ to be driven by the same clock. Only the DSI host instance controlling this
+ clock should contain this property.
+
DSI peripheral
==
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus
(mostly for the data
path). Connections between such peripherals and a DSI host can be represented
using the graph bindings [1], [2].
+Peripherals that support dual channel DSI
+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -71,6 +88,8 @@ Examples
with different virtual channel configurations.
- (4) is an example of a peripheral on a I2C control bus connected with to
a DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+ which uses I2C as its primary control bus.
1)
dsi-host {
@@ -153,3 +172,64 @@ Examples
};
};
};
+
+5)
+ i2c-host {
+ dsi-bridge@35 {
+ compatible = "...";
+ reg = <0x35>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+ };
+
+ dsi0-host {
+ ...
+
+ /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+ clock-master;
+
+ ports {
+ ...
+
+ port {
+ dsi0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ dsi1-host {
+ ...
+
+ ports {
+ ...
+
+ port {
+ dsi1_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 0/2] dt-bindings: mipi-dsi: dual-channel DSI bindings
DSI host controllers these days can be ganged together to drive larger
displays. Every SoC vendor supporting this is trying to add their own
DT property so that the corresponding drivers can identify that they
need to operate in the dual DSI mode. If we use the graph bindings, we
don't really need an additional DT property in the DSI host controller
to tell it that it's operating in dual-channel mode. It's something that
can be inferred
I don't know much about how dual-channel is implemented on anything apart
from MSM chipsets, but one thing that seems universal is that the clock
driving both the DSI controllers (and corresponding PHYs) should have the
same clock source. The DSI instance that drives this clock is generally
called the "master", and the other instance the "slave". A "clock-master"
DT property has been proposed for the same.
There are some open item(s) that aren't described in the mipi DSI/DCS
spec, but we might need to have either as bindings or some sort of DSI
flags:
- When sending commands over DSI to peripherals with 2 DSI channels,
some peripherals seem to have a requirement that both the DSIs trigger
the same command at the same time. Otherwise, the controller on the
peripheral goes a bit nuts. Is this common to all peripherals? Or are
there devices where we just need to send the DCS/generic commands to
the "master" DSI channel?
- When trying to read something back from the panel (a DCS read command
followed by a BTA etc.), should both the DSI controllers be listening
for data, or only the master?
- Anything else?
The first patch adds some explanation on how to deal with peripherals
that do DSI, but have a different control bus. This is something we've
already started using, but didn't have properly documented anywhere.
The second patch proposes bindings for DSI hosts/peripherals that
implement dual-channel DSI.
Changes in v2:
- Incorported Rob's comments.
Archit Taneja (2):
dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control
bus
dt-bindings: mipi-dsi: Add dual-channel DSI related info
.../devicetree/bindings/display/mipi-dsi-bus.txt | 153 +++--
1 file changed, 145 insertions(+), 8 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On Tue, Dec 05, 2017 at 04:03:56PM +0530, Archit Taneja wrote:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode.
>
> Signed-off-by: Archit Taneja <arch...@codeaurora.org>
> ---
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 77
> ++
> 1 file changed, 77 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 77a7cec15f5b..f556aaafdf22 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,12 @@ Required properties:
> - #size-cells: Should be 0. There are cases where it makes sense to use a
>different value here. See below.
>
> +Optional properties:
> +- clock-master: A DSI host controller may be used in conjunction with
> another DSI
> + host to drive the same peripheral. Hardware supporting such a configuration
> + generally requires the data on both the busses to be driven by the same
> clock.
> + The DSI host instance controlling this clock should contain this property.
Be explicit this is a boolean.
> +
> DSI peripheral
> ==
>
> @@ -61,6 +67,17 @@ primary control bus, but are also connected to a DSI bus
> (mostly for the data
> path). Connections between such peripherals and a DSI host can be represented
> using the graph bindings [1], [2].
>
> +Peripherals that support dual channel DSI
> +-
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the
> display).
> +The graph bindings should be used to represent the multiple DSI busses that
> are
> +connected to this peripheral. Each DSI host's output endpoint can be linked
> to
> +an input endpoint of the DSI peripheral.
> +
> +
> [1] Documentation/devicetree/bindings/graph.txt
> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> @@ -70,6 +87,8 @@ Examples
>with different virtual channel configurations.
> - (4) is an example of a peripheral on a I2C control bus connected with to
>a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> + which uses I2C as its primary control bus.
>
> 1)
> dsi-host {
> @@ -157,3 +176,61 @@ Examples
> };
> };
> };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + ...
> +
> + port@0 {
Need reg property and #{address,size}-cells.
> + dsi0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + dsi1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> + * this DSI instance drives the clock for both the host
> + * controllers
> + */
> + clock-master;
> +
> + ports {
> + ...
> +
> + port@0 {
Drop unit-address.
> + dsi0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + dsi1-host {
> + ...
> +
> + ports {
> + ...
> +
> + port@0 {
Drop unit-address.
> + dsi1_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 0/2] dt-bindings: mipi-dsi: dual-channel DSI bindings
DSI host controllers these days can be ganged together to drive larger
displays. Every SoC vendor supporting this is trying to add their own
DT property so that the corresponding drivers can identify that they
need to operate in the dual DSI mode. If we use the graph bindings, we
don't really need an additional DT property in the DSI host controller
to tell it that it's operating in dual-channel mode. It's something that
can be inferred
I don't know much about how dual-channel is implemented on anything apart
from MSM chipsets, but one thing that seems universal is that the clock
driving both the DSI controllers (and corresponding PHYs) should have the
same clock source. The DSI instance that drives this clock is generally
called the "master", and the other instance the "slave". A "clock-master"
DT property has been proposed for the same.
There are some open item(s) that aren't described in the mipi DSI/DCS
spec, but we might need to have either as bindings or some sort of DSI
flags:
- When sending commands over DSI to peripherals with 2 DSI channels,
some peripherals seem to have a requirement that both the DSIs trigger
the same command at the same time. Otherwise, the controller on the
peripheral goes a bit nuts. Is this common to all peripherals? Or are
there devices where we just need to send the DCS/generic commands to
the "master" DSI channel?
- When trying to read something back from the panel (a DCS read command
followed by a BTA etc.), should both the DSI controllers be listening
for data, or only the master?
- Anything else?
The first patch adds some explanation on how to deal with peripherals
that do DSI, but have a different control bus. This is something we've
already started using, but didn't have properly documented anywhere.
The second patch proposes bindings for DSI hosts/peripherals that
implement dual-channel DSI.
Archit Taneja (2):
dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control
bus
dt-bindings: mipi-dsi: Add dual-channel DSI related info
.../devicetree/bindings/display/mipi-dsi-bus.txt | 152 -
1 file changed, 145 insertions(+), 7 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode.
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
.../devicetree/bindings/display/mipi-dsi-bus.txt | 77 ++
1 file changed, 77 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 77a7cec15f5b..f556aaafdf22 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,12 @@ Required properties:
- #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
+Optional properties:
+- clock-master: A DSI host controller may be used in conjunction with another
DSI
+ host to drive the same peripheral. Hardware supporting such a configuration
+ generally requires the data on both the busses to be driven by the same
clock.
+ The DSI host instance controlling this clock should contain this property.
+
DSI peripheral
==
@@ -61,6 +67,17 @@ primary control bus, but are also connected to a DSI bus
(mostly for the data
path). Connections between such peripherals and a DSI host can be represented
using the graph bindings [1], [2].
+Peripherals that support dual channel DSI
+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
+
[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -70,6 +87,8 @@ Examples
with different virtual channel configurations.
- (4) is an example of a peripheral on a I2C control bus connected with to
a DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+ which uses I2C as its primary control bus.
1)
dsi-host {
@@ -157,3 +176,61 @@ Examples
};
};
};
+
+5)
+ i2c-host {
+ dsi-bridge@35 {
+ compatible = "...";
+ reg = <0x35>;
+
+ ports {
+ ...
+
+ port@0 {
+ dsi0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ dsi1_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+ };
+
+ dsi0-host {
+ ...
+
+ /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+ clock-master;
+
+ ports {
+ ...
+
+ port@0 {
+ dsi0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ dsi1-host {
+ ...
+
+ ports {
+ ...
+
+ port@0 {
+ dsi1_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dual-channel DSI
On 08/08/14 13:14, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 09:26:17AM +0200, Andrzej Hajda wrote:
>> On 08/07/2014 10:54 AM, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote:
>>>> On 08/07/2014 09:25 AM, Thierry Reding wrote:
>>>>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
>>>>>> Hi Thierry,
>>>>>>
>>>>>> Nice case.
>>>>>>
>>>>>> On 08/05/2014 05:39 PM, Thierry Reding wrote:
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I've been working on adding support for a panel that uses what's
>>>>>>> commonly known as dual-channel DSI. Sometimes this is referred to as
>>>>>>> ganged-mode as well.
>>>>>>>
>>>>>>> What is it, you ask? It's essentially a hack to work around the band-
>>>>>>> width restrictions of DSI, albeit one that's been commonly implemented
>>>>>>> by several SoC vendors.
>>>>>>>
>>>>>>> This typically works by equipping a peripheral with two DSI interfaces,
>>>>>>> each of which driving one half of the screen (symmetric left-right mode)
>>>>>>> or every other line (symmetric odd-even mode). Apparently there can be
>>>>>>> asymmetric modes in addition to those two, but they seem to be the
>>>>>>> common ones. Often both of the DSI interfaces need to be configured
>>>>>>> using DCS commands and vendor specific registers.
>>>>>>>
>>>>>>> A single display controller is typically used video data transmission.
>>>>>>> This is necessary to provide synchronization and avoid tearing and all
>>>>>>> kinds of other ugliness. For this to work both DSI controllers need to
>>>>>>> be made aware of which chunk of the video data stream is addressing
>>>>>>> them.
>>>>>>>
>>>>>>> From a software perspective, this poses two problems:
>>>>>>>
>>>>>>> 1) A dual-channel device is composed of two DSI peripheral devices which
>>>>>>>cannot be programmed independently of each other. A typical example
>>>>>>>is that the frame memory extents need to be configured differently
>>>>>>>for each of the devices (using the DCS set_column_address and
>>>>>>>set_page_address commands). Therefore each device must know of the
>>>>>>>other, or there must be a driver that binds against a dummy device
>>>>>>>that pulls in the two real devices.
I once almost had to write a driver for similar panel, but luckily the project
was canceled. =)
Here are some thoughts:
If we had a panel which is controlled via i2c, but receives the video stream
from two DSI interfaces, I think the DT would look something like:
{
display at 48 {
compatible = "sharp,lq101r1sx01";
reg = <0x48>;
ports {
port at 0 {
reg = <0>;
lcd_in0: endpoint {
remote-endpoint = <_out_ep>;
};
};
port at 1 {
reg = <1>;
lcd_in1: endpoint {
remote-endpoint = <_out_ep>;
};
};
};
};
};
{
port {
dsi1_out_ep: endpoint {
remote-endpoint = <_in0>;
lanes = <0 1 2 3 4 5>;
};
};
};
{
port {
dsi2_out_ep: endpoint {
remote-endpoint = <_in1>;
lanes = <0 1 2 3 4 5>;
};
};
};
And similarly, if the panel would be controlled via DSI, but only via one DSI
interface, I think the DT would look quite similar, except the "display" node
would be a child of "dsi1".
Now, a panel controlled via two DSI interfaces. I have to say the design sounds
rather nasty. What were the HW people thinking about? I guess you are _sure_
that you cannot do the configuration via just a single interface? =)
If you really need the control via two DSI interfaces, I'd suggest something
like this:
{
Dual-channel DSI
Added DT maintainers as we have here quite fundamental DT question: How shall we model hardware connected to multiple buses, in DT? Here we have panel connected to two MIPI-DSI buses. Below is the summary of our propositions, followed by lengthly detailed discussion, including proposed bindings. Current propositions (ordered according to my preferences): 1. Subnode of the first DSI master with phandle to 2nd DSI master. 2. Separate node with phandles to both DSI masters. 3. Two different subnodes of both DSI masters with the same compatible string, and phandle in one node to another one. 4. Two different subnodes of both DSI masters with the same compatible string and separate node with another compatible string with phandles to both DSI subnodes. Notes: - in the first two cases I guess phandles should be accompanied with bus addresses, - here we have two DSI buses but the problem will be similar with other non-discoverable buses, - case of 3 and 4 are original Thierry propositions, if they are preferred I would consider to use different compatible strings for DSI subnodes as they describe different HW interfaces. My additional comments below. On 08/08/2014 12:14 PM, Thierry Reding wrote: > On Fri, Aug 08, 2014 at 09:26:17AM +0200, Andrzej Hajda wrote: >> On 08/07/2014 10:54 AM, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote: >>>> On 08/07/2014 09:25 AM, Thierry Reding wrote: >>>>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote: >>>>>> Hi Thierry, >>>>>> >>>>>> Nice case. >>>>>> >>>>>> On 08/05/2014 05:39 PM, Thierry Reding wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> I've been working on adding support for a panel that uses what's >>>>>>> commonly known as dual-channel DSI. Sometimes this is referred to as >>>>>>> ganged-mode as well. >>>>>>> >>>>>>> What is it, you ask? It's essentially a hack to work around the band- >>>>>>> width restrictions of DSI, albeit one that's been commonly implemented >>>>>>> by several SoC vendors. >>>>>>> >>>>>>> This typically works by equipping a peripheral with two DSI interfaces, >>>>>>> each of which driving one half of the screen (symmetric left-right mode) >>>>>>> or every other line (symmetric odd-even mode). Apparently there can be >>>>>>> asymmetric modes in addition to those two, but they seem to be the >>>>>>> common ones. Often both of the DSI interfaces need to be configured >>>>>>> using DCS commands and vendor specific registers. >>>>>>> >>>>>>> A single display controller is typically used video data transmission. >>>>>>> This is necessary to provide synchronization and avoid tearing and all >>>>>>> kinds of other ugliness. For this to work both DSI controllers need to >>>>>>> be made aware of which chunk of the video data stream is addressing >>>>>>> them. >>>>>>> >>>>>>> From a software perspective, this poses two problems: >>>>>>> >>>>>>> 1) A dual-channel device is composed of two DSI peripheral devices which >>>>>>>cannot be programmed independently of each other. A typical example >>>>>>>is that the frame memory extents need to be configured differently >>>>>>>for each of the devices (using the DCS set_column_address and >>>>>>>set_page_address commands). Therefore each device must know of the >>>>>>>other, or there must be a driver that binds against a dummy device >>>>>>>that pulls in the two real devices. >>>>>> I am not sure if I understand correctly, but I see it rather as one >>>>>> device with two dsi-slave interfaces. Probably panel driver can >>>>>> create dsi dummy device to program some registers >>>>>> via second dsi interface but the panel will be attached to one control >>>>>> bus. >>>>>> It seems to be very similar to mfd/i2c devices with two or more i2c >>>>>> addresses. >>>>> They are in fact attached to two different control busses. The DSI >>>>> controllers that talk to each are separate. On Tegra they are the same >>>>> type of IP block, but still two separate instances (with th
Dual-channel DSI
On Fri, Aug 08, 2014 at 09:26:17AM +0200, Andrzej Hajda wrote: > On 08/07/2014 10:54 AM, Thierry Reding wrote: > > On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote: > >> On 08/07/2014 09:25 AM, Thierry Reding wrote: > >>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote: > >>>> Hi Thierry, > >>>> > >>>> Nice case. > >>>> > >>>> On 08/05/2014 05:39 PM, Thierry Reding wrote: > >>>>> Hi everyone, > >>>>> > >>>>> I've been working on adding support for a panel that uses what's > >>>>> commonly known as dual-channel DSI. Sometimes this is referred to as > >>>>> ganged-mode as well. > >>>>> > >>>>> What is it, you ask? It's essentially a hack to work around the band- > >>>>> width restrictions of DSI, albeit one that's been commonly implemented > >>>>> by several SoC vendors. > >>>>> > >>>>> This typically works by equipping a peripheral with two DSI interfaces, > >>>>> each of which driving one half of the screen (symmetric left-right mode) > >>>>> or every other line (symmetric odd-even mode). Apparently there can be > >>>>> asymmetric modes in addition to those two, but they seem to be the > >>>>> common ones. Often both of the DSI interfaces need to be configured > >>>>> using DCS commands and vendor specific registers. > >>>>> > >>>>> A single display controller is typically used video data transmission. > >>>>> This is necessary to provide synchronization and avoid tearing and all > >>>>> kinds of other ugliness. For this to work both DSI controllers need to > >>>>> be made aware of which chunk of the video data stream is addressing > >>>>> them. > >>>>> > >>>>> From a software perspective, this poses two problems: > >>>>> > >>>>> 1) A dual-channel device is composed of two DSI peripheral devices which > >>>>>cannot be programmed independently of each other. A typical example > >>>>>is that the frame memory extents need to be configured differently > >>>>>for each of the devices (using the DCS set_column_address and > >>>>>set_page_address commands). Therefore each device must know of the > >>>>>other, or there must be a driver that binds against a dummy device > >>>>>that pulls in the two real devices. > >>>> I am not sure if I understand correctly, but I see it rather as one > >>>> device with two dsi-slave interfaces. Probably panel driver can > >>>> create dsi dummy device to program some registers > >>>> via second dsi interface but the panel will be attached to one control > >>>> bus. > >>>> It seems to be very similar to mfd/i2c devices with two or more i2c > >>>> addresses. > >>> They are in fact attached to two different control busses. The DSI > >>> controllers that talk to each are separate. On Tegra they are the same > >>> type of IP block, but still two separate instances (with their own > >>> clock, reset, etc. inputs). > >>> > >>> So the panel driver can't create a dummy device to talk to the second > >>> DSI interface because the second DSI interface uses a different DSI > >>> host. > >> Why different DSI host does not allow that? The only thing panel needs > >> is the reference to another DSI host and this can be provided via > >> DT direct phandle or video interface. > > I'm sure one could find ways to make it work. That doesn't mean it's a > > good idea, though. The second peripheral is physically there on the > > second DSI host controller's bus, so it the device should be in device > > tree because so that the device tree matches reality. > > The question is what is the reality? Do we have two separate dsi > devices? In such case > both devices should appear in DT. > If we have single device attached to two different DSI hosts I suppose > device should appear > only in one location in DT with link to another DSI host. Doesn't the fact that both devices are connected to different DSI hosts make them separate device? While it's physically one device only (there is one panel), device tree defines devices in terms of the control bus that they are connected to. Since in this case both subdevices are
Dual-channel DSI
On 08/07/2014 10:54 AM, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote: >> On 08/07/2014 09:25 AM, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote: >>>> Hi Thierry, >>>> >>>> Nice case. >>>> >>>> On 08/05/2014 05:39 PM, Thierry Reding wrote: >>>>> Hi everyone, >>>>> >>>>> I've been working on adding support for a panel that uses what's >>>>> commonly known as dual-channel DSI. Sometimes this is referred to as >>>>> ganged-mode as well. >>>>> >>>>> What is it, you ask? It's essentially a hack to work around the band- >>>>> width restrictions of DSI, albeit one that's been commonly implemented >>>>> by several SoC vendors. >>>>> >>>>> This typically works by equipping a peripheral with two DSI interfaces, >>>>> each of which driving one half of the screen (symmetric left-right mode) >>>>> or every other line (symmetric odd-even mode). Apparently there can be >>>>> asymmetric modes in addition to those two, but they seem to be the >>>>> common ones. Often both of the DSI interfaces need to be configured >>>>> using DCS commands and vendor specific registers. >>>>> >>>>> A single display controller is typically used video data transmission. >>>>> This is necessary to provide synchronization and avoid tearing and all >>>>> kinds of other ugliness. For this to work both DSI controllers need to >>>>> be made aware of which chunk of the video data stream is addressing >>>>> them. >>>>> >>>>> From a software perspective, this poses two problems: >>>>> >>>>> 1) A dual-channel device is composed of two DSI peripheral devices which >>>>>cannot be programmed independently of each other. A typical example >>>>>is that the frame memory extents need to be configured differently >>>>>for each of the devices (using the DCS set_column_address and >>>>>set_page_address commands). Therefore each device must know of the >>>>>other, or there must be a driver that binds against a dummy device >>>>>that pulls in the two real devices. >>>> I am not sure if I understand correctly, but I see it rather as one >>>> device with two dsi-slave interfaces. Probably panel driver can >>>> create dsi dummy device to program some registers >>>> via second dsi interface but the panel will be attached to one control bus. >>>> It seems to be very similar to mfd/i2c devices with two or more i2c >>>> addresses. >>> They are in fact attached to two different control busses. The DSI >>> controllers that talk to each are separate. On Tegra they are the same >>> type of IP block, but still two separate instances (with their own >>> clock, reset, etc. inputs). >>> >>> So the panel driver can't create a dummy device to talk to the second >>> DSI interface because the second DSI interface uses a different DSI >>> host. >> Why different DSI host does not allow that? The only thing panel needs >> is the reference to another DSI host and this can be provided via >> DT direct phandle or video interface. > I'm sure one could find ways to make it work. That doesn't mean it's a > good idea, though. The second peripheral is physically there on the > second DSI host controller's bus, so it the device should be in device > tree because so that the device tree matches reality. The question is what is the reality? Do we have two separate dsi devices? In such case both devices should appear in DT. If we have single device attached to two different DSI hosts I suppose device should appear only in one location in DT with link to another DSI host. > >>>>> 2) On the DSI host side, each of the controller instances needs to know >>>>>the intimate details of the other controller (or alternatively, one >>>>>controller needs to be a "master" and the other a "slave"). >>>> The question is if they need to communicate each other, or they have >>>> to have similar configurations applied? >>> On Tegra at least the configuration needs to be almost the same. There >>> are two registers that may need to be programmed differently. But they >>> don't have to communicate with each other. Essentially the two registers >>> that req
Dual-channel DSI
On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote: > On 08/07/2014 09:25 AM, Thierry Reding wrote: > > On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote: > >> Hi Thierry, > >> > >> Nice case. > >> > >> On 08/05/2014 05:39 PM, Thierry Reding wrote: > >>> Hi everyone, > >>> > >>> I've been working on adding support for a panel that uses what's > >>> commonly known as dual-channel DSI. Sometimes this is referred to as > >>> ganged-mode as well. > >>> > >>> What is it, you ask? It's essentially a hack to work around the band- > >>> width restrictions of DSI, albeit one that's been commonly implemented > >>> by several SoC vendors. > >>> > >>> This typically works by equipping a peripheral with two DSI interfaces, > >>> each of which driving one half of the screen (symmetric left-right mode) > >>> or every other line (symmetric odd-even mode). Apparently there can be > >>> asymmetric modes in addition to those two, but they seem to be the > >>> common ones. Often both of the DSI interfaces need to be configured > >>> using DCS commands and vendor specific registers. > >>> > >>> A single display controller is typically used video data transmission. > >>> This is necessary to provide synchronization and avoid tearing and all > >>> kinds of other ugliness. For this to work both DSI controllers need to > >>> be made aware of which chunk of the video data stream is addressing > >>> them. > >>> > >>> From a software perspective, this poses two problems: > >>> > >>> 1) A dual-channel device is composed of two DSI peripheral devices which > >>>cannot be programmed independently of each other. A typical example > >>>is that the frame memory extents need to be configured differently > >>>for each of the devices (using the DCS set_column_address and > >>>set_page_address commands). Therefore each device must know of the > >>>other, or there must be a driver that binds against a dummy device > >>>that pulls in the two real devices. > >> I am not sure if I understand correctly, but I see it rather as one > >> device with two dsi-slave interfaces. Probably panel driver can > >> create dsi dummy device to program some registers > >> via second dsi interface but the panel will be attached to one control bus. > >> It seems to be very similar to mfd/i2c devices with two or more i2c > >> addresses. > > They are in fact attached to two different control busses. The DSI > > controllers that talk to each are separate. On Tegra they are the same > > type of IP block, but still two separate instances (with their own > > clock, reset, etc. inputs). > > > > So the panel driver can't create a dummy device to talk to the second > > DSI interface because the second DSI interface uses a different DSI > > host. > > Why different DSI host does not allow that? The only thing panel needs > is the reference to another DSI host and this can be provided via > DT direct phandle or video interface. I'm sure one could find ways to make it work. That doesn't mean it's a good idea, though. The second peripheral is physically there on the second DSI host controller's bus, so it the device should be in device tree because so that the device tree matches reality. > >>> 2) On the DSI host side, each of the controller instances needs to know > >>>the intimate details of the other controller (or alternatively, one > >>>controller needs to be a "master" and the other a "slave"). > >> The question is if they need to communicate each other, or they have > >> to have similar configurations applied? > > On Tegra at least the configuration needs to be almost the same. There > > are two registers that may need to be programmed differently. But they > > don't have to communicate with each other. Essentially the two registers > > that require different programming define which parts of the display > > controller's data stream they need to capture and turn into DSI packets. > > > > Theoretically it would be possible to make this work with two completely > > different DSI controllers, but in practice I'd expect that to never > > happen. So I'm not sure we need to consider the case where the register > > layout is different between the two DSI host controllers. > > So maybe the configuration could be provided by the panel. W
Dual-channel DSI
On 08/07/2014 09:25 AM, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
>> Hi Thierry,
>>
>> Nice case.
>>
>> On 08/05/2014 05:39 PM, Thierry Reding wrote:
>>> Hi everyone,
>>>
>>> I've been working on adding support for a panel that uses what's
>>> commonly known as dual-channel DSI. Sometimes this is referred to as
>>> ganged-mode as well.
>>>
>>> What is it, you ask? It's essentially a hack to work around the band-
>>> width restrictions of DSI, albeit one that's been commonly implemented
>>> by several SoC vendors.
>>>
>>> This typically works by equipping a peripheral with two DSI interfaces,
>>> each of which driving one half of the screen (symmetric left-right mode)
>>> or every other line (symmetric odd-even mode). Apparently there can be
>>> asymmetric modes in addition to those two, but they seem to be the
>>> common ones. Often both of the DSI interfaces need to be configured
>>> using DCS commands and vendor specific registers.
>>>
>>> A single display controller is typically used video data transmission.
>>> This is necessary to provide synchronization and avoid tearing and all
>>> kinds of other ugliness. For this to work both DSI controllers need to
>>> be made aware of which chunk of the video data stream is addressing
>>> them.
>>>
>>> From a software perspective, this poses two problems:
>>>
>>> 1) A dual-channel device is composed of two DSI peripheral devices which
>>>cannot be programmed independently of each other. A typical example
>>>is that the frame memory extents need to be configured differently
>>>for each of the devices (using the DCS set_column_address and
>>>set_page_address commands). Therefore each device must know of the
>>>other, or there must be a driver that binds against a dummy device
>>>that pulls in the two real devices.
>> I am not sure if I understand correctly, but I see it rather as one
>> device with two dsi-slave interfaces. Probably panel driver can
>> create dsi dummy device to program some registers
>> via second dsi interface but the panel will be attached to one control bus.
>> It seems to be very similar to mfd/i2c devices with two or more i2c
>> addresses.
> They are in fact attached to two different control busses. The DSI
> controllers that talk to each are separate. On Tegra they are the same
> type of IP block, but still two separate instances (with their own
> clock, reset, etc. inputs).
>
> So the panel driver can't create a dummy device to talk to the second
> DSI interface because the second DSI interface uses a different DSI
> host.
Why different DSI host does not allow that? The only thing panel needs
is the reference to another DSI host and this can be provided via
DT direct phandle or video interface.
>
>>> 2) On the DSI host side, each of the controller instances needs to know
>>>the intimate details of the other controller (or alternatively, one
>>>controller needs to be a "master" and the other a "slave").
>> The question is if they need to communicate each other, or they have
>> to have similar configurations applied?
> On Tegra at least the configuration needs to be almost the same. There
> are two registers that may need to be programmed differently. But they
> don't have to communicate with each other. Essentially the two registers
> that require different programming define which parts of the display
> controller's data stream they need to capture and turn into DSI packets.
>
> Theoretically it would be possible to make this work with two completely
> different DSI controllers, but in practice I'd expect that to never
> happen. So I'm not sure we need to consider the case where the register
> layout is different between the two DSI host controllers.
So maybe the configuration could be provided by the panel.
>
>>> I'm looking for feedback on how this is handled on other SoCs, hence
>>> adding a few people that I know are working on DSI as well (or have in
>>> the past). If you know of any other people that might have useful advice
>>> on this topic, feel free to include them.
>>>
>>> Another goal of this discussion is to come up with a somewhat standard
>>> way to represent this in device tree (oh no!) so that panels can be
>>> easily reused on different SoCs.
>>>
>>> What I currently have for Tegra is something along these lines:
>>>
>>> dsi at 5430 {
>>>
Dual-channel DSI
On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
> Hi Thierry,
>
> Nice case.
>
> On 08/05/2014 05:39 PM, Thierry Reding wrote:
> > Hi everyone,
> >
> > I've been working on adding support for a panel that uses what's
> > commonly known as dual-channel DSI. Sometimes this is referred to as
> > ganged-mode as well.
> >
> > What is it, you ask? It's essentially a hack to work around the band-
> > width restrictions of DSI, albeit one that's been commonly implemented
> > by several SoC vendors.
> >
> > This typically works by equipping a peripheral with two DSI interfaces,
> > each of which driving one half of the screen (symmetric left-right mode)
> > or every other line (symmetric odd-even mode). Apparently there can be
> > asymmetric modes in addition to those two, but they seem to be the
> > common ones. Often both of the DSI interfaces need to be configured
> > using DCS commands and vendor specific registers.
> >
> > A single display controller is typically used video data transmission.
> > This is necessary to provide synchronization and avoid tearing and all
> > kinds of other ugliness. For this to work both DSI controllers need to
> > be made aware of which chunk of the video data stream is addressing
> > them.
> >
> > From a software perspective, this poses two problems:
> >
> > 1) A dual-channel device is composed of two DSI peripheral devices which
> >cannot be programmed independently of each other. A typical example
> >is that the frame memory extents need to be configured differently
> >for each of the devices (using the DCS set_column_address and
> >set_page_address commands). Therefore each device must know of the
> >other, or there must be a driver that binds against a dummy device
> >that pulls in the two real devices.
>
> I am not sure if I understand correctly, but I see it rather as one
> device with two dsi-slave interfaces. Probably panel driver can
> create dsi dummy device to program some registers
> via second dsi interface but the panel will be attached to one control bus.
> It seems to be very similar to mfd/i2c devices with two or more i2c
> addresses.
They are in fact attached to two different control busses. The DSI
controllers that talk to each are separate. On Tegra they are the same
type of IP block, but still two separate instances (with their own
clock, reset, etc. inputs).
So the panel driver can't create a dummy device to talk to the second
DSI interface because the second DSI interface uses a different DSI
host.
> > 2) On the DSI host side, each of the controller instances needs to know
> >the intimate details of the other controller (or alternatively, one
> >controller needs to be a "master" and the other a "slave").
>
> The question is if they need to communicate each other, or they have
> to have similar configurations applied?
On Tegra at least the configuration needs to be almost the same. There
are two registers that may need to be programmed differently. But they
don't have to communicate with each other. Essentially the two registers
that require different programming define which parts of the display
controller's data stream they need to capture and turn into DSI packets.
Theoretically it would be possible to make this work with two completely
different DSI controllers, but in practice I'd expect that to never
happen. So I'm not sure we need to consider the case where the register
layout is different between the two DSI host controllers.
> > I'm looking for feedback on how this is handled on other SoCs, hence
> > adding a few people that I know are working on DSI as well (or have in
> > the past). If you know of any other people that might have useful advice
> > on this topic, feel free to include them.
> >
> > Another goal of this discussion is to come up with a somewhat standard
> > way to represent this in device tree (oh no!) so that panels can be
> > easily reused on different SoCs.
> >
> > What I currently have for Tegra is something along these lines:
> >
> > dsi at 5430 {
> > nvidia,ganged-mode = <>;
> >
> > panel at 0 {
> > compatible = "sharp,lq101r1sx01";
> > reg = <0>;
> >
> > secondary = <>;
> > };
> > };
> >
> > dsib: dsi at 5440 {
> > nvidia,ganged-mode;
> >
> > secondary: panel at 0 {
> > reg = <0>;
> > };
> > };
> >
> > There a
Dual-channel DSI
Hi Thierry,
Nice case.
On 08/05/2014 05:39 PM, Thierry Reding wrote:
> Hi everyone,
>
> I've been working on adding support for a panel that uses what's
> commonly known as dual-channel DSI. Sometimes this is referred to as
> ganged-mode as well.
>
> What is it, you ask? It's essentially a hack to work around the band-
> width restrictions of DSI, albeit one that's been commonly implemented
> by several SoC vendors.
>
> This typically works by equipping a peripheral with two DSI interfaces,
> each of which driving one half of the screen (symmetric left-right mode)
> or every other line (symmetric odd-even mode). Apparently there can be
> asymmetric modes in addition to those two, but they seem to be the
> common ones. Often both of the DSI interfaces need to be configured
> using DCS commands and vendor specific registers.
>
> A single display controller is typically used video data transmission.
> This is necessary to provide synchronization and avoid tearing and all
> kinds of other ugliness. For this to work both DSI controllers need to
> be made aware of which chunk of the video data stream is addressing
> them.
>
> From a software perspective, this poses two problems:
>
> 1) A dual-channel device is composed of two DSI peripheral devices which
>cannot be programmed independently of each other. A typical example
>is that the frame memory extents need to be configured differently
>for each of the devices (using the DCS set_column_address and
>set_page_address commands). Therefore each device must know of the
>other, or there must be a driver that binds against a dummy device
>that pulls in the two real devices.
I am not sure if I understand correctly, but I see it rather as one
device with two dsi-slave interfaces. Probably panel driver can
create dsi dummy device to program some registers
via second dsi interface but the panel will be attached to one control bus.
It seems to be very similar to mfd/i2c devices with two or more i2c
addresses.
>
> 2) On the DSI host side, each of the controller instances needs to know
>the intimate details of the other controller (or alternatively, one
>controller needs to be a "master" and the other a "slave").
The question is if they need to communicate each other, or they have
to have similar configurations applied?
>
> I'm looking for feedback on how this is handled on other SoCs, hence
> adding a few people that I know are working on DSI as well (or have in
> the past). If you know of any other people that might have useful advice
> on this topic, feel free to include them.
>
> Another goal of this discussion is to come up with a somewhat standard
> way to represent this in device tree (oh no!) so that panels can be
> easily reused on different SoCs.
>
> What I currently have for Tegra is something along these lines:
>
> dsi at 5430 {
> nvidia,ganged-mode = <>;
>
> panel at 0 {
> compatible = "sharp,lq101r1sx01";
> reg = <0>;
>
> secondary = <>;
> };
> };
>
> dsib: dsi at 5440 {
> nvidia,ganged-mode;
>
> secondary: panel at 0 {
> reg = <0>;
> };
> };
>
> There are a couple of other properties in those nodes, such as
> regulators and such, but I've omitted them so that the discussion can
> focus on the important bits.
>
> In the above the panel driver will bind against dsi at 5430/panel at 0 and
> use the "secondary" property to obtain a reference to the DSI peripheral
> device of the second DSI interface of the device.
>
> Similarly, the dsi at 5430 primary DSI host will obtain a reference to
> a "slave" DSI host via the "nvidia,ganged-mode" property. The secondary
> DSI host dsi at 5440 will know that it's not a fully functional DSI
> output by the presence of the empty "nvidia,ganged-mode" property.
>
> Using the above I can get things to work, but it seems somewhat kludgy.
> For example it assumes that both DSI hosts are the same type. I'm not
> sure if it makes sense for dual-channel to use completely different DSI
> hosts given that they need to be very tightly coupled (take input from
> the same display controller, use the same PLL, ...). It's also kind of
> redundant to have to specify the dual relationship twice (once for the
> peripheral and once for the DSI hosts). There's also the issue that we
> should really be specifying a compatible string for the secondary
> instance of the DSI peripheral, but that would mean that it will bind
> again
Dual-channel DSI
Hi everyone, I've been working on adding support for a panel that uses what's commonly known as dual-channel DSI. Sometimes this is referred to as ganged-mode as well. What is it, you ask? It's essentially a hack to work around the band- width restrictions of DSI, albeit one that's been commonly implemented by several SoC vendors. This typically works by equipping a peripheral with two DSI interfaces, each of which driving one half of the screen (symmetric left-right mode) or every other line (symmetric odd-even mode). Apparently there can be asymmetric modes in addition to those two, but they seem to be the common ones. Often both of the DSI interfaces need to be configured using DCS commands and vendor specific registers. A single display controller is typically used video data transmission. This is necessary to provide synchronization and avoid tearing and all kinds of other ugliness. For this to work both DSI controllers need to be made aware of which chunk of the video data stream is addressing them.
