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