linux-kernel - Re: [PATCH v3 2/2] ARM: dts: tegra20: Add video decoder node

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: <22ad307f-99d6-0760-7cc0-adbca25ac7b5@gmail.com>
Date:   Thu, 12 Oct 2017 18:43:32 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>
Cc:     Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Stephen Warren <swarren@...dotorg.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        linux-media@...r.kernel.org, linux-tegra@...r.kernel.org,
        devel@...verdev.osuosl.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] ARM: dts: tegra20: Add video decoder node

On 12.10.2017 16:45, Jon Hunter wrote:
> 
> On 12/10/17 14:25, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Thu, Oct 12, 2017 at 03:06:17PM +0300, Dmitry Osipenko wrote:
>>> Hello Vladimir,
>>>
>>> On 12.10.2017 10:43, Vladimir Zapolskiy wrote:
>>>> Hello Dmitry,
>>>>
>>>> On 10/11/2017 11:08 PM, Dmitry Osipenko wrote:
>>>>> Add a device node for the video decoder engine found on Tegra20.
>>>>>
>>>>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/tegra20.dtsi | 17 +++++++++++++++++
>>>>>  1 file changed, 17 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
>>>>> index 7c85f97f72ea..1b5d54b6c0cb 100644
>>>>> --- a/arch/arm/boot/dts/tegra20.dtsi
>>>>> +++ b/arch/arm/boot/dts/tegra20.dtsi
>>>>> @@ -249,6 +249,23 @@
>>>>>  		*/
>>>>>  	};
>>>>>  
>>>>> +	vde@...1a000 {
>>>>> +		compatible = "nvidia,tegra20-vde";
>>>>> +		reg = <0x6001a000 0x3D00    /* VDE registers */
>>>>> +		       0x40000400 0x3FC00>; /* IRAM region */
>>>>
>>>> this notation of a used region in IRAM is non-standard and potentially it
>>>> may lead to conflicts for IRAM resource between users.
>>>>
>>>> My proposal is to add a valid device tree node to describe an IRAM region
>>>> firstly, then reserve a subregion in it by using a new "iram" property.
>>>>
>>>
>>> The defined in DT IRAM region used by VDE isn't exactly correct, actually it
>>> should be much smaller. I don't know exactly what parts of IRAM VDE uses, for
>>> now it is just safer to assign the rest of the IRAM region to VDE.
>>>
>>> I'm not sure whether it really worthy to use a dynamic allocator for a single
>>> static allocation, but maybe it would come handy later.. Stephen / Jon /
>>> Thierry, what do you think?
>>
>> This sounds like a good idea. I agree that this currently doesn't seem
>> to be warranted, but consider what would happen if at some point we have
>> more devices requiring access to the IRAM. Spreading individual reg
>> properties all across the DT will make it very difficult to ensure they
>> don't overlap.
>>
>> Presumably the mmio-sram driver will check that pool don't overlap. Or
>> even if it doesn't it will make it a lot easier to verify because it's
>> all in the same DT node and then consumers only reference it.
>>
>> I like Vladimir's proposal. I also suspect that Rob may want us to stick
>> to a standardized way referencing such external memory.
> 
> FWIW I agree. Seems like a nice approach and describes the h/w accurately.
> 

Alright :)