Linux wireless drivers development
 help / color / mirror / Atom feed
* ath11k: question about memory-region
@ 2025-09-03  8:31 Alexander Wilhelm
  2025-11-03  5:19 ` Vasanthakumar Thiagarajan
  0 siblings, 1 reply; 2+ messages in thread
From: Alexander Wilhelm @ 2025-09-03  8:31 UTC (permalink / raw)
  To: Jeff Johnson; +Cc: ath11k, linux-wireless

Hello devs,

I have a question regarding the use of memory-region on a platform without CMA
support. Since CMA is not available, the driver allocates many smaller memory
chunks instead.

To evaluate an alternative, I defined a node within reserved-memory in the
device tree. However, this led to a firmware crash:

    ath11k_pci 0001:01:00.0: BAR 0: assigned [mem 0xc00000000-0xc001fffff 64bit]
    ath11k_pci 0001:01:00.0: boot pci_mem 0x10b272d0
    ath11k_pci 0001:01:00.0: boot pci probe 17cb:1104 17cb:1104
    ath11k_pci 0001:01:00.0: pci request one msi vector
    ath11k_pci 0001:01:00.0: MSI vectors: 1
    ath11k_pci 0001:01:00.0: pci msi base data is 0
    ath11k_pci 0001:01:00.0: qcn9074 hw1.0
    ath11k_pci 0001:01:00.0: FW memory mode: 0
    ath11k_pci 0001:01:00.0: boot failed to load firmware-2.bin: -2
    ath11k_pci 0001:01:00.0: boot using fw api 1
    ath11k_pci 0001:01:00.0: pci msi assignment MHI num_vectors 3 user_base_data 0 base_vector 0
    ath11k_pci 0001:01:00.0: pci num_vectors 3 base_vector 0
    ath11k_pci 0001:01:00.0: pci msi assignment CE num_vectors 1 user_base_data 0 base_vector 0
    ath11k_pci 0001:01:00.0: pci msi assignment DP num_vectors 1 user_base_data 0 base_vector 0
    ath11k_pci 0001:01:00.0: pci irq 18 group 0
    ath11k_pci 0001:01:00.0: pci irq 18 group 1
    ath11k_pci 0001:01:00.0: pci irq 18 group 2
    ath11k_pci 0001:01:00.0: pci irq 18 group 3
    ath11k_pci 0001:01:00.0: pci irq 18 group 4
    ath11k_pci 0001:01:00.0: pci irq 18 group 5
    ath11k_pci 0001:01:00.0: pci irq 18 group 6
    ath11k_pci 0001:01:00.0: pci irq 18 group 7
    ath11k_pci 0001:01:00.0: pci after request_irq msi_ep_base_data 0
    ath11k_pci 0001:01:00.0: pci ltssm 0x111
    ath11k_pci 0001:01:00.0: pci pcie_hot_rst 0x11
    ath11k_pci 0001:01:00.0: pci pcie_q6_cookie_addr 0x0
    ath11k_pci 0001:01:00.0: pci wlaon_warm_sw_entry 0x0
    ath11k_pci 0001:01:00.0: pci wlaon_warm_sw_entry 0x0
    ath11k_pci 0001:01:00.0: pci soc reset cause 0
    ath11k_pci 0001:01:00.0: pci mhistatus 0xff04
    ath11k_pci 0001:01:00.0: pci link_ctl 0x0000 L0s 0 L1 0
    ath11k_pci 0001:01:00.0: pci pci reg 0x3164 instance_id 0x11 read val 0x11
    ath11k_pci 0001:01:00.0: boot notify status reason UNKNOWN
    ath11k_pci 0001:01:00.0: boot notify status reason MHI_CB_EE_MISSION_MODE
    ath11k_pci 0001:01:00.0: qmi wifi fw qmi service connected
    ath11k_pci 0001:01:00.0: qmi indication register request
    ath11k_pci 0001:01:00.0: qmi host cap request
    ath11k_pci 0001:01:00.0: qmi firmware request memory request
    ath11k_pci 0001:01:00.0: qmi mem seg type 1 size 36700160
    ath11k_pci 0001:01:00.0: qmi mem seg type 4 size 3784704
    ath11k_pci 0001:01:00.0: qmi mem seg type 3 size 1048576
    ath11k_pci 0001:01:00.0: qmi mem seg type 9 size 8388608
    ath11k_pci 0001:01:00.0: qmi mem seg type 10 size 8192
    ath11k_pci 0001:01:00.0: qmi ignore invalid mem req type 3
    ath11k_pci 0001:01:00.0: qmi ignore invalid mem req type 9
    ath11k_pci 0001:01:00.0: qmi ignore invalid mem req type 10
    ath11k_pci 0001:01:00.0: qmi req mem_seg[0] 0x0000000040000000 36700160 1
    ath11k_pci 0001:01:00.0: qmi req mem_seg[1] 0x0000000000000000 3784704 4
    ath11k_pci 0001:01:00.0: qmi respond memory request delayed 0
    ath11k_pci 0001:01:00.0: boot notify status reason MHI_CB_EE_RDDM
    ath11k_pci 0001:01:00.0: firmware crashed: MHI_CB_EE_RDDM
    ath11k_pci 0001:01:00.0: ignore reset dev flags 0x2000
    ath11k_pci 0001:01:00.0: failed to wait qmi memory request: -110
    ath11k_pci 0001:01:00.0: qmi failed to respond fw mem req: -110

Why is `CALDB_MEM_REGION_TYPE` always set to physical address 0? Could the crash
be caused by platform-specific constraints and not the firmware/driver? Does it
make sense at all to use reserved-memory instead of small memory chunks, for
example in terms of performance?


Best regards,
Alexander Wilhelm

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ath11k: question about memory-region
  2025-09-03  8:31 ath11k: question about memory-region Alexander Wilhelm
@ 2025-11-03  5:19 ` Vasanthakumar Thiagarajan
  0 siblings, 0 replies; 2+ messages in thread
