Sync with kernel commit ca7a45ba6fb9e7ceca56d10b91db29c2f3451a2e
Author: Michał Winiarski <michal.winiarski@intel.com>
Date: Mon Feb 27 12:22:56 2017 +0100
drm/i915/skl: Add missing SKL ID
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This commit adding all known marketing names for latest gen9 platforms.
v2: On top of simplified generic string names.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Modern Intel (R) platforms with integrated graphics comes with common
names varying the range numbers. So instead of listing all supported
platforms let's start using the generic marketing strings without
the numbers.
And for the specific board we list it's actual marketing name if
available on detection.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Same ids from kernel's
commit 8363e3c3947d0e22955f94a6a87e4f17ce5087b4
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Thu Nov 10 17:23:08 2016 +0200
drm/i915/glk: Add Geminilake PCI IDs
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The probe functions in intel_module.c call intel_open_device() before
calling intel_scrn_create(), but if the later fails because of e.g.
an allocation failure they were not cleaning up the resources
claimed by intel_open_device(), esp. leaking the fd is a problem
because this breaks the fallback to the modesetting driver.
This commit fixes this by adding a intel_close_device() cleanup
function and calling that when intel_scrn_create() fails.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add the Kabylake PCI IDs based on the following kernel patches:
commit d97044b661d0d56b2a2ae9b2b95ab0b359b417dc
Author: Deepak S <deepak.s@intel.com>
Date: Wed Oct 28 12:19:51 2015 -0700
drm/i915/kbl: Add Kabylake PCI ID
commit 8b10c0cf21ec84618d4bf02c73c0543500ece68d
Author: Deepak S <deepak.s@intel.com>
Date: Wed Oct 28 12:21:12 2015 -0700
drm/i915/kbl: Add Kabylake GT4 PCI ID
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
[ickle: Copy across the real i915_pciids.h from the kernel]
As we treat it as a name we should capitilize each word, but we forgot
that rule (sometimes!) for Broadwell.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If you mistype or make the wrong selection in the AccelMethod override,
you can end up with a non-booting system, so lets always try to start
something!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Beware the barbarians at the gate, who invade and steal your ScrnInfoPtr
and its Entity from underneath you. In some configurations, we lose
access to the struct intel_device stored on the Entity after
initialisation, causing havoc. Workaround this by storing the
intel_device that we open in our driverPrivate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
From kernel commit 72bbf0af0c76cbefe9cecbd2ed670b7555e03625
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Wed Feb 13 15:27:37 2013 +0000
drm/i915/skl: Add the Skylake PCI ids
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Old Xorg xf86str.h defines NONE preventing us from using it within an
enum. Use NOACCEL instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Why? I am not sure, but it seems equally as valid as allowing the switch
to uxa/glamor as default. The runtime equivalent is Option "AccelMethod".
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we are constructed as a slaved device, we need to disable all
outputs or else they are not correctly hooked into the master device
upon startup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I assume the intention was to provide a different structure for each of
the gen 2 devices.
This doesn't change anything really.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Even the unknown/reserved ones will stay with HD Graphics.
v2: Add missing names to intel.man and README files as well. (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Copied from kernel commit 7d87a7f709650bde4d7d63117f25ee1c095da5dd
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Apr 9 18:19:04 2014 +0300
srm/i915/chv: Add Cherryview PCI IDs
and also includes non-functional changes from
commit fd3c269f8ff940cc0fbb3b7f7e84c0572f6f759a
Author: Zhao Yakui <yakui.zhao@intel.com>
Date: Thu Apr 17 10:37:35 2014 +0800
drm/i915: Split the BDW device definition to prepare for dual BSD rings on BDW GT3
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The current snapshot is 1.15.99.901, which means that the new feature
will first be available in 1.15.99.902.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the post-modern world, the platform device nodes are handed to a
non-privileged Xserver by systemd/logind. We can then query the core for
our assigned fd rather than try to open the device for ourselves (which
would fail when trying to obtain DRM_MASTER status). A consequence is
that we then do not directly control DRM_MASTER status and must act as a
delegate of systemd.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Split the identification strings between the older integrated graphic
chipsets and the more recent integrated processor graphics. This helps
to emphasis the recent branding and should reduce confusion about which
processors are supported by the driver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only fail to open the device based on the PCI address, if and only if we
do not have sufficient platform information to find the correct system
device.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One extreme fallback path through the xf86PlatformProbe results in a
call without any match data. As we have a device by this point, we can
simply do a reverse match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After some probing mechanisms, we may end up with a valid device without
knowing its PCI address a priori. Having a valid device, we can just
query it for the correct device id, and can safely abort any path that
requires PCI information that we don't have. (Those paths are not valid
under such hosting anyway - if it may be required, we could reconstruct
the address.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the saga of the untested WIP patches for hosted device probing, was
the failure in logic to detect a valid device during probing. Yikes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This allows us to pass along more metadata along with the platform
device in future. Currently we pass the device path, but in a hosted
environment we should be passing along the authorized fd from the host.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Start adding the infrastructure to disable direct hardware access if X
is being run under a system compositor (aka "hosted").
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When printing out the list of supported chipsets, remove the (many
times) repeated names as they are very confusing and obscure the product
name you may be searching for.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For these parts we do not yet known the correct marketing name, so
replace our use of the codename with the generic term.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we recognise the PCI-ID but do not have a marketing name for it, it
means we are deliberating ignoring it - presumably because it is an
engineering sample. In this case, we do not want to print out a warning
into the logfile so replace the "Unknown chipset" with some info
about the future product.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than duplicating the information we already use in the kernel, we
can reuse the pci-id tables so long as we apply a little fuzz.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently we leak the fd should we open the device node and decide that
is not a GEM/KMS kernel driver. The simplest way to perform the cleanup
upon failure is to move the checking for GEM/KMS into the device open
routine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Merge the device open in the main driver with the probing so that we can
open the path explicitly passed in by the PlatformProbe and keep that fd
around for the main driver and so avoid a later search.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we find out more of the final product names for Haswell chipsets, we
need to update the user visible identification strings.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Chris Wilson
Rodrigo Vivi
Ander Conselvan de Oliveira
Hans de Goede
Wayne Boyer
Damien Lespiau
Ville Syrjälä
Rodrigo Vivi