On 3/24/26 19:46, Dan Williams wrote:
Alison Schofield wrote:
<snip>
Like I replied to Alejandro it is not a dependency for the type-2 series [1]. It *is* a fix for the issue reported by PJ, but it can go in independent of the base type-2 work as a standalone capability. [1]: http://lore.kernel.org/[email protected]
I'm afraid I do not understand what you mean here. <snip>
Just like the decoder LOCK bit the preservation setting is a decoder property, not a region property. Region auto-assembly is then just an automatic way to set that decoder policy. So, no, I would not expect a new region flag for this policy.
Could it be acceptable an accelerator having the option of locking its HDM if not already done by the BIOS?
<snip>
Appreciate you pulling this together. I want to land type-2 with the existing expectation that unload is always destructive then circle back
As I said, v22 had that destructive behavior, but v23 kept the HDM committed, as that was what you asked for.
Last v24 has only the support for dealing with committed decoders, what is the expectation from current BIOS (Intel and AMD) if a Type2 device is found at boot time. I got now some BIOS versions which lock the HDM decoder for a Type2 device making impossible any destructive action. The reason for only supporting this case is to have a chance to be in time for 7.1 with the basic (but good enough) support as there are issues with the changes to create a region which will need all to agree on how to solve them, and unlikely before 7.1 window closes.
to address this additional detail because it is more than just decoder policy that needs to be managed. The type-2 driver may need help finding its platform firmware configured address range if a device reset destroyed the decoder settings.
And again, this problem should be addressed, IMO, as a follow-up.
