Thread (19 messages) flat view 19 messages, 6 authors, 2017-10-23

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

From: Matthias Brugger <hidden>
Date: 2017-10-19 15:11:38
Also in: dri-devel, linux-arm-kernel, linux-mediatek, lkml


On 10/19/2017 03:06 PM, Philipp Zabel wrote:
On Thu, 2017-10-19 at 15:53 +0300, Laurent Pinchart wrote:
quoted
Hi Matthias,

Thank you for the patch.

On Thursday, 19 October 2017 14:26:07 EEST Matthias Brugger wrote:
quoted
DRM subysystem and clock driver shared the same compatible mmsys.
This stopped does not work, as only the first driver for a compatible
gets probed. We change the comaptible to the new DRM identifier to fix
this.

Signed-off-by: Matthias Brugger <mbrugger-IBi9RG/b67k@public.gmane.org>
---
 .../devicetree/bindings/display/mediatek/mediatek,disp.txt          | 6 +++
 1 file changed, 6 insertions(+)

diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 383183a89164..6db652463e64 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -27,6 +27,7 @@
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.

 Required properties (all function blocks):
 - compatible: "mediatek,<chip>-disp-<function>", one of
+	"mediatek,<chip>-dispsys"    - central component for the DRM system
 	"mediatek,<chip>-disp-ovl"   - overlay (4 layers, blending, csc)
 	"mediatek,<chip>-disp-rdma"  - read DMA / line buffer
 	"mediatek,<chip>-disp-wdma"  - write DMA
@@ -71,6 +72,11 @@ mmsys: clock-controller@14000000 {
 	#clock-cells = <1>;
 };

+dispsys: display-system {
+	compatible = "mediatek,mt2701-dispsys";
+	mediatek,mmsys = <&mmsys>;
+}
So this node doesn't correspond to an IP core but is meant as a top-level 
entry point for the operating system. This leads me to three questions.

1. Is there any IP core in the Mediatek display subsystem that could be 
considered (or at least used) as a top-level entry point ? That would be my 
preferred solution as I'm not fond of DT nodes not describing hardware.
At least on MT8173 that node is MMSYS, which it is currently matching
against. The issue, if I understand correctly, is that the clocks
provided by this same region were previously created via CLK_OF_DECLARE,
and are now changed to a separate clock driver that matches to the same 
node.
Exactly that seems to be the problem we hit. I have to setup my chromebook to do
some changes, but that won't happen before the week after next week.

So yes, the MMSYS is the top-level-entry point for the display subsystem, the
clocks in mmsys are just a small part of the whole register block. I will cite
the cover letter which unfortunately wasn't send, because I broke my email setup:
"Possible solutions:
1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a simple-mfd
under the actual mmsys node. We change the clock driver to probe on this
binding. This would make sense as the clock gate register live completely in
the MMSYS configuration registers.

2) As the nodes of the DRM subsystem just need some of the registers of MMSYS
we add a new binding mediatek,mt8173-dispsys which probes the central
component of the DRM system. It has only a handle to mt8173-mmsys to access
the registerspace via regmap functions."

So this patch set implemented solution 2).

quoted
2. If there's no such IP core, are all the display subsystem IP cores grouped 
together in one MMIO register range ? If so we could move them as children of 
this new display system node which, even if doesn't describe an IP core, would 
describe the way the display IP cores are grouped in the hardware, and would 
thus be a hardware description.
They are all mapped somewhere at 140xxxxx. But there are other components which
are used by other HW blocks smi_common especially. So I'm not sure which impact
that move would have.

The MMSYS for mt8173 actually enables the overlays and set's the multiplexer for
the output path. Does this make sense? It's the first time I've a deeper look in
such a driver, so maybe I don't grasp everything.

Regards,
Matthias
quoted
3. If the answer to the second question is also negative, shouldn't this 
display system node reference all other display IP DT nodes (through direct 
phandles and/or OF graph bindings) ?
quoted
 ovl0: ovl@1400c000 {
 	compatible = "mediatek,mt8173-disp-ovl";
 	reg = <0 0x1400c000 0 0x1000>;
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help