Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[hooray]

Hello everyone,

Recently, I have been trying to use the mainline kernel to drive an MIPI 
screen on the T113-S3. I’m using kernel version linux-6.11.4, and the 
development board is the mangopi-mq-r-t113.

I also encountered the MIPI-DSI Driver issue: "sun6i-mipi-dsi 545.dsi: 
Couldn't get the DSI mod clock". Later, I followed Jakob's solution and 
modified the drivers/gpu/drm/sun4i/sun8i_tcon_top.c file, and this issue no 
longer occurred.

My next step is to modify the DTS file to add the DSI MIPI display 
information.

At this stage, I ran into some issues. Could anyone share how they added 
the display information to their DTS file?

Also, James mentioned that John Watts’ patch has mostly resolved the 
display issue. Could you share the contents of the patch?

Thank you very much!

在2024年6月29日星期六 UTC+8 07:11:25 写道：

> Hi James,
> seem like sunxi is always worked on in the night shift.
> Just saw it as well. Will try it...
>
> Thanks!
> Jakob
>
> K. James schrieb am Samstag, 29. Juni 2024 um 00:55:27 UTC+2:
>
>> Check out the patch that John Watts just sent out (you were included).
>>
>> This patch seems to fix all the tint issues.
>>
>> On Saturday 29 June 2024 at 8:52:55 am UTC+10 jakob...@gmail.com wrote:
>>
>>> Hi James,
>>> indeed this patch looks like it handles my solution properly...
>>> Will give it a try.
>>>
>>> Had just built new gstreamer 1.24 and patched in video node for T113 
>>> using the one from D1. 
>>> Including this patch i get it to probe. 
>>>
>>> https://patchwork.kernel.org/project/linux-media/patch/20221231164628...@sholland.org/
>>>  
>>> 
>>>
>>> But the screen stays blank, no error in gst-launch, but not image 
>>> either. fb0 emualtion works still.
>>>
>>> Some if my patches introduced a new color, now most of the time the 
>>> sytem boots with a pink tint.
>>>
>>> Will probably take some more months to fix this ;)
>>>
>>> K. James schrieb am Freitag, 28. Juni 2024 um 01:50:22 UTC+2:
>>>

 No, not using with gstreamer.

 Also the tcon-top pipeline is very similar to the R40, there is a DSI 
 patch for the R40 that has never been committed (still some issues) but 
 based on the testing I have done, it might also solve the D1 
 implementation 
 issues that you "patched" above:

 https://patchwork.freedesktop.org/patch/347129/?series=62062&rev=3


 On Friday 28 June 2024 at 8:43:23 am UTC+10 jakob...@gmail.com wrote:

> Hi James, oh that is brilliant. A friend of mine was doing some 
> debugging on the DSI via  a seld made FPGA analyser.The packets looked 
> fine.
> But the mixer is indeed the problem...
>
> Did you use the T113 with gstreamer - by any chance? 
>
>
>
> K. James schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2:
>
>> Hey Jakob,
>>
>> Jookia was dealing with something similar on IRC (except a blue 
>> tint). Some experimentation yielded a result for us both.
>>
>> Completely removing Mixer1 definition from the device tree and the 
>> tinting is gone.
>>
>> Patch here:
>> https://paste.xogium.me/pn.txt
>>
>> Maybe try it on your DSI implementation and let us know? 
>>
>> On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote:
>>
>>> Hey Jakob,
>>>
>>> I didn't proceed with testing the DSI on T113-S3, but I have 
>>> attempted to get the RGB output working. I have had "mixed" success. I 
>>> can 
>>> get the display initialising and a directfb test runs.
>>>
>>> But it *also* has a green tinge over the whole display, which is 
>>> consistent and I cannot fathom why.
>>>
>>> It must be device related, because the exact same kernel, driver (+ 
>>> init code), display works perfectly on my v3s test setup.
>>>
>>> So frustrating!! Did you have any further progress?
>>>
>>>
>>>
>>> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com 
>>> wrote:
>>>
 Hi James, 

 were you able to test the patches? It unfortunalty seems like this 
 isn't the only problem. On about 50% of the cold boots i get a green 
 tinted 
 image on the screen. Its working, but everything is greenish (blacks 
 and 
 also whites).
 Probably has to do with the wrong clocks or wrong dsi packager 
 setup? We also tested the patches that Frank Oltmanns posted in 
 this thread https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
 Does anybody know why the calculation of timings is so much 
 different than what the BSP of T113 does?

 Thanks!
 Jakob

 Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:

