Re: [PATCH v4 2/2] arm64: dts: ti: k3-j721e-beagleboneai64: Enable ACSPCIE output for PCIe1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 09, 2025 at 02:51:23PM +0100, Romain Naour wrote:
> Hello Siddharth, All,

Hello Romain,

> 
> Le 09/01/2025 à 12:49, Siddharth Vadapalli a écrit :
> > On Thu, Jan 09, 2025 at 11:26:27AM +0100, Romain Naour wrote:
> > 
> > Hello Romain,
> > 
> >> From: Romain Naour <romain.naour@xxxxxxx>
> >>
> >> Unlike the SK-TDA4VM (k3-j721e-sk) board, there is no clock generator
> >> (CDCI6214RGET) on the BeagleBone AI-64 (k3-j721e-beagleboneai64) to
> >> provide PCIe refclk signal to PCIe Endponts. So the ACSPCIE module must
> >> provide refclk through PCIe_REFCLK pins.
> >>
> >> Use the new "ti,syscon-acspcie-proxy-ctrl" property to enable ACSPCIE
> >> module's PAD IO Buffers.
> >>
> >> Cc: Siddharth Vadapalli <s-vadapalli@xxxxxx>
> >> Signed-off-by: Romain Naour <romain.naour@xxxxxxx>
> >> ---
> >> With this patch, we can remove "HACK: Sierra: Drive clock out" patch
> >> applied on vendor kernel for BeagleBone AI-64:
> >> https://openbeagle.org/beagleboard/linux/-/commit/ad65d7ef675966cdbc5d75f2bd545fad1914ba9b
> > 
> > [trimmed]
> > 
> >> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> >> index af3d730154ac..32a232a90100 100644
> >> --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> >> +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> >> @@ -5,6 +5,7 @@
> >>   * Copyright (C) 2016-2024 Texas Instruments Incorporated - https://www.ti.com/
> >>   */
> >>  #include <dt-bindings/phy/phy.h>
> >> +#include <dt-bindings/phy/phy-cadence.h>
> >>  #include <dt-bindings/phy/phy-ti.h>
> >>  #include <dt-bindings/mux/mux.h>
> >>  
> >> @@ -82,6 +83,11 @@ ehrpwm_tbclk: clock-controller@4140 {
> >>  			reg = <0x4140 0x18>;
> >>  			#clock-cells = <1>;
> >>  		};
> >> +
> >> +		acspcie0_proxy_ctrl: syscon@18090 {
> >> +			compatible = "ti,j721e-acspcie-proxy-ctrl", "syscon";
> >> +			reg = <0x18090 0x4>;
> > 
> > 0x_0011_8090 is probably *not* the "PROXY" register i.e. it could be
> > locked with the help of "CTRLMMR_LOCK0_KICK0" and "CTRLMMR_LOCK0_KICK1"
> > registers, in which case the CTRL_MMR region needs to be unlocked to write
> > to that register. On J784S4, that happens to be true, which is why the
> > proxy register 0x_0011_a090 was used at [0]. Please test with 0x_0011_a090
> > which is the "PROXY" register on J721E as well, i.e. it can be written to
> > unconditionally.
> > 
> > [0]:
> > https://lore.kernel.org/r/20240930111505.3101047-1-s-vadapalli@xxxxxx/
> 
> Thanks for the review!
> 
> Actually the Proxy0 vs Proxy1 choice is not really clear for me. We have two
> proxy to reach the same register:
> 
>   CTRLMMR_ACSPCIE0_CTRL Register (Proxy0 Offset = 18090h; Proxy1 Offset = 1A090h)
> 
> From my testing both addresses works (maybe since my SoC is a general purpose one).
> 
> When and why Proxy1 must be used?

Yes, both Proxy0 and Proxy1 work, but Proxy0 is the default access path
when we look at it in the context of J784S4. On J784S4, instead of
calling out Proxy0, the register is called ACSPCIE0_CTRL when it falls
in the Proxy0 range, while it is called ACSPCIE0_PROXY_CTRL when it
falls in the Proxy1 range. Therefore, from the perspective of the naming
convention followed on J784S4 for which a compatible was first introduced,
Proxy1 address would correspond to the ACSPCIE0_PROXY_CTRL register.

> 
> Otherwise I'm fine to use  0x_0011_a090.
> 
> Best regards,
> Romain

Regards,
Siddharth.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux