On Mon, Jan 29, 2024 at 12:40:25PM +0530, Manivannan Sadhasivam wrote: > 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? > The link training starts later based on a userspace/debugfs trigger. > > 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 > Sure, I will check there and respond. Thanks. > -- > மணிவண்ணன் சதாசிவம்
