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 <jakobl.g...@gmail.com> wrote:
> Hello James and Andrew,
>
> i was recently also tryting to get mipi dsi to work on T113-S3 - with the
> same error.
> These days i was going to compare register setting between mainline kernel
> and bsp u-boot.
> But this here came early and i was able to try the options.
> The LCD i use works on A64 and also works with these timings on allwinner
> kernel on my T113 board.
> On T113 the Low power mode of DSI works - i can send the init code.
> Verified that with oscilloscope and test patterns on LCD.
> Then the lanes are dead and do not have the right level afair.
>
> I used Kernel 6.5.7. DRM_SUN8I_TCON_TOP is enabled
> With MangoPi dts as base and the following nodes:
>
> +&de {
> + status = "okay";
> +};
> +
> +&dsi {
> + pinctrl-0 = <&dsi_4lane_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + panel: panel@0 {
> + reg = <0>;
> + compatible = "jnj,7i";
> + pinctrl-names = "default";
> + reset-gpios = <&pio 3 20 GPIO_ACTIVE_HIGH>;
> +
> + // pinctrl-0 = <&panel_pin>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&tcon_lcd0_out_dsi>;
> + };
> + };
> +
> + };
> +};
> +
> +&dphy {
> + status = "okay";
> +};
>
> Option2 No Luck
> @@ -655,7 +655,7 @@ dsi: dsi@5450000 {
> reg = <0x5450000 0x1000>;
> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&ccu CLK_BUS_MIPI_DSI>,
> - <&tcon_top CLK_TCON_TOP_DSI>;
> + <&tcon_top 1>;
>
> I had a feeling option 2 has something to do with it. But the patched
> kernel shows the same error.
> sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock
>
> Option1 A
> @@ -655,7 +655,7 @@ dsi: dsi@5450000 {
> reg = <0x5450000 0x1000>;
> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&ccu CLK_BUS_MIPI_DSI>,
> - <&tcon_top CLK_TCON_TOP_DSI>;
> + <&ccu CLK_MIPI_DSI>;
>
> With this patch i am no longer getting the modclock error. But i am not
> getting an image either.
> Unfortunatly i do not have my oscilloscope with me. So i cannot check if
> there is a signal, but i guess not.
>
> Option1 B
> @@ -675,7 +675,7 @@ dphy: phy@5451000 {
> reg = <0x5451000 0x1000>;
> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&ccu CLK_BUS_MIPI_DSI>,
> - <&ccu CLK_MIPI_DSI>;
> + <&tcon_top CLK_TCON_TOP_DSI>;
>
> This is not ok either.
> sun6i-mipi-dphy 5451000.phy: Couldn't get the DPHY mod clock
> sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock
>
>
> Ultimatly i tested to use Option 2 with Option 1. So both DSI and PHY get
> the modclock from top, but with the right index.
> @@ -655,7 +655,7 @@ dsi: dsi@5450000 {
> reg = <0x5450000 0x1000>;
> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&ccu CLK_BUS_MIPI_DSI>,
> - <&tcon_top CLK_TCON_TOP_DSI>;
> + <&tcon_top 1>;
> clock-names = "bus", "mod";
> resets = <&ccu RST_BUS_MIPI_DSI>;
> phys = <&dphy>;
> @@ -675,7 +675,7 @@ dphy: phy@5451000 {
> reg = <0x5451000 0x1000>;
> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&ccu CLK_BUS_MIPI_DSI>,
> - <&ccu CLK_MIPI_DSI>;
> + <&tcon_top 1>;
> clock-names = "bus", "mod";
> resets = <&ccu RST_BUS_MIPI_DSI>;
> #phy-cells = <0>;
>
> sun6i-mipi-dphy 5451000.phy: Couldn't get the DPHY mod clock
> sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock
>
> So all options are not working. I will check some more tomorrow. If you
> have another idea - i would be happy to test.,
>
> All the best
> Jakob
> K. James schrieb am Freitag, 29. Dezember 2023 um 03:48:37 UTC+1:
>
>> Hi,
>>
>> Apologies for the bad etiquette - I didn't realise the copy paste from
>> bootlin would put so much HTML. I will strip the formatting from my
>> messages in the future.
>> I am away from my desk and devkit for a few days, but I think I could
>> have narrowed it down to two issues:
>>
>> 1) Clock is wrong source - according to the device tree the mod clock for
>> the DSI interface is from TCON_TOP as you mention, and from the patchset
>> "[PATCH v2 1/4] dt-bindings: display: sun6i-dsi: Fix clock conditional"
>> Samuel makes the following point: "the module clock routes through the
>> TCON TOP".
>>
>> the device tree has the following:
>>
>> dsi: dsi@5450000 {
>> compatible = "allwinner,sun20i-d1-mipi-dsi",
>> "allwinner,sun50i-a100-mipi-dsi";
>> reg = <0x5450000 0x1000>;
>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&ccu CLK_BUS_MIPI_DSI>,
>> <&tcon_top CLK_TCON_TOP_DSI>;
>> clock-names = "bus", "mod";
>> resets = <&ccu RST_BUS_MIPI_DSI>;
>> phys = <&dphy>;
>> phy-names = "dphy";
>> status = "disabled";
>> };
>>
>> dphy: phy@5451000 {
>> compatible = "allwinner,sun20i-d1-mipi-dphy",
>> "allwinner,sun50i-a100-mipi-dphy";
>> reg = <0x5451000 0x1000>;
>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&ccu CLK_BUS_MIPI_DSI>,
>> <&ccu CLK_MIPI_DSI>;
>> clock-names = "bus", "mod";
>> resets = <&ccu RST_BUS_MIPI_DSI>;
>> #phy-cells = <0>;
>> };
>>
>> In this case the DPHY is getting its clock from the CCU node
>> "CLK_MIPI_DSI" instead of TCON TOP, so one of the following cases could be
>> true:
>>
>> > The DSI node should get its mod clock from CCU CLK_MIPI_DSI and the
>> TCON_TOP CLK_TCON_TOP_DSI clock source is incorrect, or
>> > The DPHY should get its mod clock from TCON_TOP CLK_TCON_TOP_DSI and
>> the ccu CLK_MIPI_DSI source is incorrect, or
>> > These clock sources are correct and there is some other issue (such as
>> below).
>>
>>
>> 2) alternatively, it could be just a quirk of the D1/T113 TCON TOP setup.
>>
>> I also had found this in reviewing the devicetree for this board - the
>> patchset "[PATCH v2 00/14] drm/sun4i: Allwinner D1 Display Engine 2.0
>> Support" includes the TCON Top Support the following note:
>>
>> [PATCH v2 12/14] drm/sun4i: Add support for D1 TCON TOP
>> "D1 has a TCON TOP with TCON TV0 and DSI, but no TCON TV1. This puts
>> theDSI clock name at index 1 in clock-output-names. Support this by only
>> incrementing the index for clocks that are actually supported."
>>
>>
>> But reviewing the DSI node:
>>
>>
>> dsi: dsi@5450000 {
>> compatible = "allwinner,sun20i-d1-mipi-dsi",
>> "allwinner,sun50i-a100-mipi-dsi";
>> reg = <0x5450000 0x1000>;
>> interrupts = <SOC_PERIPHERAL_IRQ(92) IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&ccu CLK_BUS_MIPI_DSI>,
>> <&tcon_top CLK_TCON_TOP_DSI>;
>> clock-names = "bus", "mod";
>> resets = <&ccu RST_BUS_MIPI_DSI>;
>> phys = <&dphy>;
>> phy-names = "dphy";
>> status = "disabled";
>>
>>
>> the definition of CLK_TCON_TOP_DSI comes from sun8i-tcon-top.h:
>>
>>
>> /* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
>> /* Copyright (C) 2018 Jernej Skrabec <jernej....@siol.net> */
>>
>> #ifndef _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
>> #define _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
>>
>> #define CLK_TCON_TOP_TV0 0
>> #define CLK_TCON_TOP_TV1 1
>> #define CLK_TCON_TOP_DSI 2
>>
>> #endif /* _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ */
>>
>>
>>
>> I believe, if that the quirk of the D1s correct to the above comment, the
>> incorrect clock index is being selected in the devicetree which would also
>> cause the failure.
>>
>>
>> In which case:
>>
>> clocks = <&ccu CLK_BUS_MIPI_DSI>, <&tcon_top 1>;
>>
>> clock-names = "bus", "mod";
>>
>>
>> would be a sufficient fix without updating the header/source.
>>
>> Either case as soon as I am back with my devkit, I would try this for
>> sure and try and see if I can find an answer.
>>
>>
>>
>> >You can check /sys/kernel/debug/clk/clk_summary (with debugfs mounted)
>> >to see what clocks are there and how they are used
>> Also great information, I will test.
>>
>>
>> Regards,
>>
>> On Thursday 28 December 2023 at 9:59:09 am UTC+10:30 Andre Przywara wrote:
>>
>>> On Tue, 26 Dec 2023 19:00:58 -0800 (PST)
>>> "K. James" <kirby.n...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> please try to avoid HTML email on lists, that makes it hard to reply
>>> inline and messes up the text view - and there is little need to provide
>>> links to every identifier anyway.
>>>
>>> > Hi All,
>>> >
>>> > Been working on getting T113-s3 on mainline as I prepare to update a
>>> > project from a v3s. One of the benefits has been the ability to move
>>> from a
>>> > 18bit RGB LCD to a MIPI-DSI display, with the interface available on
>>> the
>>> > T113-s3 , which has given some better display choices.
>>> >
>>> > The DSI driver was on mainline from 6.2, however building from sources
>>> on
>>> > init I am getting the following error:
>>> >
>>> > *"sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"*
>>> >
>>> > Its tripping at the following init in sun6i_mipi_dsi.c
>>> > <
>>> https://elixir.bootlin.com/linux/v6.6.2/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L1155>
>>>
>>> >
>>> >
>>> > if (variant-> has_mod_clk) {
>>> > dsi->mod_clk = devm_clk_get(dev, "mod");
>>> > if (IS_ERR (dsi->mod_clk)) {
>>> > dev_err(dev, "Couldn't get the DSI mod clock\n");
>>> > ret = PTR_ERR(dsi->mod_clk);
>>> > goto err_attach_clk;
>>> >}
>>>
>>> But since this comes from the DSI driver, this refers to the DT node of
>>> the DSI device, not the DE2 clock, doesn't it?
>>>
>>> > The display modclock is registered from the following DTS node in
>>> > sunxi-d1s-t113.dtsi
>>> > <
>>> https://elixir.bootlin.com/linux/v6.6.2/source/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi#L641>
>>>
>>> >
>>> >
>>> > display_clocks: clock-controller@5000000 {
>>> > compatible = "allwinner,sun20i-d1-de2-clk",
>>> > "allwinner,sun50i-h5-de2-clk";
>>> > reg = <0x5000000 0x10000>;
>>> > clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>;
>>> > clock-names = "bus", *"mod"*;
>>> > resets = <&ccu RST_BUS_DE>;
>>> > #clock-cells = <1>;
>>> > #reset-cells = <1>;
>>> > };
>>>
>>> So those are the clocks from:
>>> dsi: dsi@5450000 {
>>> ...
>>> clocks = <&ccu CLK_BUS_MIPI_DSI>,
>>> <&tcon_top CLK_TCON_TOP_DSI>;
>>> clock-names = "bus", "mod";
>>> ...
>>> };
>>>
>>> So the "mod" clock here points to the tcon_top device, the one with the
>>> "allwinner,sun20i-d1-tcon-top" compatible string. Which is implemented
>>> by drivers/gpu/drm/sun4i/sun8i_tcon_top.c, controlled by the
>>> DRM_SUN8I_TCON_TOP Kconfig symbol. Do you have that enabled?
>>>
>>> You can check /sys/kernel/debug/clk/clk_summary (with debugfs mounted)
>>> to see what clocks are there and how they are used.
>>>
>>> Cheers,
>>> Andre
>>>
>>> > I checked the buildroot config and the CCU for sun8i DE2 is being
>>> > built and included, the registration should occur and give an
>>> > exception if it's not happening: ccu-sun8i-de2.c
>>> > <
>>> https://elixir.bootlin.com/linux/v6.6.2/source/drivers/clk/sunxi-ng/ccu-sun8i-de2.c#L263>
>>>
>>> >
>>> > mod_clk <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk> =
>>> > devm_clk_get
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/devm_clk_get>(
>>> > &pdev->dev, "mod"); if (IS_ERR
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/IS_ERR>(mod_clk
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>)) return
>>> > dev_err_probe
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/dev_err_probe>(&pdev->dev,
>>>
>>> > PTR_ERR
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/PTR_ERR>(mod_clk
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>), "Couldn't
>>> > get mod clk\n");
>>> >
>>> > ret = clk_prepare_enable
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/clk_prepare_enable>(mod_clk
>>>
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/mod_clk>); if (ret)
>>> > { dev_err
>>> > <https://elixir.bootlin.com/linux/v6.6.2/C/ident/dev_err>(&pdev->dev
>>> > , "Couldn't enable mod clk: %d\n", ret); goto err_disable_bus_clk; }
>>> >
>>> > I don't see dmesg print any clock errors, but at the same time, I
>>> > understand that linux common clock framework also won't print
>>> > anything by default.
>>> >
>>> > I can't see anything in either driver that would cause an error other
>>> > than the clock not existing, if anyone has any ideas - i'm all ears.
>>> >
>>> > At the moment I am leaning towards the clock-controller; Is there a
>>> > userspace or debug option to check (mod) clock status' under the
>>> > common clock framework?
>>> >
>>> > Thanks
>>> >
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "linux-sunxi" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/linux-sunxi/HxDBpY5HbbQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/02e9453d-7335-4499-933b-ac5038e41bbcn%40googlegroups.com
> <https://groups.google.com/d/msgid/linux-sunxi/02e9453d-7335-4499-933b-ac5038e41bbcn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAMBcuYNFufPbTS5_D%2B2y16bdD%2BpO2gLCPw-Z_1X%3DcQGZRYf4Sg%40mail.gmail.com.
