On Wed, 1 Jul 2015, Francisco Jerez wrote:
Peter Antoine <peter.antoine@xxxxxxxxx> writes:
On Tue, 30 Jun 2015, Francisco Jerez wrote:
Francisco Jerez <currojerez@xxxxxxxxxx> writes:
Peter Antoine <peter.antoine@xxxxxxxxx> writes:
On Mon, 29 Jun 2015, Peter Antoine wrote:
On Thu, 25 Jun 2015, Francisco Jerez wrote:
Peter Antoine <peter.antoine@xxxxxxxxx> writes:
This change adds the programming of the MOCS registers to the gen 9+
platforms. This change set programs the MOCS register values to a set
of values that are defined to be optimal.
It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.
v2:
-'static const' for private data structures and style changes.(Matt
Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
Signed-off-by: Peter Antoine <peter.antoine@xxxxxxxxx>
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_reg.h | 9 +
drivers/gpu/drm/i915/intel_lrc.c | 10 +-
drivers/gpu/drm/i915/intel_lrc.h | 4 +
drivers/gpu/drm/i915/intel_mocs.c | 373
++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_mocs.h | 64 +++++++
6 files changed, 460 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_mocs.c
create mode 100644 drivers/gpu/drm/i915/intel_mocs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b7ddf48..c781e19 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -35,6 +35,7 @@ i915-y += i915_cmd_parser.o \
i915_irq.o \
i915_trace_points.o \
intel_lrc.o \
+ intel_mocs.o \
intel_ringbuffer.o \
intel_uncore.o
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 7213224..3a435b5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7829,4 +7829,13 @@ enum skl_disp_power_wells {
#define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
#define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
+/* MOCS (Memory Object Control State) registers */
+#define GEN9_LNCFCMOCS0 (0xB020) /* L3 Cache Control
base */
+
+#define GEN9_GFX_MOCS_0 (0xc800) /* Graphics MOCS base
register*/
+#define GEN9_MFX0_MOCS_0 (0xc900) /* Media 0 MOCS base
register*/
+#define GEN9_MFX1_MOCS_0 (0xcA00) /* Media 1 MOCS base
register*/
+#define GEN9_VEBOX_MOCS_0 (0xcB00) /* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0 (0xcc00) /* Blitter MOCS base
register*/
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 9f5485d..73b919d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -135,6 +135,7 @@
#include <drm/drmP.h>
#include <drm/i915_drm.h>
#include "i915_drv.h"
+#include "intel_mocs.h"
#define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
#define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE)
@@ -796,7 +797,7 @@ static int logical_ring_prepare(struct
intel_ringbuffer *ringbuf,
*
* Return: non-zero if the ringbuffer is not ready to be written to.
*/
-static int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
+int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
struct intel_context *ctx, int
num_dwords)
{
struct intel_engine_cs *ring = ringbuf->ring;
@@ -1379,6 +1380,13 @@ static int gen8_init_rcs_context(struct
intel_engine_cs *ring,
if (ret)
return ret;
+ /*
+ * Failing to program the MOCS is non-fatal.The system will not
+ * run at peak performance. So generate a warning and carry on.
+ */
+ if (gen9_program_mocs(ring, ctx) != 0)
+ DRM_ERROR("MOCS failed to program: expect performance
issues.");
+
return intel_lr_context_render_state_init(ring, ctx);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.h
b/drivers/gpu/drm/i915/intel_lrc.h
index 04d3a6d..dbbd6af 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -44,6 +44,10 @@ int intel_logical_rings_init(struct drm_device *dev);
int logical_ring_flush_all_caches(struct intel_ringbuffer *ringbuf,
struct intel_context *ctx);
+
+int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
+ struct intel_context *ctx, int
num_dwords);
+
/**
* intel_logical_ring_advance() - advance the ringbuffer tail
* @ringbuf: Ringbuffer to advance.
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
new file mode 100644
index 0000000..7c09e67
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -0,0 +1,373 @@
+/*
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
a
+ * copy of this software and associated documentation files (the
"Software"),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions: *
+ * The above copyright notice and this permission notice (including the
next
+ * paragraph) shall be included in all copies or substantial portions of
the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE
+ * SOFTWARE.
+ *
+ * Authors:
+ * Peter Antoine <peter.antoine@xxxxxxxxx>
+ */
+
+#include "intel_mocs.h"
+#include "intel_lrc.h"
+#include "intel_ringbuffer.h"
+
+/* structures required */
+struct drm_i915_mocs_entry {
+ u32 control_value;
+ u16 l3cc_value;
+};
+
+struct drm_i915_mocs_table {
+ u32 size;
+ const struct drm_i915_mocs_entry *table;
+};
+
+/* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
+#define MOCS_CACHEABILITY(value) (value << 0)
+#define MOCS_TGT_CACHE(value) (value << 2)
+#define MOCS_LRUM(value) (value << 4)
+#define MOCS_AOM(value) (value << 6)
+#define MOCS_LECC_ESC(value) (value << 7)
+#define MOCS_LECC_SCC(value) (value << 8)
+#define MOC_PFM(value) (value << 11)
+#define MOCS_SCF(value) (value << 14)
+
+/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word
*/
+#define MOCS_ESC(value) (value << 0)
+#define MOCS_SCC(value) (value << 1)
+#define MOCS_L3_CACHEABILITY(value) (value << 4)
+
+/* Helper defines */
+#define GEN9_NUM_MOCS_RINGS (5) /* Number of mocs engines to program
*/
+#define GEN9_NUM_MOCS_ENTRIES (63) /* 63 out of 64 - 64 is rsvrd
*/
+
+/* EDRAM Caching options */
+#define EDRAM_PAGETABLE (0)
+#define EDRAM_UC (1)
+#define EDRAM_RESERVED (2)
According to the BSpec this is WT rather than reserved?a
Just checked the Bspec and you are correct, changing the text.
As well as for the items below.
Just to add - I was looking at the wrong gen.
+#define EDRAM_WB (3)
+
+/* L3 Caching options */
+#define L3_DIRECT (0)
+#define L3_UC (1)
+#define L3_RESERVED (2)
+#define L3_WB (3)
+
+/* target cache */
+#define ELLC (0)
BSpec says that this is "Use TC/LRU controls from page table", but upon
a closer look it seems like the BSpec is wrong and your patch is
correct. Can you confirm that this is what you intended?
These values look good, they are bits 3:2 for the XXX_MOCS_N registers
(c800) and friends.
+#define LLC (1)
+#define LLC_ELLC (2)
+
+/*
+ * MOCS tables
+ *
+ * These are the MOCS tables that are programmed across all the rings.
+ * The control value is programmed to all the rings that support the
+ * MOCS registers. While the l3cc_values are only programmed to the
+ * LNCFCMOCS0 - LNCFCMOCS32 registers.
+ *
+ * NOTE: These tables MUST start with being uncached and the length MUST
be
+ * less than 63 as the last two registers are reserved by the
hardware.
+ */
+static struct drm_i915_mocs_entry skylake_mocs_table[] = {
+ /* {0x00000009, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) |
+ MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x0000003b, 0x0030} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC_ELLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))},
+ /* {0x00000039, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x00000017, 0x0030} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))},
+ /* {0x00000017, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x00000019, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) |
+ MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x00000037, 0x0030} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))},
+ /* {0x00000037, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x0000003b, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC_ELLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+};
Mesa will want an additional entry with TC=LLC/eLLC, LeCC=PTE, L3CC=WB,
everything else unset, I'll reply with a userspace patch making use of
your change if you add such an entry.
Ok. I think what you want is, same as entry two, but use the underlying
pagetable settings and not specify the EDRAM settings. Please confirm in
the new patchset.
Yeah, that sounds good.
Another thing worth mentioning is that entries 0, 2 and 5 seem to do the
same thing suspiciously, the only difference is the LRUM field which
AFAIK doesn't have any effect for LeCC=UC. Is my understanding correct?
These tables are generated via requests and then boiled down to the above.
So some of the entries are by request. Swings and roundabouts, can remove
the ones that look redundant but then the tuning that has been done wont
match. I'll add the new entry at the end of the table.
Are you planning to propagate the entry you just added back to the
original table this was generated from? What about new entries we may
need to add in the future? What should be the process to make sure that
our table and the master table don't diverge and end up with conflicting
entries we cannot remove because of ABI compatibility? I guess there
should be a comment on the top warning that the table is part of the
kernel ABI and supposed to be kept in sync with your table, so other
people don't change it unknowingly?
Thanks.
I am talking to the team that handles this and see if they will add this
(so future gens this is baked in) but it is unlikely that the other tables
will stay in step as getting in changes will cause too much grief getting
them upstreamed and as the table is auto-generated we will not be able to
guarantee the ordering. It will have to be manual job for anyone doing
this. It is required for other platforms for the tables to match the
userspace for performance reasons, but on Linux it will be by request if
there is a problem. We will see what happens.
I think it only makes sense for Linux to maintain compatibility with
Android's tables if we agree on some straightforward process for us to
allocate new entries without causing conflicts (otherwise people are
likely to ignore the issue completely and let the tables diverge, as you
mentioned yourself), and have some guarantee that any entries ever
contributed by your team to the Linux kernel (and therefore part of our
stable ABI) will never be changed or reordered in the future.
I think internally (and informally) that we cannot keep sync between Android
and Linux. We need to keep compatibility with userspace and there is no
guarantee of ordering as these tables are generated at runtime. The tables
that are in Linux are a snapshot. These changes are supposed to stabilise at
PV so they don't change in the future, but if a bug or good performance
enhancement occurs I can't imagine that they wont make the changes.
I have the impression that because of your development model you have
far more freedom to make changes in your kernel ABI after the fact than
we do -- OTOH we would be locked in if we accept to import Android's
tables now, what brings me to the next question: How would you feel
about reversing the roles of our tables? The workflow could be as
follows:
The Android kernel is more flexible, in what it accepts, and secondly (and
more importantly) you should be using the userspace drivers as this is
the API and is tuned, so changing the tables are less of a problem.
- The MOCS tables part of the Linux kernel would be developed and
discussed publicly in this mailing list, independently from your team
(which doesn't mean that your contributions and feed-back regarding
future changes in the MOCS tables wouldn't be very much welcome).
This is fine. But be aware the RFC for the MOCS was first floated in March and
teams were directly contacted when this happened and not a lot of response
was received. MOCS ain't sexy and people only get interested when they
feel that they maybe a performance problem - then they look to caching.
But, I think this is the sensible model. For the new tables (new gens) a drop
from the internal cache models as these will have had some form of tuning from
different teams and requirements (OpenCL, OpenGL, Media, Security, etc...) then
these can be discussed on the mailing list as required.
I am not sure if that is acceptable to everyone. As we are going to have to
carry some patches in Android and drop any upstream MOCS changes.
- If you wish you may maintain compatibility with Linux by sync'ing
your tables periodically. If you do you may still have the choice to
break compatibility in the future and start from scratch with clean
tables if this turns out to become a burden for you. (Note that the
converse statement doesn't work if the tables part of the Linux
kernel were to be considered downstream, because we have the
requirement of keeping backwards compatibility with previous
revisions of the ABI).
This is not really possible. As mentioned above ordering may change.
- If you choose to keep compatibility the process for you to allocate
new entries avoiding conflicts should be relatively straightforward:
Send a patch to this mailing list and once it's ACK'ed you would have
the guarantee that the same index wouldn't ever be reused for any
other purpose in the future, and you could start making use of it in
the Android stack right away.
It would be possible to allocate a high number say in the 60's as the current
table is generated from 270+ policies and only spits out 8 or 9 entries. So the
chance of the tables getting into the 60's is quite low. That could be an
option, but I can see that being poo-pooed upstream with the simple question
of why not start at 0.
Like you, it would be nice too see what others think.
Peter.
How do you feel about this proposal? It would also be nice to hear the
opinion of other people from the Linux side. Ben? Jesse?
Peter.
+
+static struct drm_i915_mocs_entry broxton_mocs_table[] = {
+ /* {0x00000001, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(ELLC) |
+ MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x00000005, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x00000005, 0x0030} */
+ {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))},
+ /* {0x00000017, 0x0030} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))},
+ /* {0x00000017, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x00000019, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) |
+ MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x00000037, 0x0030} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))},
+ /* {0x00000037, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+ /* {0x0000003b, 0x0010} */
+ {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC_ELLC) |
+ MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) |
+ MOC_PFM(0) | MOCS_SCF(0)),
+ (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))},
+};
+
Wouldn't it be a good idea to have BXT's entries match SKL's for a given
index? The TC, LeCC and LRUM settings you do here arguably don't have
any effect on BXT, L3CC does but it doesn't match SKL's setting for
entries 1 and 2. Is there any reason for this?
As mentioned above this table is auto-generated and matches another tuned
table, simply keeping them the same allows for the tuning to be consistent
across platforms.
Peter.
Other than that looks good.
+/**
+ * get_mocs_settings
+ *
+ * This function will return the values of the MOCS table that needs to
+ * be programmed for the platform. It will return the values that need
+ * to be programmed and if they need to be programmed.
+ *
+ * If the return values is false then the registers do not need
programming.
+ */
+static bool get_mocs_settings(struct drm_device *dev,
+ struct drm_i915_mocs_table *table) {
+ bool result = false;
+
+ if (IS_SKYLAKE(dev)) {
+ table->size = ARRAY_SIZE(skylake_mocs_table);
+ table->table = skylake_mocs_table;
+ result = true;
+ } else if (IS_BROXTON(dev)) {
+ table->size = ARRAY_SIZE(broxton_mocs_table);
+ table->table = broxton_mocs_table;
+ result = true;
+ } else {
+ /* Platform that should have a MOCS table does not */
+ WARN_ON(INTEL_INFO(dev)->gen >= 9);
+ }
+
+ return result;
+}
+
+/**
+ * emit_mocs_control_table() - emit the mocs control table
+ * @ringbuf: DRM device.
+ * @table: The values to program into the control regs.
+ * @reg_base: The base for the Engine that needs to be programmed.
+ *
+ * This function simply emits a MI_LOAD_REGISTER_IMM command for the
+ * given table starting at the given address.
+ *
+ * Return: Nothing.
+ */
+static void emit_mocs_control_table(struct intel_ringbuffer *ringbuf,
+ struct drm_i915_mocs_table *table,
+ u32 reg_base)
+{
+ unsigned int index;
+
+ intel_logical_ring_emit(ringbuf,
+ MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES));
+
+ for (index = 0; index < table->size; index++) {
+ intel_logical_ring_emit(ringbuf, reg_base + (index * 4));
+ intel_logical_ring_emit(ringbuf,
+ table->table[index].control_value);
+ }
+
+ /*
+ * Ok, now set the unused entries to uncached. These entries are
+ * officially undefined and no contact is given for the contents and
+ * settings is given for these entries.
+ *
+ * Entry 0 in the table is uncached - so we are just written that
+ * value to all the used entries.
+ */
+ for (; index < GEN9_NUM_MOCS_ENTRIES; index++) {
+ intel_logical_ring_emit(ringbuf, reg_base + (index * 4));
+ intel_logical_ring_emit(ringbuf,
table->table[0].control_value);
+ }
+
+ intel_logical_ring_emit(ringbuf, MI_NOOP);
+}
+
+/**
+ * emit_mocs_l3cc_table() - emit the mocs control table
+ * @ringbuf: DRM device.
+ * @table: The values to program into the control regs.
+ *
+ * This function simply emits a MI_LOAD_REGISTER_IMM command for the
+ * given table starting at the given address. This register set is
programmed
+ * in pairs.
+ *
+ * Return: Nothing.
+ */
+static void emit_mocs_l3cc_table(struct intel_ringbuffer *ringbuf,
+ struct drm_i915_mocs_table *table) {
+ unsigned int count;
+ unsigned int i;
+ u32 value;
+ u32 filler = (table->table[0].l3cc_value & 0xffff) |
+ ((table->table[0].l3cc_value & 0xffff) << 16);
+
+ intel_logical_ring_emit(ringbuf,
+ MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES / 2));
+
+ for (i = 0, count = 0; i < table->size / 2; i++, count += 2) {
+ value = (table->table[count].l3cc_value & 0xffff) |
+ ((table->table[count + 1].l3cc_value & 0xffff) <<
16);
+
+ intel_logical_ring_emit(ringbuf, GEN9_LNCFCMOCS0 + (i * 4));
+ intel_logical_ring_emit(ringbuf, value);
+ }
+
+ if (table->size & 0x01) {
+ /* Odd table size - 1 left over */
+ value = (table->table[count].l3cc_value & 0xffff) |
+ ((table->table[0].l3cc_value & 0xffff) << 16);
+ } else
+ value = filler;
+
+ /*
+ * Now set the rest of the table to uncached - use entry 0 as this
+ * will be uncached. Leave the last pair as initialised as they are
+ * reserved by the hardware.
+ */
+ for (; i < (GEN9_NUM_MOCS_ENTRIES / 2) - 1; i++) {
+ intel_logical_ring_emit(ringbuf, GEN9_LNCFCMOCS0 + (i * 4));
+ intel_logical_ring_emit(ringbuf, value);
+
+ value = filler;
+ }
+
+ intel_logical_ring_emit(ringbuf, MI_NOOP);
+}
+
+/*
+ * gen9_program_mocs() - program the MOCS register.
+ *
+ * ring: The ring that the programming batch will be run in.
+ * ctx: The intel_context to be used.
+ *
+ * This function will emit a batch buffer with the values required for
+ * programming the MOCS register values for all the currently supported
+ * rings.
+ *
+ * These registers are partially stored in the RCS context, so they are
+ * emitted at the same time so that when a context is created these
registers
+ * are set up. These registers have to be emitted into the start of the
+ * context as setting the ELSP will re-init some of these registers back
+ * to the hw values.
+ *
+ * Return: 0 on success, otherwise the error status.
+ */
+int gen9_program_mocs(struct intel_engine_cs *ring,
+ struct intel_context *ctx)
+{
+ int ret = 0;
+
+ struct drm_i915_mocs_table t;
+ struct drm_device *dev = ring->dev;
+ struct intel_ringbuffer *ringbuf = ctx->engine[ring->id].ringbuf;
+
+ if (get_mocs_settings(dev, &t)) {
+ u32 table_size;
+
+ /*
+ * OK. For each supported ring:
+ * number of mocs entries * 2 dwords for each control_value
+ * plus number of mocs entries /2 dwords for l3cc values.
+ *
+ * Plus 1 for the load command and 1 for the NOOP per ring
+ * and the l3cc programming.
+ */
+ table_size = GEN9_NUM_MOCS_RINGS *
+ ((2 * GEN9_NUM_MOCS_ENTRIES) + 2) +
+ GEN9_NUM_MOCS_ENTRIES + 2;
+ ret = intel_logical_ring_begin(ringbuf, ctx, table_size);
+ if (ret) {
+ DRM_DEBUG("intel_logical_ring_begin failed %d\n",
ret);
+ return ret;
+ }
+
+ /* program the control registers */
+ emit_mocs_control_table(ringbuf, &t, GEN9_GFX_MOCS_0);
+ emit_mocs_control_table(ringbuf, &t, GEN9_MFX0_MOCS_0);
+ emit_mocs_control_table(ringbuf, &t, GEN9_MFX1_MOCS_0);
+ emit_mocs_control_table(ringbuf, &t, GEN9_VEBOX_MOCS_0);
+ emit_mocs_control_table(ringbuf, &t, GEN9_BLT_MOCS_0);
+
+ /* now program the l3cc registers */
+ emit_mocs_l3cc_table(ringbuf, &t);
+
+ intel_logical_ring_advance(ringbuf);
+
+ DRM_DEBUG("MOCS: Table set in Context\n");
+ } else {
+ DRM_DEBUG("MOCS: Table Not supported on platform\n");
+ }
+
+ return ret;
+}
+
diff --git a/drivers/gpu/drm/i915/intel_mocs.h
b/drivers/gpu/drm/i915/intel_mocs.h
new file mode 100644
index 0000000..e2780ce
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_mocs.h
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
a
+ * copy of this software and associated documentation files (the
"Software"),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
next
+ * paragraph) shall be included in all copies or substantial portions of
the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE
+ * SOFTWARE.
+ *
+ * Authors:
+ * Peter Antoine <peter.antoine@xxxxxxxxx>
+ */
+
+#ifndef INTEL_MOCS_H
+#define INTEL_MOCS_H
+
+/**
+ * DOC: Memory Objects Control State (MOCS)
+ *
+ * Motivation:
+ * In previous Gens the MOCS settings was a value that was set by user
land as
+ * part of the batch. In Gen9 this has changed to be a single table (per
ring)
+ * that all batches now reference by index instead of programming the
MOCS
+ * directly.
+ *
+ * The one wrinkle in this is that only PART of the MOCS tables are
included
+ * in context (The GFX_MOCS_0 - GFX_MOCS_64 and the LNCFCMOCS0 -
LNCFCMOCS32
+ * registers). The rest are not (the settings for the other rings).
+ *
+ * This table needs to be set at system start-up because the way the
table
+ * interacts with the contexts and the GmmLib interface.
+ *
+ *
+ * Implementation:
+ *
+ * The table is programmed on a platform basis from a table that is
generated
+ * from the one that has been agreed by the different responsible
parties. This
+ * tables (one per supported platform) is defined in intel_mocs.c and is
+ * programmed in the first batch after the context is loaded (with the
hardware
+ * workarounds). This will then let the usual context handling keep the
MOCS in
+ * step.
+ */
+
+#include <drm/drmP.h>
+#include "i915_drv.h"
+
+int gen9_program_mocs(struct intel_engine_cs *ring,
+ struct intel_context *ctx);
+
+#endif
+
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Peter Antoine (Android Graphics Driver Software Engineer)
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Peter Antoine (Android Graphics Driver Software Engineer)
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Peter Antoine (Android Graphics Driver Software Engineer)
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
--
Peter Antoine (Android Graphics Driver Software Engineer)
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
