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