pl negotiation matrix
johna-eximiusdesign opened this issue · comments
Hey Michael,
Can you review the attached. It is meant to spell out the protocol negotiation. I took a reasonable stab at the matrix, but I wasn't confident on the Type 1,2 to Type 3 negotiations (marked with the ????). Can you please confirm the matrix is correct and fill in the ???? for lines 17 and 22.
Thanks,
John
This looks pretty good. The concept of a host being limited to supporting supporting type 3 but not types 1/2 or the inverse are not obvious to me. I think rows 14-18 and 20-24 can be condensed into a single set. That should clarify the reported values for both the blank cells. F17 should be "6" and F22 should be "5". I think it is safe to assume that this host is either single protocol (one one link layer for CXL.io) or fully featured with support for all three protocols. If both host and device support multi-protocols, it is the device that limits which of the three are actually supported in that link. If either is a single protocol only die, then both are limited by the lessor capable die.
OK, I think the answer is the F17 and F22 cells you filled in and we can implement accordingly. Other than those two cells, the Host vs Device designation didn't seem particularly relevant (we negotiated to the lowest level), but for those two we'll add the LPIF_IS_HOST parameter and negotiate accordingly.
Also, if the local parameter value or the remote advertised value is not one of the ones in the table (i.e. encoding 0,1,2 which is PCIe/DMI, RSVD, RSVD) the logic will not set pl_protocol_vld but it will propagate the link_up signal to the rest of the logic. This indicates the negotiation failure but doesn't stop the rest of the system from coming up if the negotiation was errant. This made sense to me, but let me know if you want to change this behavior.
Had a call with Michael and the above makes sense. Unsupported encodings are not a concern and we can handle them however we see fit.