On Mon, Jan 29, 2024 at 12:21:51PM +0530, Ajay Agarwal wrote: > On Sat, Jan 20, 2024 at 08:04:34PM +0530, Manivannan Sadhasivam wrote: > > On Fri, Jan 19, 2024 at 11:29:22PM +0530, Ajay Agarwal wrote: > > > On Fri, Jan 19, 2024 at 01:22:19PM +0530, Manivannan Sadhasivam wrote: > > > > On Fri, Jan 12, 2024 at 03:00:06PM +0530, Ajay Agarwal wrote: > > > > > In dw_pcie_host_init() regardless of whether the link has been > > > > > started or not, the code waits for the link to come up. Even in > > > > > cases where start_link() is not defined the code ends up spinning > > > > > in a loop for 1 second. Since in some systems dw_pcie_host_init() > > > > > gets called during probe, this one second loop for each pcie > > > > > interface instance ends up extending the boot time. > > > > > > > > > > > > > Which platform you are working on? Is that upstreamed? You should mention the > > > > specific platform where you are observing the issue. > > > > > > > This is for the Pixel phone platform. The platform driver for the same > > > is not upstreamed yet. It is in the process. > > > > > > > Then you should submit this patch at the time of the driver submission. Right > > now, you are trying to fix a problem which is not present in upstream. One can > > argue that it is a problem for designware-plat driver, but honestly I do not > > know how it works. > > > > - Mani > > > Yes Mani, this can be a problem for the designware-plat driver. To me, > the problem of a second being wasted in the probe path seems pretty > obvious. We will wait for the link to be up even though we are not > starting the link training. Can this patch be accepted considering the > problem in the dw-plat driver then? > If that's the case with your driver, when are you starting the link training? > Additionally, I have made this patch a part of a series [1] to keep the > functional and refactoring changes separate. Please let me know if you > see a concern with that. > I have responded to this series with my concerns. - Mani -- மணிவண்ணன் சதாசிவம்
