On 9/24/2014 2:57 PM, Jani Nikula wrote:
On Wed, 24 Sep 2014, Gaurav K Singh gaurav.k.si...@intel.com wrote:
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h|1 +
Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver (a standalone drm driver) probes the VED device and
creates a
on vlv, if ipvr is installed, it need be manually unloaded before
i915, otherwise user might run into use-after-free issue.
Signed-off-by: Yao Cheng yao.ch...@intel.com
---
tests/drv_module_reload | 16
1 file changed, 16 insertions(+)
diff --git a/tests/drv_module_reload
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate
BYT: pass/total=19/19-3/19
PNV: pass/total=2/2-1/2
ILK:
Hi,
Some time ago I've raised an issue, that only 32bits of TIMESTAMP are being
exposed to userspace on x86_64, you suggested that we need to stay compatible
with old (and new) userspace and proposed adding a new param that can can be
accessed via getparam.
However, after checking beignet and
On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver
The whole file is only built with CONFIG_COMPAT=y.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_ioc32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_ioc32.c
b/drivers/gpu/drm/i915/i915_ioc32.c
index 2e0613e26251..176de6322e4d
On Wed, Sep 10, 2014 at 06:16:55PM +0300, Imre Deak wrote:
The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw
events so we don't need to care about it either. Only S3 suspend and S4
freeze events are handled. Leave an assert behind to be sure.
Signed-off-by: Imre Deak
On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver
On Tue, Oct 21, 2014 at 02:56:46PM +0300, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 06:16:55PM +0300, Imre Deak wrote:
The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw
events so we don't need to care about it either. Only S3 suspend and S4
freeze events are
On Tue, Oct 21, 2014 at 12:00:30PM +0530, Singh, Gaurav K wrote:
On 9/24/2014 2:57 PM, Jani Nikula wrote:
On Wed, 24 Sep 2014, Gaurav K Singh gaurav.k.si...@intel.com wrote:
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
On Tue, Oct 21, 2014 at 01:32:44AM -0700, shuang...@intel.com wrote:
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform:
On Tue, Oct 21, 2014 at 02:40:37PM +0300, Jani Nikula wrote:
The whole file is only built with CONFIG_COMPAT=y.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -
Hi Dave,
So -rc1 is out the door and the first i915 pull request for 3.19 in your
inbox ;-)
Due to the early drm-next merge window we've already accumulated two
testing cycles instead of the usual one, but somehow there wasn't too much
going on really.
drm-intel-next-2014-10-03:
- first batch
On Tue, Oct 21, 2014 at 2:27 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
There's some simple merge conflicts with current upstream but nothing
serious really, I can push out a merge point if you want to. As usual
-nightly has the solution for you to peek at.
Sorrry I've lied, there's an
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Tuesday, October 21, 2014 1:14 PM
To: He, Shuang
Cc: intel-gfx@lists.freedesktop.org; Daniel, Thomas
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue
On Mon, Oct 20, 2014 at 05:13:45PM +0100, Siluvery, Arun wrote:
On 07/10/2014 15:21, Mika Kuoppala wrote:
If we build the workaround list in ring initialization
and decouple it from the actual writing of values, we
gain the ability to decide where and how we want to apply
the values.
The
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 9 -
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
This will be used in a follow up patch to properly release shared DPLLs
without relying on the shared_dpll field in pipe_config.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +--
drivers/gpu/drm/i915/i915_drv.h
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
It is possible for a mode set to fail if there aren't shared DPLLS that
match the new configuration requirement or other errors in clock
computation. If that step is executed after disabling crtcs, in the
failure case the hardware configuration is changed and needs to be
restored. Doing those
Hi Dave,
drm-intel-next-2014-10-03:
- first batch of skl stage 1 enabling
- fixes from Rodrigo to the PSR, fbc and sink crc code
- kerneldoc for the frontbuffer tracking code, runtime pm code and the basic
interrupt enable/disable functions
- smaller stuff all over
drm-intel-next-2014-09-19:
-
On Thu, Oct 09, 2014 at 09:39:01AM -0700, Todd Previte wrote:
Link training for Displayport can fail in many ways and at multiple different
points
during the training process. Previously, errors were logged but no additional
action
was taken based on them. Consequently, training attempts
On Thu, Oct 09, 2014 at 12:57:43PM -0700, Jesse Barnes wrote:
Some machines (like MBAs) might use a tiled framebuffer but not enable
display swizzling at boot time. We want to preserve that configuration
if possible to prevent a boot time mode set. On IVB+ it shouldn't
affect performance
On Thu, Oct 09, 2014 at 12:57:44PM -0700, Jesse Barnes wrote:
From: Kristian Høgsberg hoegsb...@gmail.com
Like mode_equal but w/o the clock checks. Useful for checking if modes
are close enough to re-use to avoid a boot time mode set for example.
Signed-off-by: Kristian Høgsberg
On Thu, Oct 09, 2014 at 12:57:45PM -0700, Jesse Barnes wrote:
From: Kristian Høgsberg hoegsb...@gmail.com
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
On Fri, Oct 10, 2014 at 06:10:41PM +0300, Jani Nikula wrote:
On Fri, 10 Oct 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, Oct 10, 2014 at 05:53:32PM +0300, Jani Nikula wrote:
Follow-up to
commit dbbe91279511d6a18a521b953a3c139e4787e660
Author: Chris Wilson
On Fri, Oct 17, 2014 at 11:41:12AM -0700, Todd Previte wrote:
V2 changes:
- Moved the intel_dp_enable_port() call out of intel_dp_enable() and placed
it
before the calls to intel_dp_enable() and vlv_wait_port_ready()
- Cleaned up a spacing issues with the code indents
- Amended the
On Mon, Oct 13, 2014 at 12:40:48AM +0800, Chia-I Wu wrote:
On Sun, Oct 12, 2014 at 1:21 AM, Chia-I Wu olva...@gmail.com wrote:
When timeout_ns is negative, it really means to wait indefinitely instead
of
returning immediately. But since userspace can no longer rely on that, I
am
not
On Tue, Oct 14, 2014 at 12:28:39PM +0100, Chris Wilson wrote:
After setting up the copy operations, add a hanging batch. This should
mean that we complete the copy and the compare then races against the
GEM reset. Hopefully, this will catch driver bugs where the target
object is no longer
On Tue, Oct 14, 2014 at 04:12:22PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If the signal helper is active, the usleep() calls return earlier, and
we may end up returning false way before the 10s timeout, failing the
subtests. This currently happens on the
On Fri, Oct 17, 2014 at 02:18:34PM +0300, Ville Syrjälä wrote:
On Wed, Oct 15, 2014 at 02:15:04PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
In its current place, it just segfaults while trying to access the
CRTC structures:
[ 9132.421681] Call Trace:
[
On Wed, Oct 15, 2014 at 02:52:41PM -0700, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
The size of the batch buffer passed to the kernel is significantly
larger than the size of the batch buffer passed to the function. A
proposed optimization as part of the
On Fri, Oct 17, 2014 at 06:42:03PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
For some yet-undiscovered reason, when IPS gets enabled, the pipe CRC
changes. Since hsw_enable_ips() doesn't really guarantees to enable
IPS (it depends on package C-states), we can't
On Fri, Oct 17, 2014 at 05:17:16PM -0400, Dave Jones wrote:
Just hit this while fuzz-testing, (curiously, no graphics
related stuff was happening, X isn't even loaded on that box).
dmar: DRHD: handling fault status reg 2
dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 7ff000
On Fri, Oct 17, 2014 at 08:26:13PM +0300, Mika Kuoppala wrote:
Jani Nikula jani.nik...@linux.intel.com writes:
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Only ports B and C have the power sequencer and backlight controls,
On Thu, Oct 16, 2014 at 12:24:42PM -0700, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
libva uses chained batch buffers in a way that the command parser
can't generally handle. Fortunately, libva doesn't need to write
registers from batch buffers in the way
2014-10-21 13:18 GMT-02:00 Daniel Vetter dan...@ffwll.ch:
On Tue, Oct 14, 2014 at 04:12:22PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If the signal helper is active, the usleep() calls return earlier, and
we may end up returning false way before the 10s timeout,
On Thu, Oct 16, 2014 at 12:39:29PM -0700, Todd Previte wrote:
On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Sometimes we seem to get utter garbage from DPCD reads. The resulting
buffer is filled with the same byte, and the
On Fri, Oct 17, 2014 at 09:08:28AM -0700, Todd Previte wrote:
On 10/17/2014 1:43 AM, Ville Syrjälä wrote:
On Thu, Oct 16, 2014 at 12:38:55PM -0700, Todd Previte wrote:
On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Turning
On Tue, Oct 21, 2014 at 01:52:46PM -0200, Paulo Zanoni wrote:
2014-10-21 13:18 GMT-02:00 Daniel Vetter dan...@ffwll.ch:
On Tue, Oct 14, 2014 at 04:12:22PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If the signal helper is active, the usleep() calls return
On Fri, Oct 17, 2014 at 12:08:38PM +0300, Jani Nikula wrote:
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
I managed to fumble the per spline PCS DW11 register defines in:
commit 9d4f193b077c1973add53e40ff9410a3371900af
On Fri, Oct 17, 2014 at 01:37:11PM +0800, Yu Zhang wrote:
Intel GVT-g (previously known as XenGT), is a complete GPU
virtualization solution with mediated pass-through for 4th
generation Intel Core processors - Haswell platform. This
technology presents a virtual full-fledged GPU to each
On Thu, Oct 16, 2014 at 02:24:27PM +0800, Yu Zhang wrote:
In the virtualized environment, forcewake operations are not
necessory for the driver, because mmio accesses will be trapped
and emulated by the host side, and real forcewake operations are
also done in the host. New mmio write handlers
On Tue, Oct 21, 2014 at 06:16:26PM +0200, Daniel Vetter wrote:
On Fri, Oct 17, 2014 at 01:37:11PM +0800, Yu Zhang wrote:
Intel GVT-g (previously known as XenGT), is a complete GPU
virtualization solution with mediated pass-through for 4th
generation Intel Core processors - Haswell platform.
From: Paulo Zanoni paulo.r.zan...@intel.com
Otherwise, a simple cat to the debugfs file can make the machine use
much more power than needed, and prevent it from runtime suspending.
Related commit:
commit 8452e1d173a16d9812422a2272c4ab0f0ba81057
Author: Mika Kuoppala
From: Paulo Zanoni paulo.r.zan...@intel.com
If we don't enable audio runtime PM, the audio driver won't release
its reference, the refcount won't ever become zero, so we will never
actually runtime suspend. So move this code from pm_rpm.c to
igt_aux.c, so kms_flip - and any other IGT test case
On Mon, Oct 20, 2014 at 01:20:50PM +0300, Imre Deak wrote:
On Fri, 2014-10-17 at 16:01 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
As far as I understand, intel_uncore_early_sanitize() was supposed to
be ran before any register access, but currently
On Tue, Oct 21, 2014 at 02:58:08PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Otherwise, a simple cat to the debugfs file can make the machine use
much more power than needed, and prevent it from runtime suspending.
Related commit:
commit
On Tue, Oct 21, 2014 at 03:01:49PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If we don't enable audio runtime PM, the audio driver won't release
its reference, the refcount won't ever become zero, so we will never
actually runtime suspend. So move this code from
On Thu, Oct 16, 2014 at 04:13:38PM +0100, Michel Thierry wrote:
Otherwise we will get WARNs when we read context status registers and
the machine is suspended.
Testcase: igt/pm_rpm/debugfs-read
Signed-off-by: Michel Thierry michel.thie...@intel.com
Queued for -next, thanks for the patch.
On Wed, Sep 10, 2014 at 06:17:07PM +0300, Imre Deak wrote:
The suspend_late handler saves some registers and powers off the device,
so it doesn't have a big overhead. Calling it at S4 poweroff_late time
makes the power off handling identical to the S3 suspend and S4 freeze
handling, so do this
On Wed, Sep 10, 2014 at 06:16:53PM +0300, Imre Deak wrote:
The first part of the patchset (1-6) fixes an S4 bug on VLV introduced
recently. The rest unifies the various S3/S4 handlers, which are in
practice the same. The only real difference - besides some unused code -
is that during S3
On Wed, Sep 10, 2014 at 06:17:09PM +0300, Imre Deak wrote:
This will hopefully make it easier to navigate the code without the need
to consult the full PM documentation.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 13
Read and verify workaround list before and after the
reset/resume. In addition wait for the gpu before reading
through mmio, so that the rc context gets properly loaded
before we read.
Cc: Arun Siluvery arun.siluv...@linux.intel.com
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
The new struct will be used in a follow up patch to allow a current and
a staged config to exist for the same shared DPLL.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 13
drivers/gpu/drm/i915/i915_drv.h
On Thu, Sep 11, 2014 at 07:15:27AM -0700, Jesse Barnes wrote:
On Thu, 11 Sep 2014 14:59:35 +0300
Imre Deak imre.d...@intel.com wrote:
On Thu, 2014-09-11 at 08:49 +0100, Chris Wilson wrote:
On Wed, Sep 10, 2014 at 06:17:01PM +0300, Imre Deak wrote:
Since correctness wins over optimal
This series changes the mode set sequence so that the clock and PLL
logic that was done in the *_crtc_mode_set() hooks is done before
disabling crtcs. This avoids having to restore the old configuration
in the case of failure, since the hardware was never touched.
Ander Conselvan de Oliveira (8):
Regression from:
commit be4710a541b517b5f8663448bffed5656d59b47b
Author: Thomas Wood thomas.w...@intel.com
Date: Fri Oct 10 11:20:35 2014 +0100
lib: add common min and max macros
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85218
Tested-by: Guo Jinxian jinxianx@intel.com
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
Mika Kuoppala mika.kuopp...@linux.intel.com writes:
If we build the workaround list in ring initialization
and decouple it from the actual writing of values, we
gain the ability to decide where and how we want to apply
the values.
The advantage of this will become more clear when
we need
Tested-by: Wayne Boyer wayne.bo...@intel.com
Before this patch I was getting pipe underrun errors on pipe A and pipe C
when
running various workloads. Shortly after the errors, the screens would go
black
and could not be recovered without rebooting.
With this patch I don't get the underrun
On 21 October 2014 23:38, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi Dave,
drm-intel-next-2014-10-03:
- first batch of skl stage 1 enabling
- fixes from Rodrigo to the PSR, fbc and sink crc code
- kerneldoc for the frontbuffer tracking code, runtime pm code and the basic
interrupt
Now that shared DPLLs configuration is staged, there's no need to track
the current ones in the new pipe_config since those are released before
making the new pipe_config effective.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
On Tue, 2014-10-21 at 15:41 +0300, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 06:17:00PM +0300, Imre Deak wrote:
If the device is suspended already through the switcheroo interface we
shouldn't suspend it again. We have the corresponding check for S3
suspend already, add it for S4 freeze
On Tue, Oct 21, 2014 at 04:08:21PM +0300, Imre Deak wrote:
On Tue, 2014-10-21 at 15:41 +0300, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 06:17:00PM +0300, Imre Deak wrote:
If the device is suspended already through the switcheroo interface we
shouldn't suspend it again. We have the
There's no users left after the conversion to calculate clocks before
disabling crtcs during mode set.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/intel_display.c | 11 ---
2
-Original Message-
From: Daniel, Thomas
Sent: Tuesday, October 21, 2014 8:46 PM
To: Daniel Vetter; He, Shuang
Cc: intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue items
in
-Original Message-
From: Daniel Vetter
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, October 21, 2014 4:29 AM
To: He, Shuang
Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make
Aside: We don't handle hpd for port A anyway, so for most panels this
doesn't matter all that much. Or we'd have piles more bug reports I think.
https://bugzilla.redhat.com/show_bug.cgi?id=1118448
probably like this.
Dave.
___
Intel-gfx mailing
From: Dave Airlie airl...@redhat.com
These two didn't get documented properly, do so.
Pointed out by Daniel.
Signed-off-by: Dave Airlie airl...@redhat.com
---
Documentation/DocBook/drm.tmpl | 9 -
drivers/gpu/drm/drm_crtc.c | 10 ++
2 files changed, 18 insertions(+), 1
Don't you need a kref_get_unless_zero here since we only destroy the idr
entry after the refcount dropped to zero? Or is there some magic thing
that prevents this like another mutex (in which case some mutex assert in
get/put would be good)?
This does all happen under mode_config.mutex but I
From: Dave Airlie airl...@redhat.com
This adds fbdev/con support for tiled monitors, so that we
only set a mode on the correct half of the monitor, or
span the two halves if needed.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fb_helper.c| 122
From: Dave Airlie airl...@redhat.com
This creates a tile group from DisplayID block, and
stores the pieces of parsed info from the DisplayID block
into the connector.
v2: add missing signoff, add new connector bits to docs.
Signed-off-by: Dave Airlie airl...@redhat.com
---
This is just a second round of the previous series, cleaned up the
problems pointed out (except property hotplug - bigger problem),
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Dave Airlie airl...@redhat.com
Logical ports are never going to have EDID changes,
they are used for the internal ports on MST monitors.
We cache the EDIDs from these to save time at MST probe.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_dp_mst_topology.c | 20
From: Dave Airlie airl...@redhat.com
A tile group is an identifier shared by a single monitor,
DisplayID topology has 8 bytes we can use for this, just
use those for now until something else comes up in the
future. We assign these to an idr and use the idr to
tell userspace what connectors are in
From: Dave Airlie airl...@redhat.com
These are just taken from the DisplayID v1.3 spec, and the
DDC spec.
v2: use __packed (Jani)
Signed-off-by: Dave Airlie airl...@redhat.com
---
include/drm/drm_displayid.h | 76 +
include/drm/drm_edid.h | 2
From: Dave Airlie airl...@redhat.com
This takes the tiling info from the connector and
exposes it to userspace, as a blob object in a
connector property.
The contents of the blob is ABI.
v2: add property + function documentation.
Signed-off-by: Dave Airlie airl...@redhat.com
---
79 matches
Mail list logo
