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/929373b1-7727-4126-8c3c-4b9ad629dda3n%40googlegroups.com.
