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