Re: [PATCH v5 2/5] dt-bindings: net: wireless: brcm4329-fmac: add clock description for AP6275P

From: andy@warmcat.com
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Jacobe Zang <jacobe.zang@wesion.com>,
	robh@kernel.org, krzk+dt@kernel.org, heiko@sntech.de,
	kvalo@kernel.org, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, conor+dt@kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	efectn@protonmail.com, dsimic@manjaro.org, jagan@edgeble.ai,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	arend@broadcom.com, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, megi@xff.cz, duoming@zju.edu.cn,
	bhelgaas@google.com, minipli@grsecurity.net,
	brcm80211@lists.linux.dev, brcm80211-dev-list.pdl@broadcom.com,
	nick@khadas.com
Subject: Re: [PATCH v5 2/5] dt-bindings: net: wireless: brcm4329-fmac: add clock description for AP6275P
Date: Wed, 31 Jul 2024 14:12:02 +0100	[thread overview]
Message-ID: <377dc5cd-c9a2-4632-a819-6b28762191a6@warmcat.com> (raw)
In-Reply-To: <dd381dc1-454f-4ecd-adb7-55de2e15d592@broadcom.com>

On 7/31/24 1:57 PM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> On 7/30/2024 7:38 PM, Sebastian Reichel wrote:

> > be probed. To become visible the devices requires:
> >
> > 1. The LPO clock to be enabled
> > 2. Power to be applied
> > 3. The WL_EN gpio to be configured correctly
> >
> > If one of the above is not met, the device will not even appear in
> > 'lspci'. I believe the binding needs to take into consideration, that
> > pwrseq is needed for the PCIe side. Fortuantely the heavy lifting of
> > creating the proper infrastructure for this has already been done by
> > Bartosz Golaszewski for Qualcomm WLAN chips. What is missing is a
> > pwrseq driver for the Broadcom chip (or this specific module?).
> 
> That does not really make sense. There is no relation between the LPO 
> clock and the PCIe clocks so 1) being a requirement for probing the 
> device looks odd. It also does not match past experience when I assisted 
> Andy Green in getting this module up and running almost two years ago.
> 
> """
> On 11/9/22 18:26, Arend Van Spriel wrote:
>  > On November 8, 2022 11:48:22 AM Andy Green <andy@warmcat.com> wrote:
>  >> Hi -
>  >>
>  >> I'm trying to bring up AP6275 support on 6.1-rc4... I have tried a 
> forward-ported sdk broadcom driver from the 5.10 based soc sdk, and the 
> mainline brcm fullmac driver.
>  >
>  > Do you have a reference to the SDK? For what SoC?
> 
> Hi Arend -
> 
> It's the OOT broadcom driver that came with the latest (Sept 2022) 
> vendor SDK for RK3588, from Rockchip.  Their evb has an AP6275 onboard.
> 
> PCIe generally is working on this (eg, for NVMe in the PCIe 4-lane slot) 
> and for network, and the PCIe part seems OK when I hack in a gpio 
> regulator to hold up the module enable gpio.
> """
> 
> So regarding 2) and 3) I agree with you.

As far as I recall (there has been a lot of water under the bridge) I think everyone has had the same experience and correctly explaining it... pcie can work generally on that platform (say, for nvme) fine, without reference to 32kHz RTC clock; but for specifically the AP6275 module being the pcie device, he won't play ball unless he came up with 32kHz to the module.  It felt like, eg, he used that as the input for his main PLL or somesuch.

So 1) is just a requirement of that module to come up and then appear as a pcie device, it's not trying to say generally that pcie function depends on 32kHz coming on that platform.

HTH

-Andy

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip