Em Mon, 25 Oct 2021 11:25:11 +0100 Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> escreveu: > On Sat, Oct 23, 2021 at 10:30:59AM +0100, Mauro Carvalho Chehab wrote: > > Hi Pali, > > > > Em Fri, 22 Oct 2021 17:16:24 +0200 > > Pali Rohár <pali@xxxxxxxxxx> escreveu: > > > > > On Tuesday 19 October 2021 07:06:42 Mauro Carvalho Chehab wrote: > > > > Before code refactor, the PERST# signals were sent at the > > > > end of the power_on logic. Then, the PCI core would probe for > > > > the buses and add them. > > > > > > > > The new logic changed it to send PERST# signals during > > > > add_bus operation. That altered the timings. > > > > > > > > Also, HiKey 970 require a little more waiting time for > > > > the PCI bridge - which is outside the SoC - to finish > > > > the PERST# reset, and then initialize the eye diagram. > > > > > > Hello! Which PCIe port do you mean by PCI bridge device? Do you mean > > > PCIe Root Port? Or upstream port on some external PCIe switch connected > > > via PCIe bus to the PCIe Root Port? Because all of these (virtual) PCIe > > > devices are presented as PCI bridge devices, so it is not clear to which > > > device it refers. > > > > HiKey 970 uses an external PCI bridge chipset (a Broadcom PEX 8606[1]), > > with 3 elements connected to the bus: an Ethernet card, a M.2 slot and > > a mini PCIe slot. It seems HiKey 970 is unique with regards to PERST# signal, > > as there are 4 independent PERST# signals there: > > > > - one for PEX 8606 (the PCIe root port); > > - one for Ethernet; > > - one for M.2; > > - one for mini-PCIe. > > > > After sending the PCIe PERST# signals, the device has to wait for 21 ms > > before adjusting the eye diagram. > > > > [1] https://docs.broadcom.com/docs/PEX_8606_AIC_RDK_HRM_v1.3_06Aug10.pdf > > > > > Normally PERST# signal is used to reset endpoint card, other end of PCIe > > > link and so PERST# signal should not affect PCIe Root Port at all. > > > > That's not the case, as PEX 8606 needs to complete its reset sequence > > for the rest of the devices to be visible. If the wait time is reduced > > or removed, the devices behind it won't be detected. > > These pieces of information should go into the commit log (or I can add > a Link: tag to this discussion) - it is fundamental to understand these > changes. > > I believe we can merge this series but we have to document this > discussion appropriately. IMO, the best is to add a Link: to the discussion: Link: https://lore.kernel.org/all/9a365cffe5af9ec5a1f79638968c3a2efa979b65.1634622716.git.mchehab+huawei@xxxxxxxxxx/ But if you prefer otherwise and want me to re-submit the series, please let me know. Regards, Mauro
