> On Mon, Sep 23, 2024 at 11:41:41AM +0200, AngeloGioacchino Del Regno wrote: > > Il 20/09/24 10:26, Lorenzo Bianconi ha scritto: > > > The PCIe controller available on the EN7581 SoC does not support > > > reset via the following lines: > > > - PCIE_MAC_RSTB > > > - PCIE_PHY_RSTB > > > - PCIE_BRG_RSTB > > > - PCIE_PE_RSTB > > > > > > Introduce the reset callback in order to avoid resetting the PCIe > > > port for Airoha EN7581 SoC. > > > > EN7581 doesn't support pulling up/down PERST#?! That looks > > definitely odd, as that signal is part of the PCI-Express CEM spec. > > > > Besides, there's another PERST# assertion at > > mtk_pcie_suspend_noirq()... > > I agree, it doesn't smell right that this SoC doesn't have a way to > assert PERST#. > Hi Bjorn & Lorenzo, "EN7581 doesn't support pulling up/down PERST#?!" The described above is not exactly accurate. EN7581 support pulling up/down PERST#.But EN7581 doesn't support reset PCIe device by bit PCIE_PE_RSTB of PCIE_RST_CTRL_REG register. EN7581 used 0x1fb00088 register of EN7581 Soc to reset PCIe device instead. Without the patch(Avoid PCIe resetting for Airoha EN7581 SoC),the reset sequence of the current code is as follows. step1.set 0x1fb00834（7581Soc reg,used to reset PCIe MAC） [release(default)->reset->release.] [this is done in reset callback] step2.set 0x1fb00088（7581Soc reg,used to reset PCIe device,control PERST） [reset(default)->release] [this is done in clock_enable callback] step3.set PCIE_MAC_RSTB（PCIe module reg,used to reset PCIe MAC) [release(default)->reset->release.] step4.set PCIE_PE_RSTB（PCIe module reg,used to reset PCIe device,control PERST,but doesn't work in EN7581） [reset(default)->release] With the 4 steps, we encountered PCIe link down issue occasionally. The root cause of the link down issue is that the status of PERST is release after step2. However there is a rule that the status of PERST must be reset before do PCIe MAC reset.So step3 doesn't meet the rule. So we should skip step3&4 to fix the PCIe link down issue of EN7581. Regards, Hui > The response at > https://lore.kernel.org/r/SG2PR03MB63415DB5791C58C7EA69FF01FF682@SG2PR > 03MB6341.apcprd03.prod.outlook.com > suggests that maybe there's a hardware defect that means asserting > PERST# doesn't work correctly? But surely firmware must have a way of > asserting PERST#, at least at boot time. > > If this is truly a hardware defect and we really can't assert PERST#, > please say that this is a defect in the commit log so people don't > think that lack of PERST# is an acceptable thing. > >Hi Bjorn, > >I do not have visibility on these hw details. >@Hui: any update on it? > >Regards, >Lorenzo > > > Bjorn
