On 4/18/2018 9:45 AM, Oscar Mateo wrote:
On 4/18/2018 9:38 AM, Chris Wilson wrote:
Quoting Oscar Mateo (2018-04-18 17:30:41)
On 4/17/2018 3:58 PM, Yunwei Zhang wrote:
+ /*
+ * HW expects MCR to be programed to a enabled slice/subslice
pair
+ * before any MMIO read into slice/subslice register
+ */
The comment above makes more sense in sanitize_mcr, together with
the WA
label. You can make it a bit more verbose with the info in the commit
message. Something like this:
/*
* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
* Before any MMIO read into slice/subslice specific registers, MCR
* packet control register needs to be programmed to point to any
* enabled s/ss pair. Otherwise, incorrect values will be returned.
* This means each subsequent MMIO read will be forwarded to an
* specific s/ss combination, but this is OK since these registers
* are consistent across s/ss in almost all cases. In the rare
* occasions, such as INSTDONE, where this value is dependent
* on s/ss combo, the read shoud be done with read_subslice_reg.
*/
I don't think any other comment is required here.
Apart from the answer to the earlier question, what mmio read after this
point? If all slice/subslice register access is through this function,
what are you trying to protect? Very curious.
-Chris
The problem is that the BSpec does not have a comprehensive list of
registers that live in the slice/subslice, so it's difficult to know
when this is going to become a problem. For example, I know from
previous experience that the MOCS tables are replicated across slices
(that's why we couldn't let UMD decide when to shutdown them: because
the MOCS tables get lost as soon as you reconfigure the number of
s/ss. The only way to do this in by poking in the context, so that the
MOCS gets reprogrammed immediately after).
This hasn't been an issue until know because the hardware would route
your read to a valid s/ss combo whenever the MCR select was 0s.
Apparently, this is not the case anymore...
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
