Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 31 May 2023 10:44:29 -0700
From:   Bjorn Andersson <quic_bjorande@quicinc.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
CC:     Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: reserved-memory: rmtfs: Allow dynamic
 allocation
Message-ID: <20230531174429.GB112802@hu-bjorande-lv.qualcomm.com>
References: <20230530193436.3833889-1-quic_bjorande@quicinc.com>
 <20230530193436.3833889-2-quic_bjorande@quicinc.com>
 <4337f333-0c78-8749-658d-3f7f69538571@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4337f333-0c78-8749-658d-3f7f69538571@linaro.org>
Precedence: bulk

On Wed, May 31, 2023 at 10:05:50AM +0200, Krzysztof Kozlowski wrote:
> On 30/05/2023 21:34, Bjorn Andersson wrote:
> > Allow instances of the qcom,rmtfs-mem either be defined as a
> > reserved-memory regoin, or just standalone given just a size.
> 
> typo: region
> 
> I am pretty sure I saw some patches from Qualcomm also making one of
> reserved-memory users a bit more dynamic (some boot-thingy?). Would be
> nice to unify...
> 
> > 
> > This relieve the DeviceTree source author the need to come up with a
> > static memory region for the region.
> 
> If you region does not have to be static, why bothering with the size in
> DT? I assume this can be really dynamic and nothing is needed in DT. Not
> even size.
> 

The size, client-id and vmid need to match the firmware and access
policy configuration, and are as such device-specific properties for the
region.

The desired size is available during the rmtfs handshake, so it's
plausible that one could come up with a mechanism of dynamic allocation.
But this would be complicated (as I'd prefer not to have the rmtfs
service in the kernel...), and we'd still end up with something in DT to
affect placement etc - often a reserved-memory region to specifically
define the placement.

We'd still need the client-id and vmid properties, and we still need
some mechanism to instantiate the rmtfs service and something that will
configure the access permissions for the region...

Regards,
Bjorn