linux-kernel - Re: [PATCH 3/3] arm64: dts: ti: k3-am62p5-sk: Reserve 576 MiB of global CMA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1b5e3175-c9b7-4fb5-b405-e46373a6a469@ti.com>
Date: Fri, 21 Jun 2024 21:44:30 +0530
From: Devarsh Thakkar <devarsht@...com>
To: Brandon Brnich <b-brnich@...com>, Vignesh Raghavendra <vigneshr@...com>
CC: <nm@...com>, <vigneshr@...com>, <kristo@...nel.org>, <robh@...nel.org>,
        <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <praneeth@...com>, <a-bhatia1@...com>,
        <j-luthra@...com>, <detheridge@...com>, <p-mantena@...com>,
        <vijayp@...com>
Subject: Re: [PATCH 3/3] arm64: dts: ti: k3-am62p5-sk: Reserve 576 MiB of
 global CMA

Hi Vignesh,

On 14/06/24 22:34, Brandon Brnich wrote:
[..]

>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
>> index fb980d46e304..5ef74d9f8eea 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
>> @@ -48,6 +48,13 @@ reserved-memory {
>>  		#size-cells = <2>;
>>  		ranges;
>>  
>> +		linux,cma {
>> +			compatible = "shared-dma-pool";
>> +			reusable;
>> +			size = <0x00 0x24000000>;
>> +			linux,cma-default;
>> +		};
> 
> Since AM62p has 8gb memory, this allocation can come from upper portion.
> Doing so breaks Wave5 encoding/decoding as the driver can not yet handle
> 48 bit addressing. 48bit support is scheduled to be upstreamed, but unsure of
> when this will actually make it in.  
> 
> Could we force this into lower 32bits using same
> alloc-ranges as done in your AM62a patch[0]?
> 


I would like to take a look at this separately, is it possible for you
to drop this patch [3/3] from series due to above comments and take the
rest two from the series ?

Regards
Devarsh