[Intel-gfx] [PATCH v9 7/7] drm/i915/icl: Define MOCS table for Icelake
Lucas De Marchi
lucas.demarchi at intel.com
Fri Jan 25 09:42:21 UTC 2019
On Thu, Jan 24, 2019 at 12:41:27PM +0200, Joonas Lahtinen wrote:
>Quoting Lucas De Marchi (2019-01-24 02:06:04)
>> From: Tomasz Lis <tomasz.lis at intel.com>
>>
>> The table has been unified across OSes to minimize virtualization overhead.
>>
>> The MOCS table is now published as part of bspec, and versioned. Entries
>> are supposed to never be modified, but new ones can be added. Adding
>> entries increases table version. The patch includes version 1 entries.
>>
>> Meaning of each entry is now explained in bspec, and user mode clients
>> are expected to know what each entry means. The 3 entries used for previous
>> platforms are still compatible with their legacy definitions, but that is
>> not guaranteed to be true for future platforms.
>>
>> v2: Fixed SCC values, improved commit comment (Daniele)
>> v3: Improved MOCS table comment (Daniele)
>> v4: Moved new entries below gen9 ones. Put common entries into
>> definition to be used in multiple arrays. (Lucas)
>> v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
>> to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas)
>> v6: Removed definitions of reserved entries. (Michal)
>> Increased limit of entries sent to the hardware on gen11+.
>> v7: Simplify table as done for previou gens (Lucas)
>> v8: Rebase on cached number of entries per-platform and use new
>> MOCS_ENTRY() macro (Lucas)
>> v9: Update comment (from Tomasz)
>>
>> BSpec: 34007
>> BSpec: 560
>>
>> Signed-off-by: Tomasz Lis <tomasz.lis at intel.com>
>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>> Reviewed-by: Lucas De Marchi <lucas.demarchi at intel.com>
>> Signed-off-by: Lucas De Marchi <lucas.demarchi at intel.com>
>> Acked-by: Tomasz Lis <tomasz.lis at intel.com>
>
>I don't think we should have A-b/R-b from patch authors.
In this case I thought it was good because I modified right and left the
patch from someone else. Getting and ack from the original author is
good.
>
>If you add you S-o-b to the code, you can remove the R-b, and if you
>wrote portion of the code, you don't really add Reviewed-by or Acked-by.
ok
>
>Similarly, if the code is modified after some R-bs are given, you should
>indicate those reviews to be stale.
Daniele had reviewed a very recent one - later changes were mostly
cosmetics. Anyway, I asked Daniele on irc after seing your response and
he said his r-b still stands, so I'm keeping it.
thanks
Lucas De Marchi
>
>Regards, Joonas
More information about the Intel-gfx
mailing list