Hi James, seem like sunxi is always worked on in the night shift. Just saw it as well. Will try it...
Thanks! Jakob K. James schrieb am Samstag, 29. Juni 2024 um 00:55:27 UTC+2: > Check out the patch that John Watts just sent out (you were included). > > This patch seems to fix all the tint issues. > > On Saturday 29 June 2024 at 8:52:55 am UTC+10 jakob...@gmail.com wrote: > >> 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/ >> >> <https://patchwork.kernel.org/project/linux-media/patch/20221231164628.19688-4-sam...@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 schrieb am Freitag, 28. Juni 2024 um 01:50:22 UTC+2: >> >>> >>> 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 >>> >>> >>> On Friday 28 June 2024 at 8:43:23 am UTC+10 jakob...@gmail.com wrote: >>> >>>> 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 schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2: >>>> >>>>> 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? >>>>> >>>>> On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote: >>>>> >>>>>> 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? >>>>>> >>>>>> >>>>>> >>>>>> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1: >>>>>>> >>>>>>>> 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"; >>>>>>>> +}; >>>>>>>> + >>>>>>>> >>>>>>>> K. James schrieb am Sonntag, 28. Januar 2024 um 03:20:07 UTC+1: >>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Saturday 27 January 2024 at 11:36:58 am UTC+10 >>>>>>>>> jakob...@gmail.com wrote: >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> Jakob L schrieb am Montag, 1. Januar 2024 um 18:10:49 UTC+1: >>>>>>>>>> >>>>>>>>>>> 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 schrieb am Sonntag, 31. Dezember 2023 um 17:01:46 UTC+1: >>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> K. James schrieb am Sonntag, 31. Dezember 2023 um 02:28:41 >>>>>>>>>>>> UTC+1: >>>>>>>>>>>> >>>>>>>>>>>>> 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.. >>>>>>>>>>>>> On Sunday 31 December 2023 at 8:23:46 am UTC+10:30 >>>>>>>>>>>>> jakob...@gmail.com wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> K. James schrieb am Samstag, 30. Dezember 2023 um 08:05:56 >>>>>>>>>>>>>> UTC+1: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, 30 Dec 2023 at 16:42, Jakob L <jakob...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> K. James schrieb am Freitag, 29. Dezember 2023 um 03:48:37 >>>>>>>>>>>>>>>> UTC+1: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thursday 28 December 2023 at 9:59:09 am UTC+10:30 Andre >>>>>>>>>>>>>>>>> Przywara wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > , "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 >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/linux-sunxi/02e9453d-7335-4499-933b-ac5038e41bbcn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/0c5a3081-9c2c-420f-a646-8862ea2c0ab8n%40googlegroups.com.
