| Message ID | 20211006035407.1147909-1-dmitry.baryshkov@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | create power sequencing subsystem | expand |
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > This is a proposed power sequencer subsystem. This is a > generification of the MMC pwrseq code. The subsystem tries to abstract > the idea of complex power-up/power-down/reset of the devices. > > The primary set of devices that promted me to create this patchset is > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > or serial + SDIO interfaces (older generations) or on serial+PCIe (newer > generations). Instead of older and newer, it would be more unstandable to mention specific chips. For example I have no clue what you mean with older generation.
Hi Dmitry, On 06/10/2021 04:53, Dmitry Baryshkov wrote: > This is a proposed power sequencer subsystem. This is a > generification of the MMC pwrseq code. The subsystem tries to abstract > the idea of complex power-up/power-down/reset of the devices. > > The primary set of devices that promted me to create this patchset is > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > or serial + SDIO interfaces (older generations) or on serial+PCIe (newer > generations). They require a set of external voltage regulators to be > powered on and (some of them) have separate WiFi and Bluetooth enable > GPIOs. > > The major drawback for now is the lack of proper PCIe integration > At this moment support for PCIe is hacked up to be able to test the > PCIe part of qca6390. Proper PCIe support would require automatically > powering up the devices before the scan basing on the proper device > structure in the device tree. This two last patches are noted as WIP and > are included into the patchset for the purpose of testing WiFi on newer > chips (like qca6390/qca6391). > > Changes since RFC v2: > - Add documentation for the pwrseq code. Document data structures, > macros and exported functions. > - Export of_pwrseq_xlate_onecell() > - Add separate pwrseq_set_drvdata() function to follow the typical API > design > - Remove pwrseq_get_optional()/devm_pwrseq_get_optional() > - Moved code to handle old mmc-pwrseq binding to the MMC patch > - Split of_pwrseq_xlate_onecell() support to a separate patch > > Changes since RFC v1: > - Provider pwrseq fallback support > - Implement fallback support in pwrseq_qca. > - Mmove susclk handling to pwrseq_qca. > - Significantly simplify hci_qca.c changes, by dropping all legacy > code. Now hci_qca uses only pwrseq calls to power up/down bluetooth > parts of the chip. > > > Tested-by: Caleb Connolly <caleb.connolly@linaro.org> [Tested on the OnePlus 6]
Hi Dmitry, On Wed Oct 6, 2021 at 5:53 AM CEST, Dmitry Baryshkov wrote: > This is a proposed power sequencer subsystem. This is a > generification of the MMC pwrseq code. The subsystem tries to abstract > the idea of complex power-up/power-down/reset of the devices. > > The primary set of devices that promted me to create this patchset is > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > or serial + SDIO interfaces (older generations) or on serial+PCIe (newer > generations). They require a set of external voltage regulators to be > powered on and (some of them) have separate WiFi and Bluetooth enable > GPIOs. > > The major drawback for now is the lack of proper PCIe integration > At this moment support for PCIe is hacked up to be able to test the > PCIe part of qca6390. Proper PCIe support would require automatically > powering up the devices before the scan basing on the proper device > structure in the device tree. This two last patches are noted as WIP and > are included into the patchset for the purpose of testing WiFi on newer > chips (like qca6390/qca6391). What's the status of this series? With this I have gotten Bluetooth to somewhat work on sm7225-fairphone-fp4, which is using WCN3990/WCN3988. Is there another solution with a different patch series that could make it work also? The latest I could find regarding some new Bluetooth thing is the following email from June 2022, but nothing seems to have happened since then. https://lore.kernel.org/linux-arm-msm/SJ0PR02MB7135746D204F13550E9BAE77F8B29@SJ0PR02MB7135.namprd02.prod.outlook.com/ Regards Luca > > Changes since RFC v2: > - Add documentation for the pwrseq code. Document data structures, > macros and exported functions. > - Export of_pwrseq_xlate_onecell() > - Add separate pwrseq_set_drvdata() function to follow the typical API > design > - Remove pwrseq_get_optional()/devm_pwrseq_get_optional() > - Moved code to handle old mmc-pwrseq binding to the MMC patch > - Split of_pwrseq_xlate_onecell() support to a separate patch > > Changes since RFC v1: > - Provider pwrseq fallback support > - Implement fallback support in pwrseq_qca. > - Mmove susclk handling to pwrseq_qca. > - Significantly simplify hci_qca.c changes, by dropping all legacy > code. Now hci_qca uses only pwrseq calls to power up/down bluetooth > parts of the chip.
Hi Dmitry, Do you still plan to refresh this series? I know there have been multiple attempts to get something similar landed in the past 10 year or so. Your series didn't seem to get much pushback from maintainers, might be worth sending a refresh :) Thanks Matthias On Wed, Oct 06, 2021 at 06:53:52AM +0300, Dmitry Baryshkov wrote: > This is a proposed power sequencer subsystem. This is a > generification of the MMC pwrseq code. The subsystem tries to abstract > the idea of complex power-up/power-down/reset of the devices. > > The primary set of devices that promted me to create this patchset is > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > or serial + SDIO interfaces (older generations) or on serial+PCIe (newer > generations). They require a set of external voltage regulators to be > powered on and (some of them) have separate WiFi and Bluetooth enable > GPIOs. > > The major drawback for now is the lack of proper PCIe integration > At this moment support for PCIe is hacked up to be able to test the > PCIe part of qca6390. Proper PCIe support would require automatically > powering up the devices before the scan basing on the proper device > structure in the device tree. This two last patches are noted as WIP and > are included into the patchset for the purpose of testing WiFi on newer > chips (like qca6390/qca6391). > > Changes since RFC v2: > - Add documentation for the pwrseq code. Document data structures, > macros and exported functions. > - Export of_pwrseq_xlate_onecell() > - Add separate pwrseq_set_drvdata() function to follow the typical API > design > - Remove pwrseq_get_optional()/devm_pwrseq_get_optional() > - Moved code to handle old mmc-pwrseq binding to the MMC patch > - Split of_pwrseq_xlate_onecell() support to a separate patch > > Changes since RFC v1: > - Provider pwrseq fallback support > - Implement fallback support in pwrseq_qca. > - Mmove susclk handling to pwrseq_qca. > - Significantly simplify hci_qca.c changes, by dropping all legacy > code. Now hci_qca uses only pwrseq calls to power up/down bluetooth > parts of the chip. > > > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k
Ho, On Thu, 13 Oct 2022 at 22:50, Matthias Kaehlcke <mka@chromium.org> wrote: > Do you still plan to refresh this series? > > I know there have been multiple attempts to get something similar > landed in the past 10 year or so. Your series didn't seem to get > much pushback from maintainers, might be worth sending a refresh :) Yes, I hope to return to it eventually. I just had no time for it lately. > On Wed, Oct 06, 2021 at 06:53:52AM +0300, Dmitry Baryshkov wrote: > > This is a proposed power sequencer subsystem. This is a > > generification of the MMC pwrseq code. The subsystem tries to abstract > > the idea of complex power-up/power-down/reset of the devices. > > > > The primary set of devices that promted me to create this patchset is > > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > > or serial + SDIO interfaces (older generations) or on serial+PCIe (newer > > generations). They require a set of external voltage regulators to be > > powered on and (some of them) have separate WiFi and Bluetooth enable > > GPIOs. > > > > The major drawback for now is the lack of proper PCIe integration > > At this moment support for PCIe is hacked up to be able to test the > > PCIe part of qca6390. Proper PCIe support would require automatically > > powering up the devices before the scan basing on the proper device > > structure in the device tree. This two last patches are noted as WIP and > > are included into the patchset for the purpose of testing WiFi on newer > > chips (like qca6390/qca6391). > > > > Changes since RFC v2: > > - Add documentation for the pwrseq code. Document data structures, > > macros and exported functions. > > - Export of_pwrseq_xlate_onecell() > > - Add separate pwrseq_set_drvdata() function to follow the typical API > > design > > - Remove pwrseq_get_optional()/devm_pwrseq_get_optional() > > - Moved code to handle old mmc-pwrseq binding to the MMC patch > > - Split of_pwrseq_xlate_onecell() support to a separate patch > > > > Changes since RFC v1: > > - Provider pwrseq fallback support > > - Implement fallback support in pwrseq_qca. > > - Mmove susclk handling to pwrseq_qca. > > - Significantly simplify hci_qca.c changes, by dropping all legacy > > code. Now hci_qca uses only pwrseq calls to power up/down bluetooth > > parts of the chip. > > > > > > > > > > _______________________________________________ > > ath10k mailing list > > ath10k@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/ath10k
Hi, sorry for being late to the party. Am Mittwoch, 19. Oktober 2022, 08:03:22 CET schrieb Dmitry Baryshkov: > Ho, > > On Thu, 13 Oct 2022 at 22:50, Matthias Kaehlcke <mka@chromium.org> wrote: > > Do you still plan to refresh this series? > > > > I know there have been multiple attempts to get something similar > > landed in the past 10 year or so. Your series didn't seem to get > > much pushback from maintainers, might be worth sending a refresh :) > > Yes, I hope to return to it eventually. I just had no time for it lately. I just found this thread while searching for power sequencing devices in Linux. From what I understand this is transforming the existing mmc pwrseq drivers into generic ones. What is the intention of this new subsystem? What is it supposed to address? In my case I have an LTE module attached via USB, but in order to use it I need to perform several steps: 1. apply power supply 2. Issue a reset pulse(!), the length actually defines whether its a reset or poweroff/on 3a. wait for a GPIO to toggle 3b. wait a minimum time 4a. device will enumerate on USB 4b. device can be access using UART This is something required to actually see/detect the device in the first place, thus it cannot be part of the device driver side. Is this something pwrseq is supposed to address? Best regards, Alexander > > On Wed, Oct 06, 2021 at 06:53:52AM +0300, Dmitry Baryshkov wrote: > > > This is a proposed power sequencer subsystem. This is a > > > generification of the MMC pwrseq code. The subsystem tries to abstract > > > the idea of complex power-up/power-down/reset of the devices. > > > > > > The primary set of devices that promted me to create this patchset is > > > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > > > or serial + SDIO interfaces (older generations) or on serial+PCIe (newer > > > generations). They require a set of external voltage regulators to be > > > powered on and (some of them) have separate WiFi and Bluetooth enable > > > GPIOs. > > > > > > The major drawback for now is the lack of proper PCIe integration > > > At this moment support for PCIe is hacked up to be able to test the > > > PCIe part of qca6390. Proper PCIe support would require automatically > > > powering up the devices before the scan basing on the proper device > > > structure in the device tree. This two last patches are noted as WIP and > > > are included into the patchset for the purpose of testing WiFi on newer > > > chips (like qca6390/qca6391). > > > > > > Changes since RFC v2: > > > - Add documentation for the pwrseq code. Document data structures, > > > > > > macros and exported functions. > > > > > > - Export of_pwrseq_xlate_onecell() > > > - Add separate pwrseq_set_drvdata() function to follow the typical API > > > > > > design > > > > > > - Remove pwrseq_get_optional()/devm_pwrseq_get_optional() > > > - Moved code to handle old mmc-pwrseq binding to the MMC patch > > > - Split of_pwrseq_xlate_onecell() support to a separate patch > > > > > > Changes since RFC v1: > > > - Provider pwrseq fallback support > > > - Implement fallback support in pwrseq_qca. > > > - Mmove susclk handling to pwrseq_qca. > > > - Significantly simplify hci_qca.c changes, by dropping all legacy > > > > > > code. Now hci_qca uses only pwrseq calls to power up/down bluetooth > > > parts of the chip. > > > > > > _______________________________________________ > > > ath10k mailing list > > > ath10k@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/ath10k
On Wed, 1 Mar 2023 at 09:17, Alexander Stein <alexander.stein@ew.tq-group.com> wrote: > > Hi, > > sorry for being late to the party. > > Am Mittwoch, 19. Oktober 2022, 08:03:22 CET schrieb Dmitry Baryshkov: > > Ho, > > > > On Thu, 13 Oct 2022 at 22:50, Matthias Kaehlcke <mka@chromium.org> wrote: > > > Do you still plan to refresh this series? > > > > > > I know there have been multiple attempts to get something similar > > > landed in the past 10 year or so. Your series didn't seem to get > > > much pushback from maintainers, might be worth sending a refresh :) > > > > Yes, I hope to return to it eventually. I just had no time for it lately. > > I just found this thread while searching for power sequencing devices in > Linux. From what I understand this is transforming the existing mmc pwrseq > drivers into generic ones. What is the intention of this new subsystem? What > is it supposed to address? > In my case I have an LTE module attached via USB, but in order to use it I > need to perform several steps: > 1. apply power supply > 2. Issue a reset pulse(!), the length actually defines whether its a reset or > poweroff/on > 3a. wait for a GPIO to toggle > 3b. wait a minimum time > 4a. device will enumerate on USB > 4b. device can be access using UART > > This is something required to actually see/detect the device in the first > place, thus it cannot be part of the device driver side. > Is this something pwrseq is supposed to address? Yes, this is one of those typical use-cases for discoverable buses that we need to add support for, in one way or the other. > > Best regards, > Alexander [...] Kind regards Uffe