Re: [PATCH 1/2] MIPS: Ingenic: Add missing nodes for Ingenic SoCs and boards. [and discussion about jz4780 SMP/MMC/Ethernet]
On 2020/11/8 下午11:28, H. Nikolaus Schaller wrote: Am 08.11.2020 um 16:13 schrieb Zhou Yanjie : On 2020/11/8 下午10:35, H. Nikolaus Schaller wrote: Am 08.11.2020 um 13:46 schrieb Zhou Yanjie : Hello Nikolaus, On 2020/11/8 上午3:03, H. Nikolaus Schaller wrote: Am 07.11.2020 um 12:52 schrieb 周琰杰 (Zhou Yanjie) : 1.Add OTG/OTG PHY/RNG nodes for JZ4780, CGU/OTG nodes for CI20. 2.Add OTG/OTG PHY/RNG/OST nodes for X1000, SSI/CGU/OST/OTG/SC16IS752 nodes for CU1000-Neo. 3.Add OTG/OTG PHY/DTRNG/OST nodes for X1830, SSI/CGU/OST/OTG/SC16IS752 nodes for CU1830-Neo. Tested-by: 周正 (Zhou Zheng) Comments below for CI20 / jz4780 only. I tried to test on top of my v5.10 working tree but the CI20 does not boot any more. Maybe the SMP hacks are in the way and I have to remove them first or try on top of v5.9.y SMP is not available on the mainline now, so the previous SMP patch needs to be removed. I have tried with CONFIG_SMP disabled and now I can boot my v5.10-rc2 (plus local patches). And can confirm that the OTG port works. Nice to hear it. (BTW: dm9000 defers probing forever but that is an unrelated issue). On my side , it will work normally after selecting CONFIG_JZ4780_EFUSE. Seems to be related to some vcc-supply: [ 14.383309] dm9000 1600.dm9000: Looking up vcc-supply from device tree [ 14.442598] [ cut here ] [ 14.442626] WARNING: CPU: 0 PID: 19 at drivers/regulator/core.c:2125 _regulator_put+0x4c/0x104 [ 14.442631] Modules linked in: ohci_platform ingenic_drm(+) gpio_keys gpio_ir_recv ohci_hcd ehci_platform dw_hdmi dwc2 roles ehci_hcd drm_kms_helper dm9000 mii rtc_pcf8563 syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks ipv6 autofs4 [ 14.442723] CPU: 0 PID: 19 Comm: kworker/0:1 Tainted: GW 5.10.0-rc2-letux-mips+ #3790 [ 14.442738] Workqueue: events deferred_probe_work_func [ 14.442745] Stack : 83941bd4 80165d58 80b7 80b7 80aaf3dc 80adad20 0009 [ 14.442775] 084d 80165da4 80b6ff37 83936978 80b7 0001 83941b98 f6d2dfd3 [ 14.442805] 80aaf3dc 000c 0114 0002 0001 746e6576 [ 14.442833] 65642073 5c11 000f 72726566 80b7 80590ad0 80adad20 [ 14.442862] 0009 084d 0001 80cb 805f6a28 0012829f 001282df [ 14.442891] ... [ 14.442901] Call Trace: [ 14.442918] [<8010912c>] show_stack+0x6c/0x12c [ 14.442933] [<801229e4>] __warn+0xd4/0x108 [ 14.442943] [<80122aa0>] warn_slowpath_fmt+0x88/0xc8 [ 14.442953] [<80590ad0>] _regulator_put+0x4c/0x104 [ 14.442961] [<80590bb0>] regulator_put+0x28/0x40 [ 14.442998] [<805dac8c>] release_nodes+0x220/0x280 [ 14.443013] [<808b1488>] really_probe+0x344/0x464 [ 14.443022] [<805d612c>] driver_probe_device+0x1d8/0x224 [ 14.443038] [<805d3efc>] bus_for_each_drv+0x90/0xc8 [ 14.443047] [<805d5e5c>] __device_attach+0xc8/0x174 [ 14.443057] [<805d4e3c>] bus_probe_device+0x3c/0xb4 [ 14.443066] [<805d53d4>] deferred_probe_work_func+0x7c/0xb4 [ 14.443078] [<8013d574>] process_one_work+0x204/0x348 [ 14.443087] [<8013e028>] worker_thread+0x28c/0x3c0 [ 14.443101] [<80143ac8>] kthread+0x14c/0x154 [ 14.443111] [<80102c0c>] ret_from_kernel_thread+0x14/0x1c [ 14.443119] [ 14.443126] ---[ end trace 76225a8e653eb480 ]--- [ 14.443379] platform 1600.dm9000: Driver dm9000 requests probe deferral I also reproduce this phenomenon here, but no idea yet. The new SMP patch will take some time because it needs to ensure support for the new X2000 processor. Ok, I see. It is a little sad since it works find until 5.9 but now is broken and means we have to test v5.10ff with only one processor. Any hints what should be hacked to make it work until a final solution becomes available in upstream? I can try to make a version that supports JZ4780 first, and I will send it to you when it is completed. Would be nice! I have completed a version and will send it to you later. Thanks and best regards! If you like you can add my Tested by: H. Nikolaus Schaller # CI20/jz4780 to this patch. Sure, I will add it to the next version. BTW, have you noticed the problem with the MMC of JZ4780? This was first discovered by Paul. After he told me, I also tested it. When MMC has a relatively heavy load, there will indeed be many error messages related to mmcblk, and it is often accompanied by file system damage. Yes, I have seen spurious mmcblk warnings and sometimes the CI20 did hang with heavy debootstrap load. No file system corruption so far. I thought it may be my µSD card but did not try another one. Or thought that the SMP code is not stable and I have to wait for a mainline solution... It seems to be related to the working frequency, and it seems to be related to the cache and mmc drivers, I am studying this issue. In addition, when doing some heavy work (such as compiling
Re: [PATCH 1/2] MIPS: Ingenic: Add missing nodes for Ingenic SoCs and boards. [and discussion about jz4780 SMP/MMC/Ethernet]
> Am 08.11.2020 um 16:13 schrieb Zhou Yanjie : > > > On 2020/11/8 下午10:35, H. Nikolaus Schaller wrote: >>> Am 08.11.2020 um 13:46 schrieb Zhou Yanjie : >>> >>> Hello Nikolaus, >>> >>> On 2020/11/8 上午3:03, H. Nikolaus Schaller wrote: > Am 07.11.2020 um 12:52 schrieb 周琰杰 (Zhou Yanjie) > : > > 1.Add OTG/OTG PHY/RNG nodes for JZ4780, CGU/OTG nodes for CI20. > 2.Add OTG/OTG PHY/RNG/OST nodes for X1000, SSI/CGU/OST/OTG/SC16IS752 > nodes for CU1000-Neo. > 3.Add OTG/OTG PHY/DTRNG/OST nodes for X1830, SSI/CGU/OST/OTG/SC16IS752 > nodes for CU1830-Neo. > > Tested-by: 周正 (Zhou Zheng) Comments below for CI20 / jz4780 only. I tried to test on top of my v5.10 working tree but the CI20 does not boot any more. Maybe the SMP hacks are in the way and I have to remove them first or try on top of v5.9.y >>> >>> SMP is not available on the mainline now, so the previous SMP patch needs >>> to be removed. >> I have tried with CONFIG_SMP disabled and now I can boot my v5.10-rc2 (plus >> local patches). >> And can confirm that the OTG port works. > > > Nice to hear it. > > >> (BTW: dm9000 defers probing forever but that is an unrelated issue). > > > On my side , it will work normally after selecting CONFIG_JZ4780_EFUSE. Seems to be related to some vcc-supply: [ 14.383309] dm9000 1600.dm9000: Looking up vcc-supply from device tree [ 14.442598] [ cut here ] [ 14.442626] WARNING: CPU: 0 PID: 19 at drivers/regulator/core.c:2125 _regulator_put+0x4c/0x104 [ 14.442631] Modules linked in: ohci_platform ingenic_drm(+) gpio_keys gpio_ir_recv ohci_hcd ehci_platform dw_hdmi dwc2 roles ehci_hcd drm_kms_helper dm9000 mii rtc_pcf8563 syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks ipv6 autofs4 [ 14.442723] CPU: 0 PID: 19 Comm: kworker/0:1 Tainted: GW 5.10.0-rc2-letux-mips+ #3790 [ 14.442738] Workqueue: events deferred_probe_work_func [ 14.442745] Stack : 83941bd4 80165d58 80b7 80b7 80aaf3dc 80adad20 0009 [ 14.442775] 084d 80165da4 80b6ff37 83936978 80b7 0001 83941b98 f6d2dfd3 [ 14.442805] 80aaf3dc 000c 0114 0002 0001 746e6576 [ 14.442833] 65642073 5c11 000f 72726566 80b7 80590ad0 80adad20 [ 14.442862] 0009 084d 0001 80cb 805f6a28 0012829f 001282df [ 14.442891] ... [ 14.442901] Call Trace: [ 14.442918] [<8010912c>] show_stack+0x6c/0x12c [ 14.442933] [<801229e4>] __warn+0xd4/0x108 [ 14.442943] [<80122aa0>] warn_slowpath_fmt+0x88/0xc8 [ 14.442953] [<80590ad0>] _regulator_put+0x4c/0x104 [ 14.442961] [<80590bb0>] regulator_put+0x28/0x40 [ 14.442998] [<805dac8c>] release_nodes+0x220/0x280 [ 14.443013] [<808b1488>] really_probe+0x344/0x464 [ 14.443022] [<805d612c>] driver_probe_device+0x1d8/0x224 [ 14.443038] [<805d3efc>] bus_for_each_drv+0x90/0xc8 [ 14.443047] [<805d5e5c>] __device_attach+0xc8/0x174 [ 14.443057] [<805d4e3c>] bus_probe_device+0x3c/0xb4 [ 14.443066] [<805d53d4>] deferred_probe_work_func+0x7c/0xb4 [ 14.443078] [<8013d574>] process_one_work+0x204/0x348 [ 14.443087] [<8013e028>] worker_thread+0x28c/0x3c0 [ 14.443101] [<80143ac8>] kthread+0x14c/0x154 [ 14.443111] [<80102c0c>] ret_from_kernel_thread+0x14/0x1c [ 14.443119] [ 14.443126] ---[ end trace 76225a8e653eb480 ]--- [ 14.443379] platform 1600.dm9000: Driver dm9000 requests probe deferral > > >>> The new SMP patch will take some time because it needs to ensure support >>> for the new X2000 processor. >> Ok, I see. It is a little sad since it works find until 5.9 but now is >> broken and means we >> have to test v5.10ff with only one processor. Any hints what should be >> hacked to make it >> work until a final solution becomes available in upstream? > > > I can try to make a version that supports JZ4780 first, and I will send it to > you when it is completed. Would be nice! > > >>> >>> Thanks and best regards! >> If you like you can add my >> >> Tested by: H. Nikolaus Schaller # CI20/jz4780 >> >> to this patch. > > > Sure, I will add it to the next version. > > > BTW, have you noticed the problem with the MMC of JZ4780? This was first > discovered by Paul. After he told me, I also tested it. When MMC has a > relatively heavy load, there will indeed be many error messages related to > mmcblk, and it is often accompanied by file system damage. Yes, I have seen spurious mmcblk warnings and sometimes the CI20 did hang with heavy debootstrap load. No file system corruption so far. I thought it may be my µSD card but did not try another one. Or thought that the SMP code is not stable and I have to wait for a mainline solution... > > In addition, when doing some heavy work (such as compiling docker locally), > the following warning message will be accompanied (this
