linux-kernel - Re: [PATCH 1/3] media: venus: Add support for static video encoder/decoder declarations

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: <6d3ed1e8-7294-4927-9aac-daffe6ffef37@oss.qualcomm.com>
Date: Fri, 29 Nov 2024 12:23:05 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
        Vikash Garodia <quic_vgarodia@...cinc.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc: quic_renjiang@...cinc.com, quic_vnagar@...cinc.com,
        quic_dikshita@...cinc.com, konradybcio@...nel.org,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 1/3] media: venus: Add support for static video
 encoder/decoder declarations

On 28.11.2024 11:34 PM, Bryan O'Donoghue wrote:
> On 28/11/2024 22:14, Bryan O'Donoghue wrote:
>> On 28/11/2024 20:02, Konrad Dybcio wrote:
>>> Bryan,
>>>
>>> I'm still not sure if keeping the logic behind this makes sense at all.
>>>
>>> Could we not just call platform_device_register_data() with a static
>>> configuration of 1 core being enc and the other dec?
>>
>> That's another way to do this. One reason I wrote this series to continue to rely on the existing compat= method though is it stuck in my mind that we have some dependency ordering logic in at the moment.
>>
>> For example:
>>
>> commit 08b1cf474b7f72750adebe0f0a35f8e9a3eb75f6
>> Author: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
>> Date:   Fri Feb 5 19:11:49 2021 +0100
>>
>> And the other reason is the prototype platform_device_register_* looks like more surgery and ultimately more validation / potential for bugs.
>>
>> Since this driver is supposed to be moving to maintenance mode, I didn't want to do a more major rewrite of the probe() and remove() paths.
>>
>> ---
>> bod
>>
> 
> and.. I wanted to continue support sdm630/sdm660/msm8996/msm8998 without any additional effort to go finding power-domains and clocks which in those cases the existing compat= method actually does something useful.
>
> Also potentially other/new additions to venus which have xcoder specific PDs and clocks would logically want to specify those as we do for the above listed SoCs.

We can just keep a small function to grab these and assign as if they
were specified under the root node (check if video-encoder/video-decoder
both exist, grab the clocks for respective cores and continue normally).

My old series [1] should make it easier to tackle that, feel free to take
it over.

Konrad

[1] https://github.com/somainline/linux/commits/topic/mars