All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <jim2101024@gmail.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,
	james.quinlan@broadcom.com,
	"Florian Fainelli" <f.fainelli@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 v1 2/3] PCI: brcmstb: Clkreq# accomodations of downstream device
Date: Thu, 6 Apr 2023 14:09:53 -0500	[thread overview]
Message-ID: <20230406190953.GA3723665@bhelgaas> (raw)
In-Reply-To: <20230406124625.41325-3-jim2101024@gmail.com>

On Thu, Apr 06, 2023 at 08:46:23AM -0400, Jim Quinlan wrote:
> The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, may be
> set into three mutually exclusive modes:
> 
>   (a) No clkreq# expected or required, refclk is always available.
>   (b) Clkreq# is expected to be driven by downstream device when needed.
>   (c) Bidirectional clkreq# for L1SS capable devices.
> 
> Previously, only (b) was supported by the driver, as almost all STB boards
> operate in this mode.  But now there is interest in activating L1SS power
> savings from STB customers, and also interest in accomodating mode (a) for
> designs such as the RPi CM4 with IO board.
> 
> The HW can tell us when mode (a) mode is needed.  But there is no easy way
> to tell if L1SS mode is needed.  Unfortunately, getting this wrong causes a
> panic during boot time.  So we rely on the DT prop "brcm,enable-l1ss" to
> tell us when mode (c) is desired.  This property has already been in
> use by Raspian Linux, but this immplementation adds more details and
> discerns between (a) and (b) automatically.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217276
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>

> +	 * We have "seen" clkreq# if it is asserted or has been in the past.
> +	 * Note that the CLKREQ_IN_MASK is 1 if clkreq# is asserted.

"CLKREQ#" to match PCIe spec and comments below.

> +	if (l1ss && IS_ENABLED(CONFIG_PCIEASPM)) {
> +		/*
> +		 * Note: This (l1ss) mode may not meet requirement for
> +		 * Endpoints that require CLKREQ# assertion to clock active
> +		 * within 400ns.
> +		 */
> +		clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
> +		dev_info(pcie->dev, "bi-dir clkreq; l1ss-capable devs only\n");
> +		dev_info(pcie->dev, "ASPM policy must be set to powersupersave\n");

Seems problematic since L1SS can be enabled/disabled at run-time:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-bus-pci?id=v6.2#n420

The simplistic answer is to advertise L1SS support if and only if you
can safely support it.

I don't know why this is an issue for this device but not others.  Is
it because there's some problem in the way the board is designed?  Or
(after skimming the bugzilla) maybe a problem with the plug-in cards?

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <jim2101024@gmail.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,
	james.quinlan@broadcom.com,
	"Florian Fainelli" <f.fainelli@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 v1 2/3] PCI: brcmstb: Clkreq# accomodations of downstream device
Date: Thu, 6 Apr 2023 14:09:53 -0500	[thread overview]
Message-ID: <20230406190953.GA3723665@bhelgaas> (raw)
In-Reply-To: <20230406124625.41325-3-jim2101024@gmail.com>

On Thu, Apr 06, 2023 at 08:46:23AM -0400, Jim Quinlan wrote:
> The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, may be
> set into three mutually exclusive modes:
> 
>   (a) No clkreq# expected or required, refclk is always available.
>   (b) Clkreq# is expected to be driven by downstream device when needed.
>   (c) Bidirectional clkreq# for L1SS capable devices.
> 
> Previously, only (b) was supported by the driver, as almost all STB boards
> operate in this mode.  But now there is interest in activating L1SS power
> savings from STB customers, and also interest in accomodating mode (a) for
> designs such as the RPi CM4 with IO board.
> 
> The HW can tell us when mode (a) mode is needed.  But there is no easy way
> to tell if L1SS mode is needed.  Unfortunately, getting this wrong causes a
> panic during boot time.  So we rely on the DT prop "brcm,enable-l1ss" to
> tell us when mode (c) is desired.  This property has already been in
> use by Raspian Linux, but this immplementation adds more details and
> discerns between (a) and (b) automatically.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217276
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>

> +	 * We have "seen" clkreq# if it is asserted or has been in the past.
> +	 * Note that the CLKREQ_IN_MASK is 1 if clkreq# is asserted.

"CLKREQ#" to match PCIe spec and comments below.

> +	if (l1ss && IS_ENABLED(CONFIG_PCIEASPM)) {
> +		/*
> +		 * Note: This (l1ss) mode may not meet requirement for
> +		 * Endpoints that require CLKREQ# assertion to clock active
> +		 * within 400ns.
> +		 */
> +		clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
> +		dev_info(pcie->dev, "bi-dir clkreq; l1ss-capable devs only\n");
> +		dev_info(pcie->dev, "ASPM policy must be set to powersupersave\n");

Seems problematic since L1SS can be enabled/disabled at run-time:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-bus-pci?id=v6.2#n420

The simplistic answer is to advertise L1SS support if and only if you
can safely support it.

I don't know why this is an issue for this device but not others.  Is
it because there's some problem in the way the board is designed?  Or
(after skimming the bugzilla) maybe a problem with the plug-in cards?

Bjorn

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

  reply	other threads:[~2023-04-06 19:10 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 12:46 [PATCH v1 0/3] PCI: brcmstb: Clkreq# accomodations of downstream device Jim Quinlan
2023-04-06 12:46 ` Jim Quinlan
2023-04-06 12:46 ` [PATCH v1 1/3] dt-bindings: PCI: brcmstb: Add two optional props Jim Quinlan
2023-04-06 12:46   ` Jim Quinlan
2023-04-06 15:39   ` Stefan Wahren
2023-04-06 15:39     ` Stefan Wahren
2023-04-06 16:58     ` Jim Quinlan
2023-04-06 16:58       ` Jim Quinlan
2023-04-06 18:35       ` Krzysztof Kozlowski
2023-04-06 18:35         ` Krzysztof Kozlowski
2023-04-06 18:47         ` Florian Fainelli
2023-04-06 18:47           ` Florian Fainelli
2023-04-06 18:53           ` Krzysztof Kozlowski
2023-04-06 18:53             ` Krzysztof Kozlowski
2023-04-06 18:34   ` Krzysztof Kozlowski
2023-04-06 18:34     ` Krzysztof Kozlowski
2023-04-06 18:53     ` Florian Fainelli
2023-04-06 18:53       ` Florian Fainelli
2023-04-06 18:54       ` Krzysztof Kozlowski
2023-04-06 18:54         ` Krzysztof Kozlowski
2023-04-06 12:46 ` [PATCH v1 2/3] PCI: brcmstb: Clkreq# accomodations of downstream device Jim Quinlan
2023-04-06 12:46   ` Jim Quinlan
2023-04-06 19:09   ` Bjorn Helgaas [this message]
2023-04-06 19:09     ` Bjorn Helgaas
2023-04-06 20:03     ` Jim Quinlan
2023-04-06 20:03       ` Jim Quinlan
2023-04-06 12:46 ` [PATCH v1 3/3] PCI: brcmstb: Allow setting the completion timeout Jim Quinlan
2023-04-06 12:46   ` Jim Quinlan
2023-04-06 15:59   ` Stefan Wahren
2023-04-06 15:59     ` Stefan Wahren
2023-04-06 17:15     ` Jim Quinlan
2023-04-06 17:15       ` Jim Quinlan
2023-04-06 21:31 ` [PATCH v1 0/3] PCI: brcmstb: Clkreq# accomodations of downstream device Cyril Brulebois
2023-04-06 21:31   ` Cyril Brulebois
2023-04-07 15:06   ` Hank Barta
2023-04-07 15:06     ` Hank Barta

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=20230406190953.GA3723665@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=f.fainelli@gmail.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.