| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Cc: 17.1 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
Cc: 17.1 <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Christian König <[email protected]>
Cc: 13.0 17.0 <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Cc: 17.0 <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
| |
While here, use the spacing defined in Ark.
https://ark.intel.com/products/codename/82879/Kaby-Lake
Reviewed-by: Jason Ekstrand <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Junwei Zhang <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
v2: s/bdw/gen; Add the 2x6 config
v3: Add min_ds_entries
Cc: "13.0" <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
I have some OCD...
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
| |
We got a couple for products that exist on ark.intel.com, so let's just
put them in now.
Signed-off-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Reviewed-by: Dhinakaran Pandiyan <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
|
|
|
|
|
|
| |
The spec has been updated adding new PCI IDs.
Reviewed-by: Dhinakaran Pandiyan <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
|
|
|
|
| |
Cc: [email protected]
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Sonny Jiang <[email protected]>
Reviewed-by: Alex Deucher <[email protected]> (Polaris10)
Reviewed-by: Michel Dänzer <[email protected]> (Polaris11)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Braswell" is a Cherryview based *thing*. It unfortunately requires extra
information to determine its marketing name. Unlike all previous products, and
hopefully all future ones, there is no unique 1:1 mapping of PCI device ID to
brand string.
I put up a fight about adding any complexity to our GL renderer string code for
a very long time. However, a wise man made a comment to me that I couldn't argue
with: if a user installs Windows on their hardware, the brand string should be
the same as what we display in Linux. The Windows driver apparently does this
check, so we should too.
Note that I did manage to find a good use for this info anyway in the compute
shader thread counts.
v2: memcpy instead of strncpy, and some minor changes (Matt)
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Jordan Justen <[email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the virtio-gpu PCI ID for virtio 1.0 (according to the
specification, "the PCI Device ID is calculated by adding 0x1040 to the
Virtio Device ID")
Support for virtio 1.0 was added in qemu 2.4 (same time virtio-gpu
landed).
Cc: "11.1 11.2" <[email protected]>
Signed-off-by: Marc-André Lureau <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Also adds some of the Iris/Pro parts which we previously didn't have named.
v2: 0x192d is gt3, not gt4
Adding some 'e' tags for eDRAM parts
Signed-off-by: Ben Widawsky <[email protected]>
Acked-by: Michał Winiarski <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Iris part is left unbranded because we did not have these with original SKL.
v2: 0x192d is gt3, not gt4
v3: Forgot to update the temporary brand string when I did v2.
Cc: "11.0 11.1" <[email protected]
Signed-off-by: Ben Widawsky <[email protected]>
Acked-by: Michał Winiarski <[email protected]>
|
|
|
|
|
|
|
| |
Add the virtio-gpu PCI ID so the driver probing works.
Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add PCI IDs for the Intel Kabylake platforms. The IDs are taken
directly from the Linux kernel patches, which are under review:
http://lists.freedesktop.org/archives/intel-gfx/2015-October/078967.html
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=kbl-upstream-v2
The Kabylake PCI IDs taken from the kernel are rearranged to be in order
of GT type, then PCI ID.
Please note that if this patch is backported, the following fixes will
need to be added before this patch:
commit 28ed1e08e8ba98e "i965/skl: Remove early platform support"
commit c1e38ad37042b0e "i965/skl: Use larger URB size where available."
Thanks to Ben for fixing a bug around setting urb.size, and being
patient with my questions about what the various fields mean.
Signed-off-by: Sarah Sharp <[email protected]>
Suggested-by: Ben Widawsky <[email protected]>
Tested-by: Rodrigo Vivi <[email protected]> (KBL-GT2)
Cc: "11.1" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few new PCI ids are added here, and one is removed (0x190B) because it no
longer seems to exist anywhere.
v2-4:
Only use ascii characters (Ilia)
0x1921 is no longer marked as f
Reviewed-by: Jordan Justen <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like other gen8+ hardware, the hardware automatically scales up thread counts.
We must be careful about the URB sizes since GT4 adds another slice.
One of the existing PCI IDs is actually mislabeled as GT3. Arguably this is a
real bug since the URB size will be wrong. Because this patch is simply meant to
add the missing IDs, that will be fixed in a later patch.
v2: No longer relevant.
v3: Update the wm thread count to support GT4. The WM thread count is used to
determine the maximum scratch space required. Currently the code always
allocates the maximum amount even though lower GT SKUs require less. The formula
is threads_per_psd * subslices_per_slice * slices
Cc: [email protected]
Reviewed-by: Jordan Justen <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Samuel Li <[email protected]>
Cc: [email protected]
|
| |
|
|
|
|
|
|
|
| |
Reviewed-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The thread counts and URB information are all speculative numbers that were
based on some CHV numbers at the time.
v2:
Originally this patch had PCI IDs. I've moved that to a new patch at the end of
the series.
Remove is_cherryview hack.
Add PCI ids. These match the ones defined in the kernel. The only one tested by
us is 0x0a84.
Capitalize the hex string (Mark)
Signed-off-by: Ben Widawsky <[email protected]>
Tested-by: "Lecluse, Philippe" <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
| |
All CHV devices will be branded as "Intel(r) HD Graphics".
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
|
|
| |
a001 and a011 are pineview chips. Say so.
Reviewed-by: Matt Turner <[email protected]>
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
| |
Signed-off-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
|
|
|
| |
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intel would like us to include the marketing names. Developers
additionally want "Broadwell GT1/2/3" because it makes it easier
to identify what hardware users have when they request assistance
or report issues.
Including both makes it easy for everyone to map between the names.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Cc: "10.2" <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Samuel Li <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
Based on a patch by Ville Syrjälä.
As usual, these are placeholder values; actual values will come later.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
There are a lot of different pci ids supported by nouveau, and more are
added all the time. The relevant distinguisher between drivers is the
chipset id.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Cc: "10.1" <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This puts the PCI IDs in place so it's easy to enable support. However,
it doesn't actually enable support since it's very preliminary still,
and a few crucial pieces (such as BLORP) are still missing.
Signed-off-by: Kenneth Graunke <[email protected]>
Acked-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per original approach by Rob, each user of the loader lib should include
loader.h and the pci_id_driver_map.h header will be used exclusively by the
loader.
Add back the include guard __IS_LOADER and remove no longer needed include
folder in the scons build.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the various window system integration layers duplicate roughly the
same code for figuring out device and driver name, pci-id's, etc. Which
is sad. So extract it out into a loader util lib.
v2 (Emil)
* Separate the introduction of libloader from the code de-duplication.
* Strip out non-pci devices support.
* Add scons + Android build system support.
* Add VISIBILITY_CFLAGS to avoid exporting the loader funcs.
v3 (Emil)
* PIPE_OS_ANDROID is undefined at this scope, use ANDROID
* Make sure we define _EGL_NO_DRM when building only swrast
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
0x9649 is sumo2, not sumo.
Signed-off-by: Alex Deucher <[email protected]>
CC: "9.2" "10.0" <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
| |
I removed this a while ago, since we never used it, but I'm finally
resurrecting the idea in the next commits.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Nothing uses the #define name, and it's not terribly useful - the
numerical ID serves the same purpose. The only thing we could really do
with it is generate slightly prettier preprocessed code. But who looks
at that?
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Signed-off-by: Alex Deucher <[email protected]>
|