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/279ec9c1-a93f-43e2-b85d-7266a7955642n%40googlegroups.com.