> Hi James,
>
> yes, exactly. The patch forces the tcon

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

Hi James,
seem like sunxi is always worked on in the night shift.
Just saw it as well. Will try it...

Thanks!
Jakob

K. James schrieb am Samstag, 29. Juni 2024 um 00:55:27 UTC+2:

> Check out the patch that John Watts just sent out (you were included).
>
> This patch seems to fix all the tint issues.
>
> On Saturday 29 June 2024 at 8:52:55 am UTC+10 jakob...@gmail.com wrote:
>
>> Hi James,
>> indeed this patch looks like it handles my solution properly...
>> Will give it a try.
>>
>> Had just built new gstreamer 1.24 and patched in video node for T113 
>> using the one from D1. 
>> Including this patch i get it to probe. 
>>
>> https://patchwork.kernel.org/project/linux-media/patch/20221231164628...@sholland.org/
>>  
>> 
>>
>> But the screen stays blank, no error in gst-launch, but not image either. 
>> fb0 emualtion works still.
>>
>> Some if my patches introduced a new color, now most of the time the sytem 
>> boots with a pink tint.
>>
>> Will probably take some more months to fix this ;)
>>
>> K. James schrieb am Freitag, 28. Juni 2024 um 01:50:22 UTC+2:
>>
>>>
>>> No, not using with gstreamer.
>>>
>>> Also the tcon-top pipeline is very similar to the R40, there is a DSI 
>>> patch for the R40 that has never been committed (still some issues) but 
>>> based on the testing I have done, it might also solve the D1 implementation 
>>> issues that you "patched" above:
>>>
>>> https://patchwork.freedesktop.org/patch/347129/?series=62062&rev=3
>>>
>>>
>>> On Friday 28 June 2024 at 8:43:23 am UTC+10 jakob...@gmail.com wrote:
>>>
 Hi James, oh that is brilliant. A friend of mine was doing some 
 debugging on the DSI via  a seld made FPGA analyser.The packets looked 
 fine.
 But the mixer is indeed the problem...

 Did you use the T113 with gstreamer - by any chance? 



 K. James schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2:

> Hey Jakob,
>
> Jookia was dealing with something similar on IRC (except a blue tint). 
> Some experimentation yielded a result for us both.
>
> Completely removing Mixer1 definition from the device tree and the 
> tinting is gone.
>
> Patch here:
> https://paste.xogium.me/pn.txt
>
> Maybe try it on your DSI implementation and let us know? 
>
> On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote:
>
>> Hey Jakob,
>>
>> I didn't proceed with testing the DSI on T113-S3, but I have 
>> attempted to get the RGB output working. I have had "mixed" success. I 
>> can 
>> get the display initialising and a directfb test runs.
>>
>> But it *also* has a green tinge over the whole display, which is 
>> consistent and I cannot fathom why.
>>
>> It must be device related, because the exact same kernel, driver (+ 
>> init code), display works perfectly on my v3s test setup.
>>
>> So frustrating!! Did you have any further progress?
>>
>>
>>
>> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com 
>> wrote:
>>
>>> Hi James, 
>>>
>>> were you able to test the patches? It unfortunalty seems like this 
>>> isn't the only problem. On about 50% of the cold boots i get a green 
>>> tinted 
>>> image on the screen. Its working, but everything is greenish (blacks 
>>> and 
>>> also whites).
>>> Probably has to do with the wrong clocks or wrong dsi packager 
>>> setup? We also tested the patches that Frank Oltmanns posted in 
>>> this thread https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
>>> Does anybody know why the calculation of timings is so much 
>>> different than what the BSP of T113 does?
>>>
>>> Thanks!
>>> Jakob
>>>
>>> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:
>>>
 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";
 +};
 

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[K. James]

Check out the patch that John Watts just sent out (you were included).

This patch seems to fix all the tint issues.

On Saturday 29 June 2024 at 8:52:55 am UTC+10 jakob...@gmail.com wrote:

