| Age | Commit message (Collapse) | Author |
|---|
|
On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.
In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.
Increase the WM memory latency values to at least 1.2 usec on SNB.
Hopefully this won't have a significant effect on power consumption.
v2: Increase the latency values regardless of the pixel clock
Cc: Robert N <crshman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254
Tested-by: Robert Navarro <crshman@gmail.com>
Tested-by: Vitaly Minko <vitaly.minko@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.
To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
Reported-by: Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This matches the algorithm used by earlier kernels when selecting the
mode for the fbcon. And only if there is no modes at all, do we fall
back to using the BIOS configuration. Seamless transition is still
preserved (from the BIOS configuration to ours) so long as the BIOS has
also chosen what we hope is the native configuration.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[Jani: applied Chris' "Please imagine that I wrote this correctly."]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
There are certain BDW high res eDP machines that regressed due to
commit 38aecea0ccbb909d635619cba22f1891e589b434
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Mar 3 11:18:10 2014 +0100
drm/i915: reverse dp link param selection, prefer fast over wide again
The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
2.7 Gbps on the affected machines. Link training succeeded for both, but
the screen remained blank with the former config. Further investigation
showed that 4 lanes at 5.4 Gbps worked also.
The root cause for the blank screen using 2 lanes remains unknown, but
apparently the driver for a certain other operating system by default
uses the max available lanes. Follow suit on Broadwell eDP, for at least
until we figure out what is going on.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Media force wake get hangs the machine when the system is booted without
displays attached. The assumption is that (at least some versions of)
the firmware has skipped some initialization in that case.
Empirical evidence suggests we need to reset the media force wake
request register in addition to the render one to avoid hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895
Reported-by: Imre Deak <imre.deak@intel.com>
Reported-by: Darren Hart <dvhart@linux.intel.com>
Tested-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
When linking the i2c sysfs file into the connector's directory
pass directory and link target in the right order.
This code was introduced with:
commit 931c1c26983b4f84e33b78579fc8d57e4a14c6b4
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Feb 11 17:12:51 2014 +0200
drm/i915: sdvo: add i2c sysfs symlink to the connector's directory
This is the same what we do for DP connectors, so make things more
consistent.
Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Most likely the minimums for both should be enough for enabling the
native resolution on the eDP, and we'll end up using the predetermined
optimal link config for the panel.
v2: Add debug prints.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73539
Tested-by: Markus Blank-Burian <burian@muenster.de>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Use defines, do not set anything if VBT has values unknown to us.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while selecting the
max lane count.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Because the docs say ULX doesn't support it on HSW.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This regression was introduced in
commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Fri Dec 6 14:11:14 2013 -0800
drm/i915: Reorganize intel_enable_ppgtt
As the i915.enable_ppgtt is read-only it cannot be changed after the
module is loaded and so we can perform an early sanitization of the
values.
v2:
- Add comment and pimp commit message (Chris)
- Use the param consistently (Jani)
v3:
- Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to
gtt_init. Fixes boot hangs on pre-gen6.
- Add a debug output for the sanitize ppgtt mode.
References: https://lkml.org/lkml/2014/4/17/599
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916
Cc: Alessandro Suardi <alessandro.suardi@gmail.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector->encoder->base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector->encoder).
If intel_connector_break_all_links() is called from intel_sanitize_crtc()
we may break the crtc connection of an encoder thru an inactive connector
in which case intel_connector_break_all_links() will not be called again
for the active connector if this happens to come later in the list due to:
if (connector->encoder->base.crtc != &crtc->base)
continue;
in intel_sanitize_crtc().
This will however leave the drm_connector->encoder linkage for this
active connector in place. Subsequently this will cause multiple
warnings in intel_connector_check_state() to trigger and the driver
will eventually die in drm_encoder_crtc_ok() (because of crtc == NULL).
To avoid this remove intel_connector_break_all_links() and move its
code to its two calling functions: intel_sanitize_crtc() and
intel_sanitize_encoder().
This allows to implement the link breaking more flexibly matching
the surrounding code: ie. in intel_sanitize_crtc() we can break the
crtc link separatly after the links to the encoders have been
broken which avoids above problem.
This regression has been introduced in:
commit 24929352481f085c5f85d4d4cbc919ddf106d381
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jul 2 20:28:59 2012 +0200
drm/i915: read out the modeset hw state at load and resume time
so goes back to the very beginning of the modeset rework.
v2: This patch takes care of the concernes voiced by Chris Wilson
and Daniel Vetter that only breaking links if the drm_connector
is linked to an encoder may miss some links.
v3: move all encoder handling to encoder loop as suggested by
Daniel Vetter.
Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Date: Wed Mar 12 16:39:40 2014 +0530
drm/i915: disable rings before HW status page setup
we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.
Reference: http://lkml.kernel.org/r/20140423202248.GA3621@amd.pavel.ucw.cz
Tested-by: Pavel Machek <pavel@ucw.cz>
Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.
So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.
This WARN has been introduced in
commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b
Author: Egbert Eich <eich@suse.de>
Date: Fri Jul 26 14:14:24 2013 +0200
drm/i915: Add messages useful for HPD storm detection debugging (v2)
before that we silently handled the hpd event and so partially
defeated the storm detection.
v2: Pimp commit message (Jani)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: bitlord <bitlord0xff@gmail.com>
Reported-by: bitlord <bitlord0xff@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:
commit 93a25a9e2d67765c3092bfaac9b855d95e39df97
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 6 09:40:43 2014 +0100
drm/i915: Disable full ppgtt by default
By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
means full, all other values are reserved.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:51 2014 -0800
drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
v2: Add a debug message to track the discard of the BIOS fb.
v3: Ville pointed out the difference between ref/unref
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77767
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.
The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.
This regression was introduced in
commit e9cb81a22841908b1c075156b409a538d09c8466
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Nov 21 13:47:23 2013 -0200
drm/i915: get a runtime PM reference when the panel VDD is on
v2: - Rebase
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the gmch_pfit state to
it.
3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.
-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
In commit
commit 6375b768a9850b6154478993e5fb566fa4614a9c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Mar 3 11:33:36 2014 +0200
drm/i915: Reject >165MHz modes w/ DVI monitors
the driver started to filter out display modes which exceed the
single-link DVI 165Mz dotclock limits when the monitor doesn't report
itself as being HDMI compliant. The intent was to filter out all
EDID derived modes that require dual-link DVI to operate since we
don't support dual-link.
However the patch went a bit too far and also causes the driver to reject
such modes even when specified by the user. Normally we don't check the
sink limitations when setting a mode from the user. This allows the user
to specify any mode whether the sink reports to support it or not. This
can be useful since often the sinks support more modes than they report
in the EDID.
So relax the checks a bit, and apply the single-link DVI dotclock limit
only when filtering the mode list, and ignore the limit when setting
a user specified mode.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961
Tested-by: Nicholas Vinson <nvinson@comcast.net>
Cc: stable@vger.kernel.org [3.14]
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
git://people.freedesktop.org/~deathsimple/linux into drm-next
Some i2c fixes over DisplayPort.
* 'drm-next-3.15-wip' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: Improve vramlimit module param documentation
drm/radeon: fix audio pin counts for DCE6+ (v2)
drm/radeon/dp: switch to the common i2c over aux code
drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/i915: support address only i2c-over-aux transactions
drm/tegra: dp: Support address-only I2C-over-AUX transactions
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
Some fixes from Intel.
* tag 'drm-intel-fixes-2014-04-11' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Always use kref tracking for all contexts.
drm/i915: do not setup backlight if not available according to VBT
drm/i915: check VBT for supported backlight type
drm/i915: Disable self-refresh for untiled fbs on i915gm
drm/mm: Don't WARN if drm_mm_reserve_node
|
|
If we always initialize kref for the context, even if we are using fake
contexts for hangstats when there is no hw support, we can forgo the
dance to dereference the ctx->obj and inspect whether we are permitted
to use kref inside i915_gem_context_reference() and _unreference().
My ulterior motive here is to improve the debugging of a use-after-free
of ctx->obj. This patch avoids the dereference here and instead forces
the assertion checks associated with kref.
v2: Refactor the fake contexts to being even more like the real
contexts, so that there is much less duplicated and special case code.
v3: Tweaks.
v4: Tweaks, minor.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76671
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: lu hua <huax.lu@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[Jani: tiny change to backport to drm-intel-fixes.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Some machines use an external EC for controlling the backlight. Info
about this is present in the VBT. Do not setup native backlight control
if no PWM backlight is available or supported according to VBT. The
acpi_backlight interface appears to work for the EC control.
In most cases there has been no harm done, but it looks like there are
machines out there that have both an EC and our PWM line connected to
the same wire. This, obviously, does not end well.
This should fix the regression caused by
commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Nov 14 12:14:29 2013 +0200
drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
AFAICT the quirk removed by the above commit effectively resulted in
i915 not driving the backlight PWM output, thus not messing things up.
Additionally this should fix the regression caused by
commit fbc9fe1b4f222a7c575e3bd8e9defe59c6190a04
Author: Aaron Lu <aaron.lu@intel.com>
Date: Fri Oct 11 21:27:45 2013 +0800
ACPI / video: Do not register backlight if win8 and native interface exists
which left some machines without a functioning backlight interface.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76276
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=62281
CC: Aaron Lu <aaron.lu@intel.com>
CC: Eric Griffith <EGriffith92@gmail.com>
CC: Kent Baxley <kent.baxley@canonical.com>
Tested-by: Kamal Mostafa <kamal@canonical.com>
Tested-by: Martin <bugs@mrvanes.com>
Tested-by: jrg.otte@gmail.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The only supported types are none and PWM. Other values are obsolete or
reserved, don't add them.
Tested-by: Kamal Mostafa <kamal@canonical.com>
Tested-by: Martin <bugs@mrvanes.com>
Tested-by: jrg.otte@gmail.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Apparently it doesn't work. X-tiled self-refresh works flawlessly
otoh. Apparently X still works correctly with linear framebuffers, so
might just be an issue with the initial modeset. It's unclear whether
this just borked wm setup from our side or a hw restriction, but just
disabling gets things going.
Note that this regression was only brought to light with
commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jan 10 14:06:47 2014 +0200
drm/i915: Fix 915GM self-refresh enable/disable
before that self-refresh for i915GM didn't work at all.
Kudos to Ville for spotting a little bug in the original patch I've
attached to the bug.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103
Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: rebase on top of drm-next with primary plane support.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Pull drm updates from Dave Airlie:
"Highlights:
- drm:
Generic display port aux features, primary plane support, drm
master management fixes, logging cleanups, enforced locking checks
(instead of docs), documentation improvements, minor number
handling cleanup, pseudofs for shared inodes.
- ttm:
add ability to allocate from both ends
- i915:
broadwell features, power domain and runtime pm, per-process
address space infrastructure (not enabled)
- msm:
power management, hdmi audio support
- nouveau:
ongoing GPU fault recovery, initial maxwell support, random fixes
- exynos:
refactored driver to clean up a lot of abstraction, DP support
moved into drm, LVDS bridge support added, parallel panel support
- gma500:
SGX MMU support, SGX irq handling, asle irq work fixes
- radeon:
video engine bringup, ring handling fixes, use dp aux helpers
- vmwgfx:
add rendernode support"
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (849 commits)
DRM: armada: fix corruption while loading cursors
drm/dp_helper: don't return EPROTO for defers (v2)
drm/bridge: export ptn3460_init function
drm/exynos: remove MODULE_DEVICE_TABLE definitions
ARM: dts: exynos4412-trats2: enable exynos/fimd node
ARM: dts: exynos4210-trats: enable exynos/fimd node
ARM: dts: exynos4412-trats2: add panel node
ARM: dts: exynos4210-trats: add panel node
ARM: dts: exynos4: add MIPI DSI Master node
drm/panel: add S6E8AA0 driver
ARM: dts: exynos4210-universal_c210: add proper panel node
drm/panel: add ld9040 driver
panel/ld9040: add DT bindings
panel/s6e8aa0: add DT bindings
drm/exynos: add DSIM driver
exynos/dsim: add DT bindings
drm/exynos: disallow fbdev initialization if no device is connected
drm/mipi_dsi: create dsi devices only for nodes with reg property
drm/mipi_dsi: add flags to DSI messages
Skip intel_crt_init for Dell XPS 8700
...
|
|
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
Merge window -fixes pull request as usual. Well, I did sneak in Jani's
drm_i915_private_t typedef removal, need to have fun with a big sed job
too ;-)
Otherwise:
- hdmi interlaced fixes (Jesse&Ville)
- pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but
not cc: stable since only really relevant for igt runs)
- large cursor wm fixes (Chris)
- fix gpu turbo boost/throttle again, was getting stuck due to vlv rps
patches (Chris+Imre)
- fix runtime pm fallout (Paulo)
- bios framebuffer inherit fix (Chris)
- a few smaller things
* tag 'drm-intel-fixes-2014-04-04' of git://anongit.freedesktop.org/drm-intel: (196 commits)
Skip intel_crt_init for Dell XPS 8700
drm/i915: vlv: fix RPS interrupt mask setting
Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"
drm/i915: move power domain init earlier during system resume
drm/i915: Fix the computation of required fb size for pipe
drm/i915: don't get/put runtime PM at the debugfs forcewake file
drm/i915: fix WARNs when reading DDI state while suspended
drm/i915: don't read cursor registers on powered down pipes
drm/i915: get runtime PM at i915_display_info
drm/i915: don't read pp_ctrl_reg if we're suspended
drm/i915: get runtime PM at i915_reg_read_ioctl
drm/i915: don't schedule force_wake_timer at gen6_read
drm/i915: vlv: reserve the GT power context only once during driver init
drm/i915: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/display: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_t
...
|
|
The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port.
The call intel_crt_init freeze the machine, so skip such call.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559
Signed-off-by: Giacomo Comes <comes at naic.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This typo may lead to missed RPS interrupts and as a result a too
low or too high frequency for the current workload. The interrupt mask
will be set properly at a subsequent GPU idle event, but can get
corrupted again at the next RPS up/down event.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
As per the inputs provided by hardware team we still use DDR
Rates as 0,1=800, 2=1066, 3=1333.
With this change, Turbo freqs used on current machines matches.
This reverts commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6.
commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Mon Nov 4 16:07:00 2013 -0800
drm/i915/vlv: fixup DDR freq detection per Punit spec
v2: Add reference to previous commit which changed this. (Daniel)
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
During resume the intel hda audio driver depends on the i915 driver
reinitializing the audio power domain. Since the order of calling the
i915 resume handler wrt. that of the audio driver is not guaranteed,
move the power domain reinitialization step to the resume_early
handler. This is guaranteed to run before the resume handler of any
other driver.
The power domain initialization in turn requires us to enable the i915
pci device first, so move that part earlier too.
Accordingly disabling of the i915 pci device should happen after the
audio suspend handler ran. So move the disabling later from the i915
resume handler to the resume_late handler.
v2:
- move intel_uncore_sanitize/early_sanitize earlier too, so they don't
get reordered wrt. intel_power_domains_init_hw()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org
[danvet: Add cc: stable and loud comments that this is just a hack.]
[danvet: Fix "Should it be static?" sparse warning reported by Wu
Fengguang's kbuilder.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.
For other drivers, allocating small bos from one end and large ones
from the other helps improve the quality of fragmentation.
Based on drm_mm work by Chris Wilson.
v3: Changed to use a TTM placement flag
v2: Updated kerneldoc
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Christian König <deathsimple@vodafone.de>
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: David Airlie <airlied@redhat.com>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
- Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
flicker for fastbooting.
- More flexible cloning for hdmi (Ville).
- Some PPGTT fixes from Ben.
- Ring init fixes from Naresh Kumar.
- set_cache_level regression fixes for the vma conversion from Ville&Chris.
- Conversion to the new dp aux helpers (Jani).
- Unification of runtime pm with pc8 support from Paulo, prep work for runtime
pm on other platforms than HSW.
- Larger cursor sizes (Sagar Kamble).
- Piles of improvements and fixes all over, as usual.
* tag 'drm-intel-next-2014-03-21' of git://anongit.freedesktop.org/drm-intel: (75 commits)
drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64
drm/i915/sdvo: fix questionable return value check
drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
drm/i915: Print how many objects are shared in per-process stats
drm/i915: Per-process stats work better when evaluated per-process
drm/i915: remove rps local variables
drm/i915: Remove extraneous MMIO for RPS
drm/i915: Rename and comment all the RPS *stuff*
drm/i915: Store the HW min frequency as min_freq
drm/i915: Fix coding style for RPS
drm/i915: Reorganize the overclock code
drm/i915: init pm.suspended earlier
drm/i915: update the PC8 and runtime PM documentation
drm/i915: rename __hsw_do_{en, dis}able_pc8
drm/i915: kill struct i915_package_c8
drm/i915: move pc8.irqs_disabled to pm.irqs_disabled
drm/i915: remove dev_priv->pc8.enabled
drm/i915: don't get/put PC8 when getting/putting power wells
drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
|
|
The computation of required framebuffer size in
commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:51 2014 -0800
drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
is too optimistic, and would rely on the invariant fb being
reconstructed to exactly fit each pipe (and probably ignore hardware
limits). Instead, we want to compute the upper bound on what the display
engine will access and ensure that is within the inherited framebuffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC. Replace all references to the CRTC fb with the
primary plane's fb.
This patch was generated by the Coccinelle semantic patching tool using
the following rules:
@@ struct drm_crtc C; @@
- (C).fb
+ C.primary->fb
@@ struct drm_crtc *C; @@
- (C)->fb
+ C->primary->fb
v3: Generate patch via coccinelle. Actual removal of crtc->fb has been
moved to a subsequent patch.
v2: Fixup several lingering crtc->fb instances that were missed in the
first patch iteration. [Rob Clark]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
Ensure that existing driver loops over all planes do not change behavior
when we begin adding new types of planes (primary and cursor) to the DRM
plane list in future patches.
v2: Switch to using drm_for_each_legacy_plane()
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
Because gen6_gt_force_wake_{get,put} should already be responsible for
getting/putting runtime PM. If we keep these calls, debugfs will not
be testing the get/put calls of the forcewake functions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
If runtime PM is enabled and we unset all modes, we will runtime
suspend after __intel_set_mode() , then function
intel_modeset_check_state() will try to read the HW state while it is
suspended and trigger lots of WARNs because it shouldn't be reading
registers.
So on this patch we make intel_ddi_connector_get_hw_state() return
false in case the power domain is disabled, and we also make
intel_display_power_enabled() return false in case the device is
suspended. Notice that we can't just use
intel_display_power_enabled_sw() because while the driver is being
initialized the power domain refcounts are not reflecting the real
state of the hardware.
Just for reference, I have previously published an alternate patch for
this problem, called "drm/i915: get runtime PM at intel_set_mode".
Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
At i915_display_info, don't call cursor_position() for a disabled
CRTC, since the CRTC may be on a powered down pipe, and this will
cause "Unclaimed register before interrupt" error messages.
Testcase: igt/pm_pc8/debugfs-read
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Otherwise we may get some WARNs complaining that we're reading a
register while we're suspended.
Testcase: igt/pm_pc8/debugfs-read
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
... at edp_have_panel_vdd. Just return false, saying we don't have the
panel VDD since the device is suspended.
We started getting WARNs about this problem since the patch that
started checking if we're suspended while reading registers.
Example backtrace provided by Paulo:
[ 63.572201] [drm:hsw_enable_pc8] Enabling package C8+
[ 63.581831] [drm:i915_runtime_suspend] Device suspended
[ 63.664798] ------------[ cut here ]------------
[ 63.664824] WARNING: CPU: 3 PID: 828 at
drivers/gpu/drm/i915/intel_uncore.c:47
assert_device_not_suspended.isra.7+0x32/0x40 [i915]()
[ 63.664826] Device suspended
[ 63.664828] Modules linked in: ccm fuse ip6table_filter ip6_tables
ebtable_nat ebtables arc4 ath9k_htc ath9k_common ath9k_hw mac80211 ath
cfg80211 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp
microcode i2c_i801 e1000e pcspkr serio_raw lpc_ich ptp pps_core mei_me
mei mfd_core dm_crypt i915 crc32_pclmul crc32c_intel
ghash_clmulni_intel i2c_algo_bit drm_kms_helper drm video
[ 63.664867] CPU: 3 PID: 828 Comm: kworker/3:3 Not tainted 3.14.0+ #153
[ 63.664869] Hardware name: Intel Corporation Shark Bay Client
platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0133.R00.1309172123
09/17/2013
[ 63.664887] Workqueue: events edp_panel_vdd_work [i915]
[ 63.664889] 0000000000000009 ffff88009d745c28 ffffffff8167ec6f
ffff88009d745c70
[ 63.664895] ffff88009d745c60 ffffffff8106c8ed ffff880036278000
00000000000c7204
[ 63.664900] ffff88014f2d3040 ffff880036278070 0000000000000001
ffff88009d745cc0
[ 63.664905] Call Trace:
[ 63.664911] [<ffffffff8167ec6f>] dump_stack+0x4d/0x66
[ 63.664916] [<ffffffff8106c8ed>] warn_slowpath_common+0x7d/0xa0
[ 63.664920] [<ffffffff8106c95c>] warn_slowpath_fmt+0x4c/0x50
[ 63.664926] [<ffffffff810bd6be>] ? mark_held_locks+0xae/0x130
[ 63.664941] [<ffffffffa00d80d2>]
assert_device_not_suspended.isra.7+0x32/0x40 [i915]
[ 63.664956] [<ffffffffa00d99d2>] gen6_read32+0x32/0x120 [i915]
[ 63.664969] [<ffffffffa00d99a0>] ? gen6_read8+0x120/0x120 [i915]
[ 63.664985] [<ffffffffa0106f8f>] edp_have_panel_vdd+0x3f/0x50 [i915]
[ 63.665000] [<ffffffffa01074e8>] edp_panel_vdd_off_sync+0x58/0x1c0 [i915]
[ 63.665004] [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560
[ 63.665018] [<ffffffffa0107684>] edp_panel_vdd_work+0x34/0x50 [i915]
[ 63.665022] [<ffffffff8108a0d7>] process_one_work+0x1f7/0x560
[ 63.665026] [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560
[ 63.665031] [<ffffffff8108ae2b>] worker_thread+0x11b/0x3a0
[ 63.665035] [<ffffffff8108ad10>] ? manage_workers.isra.21+0x2a0/0x2a0
[ 63.665039] [<ffffffff810916fc>] kthread+0xfc/0x120
[ 63.665043] [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230
[ 63.665048] [<ffffffff8169082c>] ret_from_fork+0x7c/0xb0
[ 63.665052] [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230
[ 63.665054] ---[ end trace 1250bcc890af9999 ]---
[ 63.665060] [drm:edp_panel_vdd_off_sync] Turning eDP VDD off
[ 63.665061] ------------[ cut here ]------------
Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
To avoid WARNs when we call it.
Testcase: igt/pm_pc8/reg-read-ioctl
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75693
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
So far force_wake_timer was only used by gen6_gt_force_wake_put. Since
we always had balanced gen6_gt_force_wake_get/put calls, we could
guarantee balanced calls to intel_runtime_pm_get/put.
Commit 8232644ccf099548710843e97360a3fcd6d28e04, "drm/i915: Convert
the forcewake worker into a timer func" started scheduling the
force_wake_timer at gen6_read, which resulted in an unbalanced
runtime_pm refcount.
So this commit just reverts to the old behavior until we can find a
proper way to used delayed force_wake from the register read/write
macros without leaving the runtime_pm refcounts unbalanced and without
runtime suspending the driver while forcewake is active.
Testcase: igt/pm_pc8/rte
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76544
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Atm we reserve/allocate and free the power context during GT power
enable/disable time. There is no need to do this, we can reserve/allocate
the buffer once during driver loading and free it during driver cleanup.
The re-reservation can also fail in case the driver previously manages to
allocate something on the given fixed address.
The buffer isn't exepected to move even if allocated by the BIOS, for
safety add an assert to check this assumption.
This also fixed a bug for Ville, where re-reserving the context failed
during a GPU reset (I assume because something else got allocated on its
fixed address).
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management updates from Rafael Wysocki:
"The majority of this material spent some time in linux-next, some of
it even several weeks. There are a few relatively fresh commits in
it, but they are mostly fixes and simple cleanups.
ACPI took the lead this time, both in terms of the number of commits
and the number of modified lines of code, cpufreq follows and there
are a few changes in the PM core and in cpuidle too.
A new feature that already got some LWN.net's attention is the device
PM QoS extension allowing latency tolerance requirements to be
propagated from leaf devices to their ancestors with hardware
interfaces for specifying latency tolerance. That should help systems
with hardware-driven power management to avoid going too far with it
in cases when there are latency tolerance constraints.
There also are some significant changes in the ACPI core related to
the way in which hotplug notifications are handled. They affect PCI
hotplug (ACPIPHP) and the ACPI dock station code too. The bottom line
is that all those notification now go through the root notify handler
and are propagated to the interested subsystems by means of callbacks
instead of having to install a notify handler for each device object
that we can potentially get hotplug notifications for.
In addition to that ACPICA will now advertise "Windows 2013"
compatibility for _OSI, because some systems out there don't work
correctly if that is not done (some of them don't even boot).
On the system suspend side of things, all of the device suspend and
resume callbacks, except for ->prepare() and ->complete(), are now
going to be executed asynchronously as that turns out to speed up
system suspend and resume on some platforms quite significantly and we
have a few more optimizations in that area.
Apart from that, there are some new device IDs and fixes and cleanups
all over. In particular, the system suspend and resume handling by
cpufreq should be improved and the cpuidle menu governor should be a
bit more robust now.
Specifics:
- Device PM QoS support for latency tolerance constraints on systems
with hardware interfaces allowing such constraints to be specified.
That is necessary to prevent hardware-driven power management from
becoming overly aggressive on some systems and to prevent power
management features leading to excessive latencies from being used
in some cases.
- Consolidation of the handling of ACPI hotplug notifications for
device objects. This causes all device hotplug notifications to go
through the root notify handler (that was executed for all of them
anyway before) that propagates them to individual subsystems, if
necessary, by executing callbacks provided by those subsystems
(those callbacks are associated with struct acpi_device objects
during device enumeration). As a result, the code in question
becomes both smaller in size and more straightforward and all of
those changes should not affect users.
- ACPICA update, including fixes related to the handling of _PRT in
cases when it is broken and the addition of "Windows 2013" to the
list of supported "features" for _OSI (which is necessary to
support systems that work incorrectly or don't even boot without
it). Changes from Bob Moore and Lv Zheng.
- Consolidation of ACPI _OST handling from Jiang Liu.
- ACPI battery and AC fixes allowing unusual system configurations to
be handled by that code from Alexander Mezin.
- New device IDs for the ACPI LPSS driver from Chiau Ee Chew.
- ACPI fan and thermal optimizations related to system suspend and
resume from Aaron Lu.
- Cleanups related to ACPI video from Jean Delvare.
- Assorted ACPI fixes and cleanups from Al Stone, Hanjun Guo, Lan
Tianyu, Paul Bolle, Tomasz Nowicki.
- Intel RAPL (Running Average Power Limits) driver cleanups from
Jacob Pan.
- intel_pstate fixes and cleanups from Dirk Brandewie.
- cpufreq fixes related to system suspend/resume handling from Viresh
Kumar.
- cpufreq core fixes and cleanups from Viresh Kumar, Stratos
Karafotis, Saravana Kannan, Rashika Kheria, Joe Perches.
- cpufreq drivers updates from Viresh Kumar, Zhuoyu Zhang, Rob
Herring.
- cpuidle fixes related to the menu governor from Tuukka Tikkanen.
- cpuidle fix related to coupled CPUs handling from Paul Burton.
- Asynchronous execution of all device suspend and resume callbacks,
except for ->prepare and ->complete, during system suspend and
resume from Chuansheng Liu.
- Delayed resuming of runtime-suspended devices during system suspend
for the PCI bus type and ACPI PM domain.
- New set of PM helper routines to allow device runtime PM callbacks
to be used during system suspend and resume more easily from Ulf
Hansson.
- Assorted fixes and cleanups in the PM core from Geert Uytterhoeven,
Prabhakar Lad, Philipp Zabel, Rashika Kheria, Sebastian Capella.
- devfreq fix from Saravana Kannan"
* tag 'pm+acpi-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (162 commits)
PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs
PM / sleep: Correct whitespace errors in <linux/pm.h>
intel_pstate: Set core to min P state during core offline
cpufreq: Add stop CPU callback to cpufreq_driver interface
cpufreq: Remove unnecessary braces
cpufreq: Fix checkpatch errors and warnings
cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs
MAINTAINERS: Reorder maintainer addresses for PM and ACPI
PM / Runtime: Update runtime_idle() documentation for return value meaning
video / output: Drop display output class support
fujitsu-laptop: Drop unneeded include
acer-wmi: Stop selecting VIDEO_OUTPUT_CONTROL
ACPI / gpu / drm: Stop selecting VIDEO_OUTPUT_CONTROL
ACPI / video: fix ACPI_VIDEO dependencies
cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}
cpufreq: Do not allow ->setpolicy drivers to provide ->target
cpufreq: arm_big_little: set 'physical_cluster' for each CPU
cpufreq: arm_big_little: make vexpress driver depend on bL core driver
ACPI / button: Add ACPI Button event via netlink routine
ACPI: Remove duplicate definitions of PREFIX
...
|
|
Remove the rest of the references to drm_i915_private_t. No functional
changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop hunk in i915_cmd_parser.c]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
