Try to address the drm_debugfs issues

[Christian König]

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