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.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/2b3418ba-2357-4125-bf13-861a26f54661n%40googlegroups.com.
