Check out the patch that John Watts just sent out (you were included). This patch seems to fix all the tint issues.
On Saturday 29 June 2024 at 8:52:55 am UTC+10 jakob...@gmail.com wrote: > Hi James, > indeed this patch looks like it handles my solution properly... > Will give it a try. > > Had just built new gstreamer 1.24 and patched in video node for T113 using > the one from D1. > Including this patch i get it to probe. > > https://patchwork.kernel.org/project/linux-media/patch/20221231164628...@sholland.org/ > > <https://patchwork.kernel.org/project/linux-media/patch/20221231164628.19688-4-sam...@sholland.org/> > > But the screen stays blank, no error in gst-launch, but not image either. > fb0 emualtion works still. > > Some if my patches introduced a new color, now most of the time the sytem > boots with a pink tint. > > Will probably take some more months to fix this ;) > > K. James schrieb am Freitag, 28. Juni 2024 um 01:50:22 UTC+2: > >> >> No, not using with gstreamer. >> >> Also the tcon-top pipeline is very similar to the R40, there is a DSI >> patch for the R40 that has never been committed (still some issues) but >> based on the testing I have done, it might also solve the D1 implementation >> issues that you "patched" above: >> >> https://patchwork.freedesktop.org/patch/347129/?series=62062&rev=3 >> >> >> On Friday 28 June 2024 at 8:43:23 am UTC+10 jakob...@gmail.com wrote: >> >>> Hi James, oh that is brilliant. A friend of mine was doing some >>> debugging on the DSI via a seld made FPGA analyser.The packets looked fine. >>> But the mixer is indeed the problem... >>> >>> Did you use the T113 with gstreamer - by any chance? >>> >>> >>> >>> K. James schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2: >>> >>>> Hey Jakob, >>>> >>>> Jookia was dealing with something similar on IRC (except a blue tint). >>>> Some experimentation yielded a result for us both. >>>> >>>> Completely removing Mixer1 definition from the device tree and the >>>> tinting is gone. >>>> >>>> Patch here: >>>> https://paste.xogium.me/pn.txt >>>> >>>> Maybe try it on your DSI implementation and let us know? >>>> >>>> On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote: >>>> >>>>> Hey Jakob, >>>>> >>>>> I didn't proceed with testing the DSI on T113-S3, but I have attempted >>>>> to get the RGB output working. I have had "mixed" success. I can get the >>>>> display initialising and a directfb test runs. >>>>> >>>>> But it *also* has a green tinge over the whole display, which is >>>>> consistent and I cannot fathom why. >>>>> >>>>> It must be device related, because the exact same kernel, driver (+ >>>>> init code), display works perfectly on my v3s test setup. >>>>> >>>>> So frustrating!! Did you have any further progress? >>>>> >>>>> >>>>> >>>>> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com >>>>> wrote: >>>>> >>>>>> Hi James, >>>>>> >>>>>> were you able to test the patches? It unfortunalty seems like this >>>>>> isn't the only problem. On about 50% of the cold boots i get a green >>>>>> tinted >>>>>> image on the screen. Its working, but everything is greenish (blacks and >>>>>> also whites). >>>>>> Probably has to do with the wrong clocks or wrong dsi packager setup? >>>>>> We also tested the patches that Frank Oltmanns posted in this thread >>>>>> https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw >>>>>> Does anybody know why the calculation of timings is so much different >>>>>> than what the BSP of T113 does? >>>>>> >>>>>> Thanks! >>>>>> Jakob >>>>>> >>>>>> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1: >>>>>> >>>>>>> Hi James, >>>>>>> >>>>>>> yes, exactly. The patch forces the tcon_top to bind at probe. >>>>>>> Its tested on 6.7.0 kernel with a custom mipi panel. But any other >>>>>>> panel should work. It was based on panel-feiyang-fy07024di26a30d.c, >>>>>>> i think. >>>>>>> I added these nodes to MangoPi dts. All other settings are stock >>>>>>> kernel. >>>>>>> >>>>>>> +&de { >>>>>>> + status = "okay"; >>>>>>> +}; >>>>>>> + >>>>>>> +&dsi { >>>>>>> + pinctrl-0 = <&dsi_4lane_pins>; >>>>>>> + pinctrl-names = "default"; >>>>>>> + status = "okay"; >>>>>>> + >>>>>>> + panel: panel@0 { >>>>>>> + reg = <0>; >>>>>>> + compatible = "test,7x-0"; >>>>>>> >>>>>>> + pinctrl-names = "default"; >>>>>>> + reset-gpios = <&pio 3 20 GPIO_ACTIVE_HIGH>; >>>>>>> + >>>>>>> + port { >>>>>>> + panel_in: endpoint { >>>>>>> + remote-endpoint = <&tcon_lcd0_out_dsi>; >>>>>>> + }; >>>>>>> + }; >>>>>>> + >>>>>>> + }; >>>>>>> +}; >>>>>>> + >>>>>>> +&dphy { >>>>>>> + status = "okay"; >>>>>>> +}; >>>>>>> + >>>>>>> >>>>>>> K. James schrieb am Sonntag, 28. Januar 2024 um 03:20:07 UTC+1: >>>>>>> >>>>>>>> Hey Jakob, >>>>>>>> >>>>>>>> So the issue is some sort of race condition between the binding of >>>>>>>> tcon top and the dsi driver? >>>>>>>> >>>>>>>> And your patch above forces the tcon top to bind? >>>>>>>> >>>>>>>> What DTS/Clock settings did you use with this? what kernel version? >>>>>>>> I will test. >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Saturday 27 January 2024 at 11:36:58 am UTC+10 >>>>>>>> jakob...@gmail.com wrote: >>>>>>>> >>>>>>>>> Hi James, >>>>>>>>> >>>>>>>>> a friend of mine managed to fix it based on our analysis. Its a >>>>>>>>> hack. >>>>>>>>> But it proves that the problem is what i had written. Not sure how >>>>>>>>> to code it so it can be upstreamed. >>>>>>>>> But you can test your hardware and use it like this. >>>>>>>>> >>>>>>>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c >>>>>>>>> b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c >>>>>>>>> index a1ca3916f42b..df7b5c64679a 100644 >>>>>>>>> --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c >>>>>>>>> +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c >>>>>>>>> @@ -121,6 +121,12 @@ static struct clk_hw >>>>>>>>> *sun8i_tcon_top_register_gate(struct device *dev, >>>>>>>>> bit, 0, lock); >>>>>>>>> }; >>>>>>>>> >>>>>>>>> +static int bind_new(struct device *dev, struct device *master, >>>>>>>>> + void *data) >>>>>>>>> +{ >>>>>>>>> + return 0; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> static int sun8i_tcon_top_bind(struct device *dev, struct device >>>>>>>>> *master, >>>>>>>>> void *data) >>>>>>>>> { >>>>>>>>> @@ -251,13 +257,18 @@ static void sun8i_tcon_top_unbind(struct >>>>>>>>> device *dev, struct device *master, >>>>>>>>> } >>>>>>>>> >>>>>>>>> static const struct component_ops sun8i_tcon_top_ops = { >>>>>>>>> - .bind = sun8i_tcon_top_bind, >>>>>>>>> + .bind = bind_new, >>>>>>>>> .unbind = sun8i_tcon_top_unbind, >>>>>>>>> }; >>>>>>>>> >>>>>>>>> static int sun8i_tcon_top_probe(struct platform_device *pdev) >>>>>>>>> { >>>>>>>>> - return component_add(&pdev->dev, &sun8i_tcon_top_ops); >>>>>>>>> + dev_info(&pdev->dev, "%s\n", __func__); >>>>>>>>> + component_add(&pdev->dev, &sun8i_tcon_top_ops); >>>>>>>>> + >>>>>>>>> + sun8i_tcon_top_bind(&pdev->dev, NULL, NULL); >>>>>>>>> + >>>>>>>>> + return 0; >>>>>>>>> } >>>>>>>>> >>>>>>>>> static void sun8i_tcon_top_remove(struct platform_device *pdev) >>>>>>>>> -- >>>>>>>>> 2.34.1 >>>>>>>>> >>>>>>>>> Jakob L schrieb am Montag, 1. Januar 2024 um 18:10:49 UTC+1: >>>>>>>>> >>>>>>>>>> I inserted some printks in the sun4i_tcon.c, sun8i-tcon-top.c and >>>>>>>>>> sun6i_mipi_dsi.c (because there are not many debug prints with >>>>>>>>>> DRM.debug) >>>>>>>>>> [ 0.968820] sun4i_tcon_probe >>>>>>>>>> [ 0.968890] sun4i_tcon_probe:hasChannel0 >>>>>>>>>> [ 0.969635] sun4i_tcon_probe >>>>>>>>>> [ 0.976753] sun8i_tcon_top_probe >>>>>>>>>> [ 2.391061] sun6i_dsi_probe >>>>>>>>>> [ 2.394217] sun6i-mipi-dsi 5450000.dsi: supply vcc-dsi not >>>>>>>>>> found, using dummy regulator >>>>>>>>>> [ 2.403074] sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI >>>>>>>>>> mod clock >>>>>>>>>> >>>>>>>>>> Might have to look more, but it seems the the tcon and tcon_top >>>>>>>>>> are probed, then when dsi is probed later, it fails. Can it be that >>>>>>>>>> the >>>>>>>>>> clock is not available yet, because tcon and tcon_top are not bound >>>>>>>>>> yet? >>>>>>>>>> I saw that this dependencies where a problem with other sunxi >>>>>>>>>> mipi implementations. Had been fixed though in 2019. >>>>>>>>>> So it might be that the clocks are fine after all. But it fails >>>>>>>>>> for another reason. >>>>>>>>>> >>>>>>>>>> Jakob L schrieb am Sonntag, 31. Dezember 2023 um 17:01:46 UTC+1: >>>>>>>>>> >>>>>>>>>>> Indeed, >>>>>>>>>>> >>>>>>>>>>> Had not looked at the clock print yet, but I saw the same thing >>>>>>>>>>> in the registers yesterday. TCON_TOP is not configured and >>>>>>>>>>> presumably not >>>>>>>>>>> enabled. Neither is the DPHY. >>>>>>>>>>> The above clock print was with the only patch that did not give >>>>>>>>>>> errors. >>>>>>>>>>> Option1 A >>>>>>>>>>> @@ -655,7 +655,7 @@ dsi: dsi@5450000 { >>>>>>>>>>> >>>>>>>>>>> reg = <0x5450000 0x1000>; >>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>> - <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>> + <&ccu CLK_MIPI_DSI>; >>>>>>>>>>> >>>>>>>>>>> So tcon-top-dsi not beeing prepared and enabled is ok. >>>>>>>>>>> >>>>>>>>>>> But looking at the registers from uboot and sun8i_tcon_top.h it >>>>>>>>>>> is clear that TCON_TOP_TCON_DSI_GATE is beeing set. So some clock >>>>>>>>>>> must come >>>>>>>>>>> from TCON_TOP >>>>>>>>>>> Also TCON_TOP_PORT_SEL_REG is set to 0x00000020 (kernel 0) >>>>>>>>>>> #define TCON_TOP_PORT_DE0_MSK GENMASK(1, 0) >>>>>>>>>>> #define TCON_TOP_PORT_DE1_MSK GENMASK(5, 4) >>>>>>>>>>> >>>>>>>>>>> So i looked again at what you found with Option 2 (index of >>>>>>>>>>> TCON_TOP clocks). In my kernel 6.5.7 its already fixed by Samuel >>>>>>>>>>> Holland. >>>>>>>>>>> https://lore.kernel.org/lkml/20220412042807.47519-13 >>>>>>>>>>> It is not needed anymore once you use a newer kernel. >>>>>>>>>>> >>>>>>>>>>> It has to be something on the init code for DPHY and TCON_TOP as >>>>>>>>>>> those registers remain untouched by the kernel as it is now. >>>>>>>>>>> Or it is because the clock is wrong, and thus the *DSI_BGR_REG >>>>>>>>>>> 0x02001B4C *DSI Clock is masked, resulting in failed writes to >>>>>>>>>>> some registers. >>>>>>>>>>> Might not be as easy as i hoped some days ago... >>>>>>>>>>> >>>>>>>>>>> Have a nice new years eve and a good start into the new one! >>>>>>>>>>> Jakob >>>>>>>>>>> K. James schrieb am Sonntag, 31. Dezember 2023 um 02:28:41 UTC+1: >>>>>>>>>>> >>>>>>>>>>>> Jakob, >>>>>>>>>>>> >>>>>>>>>>>> Regarding your clock, I don't know which DTS configuration this >>>>>>>>>>>> is from however: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> enable prepare protect >>>>>>>>>>>> duty hardware >>>>>>>>>>>> clock count count count >>>>>>>>>>>> rate accuracy phase cycle enable >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------------------------------------------- >>>>>>>>>>>> ..... >>>>>>>>>>>> tcon-top-dsi 0 0 0 >>>>>>>>>>>> 216000000 0 0 50000 N >>>>>>>>>>>> ..... >>>>>>>>>>>> >>>>>>>>>>>> bus-mipi-dsi 0 2 0 >>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>> ..... >>>>>>>>>>>> >>>>>>>>>>>> If the DSI device/phy mod bus is supposed to be tcon-top-dsi >>>>>>>>>>>> (unlikely due to the prepare count) - it's not being enabled/set >>>>>>>>>>>> by the >>>>>>>>>>>> tcon top driver. But maybe you have the mod bus being set from a >>>>>>>>>>>> different >>>>>>>>>>>> clock in this config? >>>>>>>>>>>> >>>>>>>>>>>> If the DSI device/phy supposed to be using the bus-mipi-dsi >>>>>>>>>>>> (likely as this is the default in the mainline t113/d1s device >>>>>>>>>>>> tree) then >>>>>>>>>>>> its being prepared, but not enabled, which is maybe odd? certainly >>>>>>>>>>>> a >>>>>>>>>>>> prepare count of two, without an enable count of two indicates >>>>>>>>>>>> something >>>>>>>>>>>> funny, like the CCU is not starting the bus-mipi-dsi clock like it >>>>>>>>>>>> should >>>>>>>>>>>> when its called? >>>>>>>>>>>> >>>>>>>>>>>> This could be a thread to pull.. >>>>>>>>>>>> On Sunday 31 December 2023 at 8:23:46 am UTC+10:30 >>>>>>>>>>>> jakob...@gmail.com wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello James, >>>>>>>>>>>>> >>>>>>>>>>>>> yes indeed. I also was pleasantly surprised to see your >>>>>>>>>>>>> question and that it has replies. Actually i started with T113 >>>>>>>>>>>>> about 6 >>>>>>>>>>>>> months ago. But then paused till last week. >>>>>>>>>>>>> I feel it is not far off and its a nice project to learn. >>>>>>>>>>>>> >>>>>>>>>>>>> Since the patches from Samuel Holland mention that its a >>>>>>>>>>>>> similar DSI hardware (40nm version) as the A64, i tried to add a >>>>>>>>>>>>> no >>>>>>>>>>>>> mod-clock patch. It removes the error, but it wont work. >>>>>>>>>>>>> >>>>>>>>>>>>> And according to the User Manual T113 does need a module clock >>>>>>>>>>>>> and it has to be started after the data clock. Otherwise that >>>>>>>>>>>>> Manual is >>>>>>>>>>>>> horrible and thin in DSI. >>>>>>>>>>>>> As far as i understand page 57 dsi module clock can be hosc, >>>>>>>>>>>>> peripll1x, video0pll2x, video1pll2x, audio1pll_div2 (this matches >>>>>>>>>>>>> the >>>>>>>>>>>>> registers from DSI_CLK_REG). >>>>>>>>>>>>> In typical pll application PLL_PERI(2X) is suggested for DSI. >>>>>>>>>>>>> Allwinner uboot sets the source in DSI_CLK_REG to 001 >>>>>>>>>>>>> (PLL_PERI(1x) and the >>>>>>>>>>>>> Factor to 0011 (4) >>>>>>>>>>>>> >>>>>>>>>>>>> I think the routing through TCON TOP is something that is done >>>>>>>>>>>>> in the kernel to make it fit into the scheme, but in hardware its >>>>>>>>>>>>> not >>>>>>>>>>>>> relevant? >>>>>>>>>>>>> >>>>>>>>>>>>> This is the output of /sys/kernel/debug/clk/clk_summary >>>>>>>>>>>>> (shortened) >>>>>>>>>>>>> enable prepare protect >>>>>>>>>>>>> duty hardware >>>>>>>>>>>>> clock count count count >>>>>>>>>>>>> rate accuracy phase cycle enable >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------------------------------------------- >>>>>>>>>>>>> iosc 1 1 0 >>>>>>>>>>>>> 16000000 300000000 0 50000 Y >>>>>>>>>>>>> iosc-32k 1 1 0 >>>>>>>>>>>>> 31250 300000000 0 50000 Y >>>>>>>>>>>>> osc32k 1 1 0 >>>>>>>>>>>>> 31250 300000000 0 50000 Y >>>>>>>>>>>>> hdmi-cec 0 0 0 >>>>>>>>>>>>> 31250 300000000 0 50000 N >>>>>>>>>>>>> r-ir-rx 0 0 0 >>>>>>>>>>>>> 31250 300000000 0 50000 N >>>>>>>>>>>>> rtc-32k 1 1 0 >>>>>>>>>>>>> 31250 300000000 0 50000 Y >>>>>>>>>>>>> osc32k-fanout 0 0 0 >>>>>>>>>>>>> 31250 300000000 0 50000 N >>>>>>>>>>>>> dcxo 10 10 2 >>>>>>>>>>>>> 24000000 0 0 50000 Y >>>>>>>>>>>>> pll-ve 0 0 0 >>>>>>>>>>>>> 432000000 0 0 50000 N >>>>>>>>>>>>> ve 0 0 0 >>>>>>>>>>>>> 432000000 0 0 50000 N >>>>>>>>>>>>> pll-video1-4x 0 0 0 >>>>>>>>>>>>> 1188000000 0 0 50000 N >>>>>>>>>>>>> pll-video1 0 0 0 >>>>>>>>>>>>> 297000000 0 0 50000 Y >>>>>>>>>>>>> pll-video1-2x 0 0 0 >>>>>>>>>>>>> 594000000 0 0 50000 Y >>>>>>>>>>>>> pll-video0-4x 2 2 1 >>>>>>>>>>>>> 864000000 0 0 50000 Y >>>>>>>>>>>>> de 3 3 0 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> wb-div 0 0 0 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> wb 0 0 0 >>>>>>>>>>>>> 216000000 0 0 50000 N >>>>>>>>>>>>> mixer1-div 1 1 0 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> mixer1 1 1 0 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> mixer0-div 1 1 0 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> mixer0 1 1 0 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> pll-video0 1 1 1 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> fanout-27M 0 0 0 >>>>>>>>>>>>> 216000000 0 0 50000 N >>>>>>>>>>>>> tve 0 0 0 >>>>>>>>>>>>> 216000000 0 0 50000 N >>>>>>>>>>>>> tcon-tv 0 0 0 >>>>>>>>>>>>> 216000000 0 0 50000 N >>>>>>>>>>>>> tcon-top-tv0 0 0 0 >>>>>>>>>>>>> 216000000 0 0 50000 N >>>>>>>>>>>>> tcon-lcd0 2 2 1 >>>>>>>>>>>>> 216000000 0 0 50000 Y >>>>>>>>>>>>> tcon-pixel-clock 1 1 1 >>>>>>>>>>>>> 54000000 0 0 50000 Y >>>>>>>>>>>>> tcon-top-dsi 0 0 0 >>>>>>>>>>>>> 216000000 0 0 50000 N >>>>>>>>>>>>> pll-video0-2x 0 0 0 >>>>>>>>>>>>> 432000000 0 0 50000 Y >>>>>>>>>>>>> pll-periph0-4x 1 1 1 >>>>>>>>>>>>> 2400000000 0 0 50000 Y >>>>>>>>>>>>> pll-periph0-800M 0 0 0 >>>>>>>>>>>>> 800000000 0 0 50000 Y >>>>>>>>>>>>> pll-periph0-2x 1 1 1 >>>>>>>>>>>>> 1200000000 0 0 50000 Y >>>>>>>>>>>>> fanout-32k 0 0 0 >>>>>>>>>>>>> 32768 0 0 50000 N >>>>>>>>>>>>> fanout2 0 0 0 >>>>>>>>>>>>> 32768 0 0 50000 N >>>>>>>>>>>>> fanout1 0 0 0 >>>>>>>>>>>>> 32768 0 0 50000 N >>>>>>>>>>>>> fanout0 0 0 0 >>>>>>>>>>>>> 32768 0 0 50000 N >>>>>>>>>>>>> fanout-16M 0 0 0 >>>>>>>>>>>>> 16000000 0 0 50000 N >>>>>>>>>>>>> csi-top 0 0 0 >>>>>>>>>>>>> 1200000000 0 0 50000 N >>>>>>>>>>>>> hdmi-cec-32k 0 0 0 >>>>>>>>>>>>> 32768 0 0 50000 N >>>>>>>>>>>>> ce 0 0 0 >>>>>>>>>>>>> 300000000 0 0 50000 N >>>>>>>>>>>>> g2d 0 0 0 >>>>>>>>>>>>> 1200000000 0 0 50000 N >>>>>>>>>>>>> di 0 0 0 >>>>>>>>>>>>> 1200000000 0 0 50000 N >>>>>>>>>>>>> pll-periph0-div3 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> pll-periph0 5 5 1 >>>>>>>>>>>>> 600000000 0 0 50000 Y >>>>>>>>>>>>> mmc0 0 0 0 >>>>>>>>>>>>> 50000000 0 0 50000 N >>>>>>>>>>>>> mipi-dsi 2 2 1 >>>>>>>>>>>>> 150000000 0 0 50000 Y >>>>>>>>>>>>> fanout-25M 0 0 0 >>>>>>>>>>>>> 25000000 0 0 50000 N >>>>>>>>>>>>> usb-ohci1 2 2 0 >>>>>>>>>>>>> 12000000 0 0 50000 Y >>>>>>>>>>>>> usb-ohci0 2 2 0 >>>>>>>>>>>>> 12000000 0 0 50000 Y >>>>>>>>>>>>> spdif-rx 0 0 0 >>>>>>>>>>>>> 600000000 0 0 50000 N >>>>>>>>>>>>> emac-25M 0 0 0 >>>>>>>>>>>>> 25000000 0 0 50000 N >>>>>>>>>>>>> apb0 1 1 0 >>>>>>>>>>>>> 100000000 0 0 50000 Y >>>>>>>>>>>>> fanout-pclk 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-tzma 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-tpadc 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-lradc 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-audio 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-dmic 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-spdif 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-i2s2 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-i2s1 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-i2s0 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-ths 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-gpadc 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-ir-tx 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-iommu 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> bus-pwm 0 0 0 >>>>>>>>>>>>> 100000000 0 0 50000 N >>>>>>>>>>>>> psi-ahb 13 14 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-riscv-cfg 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-dsp-cfg 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-csi 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-ledc 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-tvd 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-tvd-top 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-tve 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-tve-top 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-tcon-tv 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-tcon-lcd0 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-mipi-dsi 0 2 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-hdmi 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-dpss-top 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-otg 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-ehci1 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-ehci0 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-ohci1 2 2 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-ohci0 2 2 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-emac 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-spi1 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-spi0 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-mmc2 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-mmc1 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-mmc0 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-dram 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-dbg 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-hstimer 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-spinlock 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-msgbox2 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-msgbox1 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-msgbox0 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-dma 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-ve 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-ce 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-g2d 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-di 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-de 3 3 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-wb 0 0 0 >>>>>>>>>>>>> 200000000 0 0 50000 N >>>>>>>>>>>>> bus-mixer1 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> bus-mixer0 1 1 0 >>>>>>>>>>>>> 200000000 0 0 50000 Y >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I have pulled a register overview from the working uboot >>>>>>>>>>>>> config. Will try to find some differences and keep you posted. >>>>>>>>>>>>> K. James schrieb am Samstag, 30. Dezember 2023 um 08:05:56 >>>>>>>>>>>>> UTC+1: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hey Jakob, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ok, nice to know there is someone else working to solve the >>>>>>>>>>>>>> same problem, I saw some other guys having similar issues on the >>>>>>>>>>>>>> IRC >>>>>>>>>>>>>> channel. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Shame it was not something obvious like clock index didn't >>>>>>>>>>>>>> solve it straight away, but Option 1A seems like it could be >>>>>>>>>>>>>> part of the >>>>>>>>>>>>>> solution - at least it was init without error >>>>>>>>>>>>>> >>>>>>>>>>>>>> Pinctrl looks ok too, I don't think it should matter if it's >>>>>>>>>>>>>> under the dsi, dphy or tcon node - and no pinctrl assertion >>>>>>>>>>>>>> errors I >>>>>>>>>>>>>> presume? >>>>>>>>>>>>>> but if you have a chance to scope the lanes might give us >>>>>>>>>>>>>> some indication if we are anything looking correct with the >>>>>>>>>>>>>> working clock >>>>>>>>>>>>>> config. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Worth checking /sys/kernel/debug/clk/clk_summary (with >>>>>>>>>>>>>> debugfs mounted) to see if we can identify the clock sources >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think the tcon print out any debug messages at the >>>>>>>>>>>>>> default level, maybe increase the console loglevel and pastebin >>>>>>>>>>>>>> your full >>>>>>>>>>>>>> dmesg? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, 30 Dec 2023 at 16:42, Jakob L <jakob...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello James and Andrew, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> i was recently also tryting to get mipi dsi to work on >>>>>>>>>>>>>>> T113-S3 - with the same error. >>>>>>>>>>>>>>> These days i was going to compare register setting between >>>>>>>>>>>>>>> mainline kernel and bsp u-boot. >>>>>>>>>>>>>>> But this here came early and i was able to try the options. >>>>>>>>>>>>>>> The LCD i use works on A64 and also works with these timings >>>>>>>>>>>>>>> on allwinner kernel on my T113 board. >>>>>>>>>>>>>>> On T113 the Low power mode of DSI works - i can send the >>>>>>>>>>>>>>> init code. Verified that with oscilloscope and test patterns on >>>>>>>>>>>>>>> LCD. >>>>>>>>>>>>>>> Then the lanes are dead and do not have the right level >>>>>>>>>>>>>>> afair. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I used Kernel 6.5.7. DRM_SUN8I_TCON_TOP is enabled >>>>>>>>>>>>>>> With MangoPi dts as base and the following nodes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +&de { >>>>>>>>>>>>>>> + status = "okay"; >>>>>>>>>>>>>>> +}; >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> +&dsi { >>>>>>>>>>>>>>> + pinctrl-0 = <&dsi_4lane_pins>; >>>>>>>>>>>>>>> + pinctrl-names = "default"; >>>>>>>>>>>>>>> + status = "okay"; >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + panel: panel@0 { >>>>>>>>>>>>>>> + reg = <0>; >>>>>>>>>>>>>>> + compatible = "jnj,7i"; >>>>>>>>>>>>>>> + pinctrl-names = "default"; >>>>>>>>>>>>>>> + reset-gpios = <&pio 3 20 GPIO_ACTIVE_HIGH>; >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + // pinctrl-0 = <&panel_pin>; >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + port { >>>>>>>>>>>>>>> + panel_in: endpoint { >>>>>>>>>>>>>>> + remote-endpoint = <&tcon_lcd0_out_dsi>; >>>>>>>>>>>>>>> + }; >>>>>>>>>>>>>>> + }; >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + }; >>>>>>>>>>>>>>> +}; >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> +&dphy { >>>>>>>>>>>>>>> + status = "okay"; >>>>>>>>>>>>>>> +}; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Option2 No Luck >>>>>>>>>>>>>>> @@ -655,7 +655,7 @@ dsi: dsi@5450000 { >>>>>>>>>>>>>>> reg = <0x5450000 0x1000>; >>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>> - <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>>>>>> + <&tcon_top 1>; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I had a feeling option 2 has something to do with it. But >>>>>>>>>>>>>>> the patched kernel shows the same error. >>>>>>>>>>>>>>> sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Option1 A >>>>>>>>>>>>>>> @@ -655,7 +655,7 @@ dsi: dsi@5450000 { >>>>>>>>>>>>>>> reg = <0x5450000 0x1000>; >>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>> - <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>>>>>> + <&ccu CLK_MIPI_DSI>; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With this patch i am no longer getting the modclock error. >>>>>>>>>>>>>>> But i am not getting an image either. >>>>>>>>>>>>>>> Unfortunatly i do not have my oscilloscope with me. So i >>>>>>>>>>>>>>> cannot check if there is a signal, but i guess not. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Option1 B >>>>>>>>>>>>>>> @@ -675,7 +675,7 @@ dphy: phy@5451000 { >>>>>>>>>>>>>>> reg = <0x5451000 0x1000>; >>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>> - <&ccu CLK_MIPI_DSI>; >>>>>>>>>>>>>>> + <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is not ok either. >>>>>>>>>>>>>>> sun6i-mipi-dphy 5451000.phy: Couldn't get the DPHY mod clock >>>>>>>>>>>>>>> sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ultimatly i tested to use Option 2 with Option 1. So both >>>>>>>>>>>>>>> DSI and PHY get the modclock from top, but with the right index. >>>>>>>>>>>>>>> @@ -655,7 +655,7 @@ dsi: dsi@5450000 { >>>>>>>>>>>>>>> reg = <0x5450000 0x1000>; >>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>> - <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>>>>>> + <&tcon_top 1>; >>>>>>>>>>>>>>> clock-names = "bus", "mod"; >>>>>>>>>>>>>>> resets = <&ccu RST_BUS_MIPI_DSI>; >>>>>>>>>>>>>>> phys = <&dphy>; >>>>>>>>>>>>>>> @@ -675,7 +675,7 @@ dphy: phy@5451000 { >>>>>>>>>>>>>>> reg = <0x5451000 0x1000>; >>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>> - <&ccu CLK_MIPI_DSI>; >>>>>>>>>>>>>>> + <&tcon_top 1>; >>>>>>>>>>>>>>> clock-names = "bus", "mod"; >>>>>>>>>>>>>>> resets = <&ccu RST_BUS_MIPI_DSI>; >>>>>>>>>>>>>>> #phy-cells = <0>; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> sun6i-mipi-dphy 5451000.phy: Couldn't get the DPHY mod clock >>>>>>>>>>>>>>> sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So all options are not working. I will check some more >>>>>>>>>>>>>>> tomorrow. If you have another idea - i would be happy to test., >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All the best >>>>>>>>>>>>>>> Jakob >>>>>>>>>>>>>>> K. James schrieb am Freitag, 29. Dezember 2023 um 03:48:37 >>>>>>>>>>>>>>> UTC+1: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Apologies for the bad etiquette - I didn't realise the copy >>>>>>>>>>>>>>>> paste from bootlin would put so much HTML. I will strip the >>>>>>>>>>>>>>>> formatting from >>>>>>>>>>>>>>>> my messages in the future. >>>>>>>>>>>>>>>> I am away from my desk and devkit for a few days, but I >>>>>>>>>>>>>>>> think I could have narrowed it down to two issues: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) Clock is wrong source - according to the device tree the >>>>>>>>>>>>>>>> mod clock for the DSI interface is from TCON_TOP as you >>>>>>>>>>>>>>>> mention, and from >>>>>>>>>>>>>>>> the patchset "[PATCH v2 1/4] dt-bindings: display: sun6i-dsi: >>>>>>>>>>>>>>>> Fix clock >>>>>>>>>>>>>>>> conditional" >>>>>>>>>>>>>>>> Samuel makes the following point: "the module clock routes >>>>>>>>>>>>>>>> through the TCON TOP". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the device tree has the following: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> dsi: dsi@5450000 { >>>>>>>>>>>>>>>> compatible = "allwinner,sun20i-d1-mipi-dsi", >>>>>>>>>>>>>>>> "allwinner,sun50i-a100-mipi-dsi"; >>>>>>>>>>>>>>>> reg = <0x5450000 0x1000>; >>>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>>> <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>>>>>>> clock-names = "bus", "mod"; >>>>>>>>>>>>>>>> resets = <&ccu RST_BUS_MIPI_DSI>; >>>>>>>>>>>>>>>> phys = <&dphy>; >>>>>>>>>>>>>>>> phy-names = "dphy"; >>>>>>>>>>>>>>>> status = "disabled"; >>>>>>>>>>>>>>>> }; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> dphy: phy@5451000 { >>>>>>>>>>>>>>>> compatible = "allwinner,sun20i-d1-mipi-dphy", >>>>>>>>>>>>>>>> "allwinner,sun50i-a100-mipi-dphy"; >>>>>>>>>>>>>>>> reg = <0x5451000 0x1000>; >>>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>>> <&ccu CLK_MIPI_DSI>; >>>>>>>>>>>>>>>> clock-names = "bus", "mod"; >>>>>>>>>>>>>>>> resets = <&ccu RST_BUS_MIPI_DSI>; >>>>>>>>>>>>>>>> #phy-cells = <0>; >>>>>>>>>>>>>>>> }; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In this case the DPHY is getting its clock from the CCU >>>>>>>>>>>>>>>> node "CLK_MIPI_DSI" instead of TCON TOP, so one of the >>>>>>>>>>>>>>>> following cases >>>>>>>>>>>>>>>> could be true: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > The DSI node should get its mod clock from CCU >>>>>>>>>>>>>>>> CLK_MIPI_DSI and the TCON_TOP CLK_TCON_TOP_DSI clock source is >>>>>>>>>>>>>>>> incorrect, or >>>>>>>>>>>>>>>> > The DPHY should get its mod clock from TCON_TOP >>>>>>>>>>>>>>>> CLK_TCON_TOP_DSI and the ccu CLK_MIPI_DSI source is incorrect, >>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>> > These clock sources are correct and there is some other >>>>>>>>>>>>>>>> issue (such as below). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) alternatively, it could be just a quirk of the D1/T113 >>>>>>>>>>>>>>>> TCON TOP setup. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I also had found this in reviewing the devicetree for this >>>>>>>>>>>>>>>> board - the patchset "[PATCH v2 00/14] drm/sun4i: Allwinner D1 >>>>>>>>>>>>>>>> Display >>>>>>>>>>>>>>>> Engine 2.0 Support" includes the TCON Top Support the >>>>>>>>>>>>>>>> following note: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [PATCH v2 12/14] drm/sun4i: Add support for D1 TCON TOP >>>>>>>>>>>>>>>> "D1 has a TCON TOP with TCON TV0 and DSI, but no TCON TV1. >>>>>>>>>>>>>>>> This puts theDSI clock name at index 1 in clock-output-names. >>>>>>>>>>>>>>>> Support this >>>>>>>>>>>>>>>> by only incrementing the index for clocks that are actually >>>>>>>>>>>>>>>> supported." >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But reviewing the DSI node: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> dsi: dsi@5450000 { >>>>>>>>>>>>>>>> compatible = "allwinner,sun20i-d1-mipi-dsi", >>>>>>>>>>>>>>>> "allwinner,sun50i-a100-mipi-dsi"; >>>>>>>>>>>>>>>> reg = <0x5450000 0x1000>; >>>>>>>>>>>>>>>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>; >>>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>>> <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>>>>>>> clock-names = "bus", "mod"; >>>>>>>>>>>>>>>> resets = <&ccu RST_BUS_MIPI_DSI>; >>>>>>>>>>>>>>>> phys = <&dphy>; >>>>>>>>>>>>>>>> phy-names = "dphy"; >>>>>>>>>>>>>>>> status = "disabled"; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the definition of CLK_TCON_TOP_DSI comes from >>>>>>>>>>>>>>>> sun8i-tcon-top.h: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ >>>>>>>>>>>>>>>> /* Copyright (C) 2018 Jernej Skrabec <jernej....@siol.net> >>>>>>>>>>>>>>>> */ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> #ifndef _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ >>>>>>>>>>>>>>>> #define _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> #define CLK_TCON_TOP_TV0 0 >>>>>>>>>>>>>>>> #define CLK_TCON_TOP_TV1 1 >>>>>>>>>>>>>>>> #define CLK_TCON_TOP_DSI 2 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> #endif /* _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ */ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I believe, if that the quirk of the D1s correct to the >>>>>>>>>>>>>>>> above comment, the incorrect clock index is being selected in >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> devicetree which would also cause the failure. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In which case: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, <&tcon_top 1>; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> clock-names = "bus", "mod"; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> would be a sufficient fix without updating the >>>>>>>>>>>>>>>> header/source. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Either case as soon as I am back with my devkit, I would >>>>>>>>>>>>>>>> try this for sure and try and see if I can find an answer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >You can check /sys/kernel/debug/clk/clk_summary (with >>>>>>>>>>>>>>>> debugfs mounted) >>>>>>>>>>>>>>>> >to see what clocks are there and how they are used >>>>>>>>>>>>>>>> Also great information, I will test. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thursday 28 December 2023 at 9:59:09 am UTC+10:30 Andre >>>>>>>>>>>>>>>> Przywara wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, 26 Dec 2023 19:00:58 -0800 (PST) >>>>>>>>>>>>>>>>> "K. James" <kirby.n...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> please try to avoid HTML email on lists, that makes it >>>>>>>>>>>>>>>>> hard to reply >>>>>>>>>>>>>>>>> inline and messes up the text view - and there is little >>>>>>>>>>>>>>>>> need to provide >>>>>>>>>>>>>>>>> links to every identifier anyway. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Hi All, >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Been working on getting T113-s3 on mainline as I prepare >>>>>>>>>>>>>>>>> to update a >>>>>>>>>>>>>>>>> > project from a v3s. One of the benefits has been the >>>>>>>>>>>>>>>>> ability to move from a >>>>>>>>>>>>>>>>> > 18bit RGB LCD to a MIPI-DSI display, with the interface >>>>>>>>>>>>>>>>> available on the >>>>>>>>>>>>>>>>> > T113-s3 , which has given some better display choices. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > The DSI driver was on mainline from 6.2, however >>>>>>>>>>>>>>>>> building from sources on >>>>>>>>>>>>>>>>> > init I am getting the following error: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > *"sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod >>>>>>>>>>>>>>>>> clock"* >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Its tripping at the following init in sun6i_mipi_dsi.c >>>>>>>>>>>>>>>>> > < >>>>>>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.6.2/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L1155> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > if (variant-> has_mod_clk) { >>>>>>>>>>>>>>>>> > dsi->mod_clk = devm_clk_get(dev, "mod"); >>>>>>>>>>>>>>>>> > if (IS_ERR (dsi->mod_clk)) { >>>>>>>>>>>>>>>>> > dev_err(dev, "Couldn't get the DSI mod clock\n"); >>>>>>>>>>>>>>>>> > ret = PTR_ERR(dsi->mod_clk); >>>>>>>>>>>>>>>>> > goto err_attach_clk; >>>>>>>>>>>>>>>>> >} >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But since this comes from the DSI driver, this refers to >>>>>>>>>>>>>>>>> the DT node of >>>>>>>>>>>>>>>>> the DSI device, not the DE2 clock, doesn't it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > The display modclock is registered from the following >>>>>>>>>>>>>>>>> DTS node in >>>>>>>>>>>>>>>>> > sunxi-d1s-t113.dtsi >>>>>>>>>>>>>>>>> > < >>>>>>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.6.2/source/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi#L641> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > display_clocks: clock-controller@5000000 { >>>>>>>>>>>>>>>>> > compatible = "allwinner,sun20i-d1-de2-clk", >>>>>>>>>>>>>>>>> > "allwinner,sun50i-h5-de2-clk"; >>>>>>>>>>>>>>>>> > reg = <0x5000000 0x10000>; >>>>>>>>>>>>>>>>> > clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>; >>>>>>>>>>>>>>>>> > clock-names = "bus", *"mod"*; >>>>>>>>>>>>>>>>> > resets = <&ccu RST_BUS_DE>; >>>>>>>>>>>>>>>>> > #clock-cells = <1>; >>>>>>>>>>>>>>>>> > #reset-cells = <1>; >>>>>>>>>>>>>>>>> > }; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So those are the clocks from: >>>>>>>>>>>>>>>>> dsi: dsi@5450000 { >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> clocks = <&ccu CLK_BUS_MIPI_DSI>, >>>>>>>>>>>>>>>>> <&tcon_top CLK_TCON_TOP_DSI>; >>>>>>>>>>>>>>>>> clock-names = "bus", "mod"; >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> }; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So the "mod" clock here points to the tcon_top device, the >>>>>>>>>>>>>>>>> one with the >>>>>>>>>>>>>>>>> "allwinner,sun20i-d1-tcon-top" compatible string. Which is >>>>>>>>>>>>>>>>> implemented >>>>>>>>>>>>>>>>> by drivers/gpu/drm/sun4i/sun8i_tcon_top.c, controlled by >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> DRM_SUN8I_TCON_TOP Kconfig symbol. Do you have that >>>>>>>>>>>>>>>>> enabled? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You can check /sys/kernel/debug/clk/clk_summary (with >>>>>>>>>>>>>>>>> debugfs mounted) >>>>>>>>>>>>>>>>> to see what clocks are there and how they are used. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>> Andre >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > I checked the buildroot config and the CCU for sun8i DE2 >>>>>>>>>>>>>>>>> is being >>>>>>>>>>>>>>>>> > built and included, the registration should occur and >>>>>>>>>>>>>>>>> give an >>>>>>>>>>>>>>>>> > exception if it's not happening: ccu-sun8i-de2.c >>>>>>>>>>>>>>>>> > < >>>>>>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.6.2/source/drivers/clk/sunxi-ng/ccu-sun8i-de2.c#L263> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > mod_clk < >>>>>>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk> >>>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>>> > devm_clk_get >>>>>>>>>>>>>>>>> > < >>>>>>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.6.2/C/ident/devm_clk_get>( >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > &pdev->dev, "mod"); if (IS_ERR >>>>>>>>>>>>>>>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/IS_ERR>(mod_clk >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>)) >>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>> > dev_err_probe >>>>>>>>>>>>>>>>> > < >>>>>>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.6.2/C/ident/dev_err_probe>(&pdev->dev, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > PTR_ERR >>>>>>>>>>>>>>>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/PTR_ERR>(mod_clk >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>), >>>>>>>>>>>>>>>>> "Couldn't >>>>>>>>>>>>>>>>> > get mod clk\n"); >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > ret = clk_prepare_enable >>>>>>>>>>>>>>>>> > < >>>>>>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.6.2/C/ident/clk_prepare_enable>(mod_clk >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>); >>>>>>>>>>>>>>>>> if (ret) >>>>>>>>>>>>>>>>> > { dev_err >>>>>>>>>>>>>>>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/dev_err>(&pdev->dev >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > , "Couldn't enable mod clk: %d\n", ret); goto >>>>>>>>>>>>>>>>> err_disable_bus_clk; } >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > I don't see dmesg print any clock errors, but at the >>>>>>>>>>>>>>>>> same time, I >>>>>>>>>>>>>>>>> > understand that linux common clock framework also won't >>>>>>>>>>>>>>>>> print >>>>>>>>>>>>>>>>> > anything by default. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > I can't see anything in either driver that would cause >>>>>>>>>>>>>>>>> an error other >>>>>>>>>>>>>>>>> > than the clock not existing, if anyone has any ideas - >>>>>>>>>>>>>>>>> i'm all ears. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > At the moment I am leaning towards the clock-controller; >>>>>>>>>>>>>>>>> Is there a >>>>>>>>>>>>>>>>> > userspace or debug option to check (mod) clock status' >>>>>>>>>>>>>>>>> under the >>>>>>>>>>>>>>>>> > common clock framework? >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> You received this message because you are subscribed to a >>>>>>>>>>>>>>> topic in the Google Groups "linux-sunxi" group. >>>>>>>>>>>>>>> To unsubscribe from this topic, visit >>>>>>>>>>>>>>> https://groups.google.com/d/topic/linux-sunxi/HxDBpY5HbbQ/unsubscribe >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> To unsubscribe from this group and all its topics, send an >>>>>>>>>>>>>>> email to linux-sunxi...@googlegroups.com. >>>>>>>>>>>>>>> To view this discussion on the web, visit >>>>>>>>>>>>>>> https://groups.google.com/d/msgid/linux-sunxi/02e9453d-7335-4499-933b-ac5038e41bbcn%40googlegroups.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/linux-sunxi/02e9453d-7335-4499-933b-ac5038e41bbcn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/5d7c8282-532f-4ef8-893e-741d93c6373en%40googlegroups.com.
