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/e3a1e436-9112-46aa-8737-984dc85de412n%40googlegroups.com.