gk7205v500: build the CMA allocator into osal

[widgetii]

mmz_allocator=cma could not work on the gk7205v500 family. The kbuild
left mmz/cma_allocator.o out of the osal module. So on a CMA kernel
osal.c's call to cma_allocator_setopt() went unresolved, and the module
would not load:

open_osal: Unknown symbol cma_allocator_setopt (err 0)

The file had also never been ported from the HiSilicon kernel's API:

• It called get_cma_zone(). The xmedia kernel's drivers/xmedia/cma
  exports xmedia_get_cma_zone().
• It kept a private copy of struct cma_zone. It now includes
  <linux/xmedia_cma.h>, so the layout cannot drift from the kernel's.
• It defined max_malloc_size, which allocator.c already defines. That
  was a link error once the file was actually built.

It is now built only when the kernel has CONFIG_CMA, so a non-CMA build
is unchanged. The printk of the zone casts its gfp_t/phys_addr_t
arguments to match the %lx format.

Verified on a GK7205V510 (128 MiB DDR) running openipc/linux 4.9.37 with
CMA + DMA_CMA, booted with mem=128M mmz_allocator=cma
mmz=anonymous,0,0x42000000,96M:

cma: Reserved 96 MiB at 0x42000000
Media Memory Zone Manager
cmz zone gfp 0x0, phys 0x42000000, nbytes 0x6000000
osal 1.0 init success!

All 28 modules load, majestic starts the SDK, and CmaFree falls by the
~15 MB the media stack allocates from the zone. Linux keeps the rest of
the DDR: MemTotal is 125840 kB, against 28612 kB with mem=32M and the
xmedia carve-out.

Testing notes

• This repo's CI builds against firmware master, whose gk7205v500 kernel has no CMA yet. CI therefore checks that the non-CMA build is unchanged; it doesn't compile cma_allocator.o.
• The CMA build was exercised in gk7205v500 NAND: FIT kernel volume, CMA, and sysupgrade for UBI layouts firmware#2526. That PR enables CMA for gk7205v500 and carries this change as a package patch on ecbc855, which is this repo's main.
• Once this is merged, a hisilicon-opensdk bump replaces that patch.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Enable CMA allocation in gk7205v500 OSAL

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Link the CMA allocator into OSAL when CONFIG_CMA is enabled, resolving the missing symbol.
• Use the xmedia kernel’s CMA API and shared zone definition to avoid incompatible layouts.
• Share the existing allocation limit; leave non-CMA builds unchanged.

Diagram

graph TD
  config{"CONFIG_CMA?"} -->|enabled| build["OSAL kbuild"] --> osal["OSAL module"] --> allocator["CMA allocator"] --> api["xmedia zone API"] --> zone["Reserved CMA zone"]

Loading

High-Level Assessment

Conditionally linking the existing allocator and using the kernel-owned CMA definition is the direct fix. Reimplementing allocation or retaining a private zone layout would add risk without addressing the integration more effectively.

Files changed (2) +13 / -15

Bug fix (2) +13 / -15

gk7205v500.kbuildLink the CMA allocator when CONFIG_CMA is enabled +5/-0

Link the CMA allocator when CONFIG_CMA is enabled

• Adds cma_allocator.o to the gk7205v500 OSAL module only for CMA-enabled kernels. Non-CMA builds keep their existing object list.

kernel/gk7205v500.kbuild

cma_allocator.cAlign CMA zone lookup and definitions with xmedia +8/-15

Align CMA zone lookup and definitions with xmedia

• Replaces the private CMA zone structure and legacy lookup with the xmedia kernel header and API. References the allocation limit already defined in allocator.c and casts zone fields to match their printk format.

kernel/osal/gk7205v500/mmz/cma_allocator.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. CMA callers can receive misaligned memory ✓ Resolved

Description

__mmb_alloc() accepts the requested align value but passes only the page count and size-derived
order to dma_alloc_from_contiguous(). When a caller requests alignment greater than that implied
by the allocation size, the returned physical address need not meet the requested alignment, unlike
an allocation through the existing fixed-region allocator.

Code

kernel/gk7205v500.kbuild[70]

+$(PREFIX)osal-objs += osal/gk7205v500/mmz/cma_allocator.o

Evidence

The PR links the previously dormant CMA implementation. The exported allocation API and user-device
ioctl both pass through the caller's alignment, but the CMA allocation call does not use it; the
existing fixed-region allocator explicitly aligns candidate addresses.

kernel/gk7205v500.kbuild[69-71]
kernel/osal/gk7205v500/mmz/mmz-userdev.c[145-155]
kernel/osal/gk7205v500/mmz/media-mem.c[233-245]
kernel/osal/gk7205v500/mmz/cma_allocator.c[74-99]
kernel/osal/gk7205v500/mmz/allocator.c[58-65]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly linked CMA allocator can return physical addresses that do not satisfy the caller's requested alignment.
## Fix Focus Areas
- kernel/gk7205v500.kbuild[69-71]
- kernel/osal/gk7205v500/mmz/cma_allocator.c[58-103]
## Recommended Fix
Apply the requested alignment when allocating CMA pages. If the allocator cannot satisfy an alignment, return failure rather than returning a misaligned block.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. OSAL loads without a usable CMA zone ✓ Resolved

Description

__allocator_init() skips missing or failed zone registrations but returns zero even when none were
registered. If every configured zone lookup or registration fails, media_mem_init() continues
successfully while subsequent CMA allocations return NULL because the zone list is empty.

Code

kernel/gk7205v500.kbuild[70]

+$(PREFIX)osal-objs += osal/gk7205v500/mmz/cma_allocator.o

Evidence

The new kbuild entry activates this initializer. Failed lookups are skipped and failed registrations
are destroyed, but the function still returns success; media initialization proceeds, and allocation
without a zone returns NULL. The repository's other CMA initializer checks for the
all-registrations-failed case.

kernel/gk7205v500.kbuild[69-71]
kernel/osal/gk7205v500/mmz/cma_allocator.c[396-438]
kernel/osal/gk7205v500/mmz/cma_allocator.c[88-109]
kernel/osal/gk7205v500/mmz/media-mem.c[849-876]
kernel/osal/linux/kernel/mmz/cma_allocator.c[604-623]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly activated CMA initializer reports success even if it registers no usable zone.
## Fix Focus Areas
- kernel/gk7205v500.kbuild[69-71]
- kernel/osal/gk7205v500/mmz/cma_allocator.c[382-439]
## Recommended Fix
Track successful CMA zone registrations and return an error when the configured zones yield none. Let `media_mem_init()` propagate that error so OSAL does not load with a nonfunctional allocator.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[widgetii]

Both review findings were real; addressed in 84fd543:

1. Alignment. __mmb_alloc() ignored the caller's align. It now asks dma_alloc_from_contiguous() for max(get_order(size), get_order(align)), so existing allocations get the same block and a larger requested alignment is honoured. That call silently caps the order at CONFIG_CMA_ALIGNMENT, so an alignment beyond the cap is refused rather than returned unmet.
2. No usable zone. __allocator_init() now counts attempted and registered zones and returns -ENODEV when none registered, as kernel/osal/linux's CMA allocator does. media_mem_init() already propagates it, so modprobe fails instead of osal loading with an empty zone list.

Re-verified on a GK7205V510 with mmz_allocator=cma mmz=anonymous,0,0x42000000,96M:

• the zone registers and osal 1.0 init success!;
• all 28 modules load, and CmaFree falls by the same ~15 MB;
• majestic reports HiSilicon SDK started;
• no allocation is refused for its alignment.