- 22 Apr, 2013 21 commits
-
-
Alex Deucher authored
Need to wait for the new addresses to take affect before re-enabling the MC. Signed-off-by:Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Alex Deucher authored
Need to wait for the new addresses to take affect before re-enabling the MC. Signed-off-by: -
Alex Deucher authored
Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by: -
Alex Deucher authored
Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by: -
Alex Deucher authored
Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by: -
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
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
-
Stephen Warren authored
ARCH_TEGRA always enabled OF, so there's no need for any driver to depend on it. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Thierry Reding <thierry.reding@avionic-design.de>
-
Thierry Reding authored
While at it, also include the RGB565 pixelformat in the list of formats supported by overlays. Signed-off-by:
Erik Faye-Lund <kusmabite@gmail.com>
-
Terje Bergstrom authored
Add client driver for 2D device, and IOCTLs to pass work to host1x channel for 2D. Also adds functions that can be called to access sync points from DRM. Signed-off-by:
Arto Merilainen <amerilainen@nvidia.com> Signed-off-by:
Terje Bergstrom <tbergstrom@nvidia.com> Reviewed-by:
-
Arto Merilainen authored
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. Signed-off-by:
-
Terje Bergstrom authored
Remove second host1x driver, and bind tegra-drm to the new host1x driver. The logic to parse device tree and track clients is moved to drm.c. Signed-off-by:
-
Arto Merilainen authored
Both host1x and drm drivers have host1x structures. This patch renames the host1x structure under drm to follow name host1x_drm. Signed-off-by:
-
Terje Bergstrom authored
Make drm part of host1x driver. Signed-off-by:
-
Terje Bergstrom authored
Add support for host1x debugging. Adds debugfs entries, and dumps channel state to UART in case of stuck job. Signed-off-by:
-
Terje Bergstrom authored
Add support for host1x client modules, and host1x channels to submit work to the clients. Signed-off-by:
-
Terje Bergstrom authored
Add support for sync point interrupts, and sync point wait. Sync point wait used interrupts for unblocking wait. Signed-off-by:
-
Terje Bergstrom authored
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. Signed-off-by:
-
Laurent Pinchart authored
Test whether the pixel format changes in the mode set handler, and perform a full mode set instead of a mode set base if it does. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Laurent Pinchart authored
A page flip is not a mode set, changing the frame buffer pixel format doesn't make sense and isn't handled by most drivers anyway. Disallow it. Signed-off-by:
-
Dave Airlie authored
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
-
git://people.freedesktop.org/~danvet/drm-intelDave Airlie authored
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 ...
-
- 20 Apr, 2013 1 commit
-
-
Vikas Sajjan authored
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(). Signed-off-by:
Vikas Sajjan <vikas.sajjan@linaro.org> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
- 18 Apr, 2013 18 commits
-
-
Daniel Vetter authored
Oops. This regression has been introduced in commit 5d2d38dd Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:45:01 2013 +0100 drm/i915: clean up pipe bpp confusion Reported-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
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:
-
Paulo Zanoni authored
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:
Imre Deak <imre.deak@intel.com> [danvet: Delete the redudant #define that Imre spotted in his review.] Signed-off-by:
-
Paulo Zanoni authored
Check the VBT to see if the machine has inverted FDI RX polarity on CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2 registers. This should fix some machines that were showing black screens on all outputs. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029Signed-off-by:
-
Egbert Eich authored
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:
-
Egbert Eich authored
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 authored
To disable previously enabled HPD IRQs we need to reset them and set the enabled ones individually. Signed-off-by:
-
Egbert Eich authored
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 authored
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:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
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 authored
We have the exact same comment inside intel_init_display. This is a leftover from when we moved a lot of code from intel_display.c to intel_pm.c. Signed-off-by:
-
Ben Widawsky authored
Caused by me with v2 of commit 219f4fdb Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Mar 15 11:17:54 2013 -0700 drm/i915: Introduce GEN7_FEATURES for device info 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 authored
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:
-
Mika Kuoppala authored
commit 647416f9 Author: Kees Cook <keescook@chromium.org> Date: Sun Mar 10 14:10:06 2013 -0700 drm/i915: use simple attribute in debugfs routines made i915_next_seqno debugfs entry to crop it's output if returned value was large enough. Using simple_attr will limit the output to 24 bytes. Fix is to strip out preamples on all simple attributes that have one. v2: Fix all simple attributes (Daniel Vetter) Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Daniel Vetter authored
The recent rework of the pfit handling didn't take into account that the panel fitter is fixed to pipe B: commit 24a1f16d Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Feb 8 16:35:37 2013 +0200 drm/i915: disable shared panel fitter for pipe 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/19049Reviewed-by:
-
Daniel Vetter authored
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 commit 4e53c2e0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 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 commit 45e2b5f6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open 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.htmlTested-by:
Richard Cochran <richardcochran@gmail.com> Reviewed-by:
-
Jani Nikula authored
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=55701Signed-off-by:
Peter Verthez <peter.verthez@skynet.be> Cc: stable@vger.kernel.org Signed-off-by:
-
