Re: [PATCH v2 4/4] arm64: dts: qcom: x1-dell-thena: bump linux,cma to 256 MiB

[Bjorn Andersson <andersson@kernel.org>]

On Fri, May 22, 2026 at 10:33:45PM +0100, Bryan O'Donoghue wrote:
> On 22/05/2026 18:16, Michael Scott wrote:
> > > └─[$] <git:(0.7.0-multipass-v0*)>
> > 
> > Good point about the libcamera version. I debugged this on Ubuntu 26.04
> > (v0.7.0+patches). I tried testing v0.7.1, but it caused a crash due to
> > API changes with other parts of the subsystem.  I checked the diff of
> > upstream between v0.7.0 and v0.7.1 for the dma allocator code and I
> > didn't see any changes, but I wasn't looking at the software ISP
> > changes.
> > 
> > This highlights that "I'm doing this wrong". I'll move to a cleaner
> > rolling distro where staying current is a lot easier.
> > 
> > The GPUISP support looks great!
> > 
> > Dropping this patch as I'm not understanding the full allocator story.
> > Sorry for the noise.
> 
> The whole make CMA bigger thing is an error I was pushing myself.
> 
> CMA is required for some systems like say Hantro on i.MX where - the encoder
> doesn't know how to deal with non PHYS contig memory so when you are passing
> framebuffers around from once hw block to another, you need to make them
> physically contiguous.
> 
> Not a problem for us on Qcom hw though. Like Rob said, I'm actually not sure
> why we need a CMA block on Qcom hardware at all.
> 

&pcie_smmu { status = "reserved" }; means that typical Makena and Hamoa
machines need CMA. Which should be unrelated...

Regards,
Bjorn

> GPU or WiFi I think but not for Camera anymore anyway.
> 
> ---
> bod