Age | Commit message (Collapse) | Author |
|
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]
|
|
Syncs up to
kernel commit ee87697f8bc4da0aea6fe1a825c734fb5e4a5b3b
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Fri May 15 19:43:56 2015 +0100
drm/i915/bxt: Update the Broxton PCI ids
and, importantly, including
kernel commit 1347f5b46a270db1991625f9f57af91e23a4b512
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Tue Mar 17 11:39:27 2015 +0200
drm/i915/bxt: Add BXT PCI id
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When run with -configure, xf86configptr is NULL, so be careful and do
not dereference it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
All CHV devices will be branded as "Intel(r) HD Graphics".
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
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>
|
|
It never was a stable or complete replacement, and now it is
incorporated in Xorg itself!
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>
|
|
Sigh, a late fix was not compile checked against xorg-1.7.
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74162
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Assign gen=8 to the Broadwell PCI IDs, no marketing names are known at
this point in time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
All of the new Atom (Baytrail) products ship with "HD Graphics".
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>
|
|
Highlights of that distribution include xorg-xserver-1.6.5, kernel
3.0.76 and gcc-4.3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Prevents the build failing with i810 if we can not find vgaHW.h
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For the older xserver.
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>
|
|
We want these allocated in ro memory even if the antique API complains.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Move all the UXA backend specifc files into their own subdirectory.
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
These devices are not for retail and so have no marketing names.
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>
|
|
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>
|