Alex Deucher [Wed, 10 Apr 2013 23:08:14 +0000 (19:08 -0400)]
drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)
Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=57567
https://bugs.freedesktop.org/show_bug.cgi?id=43655
https://bugzilla.kernel.org/show_bug.cgi?id=56441
v2: blank displays first, then disable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Dave Airlie [Mon, 22 Apr 2013 10:49:07 +0000 (20:49 +1000)]
Merge tag 'drm/tegra/for-3.10' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.10-rc1
The bulk of this pull-request is the host1x series that has been in the
works for a few months. The current implementation looks good and has
been tested by several independent parties. So far no issues have been
found. To be on the safe side, the new Tegra-specific DRM IOCTLs depend
on staging in order to give some amount of flexibility to change them
just in case. The plan is to remove that dependency once more userspace
exists to verify the adequacy of the IOCTLs.
Currently only the 2D engine is supported, but patches are in the works
to enable 3D support on top of this framework as well. Various bits of
open-source userspace exist to test the 2D and 3D support[0]. This is
still a bit immature but it allows to verify that the kernel interfaces
work properly.
To round things off there are two smaller cleanup patches, one of them
adding a new pixel format and the other removing a redundent Kconfig
dependency.
[0]: https://github.com/grate-driver
* tag 'drm/tegra/for-3.10' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: don't depend on OF
drm/tegra: Support the XBGR8888 pixelformat
drm/tegra: Add gr2d device
gpu: host1x: drm: Add memory manager and fb
gpu: host1x: Remove second host1x driver
gpu: host1x: drm: Rename host1x to host1x_drm
drm/tegra: Move drm to live under host1x
gpu: host1x: Add debug support
gpu: host1x: Add channel support
gpu: host1x: Add syncpoint wait and interrupts
gpu: host1x: Add host1x driver
Arto Merilainen [Fri, 22 Mar 2013 14:34:08 +0000 (16:34 +0200)]
gpu: host1x: drm: Add memory manager and fb
This patch introduces a memory manager for tegra drm and moves
existing parts to use it. As cma framebuffer helpers can no more
be used, this patch adds also a separate framebuffer driver for
tegra.
Terje Bergstrom [Fri, 22 Mar 2013 14:34:01 +0000 (16:34 +0200)]
gpu: host1x: Add host1x driver
Add host1x, the driver for host1x and its client unit 2D. The Tegra
host1x module is the DMA engine for register access to Tegra's
graphics- and multimedia-related modules. The modules served by
host1x are referred to as clients. host1x includes some other
functionality, such as synchronization.
Dave Airlie [Mon, 22 Apr 2013 09:47:40 +0000 (19:47 +1000)]
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Inki writes:
This is initial pull request for Exynos. It includes a big change
that it makes drm_display_mode for timings parameters to be used
for exynos4 and exynos5 commonly and cleans up unnecessary codes.
And also it adds device tree support for fimd to get timing values
and interrupt source from dts file.
In addition, one more patch, device tree support feature for Exynos
FIMC, is being reviewed. This patch was posted a little ago like below,
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17568.html
So we are going to request git pull one more time after reviewed.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: prepare FIMD clocks
Revert "of/exynos_g2d: Add Bindings for exynos G2D driver"
drm/exynos: drm_connector: Fix error check condition
drm/exynos: drm_rotator: Fix incorrect usage of IS_ERR_OR_NULL
drm/exynos: mixer: Fix incorrect usage of IS_ERR_OR_NULL
drm/exynos: hdmi: Fix incorrect usage of IS_ERR_OR_NULL
drm/exynos: change the method for getting the interrupt
drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd
drm/exynos: Add display-timing node parsing using video helper function
drm/exynos: hdmi: move mode_fixup to drm common hdmi
drm/exynos: hdmi: using drm_display_mode timings for exynos4
Dave Airlie [Mon, 22 Apr 2013 08:48:45 +0000 (18:48 +1000)]
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:
As promised a stash of (mostly) fixes. Two pieces of non-fixes included:
- A notch more gtt refactoring from Ben, beating to death with igt in our
nightly testing.
- Support for display display-less server chips (again from Ben). New hw
support which is only likely to break itself ;-)
Otherwise just tons of fixes:
- hpd irq storm mitigation from Egbert Eich. Your -next tree already has
the infrastructure, this here just supplies the logic.
- sdvo hw state check fix from Egbert Eich
- fb cb tune settings for the pch pll clocks on cpt/ppt
- "Bring a bigger gun" coherence workaround for multi-threade, mulit-core
& thrashing tiled gtt cpu access from Chris.
- Update haswell mPHY code.
- l3$ caching for context objects on ivb/hsw (Chris).
- dp aux refclock fix for haswell (Jani)
- moar overclocking fixes for snb/ivb (Ben)
- ecobits ppgtt pte caching control fixes from Ville
- fence stride check fixes and limit improvements (Ville)
- fix up crtc force restoring, potentially resulting in tons of hw state
check WARNs
- OOPS fix for NULL derefencing of fb pointers when force-restoring a crtc
when other crtcs are disabled and the force-restored crtc is _not_ the
first one.
- Fix pfit disabling on gen2/3.
- Haswell ring freq scaling fixes (Chris).
- backlight init/teardown fix (failed eDP init killed the lvds backlight)
from Jani
- cpt/ppt fdi polarity fixes from Paulo (should help a lot of the FDI link
train failures).
- And a bunch of smaller things all over.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (56 commits)
drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config
drm/i915: move cpu_transcoder to the pipe configuration
drm/i915: preserve the PBC bits of TRANS_CHICKEN2
drm/i915: set CPT FDI RX polarity bits based on VBT
drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)
drm/i915: Mask out the HPD irq bits before setting them individually.
drm/i915: (re)init HPD interrupt storm statistics
drm/i915: Add HPD IRQ storm detection (v5)
drm/i915: WARN when LPT-LP is not paired with ULT CPU
drm/i915: don't intel_crt_init on any ULT machines
drm/i915: remove comment about IVB link training from intel_pm.c
drm/i915: VLV doesn't have LLC
drm/i915: Scale ring, rather than ia, frequency on Haswell
drm/i915: shorten debugfs output simple attributes
drm/i915: Fixup pfit disabling for gen2/3
drm/i915: Fixup Oops in the pipe config computation
drm/i915: ensure single initialization and cleanup of backlight device
drm/i915: don't touch the PF regs if the power well is down
drm/i915: add intel_using_power_well
...
While migrating to common clock framework (CCF), I found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
Calling clk_prepare() for FIMD clocks fixes the issue.
This patch also replaces clk_disable() with clk_unprepare() during exit, since
clk_prepare() is called in fimd_probe().
Daniel Vetter [Wed, 17 Apr 2013 18:15:07 +0000 (20:15 +0200)]
drm/i915: move cpu_transcoder to the pipe configuration
For a bunch of reason we need to more accurately track this:
- hw pipe state readout for Haswell needs the cpu transcoder.
- We need to know the right cpu transcoder in a bunch of places in
->disable and other modeset callbacks.
In the future we need to add hw state readout&check support, too. But
to avoid ugly merge conflicts do the rote sed job now without any
functional changes.
v2: Preserve the cpu_transcoder value when overwriting crtc->config.
Reported by Paulo.
Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: Removed rough whitespace that Chris spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Mon, 8 Apr 2013 18:48:08 +0000 (15:48 -0300)]
drm/i915: preserve the PBC bits of TRANS_CHICKEN2
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Delete the redudant #define that Imre spotted in his review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.
v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker.
v3: Clarified loop start value,
Removed superfluous test for Ivybridge and Haswell,
Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)
v4: Fixed two bugs pointed out by Jani Nikula.
Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.
v2: Fixed cleanup typo.
v3: Fixed format issues, clarified a variable name,
changed pr_warn() to DRM_INFO() as suggested by
Jani Nikula <jani.nikula@linux.intel.com>.
Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.
Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise seems to be bad routing of the hotplug line
on the board: cross talk from other signals seems to cause erronous
hotplug interrupts. This has been documented as an erratum for the
the i945GM chipset and thus hotplug support was disabled for this
chipset model but others seem to have this problem, too.
We have seen this issue on a G35 motherboard for example:
Even different motherboards of the same model seem to behave
differently: while some only see only around 10-100 interrupts/s
others seem to see 5k or more.
We've also observed a dependency on the selected video mode.
Also on certain laptops interrupt noise seems to occur duing
battery charging when the battery is at a certain charge levels.
Thus we add a simple algorithm here that detects an 'interrupt storm'
condition.
v2: Fixed comment.
v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff.
v4: Followed by Jesse Barnes to use a time_..() macro.
v5: Fixed coding style as suggested by Jani Nikula.
Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 12 Apr 2013 21:16:53 +0000 (18:16 -0300)]
drm/i915: don't intel_crt_init on any ULT machines
We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.
Cc: stable@vger.kernel.org Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I don't have a VLV to test it with, Jesse, Ken, can one of you test?
Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 12 Apr 2013 18:10:13 +0000 (19:10 +0100)]
drm/i915: Scale ring, rather than ia, frequency on Haswell
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.
v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add space checkpatch complained about.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix this up by properly computing the pipe the pfit is on. Also
extract the logic into its own function, add a debug assert to check
that the pipe is off (mostly just documentation) and add some debug
output.
If pipe A was disabled after pipe B was set up, the panel fitter will
be disabled. Now most userspace doesn't do modesets in this order,
which is why I couldn't ever reproduce this and why it took me so long
to figure out.
We really need hw state readout and check support for the pannel
fitter ...
Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Hans de Bruin <jmdebruin@xmsnet.nl>
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19049 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 12 Apr 2013 16:48:43 +0000 (18:48 +0200)]
drm/i915: Fixup Oops in the pipe config computation
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes compares the current state with where we
want to go to (which is carefully set up by intel_crtc_set_config) and
then goes through the modeset sequence for any crtc which needs
updating.
Now the issue is that the actual interface with the remaining code
still only works on one crtc, and so we only pass in one fb and one
mode. In intel_set_mode we also only compute one intel_crtc_config
(which should be the one for the crtc we're doing a modeset on).
The reason for that mismatch is twofold:
- We want to eventually do all modeset as global state changes, so
it's just infrastructure prep.
- But even the old semantics can change more than one crtc when you
e.g. move a connector from crtc A to crtc B, then both crtc A and B
need to be updated. Usually that means one pipe is disabled and the
other enabled. This is also the reason why the hack doesn't touch the
disable_pipes mask.
Now hilarity ensued in our kms config restore paths when we actually
try to do a modeset on all crtcs: If the first crtc should be off and
the second should be on, then the call on the first crtc will notice
that the 2nd one should be switched on and so tries to compute the
pipe_config. But due to a lack of passed-in fb (crtc 1 should be off
after all) it only results in tears.
This case is ridiculously easy to hit on gen2/3 where the lvds output
is restricted to pipe B. Note that before the pipe_config bpp rework
gen2/3 didn't care really about the fb->depth, so this is a regression
brought to light with
drm/i915: precompute pipe bpp before touching the hw
But apparently Ajax also managed to blow up pch platforms, probably
with some randomized configs, and pch platforms trip up over the lack
of an fb even in the old code. So this actually goes back to the first
introduction of the new modeset restore code in
Fix this mess by now by justing shunting all the cool new global
modeset logic in intel_modeset_affected_pipes.
v2: Improve commit message and clean up all the comments in
intel_modeset_affected_pipes - since the introduction of the modeset
restore code they've been a bit outdated.
Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 Cc: stable@vger.kernel.org
References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html Tested-by: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Fri, 12 Apr 2013 12:18:38 +0000 (15:18 +0300)]
drm/i915: ensure single initialization and cleanup of backlight device
Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.
A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Peter Verthez <peter.verthez@skynet.be> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 11 Apr 2013 18:22:50 +0000 (20:22 +0200)]
drm/i915: don't check inconsistent modeset state when force-restoring
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the end, so we don't reduce the amount of
checking.
v2: Try harder not to create a big patch (Chris).
v3: Even smaller (still Chris). Also fix a trailing space.
References: https://lkml.org/lkml/2013/3/16/60 Cc: Tomas Melin <tomas.melin@iki.fi> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Tomas Melin <tomas.melin@iki.fi> Tested-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 9 Apr 2013 10:02:47 +0000 (13:02 +0300)]
drm/i915: IVB/HSW have 32 fence register
Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.
Increasing the number of fences was attempted before [1], but there was
some uncertainty about the maximum CPU fence number for FBC. Since then
BSpec has been updated to state that there are in fact 32 fence registers,
and the CPU fence number field in the SNB_DPFC_CTL_SA register is 5 bits,
and the CPU fence number field in the ILK_DPFC_CONTROL register must be
zero. So now it all makes sense.
changed the sysfs read semantics for 'gt_max_freq_mhz'. By
always returning overclock max instead of stored value.
Fix this by returning the stored value. Separate sysfs entry
should be considered for overclocking max freq.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63415 Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 4 Apr 2013 12:13:42 +0000 (15:13 +0300)]
drm/i915: Configure GAM_ECOCHK appropriatly for Gen7
IVB and HSW use different encodings for the PPGTT cacheability bits in
the GAM_ECOCHK register.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 4 Apr 2013 12:13:41 +0000 (15:13 +0300)]
drm/i915: Set GAC_ECO_BITS register on Gen7+
According to BSpec GAC_ECO_BITS register exists on Gen7 platforms as
well. Configure it accordingly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 4 Apr 2013 12:13:40 +0000 (15:13 +0300)]
drm/i915: Add ECOBITS_SNB_BIT
GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add
the define, and enable it on SNB.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Fri, 5 Apr 2013 21:29:23 +0000 (14:29 -0700)]
drm/i915: Don't default to overclock max
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Fri, 5 Apr 2013 21:29:22 +0000 (14:29 -0700)]
drm/i915: Better overclock support
Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also fixes an issue where if one sets the max frequency to be
below the overclock max, they wouldn't be able to set back the proper
overclock max.
In addition I've added a couple of other bits:
Show the overclock freq. as max in sysfs
Print the overclock max in debugfs.
Print a warning if the user sets the min frequency to be in the
overclock range.
In this patch I've decided to store the hw_max when we read it from the
pcode at init. The reason I do this is the pcode reads can fail, and are
slow.
v2: Report when user requested overclocked max (Daniel)
Remove when user sets min to overclock range (Daniel)
Reported-by: freezer from #intel-gfx on irc Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
that Mika spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Tue, 9 Apr 2013 05:11:00 +0000 (08:11 +0300)]
drm/i915: use lower aux clock divider on non-ULT HSW
Workaround to avoid intermittent aux channel failures, per spec change.
v2: Don't mess with cpu dp aux divider (Paulo Zanoni)
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Kill spurious tab spotted by Paulo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 9 Apr 2013 01:43:56 +0000 (18:43 -0700)]
drm/i915: Allow PPGTT enable to fail
I'm really not happy that we have to support this, but this will be the
simplest way to handle cases where PPGTT init can fail, which I promise
will be coming in the future.
v2: Resolve conflicts due to patch series reordering.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 9 Apr 2013 01:43:55 +0000 (18:43 -0700)]
drm/i915: NULL aliasing_ppgtt on cleanup
This will allow us to carry on if we've cleaned up the PPGTT. The usage
for this is coming up - it simplifies handling a failed PPGTT init.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Spill the secrets about failing ppgtt init.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 9 Apr 2013 01:43:51 +0000 (18:43 -0700)]
drm/i915/ppgtt: Set scratch page "globally"
The PPGTT scratch page is used for all gens, and doing it in the global
part of our PPGTT setup makes the code a bit nicer.
This was in a patch submitted earlier as part of the PPGTT cleanups.
Grumpy maintainer must have missed it, and I didn't yell when
appropriate. Apologies for everyone :-)
v2: Update commit message
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 9 Apr 2013 01:43:49 +0000 (18:43 -0700)]
drm/i915: Map registers before GTT init
This will allow us to read/write registers in GTT init.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Fix up error handling. We really should look into devres for
this stuff ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 9 Apr 2013 01:43:48 +0000 (18:43 -0700)]
drm/i915: Call out GEN6 PTE specificity
We can assume that the PTE layout, and size changes for future
generations. To avoid confusion with the existing GEN6 PTE typedef, give
it a GEN6_ prefix.
v2: Fixup checkpatch warning and bikeshed commit message slightly.
v3: Rebase on top of Imre's for_each_sg_pages rework.
v4: Fixup conflicts in patch series reordering.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 9 Apr 2013 01:43:47 +0000 (18:43 -0700)]
drm/i915: generalize pte vs. register BAR allocation
All gen6+ parts so far have 1 BAR which holds both the register space
and the GTT PTEs. Up until now, that was a 4MB BAR with half allocated
to each.
I have a strong hunch (wink, nod, wink) that future gens will also keep
a similar 50-50 split though the sizes may change. To help this along
change the code to obey the rule of half the total size instead of a
hard-coded 2MB.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 8 Apr 2013 13:28:40 +0000 (14:28 +0100)]
drm/i915: Use MLC (l3$) for context objects
Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are not backed by any
particular cache (such as the sampler or render caches) our only option
is to select the generic mid-level cache. This reduces the latency of
the swap by about 5%.
Oddly this effect can be observed running smokin-guns on IVB at
1280x1024:
Using BLT copies for swaps: 151.67 fps
Using Render copies for swaps (unpatched): 141.70 fps
With contexts disabled: 150.23 fps
With contexts in L3$: 150.77 fps
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 4 Apr 2013 20:31:03 +0000 (21:31 +0100)]
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
manually flush writes to memory prior to writing the fence register in
conjunction with the memory barriers placed around the register write.
Fixes i-g-t/gem_fence_thrash
v2: Bring a bigger gun
v3: Switch the bigger gun for heavier bullets (Arjan van de Ven)
v4: Remove changes for working generations.
v5: Reduce to a per-cpu wbinvd() call prior to updating the fences.
v6: Rewrite comments to ellide forgotten history.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Tested-by: Jon Bloomfield <jon.bloomfield@intel.com> (v2) Cc: stable@vger.kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Fix the spelling in the added comment (Chris).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63246 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 4 Apr 2013 20:20:34 +0000 (22:20 +0200)]
drm/i915: set CB tuning also for the reduce clock
Since the ratio is different, we also need to pass in the parameters
for the reduced clock. Might or might not reduce flicker for the
auto-downclocking on lvds/eDP.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 4 Apr 2013 20:20:33 +0000 (22:20 +0200)]
drm/i915: fix FP CB tuning limits for lvds
Only on IBX should we set the limiting factor to 25 unconditionally
for dual-channel mode, on CPT/PPT 25 only applies when the lvds
refclock is 100MHz.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Fix SDVO connector and encoder get_hw_state functions
The connector associated with the encoder is considered active when the
output associtated with this connector is active on the encoder. The
encoder itself is considered active when either there is an active
output on it or the respective SDVO channel is active.
Having active outputs when the SDVO channel is inactive seems to be
inconsistent: such states can be found when intel_modeset_setup_hw_state()
collects the hardware state set by the BIOS.
This inconsistency will be fixed in intel_sanitize_crtc()
(when intel_crtc_update_dpms() is called), this however only happens
when the encoder is associated with a crtc.
Dave Airlie [Wed, 17 Apr 2013 05:18:32 +0000 (15:18 +1000)]
Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next
Patrik writes:
I haven't had much review or testing on other platforms than Poulsbo but
at least the following Cedarview bug has been squashed and no
regressions reported: https://bugs.freedesktop.org/show_bug.cgi?id=58527
* 'gma500-next' of git://github.com/patjak/drm-gma500:
drm/gma500: Add debugging info to psb_gtt_restore()
drm/gma500: Check connector status before restoring sdvo
gma500:fix build failure for 3.9-rc5
drm/gma500: Fix hibernation problems on sdvo encoders
drm/gma500: Add hooks for hibernation
drm/gma500: Activate the gtt rebuild on suspend/resume
drm/gma500: Add support for rebuilding the gtt
drm/gma500: Change fb name so pm-utils doesn't apply quirks
gma500: Make VGA and HDMI connector hotpluggable
drm/gma500: Clean up various defines
drm/gma500: Remove unnecessary function exposure
drm/gma500: Type clock limits directly into array and remove defines
drm/gma500: Calculate clock in one function instead of three identical
drm/gma500: Remove unused i8xx clock limits
gma500: medfield: Fix possible NULL pointer dereference
drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with kmemdup
gma500: remove unused drm_psb_no_fb
Dave Airlie [Tue, 16 Apr 2013 22:48:23 +0000 (08:48 +1000)]
Merge branch 'drm-next-3.10' of git://people.freedesktop.org/~agd5f/linux into drm-next
Alex writes:
This is the initial 3.10 pull request for radeon. The big changes here
are UVD support and proper tiling support for SI. The rest is
bug fixes. I hope to have another pull request later in the week with
some new things we've been working on internally.
* 'drm-next-3.10' of git://people.freedesktop.org/~agd5f/linux: (28 commits)
drm/radeon: Always flush the VM
drm/radeon: re-enable PTE/PDE packet for set_page on cayman/TN
drm/radeon: cleanup properly if mmio mapping fails
drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS
drm/radeon: add si tile mode array query v3
drm/radeon: add ring working query
drm/radeon: handle broken disabled rb mask gracefully
drm/radeon: add pcie set/get lanes callbacks for newer asics
drm/radeon: update r600 set/get pcie lane config
drm/radeon/kms: replace *REG32_PCIE_P with *REG32_PCIE_PORT
drm/radeon: remove unused blit remnants from si.c
drm/radeon: add UVD tiling addr config v2
drm/radeon: init UVD clocks to sane defaults
drm/radeon: add set_uvd_clocks callback for r7xx v3
drm/radeon: add set_uvd_clocks callback for SI
drm/radeon: add set_uvd_clocks callback for evergreen
drm/radeon: add set_uvd_clocks callback for ON/LN/TN (v4)
drm/radeon: add radeon_atom_get_clock_dividers helper
drm/radeon: add pm callback for setting uvd clocks
drm/radeon: UVD bringup v8
...
This is slightly cleaned up version of Jerome's patch.
There seems to be an issue tracking the last flush of
the VM which results in hangs in certain cases when
VM is used. For now just flush the VM for every IB.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Alex Deucher [Tue, 16 Apr 2013 14:42:15 +0000 (10:42 -0400)]
drm/radeon: re-enable PTE/PDE packet for set_page on cayman/TN
PTE/PDE doesn't support a single update (count = 1). We had
previously disabled it since it we were hitting that case which
let to hangs. The PTE/PDE packet is much more efficient for VM
updates where it can be used.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Revert "of/exynos_g2d: Add Bindings for exynos G2D driver"
This reverts commit 09495dda6a62c74b13412a63528093910ef80edd.
The description is incomplete and the location of this file
is incorrect. Based on discussion with the Samsung media and DRM subsystem
maintainers, the documentaion of Samsung G2D bindings has been placed at:
Documentation/devicetree/bindings/gpu/samsung-g2d.txt
drm/exynos: change the method for getting the interrupt
Replaces the "platform_get_resource() for IORESOURCE_IRQ" with
platform_get_resource_byname().
Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order: "fifo",
"vsync", and "lcd_sys".
But The FIMD driver expects the "vsync" interrupt to be mentioned as the
1st parameter in the FIMD DT node. So to meet this expectation of the
driver, the FIMD DT node was forced to be made by keeping "vsync" as the
1st paramter.
For example in exynos4, the FIMD DT node has interrupt numbers
mentioned as <11, 1> <11, 0> <11, 2> keeping "vsync" as the 1st paramter.
This patch fixes the above mentioned "hack" of re-ordering of the
FIMD interrupt numbers by getting interrupt resource of FIMD by using
platform_get_resource_byname().
Rahul Sharma [Wed, 6 Mar 2013 08:28:16 +0000 (17:28 +0900)]
drm/exynos: hdmi: move mode_fixup to drm common hdmi
Currently, mode_fixup code doesn't consider the limitations of mixer as it
is implemented inside the hdmi driver. Following fix, moves the mode_fixup
to common drm hdmi driver. To check the mode support, it calls both, mixer
and hdmi check_timing callbacks for a given resolution mode.
This patch is dependent on https://patchwork.kernel.org/patch/2176021/.
Rahul Sharma [Wed, 6 Mar 2013 08:33:29 +0000 (17:33 +0900)]
drm/exynos: hdmi: using drm_display_mode timings for exynos4
Exynos5 is already using drm_display_mode for timings parameters. Exynos4
is also modifed to use the same. List of supported resolutions and
corresponding timings are removed which helps is enabling some extra
resolutions. It also cleans some of the duplicate code.
Exynos4 and Exynos5 Mixers, work fine for the same range of resolutions. Hence
same condition (to find the supported mode) is applied to both.
More exynos4 phy configs can be added later to extend the mode supprot.
Dave Airlie [Tue, 16 Apr 2013 03:24:25 +0000 (13:24 +1000)]
drm/qxl: make lots of things static.
/usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:414:9: sparse: preprocessor token offsetof redefined
include/linux/stddef.h:17:9: this was the original definition
>> drivers/gpu/drm/qxl/qxl_drv.c:49:5: sparse: symbol 'qxl_modeset' was not declared. Should it be static?
Reported-by: kbuild test robot. Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Tue, 16 Apr 2013 03:20:03 +0000 (13:20 +1000)]
Merge tag 'omapdss-for-3.10' of git://gitorious.org/linux-omap-dss2/linux into drm-next
Omapdss patches for 3.10 merge window
The biggest changes are:
* DSI video mode: automatic clock and timing calculation
* Lots of platform data related panel driver cleanups, to prepare for DT
* tag 'omapdss-for-3.10' of git://gitorious.org/linux-omap-dss2/linux: (69 commits)
drm/omap: add statics to a few structs
drm/omap: Fix and improve crtc and overlay manager correlation
drm/omap: Take a fb reference in omap_plane_update()
drm/omap: Make fixed resolution panels work
drm/omap: fix modeset_init if a panel doesn't satisfy omapdrm requirements
OMAPDSS: DPI: widen the pck search when using dss fck
OMAPDSS: fix dss_fck clock rate rounding
omapdss: use devm_clk_get()
OMAPDSS: nec-nl8048 panel: Use dev_pm_ops
OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5
OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers
omapdss: Features: Fix some parameter ranges
omapdss: DISPC: add max pixel clock limits for LCD and TV managers
OMAPDSS: DSI: Use devm_clk_get()
drivers: video: omap2: dss: Use PTR_RET function
OMAPDSS: VENC: remove platform_enable/disable calls
OMAPDSS: n8x0 panel: remove use of platform_enable/disable
OMAPDSS: n8x0 panel: handle gpio data in panel driver
OMAPDSS: picodlp panel: remove platform_enable/disable callbacks
OMAPDSS: picodlp panel: handle gpio data in panel driver
...
Chris Wilson [Fri, 12 Apr 2013 09:39:59 +0000 (10:39 +0100)]
drm: Perform ioctl command validation on the stored kernel values
Userspace is free to pass in any command bits it feels like through the
ioctl cmd, and for example trinity likes to fuzz those bits to create
conflicting commands. So instead of relying upon userspace to pass along
the correct IN/OUT flags for the ioctl, use the flags as expected by the
kernel.
This does have a side-effect that NULL pointers can not be substituted
by userspace in place of a struct. This feature was not being used by
any driver, but instead exposed all of the command handlers to a user
triggerable OOPS.
Paul Sokolovsky [Fri, 12 Apr 2013 23:28:26 +0000 (18:28 -0500)]
drm.h: Fix DRM compilation with bare-metal toolchain.
An ifdef in drm.h expects to be compiled with full-fledged Linux
toolchain, but it's common to compile kernel with just bare-metal
toolchain which doesn't define __linux__. So, also add __KERNEL__
check.
[nm@ti.com: port forward to 3.9-rc6 and post to dri devel for feedback as RFC] Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm: Destroy property blobs at mode config cleanup time
Property blob objects need to be destroyed when cleaning up to avoid
memory leaks. Go through the list of all blobs in the
drm_mode_config_cleanup() function and destroy them.
The drm_mode_config_cleanup() function needs to be moved after the
drm_property_destroy_blob() declaration. Move drm_mode_config_init() as
well to keep the functions together.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Tue, 16 Apr 2013 03:03:47 +0000 (13:03 +1000)]
Merge tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:
Since I expect Linus to open the merge window in about a week I guess this
is the last i915 feature pull for 3.10. Highlights:
Updated testing tree for -next. Highlights:
- Corner case fixes discovered with static analyzers (Damien).
- More fixes to combat unclaimed register errors on Haswell (Paulo).
- Some small fixes to the gpu turbo code (Rodrigo+Ben), Ben has more
fixes for overclocking support pending.
- More prep work for fastboot from Chris.
- VT-switchless suspend/resume from Jesse.
- The prep work of Egbert Eich's hpd irq storm handling. Hopefully we can
squeeze in the actual storm handling code for 3.10 ...
- More convenience helpers for Imre's sg iterator. Core parts acked by
Andrew Morton.
- A bit of backlight code cleanup from Jani.
- Fixed ilk gpu reset (Jesse).
- Reduced color range handling fixes for VLV (Ville).
The big item here is though the introduction of pipe_config to properly
pre-compute the desired modeset state before touching the hw. Together
with some very basic support to read out the current config from the hw
and compare the state with the sw tracking. This is all prep work for more
reliable fastboot, atomic modesets and other cool features. Stuff
converted to the new world includes:
- Most simple pipe attributes (reduce color range, pixel multiplier).
- Pipe bpp/dither handling.
- Some convenience flags like ->has_pch_encoder to simplify the code flow.
- (Almost) DP clock handling, had to be reverted since part of a prep
patch was lost in rebasing ...
Expect a lot of patches for this throughout 3.11, there's tons of work
till we have all state properly tracked for fastbooting to woExpect a lot
of patches for this throughout 3.11, there's tons of work till we have all
state properly tracked for fastbooting to work.
For 3.10 I have a bunch of fixes queued up and I plan to send them all out
at the end of this week. I need to shuffle patches in my -next queue a bit
so that we don't but feature-y stuff in there, too. The main thing I'd
like to sneak in is Egbert's hpd irq storm handling, which should be
pretty low-risk since all the infrastructure work has landed already. I
also have the oops fix pending, but that only mustered review before the
w/e and giving how hairy that part of our modeset code is, I want to give
it some more testing before forwarding.
Note: annarchy.fd.o seems to run out of disk space, so couldn't push the
usual for-airlied branch. Tag should work though.
Note 2: I've had to do a backmerge since conflicts grew too ugly, but the
upstream -rc I've backmerged is already in your drm-next.
* tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits)
drm/i915: info level for simulated gpu hang dmesg notice
drm/i915: revert eDP bpp clamping code changes
Revert "drm/i915: fix DP get_hw_state return value"
drm/i915: Don't use the HDMI port color range bit on Valleyview
drm/i915: Set PIPECONF color range bit on Valleyview
drm/i915: extract i9xx_set_pipeconf
drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
drm/i915: create pipe_config->dpll for clock state
drm/i915: hw readout support for ->has_pch_encoders
drm/i915: add hw state readout/checking for pipe_config
drm/i915: rip out superflous is_dp&is_cpu_edp tracking
drm/i915: remove leaky eDP functions
drm/i915: track dp target_clock in pipe_config
drm/i915: move dp_m_n computation to dp_encoder->compute_config
drm/i915: clear up the fdi/dp set_m_n confusion
drm/i915: Fix sdvo connector get_hw_state function
drm/i915: drop DPFLIPSTAT enables on VLV v3
drm/i915: add Punit read/write routines for VLV v2
drm/i915: panel power sequencing for VLV eDP v2
drm/i915/dp: fix up VLV DP handling v2
...
drm/gma500: Check connector status before restoring sdvo
This patch fixes a bug introduced by:
commit 749387dc8d8270b279f27a0a794cdf4f4a4aa774
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date: Sun Apr 7 16:35:50 2013 +0200
drm/gma500: Fix hibernation problems on sdvo encoders
The bug is triggered when we do a mode set on a sdvo encoder with all
connectors in the disconnected state. A crtc is considered enabled by
drm even though all of its connectors are disconnected. Work around
this by adding a check in our sdvo restore function.
Also remove the unneeded dpms on. Prepare and Commit will take care of
that.
projects / mirror_ubuntu-eoan-kernel.git / log