Hello Siddharth, Le 10/01/2025 à 09:15, Siddharth Vadapalli a écrit : > 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. Ok, thanks for the explanation. I beleive it's worth to add it to the commit log. Best regards, Romain > >> >> Otherwise I'm fine to use 0x_0011_a090. >> >> Best regards, >> Romain > > Regards, > Siddharth.
