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/689a235a-ea85-4fba-857d-42cf542ff3e4n%40googlegroups.com.
