Re: [PATCH v9 7/7] drm/i915/icl: Define MOCS table for Icelake

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>

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@xxxxxxxxx>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx>
Reviewed-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
Acked-by: Tomasz Lis <tomasz.lis@xxxxxxxxx>

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux