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