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>
Start filling in the names for the parts that have been announced, the
Iris branded Haswell GT3 parts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As Chris mentioned there is a tendency for us to find out more
PCI IDs only when users report. So let's add all new reserved Haswell IDs.
I didn't have better names for this reserved ids and didn't want to use rsvd1
and rsvd2 groups, so I decided to use "B" and "E" that stands for the last
id digit.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
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>
There is a tendency for a product to ship based on a 'reserved' PCI-ID
prior to us being notified about it. In other words, the first we find
out about such a product is when customers start complaining about their
shiny new hardware not being supported...
References: https://bugs.freedesktop.org/show_bug.cgi?id=63701
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Do not rely on a fully populated set of CRTCs, but merely note that the
GETRESOURCES ioctl returns an error if KMS is not enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the kernel has the module, but the KMS module option is not enabled,
we cannot function. So after checking to see if the i915.ko is bound,
then querying whether it provides any KMS resources. If it has no CRTCs
attached, then we need to failover to the VESA/fbdev drivers. Note that
this should have been detected by drmCheckModesettingSupported()
References: https://bugs.freedesktop.org/show_bug.cgi?id=60987
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Damien Lespiau
Rodrigo Vivi
Hans de Goede
Rodrigo Vivi