Re: [PATCH] Kirin-PCIe: Add kirin pcie msi feature.
On Tue, May 8, 2018 at 12:03 AM, Yao Chen wrote:
> This patch adds kirin pcie msi feature.
>
> Signed-off-by: Yao Chen
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
> drivers/pci/dwc/pcie-kirin.c | 38
> +++
> 2 files changed, 40 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index ec3eb8e..4ef684f 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -872,6 +872,8 @@
> 0x0 0x0200>;
> num-lanes = <1>;
> #interrupt-cells = <1>;
> + interrupts = <0 283 4>;
> + interrupts-names = "msi";
Possible typo? Should be interrupt-names = "msi";
> interrupt-map-mask = <0xf800 0 0 7>;
> interrupt-map = <0x0 0 0 1
> &gic GIC_SPI 282
> IRQ_TYPE_LEVEL_HIGH>,
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> index d2970a0..2319c9c 100644
> --- a/drivers/pci/dwc/pcie-kirin.c
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port
> *pp)
> return 0;
> }
>
> +static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
> +{
> + struct pcie_port *pp = arg;
> +
> + return dw_handle_msi_irq(pp);
> +}
> +
> +static void kirin_pcie_msi_init(struct pcie_port *pp)
> +{
> + dw_pcie_msi_init(pp);
> +}
> +
> +static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
> +{
> + if (IS_ENABLED(CONFIG_PCI_MSI))
> + kirin_pcie_msi_init(pp);
> +}
> +
> static int kirin_pcie_host_init(struct pcie_port *pp)
> {
> kirin_pcie_establish_link(pp);
> + kirin_pcie_enable_interrupts(pp);
>
> return 0;
> }
> @@ -448,6 +467,25 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
> static int __init kirin_add_pcie_port(struct dw_pcie *pci,
> struct platform_device *pdev)
> {
> + int ret;
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> + if (!pci->pp.msi_irq) {
> + dev_err(&pdev->dev, "failed to get msi irq\n");
> + return -ENODEV;
> + }
> + ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
> + kirin_pcie_msi_irq_handler,
> + IRQF_SHARED | IRQF_NO_THREAD,
> + "kirin_pcie_msi", &pci->pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to request msi irq\n");
> + return ret;
> + }
> + }
> +
> + pci->pp.root_bus_nr = -1;
> pci->pp.ops = &kirin_pcie_host_ops;
>
> return dw_pcie_host_init(&pci->pp);
> --
> 1.9.1
>
Re: [PATCH] of: Overlay manager
On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand wrote:
> On 09/08/16 13:35, dimitr...@google.com wrote:
>> From e14eb45fa5a93c1bff8a6dfe7b6756e4ad72c579 Mon Sep 17 00:00:00 2001
>> From: Dmitry Shmidt
>> Date: Wed, 24 Aug 2016 13:25:52 -0700
>> Subject: [PATCH] of: Overlay manager
>>
>> Overlay manager processes DT entries on demand.
>> It is chosen by CONFIG_OF_OVERLAY_MGR option.
>> These entries can be chosen from kernel command line:
>> overlay_mgr.overlay_dt_entry=hardware_cfg_0
>> DT contains main overlay_mng entry with all possible
>> HW config setups. And then kernel command line option
>> will allow to choose between them.
>>
>> Kernel DT entry:
>> overlay_mgr {
>> compatible = "linux,overlay_manager";
>> hardware_cfg_0 {
>> overlay@0 {
>> fragment@0 {
>> __overlay__ {
>> };
>> };
>> };
>> overlay@1 {
>> fragment@0 {
>> __overlay__ {
>> };
>> };
>> };
>> };
>> };
>
> What problem(s) are you trying to solve with this?
Currently the Linux kernel doesn't provide a way for boot time
selection of different possible board configurations, when the board
peripherals are specified via Device Tree.
Thus, this patch provides a driver which takes a boot option to
apply pre-defined device-tree overlay fragments on bootup. This
allows a single kernel/devicetree to be able to support a number of
different configurations by only changing a boot argument.
> What is the use case?
It is usually useful for development board when you can use
different peripherals. For example you want to use special
LCD panel. Using it will go on account of other stuff like GPIOs,
so you don't want it all the time. And it is not convenient to
apply new patches and to recompile the kernel. And this code
allows to choose LCD panel configuration from command line.
> -Frank
>
>>
>> Signed-off-by: Dmitry Shmidt
>> Tested-by: John Stultz
>> Acked-by: John Stultz
>> ---
>> .../devicetree/bindings/of/overlay_mgr.txt | 32
>> drivers/of/Kconfig | 10 +++
>> drivers/of/Makefile| 1 +
>> drivers/of/overlay_mgr.c | 90
>> ++
>> 4 files changed, 133 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/of/overlay_mgr.txt
>> create mode 100644 drivers/of/overlay_mgr.c
>>
>> diff --git a/Documentation/devicetree/bindings/of/overlay_mgr.txt
>> b/Documentation/devicetree/bindings/of/overlay_mgr.txt
>> new file mode 100644
>> index 000..5f3ce4c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/of/overlay_mgr.txt
>> @@ -0,0 +1,32 @@
>> +overlay_mgr
>> +
>> +Required properties:
>> +- compatible: "linux,overlay_manager";
>> +
>> +Optional properties:
>> +- starts from the word "hardware": hardware_cfg_0
>> +
>> +These properties can be chosen from kernel command line:
>> +overlay_mgr.overlay_dt_entry=hardware_cfg_0
>> +DT contains main overlay_mng entry with all possible
>> +HW config setups. And then kernel command line option
>> +will allow to choose between them.
>> +
>> +Example:
>> +overlay_mgr {
>> +compatible = "linux,overlay_manager";
>> +hardware_cfg_0 {
>> +overlay@0 {
>> +fragment@0 {
>> +__overlay__ {
>> +};
>> +};
>> +};
>> +overlay@1 {
>> +fragment@0 {
>> +__overlay__ {
>> +};
>> +};
>> +};
>> +};
>> +};
>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>> index e2a4841..e3eb06d 100644
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -112,4 +112,14 @@ config OF_OVERLAY
>>While this option is selected automatically when needed, you can
>>enable it manually to improve device tree unit test coverage.
>>
>> +config OF_OVERLAY_MGR
>> +bool "Enable Overlay manager"
>> +default n
>> +depends on OF_OVERLAY
>> +help
>> + Enables Ov
Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact
On Fri, Aug 26, 2016 at 5:51 AM, Tejun Heo wrote: > Hello, John. > > On Thu, Aug 25, 2016 at 07:14:07PM -0700, John Stultz wrote: >> Hey! Good news. This patch along with Peter's locking changes pushes >> the latencies down to an apparently acceptable level! > > Ah, that's good to hear. Please feel free to ping me if you guys > wanna talk about cgroup usage in android. Thanks a lot for all your help resolving this issue! > Thanks! > > -- > tejun
Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes
On Wed, Jul 13, 2016 at 1:52 PM, Paul E. McKenney
wrote:
> On Wed, Jul 13, 2016 at 10:26:57PM +0200, Peter Zijlstra wrote:
>> On Wed, Jul 13, 2016 at 04:18:23PM -0400, Tejun Heo wrote:
>> > Hello, John.
>> >
>> > On Wed, Jul 13, 2016 at 01:13:11PM -0700, John Stultz wrote:
>> > > On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo wrote:
>> > > > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote:
>> > > >> One interesting thing to try would be replacing it with a regular
>> > > >> non-percpu rwsem and see how it behaves. That should easily tell us
>> > > >> whether this is from actual contention or artifacts from percpu_rwsem
>> > > >> implementation.
>> > > >
>> > > > So, something like the following. Can you please see whether this
>> > > > makes any difference?
>> > >
>> > > Yea. So this brings it down for me closer to what we're seeing with
>> > > the Dmitry's patch reverting the two problematic commits, usually
>> > > 10-50us with one early spike at 18ms.
>> >
>> > So, it's a percpu rwsem issue then. I haven't really followed the
>> > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected
>> > on down write expected with the current implementation of
>> > percpu_rwsem?
>>
>> There is a synchronize_sched() in there, so sorta. That thing is heavily
>> geared towards readers, as is the only 'sane' choice for global locks.
>
> Then one diagnostic step to take would be to replace that
> synchronize_sched() with synchronize_sched_expedited(), and see if that
> gets rid of the delays.
>
> Not a particularly real-time-friendly fix, but certainly a good check
> on our various assumptions.
All delays <200 us, but one that is 3 ms.
> Thanx, Paul
>
>
>
> diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> index be922c9f3d37..211acddc7e21 100644
> --- a/kernel/rcu/sync.c
> +++ b/kernel/rcu/sync.c
> @@ -38,19 +38,19 @@ static const struct {
> #endif
> } gp_ops[] = {
> [RCU_SYNC] = {
> - .sync = synchronize_rcu,
> + .sync = synchronize_rcu_expedited,
> .call = call_rcu,
> .wait = rcu_barrier,
> __INIT_HELD(rcu_read_lock_held)
> },
> [RCU_SCHED_SYNC] = {
> - .sync = synchronize_sched,
> + .sync = synchronize_sched_expedited,
> .call = call_rcu_sched,
> .wait = rcu_barrier_sched,
> __INIT_HELD(rcu_read_lock_sched_held)
> },
> [RCU_BH_SYNC] = {
> - .sync = synchronize_rcu_bh,
> + .sync = synchronize_rcu_bh_expedited,
> .call = call_rcu_bh,
> .wait = rcu_barrier_bh,
> __INIT_HELD(rcu_read_lock_bh_held)
>
Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes
On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo wrote:
> On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote:
>> One interesting thing to try would be replacing it with a regular
>> non-percpu rwsem and see how it behaves. That should easily tell us
>> whether this is from actual contention or artifacts from percpu_rwsem
>> implementation.
>
> So, something like the following. Can you please see whether this
> makes any difference?
It is making difference. We need to conduct more tests, but it
looks much better. I see only one 18.5 ms delay. Most of time it
is <200 us delay.
> Thanks.
>
> diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
> index 5b17de6..bc1e4d8 100644
> --- a/include/linux/cgroup-defs.h
> +++ b/include/linux/cgroup-defs.h
> @@ -14,7 +14,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
>
> #ifdef CONFIG_CGROUPS
> @@ -518,7 +518,7 @@ struct cgroup_subsys {
> unsigned int depends_on;
> };
>
> -extern struct percpu_rw_semaphore cgroup_threadgroup_rwsem;
> +extern struct rw_semaphore cgroup_threadgroup_rwsem;
>
> /**
> * cgroup_threadgroup_change_begin - threadgroup exclusion for cgroups
> @@ -529,7 +529,7 @@ extern struct percpu_rw_semaphore
> cgroup_threadgroup_rwsem;
> */
> static inline void cgroup_threadgroup_change_begin(struct task_struct *tsk)
> {
> - percpu_down_read(&cgroup_threadgroup_rwsem);
> + down_read(&cgroup_threadgroup_rwsem);
> }
>
> /**
> @@ -541,7 +541,7 @@ static inline void cgroup_threadgroup_change_begin(struct
> task_struct *tsk)
> */
> static inline void cgroup_threadgroup_change_end(struct task_struct *tsk)
> {
> - percpu_up_read(&cgroup_threadgroup_rwsem);
> + up_read(&cgroup_threadgroup_rwsem);
> }
>
> #else /* CONFIG_CGROUPS */
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 86cb5c6..ed9c142 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -113,7 +113,7 @@ static DEFINE_SPINLOCK(cgroup_file_kn_lock);
> */
> static DEFINE_SPINLOCK(release_agent_path_lock);
>
> -struct percpu_rw_semaphore cgroup_threadgroup_rwsem;
> +DECLARE_RWSEM(cgroup_threadgroup_rwsem);
>
> #define cgroup_assert_mutex_or_rcu_locked()\
> RCU_LOCKDEP_WARN(!rcu_read_lock_held() && \
> @@ -2899,7 +2899,7 @@ static ssize_t __cgroup_procs_write(struct
> kernfs_open_file *of, char *buf,
> if (!cgrp)
> return -ENODEV;
>
> - percpu_down_write(&cgroup_threadgroup_rwsem);
> + down_write(&cgroup_threadgroup_rwsem);
> rcu_read_lock();
> if (pid) {
> tsk = find_task_by_vpid(pid);
> @@ -2937,7 +2937,7 @@ static ssize_t __cgroup_procs_write(struct
> kernfs_open_file *of, char *buf,
> out_unlock_rcu:
> rcu_read_unlock();
> out_unlock_threadgroup:
> - percpu_up_write(&cgroup_threadgroup_rwsem);
> + up_write(&cgroup_threadgroup_rwsem);
> for_each_subsys(ss, ssid)
> if (ss->post_attach)
> ss->post_attach();
> @@ -3077,7 +3077,7 @@ static int cgroup_update_dfl_csses(struct cgroup *cgrp)
>
> lockdep_assert_held(&cgroup_mutex);
>
> - percpu_down_write(&cgroup_threadgroup_rwsem);
> + down_write(&cgroup_threadgroup_rwsem);
>
> /* look up all csses currently attached to @cgrp's subtree */
> spin_lock_bh(&css_set_lock);
> @@ -3112,7 +3112,7 @@ static int cgroup_update_dfl_csses(struct cgroup *cgrp)
> ret = cgroup_taskset_migrate(&tset, cgrp->root);
> out_finish:
> cgroup_migrate_finish(&preloaded_csets);
> - percpu_up_write(&cgroup_threadgroup_rwsem);
> + up_write(&cgroup_threadgroup_rwsem);
> return ret;
> }
>
> @@ -5601,7 +5601,7 @@ int __init cgroup_init(void)
> int ssid;
>
> BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16);
> - BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem));
> + //BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem));
> BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files));
> BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files));
>
Re: building and using modules on arm64 hikey board
On Tue, May 31, 2016 at 1:58 PM, Ard Biesheuvel wrote: > On 31 May 2016 at 22:24, Dmitry Shmidt wrote: >> On Mon, May 30, 2016 at 4:30 AM, Ard Biesheuvel >> wrote: >>> This is likely caused by the fact that the Android AArch64 toolchain uses >>> -fpic by default. Could you try adding -fno-pic to the CFLAGS? >> >> Actually Arend is using 4.4, and we need to pull your fix, Ard: >> >> commit 80a2d83376001f6a1993f2e925670ab0e4cdb76d >> Author: Ard Biesheuvel >> Date: Tue Jan 5 10:18:52 2016 +0100 >> >> arm64: module: avoid undefined shift behavior in reloc_data() >> > > OK, that was going to be my next question to Arend, i.e., to check > whether he has all the recent fixes we did for the module loader. > > But I'd also like to understand how we ended up with PREL32 > relocations in the first place, since those are quite unusual in > object code generated from generic C source code when using the > non-pic small model, which is normally GCC's default. Are there any > other code generation defaults for the Android AArch64 GCC toolchain > that you are aware of? I am still trying to get an answer from toolchain supporters, but it looks like compiler decides by itself what type of branch to use, and it is using PREL32 in case it knows for sure that branch will succeed. I suspect is it done to reduce code size. >>>> On 30 mei 2016, at 12:21, Arend Van Spriel >>>> wrote: >>>> >>>> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP >>>> image for it (see [1]). For development I would like to use >>>> CONFIG_MODULES. However, when I try to insmod the build module I get: >>>> >>>> [ 287.903653] module cfg80211: overflow in relocation type 261 val >>>> ffbffc006530 >>>> >>>> Looking AArch64 ELF documentation [2], section 4.6.5, it has: >>>> code|name|operation |overflow check | >>>> 261 |R_AARCH64_PREL32|S + A - P |-2^31 <= X < 2^32| >>>> >>>> So basically the highest 32 bits should all be one and so ffbf is >>>> invalid. From what I could find searching internet it could be an issue >>>> with linker options so I build kernel and modules with V=1. Here the >>>> linker invocation for them: >>>> >>>> + aarch64-linux-android-ld -EL -p --no-undefined -X --build-id -o vmlinux \ >>>> -T ./arch/arm64/kernel/vmlinux.lds arch/arm64/kernel/head.o >>>> init/built-in.o \ >>>> --start-group usr/built-in.o arch/arm64/kernel/built-in.o >>>> arch/arm64/mm/built-in.o \ >>>> arch/arm64/net/built-in.o arch/arm64/kvm/built-in.o >>>> arch/arm64/crypto/built-in.o \ >>>> ./drivers/firmware/efi/libstub/lib.a kernel/built-in.o certs/built-in.o >>>> mm/built-in.o \ >>>> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o >>>> block/built-in.o \ >>>> arch/arm64/lib/lib.a lib/lib.a arch/arm64/lib/built-in.o lib/built-in.o >>>> drivers/built-in.o \ >>>> sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o >>>> --end-group .tmp_kallsyms2.o >>>> >>>> aarch64-linux-android-ld -EL -r -T ./scripts/module-common.lds >>>> --build-id \ >>>> -o net/wireless/cfg80211.ko net/wireless/cfg80211.o >>>> net/wireless/cfg80211.mod.o >>>> >>>> Attached are vmlinux.lds and module-common.lds. I also tried taking >>>> upstream arch/arm64/kernel/module.lds in hikey-linaro tree. If someone >>>> can give a hint or educated guess at what to try it would be appreciated. >>>> >>>> Regards, >>>> Arend >>>> >>>> [1] https://source.android.com/source/devices.html#building-kernel >>>> [2] >>>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf >>>> >>>> >>> >>> ___ >>> linux-arm-kernel mailing list >>> linux-arm-ker...@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: building and using modules on arm64 hikey board
On Mon, May 30, 2016 at 4:30 AM, Ard Biesheuvel wrote: > This is likely caused by the fact that the Android AArch64 toolchain uses > -fpic by default. Could you try adding -fno-pic to the CFLAGS? Actually Arend is using 4.4, and we need to pull your fix, Ard: commit 80a2d83376001f6a1993f2e925670ab0e4cdb76d Author: Ard Biesheuvel Date: Tue Jan 5 10:18:52 2016 +0100 arm64: module: avoid undefined shift behavior in reloc_data() >> On 30 mei 2016, at 12:21, Arend Van Spriel >> wrote: >> >> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP >> image for it (see [1]). For development I would like to use >> CONFIG_MODULES. However, when I try to insmod the build module I get: >> >> [ 287.903653] module cfg80211: overflow in relocation type 261 val >> ffbffc006530 >> >> Looking AArch64 ELF documentation [2], section 4.6.5, it has: >> code|name|operation |overflow check | >> 261 |R_AARCH64_PREL32|S + A - P |-2^31 <= X < 2^32| >> >> So basically the highest 32 bits should all be one and so ffbf is >> invalid. From what I could find searching internet it could be an issue >> with linker options so I build kernel and modules with V=1. Here the >> linker invocation for them: >> >> + aarch64-linux-android-ld -EL -p --no-undefined -X --build-id -o vmlinux \ >> -T ./arch/arm64/kernel/vmlinux.lds arch/arm64/kernel/head.o >> init/built-in.o \ >> --start-group usr/built-in.o arch/arm64/kernel/built-in.o >> arch/arm64/mm/built-in.o \ >> arch/arm64/net/built-in.o arch/arm64/kvm/built-in.o >> arch/arm64/crypto/built-in.o \ >> ./drivers/firmware/efi/libstub/lib.a kernel/built-in.o certs/built-in.o >> mm/built-in.o \ >> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o >> block/built-in.o \ >> arch/arm64/lib/lib.a lib/lib.a arch/arm64/lib/built-in.o lib/built-in.o >> drivers/built-in.o \ >> sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o >> --end-group .tmp_kallsyms2.o >> >> aarch64-linux-android-ld -EL -r -T ./scripts/module-common.lds >> --build-id \ >> -o net/wireless/cfg80211.ko net/wireless/cfg80211.o >> net/wireless/cfg80211.mod.o >> >> Attached are vmlinux.lds and module-common.lds. I also tried taking >> upstream arch/arm64/kernel/module.lds in hikey-linaro tree. If someone >> can give a hint or educated guess at what to try it would be appreciated. >> >> Regards, >> Arend >> >> [1] https://source.android.com/source/devices.html#building-kernel >> [2] >> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf >> >> > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: Broadcom 43340 module on iMX6DL
On Thu, Apr 23, 2015 at 11:10 AM, John Tobias wrote: > Hello Guys, > > I am trying to use the bcmdhd wifi driver 43340 module on iMX6DL > processor using kernel Freescale GA (3.10.53). > > I am having an issue with the sdio registration. I would like to know > if anyone here had the same issue and how did you solve it?. I would be careful with terminology - this error has nothing to do with sdio registration. Moreover, you found wlan sdio device: mmc0: new high speed SDIO card at address 0001 The problem is that after loading FW (you probably skipped this line in log) it is not responding. There are several reasons for this. 1) You didn't set up properly IRQ line. There are two ways: OOB interrupt and SDIO interrupt. I don't know how it is set in HW on your board. You may try to use polling as a test Something like replace uint dhd_poll = FALSE; uint dhd_intr = TRUE; to uint dhd_poll = TRUE; uint dhd_intr = FALSE; But I am not sure about your source base and if it is working at all these days. 2) Your FW is wrong and it is not responding 3) Something else... :) > > > Entry: wifi_add_dev > Entry: wifi_add_dev > Entry: wifi_probe > wifi_probe: calling wifi_set_power on > Entry: wifi_set_power > wifi_set_power = 1 > wifi_set_carddetect = 1 > mmc0: queuing unknown CIS tuple 0x80 (7 bytes) > mmc0: queuing unknown CIS tuple 0x80 (6 bytes) > mmc0: queuing unknown CIS tuple 0x91 (3 bytes) > mmc0: new high speed SDIO card at address 0001 > > Dongle Host Driver, version 1.88.45 (r) > Compiled in drivers/net/wireless/bcmdhd on Apr 23 2015 at 00:40:05 > F1 signature OK, socitype:0x1 chip:0xa94c rev:0x2 pkg:0x0 > DHD: dongle ram size is set to 524288(orig 524288) at 0x0 > wl_create_event_handler(): thread:wl_event_handler:3ba started > CFG80211-ERROR) wl_event_handler : tsk Enter, tsk = 0x96741444 > dhd_attach(): thread:dhd_watchdog_thread:3bb started > dhd_attach(): thread:dhd_dpc:3bc started > dhd_attach(): thread:dhd_rxf:3bd started > dhd_attach(): thread:dhd_sysioc:3be started > wifi_get_mac_addr > dhdsdio_write_vars: Download, Upload and compare of NVRAM succeeded. > > > Times out here... > dhd_module_init: sdio_register_driver timeout or error > > dhd_bus_init: enable 0x06, ready 0x02 (waited 3006383us) > dhd_bus_start failed bus is not ready > dhdsdio_probe: dhd_bus_start failed > dhd_detach(): thread:dhd_sysioc:3be terminated OK > dhd_detach(): thread:dhd_watchdog_thread:3bb terminated OK > dhd_dpc_thread: Unexpected up_cnt 0 > dhd_detach(): thread:dhd_dpc:3bc terminated OK > dhd_detach(): thread:dhd_rxf:3bd terminated OK > CFG80211-ERROR) wl_event_handler : was terminated > wl_destroy_event_handler(): thread:wl_event_handler:3ba terminated OK > dhd_osl_detach: MEMORY LEAK 156 bytes > ## wifi_remove > Entry: wifi_set_power > wifi_set_power = 0 > navdy_wifi_power: 0 > wifi_set_carddetect = 0 > insmod: init_module '/system/lib/modules/bcmdhd.ko' failed (No such device) > # mmc0: card 0001 removed > > > Note: I ran the command below to load the driver: > insmod /system/lib/modules/bcmdhd.ko > firmware_path=/system/vendor/firmware/brcmfmac43340-sdio.bin > nvram_path=/system/vendor/firmware/bcmdhd.cal > > > Regards, > > John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
