Re: [PATCH] ath10k: do not enforce interrupt trigger type
On 5/14/22 12:05 AM, Steev Klimaszewski wrote: On 5/13/22 10:57 AM, Kalle Valo wrote: Krzysztof Kozlowski writes: Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge rising - but instead rely on Devicetree to configure it. All Qualcomm DTSI with WCN3990 define the interrupt type as level high, so the mismatch between DTSI and driver causes rebind issues: $ echo 1880.wifi > /sys/bus/platform/drivers/ath10k_snoc/unbind $ echo 1880.wifi > /sys/bus/platform/drivers/ath10k_snoc/bind [ 44.763114] irq: type mismatch, failed to map hwirq-446 for interrupt-controller@17a0! [ 44.763130] ath10k_snoc 1880.wifi: error -ENXIO: IRQ index 0 not found [ 44.763140] ath10k_snoc 1880.wifi: failed to initialize resource: -6 So you tested on WCN3990? On what firmware version? I can add the Tested-on tag if you provide that. Hello Krzystof, Kalle, I have seen this issue as well on a Lenovo Flex 5G, which has a WCN3990: wcn3990 hw1.0 target 0x0008 chip_id 0x sub : kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790 htt-ver 3.86 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1 With this patch applied, I no longer see the error message in the commit message, when I unbind/bind when wifi stops working. Tested-by: Steev Klimaszewski -- Steev Apologies for the second email - I've tested this now on both the Lenovo Flex 5G, as I have seen the issue on it as well, as well as on the Lenovo Yoga C630, where I did not but I did have issues with attempting to rebind the device, prior to this patch. Firmware version for the Flex 5G is qmi chip_id 0x30224 chip_family 0x4001 board_id 0xff soc_id 0x4006 qmi fw_version 0x32080009 fw_build_timestamp 2020-11-16 14:44 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.0.c8-9-QCAHLSWSC8180XMTPLZ-1 Firmware version on the Yoga C630 is qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40030001 qmi fw_version 0x2009856b fw_build_timestamp 2018-07-19 12:28 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: do not enforce interrupt trigger type
On 5/13/22 10:57 AM, Kalle Valo wrote: Krzysztof Kozlowski writes: Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge rising - but instead rely on Devicetree to configure it. All Qualcomm DTSI with WCN3990 define the interrupt type as level high, so the mismatch between DTSI and driver causes rebind issues: $ echo 1880.wifi > /sys/bus/platform/drivers/ath10k_snoc/unbind $ echo 1880.wifi > /sys/bus/platform/drivers/ath10k_snoc/bind [ 44.763114] irq: type mismatch, failed to map hwirq-446 for interrupt-controller@17a0! [ 44.763130] ath10k_snoc 1880.wifi: error -ENXIO: IRQ index 0 not found [ 44.763140] ath10k_snoc 1880.wifi: failed to initialize resource: -6 So you tested on WCN3990? On what firmware version? I can add the Tested-on tag if you provide that. Hello Krzystof, Kalle, I have seen this issue as well on a Lenovo Flex 5G, which has a WCN3990: wcn3990 hw1.0 target 0x0008 chip_id 0x sub : kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790 htt-ver 3.86 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1 With this patch applied, I no longer see the error message in the commit message, when I unbind/bind when wifi stops working. Tested-by: Steev Klimaszewski -- Steev ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC v2 00/13] create power sequencing subsystem
On 8/29/21 8:12 AM, Dmitry Baryshkov wrote: > This is the second RFC on the 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. > > To ease migration to pwrseq and to provide compatibility with older > device trees, while keeping drivers simple, this iteration of RFC > introduces pwrseq fallback support: pwrseq driver can register fallback > providers. If another device driver requests pwrseq instance and none > was declared, the pwrseq fallback code would go through the list of > fallback providers and if the match is found, driver would return a > crafted pwrseq instance. For now this mechanism is limited to the OF > device matching, but it can be extended further to use any combination > of device IDs. > > 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. > > This patchset being an RFC tries to demonstrate the approach, design and > usage of the pwrseq subsystem. Following issues are present in the RFC > at this moment but will be fixed later if the overall approach would be > viewed as acceptable: > > - No documentation >While the code tries to be self-documenting proper documentation >would be required. > > - Minimal device tree bindings changes >There are no proper updates for the DT bindings (thus neither Rob >Herring nor devicetree are included in the To/Cc lists). The dt >schema changes would be a part of v1. > > - 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 bus scan depending on the proper >device structure in the device tree. > > 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. > I tested this here, on the Lenovo Yoga C630, after creating a patch to do basically the same thing as the db845c does. One thing I noticed, if PWRSEQ=y and the rest are =m, there is a build error. I suppose once the full set is posted and not RFC, I can send the patch for that. One question I have, if you don't mind, in patch 11, you add a second channel to qca power sequencer. I've added that here, but in the c630's dts, "vreg_l23a_3p3: ldo23" is empty, so I added the same numbers in for the regulator, and I'm wondering how to test that it's actually working correctly? -- steev ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: Don't always treat modem stop events as crashes
h10k_snoc_free_irq(ar);
> ath10k_snoc_release_resource(ar);
> + ath10k_modem_deinit(ar);
> ath10k_qmi_deinit(ar);
> ath10k_core_destroy(ar);
>
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.h
> b/drivers/net/wireless/ath/ath10k/snoc.h
> index 5095d1893681..d986edc772f8 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.h
> +++ b/drivers/net/wireless/ath/ath10k/snoc.h
> @@ -6,6 +6,8 @@
> #ifndef _SNOC_H_
> #define _SNOC_H_
>
> +#include
> +
> #include "hw.h"
> #include "ce.h"
> #include "qmi.h"
> @@ -75,6 +77,8 @@ struct ath10k_snoc {
> struct clk_bulk_data *clks;
> size_t num_clks;
> struct ath10k_qmi *qmi;
> + struct notifier_block nb;
> + void *notifier;
> unsigned long flags;
> bool xo_cal_supported;
> u32 xo_cal_data;
>
> base-commit: 7d2a07b769330c34b4deabeed939325c77a7ec2f
I was also seeing this on the Lenovo Yoga C630, so I pulled the patch in
to test here and after testing 20 reboots, I have not seen the message once.
Tested-By: Steev Klimaszewski
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
