Re: [PATCH v5 2/2] PCI: imx6: Add a method to handle CLKREQ# override active low

[Bjorn Helgaas <helgaas@kernel.org>]

On Fri, Sep 26, 2025 at 03:08:30AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>

> > On Fri, Sep 26, 2025 at 02:19:37AM +0000, Hongxing Zhu wrote:
> > > > -----Original Message-----
> > > > From: Bjorn Helgaas <helgaas@kernel.org> On Tue, Sep 23, 2025 at
> > > > 03:39:13PM +0800, Richard Zhu wrote:
> > > > > The CLKREQ# is an open drain, active low signal that is
> > > > > driven low by the card to request reference clock. It's an
> > > > > optional signal added in PCIe CEM r4.0, sec 2. Thus, this
> > > > > signal wouldn't be driven low if it's reserved.
> > > > >
> > > > > Since the reference clock controlled by CLKREQ# may be
> > > > > required by i.MX PCIe host too. To make sure this clock is
> > > > > ready even when the CLKREQ# isn't driven low by the card(e.x
> > > > > the scenario described above), force CLKREQ# override active
> > > > > low for i.MX PCIe host during initialization.
> > > > >
> > > > > The CLKREQ# override can be cleared safely when
> > > > > supports-clkreq is present and PCIe link is up later.
> > > > > Because the CLKREQ# would be driven low by the card at this
> > > > > time.
> > > >
> > > > What happens if we clear the CLKREQ# override (so the host
> > > > doesn't assert it), and the link is up but the card never
> > > > asserts CLKREQ# (since it's an optional signal)?
> > > >
> > > > Does the i.MX host still work?
> > >
> > > The CLKREQ# override active low only be cleared when link is up
> > > and supports-clkreq is present. In the other words, there is a
> > > remote endpoint  device, and the CLKREQ# would be driven active
> > > low by this endpoint device.
> > 
> > Assume an endpoint designed to CEM r2.0.  CLKREQ# doesn't exist in
> > CEM r2.0, so even if the endpoint is present and the link is up,
> > the endpoint will not assert CLKREQ#.
> > 
> > Will the i.MX host still work?

> Yes, i.MX host still work. 
> If the endpoint designed to CEM r2.0, and CLKREQ# is reserved. The
> property suppots-clkreq wouldn't present in this scenario. Thus, the
> CLKREQ# override active low set by host driver wouldn't be cleared
> later, although the link is up and an endpoint is present.

Do you mean 'supports-clkreq' describes the *endpoint*, and you need
to change the devicetree depending on which endpoint is connected?

The schema says 'supports-clkreq' tells us whether CLKREQ# signal
routing exists, not whether the downstream device actually supports
CLKREQ#:

  https://github.com/devicetree-org/dt-schema/blob/4b28bc79fdc552f3e0b870ef1362bb711925f4f3/dtschema/schemas/pci/pci-bus-common.yaml#L155

I don't see 'supports-clkreq' in any devicetree related to imx6, so
I'm not sure this patch is needed yet.  Does it fix an existing
problem?

If it enables some future functionality, maybe we should defer it
until we're actually ready to enable that functionality?

Bjorn