Date:   Wed, 21 Sep 2022 08:35:43 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Doug Berger <opendmb@...il.com>, Rob Herring <robh@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Frank Rowand <frowand.list@...il.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <songmuchun@...edance.com>,
        Mike Rapoport <rppt@...nel.org>,
        Christoph Hellwig <hch@....de>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Robin Murphy <robin.murphy@....com>,
        Borislav Petkov <bp@...e.de>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Neeraj Upadhyay <quic_neeraju@...cinc.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Hildenbrand <david@...hat.com>, Zi Yan <ziy@...dia.com>,
        Oscar Salvador <osalvador@...e.de>,
        Hari Bathini <hbathini@...ux.ibm.com>,
        Kees Cook <keescook@...omium.org>,
        - <devicetree-spec@...r.kernel.org>,
        KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
        Mel Gorman <mgorman@...e.de>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-mm@...ck.org, iommu@...ts.linux.dev
Subject: Re: [PATCH 16/21] dt-bindings: reserved-memory: introduce
 designated-movable-block

On 21/09/2022 02:14, Doug Berger wrote:
> On 9/19/2022 4:03 AM, Krzysztof Kozlowski wrote:
>> On 19/09/2022 01:12, Doug Berger wrote:
>>> On 9/18/2022 3:31 AM, Krzysztof Kozlowski wrote:
>>>> On 14/09/2022 18:13, Doug Berger wrote:
>>>>> On 9/14/2022 7:55 AM, Rob Herring wrote:
>>>>>> On Tue, Sep 13, 2022 at 12:55:03PM -0700, Doug Berger wrote:
>>>>>>> Introduce designated-movable-block.yaml to document the
>>>>>>> devicetree binding for Designated Movable Block children of the
>>>>>>> reserved-memory node.
>>>>>>
>>>>>> What is a Designated Movable Block? This patch needs to stand on its
>>>>>> own.
>>>>> As noted in my reply to your [PATCH 00/21] comment, my intention in
>>>>> submitting the entire patch set (and specifically PATCH 00/21]) was to
>>>>> communicate this context. Now that I believe I understand that only this
>>>>> patch should have been submitted to the devicetree-spec mailing list, I
>>>>> will strive harder to make it more self contained.
>>>>
>>>> The submission of entire thread was ok. What is missing is the
>>>> explanation in this commit. This commit must be self-explanatory (e.g.
>>>> in explaining "Why are you doing it?"), not rely on other commits for
>>>> such explanation.
>>>>
>>>>>
>>>>>>
>>>>>> Why does this belong or need to be in DT?
>>>>> While my preferred method of declaring Designated Movable Blocks is
>>>>> through the movablecore kernel parameter, I can conceive that others may
>>>>> wish to take advantage of the reserved-memory DT nodes. In particular,
>>>>> it has the advantage that a device can claim ownership of the
>>>>> reserved-memory via device tree, which is something that has yet to be
>>>>> implemented for DMBs defined with movablecore.
>>>>
>>>> Rephrasing the question: why OS memory layout and OS behavior is a
>>>> property of hardware (DTS)?
>>> I would say the premise is fundamentally the same as the existing
>>> reserved-memory child node.
>>
>> I don't think it is fundamentally the same.
>>
>> The existing reserved-memory node describes memory used by hardware - by
>> other devices. The OS way of handling this memory - movable, reclaimable
>> etc - is not part of it.
>>
>> So no, it is not the same.
>>
>>>
>>> I've been rethinking how this should be specified. I am now thinking
>>> that it may be better to introduce a new Reserved Memory property that
>>> serves as a modifier to the 'reusable' property. The 'reusable' property
>>> allows the OS to use memory that has been reserved for a device and
>>> therefore requires the device driver to reclaim the memory prior to its
>>> use. However, an OS may have multiple ways of implementing such reuse
>>> and reclamation.
>>
>> ... and I repeat the question - why OS way of implementing reuse and
>> reclamation is relevant to DT?
>>
>>> I am considering introducing the vendor specific 'linux,dmb' property
>>> that is dependent on the 'reusable' property to allow both the OS and
>>> the device driver to identify the method used by the Linux OS to support
>>> reuse and reclamation of the reserved-memory child node.
>>
>> Sure, but why? Why OS and Linux driver specific pieces should be in DT?
>>> Such a property would remove any need for new compatible strings to the
>>> device tree. Does that approach seem reasonable to you?
>>
>> No, because you did not explain original question. At all.
> I apologize if I have somehow offended you, but please recognize that my 
> apparent inability to answer your question does not come from an 
> unwillingness to do so.
> 
> I believe an example of the reserved-memory node being used the way you 
> indicate (though there are other uses) can be expressed with device tree 
> nodes like these:
> 
> reserved-memory {
> 	#address-cells = <0x1>;
> 	#size-cells = <0x1>;
> 	ranges;
> 
> 	multimedia_reserved: multimedia@...00000 {
> 		reg = <0x80000000 0x10000000>;
> 	};
> };
> 
> decoder@...2000 {
> 	memory-region = <&multimedia_reserved>;
> 	/* ... */
> };
> 
> Here a 256MB chunk of memory is reserved for use by a hardware decoder 
> as part of rendering a video stream. In this case the memory is reserved 
> for the exclusive use of the decoder device and its associated device 
> driver.
> 
> The Devicetree Specification includes a property named 'reusable' that 
> could be applied to the multimedia node to allow the OS to "use the 
> memory in this region with the limitation that the device driver(s) 
> owning the region need to be able to reclaim it back". 

Indeed, there is such.... and should be used instead. :)

> This is a good 
> idea, because this memory could probably be put to good use when the 
> decoder is not active. Unfortunately, the methods for reusing this 
> memory are not defined for Linux so the multimedia reserved memory would 
> not be reused even though the devicetree indicates that it is allowed.

Then rather implementation has to be changed, not Devicetree bindings.

> 
> The notion behind this commit was to introduce the 
> 'designated-movable-block' compatible string that could be added to the 
> multimedia node to allow the Client Program (i.e. Linux) to select a 
> device driver that knows how to reclaim reserved memory back from the OS 
> when it is needed by the decoder device and release it back to the OS 
> when the decoder no longer needs it. In this way, the purpose of the 
> multimedia node remains the same (i.e. to reserve memory for use by a 
> device), but a new compatible string is defined to allow for selection 
> of an appropriate device driver and allow successful reuse of the memory 
> for the benefit of the system.

We don't need a new compatible for it but use that existing property.

> 
>  From Rob's feedback it is clear that 'designated-movable-block' is not 
> an appropriate name, but maybe 'linux,dmb' might have been. However, it 
> would be more flexible if a 'linux,dmb' property could be introduced as 
> a modifier to the existing 'reusable' property to provide a general 
> mechanism for clarifying how 'reusable' should be supported by the 
> Client Software and its device drivers.
> 
> Such a property is not directly relevant to hardware, but the devicetree 
> is not wholly concerned with hardware. Reserved memory node children 
> include support for 'linux,cma-default' and 'linux,dma-default' 
> properties that signal behavioral intent to the Linux OS. Some aspects 
> of the devicetree (e.g. the /chosen node and 'reusable' property) are 
> for the benefit of the Client Program.

Fair enough, although there is difference between generic property for
reusable/reclaimable memory and a property describing one of Linux
memory-management zones.

Best regards,
Krzysztof

Powered by blists - more mailing lists