> Hi James,
> indeed this patch looks like it handles my solution properly...
> Will give it a try.
>
> Had just built new gstreamer 1.24 and patched in video node for T113 using 
> the one from D1. 
> Including this patch i get it to probe. 
>
> https://patchwork.kernel.org/project/linux-media/patch/20221231164628...@sholland.org/
>  
> 
>
> But the screen stays blank, no error in gst-launch, but not image either. 
> fb0 emualtion works still.
>
> Some if my patches introduced a new color, now most of the time the sytem 
> boots with a pink tint.
>
> Will probably take some more months to fix this ;)
>
> K. James schrieb am Freitag, 28. Juni 2024 um 01:50:22 UTC+2:
>
>>
>> No, not using with gstreamer.
>>
>> Also the tcon-top pipeline is very similar to the R40, there is a DSI 
>> patch for the R40 that has never been committed (still some issues) but 
>> based on the testing I have done, it might also solve the D1 implementation 
>> issues that you "patched" above:
>>
>> https://patchwork.freedesktop.org/patch/347129/?series=62062&rev=3
>>
>>
>> On Friday 28 June 2024 at 8:43:23 am UTC+10 jakob...@gmail.com wrote:
>>
>>> Hi James, oh that is brilliant. A friend of mine was doing some 
>>> debugging on the DSI via  a seld made FPGA analyser.The packets looked fine.
>>> But the mixer is indeed the problem...
>>>
>>> Did you use the T113 with gstreamer - by any chance? 
>>>
>>>
>>>
>>> K. James schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2:
>>>
 Hey Jakob,

 Jookia was dealing with something similar on IRC (except a blue tint). 
 Some experimentation yielded a result for us both.

 Completely removing Mixer1 definition from the device tree and the 
 tinting is gone.

 Patch here:
 https://paste.xogium.me/pn.txt

 Maybe try it on your DSI implementation and let us know? 

 On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote:

> Hey Jakob,
>
> I didn't proceed with testing the DSI on T113-S3, but I have attempted 
> to get the RGB output working. I have had "mixed" success. I can get the 
> display initialising and a directfb test runs.
>
> But it *also* has a green tinge over the whole display, which is 
> consistent and I cannot fathom why.
>
> It must be device related, because the exact same kernel, driver (+ 
> init code), display works perfectly on my v3s test setup.
>
> So frustrating!! Did you have any further progress?
>
>
>
> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com 
> wrote:
>
>> Hi James, 
>>
>> were you able to test the patches? It unfortunalty seems like this 
>> isn't the only problem. On about 50% of the cold boots i get a green 
>> tinted 
>> image on the screen. Its working, but everything is greenish (blacks and 
>> also whites).
>> Probably has to do with the wrong clocks or wrong dsi packager setup? 
>> We also tested the patches that Frank Oltmanns posted in this thread 
>> https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
>> Does anybody know why the calculation of timings is so much different 
>> than what the BSP of T113 does?
>>
>> Thanks!
>> Jakob
>>
>> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:
>>
>>> 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 

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

Hi James,
indeed this patch looks like it handles my solution properly...
Will give it a try.

Had just built new gstreamer 1.24 and patched in video node for T113 using 
the one from D1. 
Including this patch i get it to probe. 
https://patchwork.kernel.org/project/linux-media/patch/20221231164628.19688-4-sam...@sholland.org/

But the screen stays blank, no error in gst-launch, but not image either. 
fb0 emualtion works still.

Some if my patches introduced a new color, now most of the time the sytem 
boots with a pink tint.

Will probably take some more months to fix this ;)

K. James schrieb am Freitag, 28. Juni 2024 um 01:50:22 UTC+2:

>
> No, not using with gstreamer.
>
> Also the tcon-top pipeline is very similar to the R40, there is a DSI 
> patch for the R40 that has never been committed (still some issues) but 
> based on the testing I have done, it might also solve the D1 implementation 
> issues that you "patched" above:
>
> https://patchwork.freedesktop.org/patch/347129/?series=62062&rev=3
>
>
> On Friday 28 June 2024 at 8:43:23 am UTC+10 jakob...@gmail.com wrote:
>
>> Hi James, oh that is brilliant. A friend of mine was doing some debugging 
>> on the DSI via  a seld made FPGA analyser.The packets looked fine.
>> But the mixer is indeed the problem...
>>
>> Did you use the T113 with gstreamer - by any chance? 
>>
>>
>>
>> K. James schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2:
>>
>>> Hey Jakob,
>>>
>>> Jookia was dealing with something similar on IRC (except a blue tint). 
>>> Some experimentation yielded a result for us both.
>>>
>>> Completely removing Mixer1 definition from the device tree and the 
>>> tinting is gone.
>>>
>>> Patch here:
>>> https://paste.xogium.me/pn.txt
>>>
>>> Maybe try it on your DSI implementation and let us know? 
>>>
>>> On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote:
>>>
 Hey Jakob,

 I didn't proceed with testing the DSI on T113-S3, but I have attempted 
 to get the RGB output working. I have had "mixed" success. I can get the 
 display initialising and a directfb test runs.

 But it *also* has a green tinge over the whole display, which is 
 consistent and I cannot fathom why.

 It must be device related, because the exact same kernel, driver (+ 
 init code), display works perfectly on my v3s test setup.

 So frustrating!! Did you have any further progress?



 On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com 
 wrote:

