Re: [PATCH v5 05/12] PCI: brcmstb: Use swinit reset if available

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 6, 2024 at 11:03 PM Manivannan Sadhasivam
<manivannan.sadhasivam@xxxxxxxxxx> wrote:
>
> On Wed, Jul 31, 2024 at 06:28:19PM -0400, Jim Quinlan wrote:
> > The 7712 SOC adds a software init reset device for the PCIe HW.
> > If found in the DT node, use it.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@xxxxxxxxxxxx>
> > ---
> >  drivers/pci/controller/pcie-brcmstb.c | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> > index 4d68fe318178..948fd4d176bc 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -266,6 +266,7 @@ struct brcm_pcie {
> >       struct reset_control    *rescal;
> >       struct reset_control    *perst_reset;
> >       struct reset_control    *bridge_reset;
> > +     struct reset_control    *swinit_reset;
> >       int                     num_memc;
> >       u64                     memc_size[PCIE_BRCM_MAX_MEMC];
> >       u32                     hw_rev;
> > @@ -1633,12 +1634,30 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> >       if (IS_ERR(pcie->bridge_reset))
> >               return PTR_ERR(pcie->bridge_reset);
> >
> > +     pcie->swinit_reset = devm_reset_control_get_optional_exclusive(&pdev->dev, "swinit");
> > +     if (IS_ERR(pcie->swinit_reset))
> > +             return PTR_ERR(pcie->swinit_reset);
> > +
> >       ret = clk_prepare_enable(pcie->clk);
> >       if (ret)
> >               return dev_err_probe(&pdev->dev, ret, "could not enable clock\n");
> >
> >       pcie->bridge_sw_init_set(pcie, 0);
> >
> > +     if (pcie->swinit_reset) {
>
> You already have a callback called 'bridge_sw_init_set', so this 'swinit_reset'
> is different from 'bridge_sw_init'?
Yes.  The swinit_reset is a soft reset of the entire core while
bridge_sw_init reset is only for the bridge to system memory.

If so, does it make sense to move this into
> the callback itself to have all reset sequence in one place?

The order and placement of the resets can sometimes be fragile and I
would prefer to leave them where they are.

Regards,
Jim Quinlan
Broadcom STB/CM

>
> - Mani
>
> > +             ret = reset_control_assert(pcie->swinit_reset);
> > +             if (dev_err_probe(&pdev->dev, ret, "could not assert reset 'swinit'\n"))
> > +                     goto clk_disable_unprepare;
> > +
> > +             /* HW team recommends 1us for proper sync and propagation of reset */
> > +             udelay(1);
> > +
> > +             ret = reset_control_deassert(pcie->swinit_reset);
> > +             if (dev_err_probe(&pdev->dev, ret,
> > +                               "could not de-assert reset 'swinit' after asserting\n"))
> > +                     goto clk_disable_unprepare;
> > +     }
> > +
> >       ret = reset_control_reset(pcie->rescal);
> >       if (dev_err_probe(&pdev->dev, ret, "failed to deassert 'rescal'\n"))
> >               goto clk_disable_unprepare;
> > --
> > 2.17.1
> >
>
> --
> மணிவண்ணன் சதாசிவம்

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux