From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 40E85C52D7C for ; Mon, 12 Aug 2024 15:58:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=R7G5lXJ8+mpxTpxMVd0PsQcEoG84K7UrtkS21/lEGPI=; b=AqecjB50ITekWNCiPHU5xzCA+N y6v/0c8MK3gfS3NzgfY8WgpNcKTComKxRy/ljeTpSzDAHonHCmf/Cb4hXGfgIi7VKBWJuVZLhQIw8 ODG26l+zMMFyRDqmfcwfkDCzfN0UdhhNP0I8e9RyuCc3gWgh/BFn7yQHg9ipzEv+gS+iYO6YLq9sp rJuwgHO84lAjF+Y6nPeNWVoyAuZi+PBp1Rc81dTGDoq1e+73sb3iHKwZ2gFkXJgSjUjVdm6GmG0YZ +svGpmK8j9zzvGGWJHRu1O0oFusP95qmTVnfP1V/ACvimUhMsr0ObTcqAzh1WID7ky/bBS3IJpY/Q l4Ip3nGQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdXRK-00000000onv-0Zma; Mon, 12 Aug 2024 15:58:34 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdXQi-00000000ogA-3LLf for linux-arm-kernel@lists.infradead.org; Mon, 12 Aug 2024 15:57:58 +0000 Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1ff1cd07f56so37715835ad.2 for ; Mon, 12 Aug 2024 08:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1723478276; x=1724083076; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=R7G5lXJ8+mpxTpxMVd0PsQcEoG84K7UrtkS21/lEGPI=; b=gBvudDjLAMUKWSxIYGhTFyfX6goC7axvdIkwnYBEUIm+jLuAdod9AP+hTVBcN1m3WU FKVcLnrbitpMsmXXeqSmoqKJZ9cl7Fz+MDxgWaa15LOUmhn5yQOwccquzEWHrArOkW2f V5khzPGoErsKkRfCzQBfkyNs8/iSh9EpKznbXFvANFsTfJbI18cL5kA1ZqI0z3Ixf28Y ZS/KKV13qY4Xa/SSeNJ2x+65KZcbCfMMBe5mWGQF2bl0Q4suDBlGrQ2Kx+Z1WyyeSqWW rlx4LPKF205KKmtbYD7P0/tQa9q2o6ni7I/+SK6HuhDi90KYUJz5H0ZWTBZenV2zm+Gn KUbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723478276; x=1724083076; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R7G5lXJ8+mpxTpxMVd0PsQcEoG84K7UrtkS21/lEGPI=; b=c2Y8GJ9XKDwPg+wEF0pokJ8jBpBXABb6dhKi7ix/j8uP/5Axk/VQ7/fLXEQ1LLaLgC 3+yET5ifGxLgWXFo3Y0tBJWC5tT/C5KrUaGZAs7Zf+mL70pGUKsbaZRJIa+jo4/Harhx Kd9ki1g3+o+chjRr2OefRq0177IVF/5PTHtX6T1Kgqi0rhxPgerIu5TMOnY99BKo7S5K C4vrR1/aT4KtiltHM06kFbsLKYtd8mFc5d6CC+jo8C3Tpfg+0Msf4jz5o4ew2TvFMxBy fN3SCOAJs1RNZxnSf5RH/EjUKTSdGbE6IK84aszPes25klCLLl4/GyO9q7GAlcQ+2jHb 0sKA== X-Forwarded-Encrypted: i=1; AJvYcCWhx1YJyPS0OW1mUorKcHI61dmlEDhyR7oB+VILVKsroO/v/7+/bhzm4e7Fa55nRbUmj5Xsq0hsguKxC36wn5fv7VCvf1YdMxpNXV99xpRwLjAUQzA= X-Gm-Message-State: AOJu0Yz9LbGap2RxvvmRhywlT7aqnxtpl7Jf3NdPrYXHuAN91OdFUDPQ yujbSZIemYmrzqyfH0i+3QnwFgAbd2pr4N6A9lMFk6L1RtinY800LTEK221Vag== X-Google-Smtp-Source: AGHT+IEEj6btaDgOaSWDOrp+QplOLF1Pkma236uqOawQUH1HjeR+8/1+9MHkiVLvKalQKMrFDrGubg== X-Received: by 2002:a17:903:230f:b0:1fa:8f64:8b0d with SMTP id d9443c01a7336-201ca1219e9mr8738555ad.4.1723478276032; Mon, 12 Aug 2024 08:57:56 -0700 (PDT) Received: from thinkpad ([220.158.156.101]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-200bba063f6sm39609315ad.204.2024.08.12.08.57.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Aug 2024 08:57:55 -0700 (PDT) Date: Mon, 12 Aug 2024 21:27:47 +0530 From: Manivannan Sadhasivam To: Jim Quinlan Cc: Stanimir Varbanov , linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Cyril Brulebois , Krzysztof Kozlowski , bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com, Florian Fainelli , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Philipp Zabel , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v5 05/12] PCI: brcmstb: Use swinit reset if available Message-ID: <20240812155747.GA6003@thinkpad> References: <20240731222831.14895-1-james.quinlan@broadcom.com> <20240731222831.14895-6-james.quinlan@broadcom.com> <57f11aff-95f8-41fd-b35e-a9e5a85c68e3@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240812_085756_886485_9F4B3FD2 X-CRM114-Status: GOOD ( 35.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 12, 2024 at 09:43:46AM -0400, Jim Quinlan wrote: > On Fri, Aug 9, 2024 at 5:53 AM Stanimir Varbanov wrote: > > > > Hi Jim, > > > > On 8/1/24 01:28, 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 > > > --- > > > 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) { > > > + 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); > > > > Hmm, shouldn't this delay be part of .assert/.deassert reset_control > > driver? I think this detail is reset-control hw specific and the > > consumers does not need to know it. > > This was discussed previously. I pointed out that we use a reset > provider that governs dozens of devices. The only thing that the > provider could do is to employ a worst case delay used for all > resets. This is unacceptable; we have certain devices that may have > to invoke > reset often and require timely action, and we do not want them having > to wait the same amount of worst case delay as for example, a UART device reset. > > Further, if I do a "grep reset_control_assert -A 10 drivers" I see > plenty of existing drivers that use usleep/msleep/udelay after the call to > reset_control_assert, just as I am doing now. > > As far as my opinion goes (FWIW) I think the delay is more apt to > be present in the consumer driver and not the provider driver. To > ascertain this specific delay I had to consult with the PCIe HW team, > not the HW team that implemented the reset controller. > Yeah. Often the reset controller won't have any idea about the delay required between assert + deassert, unless the reset controller is closely tied to the peripheral. So keeping the delay in consumer drivers is the right thing to do. - Mani -- மணிவண்ணன் சதாசிவம்