> Hi James, 
>
> were you able to test the patches? It unfortunalty seems like this 
> isn't the only problem. On about 50% of the cold boots i get a green 
> tinted 
> image on the screen. Its working, but everything is greenish (blacks and 
> also whites).
> Probably has to do with the wrong clocks or wrong dsi packager setup? 
> We also tested the patches that Frank Oltmanns posted in this thread 
> https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
> Does anybody know why the calculation of timings is so much different 
> than what the BSP of T113 does?
>
> Thanks!
> Jakob
>
> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:
>
>> 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 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 upstre

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[K. James]

No, not using with gstreamer.

Also the tcon-top pipeline is very similar to the R40, there is a DSI patch 
for the R40 that has never been committed (still some issues) but based on 
the testing I have done, it might also solve the D1 implementation issues 
that you "patched" above:

https://patchwork.freedesktop.org/patch/347129/?series=62062&rev=3


On Friday 28 June 2024 at 8:43:23 am UTC+10 jakob...@gmail.com wrote:

> Hi James, oh that is brilliant. A friend of mine was doing some debugging 
> on the DSI via  a seld made FPGA analyser.The packets looked fine.
> But the mixer is indeed the problem...
>
> Did you use the T113 with gstreamer - by any chance? 
>
>
>
> K. James schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2:
>
>> Hey Jakob,
>>
>> Jookia was dealing with something similar on IRC (except a blue tint). 
>> Some experimentation yielded a result for us both.
>>
>> Completely removing Mixer1 definition from the device tree and the 
>> tinting is gone.
>>
>> Patch here:
>> https://paste.xogium.me/pn.txt
>>
>> Maybe try it on your DSI implementation and let us know? 
>>
>> On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote:
>>
>>> Hey Jakob,
>>>
>>> I didn't proceed with testing the DSI on T113-S3, but I have attempted 
>>> to get the RGB output working. I have had "mixed" success. I can get the 
>>> display initialising and a directfb test runs.
>>>
>>> But it *also* has a green tinge over the whole display, which is 
>>> consistent and I cannot fathom why.
>>>
>>> It must be device related, because the exact same kernel, driver (+ init 
>>> code), display works perfectly on my v3s test setup.
>>>
>>> So frustrating!! Did you have any further progress?
>>>
>>>
>>>
>>> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com 
>>> wrote:
>>>
 Hi James, 

 were you able to test the patches? It unfortunalty seems like this 
 isn't the only problem. On about 50% of the cold boots i get a green 
 tinted 
 image on the screen. Its working, but everything is greenish (blacks and 
 also whites).
 Probably has to do with the wrong clocks or wrong dsi packager setup? 
 We also tested the patches that Frank Oltmanns posted in this thread 
 https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
 Does anybody know why the calculation of timings is so much different 
 than what the BSP of T113 does?

 Thanks!
 Jakob

 Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:

> 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 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)

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

Hi James, oh that is brilliant. A friend of mine was doing some debugging 
on the DSI via  a seld made FPGA analyser.The packets looked fine.
But the mixer is indeed the problem...

Did you use the T113 with gstreamer - by any chance? 



K. James schrieb am Mittwoch, 12. Juni 2024 um 08:15:37 UTC+2:

> Hey Jakob,
>
> Jookia was dealing with something similar on IRC (except a blue tint). 
> Some experimentation yielded a result for us both.
>
> Completely removing Mixer1 definition from the device tree and the tinting 
> is gone.
>
> Patch here:
> https://paste.xogium.me/pn.txt
>
> Maybe try it on your DSI implementation and let us know? 
>
> On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote:
>
>> Hey Jakob,
>>
>> I didn't proceed with testing the DSI on T113-S3, but I have attempted to 
>> get the RGB output working. I have had "mixed" success. I can get the 
>> display initialising and a directfb test runs.
>>
>> But it *also* has a green tinge over the whole display, which is 
>> consistent and I cannot fathom why.
>>
>> It must be device related, because the exact same kernel, driver (+ init 
>> code), display works perfectly on my v3s test setup.
>>
>> So frustrating!! Did you have any further progress?
>>
>>
>>
>> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com 
>> wrote:
>>
>>> Hi James, 
>>>
>>> were you able to test the patches? It unfortunalty seems like this isn't 
>>> the only problem. On about 50% of the cold boots i get a green tinted image 
>>> on the screen. Its working, but everything is greenish (blacks and also 
>>> whites).
>>> Probably has to do with the wrong clocks or wrong dsi packager setup? We 
>>> also tested the patches that Frank Oltmanns posted in this thread 
>>> https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
>>> Does anybody know why the calculation of timings is so much different 
>>> than what the BSP of T113 does?
>>>
>>> Thanks!
>>> Jakob
>>>
>>> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:
>>>
 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 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);
>> +
>> +

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[K. James]

Hey Jakob,

Jookia was dealing with something similar on IRC (except a blue tint). Some 
experimentation yielded a result for us both.

Completely removing Mixer1 definition from the device tree and the tinting 
is gone.

Patch here:
https://paste.xogium.me/pn.txt

Maybe try it on your DSI implementation and let us know? 

On Wednesday 12 June 2024 at 8:38:36 am UTC+10 K. James wrote:

> Hey Jakob,
>
> I didn't proceed with testing the DSI on T113-S3, but I have attempted to 
> get the RGB output working. I have had "mixed" success. I can get the 
> display initialising and a directfb test runs.
>
> But it *also* has a green tinge over the whole display, which is 
> consistent and I cannot fathom why.
>
> It must be device related, because the exact same kernel, driver (+ init 
> code), display works perfectly on my v3s test setup.
>
> So frustrating!! Did you have any further progress?
>
>
>
> On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com wrote:
>
>> Hi James, 
>>
>> were you able to test the patches? It unfortunalty seems like this isn't 
>> the only problem. On about 50% of the cold boots i get a green tinted image 
>> on the screen. Its working, but everything is greenish (blacks and also 
>> whites).
>> Probably has to do with the wrong clocks or wrong dsi packager setup? We 
>> also tested the patches that Frank Oltmanns posted in this thread 
>> https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
>> Does anybody know why the calculation of timings is so much different 
>> than what the BSP of T113 does?
>>
>> Thanks!
>> Jakob
>>
>> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:
>>
>>> 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 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.968

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[K. James]

Hey Jakob,

I didn't proceed with testing the DSI on T113-S3, but I have attempted to 
get the RGB output working. I have had "mixed" success. I can get the 
display initialising and a directfb test runs.

But it *also* has a green tinge over the whole display, which is consistent 
and I cannot fathom why.

It must be device related, because the exact same kernel, driver (+ init 
code), display works perfectly on my v3s test setup.

So frustrating!! Did you have any further progress?



On Monday 26 February 2024 at 11:57:30 pm UTC+10 jakob...@gmail.com wrote:

> Hi James, 
>
> were you able to test the patches? It unfortunalty seems like this isn't 
> the only problem. On about 50% of the cold boots i get a green tinted image 
> on the screen. Its working, but everything is greenish (blacks and also 
> whites).
> Probably has to do with the wrong clocks or wrong dsi packager setup? We 
> also tested the patches that Frank Oltmanns posted in this thread 
> https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
> Does anybody know why the calculation of timings is so much different than 
> what the BSP of T113 does?
>
> Thanks!
> Jakob
>
> Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:
>
>> 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 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 545.dsi: supply vcc-dsi not found, 
> using dummy regulator
> [2.403074] sun6i-mipi-dsi 545.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

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

Hi James, 

were you able to test the patches? It unfortunalty seems like this isn't 
the only problem. On about 50% of the cold boots i get a green tinted image 
on the screen. Its working, but everything is greenish (blacks and also 
whites).
Probably has to do with the wrong clocks or wrong dsi packager setup? We 
also tested the patches that Frank Oltmanns posted in this thread 
https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
Does anybody know why the calculation of timings is so much different than 
what the BSP of T113 does?

