T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

K. James

unread,

Dec 26, 2023, 10:07:26 PM12/26/23

to linux-sunxi

Hi All,

Been working on getting T113-s3 on mainline as I prepare to update a project from a v3s. One of the benefits has been the ability to move from a 18bit RGB LCD to a MIPI-DSI display, with the interface available on the T113-s3 , which has given some better display choices.

The DSI driver was on mainline from 6.2, however building from sources on init I am getting the following error:

"sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

Its tripping at the following init in sun6i_mipi_dsi.c

if (variant->has_mod_clk) { dsi->mod_clk = devm_clk_get(dev, "mod"); if (IS_ERR(dsi->mod_clk)) { dev_err(dev, "Couldn't get the DSI mod clock\n"); ret = PTR_ERR(dsi->mod_clk); goto err_attach_clk; }

The display modclock is registered from the following DTS node in sunxi-d1s-t113.dtsi

display_clocks: clock-controller@5000000 { compatible = "allwinner,sun20i-d1-de2-clk", "allwinner,sun50i-h5-de2-clk"; reg = <0x5000000 0x10000>; clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>; clock-names = "bus", "mod"; resets = <&ccu RST_BUS_DE>; #clock-cells = <1>; #reset-cells = <1>;

};

I checked the buildroot config and the CCU for sun8i DE2 is being built and included, the registration should occur and give an exception if it's not happening: ccu-sun8i-de2.c

mod_clk = devm_clk_get(&pdev->dev, "mod"); if (IS_ERR(mod_clk)) return dev_err_probe(&pdev->dev, PTR_ERR(mod_clk), "Couldn't get mod clk\n");

ret = clk_prepare_enable(mod_clk); if (ret) { dev_err(&pdev->dev, "Couldn't enable mod clk: %d\n", ret); goto err_disable_bus_clk; }

I don't see dmesg print any clock errors, but at the same time, I understand that linux common clock framework also won't print anything by default.

I can't see anything in either driver that would cause an error other than the clock not existing, if anyone has any ideas - i'm all ears.

At the moment I am leaning towards the clock-controller; Is there a userspace or debug option to check (mod) clock status' under the common clock framework?

Thanks

Andre Przywara

unread,

Dec 27, 2023, 6:29:09 PM12/27/23

to K. James, linux-sunxi

On Tue, 26 Dec 2023 19:00:58 -0800 (PST)
"K. James" <kirby.n...@gmail.com> wrote:

Hi,

please try to avoid HTML email on lists, that makes it hard to reply
inline and messes up the text view - and there is little need to provide
links to every identifier anyway.

> Hi All,
>
> Been working on getting T113-s3 on mainline as I prepare to update a
> project from a v3s. One of the benefits has been the ability to move from a
> 18bit RGB LCD to a MIPI-DSI display, with the interface available on the
> T113-s3 , which has given some better display choices.
>
> The DSI driver was on mainline from 6.2, however building from sources on
> init I am getting the following error:
>

> *"sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"*

>
> Its tripping at the following init in sun6i_mipi_dsi.c

> <https://elixir.bootlin.com/linux/v6.6.2/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L1155>

>
>
> if (variant-> has_mod_clk) {
> dsi->mod_clk = devm_clk_get(dev, "mod");

> if (IS_ERR (dsi->mod_clk)) {

> dev_err(dev, "Couldn't get the DSI mod clock\n");
> ret = PTR_ERR(dsi->mod_clk);
> goto err_attach_clk;
>}

But since this comes from the DSI driver, this refers to the DT node of
the DSI device, not the DE2 clock, doesn't it?

> The display modclock is registered from the following DTS node in
> sunxi-d1s-t113.dtsi

> <https://elixir.bootlin.com/linux/v6.6.2/source/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi#L641>

>
>
> display_clocks: clock-controller@5000000 {
> compatible = "allwinner,sun20i-d1-de2-clk",
> "allwinner,sun50i-h5-de2-clk";
> reg = <0x5000000 0x10000>;
> clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>;

> clock-names = "bus", *"mod"*;

> resets = <&ccu RST_BUS_DE>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> };

So those are the clocks from:
dsi: dsi@5450000 {
...
clocks = <&ccu CLK_BUS_MIPI_DSI>,
<&tcon_top CLK_TCON_TOP_DSI>;

clock-names = "bus", "mod";

...
};

So the "mod" clock here points to the tcon_top device, the one with the
"allwinner,sun20i-d1-tcon-top" compatible string. Which is implemented
by drivers/gpu/drm/sun4i/sun8i_tcon_top.c, controlled by the
DRM_SUN8I_TCON_TOP Kconfig symbol. Do you have that enabled?

You can check /sys/kernel/debug/clk/clk_summary (with debugfs mounted)
to see what clocks are there and how they are used.

Cheers,
Andre

> I checked the buildroot config and the CCU for sun8i DE2 is being
> built and included, the registration should occur and give an
> exception if it's not happening: ccu-sun8i-de2.c

> <https://elixir.bootlin.com/linux/v6.6.2/source/drivers/clk/sunxi-ng/ccu-sun8i-de2.c#L263>
>
> mod_clk <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk> =
> devm_clk_get
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/devm_clk_get>(
> &pdev->dev, "mod"); if (IS_ERR
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/IS_ERR>(mod_clk
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>)) return
> dev_err_probe
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/dev_err_probe>(&pdev->dev,
> PTR_ERR
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/PTR_ERR>(mod_clk
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>), "Couldn't

> get mod clk\n");
>
> ret = clk_prepare_enable

> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/clk_prepare_enable>(mod_clk
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>); if (ret)
> { dev_err
> <https://elixir.bootlin.com/linux/v6.6.2/C/ident/dev_err>(&pdev->dev

K. James

unread,

Dec 28, 2023, 9:48:37 PM12/28/23

to linux-sunxi

Hi,

Apologies for the bad etiquette - I didn't realise the copy paste from bootlin would put so much HTML. I will strip the formatting from my messages in the future.
I am away from my desk and devkit for a few days, but I think I could have narrowed it down to two issues:

1) Clock is wrong source - according to the device tree the mod clock for the DSI interface is from TCON_TOP as you mention, and from the patchset "[PATCH v2 1/4] dt-bindings: display: sun6i-dsi: Fix clock conditional"
Samuel makes the following point: "the module clock routes through the TCON TOP".

the device tree has the following:

dsi: dsi@5450000 {
compatible = "allwinner,sun20i-d1-mipi-dsi",
"allwinner,sun50i-a100-mipi-dsi";
reg = <0x5450000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;

clocks = <&ccu CLK_BUS_MIPI_DSI>,
<&tcon_top CLK_TCON_TOP_DSI>;
clock-names = "bus", "mod";

resets = <&ccu RST_BUS_MIPI_DSI>;
phys = <&dphy>;
phy-names = "dphy";
status = "disabled";
};

dphy: phy@5451000 {
compatible = "allwinner,sun20i-d1-mipi-dphy",
"allwinner,sun50i-a100-mipi-dphy";
reg = <0x5451000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;

clocks = <&ccu CLK_BUS_MIPI_DSI>,

<&ccu CLK_MIPI_DSI>;

clock-names = "bus", "mod";

resets = <&ccu RST_BUS_MIPI_DSI>;
#phy-cells = <0>;
};

In this case the DPHY is getting its clock from the CCU node "CLK_MIPI_DSI" instead of TCON TOP, so one of the following cases could be true:

> The DSI node should get its mod clock from CCU CLK_MIPI_DSI and the TCON_TOP CLK_TCON_TOP_DSI clock source is incorrect, or
> The DPHY should get its mod clock from TCON_TOP CLK_TCON_TOP_DSI and the ccu CLK_MIPI_DSI source is incorrect, or
> These clock sources are correct and there is some other issue (such as below).

2) alternatively, it could be just a quirk of the D1/T113 TCON TOP setup.

I also had found this in reviewing the devicetree for this board - the patchset "[PATCH v2 00/14] drm/sun4i: Allwinner D1 Display Engine 2.0 Support" includes the TCON Top Support the following note:

[PATCH v2 12/14] drm/sun4i: Add support for D1 TCON TOP
"D1 has a TCON TOP with TCON TV0 and DSI, but no TCON TV1. This puts theDSI clock name at index 1 in clock-output-names. Support this by only incrementing the index for clocks that are actually supported."

But reviewing the DSI node:

dsi: dsi@5450000 {
compatible = "allwinner,sun20i-d1-mipi-dsi",
"allwinner,sun50i-a100-mipi-dsi";
reg = <0x5450000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;

clocks = <&ccu CLK_BUS_MIPI_DSI>,
<&tcon_top CLK_TCON_TOP_DSI>;
clock-names = "bus", "mod";

resets = <&ccu RST_BUS_MIPI_DSI>;
phys = <&dphy>;
phy-names = "dphy";
status = "disabled";

the definition of CLK_TCON_TOP_DSI comes from sun8i-tcon-top.h:

/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
/* Copyright (C) 2018 Jernej Skrabec <jernej....@siol.net> */

#ifndef _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
#define _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_

#define CLK_TCON_TOP_TV0 0
#define CLK_TCON_TOP_TV1 1
#define CLK_TCON_TOP_DSI 2

#endif /* _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ */

I believe, if that the quirk of the D1s correct to the above comment, the incorrect clock index is being selected in the devicetree which would also cause the failure.

In which case:

clocks = <&ccu CLK_BUS_MIPI_DSI>, <&tcon_top 1>;

clock-names = "bus", "mod";

would be a sufficient fix without updating the header/source.

Either case as soon as I am back with my devkit, I would try this for sure and try and see if I can find an answer.

>You can check /sys/kernel/debug/clk/clk_summary (with debugfs mounted)
>to see what clocks are there and how they are used

Also great information, I will test.

Regards,

Jakob L

unread,

Dec 30, 2023, 1:12:32 AM12/30/23

to linux-sunxi

Hello James and Andrew,

i was recently also tryting to get mipi dsi to work on T113-S3 - with the same error.
These days i was going to compare register setting between mainline kernel and bsp u-boot.

But this here came early and i was able to try the options.
The LCD i use works on A64 and also works with these timings on allwinner kernel on my T113 board.

On T113 the Low power mode of DSI works - i can send the init code. Verified that with oscilloscope and test patterns on LCD.
Then the lanes are dead and do not have the right level afair.

I used Kernel 6.5.7. DRM_SUN8I_TCON_TOP is enabled

With MangoPi dts as base and the following nodes:

+&de {
+ status = "okay";
+};
+
+&dsi {
+ pinctrl-0 = <&dsi_4lane_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ panel: panel@0 {
+ reg = <0>;
+ compatible = "jnj,7i";
+ pinctrl-names = "default";
+ reset-gpios = <&pio 3 20 GPIO_ACTIVE_HIGH>;
+
+ // pinctrl-0 = <&panel_pin>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&tcon_lcd0_out_dsi>;
+ };
+ };
+
+ };
+};
+
+&dphy {
+ status = "okay";
+};

Option2 No Luck

@@ -655,7 +655,7 @@ dsi: dsi@5450000 {

reg = <0x5450000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_MIPI_DSI>,

- <&tcon_top CLK_TCON_TOP_DSI>;
+ <&tcon_top 1>;

I had a feeling option 2 has something to do with it. But the patched kernel shows the same error.

sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock

Option1 A

@@ -655,7 +655,7 @@ dsi: dsi@5450000 {

reg = <0x5450000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_MIPI_DSI>,

- <&tcon_top CLK_TCON_TOP_DSI>;
+ <&ccu CLK_MIPI_DSI>;

With this patch i am no longer getting the modclock error. But i am not getting an image either.

Unfortunatly i do not have my oscilloscope with me. So i cannot check if there is a signal, but i guess not.

Option1 B

@@ -675,7 +675,7 @@ dphy: phy@5451000 {

reg = <0x5451000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_MIPI_DSI>,

- <&ccu CLK_MIPI_DSI>;
+ <&tcon_top CLK_TCON_TOP_DSI>;

This is not ok either.

sun6i-mipi-dphy 5451000.phy: Couldn't get the DPHY mod clock

sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock

Ultimatly i tested to use Option 2 with Option 1. So both DSI and PHY get the modclock from top, but with the right index.

@@ -655,7 +655,7 @@ dsi: dsi@5450000 {

reg = <0x5450000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_MIPI_DSI>,

- <&tcon_top CLK_TCON_TOP_DSI>;
+ <&tcon_top 1>;

clock-names = "bus", "mod";

resets = <&ccu RST_BUS_MIPI_DSI>;
phys = <&dphy>;

@@ -675,7 +675,7 @@ dphy: phy@5451000 {

reg = <0x5451000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_MIPI_DSI>,

- <&ccu CLK_MIPI_DSI>;
+ <&tcon_top 1>;

clock-names = "bus", "mod";

resets = <&ccu RST_BUS_MIPI_DSI>;
#phy-cells = <0>;

sun6i-mipi-dphy 5451000.phy: Couldn't get the DPHY mod clock

sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock

So all options are not working. I will check some more tomorrow. If you have another idea - i would be happy to test.,

All the best

Jakob

Kirby Nankivell

unread,

Dec 30, 2023, 2:05:56 AM12/30/23

to jakob...@gmail.com, linux-sunxi

Hey Jakob,

Ok, nice to know there is someone else working to solve the same problem, I saw some other guys having similar issues on the IRC channel.

Shame it was not something obvious like clock index didn't solve it straight away, but Option 1A seems like it could be part of the solution - at least it was init without error

Pinctrl looks ok too, I don't think it should matter if it's under the dsi, dphy or tcon node - and no pinctrl assertion errors I presume?
but if you have a chance to scope the lanes might give us some indication if we are anything looking correct with the working clock config.

Worth checking /sys/kernel/debug/clk/clk_summary (with debugfs mounted) to see if we can identify the clock sources

I don't think the tcon print out any debug messages at the default level, maybe increase the console loglevel and pastebin your full dmesg?

--
You received this message because you are subscribed to a topic in the Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/HxDBpY5HbbQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to linux-sunxi...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/02e9453d-7335-4499-933b-ac5038e41bbcn%40googlegroups.com.

Jakob L

unread,

Dec 30, 2023, 4:53:46 PM12/30/23

to linux-sunxi

Hello James,

yes indeed. I also was pleasantly surprised to see your question and that it has replies. Actually i started with T113 about 6 months ago. But then paused till last week.

I feel it is not far off and its a nice project to learn.

Since the patches from Samuel Holland mention that its a similar DSI hardware (40nm version) as the A64, i tried to add a no mod-clock patch. It removes the error, but it wont work.

And according to the User Manual T113 does need a module clock and it has to be started after the data clock. Otherwise that Manual is horrible and thin in DSI.

As far as i understand page 57 dsi module clock can be hosc, peripll1x, video0pll2x, video1pll2x, audio1pll_div2 (this matches the registers from DSI_CLK_REG).

In typical pll application PLL_PERI(2X) is suggested for DSI. Allwinner uboot sets the source in DSI_CLK_REG to 001 (PLL_PERI(1x) and the Factor to 0011 (4)

I think the routing through TCON TOP is something that is done in the kernel to make it fit into the scheme, but in hardware its not relevant?

This is the output of /sys/kernel/debug/clk/clk_summary (shortened)

enable prepare protect duty hardware
clock count count count rate accuracy phase cycle enable
-------------------------------------------------------------------------------------------------------
iosc 1 1 0 16000000 300000000 0 50000 Y
iosc-32k 1 1 0 31250 300000000 0 50000 Y
osc32k 1 1 0 31250 300000000 0 50000 Y
hdmi-cec 0 0 0 31250 300000000 0 50000 N
r-ir-rx 0 0 0 31250 300000000 0 50000 N
rtc-32k 1 1 0 31250 300000000 0 50000 Y
osc32k-fanout 0 0 0 31250 300000000 0 50000 N
dcxo 10 10 2 24000000 0 0 50000 Y
pll-ve 0 0 0 432000000 0 0 50000 N
ve 0 0 0 432000000 0 0 50000 N
pll-video1-4x 0 0 0 1188000000 0 0 50000 N
pll-video1 0 0 0 297000000 0 0 50000 Y
pll-video1-2x 0 0 0 594000000 0 0 50000 Y
pll-video0-4x 2 2 1 864000000 0 0 50000 Y
de 3 3 0 216000000 0 0 50000 Y
wb-div 0 0 0 216000000 0 0 50000 Y
wb 0 0 0 216000000 0 0 50000 N
mixer1-div 1 1 0 216000000 0 0 50000 Y
mixer1 1 1 0 216000000 0 0 50000 Y
mixer0-div 1 1 0 216000000 0 0 50000 Y
mixer0 1 1 0 216000000 0 0 50000 Y
pll-video0 1 1 1 216000000 0 0 50000 Y
fanout-27M 0 0 0 216000000 0 0 50000 N
tve 0 0 0 216000000 0 0 50000 N
tcon-tv 0 0 0 216000000 0 0 50000 N
tcon-top-tv0 0 0 0 216000000 0 0 50000 N
tcon-lcd0 2 2 1 216000000 0 0 50000 Y
tcon-pixel-clock 1 1 1 54000000 0 0 50000 Y
tcon-top-dsi 0 0 0 216000000 0 0 50000 N
pll-video0-2x 0 0 0 432000000 0 0 50000 Y
pll-periph0-4x 1 1 1 2400000000 0 0 50000 Y
pll-periph0-800M 0 0 0 800000000 0 0 50000 Y
pll-periph0-2x 1 1 1 1200000000 0 0 50000 Y
fanout-32k 0 0 0 32768 0 0 50000 N
fanout2 0 0 0 32768 0 0 50000 N
fanout1 0 0 0 32768 0 0 50000 N
fanout0 0 0 0 32768 0 0 50000 N
fanout-16M 0 0 0 16000000 0 0 50000 N
csi-top 0 0 0 1200000000 0 0 50000 N
hdmi-cec-32k 0 0 0 32768 0 0 50000 N
ce 0 0 0 300000000 0 0 50000 N
g2d 0 0 0 1200000000 0 0 50000 N
di 0 0 0 1200000000 0 0 50000 N
pll-periph0-div3 0 0 0 200000000 0 0 50000 Y
pll-periph0 5 5 1 600000000 0 0 50000 Y
mmc0 0 0 0 50000000 0 0 50000 N
mipi-dsi 2 2 1 150000000 0 0 50000 Y
fanout-25M 0 0 0 25000000 0 0 50000 N
usb-ohci1 2 2 0 12000000 0 0 50000 Y
usb-ohci0 2 2 0 12000000 0 0 50000 Y
spdif-rx 0 0 0 600000000 0 0 50000 N
emac-25M 0 0 0 25000000 0 0 50000 N
apb0 1 1 0 100000000 0 0 50000 Y
fanout-pclk 0 0 0 100000000 0 0 50000 N
bus-tzma 0 0 0 100000000 0 0 50000 N
bus-tpadc 0 0 0 100000000 0 0 50000 N
bus-lradc 0 0 0 100000000 0 0 50000 N
bus-audio 0 0 0 100000000 0 0 50000 N
bus-dmic 0 0 0 100000000 0 0 50000 N
bus-spdif 0 0 0 100000000 0 0 50000 N
bus-i2s2 0 0 0 100000000 0 0 50000 N
bus-i2s1 0 0 0 100000000 0 0 50000 N
bus-i2s0 0 0 0 100000000 0 0 50000 N
bus-ths 0 0 0 100000000 0 0 50000 N
bus-gpadc 0 0 0 100000000 0 0 50000 N
bus-ir-tx 0 0 0 100000000 0 0 50000 N
bus-iommu 0 0 0 100000000 0 0 50000 N
bus-pwm 0 0 0 100000000 0 0 50000 N
psi-ahb 13 14 0 200000000 0 0 50000 Y
bus-riscv-cfg 1 1 0 200000000 0 0 50000 Y
bus-dsp-cfg 0 0 0 200000000 0 0 50000 N
bus-csi 0 0 0 200000000 0 0 50000 N
bus-ledc 0 0 0 200000000 0 0 50000 N
bus-tvd 0 0 0 200000000 0 0 50000 N
bus-tvd-top 0 0 0 200000000 0 0 50000 N
bus-tve 0 0 0 200000000 0 0 50000 N
bus-tve-top 0 0 0 200000000 0 0 50000 N
bus-tcon-tv 1 1 0 200000000 0 0 50000 Y
bus-tcon-lcd0 1 1 0 200000000 0 0 50000 Y
bus-mipi-dsi 0 2 0 200000000 0 0 50000 N
bus-hdmi 0 0 0 200000000 0 0 50000 N
bus-dpss-top 1 1 0 200000000 0 0 50000 Y
bus-otg 1 1 0 200000000 0 0 50000 Y
bus-ehci1 1 1 0 200000000 0 0 50000 Y
bus-ehci0 1 1 0 200000000 0 0 50000 Y
bus-ohci1 2 2 0 200000000 0 0 50000 Y
bus-ohci0 2 2 0 200000000 0 0 50000 Y
bus-emac 1 1 0 200000000 0 0 50000 Y
bus-spi1 0 0 0 200000000 0 0 50000 N
bus-spi0 0 0 0 200000000 0 0 50000 N
bus-mmc2 0 0 0 200000000 0 0 50000 N
bus-mmc1 0 0 0 200000000 0 0 50000 N
bus-mmc0 0 0 0 200000000 0 0 50000 N
bus-dram 1 1 0 200000000 0 0 50000 Y
bus-dbg 0 0 0 200000000 0 0 50000 N
bus-hstimer 0 0 0 200000000 0 0 50000 N
bus-spinlock 0 0 0 200000000 0 0 50000 N
bus-msgbox2 0 0 0 200000000 0 0 50000 N
bus-msgbox1 0 0 0 200000000 0 0 50000 N
bus-msgbox0 0 0 0 200000000 0 0 50000 N
bus-dma 1 1 0 200000000 0 0 50000 Y
bus-ve 0 0 0 200000000 0 0 50000 N
bus-ce 0 0 0 200000000 0 0 50000 N
bus-g2d 0 0 0 200000000 0 0 50000 N
bus-di 0 0 0 200000000 0 0 50000 N
bus-de 3 3 0 200000000 0 0 50000 Y
bus-wb 0 0 0 200000000 0 0 50000 N
bus-mixer1 1 1 0 200000000 0 0 50000 Y
bus-mixer0 1 1 0 200000000 0 0 50000 Y

I have pulled a register overview from the working uboot config. Will try to find some differences and keep you posted.

Jakob L

unread,

Dec 30, 2023, 8:28:26 PM12/30/23

to linux-sunxi

The lack of documentation is really bad. Consider TCON TOP has its own register space its surely actual hardware. DPHY is also completly undocumented. Guess i have to read the bsp code.

Registers for CCU, TCON0, TCON_TOP and DPHY are quite different... resetting Modules via CCU and then writing them manually doesnt work.

But probably i am not doing that in the right order.

Differences i found:

CCU

DSI_BGR_REG 0x02001B4C
uboot 0x00010001
Kernel 0x00010000 //DSI CLOCK is masked

TCONLCD_CLK_REG 0x02001B60
uboot 0x81000000
001: PLL_VIDEO0(4X)
Kernel 0x80000000
000: PLL_VIDEO0(1X)

PLL_VIDEO0_CTRL_REG 0x02001040
uboot 0xc8001703
Kernel 0xF8002300

DE_CLK_REG 0x02001600
uboot 0x80000003
000: PLL_PERI(2X)
Kernel 0x81000003
001: PLL_VIDEO0(4X)

TCON0

LCD_GINT0_REG 0x05461004

uboot 00000a02
DE_INT_FLAG Enabled
Kernel 0x00000A03
DE_INT_FLAG Enabled
FSYNC_INT_FLAG Enabled

LCD_DCLK_REG 0x05461044
uboot 0xF0000004
Kernel 0x80000004

LCD_CPU_IF_REG 0x05461060
uboot 0001 0000 0000 0000 0000000000000101
31:28 CPU MODE xxx1 DSI
Kernel 0001 0000 0000 0001 0000 0000 0000 0101
FLUSH 16 //Direct Transfer mode

LCD_CPU_TRI0_REG 0x05461160
uboot 1111 0100 0000 0001 1000 1111
BLOCK SPACE 27:16 1111 0100
Kernel 1111 0011 0000 0001 1000 1111

LCD_CPU_TRI1_REG 0x05461164
uboot 11010000010011111111
kernel 0100011110000000010011111111

LCD_CPU_TRI2_REG 0x05461168
uboot 0001 0000 1011 0011 0000 0000 0000 1010
START_DLY 31:16 4275
SYNC_MODE 14:13 Auto
TRANS_START_SET 12:0 10
Kernel 0110 0111 0011 0000 0000 0000 1010

LCD_SAFE_PERIOD_REG 0x054611F0
Uboot 0x021c0003
Kernel 0x0BB80003

GPIO

PORT D 0x020000A4 DRIVE STRENGTH
uboot 0x33333333

Kernel 0x22222222

DPHY

COMBO_PHY_REG 0x05451110
uboot 0x0000000b
kernel 0x00000000

COMBO_PHY_REG 0x05451114
uboot 00000000
kernel 0x00000000

?? 0x0545111C
uboot 0x00000014
kernel 0x0

TCON_TOP

0x0546001C

uboot 0x00000020

kernel 0x00000000

0x05460020

uboot 0x00010000

kernel 0x00000000

Will have another look tomorrow, if i can.

K. James

unread,

Dec 30, 2023, 8:28:41 PM12/30/23

to linux-sunxi

Jakob,

Regarding your clock, I don't know which DTS configuration this is from however:

enable prepare protect duty hardware
clock count count count rate accuracy phase cycle enable
-------------------------------------------------------------------------------------------------------

.....

tcon-top-dsi 0 0 0 216000000 0 0 50000 N

.....

bus-mipi-dsi 0 2 0 200000000 0 0 50000 N

.....

If the DSI device/phy mod bus is supposed to be tcon-top-dsi (unlikely due to the prepare count) - it's not being enabled/set by the tcon top driver. But maybe you have the mod bus being set from a different clock in this config?

If the DSI device/phy supposed to be using the bus-mipi-dsi (likely as this is the default in the mainline t113/d1s device tree) then its being prepared, but not enabled, which is maybe odd? certainly a prepare count of two, without an enable count of two indicates something funny, like the CCU is not starting the bus-mipi-dsi clock like it should when its called?

This could be a thread to pull..

Jakob L

unread,

Dec 31, 2023, 11:01:46 AM12/31/23

to linux-sunxi

Indeed,

Had not looked at the clock print yet, but I saw the same thing in the registers yesterday. TCON_TOP is not configured and presumably not enabled. Neither is the DPHY.

The above clock print was with the only patch that did not give errors.

Option1 A

@@ -655,7 +655,7 @@ dsi: dsi@5450000 {

reg = <0x5450000 0x1000>;
interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_MIPI_DSI>,

- <&tcon_top CLK_TCON_TOP_DSI>;
+ <&ccu CLK_MIPI_DSI>;

So tcon-top-dsi not beeing prepared and enabled is ok.

But looking at the registers from uboot and sun8i_tcon_top.h it is clear that TCON_TOP_TCON_DSI_GATE is beeing set. So some clock must come from TCON_TOP

Also TCON_TOP_PORT_SEL_REG is set to 0x00000020 (kernel 0)
#define TCON_TOP_PORT_DE0_MSK GENMASK(1, 0)
#define TCON_TOP_PORT_DE1_MSK GENMASK(5, 4)

So i looked again at what you found with Option 2 (index of TCON_TOP clocks). In my kernel 6.5.7 its already fixed by Samuel Holland.

https://lore.kernel.org/lkml/20220412042807.47519-13

It is not needed anymore once you use a newer kernel.

It has to be something on the init code for DPHY and TCON_TOP as those registers remain untouched by the kernel as it is now.
Or it is because the clock is wrong, and thus the DSI_BGR_REG 0x02001B4C DSI Clock is masked, resulting in failed writes to some registers.

Might not be as easy as i hoped some days ago...

Have a nice new years eve and a good start into the new one!

Jakob

Jakob L

unread,

Jan 1, 2024, 12:10:49 PMJan 1

to linux-sunxi

I inserted some printks in the sun4i_tcon.c, sun8i-tcon-top.c and sun6i_mipi_dsi.c (because there are not many debug prints with DRM.debug)
[ 0.968820] sun4i_tcon_probe
[ 0.968890] sun4i_tcon_probe:hasChannel0
[ 0.969635] sun4i_tcon_probe
[ 0.976753] sun8i_tcon_top_probe
[ 2.391061] sun6i_dsi_probe

[ 2.394217] sun6i-mipi-dsi 5450000.dsi: supply vcc-dsi not found, using dummy regulator
[ 2.403074] sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock

Might have to look more, but it seems the the tcon and tcon_top are probed, then when dsi is probed later, it fails. Can it be that the clock is not available yet, because tcon and tcon_top are not bound yet?

I saw that this dependencies where a problem with other sunxi mipi implementations. Had been fixed though in 2019.

So it might be that the clocks are fine after all. But it fails for another reason.

Jakob L

unread,

Jan 26, 2024, 8:36:58 PMJan 26

to linux-sunxi

Hi James,

a friend of mine managed to fix it based on our analysis. Its a hack.

But it proves that the problem is what i had written. Not sure how to code it so it can be upstreamed.

But you can test your hardware and use it like this.

diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index a1ca3916f42b..df7b5c64679a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -121,6 +121,12 @@ static struct clk_hw *sun8i_tcon_top_register_gate(struct device *dev,
bit, 0, lock);
};

+static int bind_new(struct device *dev, struct device *master,
+ void *data)
+{
+ return 0;
+}
+
static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
void *data)
{
@@ -251,13 +257,18 @@ static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
}

static const struct component_ops sun8i_tcon_top_ops = {
- .bind = sun8i_tcon_top_bind,
+ .bind = bind_new,
.unbind = sun8i_tcon_top_unbind,
};

static int sun8i_tcon_top_probe(struct platform_device *pdev)
{
- return component_add(&pdev->dev, &sun8i_tcon_top_ops);
+ dev_info(&pdev->dev, "%s\n", __func__);
+ component_add(&pdev->dev, &sun8i_tcon_top_ops);
+
+ sun8i_tcon_top_bind(&pdev->dev, NULL, NULL);
+
+ return 0;
}

static void sun8i_tcon_top_remove(struct platform_device *pdev)
--
2.34.1

K. James

unread,

Jan 27, 2024, 9:20:07 PMJan 27

to linux-sunxi

Hey Jakob,

So the issue is some sort of race condition between the binding of tcon top and the dsi driver?

And your patch above forces the tcon top to bind?

What DTS/Clock settings did you use with this? what kernel version? I will test.

Cheers

Jakob L

unread,

Jan 29, 2024, 6:35:29 AMJan 29

to linux-sunxi

Hi James,

yes, exactly. The patch forces the tcon_top to bind at probe.

Its tested on 6.7.0 kernel with a custom mipi panel. But any other panel should work. It was based on panel-feiyang-fy07024di26a30d.c, i think.

I added these nodes to MangoPi dts. All other settings are stock kernel.

+&de {
+ status = "okay";
+};
+
+&dsi {
+ pinctrl-0 = <&dsi_4lane_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ panel: panel@0 {
+ reg = <0>;

+ compatible = "test,7x-0";

+ pinctrl-names = "default";
+ reset-gpios = <&pio 3 20 GPIO_ACTIVE_HIGH>;
+

+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&tcon_lcd0_out_dsi>;
+ };
+ };
+
+ };
+};
+
+&dphy {
+ status = "okay";
+};

+

Jakob L

unread,

Feb 26, 2024, 8:57:30 AMFeb 26

to linux-sunxi

Hi James,

were you able to test the patches? It unfortunalty seems like this isn't the only problem. On about 50% of the cold boots i get a green tinted image on the screen. Its working, but everything is greenish (blacks and also whites).

Probably has to do with the wrong clocks or wrong dsi packager setup? We also tested the patches that Frank Oltmanns posted in this thread https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw

Does anybody know why the calculation of timings is so much different than what the BSP of T113 does?

Thanks!
Jakob

K. James

unread,

Jun 11, 2024, 6:38:36 PMJun 11

to linux-sunxi

Hey Jakob,

I didn't proceed with testing the DSI on T113-S3, but I have attempted to get the RGB output working. I have had "mixed" success. I can get the display initialising and a directfb test runs.

But it *also* has a green tinge over the whole display, which is consistent and I cannot fathom why.

It must be device related, because the exact same kernel, driver (+ init code), display works perfectly on my v3s test setup.

So frustrating!! Did you have any further progress?

K. James

unread,

Jun 12, 2024, 2:15:37 AMJun 12

to linux-sunxi

Hey Jakob,

Jookia was dealing with something similar on IRC (except a blue tint). Some experimentation yielded a result for us both.

Completely removing Mixer1 definition from the device tree and the tinting is gone.

Patch here:

https://paste.xogium.me/pn.txt

Maybe try it on your DSI implementation and let us know?

Jakob L

unread,

Jun 27, 2024, 6:43:23 PM (5 days ago) Jun 27

to linux-sunxi

Hi James, oh that is brilliant. A friend of mine was doing some debugging on the DSI via a seld made FPGA analyser.The packets looked fine.

But the mixer is indeed the problem...

Did you use the T113 with gstreamer - by any chance?

K. James

unread,

Jun 27, 2024, 7:50:22 PM (5 days ago) Jun 27

to linux-sunxi

No, not using with gstreamer.

Also the tcon-top pipeline is very similar to the R40, there is a DSI patch for the R40 that has never been committed (still some issues) but based on the testing I have done, it might also solve the D1 implementation issues that you "patched" above:

https://patchwork.freedesktop.org/patch/347129/?series=62062&rev=3

Jakob L

unread,

Jun 28, 2024, 6:52:55 PM (4 days ago) Jun 28

to linux-sunxi

Hi James,

indeed this patch looks like it handles my solution properly...

Will give it a try.

Had just built new gstreamer 1.24 and patched in video node for T113 using the one from D1.

Including this patch i get it to probe.

https://patchwork.kernel.org/project/linux-media/patch/20221231164628...@sholland.org/

But the screen stays blank, no error in gst-launch, but not image either. fb0 emualtion works still.

Some if my patches introduced a new color, now most of the time the sytem boots with a pink tint.

Will probably take some more months to fix this ;)

K. James

unread,

Jun 28, 2024, 6:55:27 PM (4 days ago) Jun 28

to linux-sunxi

Check out the patch that John Watts just sent out (you were included).

This patch seems to fix all the tint issues.

Jakob L

unread,

Jun 28, 2024, 7:11:25 PM (4 days ago) Jun 28

to linux-sunxi

Hi James,

seem like sunxi is always worked on in the night shift.

Just saw it as well. Will try it...

Thanks!
Jakob

Reply all

Reply to author

Forward