Am 10.02.23 um 13:18 schrieb Maxime Ripard:
[SNIP]
Well you don't seem to understand what I'm talking about.
I would certainly like you to stop making those kind of statements.
Apart from creating unnecessary tension, they don't bring anything to
the discussion.
Sorry for saying that. It was really not very polite from me.
It's just that you indeed seem to be talking about something completely
different.
This is about the primary and render node under /dev/dri/, not some
separate hw device.
The thing is, vc4 and v3d are both different nodes under /dev/dri and
separate hw devices.
So you really have only one hardware device. E.g. clocks, IOMMU, power
etc... is all the same.
Well, I mean, you can claim that all you want, but they certainly aren't
the same hardware device. Just like on virtually any !x86 SoC, the GPU
and display engines aren't the same device, and most of the time don't
even come from the same vendor.
Yeah, I'm perfectly aware of that.
This is just about the primary and render node under /dev/dri. This is a
software construct we use for access control, nothing else.
As far as I can see separate render and display hardware are a
completely different topic. Or am I missing something?
Going back to the initial issue, one of the files exposed by the v3d
driver is the v3d registers content. It makes no sense to expose the v3d
registers into the primary (vc4) node when the hardware doesn't match,
and v3d has its own node.
But those are different primary nodes, aren't they? E.g. you have
different /dev/dri/card0 and /dev/dri/card1 for them?
For the IOCTL level the render node is just a secure subset of the
functionality of the primary node. So I would not expect that there is
something different for the debugfs files.
Regards,
Christian.
Maxime