Thanks!
Jakob

Jakob L schrieb am Montag, 29. Januar 2024 um 12:35:29 UTC+1:

> 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 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 545.dsi: supply vcc-dsi not found, 
 using dummy regulator
 [2.403074] sun6i-mipi-dsi 545.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@545 {
>
>   reg = <0x545 0x1000

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

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 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 545.dsi: supply vcc-dsi not found, 
>>> using dummy regulator
>>> [2.403074] sun6i-mipi-dsi 545.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@545 {

   reg = <0x545 0x1000>;
   interrupts = ;
   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 0x0020 (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.

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[K. James]

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 545.dsi: supply vcc-dsi not found, 
>> using dummy regulator
>> [2.403074] sun6i-mipi-dsi 545.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@545 {
>>>
>>>   reg = <0x545 0x1000>;
>>>   interrupts = ;
>>>   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 0x0020 (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
dutyhardware
clockcountcountcountrate
  accuracy  phasecycle  enable

 -

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

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 545.dsi: supply vcc-dsi not found, using 
> dummy regulator
> [2.403074] sun6i-mipi-dsi 545.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@545 {
>>
>>   reg = <0x545 0x1000>;
>>   interrupts = ;
>>   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 0x0020 (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
>>>dutyhardware
>>>clockcountcountcountrate  
>>>accuracy  phasecycle  enable
>>>
>>> ---
>>> .
>>> tcon-top-dsi0   00   21600   
>>>0  05 N
>>> .
>>>
>>> bus-mipi-dsi   02   0   2
>>>   0   0   5 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/s

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

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 545.dsi: supply vcc-dsi not found, using 
dummy regulator
[2.403074] sun6i-mipi-dsi 545.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@545 {
>
>   reg = <0x545 0x1000>;
>   interrupts = ;
>   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 0x0020 (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  
>>  dutyhardware
>>clockcountcountcountrate  
>>accuracy  phasecycle  enable
>>
>> ---
>> .
>> tcon-top-dsi0   00   21600   
>>0  05 N
>> .
>>
>> bus-mipi-dsi   02   0   2
>>   0   0   5 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

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

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@545 {

  reg = <0x545 0x1000>;
  interrupts = ;
  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 0x0020 (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  
>  dutyhardware
>clockcountcountcountrate
>  accuracy  phasecycle  enable
>
> ---
> .
> tcon-top-dsi0   00   21600 
>  0  05 N
> .
>
> bus-mipi-dsi   02   0   2  
> 0   0   5 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  countcountcountrate   
>> accuracy phase  cycleenable
>>
>> ---
>>  iosc 1101600 
>>  3 0  5 Y
>> iosc-32k  110   31250 
>>  3 0  5 Y
>>osc32k 110   31250 
>>  3 0  5 Y
>>   hdmi-cec000   31250 
>>  3 0  5 N
>>   r-ir-rx 00 

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[K. James]

Jakob,

Regarding your clock, I don't know which DTS configuration this is from 
however:

enable  prepare  protect
   dutyhardware
   clockcountcountcountrate
 accuracy  phasecycle  enable
---
.
tcon-top-dsi0   00   21600 
 0  05 N
.
bus-mipi-dsi   02   0   2  
0   0   5 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  countcountcountrate   
> accuracy phase  cycleenable
>
> ---
>  iosc 1101600 
>  3 0  5 Y
> iosc-32k  110   31250 
>  3 0  5 Y
>osc32k 110   31250 
>  3 0  5 Y
>   hdmi-cec000   31250 
>  3 0  5 N
>   r-ir-rx 000   31250 
>  3 0  5 N
>   rtc-32k 110   31250 
>  3 0  5 Y
>   osc32k-fanout   000   31250 
>  3 0  5 N
>  dcxo10   1022400 
>  0 0  5 Y
>   pll-ve000   43200   
>0 0  5 N
>ve 000   43200 
>  0 0  5 N
> pll-video1-4x 000  118800 
>  0 0  5 N
>pll-video1 000   29700 
>  0 0  5 Y
>pll-video1-2x  000   59400 
>  0 0  5 Y
> pll-video0-4x 221   86400 
>  0 0  5 Y
>de 330   21600 
>  0 0  5 Y
>   wb-div  000   21600 
>  0 0  5 Y
>  wb   000   21600 
>  0 0  5 N
>   mixer1-div  110   21600 
>  0 0  5 Y
>  mixer1   110   21600 
>  0 0  5 Y
>   mixer0-di

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

The lack of documentation is really bad. Consider TCON TOP has its own 
register space its surely actual hardware. DPHY is also completly 
undocumented. Guess i have to read the bsp code.

Registers for CCU, TCON0, TCON_TOP and DPHY are quite different... 
resetting Modules via CCU and then writing them manually doesnt work. 
But probably i am not doing that in the right order.

Differences i found:
*CCU*
*DSI_BGR_REG 0x02001B4C *
uboot 0x00010001
Kernel 0x0001  //DSI CLOCK is masked 

*TCONLCD_CLK_REG 0x02001B60 *
uboot 0x8100
001: PLL_VIDEO0(4X)
Kernel 0x8000
000: PLL_VIDEO0(1X)

*PLL_VIDEO0_CTRL_REG 0x02001040*
uboot 0xc8001703
Kernel 0xF8002300

*DE_CLK_REG 0x02001600*
uboot 0x8003
000: PLL_PERI(2X)
Kernel 0x8103
001: PLL_VIDEO0(4X)

*TCON0*
*LCD_GINT0_REG  0x05461004*
uboot 0a02
DE_INT_FLAG Enabled
Kernel 0x0A03
DE_INT_FLAG Enabled
FSYNC_INT_FLAG Enabled

*LCD_DCLK_REG 0x05461044*
uboot  0xF004
Kernel 0x8004

*LCD_CPU_IF_REG 0x05461060*
uboot 0001    0101
31:28 CPU MODE xxx1 DSI
Kernel 0001   0001    0101
FLUSH 16 //Direct Transfer mode

*LCD_CPU_TRI0_REG  0x05461160*
uboot  0100  0001 1000 
BLOCK SPACE 27:16  0100
Kernel  0011  0001 1000 

*LCD_CPU_TRI1_REG  0x05461164*
uboot11010100
kernel 01000100

*LCD_CPU_TRI2_REG  0x05461168*
uboot 0001  1011 0011    1010
START_DLY 31:16 4275
SYNC_MODE 14:13 Auto
TRANS_START_SET 12:0 10
Kernel  0110 0111 0011    1010

*LCD_SAFE_PERIOD_REG 0x054611F0*
Uboot  0x021c0003
Kernel 0x0BB80003

*GPIO*
*PORT D 0x02A4 DRIVE STRENGTH*
uboot 0x
Kernel 0x

*DPHY*
*COMBO_PHY_REG 0x05451110 *
uboot 0x000b
kernel 0x

*COMBO_PHY_REG 0x05451114 *
uboot 
kernel 0x

*?? 0x0545111C *
uboot 0x0014
kernel 0x0

*TCON_TOP *
*0x0546001C*
uboot 0x0020
kernel 0x

*0x05460020*
uboot 0x0001
kernel 0x

Will have another look tomorrow, if i can.
Jakob L schrieb am Samstag, 30. Dezember 2023 um 22:53:46 UTC+1:

> 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  countcountcountrate   
> accuracy phase  cycleenable
>
> ---
>  iosc 1101600 
>  3 0  5 Y
> iosc-32k  110   31250 
>  3 0  5 Y
>osc32k 110   31250 
>  3 0  5 Y
>   hdmi-cec000   31250 
>  3 0  5 N
>   r-ir-rx 000   31250 
>  3 0  5 N
>   rtc-32k 110   31250 
>  3 0  5 Y
>   osc32k-fanout   000   31250 
>  3 0  5 N
>  dcxo10   1022400 
>  0 0  5 Y
>   pll-ve000   43200   
>0 0  5 N
>ve 000   43200 
>  0 0  5 N
> pll-video1-4x 000  118800 
>  0 0  5 N
>pll-video1 000   29700 
>  0 0  5 Y
>pll-video1-2x  000 

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

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  countcountcountrate   
accuracy phase  cycleenable
---
 iosc 1101600 
 3 0  5 Y
iosc-32k  110   31250 
 3 0  5 Y
   osc32k 110   31250 
 3 0  5 Y
  hdmi-cec000   31250 
 3 0  5 N
  r-ir-rx 000   31250 
 3 0  5 N
  rtc-32k 110   31250 
 3 0  5 Y
  osc32k-fanout   000   31250 
 3 0  5 N
 dcxo10   1022400   
   0 0  5 Y
  pll-ve000   43200 
 0 0  5 N
   ve 000   43200   
   0 0  5 N
pll-video1-4x 000  118800   
   0 0  5 N
   pll-video1 000   29700   
   0 0  5 Y
   pll-video1-2x  000   59400   
   0 0  5 Y
pll-video0-4x 221   86400   
   0 0  5 Y
   de 330   21600   
   0 0  5 Y
  wb-div  000   21600   
   0 0  5 Y
 wb   000   21600   
   0 0  5 N
  mixer1-div  110   21600   
   0 0  5 Y
 mixer1   110   21600   
   0 0  5 Y
  mixer0-div  110   21600   
   0 0  5 Y
 mixer0   110   21600   
   0 0  5 Y
   pll-video0 111   21600   
   0 0  5 Y
  fanout-27M  000   21600   
   0 0  5 N
  tve 000   21600   
   0 0  5 N
  tcon-tv 000   21600   
   0 0  5 N
 tcon-top-tv0 000   21600   
   0 0  5 N
  tcon-lcd0   221   21600   
   0 0  5 Y
 tcon-pixel-clock 1115400   
   0 0  5 Y
 tcon-top-dsi 000   21600   
   0 0  5 N
   pll-video0-2x  000   43200   
   0 0  5 Y
pll-periph0-4x111  24   
   0 0  5 Y
   pll-periph0-800M   000   8   
   0 0  5 Y
   pll-periph0-2x 111  12   
   0 0  5 Y
  fanout-32k  000   32768   
   0 0

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Kirby Nankivell]

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  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@545 {
>   reg = <0x545 0x1000>;
>   interrupts = ;
>   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 545.dsi: Couldn't get the DSI mod clock
>
> Option1 A
> @@ -655,7 +655,7 @@ dsi: dsi@545 {
>   reg = <0x545 0x1000>;
>   interrupts = ;
>   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 = ;
>   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 545.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@545 {
>   reg = <0x545 0x1000>;
>   interrupts = ;
>   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 = ;
>   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 545.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@545 {
>> compatible = "allwinner,sun20i-d1-mipi-dsi",
>> "allwinner,s

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Jakob L]

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@545 {
  reg = <0x545 0x1000>;
  interrupts = ;
  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 545.dsi: Couldn't get the DSI mod clock

Option1 A 
@@ -655,7 +655,7 @@ dsi: dsi@545 {
  reg = <0x545 0x1000>;
  interrupts = ;
  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 = ;
  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 545.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@545 {
  reg = <0x545 0x1000>;
  interrupts = ;
  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 = ;
  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 545.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@545 {
> compatible = "allwinner,sun20i-d1-mipi-dsi",
> "allwinner,sun50i-a100-mipi-dsi";
> reg = <0x545 0x1000>;
> interrupts = ;
> 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 = ;
> 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/T

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[K. James]

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@545 {
compatible = "allwinner,sun20i-d1-mipi-dsi",
"allwinner,sun50i-a100-mipi-dsi";
reg = <0x545 0x1000>;
interrupts = ;
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 = ;
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@545 {
compatible = "allwinner,sun20i-d1-mipi-dsi",
"allwinner,sun50i-a100-mipi-dsi";
reg = <0x545 0x1000>;
interrupts = ;
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  */

#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"  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 545.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 displ

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Andre Przywara]

On Tue, 26 Dec 2023 19:00:58 -0800 (PST)
"K. James"  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 545.dsi: Couldn't get the DSI mod clock"*
> 
> Its tripping at the following init in sun6i_mipi_dsi.c 
> 
> 
> 
> 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 
> 
> 
> 
> display_clocks: clock-controller@500 {
>   compatible = "allwinner,sun20i-d1-de2-clk",
>"allwinner,sun50i-h5-de2-clk";
>   reg = <0x500 0x1>;
>   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@545 {
...
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 
> 
> 
> mod_clk  = 
> devm_clk_get
> (
> &pdev->dev, "mod"); if (IS_ERR
> (mod_clk
> )) return
> dev_err_probe
> (&pdev->dev,
> PTR_ERR
> (mod_clk
> ), "Couldn't
> get mod clk\n");
> 
> ret = clk_prepare_enable 
> (mod_clk 
> ); if (ret)
> { 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 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/20231227232842.5c1c9ed8%40minigeek.lan.