[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<TYZPR03MB70011B5F10967EAD64FE499780D32@TYZPR03MB7001.apcprd03.prod.outlook.com>
Date: Mon, 1 Jul 2024 10:57:36 +0000
From: Jacobe Zang <jacobe.zang@...ion.com>
To: Arend Van Spriel <arend.vanspriel@...adcom.com>, Stefan Wahren
<wahrenst@....net>, "wens@...nel.org" <wens@...nel.org>
CC: "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
<krzk+dt@...nel.org>, "heiko@...ech.de" <heiko@...ech.de>, "kvalo@...nel.org"
<kvalo@...nel.org>, "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org"
<kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
"conor+dt@...nel.org" <conor+dt@...nel.org>, "efectn@...tonmail.com"
<efectn@...tonmail.com>, "dsimic@...jaro.org" <dsimic@...jaro.org>,
"jagan@...eble.ai" <jagan@...eble.ai>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-rockchip@...ts.infradead.org"
<linux-rockchip@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "arend@...adcom.com" <arend@...adcom.com>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "megi@....cz"
<megi@....cz>, "duoming@....edu.cn" <duoming@....edu.cn>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>, "minipli@...ecurity.net"
<minipli@...ecurity.net>, "brcm80211@...ts.linux.dev"
<brcm80211@...ts.linux.dev>, "brcm80211-dev-list.pdl@...adcom.com"
<brcm80211-dev-list.pdl@...adcom.com>, Nick Xie <nick@...das.com>
Subject: Re: [PATCH v3 4/5] wifi: brcmfmac: Add optional lpo clock enable
support
>> Am 30.06.24 um 11:15 schrieb Chen-Yu Tsai:
>>> On Sun, Jun 30, 2024 at 5:10 PM Jacobe Zang <jacobe.zang@...ion.com> wrote:
>>>> Hi Stefan,
>>>>
>>>>>> WiFi modules often require 32kHz clock to function. Add support to
>>>>>> enable the clock to PCIe driver.
>>>>> the low power clock is independent from the host interface like PCIe. So
>>>>> the clock handling should move to the common code. Sorry, not i cannot
>>>>> give a good suggestion, what's the best place for this.
>>>> I think the clock is used by the PCIe device so enable it in this file.
>>>> Also I checked
>>>> use of clock which in spi[0] or sdio[0] device was enabled similarly to this.
>>>>
>>>> [0]
>>>> https://lore.kernel.org/all/20210806081229.721731-4-claudiu.beznea@microchip.com/
>>> You're looking at the wrong driver. For brcmfmac, the lpo clock is toggled
>>> by the MMC pwrseq code. And for the Bluetooth side (where it really matters)
>>> for UARTs, it is in drivers/bluetooth/hci_bcm.c. and documented in the
>>> binding Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
As ChenYu said, hci_bcm.c has handled for bt clock. But it seemed that clock has
never handled in brcmfmac wifi driver. So I wonder does everyone all enable the
clock in BT node not wifi?
>> Thanks for clarifying. So this change handles the PCIe case without
>> bluetooth. For USB the clock control doesn't make sense.
>>
>> Sorry for the noise
>
> So someone could end up with both wifi and bt LPO clock defined in DTS
> file. Not sure if that can be expressed and validated in device tree, but
> at the least there should be a fair warning in both binding files that
> there can be only one!
>
> The LPO clock matters to the chip. It is not specific to the BT part. The
I also think that it is necessary to handle the clock in wifi driver, though.
> clock is important for the power-up cycle. The timing difference WL_REG_ON
> and BT_REG_ON is expressed in LPO clock cycles.
---
Best Regards
Jacobe
Powered by blists - more mailing lists