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/ce571782-4517-4db2-be7f-1ea6ca793c39n%40googlegroups.com.
