| Message ID | 20240730033053.4092132-3-jacobe.zang@wesion.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add AP6275P wireless support | expand |
On 30/07/2024 05:30, Jacobe Zang wrote: > Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow > external low power clock input. In DTS the clock as an optional choice in > the absence of an internal clock. > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
+ Linus W On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: > Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow > external low power clock input. In DTS the clock as an optional choice in > the absence of an internal clock. > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> > --- > .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > index 2c2093c77ec9a..a3607d55ef367 100644 > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > @@ -122,6 +122,14 @@ properties: > NVRAM. This would normally be filled in by the bootloader from platform > configuration data. > > + clocks: > + items: > + - description: External Low Power Clock input (32.768KHz) > + > + clock-names: > + items: > + - const: lpo > + We still have an issue that this clock input is also present in the bindings specification broadcom-bluetooth.yaml (not in bluetooth subfolder). This clock is actually a chip resource. What happens if both are defined and both wifi and bt drivers try to enable this clock? Can this be expressed in yaml or can we only put a textual warning in the property descriptions? Regards, Arend
On 30/07/2024 08:37, Arend Van Spriel wrote: > + Linus W > > On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: > >> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >> external low power clock input. In DTS the clock as an optional choice in >> the absence of an internal clock. >> >> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >> --- >> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git >> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >> index 2c2093c77ec9a..a3607d55ef367 100644 >> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >> @@ -122,6 +122,14 @@ properties: >> NVRAM. This would normally be filled in by the bootloader from platform >> configuration data. >> >> + clocks: >> + items: >> + - description: External Low Power Clock input (32.768KHz) >> + >> + clock-names: >> + items: >> + - const: lpo >> + > > We still have an issue that this clock input is also present in the > bindings specification broadcom-bluetooth.yaml (not in bluetooth > subfolder). This clock is actually a chip resource. What happens if both > are defined and both wifi and bt drivers try to enable this clock? Can this > be expressed in yaml or can we only put a textual warning in the property > descriptions? Just like all clocks, what would happen? It will be enabled. Best regards, Krzysztof
On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > On 30/07/2024 08:37, Arend Van Spriel wrote: >> + Linus W >> >> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >> >>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>> external low power clock input. In DTS the clock as an optional choice in >>> the absence of an internal clock. >>> >>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>> --- >>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>> index 2c2093c77ec9a..a3607d55ef367 100644 >>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>> @@ -122,6 +122,14 @@ properties: >>> NVRAM. This would normally be filled in by the bootloader from platform >>> configuration data. >>> >>> + clocks: >>> + items: >>> + - description: External Low Power Clock input (32.768KHz) >>> + >>> + clock-names: >>> + items: >>> + - const: lpo >>> + >> >> We still have an issue that this clock input is also present in the >> bindings specification broadcom-bluetooth.yaml (not in bluetooth >> subfolder). This clock is actually a chip resource. What happens if both >> are defined and both wifi and bt drivers try to enable this clock? Can this >> be expressed in yaml or can we only put a textual warning in the property >> descriptions? > > Just like all clocks, what would happen? It will be enabled. Oh, wow! Cool stuff. But seriously is it not a problem to have two entities controlling one and the same clock? Is this use-case taken into account by the clock framework? Regards, Arend
>> On 30/07/2024 08:37, Arend Van Spriel wrote: >>> + Linus W >>> >>> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>> >>>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>> external low power clock input. In DTS the clock as an optional choice in >>>> the absence of an internal clock. >>>> >>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>> --- >>>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> index 2c2093c77ec9a..a3607d55ef367 100644 >>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> @@ -122,6 +122,14 @@ properties: >>>> NVRAM. This would normally be filled in by the bootloader from platform >>>> configuration data. >>>> >>>> + clocks: >>>> + items: >>>> + - description: External Low Power Clock input (32.768KHz) >>>> + >>>> + clock-names: >>>> + items: >>>> + - const: lpo >>>> + >>> >>> We still have an issue that this clock input is also present in the >>> bindings specification broadcom-bluetooth.yaml (not in bluetooth >>> subfolder). This clock is actually a chip resource. What happens if both >>> are defined and both wifi and bt drivers try to enable this clock? Can this >>> be expressed in yaml or can we only put a textual warning in the property >>> descriptions? >> >> Just like all clocks, what would happen? It will be enabled. > > Oh, wow! Cool stuff. But seriously is it not a problem to have two entities > controlling one and the same clock? Is this use-case taken into account by > the clock framework? I have enabled the same clock both in bluetooth and wifi just now, they worked well. Maybe this make sense? --- Best Regards Jacobe
On July 30, 2024 12:00:25 PM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>> On 30/07/2024 08:37, Arend Van Spriel wrote: >>>> + Linus W >>>> >>>> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>>> >>>>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>>> external low power clock input. In DTS the clock as an optional choice in >>>>> the absence of an internal clock. >>>>> >>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>>> --- >>>>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>>> 1 file changed, 8 insertions(+) >>>>> >>>>> diff --git >>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> index 2c2093c77ec9a..a3607d55ef367 100644 >>>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> @@ -122,6 +122,14 @@ properties: >>>>> NVRAM. This would normally be filled in by the bootloader from platform >>>>> configuration data. >>>>> >>>>> + clocks: >>>>> + items: >>>>> + - description: External Low Power Clock input (32.768KHz) >>>>> + >>>>> + clock-names: >>>>> + items: >>>>> + - const: lpo >>>>> + >>>> >>>> We still have an issue that this clock input is also present in the >>>> bindings specification broadcom-bluetooth.yaml (not in bluetooth >>>> subfolder). This clock is actually a chip resource. What happens if both >>>> are defined and both wifi and bt drivers try to enable this clock? Can this >>>> be expressed in yaml or can we only put a textual warning in the property >>>> descriptions? >>> >>> Just like all clocks, what would happen? It will be enabled. >> >> Oh, wow! Cool stuff. But seriously is it not a problem to have two entities >> controlling one and the same clock? Is this use-case taken into account by >> the clock framework? > > I have enabled the same clock both in bluetooth and wifi just now, they worked > well. Maybe this make sense? What happens if you unload one of the drivers? Also would like to know if you are using an nvram file. If so can you share it's content. Regards, Arend
>>>> On 30/07/2024 08:37, Arend Van Spriel wrote: >>>>> + Linus W >>>>> >>>>> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>>>> >>>>>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>>>> external low power clock input. In DTS the clock as an optional choice in >>>>>> the absence of an internal clock. >>>>>> >>>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>>>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>>>> --- >>>>>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>>>> 1 file changed, 8 insertions(+) >>>>>> >>>>>> diff --git >>>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>> index 2c2093c77ec9a..a3607d55ef367 100644 >>>>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>> @@ -122,6 +122,14 @@ properties: >>>>>> NVRAM. This would normally be filled in by the bootloader from platform >>>>>> configuration data. >>>>>> >>>>>> + clocks: >>>>>> + items: >>>>>> + - description: External Low Power Clock input (32.768KHz) >>>>>> + >>>>>> + clock-names: >>>>>> + items: >>>>>> + - const: lpo >>>>>> + >>>>> >>>>> We still have an issue that this clock input is also present in the >>>>> bindings specification broadcom-bluetooth.yaml (not in bluetooth >>>>> subfolder). This clock is actually a chip resource. What happens if both >>>>> are defined and both wifi and bt drivers try to enable this clock? Can this >>>>> be expressed in yaml or can we only put a textual warning in the property >>>>> descriptions? >>>> >>>> Just like all clocks, what would happen? It will be enabled. >>> >>> Oh, wow! Cool stuff. But seriously is it not a problem to have two entities >>> controlling one and the same clock? Is this use-case taken into account by >>> the clock framework? >> >> I have enabled the same clock both in bluetooth and wifi just now, they worked >> well. Maybe this make sense? > > What happens if you unload one of the drivers? Also would like to know if > you are using an nvram file. If so can you share it's content. After rmmod the wifi relevant driver, bluetooth still works well. The content of nvram text shows below: # AP6275P_NVRAM_V1.1_20200702 # AP6271P_V00 board, iPA version. # nvram copied and edited from AP6271P_EVB_V01 EVB board // # SSID generated using Alberto's boardssid.py script: # ********************SUMMARY******************** # Board Name: AP6271P_V00 #SSID: 0x086d #macmid: 0x02df # Successfully made SSID entry in sromdefs.tcl. # Successfully made macmid entry in sromdefs.tcl. # Successfully made SSID entry in tblssid.py. # ************************************************* # $ Copyright Broadcom $ # # # <<Broadcom-WL-IPTag/Proprietary:>> NVRAMRev=$Rev: 874188 $ sromrev=11 boardrev=0x1213 boardtype=0x08ed boardflags=0x00400201 boardflags2=0xc0800000 boardflags3=0x40002180 #boardnum=57410 macaddr=00:90:4c:12:d0:01 jtag_irw=38 #Regulatory specific ccode=0 regrev=0 # Board specific vendid=0x14e4 devid=0x449d manfid=0x2d0 antswitch=0 pdgain5g=0 pdgain2g=0 aa2g=3 aa5g=3 agbg0=2 agbg1=2 aga0=2 aga1=2 extpagain2g=2 extpagain5g=2 rxgains2gelnagaina0=0 rxgains2gtrisoa0=0 rxgains2gtrelnabypa0=0 rxgains5gelnagaina0=0 rxgains5gtrisoa0=0 rxgains5gtrelnabypa0=0 rxgains5gmelnagaina0=0 rxgains5gmtrisoa0=0 rxgains5gmtrelnabypa0=0 rxgains5ghelnagaina0=0 rxgains5ghtrisoa0=0 rxgains5ghtrelnabypa0=0 rxgains2gelnagaina1=0 rxgains2gtrisoa1=0 rxgains2gtrelnabypa1=0 rxgains5gelnagaina1=0 rxgains5gtrisoa1=0 rxgains5gtrelnabypa1=0 rxgains5gmelnagaina1=0 rxgains5gmtrisoa1=0 rxgains5gmtrelnabypa1=0 rxgains5ghelnagaina1=0 rxgains5ghtrisoa1=0 rxgains5ghtrelnabypa1=0 #RSSI related # 2G rssicorrnorm_c0=4,4 rssicorrnorm_c1=4,4 # 5G rssicorrnorm5g_c0=5,5,5,5,5,5,5,5,5,5,5,5 rssicorrnorm5g_c1=4,4,4,4,4,4,4,4,4,4,4,4 #Two range TSSI tworangetssi2g=0 tworangetssi5g=0 lowpowerrange2g=0 lowpowerrange5g=0 low_adc_rate_en=1 nocrc=1 otpimagesize=502 xtalfreq=37400 txchain=3 rxchain=3 cckdigfilttype=2 #bit mask for slice capability bit 0:2G bit 1:5G bandcap=3 #TXBF Related rpcal2g=0 rpcal5gb0=0 rpcal5gb1=0 rpcal5gb2=0 rpcal5gb3=0 #FDSS Related fdss_level_2g=4,4 fdss_interp_en=1 fdss_level_5g=3,3 fdss_level_11ax_2g=3,3 fdss_level_11ax_2g_ch1=3,3 fdss_level_11ax_2g_ch11=3,3 fdss_level_11ax_5g=3,3 #Tempsense Related tempthresh=255 tempoffset=40 rawtempsense=0x1ff phycal_tempdelta=15 temps_period=15 temps_hysteresis=15 #------------- TSSI Related ------------- tssipos2g=1 tssipos5g=1 AvVmid_c0=2,127,4,92,4,91,4,91,4,94 AvVmid_c1=2,127,4,93,4,93,4,95,3,110 # CCK in case of multi mode 2 pa2gccka0=-137,7810,-928 pa2gccka1=-139,7853,-929 # OFDM in case of multi_mode 2 pa2ga0=-103,7727,-855 pa2ga1=-126,7258,-826 pa5ga0=-176,5703,-703,-180,5747,-708,-165,5994,-732,-146,6299,-757 pa5ga1=-132,6132,-760,-107,6472,-769,-142,6184,-752,-108,7237,-858 # Max power and offsets maxp2ga0=86 maxp2ga1=86 maxp5ga0=74,74,74,74 maxp5ga1=68,68,68,70 subband5gver=0x4 paparambwver=3 cckpwroffset0=0 cckpwroffset1=0 pdoffset40ma0=0x4433 pdoffset80ma0=0x3232 pdoffset40ma1=0x2333 pdoffset80ma1=0x1222 cckbw202gpo=0x2222 cckbw20ul2gpo=0 mcsbw202gpo=0x98533221 mcsbw402gpo=0x44000000 dot11agofdmhrbw202gpo=0x4444 ofdmlrbw202gpo=0x0033 mcsbw205glpo=0x49533322 mcsbw405glpo=0xE9443342 mcsbw805glpo=0xEC665542 mcsbw1605glpo=0 mcsbw205gmpo=0x49200000 mcsbw405gmpo=0xE9443342 mcsbw805gmpo=0xEC665542 mcsbw1605gmpo=0 mcsbw205ghpo=0x49312220 #mcsbw405ghpo=0x84-1-1-2-2-2-5 mcsbw405ghpo=0xC8221110 #mcsbw405ghpo=0x88555555 mcsbw805ghpo=0xCC443320 powoffs2gtna0=0,0,0,0,0,0,0,0,0,0,0,0,0,0 powoffs2gtna1=0,0,0,0,0,0,0,0,0,0,0,0,0,0 mcs1024qam2gpo=0xDDDD mcs1024qam5glpo=0xFFFFCC mcs1024qam5gmpo=0xFFFFCC mcs1024qam5ghpo=0xFFFFCC mcs1024qam5gx1po=0xFFFFCC mcs1024qam5gx2po=0xFFFFCC mcs8poexp=0 mcs9poexp=0 mcs10poexp=0 # 5G power offset per channel for band edge channel powoffs5g20mtna0=0,0,0,0,0,0,0 powoffs5g20mtna1=0,0,0,0,0,0,0 powoffs5g40mtna0=0,0,0,0,0 powoffs5g40mtna1=0,0,0,0,0 powoffs5g80mtna0=0,0,0,0,0 powoffs5g80mtna1=0,0,0,0,0 mcs11poexp=0 #LTE Coex Related ltecxmux=0 ltecxpadnum=0x0504 ltecxfnsel=0x44 ltecxgcigpio=0x04 #OOB params #device_wake_opt=1 host_wake_opt=0 # SWCTRL Related swctrlmap_2g=0x10101010,0x06030401,0x04011010,0x000000,0x3FF swctrlmapext_2g=0x00000000,0x00000000,0x00000000,0x000000,0x000 swctrlmap_5g=0x80408040,0x21240120,0x01208040,0x000000,0x3FF swctrlmapext_5g=0x00000000,0x00000000,0x00000000,0x000000,0x000 clb2gslice0core0=0x01b clb2gslice1core0=0x000 clb5gslice0core0=0x064 clb5gslice1core0=0x000 clb2gslice0core1=0x056 clb2gslice1core1=0x000 clb5gslice0core1=0x0a1 clb5gslice1core1=0x000 btc_prisel_ant_mask=0x2 clb_swctrl_smask_ant0=0x27f clb_swctrl_smask_ant1=0x2f7 muxenab=1 #BT Coex 1:TDM btc_mode=1 # --- PAPD Cal related params ---- txwbpapden=0 # 0:NBPAPD 1:WBPAPD # NB PAPD Cal params nb_eps_offset=470,470 nb_bbmult=66,66 nb_papdcalidx=6,6 nb_txattn=2,2 nb_rxattn=1,1 nb_eps_stopidx=63 epsilonoff_5g20_c0=0,0,0,0 epsilonoff_5g40_c0=0,0,0,0 epsilonoff_5g80_c0=0,0,0,0 epsilonoff_5g20_c1=0,0,0,0 epsilonoff_5g40_c1=0,0,0,0 epsilonoff_5g80_c1=0,0,-1,-1 epsilonoff_2g20_c0=0 epsilonoff_2g20_c1=0 # energy detect threshold ed_thresh2g=-67 ed_thresh5g=-67 # energy detect threshold for EU eu_edthresh2g=-67 eu_edthresh5g=-67 #rpcal coef for imptxbf rpcal5gb0=238 rpcal5gb1=228 rpcal5gb2=222 rpcal5gb3=229 rpcal2g=15 ocl=1 bt_coex_chdep_div=1 # OLPC Related disable_olpc=0 olpc_thresh5g=32 olpc_anchor5g=40 olpc_thresh2g=32 olpc_anchor2g=40 #PAPR related paprdis=0 paprrmcsgamma2g=500,550,550,-1,-1,-1,-1,-1,-1,-1,-1,-1 paprrmcsgain2g=128,128,128,0,0,0,0,0,0,0,0,0 paprrmcsgamma2g_ch13=500,550,550,-1,-1,-1,-1,-1,-1,-1,-1,-1 paprrmcsgain2g_ch13=128,128,128,0,0,0,0,0,0,0,0,0 paprrmcsgamma2g_ch1=500,550,550,-1,-1,-1,-1,-1,-1,-1,-1,-1 paprrmcsgain2g_ch1=128,128,128,0,0,0,0,0,0,0,0,0 paprrmcsgamma5g20=500,500,500,-1,-1,-1,-1,-1,-1,-1,-1,-1 paprrmcsgain5g20=128,128,128,0,0,0,0,0,0,0,0,0 paprrmcsgamma5g40=600,600,600,-1,-1,-1,-1,-1,-1,-1,-1,-1 paprrmcsgain5g40=128,128,128,0,0,0,0,0,0,0,0,0 paprrmcsgamma5g80=-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 paprrmcsgain5g80=0,0,0,0,0,0,0,0,0,0,0,0 # Enable papd for cck when target pwr ge 16dBm cckpapd_pwrthresh=64 ## ULOFDMA Board limit PPRs for 2G20 ## ruppr2g20bpska0=0x0 ruppr2g20bpska1=0x0 ruppr2g20qpska0=0x0 ruppr2g20qpska1=0x0 ruppr2g20qam16a0=0x0 ruppr2g20qam16a1=0x0 ruppr2g20qam64a0=0x1 ruppr2g20qam64a1=0x1 ruppr2g20qam256a0=0x21084 ruppr2g20qam256a1=0x21084 ruppr2g20qam1024a0=0x0 ruppr2g20qam1024a1=0x0 ## ULOFDMA Board limit PPRs for 5G20 ## ruppr5g20bpska0=0x20000 ruppr5g20bpska1=0x20000 ruppr5g20qpska0=0x18000 ruppr5g20qpska1=0x18000 ruppr5g20qam16a0=0x28000 ruppr5g20qam16a1=0x28000 ruppr5g20qam64a0=0x29086 ruppr5g20qam64a1=0x29086 ruppr5g20qam256a0=0x62908 ruppr5g20qam256a1=0x62908 ruppr5g20qam1024a0=0x70000 ruppr5g20qam1024a1=0x70000 ## ULOFDMA Board limit PPRs for 5G40 ## ruppr5g40bpska0=0x638000 ruppr5g40bpska1=0x638000 ruppr5g40qpska0=0x840020 ruppr5g40qpska1=0x840020 ruppr5g40qam16a0=0x638001 ruppr5g40qam16a1=0x638001 ruppr5g40qam64a0=0x739085 ruppr5g40qam64a1=0x739085 ruppr5g40qam256a0=0x106a108 ruppr5g40qam256a1=0x106a108 ruppr5g40qam1024a0=0x1078000 ruppr5g40qam1024a1=0x1078000 ## ULOFDMA Board limit PPRs for 5G80 ## ruppr5g80bpska0=0x0 ruppr5g80bpska1=0x0 ruppr5g80qpska0=0x0 ruppr5g80qpska1=0x0 ruppr5g80qam16a0=0x0 ruppr5g80qam16a1=0x0 ruppr5g80qam64a0=0x187218e7 ruppr5g80qam64a1=0x187218e7 ruppr5g80qam256a0=0x3904254a ruppr5g80qam256a1=0x3904254a ruppr5g80qam1024a0=0x49068000 ruppr5g80qam1024a1=0x49068000 --- Best Regards Jacobe
On 30/07/2024 11:52, Arend Van Spriel wrote: > On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> On 30/07/2024 08:37, Arend Van Spriel wrote: >>> + Linus W >>> >>> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>> >>>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>> external low power clock input. In DTS the clock as an optional choice in >>>> the absence of an internal clock. >>>> >>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>> --- >>>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> index 2c2093c77ec9a..a3607d55ef367 100644 >>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>> @@ -122,6 +122,14 @@ properties: >>>> NVRAM. This would normally be filled in by the bootloader from platform >>>> configuration data. >>>> >>>> + clocks: >>>> + items: >>>> + - description: External Low Power Clock input (32.768KHz) >>>> + >>>> + clock-names: >>>> + items: >>>> + - const: lpo >>>> + >>> >>> We still have an issue that this clock input is also present in the >>> bindings specification broadcom-bluetooth.yaml (not in bluetooth >>> subfolder). This clock is actually a chip resource. What happens if both >>> are defined and both wifi and bt drivers try to enable this clock? Can this >>> be expressed in yaml or can we only put a textual warning in the property >>> descriptions? >> >> Just like all clocks, what would happen? It will be enabled. > > Oh, wow! Cool stuff. But seriously is it not a problem to have two entities > controlling one and the same clock? Is this use-case taken into account by > the clock framework? Yes, it is handled correctly. That's a basic use-case, handled by CCF since some years (~12?). Anyway, whatever OS is doing (or not doing) with the clocks is independent of the bindings here. The question is about hardware - does this node, which represents PCI interface of the chip, has/uses the clocks? Best regards, Krzysztof
On July 30, 2024 12:18:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > On 30/07/2024 11:52, Arend Van Spriel wrote: >> On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >>> On 30/07/2024 08:37, Arend Van Spriel wrote: >>>> + Linus W >>>> >>>> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>>> >>>>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>>> external low power clock input. In DTS the clock as an optional choice in >>>>> the absence of an internal clock. >>>>> >>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>>> --- >>>>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>>> 1 file changed, 8 insertions(+) >>>>> >>>>> diff --git >>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> index 2c2093c77ec9a..a3607d55ef367 100644 >>>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>> @@ -122,6 +122,14 @@ properties: >>>>> NVRAM. This would normally be filled in by the bootloader from platform >>>>> configuration data. >>>>> >>>>> + clocks: >>>>> + items: >>>>> + - description: External Low Power Clock input (32.768KHz) >>>>> + >>>>> + clock-names: >>>>> + items: >>>>> + - const: lpo >>>>> + >>>> >>>> We still have an issue that this clock input is also present in the >>>> bindings specification broadcom-bluetooth.yaml (not in bluetooth >>>> subfolder). This clock is actually a chip resource. What happens if both >>>> are defined and both wifi and bt drivers try to enable this clock? Can this >>>> be expressed in yaml or can we only put a textual warning in the property >>>> descriptions? >>> >>> Just like all clocks, what would happen? It will be enabled. >> >> Oh, wow! Cool stuff. But seriously is it not a problem to have two entities >> controlling one and the same clock? Is this use-case taken into account by >> the clock framework? > > Yes, it is handled correctly. That's a basic use-case, handled by CCF > since some years (~12?). Anyway, whatever OS is doing (or not doing) > with the clocks is independent of the bindings here. The question is Agree. Probably the bindings would not be the place to document this if it would be an issue. > about hardware - does this node, which represents PCI interface of the > chip, has/uses the clocks. The schematics I found for the wifi module and the khadas edge platform show these are indeed wired to the chip. Regards, Arend > Best regards, > Krzysztof
Hi, On Tue, Jul 30, 2024 at 01:16:57PM GMT, Arend Van Spriel wrote: > On July 30, 2024 12:18:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > On 30/07/2024 11:52, Arend Van Spriel wrote: > > > On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > On 30/07/2024 08:37, Arend Van Spriel wrote: > > > > > + Linus W > > > > > > > > > > On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: > > > > > > > > > > > Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow > > > > > > external low power clock input. In DTS the clock as an optional choice in > > > > > > the absence of an internal clock. > > > > > > > > > > > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> > > > > > > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> > > > > > > --- > > > > > > .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ > > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > index 2c2093c77ec9a..a3607d55ef367 100644 > > > > > > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > @@ -122,6 +122,14 @@ properties: > > > > > > NVRAM. This would normally be filled in by the bootloader from platform > > > > > > configuration data. > > > > > > > > > > > > + clocks: > > > > > > + items: > > > > > > + - description: External Low Power Clock input (32.768KHz) > > > > > > + > > > > > > + clock-names: > > > > > > + items: > > > > > > + - const: lpo > > > > > > + > > > > > > > > > > We still have an issue that this clock input is also present in the > > > > > bindings specification broadcom-bluetooth.yaml (not in bluetooth > > > > > subfolder). This clock is actually a chip resource. What happens if both > > > > > are defined and both wifi and bt drivers try to enable this clock? Can this > > > > > be expressed in yaml or can we only put a textual warning in the property > > > > > descriptions? > > > > > > > > Just like all clocks, what would happen? It will be enabled. > > > > > > Oh, wow! Cool stuff. But seriously is it not a problem to have two entities > > > controlling one and the same clock? Is this use-case taken into account by > > > the clock framework? > > > > Yes, it is handled correctly. That's a basic use-case, handled by CCF > > since some years (~12?). Anyway, whatever OS is doing (or not doing) > > with the clocks is independent of the bindings here. The question is > > Agree. Probably the bindings would not be the place to document this if it > would be an issue. > > > about hardware - does this node, which represents PCI interface of the > > chip, has/uses the clocks. > > The schematics I found for the wifi module and the khadas edge platform show > these are indeed wired to the chip. I have a Rockchip RK3588 Evaluation Board on my desk, which uses the same WLAN AP6275P module. I think I already commented on a prior version of this series: The LPO clock is needed to make the PCIe device visible on the bus. That means this series only works if the clock has already been running. Otherwise the PCIe driver will never 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?). Greetings, -- Sebastian
On 7/30/2024 7:38 PM, Sebastian Reichel wrote: > Hi, > > On Tue, Jul 30, 2024 at 01:16:57PM GMT, Arend Van Spriel wrote: >> On July 30, 2024 12:18:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >>> On 30/07/2024 11:52, Arend Van Spriel wrote: >>>> On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> >>>>> On 30/07/2024 08:37, Arend Van Spriel wrote: >>>>>> + Linus W >>>>>> >>>>>> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>>>>> >>>>>>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>>>>> external low power clock input. In DTS the clock as an optional choice in >>>>>>> the absence of an internal clock. >>>>>>> >>>>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>>>>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>>>>> --- >>>>>>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>>>>> 1 file changed, 8 insertions(+) >>>>>>> >>>>>>> diff --git >>>>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> index 2c2093c77ec9a..a3607d55ef367 100644 >>>>>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> @@ -122,6 +122,14 @@ properties: >>>>>>> NVRAM. This would normally be filled in by the bootloader from platform >>>>>>> configuration data. >>>>>>> >>>>>>> + clocks: >>>>>>> + items: >>>>>>> + - description: External Low Power Clock input (32.768KHz) >>>>>>> + >>>>>>> + clock-names: >>>>>>> + items: >>>>>>> + - const: lpo >>>>>>> + >>>>>> >>>>>> We still have an issue that this clock input is also present in the >>>>>> bindings specification broadcom-bluetooth.yaml (not in bluetooth >>>>>> subfolder). This clock is actually a chip resource. What happens if both >>>>>> are defined and both wifi and bt drivers try to enable this clock? Can this >>>>>> be expressed in yaml or can we only put a textual warning in the property >>>>>> descriptions? >>>>> >>>>> Just like all clocks, what would happen? It will be enabled. >>>> >>>> Oh, wow! Cool stuff. But seriously is it not a problem to have two entities >>>> controlling one and the same clock? Is this use-case taken into account by >>>> the clock framework? >>> >>> Yes, it is handled correctly. That's a basic use-case, handled by CCF >>> since some years (~12?). Anyway, whatever OS is doing (or not doing) >>> with the clocks is independent of the bindings here. The question is >> >> Agree. Probably the bindings would not be the place to document this if it >> would be an issue. >> >>> about hardware - does this node, which represents PCI interface of the >>> chip, has/uses the clocks. >> >> The schematics I found for the wifi module and the khadas edge platform show >> these are indeed wired to the chip. > > I have a Rockchip RK3588 Evaluation Board on my desk, which uses the > same WLAN AP6275P module. I think I already commented on a prior > version of this series: The LPO clock is needed to make the PCIe > device visible on the bus. That means this series only works if the > clock has already been running. Otherwise the PCIe driver will never > 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. Regards, Arend
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
Hi, On Wed, Jul 31, 2024 at 02:57:37PM GMT, Arend van Spriel wrote: > On 7/30/2024 7:38 PM, Sebastian Reichel wrote: > > Hi, > > > > On Tue, Jul 30, 2024 at 01:16:57PM GMT, Arend Van Spriel wrote: > > > On July 30, 2024 12:18:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > On 30/07/2024 11:52, Arend Van Spriel wrote: > > > > > On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > > > > On 30/07/2024 08:37, Arend Van Spriel wrote: > > > > > > > + Linus W > > > > > > > > > > > > > > On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: > > > > > > > > > > > > > > > Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow > > > > > > > > external low power clock input. In DTS the clock as an optional choice in > > > > > > > > the absence of an internal clock. > > > > > > > > > > > > > > > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> > > > > > > > > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> > > > > > > > > --- > > > > > > > > .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ > > > > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > > > > > > > diff --git > > > > > > > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > index 2c2093c77ec9a..a3607d55ef367 100644 > > > > > > > > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > @@ -122,6 +122,14 @@ properties: > > > > > > > > NVRAM. This would normally be filled in by the bootloader from platform > > > > > > > > configuration data. > > > > > > > > > > > > > > > > + clocks: > > > > > > > > + items: > > > > > > > > + - description: External Low Power Clock input (32.768KHz) > > > > > > > > + > > > > > > > > + clock-names: > > > > > > > > + items: > > > > > > > > + - const: lpo > > > > > > > > + > > > > > > > > > > > > > > We still have an issue that this clock input is also present in the > > > > > > > bindings specification broadcom-bluetooth.yaml (not in bluetooth > > > > > > > subfolder). This clock is actually a chip resource. What happens if both > > > > > > > are defined and both wifi and bt drivers try to enable this clock? Can this > > > > > > > be expressed in yaml or can we only put a textual warning in the property > > > > > > > descriptions? > > > > > > > > > > > > Just like all clocks, what would happen? It will be enabled. > > > > > > > > > > Oh, wow! Cool stuff. But seriously is it not a problem to have two entities > > > > > controlling one and the same clock? Is this use-case taken into account by > > > > > the clock framework? > > > > > > > > Yes, it is handled correctly. That's a basic use-case, handled by CCF > > > > since some years (~12?). Anyway, whatever OS is doing (or not doing) > > > > with the clocks is independent of the bindings here. The question is > > > > > > Agree. Probably the bindings would not be the place to document this if it > > > would be an issue. > > > > > > > about hardware - does this node, which represents PCI interface of the > > > > chip, has/uses the clocks. > > > > > > The schematics I found for the wifi module and the khadas edge platform show > > > these are indeed wired to the chip. > > > > I have a Rockchip RK3588 Evaluation Board on my desk, which uses the > > same WLAN AP6275P module. I think I already commented on a prior > > version of this series: The LPO clock is needed to make the PCIe > > device visible on the bus. That means this series only works if the > > clock has already been running. Otherwise the PCIe driver will never > > 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. Well, first of all I can easily reproduce this on my RK3588 EVB1. I intentionally ignore any bluetooth bits to avoid cross-effects from bluetooth enabling any clocks / regulators / GPIOs and make sure the RTC output clock is disabled at boot time (i.e. boot once without any reference to the RTC clock and without 'clk_ignore_unused' kernel argument). When booting up like this the WLAN device is not visible in 'lspci' despite the WL_REG_ON GPIO being hogged. If I additionally hack the RTC output clock to be enabled the WLAN device becomes visible in 'lspci'. The datasheet fully explains this: https://www.lcsc.com/datasheet/lcsc_datasheet_2203281730_AMPAK-Tech-AP6275P_C2984107.pdf PDF Page 23/24 (20/21 in the footer) has the Host Interface Timing Diagram. WL_REG_ON should only be enabled after 2 cycles from LPO. That means with LPO being disabled WL_REG_ON cannot be enabled. I'm pretty sure WL_REG_ON means WLAN_REGULATOR_ON, so the logic is not powered. On page 27 (24 in the footer) there is also a PCIe Power-On Timing diagram, which shows that WL_REG_ON must be enabled before the PCIe refclk is enabled. So there is a specific power up sequence, which must be followed. Greetings, -- Sebastian
On July 31, 2024 3:54:52 PM Sebastian Reichel <sebastian.reichel@collabora.com> wrote: > Hi, > > On Wed, Jul 31, 2024 at 02:57:37PM GMT, Arend van Spriel wrote: >> On 7/30/2024 7:38 PM, Sebastian Reichel wrote: >>> Hi, >>> >>> On Tue, Jul 30, 2024 at 01:16:57PM GMT, Arend Van Spriel wrote: >>>> On July 30, 2024 12:18:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> >>>>> On 30/07/2024 11:52, Arend Van Spriel wrote: >>>>>> On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>>>> >>>>>>> On 30/07/2024 08:37, Arend Van Spriel wrote: >>>>>>> > + Linus W >>>>>>> > >>>>>>> > On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>>>>>> > >>>>>>> > > Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>>>>> > > external low power clock input. In DTS the clock as an optional choice in >>>>>>> > > the absence of an internal clock. >>>>>>> > > >>>>>>> > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>>>>> > > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>>>>> > > --- >>>>>>> > > .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>>>>> > > 1 file changed, 8 insertions(+) >>>>>>> > > >>>>>>> > > diff --git >>>>>>> > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> > > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> > > index 2c2093c77ec9a..a3607d55ef367 100644 >>>>>>> > > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>> > > @@ -122,6 +122,14 @@ properties: >>>>>>> > > NVRAM. This would normally be filled in by the bootloader from platform >>>>>>> > > configuration data. >>>>>>> > > >>>>>>> > > + clocks: >>>>>>> > > + items: >>>>>>> > > + - description: External Low Power Clock input (32.768KHz) >>>>>>> > > + >>>>>>> > > + clock-names: >>>>>>> > > + items: >>>>>>> > > + - const: lpo >>>>>>> > > + >>>>>>> > >>>>>>> > We still have an issue that this clock input is also present in the >>>>>>> > bindings specification broadcom-bluetooth.yaml (not in bluetooth >>>>>>> > subfolder). This clock is actually a chip resource. What happens if both >>>>>>> > are defined and both wifi and bt drivers try to enable this clock? Can this >>>>>>> > be expressed in yaml or can we only put a textual warning in the property >>>>>>> > descriptions? >>>>>>> >>>>>>> Just like all clocks, what would happen? It will be enabled. >>>>>> >>>>>> Oh, wow! Cool stuff. But seriously is it not a problem to have two entities >>>>>> controlling one and the same clock? Is this use-case taken into account by >>>>>> the clock framework? >>>>> >>>>> Yes, it is handled correctly. That's a basic use-case, handled by CCF >>>>> since some years (~12?). Anyway, whatever OS is doing (or not doing) >>>>> with the clocks is independent of the bindings here. The question is >>>> >>>> Agree. Probably the bindings would not be the place to document this if it >>>> would be an issue. >>>> >>>>> about hardware - does this node, which represents PCI interface of the >>>>> chip, has/uses the clocks. >>>> >>>> The schematics I found for the wifi module and the khadas edge platform show >>>> these are indeed wired to the chip. >>> >>> I have a Rockchip RK3588 Evaluation Board on my desk, which uses the >>> same WLAN AP6275P module. I think I already commented on a prior >>> version of this series: The LPO clock is needed to make the PCIe >>> device visible on the bus. That means this series only works if the >>> clock has already been running. Otherwise the PCIe driver will never >>> 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. > > Well, first of all I can easily reproduce this on my RK3588 EVB1. I > intentionally ignore any bluetooth bits to avoid cross-effects from > bluetooth enabling any clocks / regulators / GPIOs and make sure the > RTC output clock is disabled at boot time (i.e. boot once without > any reference to the RTC clock and without 'clk_ignore_unused' > kernel argument). When booting up like this the WLAN device is not > visible in 'lspci' despite the WL_REG_ON GPIO being hogged. If I > additionally hack the RTC output clock to be enabled the WLAN device > becomes visible in 'lspci'. > > The datasheet fully explains this: > > https://www.lcsc.com/datasheet/lcsc_datasheet_2203281730_AMPAK-Tech-AP6275P_C2984107.pdf > > PDF Page 23/24 (20/21 in the footer) has the Host Interface Timing > Diagram. WL_REG_ON should only be enabled after 2 cycles from LPO. > That means with LPO being disabled WL_REG_ON cannot be enabled. I'm > pretty sure WL_REG_ON means WLAN_REGULATOR_ON, so the logic is not > powered. On page 27 (24 in the footer) there is also a PCIe Power-On > Timing diagram, which shows that WL_REG_ON must be enabled before > the PCIe refclk is enabled. > > So there is a specific power up sequence, which must be followed. The chip also has an (less accurate) internal LPO so the 32khz sleep clock in the diagram does not have to be an external clock. Maybe Ampak bootstrapped the chip to disable the internal clock. Dunno. What Andy needed back then to get firmware running was a change in the nvram file to force using the internal LPO, but the device was already visible on the PCIe bus. Regards, Arend
Hi, On Wed, Jul 31, 2024 at 05:12:43PM GMT, Arend Van Spriel wrote: > On July 31, 2024 3:54:52 PM Sebastian Reichel > <sebastian.reichel@collabora.com> wrote: > > On Wed, Jul 31, 2024 at 02:57:37PM GMT, Arend van Spriel wrote: > > > On 7/30/2024 7:38 PM, Sebastian Reichel wrote: > > > > On Tue, Jul 30, 2024 at 01:16:57PM GMT, Arend Van Spriel wrote: > > > > > On July 30, 2024 12:18:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > > > > On 30/07/2024 11:52, Arend Van Spriel wrote: > > > > > > > On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > > > > > > > > On 30/07/2024 08:37, Arend Van Spriel wrote: > > > > > > > > > + Linus W > > > > > > > > > > > > > > > > > > On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: > > > > > > > > > > > > > > > > > > > Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow > > > > > > > > > > external low power clock input. In DTS the clock as an optional choice in > > > > > > > > > > the absence of an internal clock. > > > > > > > > > > > > > > > > > > > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> > > > > > > > > > > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> > > > > > > > > > > --- > > > > > > > > > > .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ > > > > > > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > > > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > > > index 2c2093c77ec9a..a3607d55ef367 100644 > > > > > > > > > > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > > > > > > > @@ -122,6 +122,14 @@ properties: > > > > > > > > > > NVRAM. This would normally be filled in by the bootloader from platform > > > > > > > > > > configuration data. > > > > > > > > > > > > > > > > > > > > + clocks: > > > > > > > > > > + items: > > > > > > > > > > + - description: External Low Power Clock input (32.768KHz) > > > > > > > > > > + > > > > > > > > > > + clock-names: > > > > > > > > > > + items: > > > > > > > > > > + - const: lpo > > > > > > > > > > + > > > > > > > > > > > > > > > > > > We still have an issue that this clock input is also present in the > > > > > > > > > bindings specification broadcom-bluetooth.yaml (not in bluetooth > > > > > > > > > subfolder). This clock is actually a chip resource. What happens if both > > > > > > > > > are defined and both wifi and bt drivers try to enable this clock? Can this > > > > > > > > > be expressed in yaml or can we only put a textual warning in the property > > > > > > > > > descriptions? > > > > > > > > > > > > > > > > Just like all clocks, what would happen? It will be enabled. > > > > > > > > > > > > > > Oh, wow! Cool stuff. But seriously is it not a problem to have two entities > > > > > > > controlling one and the same clock? Is this use-case taken into account by > > > > > > > the clock framework? > > > > > > > > > > > > Yes, it is handled correctly. That's a basic use-case, handled by CCF > > > > > > since some years (~12?). Anyway, whatever OS is doing (or not doing) > > > > > > with the clocks is independent of the bindings here. The question is > > > > > > > > > > Agree. Probably the bindings would not be the place to document this if it > > > > > would be an issue. > > > > > > > > > > > about hardware - does this node, which represents PCI interface of the > > > > > > chip, has/uses the clocks. > > > > > > > > > > The schematics I found for the wifi module and the khadas edge platform show > > > > > these are indeed wired to the chip. > > > > > > > > I have a Rockchip RK3588 Evaluation Board on my desk, which uses the > > > > same WLAN AP6275P module. I think I already commented on a prior > > > > version of this series: The LPO clock is needed to make the PCIe > > > > device visible on the bus. That means this series only works if the > > > > clock has already been running. Otherwise the PCIe driver will never > > > > 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. > > > > Well, first of all I can easily reproduce this on my RK3588 EVB1. I > > intentionally ignore any bluetooth bits to avoid cross-effects from > > bluetooth enabling any clocks / regulators / GPIOs and make sure the > > RTC output clock is disabled at boot time (i.e. boot once without > > any reference to the RTC clock and without 'clk_ignore_unused' > > kernel argument). When booting up like this the WLAN device is not > > visible in 'lspci' despite the WL_REG_ON GPIO being hogged. If I > > additionally hack the RTC output clock to be enabled the WLAN device > > becomes visible in 'lspci'. > > > > The datasheet fully explains this: > > > > https://www.lcsc.com/datasheet/lcsc_datasheet_2203281730_AMPAK-Tech-AP6275P_C2984107.pdf > > > > PDF Page 23/24 (20/21 in the footer) has the Host Interface Timing > > Diagram. WL_REG_ON should only be enabled after 2 cycles from LPO. > > That means with LPO being disabled WL_REG_ON cannot be enabled. I'm > > pretty sure WL_REG_ON means WLAN_REGULATOR_ON, so the logic is not > > powered. On page 27 (24 in the footer) there is also a PCIe Power-On > > Timing diagram, which shows that WL_REG_ON must be enabled before > > the PCIe refclk is enabled. > > > > So there is a specific power up sequence, which must be followed. > > The chip also has an (less accurate) internal LPO so the 32khz sleep clock > in the diagram does not have to be an external clock. Maybe Ampak > bootstrapped the chip to disable the internal clock. Dunno. > > What Andy needed back then to get firmware running was a change in the nvram > file to force using the internal LPO, but the device was already visible on > the PCIe bus. mh, I just tested again and I can no longer reproduce the LPO requirement for PCIe detection. Maybe it was something else all along (I did most of my tests quite some time ago). Sorry for the noise. -- Sebastian
On 7/31/2024 7:50 PM, Sebastian Reichel wrote: > Hi, > > On Wed, Jul 31, 2024 at 05:12:43PM GMT, Arend Van Spriel wrote: >> On July 31, 2024 3:54:52 PM Sebastian Reichel >> <sebastian.reichel@collabora.com> wrote: >>> On Wed, Jul 31, 2024 at 02:57:37PM GMT, Arend van Spriel wrote: >>>> On 7/30/2024 7:38 PM, Sebastian Reichel wrote: >>>>> On Tue, Jul 30, 2024 at 01:16:57PM GMT, Arend Van Spriel wrote: >>>>>> On July 30, 2024 12:18:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>>>> >>>>>>> On 30/07/2024 11:52, Arend Van Spriel wrote: >>>>>>>> On July 30, 2024 11:01:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>>>>>> >>>>>>>>> On 30/07/2024 08:37, Arend Van Spriel wrote: >>>>>>>>>> + Linus W >>>>>>>>>> >>>>>>>>>> On July 30, 2024 5:31:15 AM Jacobe Zang <jacobe.zang@wesion.com> wrote: >>>>>>>>>> >>>>>>>>>>> Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow >>>>>>>>>>> external low power clock input. In DTS the clock as an optional choice in >>>>>>>>>>> the absence of an internal clock. >>>>>>>>>>> >>>>>>>>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >>>>>>>>>>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> >>>>>>>>>>> --- >>>>>>>>>>> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 ++++++++ >>>>>>>>>>> 1 file changed, 8 insertions(+) >>>>>>>>>>> >>>>>>>>>>> diff --git >>>>>>>>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>>>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>>>>>> index 2c2093c77ec9a..a3607d55ef367 100644 >>>>>>>>>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>>>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml >>>>>>>>>>> @@ -122,6 +122,14 @@ properties: >>>>>>>>>>> NVRAM. This would normally be filled in by the bootloader from platform >>>>>>>>>>> configuration data. >>>>>>>>>>> >>>>>>>>>>> + clocks: >>>>>>>>>>> + items: >>>>>>>>>>> + - description: External Low Power Clock input (32.768KHz) >>>>>>>>>>> + >>>>>>>>>>> + clock-names: >>>>>>>>>>> + items: >>>>>>>>>>> + - const: lpo >>>>>>>>>>> + >>>>>>>>>> >>>>>>>>>> We still have an issue that this clock input is also present in the >>>>>>>>>> bindings specification broadcom-bluetooth.yaml (not in bluetooth >>>>>>>>>> subfolder). This clock is actually a chip resource. What happens if both >>>>>>>>>> are defined and both wifi and bt drivers try to enable this clock? Can this >>>>>>>>>> be expressed in yaml or can we only put a textual warning in the property >>>>>>>>>> descriptions? >>>>>>>>> >>>>>>>>> Just like all clocks, what would happen? It will be enabled. >>>>>>>> >>>>>>>> Oh, wow! Cool stuff. But seriously is it not a problem to have two entities >>>>>>>> controlling one and the same clock? Is this use-case taken into account by >>>>>>>> the clock framework? >>>>>>> >>>>>>> Yes, it is handled correctly. That's a basic use-case, handled by CCF >>>>>>> since some years (~12?). Anyway, whatever OS is doing (or not doing) >>>>>>> with the clocks is independent of the bindings here. The question is >>>>>> >>>>>> Agree. Probably the bindings would not be the place to document this if it >>>>>> would be an issue. >>>>>> >>>>>>> about hardware - does this node, which represents PCI interface of the >>>>>>> chip, has/uses the clocks. >>>>>> >>>>>> The schematics I found for the wifi module and the khadas edge platform show >>>>>> these are indeed wired to the chip. >>>>> >>>>> I have a Rockchip RK3588 Evaluation Board on my desk, which uses the >>>>> same WLAN AP6275P module. I think I already commented on a prior >>>>> version of this series: The LPO clock is needed to make the PCIe >>>>> device visible on the bus. That means this series only works if the >>>>> clock has already been running. Otherwise the PCIe driver will never >>>>> 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. >>> >>> Well, first of all I can easily reproduce this on my RK3588 EVB1. I >>> intentionally ignore any bluetooth bits to avoid cross-effects from >>> bluetooth enabling any clocks / regulators / GPIOs and make sure the >>> RTC output clock is disabled at boot time (i.e. boot once without >>> any reference to the RTC clock and without 'clk_ignore_unused' >>> kernel argument). When booting up like this the WLAN device is not >>> visible in 'lspci' despite the WL_REG_ON GPIO being hogged. If I >>> additionally hack the RTC output clock to be enabled the WLAN device >>> becomes visible in 'lspci'. >>> >>> The datasheet fully explains this: >>> >>> https://www.lcsc.com/datasheet/lcsc_datasheet_2203281730_AMPAK-Tech-AP6275P_C2984107.pdf >>> >>> PDF Page 23/24 (20/21 in the footer) has the Host Interface Timing >>> Diagram. WL_REG_ON should only be enabled after 2 cycles from LPO. >>> That means with LPO being disabled WL_REG_ON cannot be enabled. I'm >>> pretty sure WL_REG_ON means WLAN_REGULATOR_ON, so the logic is not >>> powered. On page 27 (24 in the footer) there is also a PCIe Power-On >>> Timing diagram, which shows that WL_REG_ON must be enabled before >>> the PCIe refclk is enabled. >>> >>> So there is a specific power up sequence, which must be followed. >> >> The chip also has an (less accurate) internal LPO so the 32khz sleep clock >> in the diagram does not have to be an external clock. Maybe Ampak >> bootstrapped the chip to disable the internal clock. Dunno. >> >> What Andy needed back then to get firmware running was a change in the nvram >> file to force using the internal LPO, but the device was already visible on >> the PCIe bus. > > mh, I just tested again and I can no longer reproduce the LPO > requirement for PCIe detection. Maybe it was something else all > along (I did most of my tests quite some time ago). > Sorry for the noise. Hi Sebastian, Thanks for letting it know. Regards, Arend
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml index 2c2093c77ec9a..a3607d55ef367 100644 --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml @@ -122,6 +122,14 @@ properties: NVRAM. This would normally be filled in by the bootloader from platform configuration data. + clocks: + items: + - description: External Low Power Clock input (32.768KHz) + + clock-names: + items: + - const: lpo + required: - compatible - reg