>-----Original Message----- >From: Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> >Sent: 2019年12月12日 18:59 >To: Peng Ma <peng.ma@xxxxxxx> >Cc: shawnguo@xxxxxxxxxx; s.hauer@xxxxxxxxxxxxxx; >linux-kernel@xxxxxxxxxxxxxxx; linux@xxxxxxxxxxxxxxxx; Abel Vesa ><abel.vesa@xxxxxxx>; Aisheng Dong <aisheng.dong@xxxxxxx>; Anson Huang ><anson.huang@xxxxxxx>; Bogdan Florin Vlad <bogdan.vlad@xxxxxxx>; >BOUGH CHEN <haibo.chen@xxxxxxx>; Clark Wang ><xiaoning.wang@xxxxxxx>; Daniel Baluta <daniel.baluta@xxxxxxx>; Fancy >Fang <chen.fang@xxxxxxx>; Han Xu <han.xu@xxxxxxx>; Horia Geanta ><horia.geanta@xxxxxxx>; Iuliana Prodan <iuliana.prodan@xxxxxxx>; Jacky >Bai <ping.bai@xxxxxxx>; Joakim Zhang <qiangqing.zhang@xxxxxxx>; Jun Li ><jun.li@xxxxxxx>; Leo Zhang <leo.zhang@xxxxxxx>; Leonard Crestez ><leonard.crestez@xxxxxxx>; Mircea Pop <mircea.pop@xxxxxxx>; Mirela >Rabulea <mirela.rabulea@xxxxxxx>; Peng Fan <peng.fan@xxxxxxx>; Peter >Chen <peter.chen@xxxxxxx>; Ranjani Vaidyanathan ><ranjani.vaidyanathan@xxxxxxx>; Robert Chiras <robert.chiras@xxxxxxx>; >Robin Gong <yibin.gong@xxxxxxx>; Shenwei Wang ><shenwei.wang@xxxxxxx>; Viorel Suman <viorel.suman@xxxxxxx>; Ying Liu ><victor.liu@xxxxxxx>; Zening Wang <zening.wang@xxxxxxx>; >kernel@xxxxxxxxxxxxxx; festevam@xxxxxxxxx; >linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-i2c@xxxxxxxxxxxxxxx >Subject: Re: [EXT] Re: [PATCH] i2c: imx: Defer probing if EDMA not available > >Caution: EXT Email > >On Thu, Dec 12, 2019 at 03:09:32AM +0000, Peng Ma wrote: >> Hello Russell, >> >> Thanks very much for your strict guidance and comments. >> I realized it is hard to us that we want to i2c used edma when edma >> probe after i2c probe. > >I have no problem with that aim. I'm just very concerned by the proposed >implementation, especially when it has already been proven to cause >regressions in the kernel. I seem to remember that the infinite loop caused >other issues, such as the system being unable to complete booting. > >> I look forward to discussing with you as below, if you like. >> Thanks. >> >> You say I could do this: >> "So, if you want to do this (and yes, I'd also encourage it to be >> conditional on EDMA being built-in, as I2C is commonly used as a way >> to get at RTCs, which are read before kernel modules can be loaded) >> then you MUST move >> i2c_imx_dma_request() before >> i2c_add_numbered_adapter() to avoid the infinite loop." >> >> Even if I do this, It's hard to avoid the infinite loop of i2c probe caused by >EDMA(build-in) initialization failure. > >It isn't clear what you mean here. > >If EDMA fails to probe (because fsl_edma_probe() returns an error other than >EPROBE_DEFER) then of_dma_find_controller() will return NULL. That will be >propagated down through i2c_imx_dma_request(). This is no different from the >case where EDMA is built as a module. It is also no different from the case >where EDMA hasn't yet been probed. > Hello Russell, The result of my test is not like that, It is still with probe loop, the test config as follows: 1.EDMA build-in 2.return -EINVAL top of fsl_edma_probe when edma probe 3.i2c probe with original patch, I put the i2c_imx_dma_request in front of i2c_add_numbered_adapter or used original patch. I send you the function of_dma_request_slave_channel could explain it last mail, "Return -EPROBE_DEFER" depends on: 1. edma not probe or probe failed 2. There is edma node in DTS and I2C with edma property >If i2c_imx_dma_request() is placed after i2c_add_numbered_adapter(), and >EPROBE_DEFER is propagated out of i2c_imx_probe(), then _yes_, it will cause >an infinite loop, because you are replicating the exact conditions that caused >the attempt to propagate i2c_imx_dma_request()'s return value to be reverted >last time - which brought the kernel to a grinding halt. > >If i2c_imx_dma_request() is placed before i2c_add_numbered_adapter(), then >there is no infinite deferred probing loop - yes, i2c_imx_probe() will be called as >a result of other drivers successfully probing, and each time it will return >EPROBE_DEFER, but the _key_ point is that the action of i2c_imx_probe() will >not _self trigger_ the deferred probing _and_ place itself onto the deferred >probe list. > >Please, rather than continuing to send emails arguing over this point, >investigate the stated issue with some practical tests: > >1. Make i2c_imx_probe() propagate i2c_imx_dma_request()'s return value, > as it did in the original patch. >2. Build i2c-imx into the kernel. >3. Build edma as a module. >4. Build and test boot the kernel and check what happens. >5. Move i2c_imx_dma_request() before i2c_add_numbered_adapter() 6. Build >and test boot the resulting kernel and note any differences. > [Peng Ma] the i2c probe loop still exist but not infinite loop with below cases: 1: Used original patch Build i2c-imx into the kernel Build edma into the kernel 2: Used original patch Build i2c-imx into the kernel Build edma into the kernel Move i2c_imx_dma_request() before i2c_add_numbered_adapter() 3: Used original patch Build i2c-imx into the kernel Build edma as a module Move i2c_imx_dma_request() before i2c_add_numbered_adapter() I saw the commit e8c220fac415d9f4a994b0c2871b835feac1eb4e you said 1. i2c_imx_probe() is called and successfully registers an I2C adapter via i2c_add_numbered_adapter() 2. As a part of i2c_add_numbered_adapter() new I2C slave devices are added from DT which results in a call to driver_deferred_probe_trigger() 3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which due to lack of proper DMA driver returns -EPROBE_DEFER 4. i2c_imx_probe() fails, removes I2C adapter and returns -EPROBE_DEFER, which places it into deferred probe list 5. Deferred probe work triggered in #2 above kicks in and calls i2c_imx_probe() again thus bringing us to step #1" Can I understand 4, you mean just remove I2C adapter the i2c slave devices not be removed? Then the i2c slave devices will probe their drivers triggered the driver_deferred_probe_trigger(). If so, My test is not like this, when the i2c probe failed the i2c slave devices will be removed and I2C adapter will be removed too. Best Regards, Peng >-- >RMK's Patch system: >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ar >mlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cpeng.ma >%40nxp.com%7Ca535712eabe343a51c2f08d77ef250e4%7C686ea1d3bc2b4c6 >fa92cd99c5c301635%7C0%7C0%7C637117451627341155&sdata=%2Fyz >xAI8%2FezVRwGTaT4vYa3CMkIMsaSYiaH8DjvJWUKA%3D&reserved=0 >FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps >up According to speedtest.net: 11.9Mbps down 500kbps up
