On 28/11/2024 20:02, Konrad Dybcio wrote:
On 27.11.2024 2:34 AM, Bryan O'Donoghue wrote:
Add resource structure data and probe() logic to support static
declarations of encoder and decoder.
Right now we rely on video encoder/decoder selection happening in the dtb
but, this goes against the remit of device tree which is supposed to
describe hardware, not select functional logic in Linux drivers.
Provide two strings in the venus resource structure enc_nodename and
dec_nodename.
When set the venus driver will create an OF entry in-memory consistent
with:
dec_nodename {
compat = "video-decoder";
};
and/or
enc_nodename {
compat = "video-encoder";
};
This will allow us to reuse the existing driver scheme of relying on compat
names maintaining compatibility with old dtb files.
dec_nodename can be "video-decoder" or "video0"
enc_nodename can be "video-encoder" or "video1"
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
---
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
