All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: linux-pci@vger.kernel.org,
	"Nicolas Saenz Julienne" <nsaenz@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Cyril Brulebois" <kibi@debian.org>,
	"Phil Elwell" <phil@raspberrypi.com>,
	bcm-kernel-feedback-list@broadcom.com,
	"Florian Fainelli" <florian.fainelli@broadcom.com>,
	"Jim Quinlan" <jim2101024@gmail.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-rpi-kernel@lists.infradead.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 2/4] PCI: brcmstb: Set reasonable value for internal bus timeout
Date: Mon, 6 May 2024 17:45:08 -0500	[thread overview]
Message-ID: <20240506224508.GA1713699@bhelgaas> (raw)
In-Reply-To: <20240403213902.26391-3-james.quinlan@broadcom.com>

On Wed, Apr 03, 2024 at 05:38:59PM -0400, Jim Quinlan wrote:
> HW initializes an internal bus timeout register to a small value for
> debugging convenience.  Set this to something reasonable, i.e. in the
> vicinity of 10 msec.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---
>  drivers/pci/controller/pcie-brcmstb.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index f9dd6622fe10..e3480ca4cd57 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -664,6 +664,21 @@ static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
>  	return 0;
>  }
>  
> +/*
> + * An internal HW bus timer value is set to a small value for debugging
> + * convenience.  Set this to something reasonable, i.e. somewhere around
> + * 10ms.
> + */
> +static void brcm_extend_internal_bus_timeout(struct brcm_pcie *pcie, u32 nsec)
> +{
> +	/* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
> +	const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
> +	u32 timeout_us = nsec / 1000;
> +
> +	/* Each unit in timeout register is 1/216,000,000 seconds */
> +	writel(216 * timeout_us, pcie->base + REG_OFFSET);
> +}
> +
>  /* The controller is capable of serving in both RC and EP roles */
>  static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
>  {
> @@ -1059,6 +1074,9 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
>  		return -ENODEV;
>  	}
>  
> +	/* Extend internal bus timeout to 8ms or so */
> +	brcm_extend_internal_bus_timeout(pcie, SZ_8M);

The 216*usec is obviously determined by hardware, but the choice of
nsec for the interface, and converting to usec internally seems
arbitrary; the caller could just easily supply usec.  Or do you
envision using this interface for timeouts < 1 usec?

"SZ_8M" seems a little unusual as a time measurement and doesn't give
a hint about the units.  It's pretty common to use "8 * USEC_PER_MSEC"
or even "8 * NSEC_PER_MSEC" for things like this.

But it's fine with me as-is.

>  	if (pcie->gen)
>  		brcm_pcie_set_gen(pcie, pcie->gen);
>  
> -- 
> 2.17.1
> 



WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: linux-pci@vger.kernel.org,
	"Nicolas Saenz Julienne" <nsaenz@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Cyril Brulebois" <kibi@debian.org>,
	"Phil Elwell" <phil@raspberrypi.com>,
	bcm-kernel-feedback-list@broadcom.com,
	"Florian Fainelli" <florian.fainelli@broadcom.com>,
	"Jim Quinlan" <jim2101024@gmail.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-rpi-kernel@lists.infradead.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 2/4] PCI: brcmstb: Set reasonable value for internal bus timeout
Date: Mon, 6 May 2024 17:45:08 -0500	[thread overview]
Message-ID: <20240506224508.GA1713699@bhelgaas> (raw)
In-Reply-To: <20240403213902.26391-3-james.quinlan@broadcom.com>

On Wed, Apr 03, 2024 at 05:38:59PM -0400, Jim Quinlan wrote:
> HW initializes an internal bus timeout register to a small value for
> debugging convenience.  Set this to something reasonable, i.e. in the
> vicinity of 10 msec.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---
>  drivers/pci/controller/pcie-brcmstb.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index f9dd6622fe10..e3480ca4cd57 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -664,6 +664,21 @@ static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
>  	return 0;
>  }
>  
> +/*
> + * An internal HW bus timer value is set to a small value for debugging
> + * convenience.  Set this to something reasonable, i.e. somewhere around
> + * 10ms.
> + */
> +static void brcm_extend_internal_bus_timeout(struct brcm_pcie *pcie, u32 nsec)
> +{
> +	/* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
> +	const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
> +	u32 timeout_us = nsec / 1000;
> +
> +	/* Each unit in timeout register is 1/216,000,000 seconds */
> +	writel(216 * timeout_us, pcie->base + REG_OFFSET);
> +}
> +
>  /* The controller is capable of serving in both RC and EP roles */
>  static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
>  {
> @@ -1059,6 +1074,9 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
>  		return -ENODEV;
>  	}
>  
> +	/* Extend internal bus timeout to 8ms or so */
> +	brcm_extend_internal_bus_timeout(pcie, SZ_8M);

The 216*usec is obviously determined by hardware, but the choice of
nsec for the interface, and converting to usec internally seems
arbitrary; the caller could just easily supply usec.  Or do you
envision using this interface for timeouts < 1 usec?

"SZ_8M" seems a little unusual as a time measurement and doesn't give
a hint about the units.  It's pretty common to use "8 * USEC_PER_MSEC"
or even "8 * NSEC_PER_MSEC" for things like this.

But it's fine with me as-is.

>  	if (pcie->gen)
>  		brcm_pcie_set_gen(pcie, pcie->gen);
>  
> -- 
> 2.17.1
> 



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-06 22:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 21:38 [PATCH v9 0/4] PCI: brcmstb: Configure appropriate HW CLKREQ# mode Jim Quinlan
2024-04-03 21:38 ` Jim Quinlan
2024-04-03 21:38 ` [PATCH v9 1/4] dt-bindings: PCI: brcmstb: Add property "brcm,clkreq-mode" Jim Quinlan
2024-04-03 21:38   ` Jim Quinlan
2024-04-03 21:38 ` [PATCH v9 2/4] PCI: brcmstb: Set reasonable value for internal bus timeout Jim Quinlan
2024-04-03 21:38   ` Jim Quinlan
2024-05-06 22:45   ` Bjorn Helgaas [this message]
2024-05-06 22:45     ` Bjorn Helgaas
2024-04-03 21:39 ` [PATCH v9 3/4] PCI: brcmstb: Set downstream maximum {no-}snoop LTR values Jim Quinlan
2024-04-03 21:39   ` Jim Quinlan
2024-04-04 16:47   ` kernel test robot
2024-04-04 16:48   ` kernel test robot
2024-04-03 21:39 ` [PATCH v9 4/4] PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device Jim Quinlan
2024-04-03 21:39   ` Jim Quinlan
2024-05-06 23:20   ` Bjorn Helgaas
2024-05-06 23:20     ` Bjorn Helgaas
2024-05-08 17:55     ` Jim Quinlan
2024-05-08 17:55       ` Jim Quinlan
2024-05-08 23:33       ` Bjorn Helgaas
2024-05-08 23:33         ` Bjorn Helgaas
2024-04-04 20:01 ` [PATCH v9 0/4] PCI: brcmstb: Configure appropriate HW CLKREQ# mode Cyril Brulebois
2024-04-04 20:01   ` Cyril Brulebois
2024-04-30 21:02 ` Jim Quinlan
2024-04-30 21:02   ` Jim Quinlan
2024-05-06 22:31   ` Bjorn Helgaas
2024-05-06 22:31     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240506224508.GA1713699@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=james.quinlan@broadcom.com \
    --cc=jim2101024@gmail.com \
    --cc=kibi@debian.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lpieralisi@kernel.org \
    --cc=nsaenz@kernel.org \
    --cc=phil@raspberrypi.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.