[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241018231305.GA768070@bhelgaas>
Date: Fri, 18 Oct 2024 18:13:05 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Richard Zhu <hongxing.zhu@....com>
Cc: kw@...ux.com, manivannan.sadhasivam@...aro.org, bhelgaas@...gle.com,
lpieralisi@...nel.org, frank.li@....com, l.stach@...gutronix.de,
robh+dt@...nel.org, conor+dt@...nel.org, shawnguo@...nel.org,
krzysztof.kozlowski+dt@...aro.org, festevam@...il.com,
s.hauer@...gutronix.de, linux-pci@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, kernel@...gutronix.de,
imx@...ts.linux.dev
Subject: Re: [PATCH v4 1/9] dt-bindings: imx6q-pcie: Add ref clock for i.MX95
PCIe RC
On Tue, Oct 15, 2024 at 04:33:25PM +0800, Richard Zhu wrote:
> Previous reference clock of i.MX95 PCIe RC is on when system boot to
> kernel. But boot firmware change the behavor, it is off when boot. So it
> needs be turn on when it is used. Also it needs be turn off/on when suspend
> and resume.
I think this background would make more sense in patch 2. IIUC,
that's where the driver behavior changes to do something with the
"ref" clock.
I'm not sure how to interpret "Previous reference clock of i.MX95 PCIe
RC is on when system boot to kernel. But boot firmware change the
behavor, it is off when boot."
Does that mean a previous version of the boot firmware left the ref
clock on at handoff to the OS, and newer firmware turns it off? If
so, I think it would be useful to include information about the
relevant firmware versions.
> Add one ref clock for i.MX95 PCIe RC. Increase clocks' maxItems to 5 and keep
> the same restriction with other compatible string.
Powered by blists - more mailing lists