You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ONI compliance registers
Since the spec might evolve in the future, with new capabilities that might have hardware-dependent parameters, the second register region is reserved for information about the hardware capabilities themselves.
Address 0x00100000 will contain the specification version. Since new capabilities will always be specified in a revision, this is enough to inform of all the capabilities.
Following addresses will specify optional or hardware-dependent parameters as described in the relevant specification version, such as buffer sizes for specific functions.
The text was updated successfully, but these errors were encountered:
Since I originally wrote this, I have a slightly different opinion.
The base idea is the same: We need a field that informs to which spec revision the hardware is compliant. And we might need fields for some values whose meaning might be defined by the spec but actual values are hardware-dependent.
However, I am now inclined to think that a revision might not always just be a full set of fixed capabilities. I believe we should be able to define capabilities as "optional" sections of the spec, which is a common practice. This section should, then, accommodate ways to inform which optional capabilities (as defined by a spec version) are enabled.
Ported from jonnew/ONI#6 and related to #5
Original text:
The text was updated successfully, but these errors were encountered: