From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Krzysztof Wilczy??ski <kw@linux.com>,
Rob Herring <robh@kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
quic_krichai@quicinc.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v3] PCI: Add D3 support for PCI bridges in DT based platforms
Date: Tue, 5 Mar 2024 21:55:37 +0530 [thread overview]
Message-ID: <20240305162537.GA8339@thinkpad> (raw)
In-Reply-To: <20240222094052.GA25101@wunner.de>
On Thu, Feb 22, 2024 at 10:40:52AM +0100, Lukas Wunner wrote:
> On Wed, Feb 21, 2024 at 12:20:00PM -0600, Bjorn Helgaas wrote:
> > 1) D3hot doesn't work per spec. This sounds like a hardware
> > defect in the device that should be a quirk based on
> > Vendor/Device ID, not something in DT. I don't actually know if
> > this is common, although there are several existing quirks that
> > mention issues with D3.
>
> My recollection is that putting Root Ports into D3hot on older x86
> systems would raise MCEs, which is why pci_bridge_d3_possible() only
> allows D3hot in cases which are known to work (e.g. Thunderbolt
> controllers, machines with a recent BIOS). It was a conservative
> policy chosen to avoid regressions.
>
So pci_bridge_d3_possible() is only checking for D3hot capability? If so, I'd
rename it to pci_bridge_d3hot_possible() and also 'bridge_d3' to 'bridge_d3hot'
to make it explicit.
Since the default value of 'd3cold_allowed' is true, I believe the code expects
all devices to support D0 and D3cold. Please correct me if I'm wrong.
- Mani
> I don't know if similar issues exist on non-ACPI systems. If they
> don't exist, platform_pci_bridge_d3() could just return true for
> all devicetree-based systems. Might be worth testing if any systems
> can be found which exhibit issues with such a policy. That would
> obviate the need to specify "supports-d3" in the devicetree.
> Quite the opposite, ports which are known not to work could be
> blacklisted. Of course if it turns out that's the majority then
> whitelisting via "supports-d3" is a better option.
>
>
> > 2) The platform doesn't support putting the bridge in D3cold and
> > back to D0. I don't understand this either because I assumed DT
> > would describe *hardware*, and "supports-d3" might imply the
> > presence of hardware power control, but doesn't tell us how to
> > operate it, and it must be up to a native driver to know how to
> > do it.
>
> I think we're putting devices into D3hot first before cutting power
> (i.e. putting them into D3cold), so knowing that D3hot is safe is
> basically a prerequisite for D3cold.
>
> Thanks,
>
> Lukas
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-03-05 16:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 11:46 [PATCH v3] PCI: Add D3 support for PCI bridges in DT based platforms Manivannan Sadhasivam
2024-02-14 12:19 ` Lukas Wunner
2024-02-20 22:02 ` Bjorn Helgaas
2024-02-21 5:19 ` Manivannan Sadhasivam
2024-02-21 18:20 ` Bjorn Helgaas
2024-02-22 4:06 ` Manivannan Sadhasivam
2024-02-26 23:39 ` Bjorn Helgaas
2024-02-27 7:30 ` Manivannan Sadhasivam
2024-02-27 16:25 ` Bjorn Helgaas
2024-02-27 17:08 ` Manivannan Sadhasivam
2024-02-27 17:37 ` Bjorn Helgaas
2024-02-27 18:40 ` Manivannan Sadhasivam
2024-02-27 22:54 ` Bjorn Helgaas
2024-02-22 9:40 ` Lukas Wunner
2024-02-26 23:17 ` Bjorn Helgaas
2024-03-05 16:25 ` Manivannan Sadhasivam [this message]
2024-03-05 17:51 ` 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=20240305162537.GA8339@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=andersson@kernel.org \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=quic_krichai@quicinc.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.