No functional change. Just organizing the code
so it gets clear for future platforms.
Paulo deserves credits becuase he was the one
that just noticed this IS_9XX was in the wrong position
after CNL patches got introduced.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
As far as I understand, IS_9XX should return true for it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Add kernel commit id for reference.
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")
v2: Remove PCI IDs for SKU not mentioned in spec.
v3: Add kernel commit id for reference.
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Add the PCI IDs for U SKU IN CFL by following the spec.
v2: Update IDs
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Add the PCI IDs for H SKU IN CFL by following the spec.
v2: Update IDs
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Add the PCI IDs for S SKU IN CFL by following the spec.
v2: Update IDs.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This is unusual. Usually IDs listed on early stages of platform
definition are kept there as reserved for later use.
However these IDs here are not listed anymore in any of steppings
and devices IDs tables for Kabylake on configurations overview
section of BSpec.
So it is better removing them before they become used in any
other future platform.
v2: Rebase.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The spec has been updated adding new PCI IDs.
v2: Avoid using "H" instead of HALO to keep names uniform - DK.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
These IDs were already part of the kernel since:
kernel commit 985dd4360fdf2533fe48a33a4a2094f2e4718dc0
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Jan 28 16:04:12 2016 +0200
drm/i915/bxt: update list of PCIIDs
Cc: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Also, following kernel definition Kabylake is skylake.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This removes ones which aren't used, and adds some new ones. I kept the original
names where possible.
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
v2: Add more PCI IDs (Michael H. Nguyen)
v3: Synchronize one more with the kernel PCI IDs (Damien)
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Michael H. Nguyen <michael.h.nguyen@intel.com>
At DDX commit Chris mentioned the tendency we have of finding out more
PCI IDs only when users report. So Let's add all new reserved Haswell IDs.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=63701
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
When publishing first HSW ids we weren't allowed to use "GT3" codname.
But this is the correct codname and Mesa is using it already.
So to avoid people getting confused why in Mesa it is called GT3 and here
it is called GT2_PLUS let's fix this name in a standard and correct way.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The second digit was off by one, which meant we accidentally treated
GT(n) as GT(n-1). This also meant no support for GT1 at all.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Protect the macro argument evaluations with parens.
This is already touching most lines, so while at it, fix up all white
space to uniform style throughout the file.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Intel GPU Tools is newer and arguably better. This change doesn't
completely merge the files because it's a bit simpler if we move the
I9XX macro over to Intel GPU Tools, and don't move over a few macros
from IGT that libdrm doesn't care about.
It has been discussed, and would seem even easier if Intel GPU Tools
simply used the libdrm header files. Whether or not we move to that,
this should help that effort.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
These will be used by intel_decode.c, and were taken from intel-gpu-tools.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
This will make these macros reusable from intel_decode.c, which
doesn't have a bufmgr_gem context, without faking the struct. We
should generally only be using these macros from bufmgr_gem context
setup anyway.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
This patch to libdrm adds support for the new execbuf2 ioctl. If
detected, it will be used instead of the old ioctl. By using the new
drm_intel_bufmgr_gem_enable_fenced_relocs(), you can indicate that any
time a fence register is actually required for a relocation target you
will call drm_intel_bo_emit_reloc_fence instead of
drm_intel_bo_emit_reloc, which will reduce fence register pressure.
Signed-off-by: Eric Anholt <eric@anholt.net>
Anuj Phogat
Rodrigo Vivi
Paulo Zanoni
Anusha Srivatsa
Ben Widawsky
Michał Winiarski
Ben Widawsky
Damien Lespiau
Ville Syrjälä
Rodrigo Vivi
Kenneth Graunke
Jesse Barnes
Eugeni Dodonov
Eric Anholt
Kristian Høgsberg