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@xxxxxxxxxx>
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.
---
bod