From: Vasanthakumar Thiagarajan @ 2025-11-03  5:19 UTC (permalink / raw)
  To: Alexander Wilhelm, Jeff Johnson; +Cc: ath11k, linux-wireless



On 9/3/2025 2:01 PM, Alexander Wilhelm wrote:
> Hello devs,
> 
> I have a question regarding the use of memory-region on a platform without CMA
> support. Since CMA is not available, the driver allocates many smaller memory
> chunks instead.
> 
> To evaluate an alternative, I defined a node within reserved-memory in the
> device tree. However, this led to a firmware crash:
> 
>      ath11k_pci 0001:01:00.0: BAR 0: assigned [mem 0xc00000000-0xc001fffff 64bit]
>      ath11k_pci 0001:01:00.0: boot pci_mem 0x10b272d0
>      ath11k_pci 0001:01:00.0: boot pci probe 17cb:1104 17cb:1104
>      ath11k_pci 0001:01:00.0: pci request one msi vector
>      ath11k_pci 0001:01:00.0: MSI vectors: 1
>      ath11k_pci 0001:01:00.0: pci msi base data is 0
>      ath11k_pci 0001:01:00.0: qcn9074 hw1.0
>      ath11k_pci 0001:01:00.0: FW memory mode: 0
>      ath11k_pci 0001:01:00.0: boot failed to load firmware-2.bin: -2
>      ath11k_pci 0001:01:00.0: boot using fw api 1
>      ath11k_pci 0001:01:00.0: pci msi assignment MHI num_vectors 3 user_base_data 0 base_vector 0
>      ath11k_pci 0001:01:00.0: pci num_vectors 3 base_vector 0
>      ath11k_pci 0001:01:00.0: pci msi assignment CE num_vectors 1 user_base_data 0 base_vector 0
>      ath11k_pci 0001:01:00.0: pci msi assignment DP num_vectors 1 user_base_data 0 base_vector 0
>      ath11k_pci 0001:01:00.0: pci irq 18 group 0
>      ath11k_pci 0001:01:00.0: pci irq 18 group 1
>      ath11k_pci 0001:01:00.0: pci irq 18 group 2
>      ath11k_pci 0001:01:00.0: pci irq 18 group 3
>      ath11k_pci 0001:01:00.0: pci irq 18 group 4
>      ath11k_pci 0001:01:00.0: pci irq 18 group 5
>      ath11k_pci 0001:01:00.0: pci irq 18 group 6
>      ath11k_pci 0001:01:00.0: pci irq 18 group 7
>      ath11k_pci 0001:01:00.0: pci after request_irq msi_ep_base_data 0
>      ath11k_pci 0001:01:00.0: pci ltssm 0x111
>      ath11k_pci 0001:01:00.0: pci pcie_hot_rst 0x11
>      ath11k_pci 0001:01:00.0: pci pcie_q6_cookie_addr 0x0
>      ath11k_pci 0001:01:00.0: pci wlaon_warm_sw_entry 0x0
>      ath11k_pci 0001:01:00.0: pci wlaon_warm_sw_entry 0x0
>      ath11k_pci 0001:01:00.0: pci soc reset cause 0
>      ath11k_pci 0001:01:00.0: pci mhistatus 0xff04
>      ath11k_pci 0001:01:00.0: pci link_ctl 0x0000 L0s 0 L1 0
>      ath11k_pci 0001:01:00.0: pci pci reg 0x3164 instance_id 0x11 read val 0x11
>      ath11k_pci 0001:01:00.0: boot notify status reason UNKNOWN
>      ath11k_pci 0001:01:00.0: boot notify status reason MHI_CB_EE_MISSION_MODE
>      ath11k_pci 0001:01:00.0: qmi wifi fw qmi service connected
>      ath11k_pci 0001:01:00.0: qmi indication register request
>      ath11k_pci 0001:01:00.0: qmi host cap request
>      ath11k_pci 0001:01:00.0: qmi firmware request memory request
>      ath11k_pci 0001:01:00.0: qmi mem seg type 1 size 36700160
>      ath11k_pci 0001:01:00.0: qmi mem seg type 4 size 3784704
>      ath11k_pci 0001:01:00.0: qmi mem seg type 3 size 1048576
>      ath11k_pci 0001:01:00.0: qmi mem seg type 9 size 8388608
>      ath11k_pci 0001:01:00.0: qmi mem seg type 10 size 8192
>      ath11k_pci 0001:01:00.0: qmi ignore invalid mem req type 3
>      ath11k_pci 0001:01:00.0: qmi ignore invalid mem req type 9
>      ath11k_pci 0001:01:00.0: qmi ignore invalid mem req type 10
>      ath11k_pci 0001:01:00.0: qmi req mem_seg[0] 0x0000000040000000 36700160 1
>      ath11k_pci 0001:01:00.0: qmi req mem_seg[1] 0x0000000000000000 3784704 4
>      ath11k_pci 0001:01:00.0: qmi respond memory request delayed 0
>      ath11k_pci 0001:01:00.0: boot notify status reason MHI_CB_EE_RDDM
>      ath11k_pci 0001:01:00.0: firmware crashed: MHI_CB_EE_RDDM
>      ath11k_pci 0001:01:00.0: ignore reset dev flags 0x2000
>      ath11k_pci 0001:01:00.0: failed to wait qmi memory request: -110
>      ath11k_pci 0001:01:00.0: qmi failed to respond fw mem req: -110
> 
> Why is `CALDB_MEM_REGION_TYPE` always set to physical address 0?

Coldboot cal is disabled for qcn9074.

> Could the crash be caused by platform-specific constraints and not the firmware/driver?

Hard to say. At least from WLAN side there is no known issues when using reserved-memory. 
Can you share your reserved memory node?

> Does it make sense at all to use reserved-memory instead of small memory chunks, for
> example in terms of performance?

There will not be any visible performance differences between reserved-memory and
small memory chunks.

Vasanth

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-11-03  5:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-03  8:31 ath11k: question about memory-region Alexander Wilhelm
2025-11-03  5:19 ` Vasanthakumar Thiagarajan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox