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 [email protected] 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 [email protected] >>>> 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 >>>>>>>> [email protected] 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 <[email protected]> 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 <[email protected]> */ >>>>>>>>>>>> >>>>>>>>>>>> #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" <[email protected]> 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 [email protected]. >>>>>>>>>>> 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/790efd08-5315-41e6-9807-0cbbc03a1855n%40googlegroups.com.
