summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'trace-v4.1' of ↵Linus Torvalds2015-04-143-3/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing updates from Steven Rostedt: "Some clean ups and small fixes, but the biggest change is the addition of the TRACE_DEFINE_ENUM() macro that can be used by tracepoints. Tracepoints have helper functions for the TP_printk() called __print_symbolic() and __print_flags() that lets a numeric number be displayed as a a human comprehensible text. What is placed in the TP_printk() is also shown in the tracepoint format file such that user space tools like perf and trace-cmd can parse the binary data and express the values too. Unfortunately, the way the TRACE_EVENT() macro works, anything placed in the TP_printk() will be shown pretty much exactly as is. The problem arises when enums are used. That's because unlike macros, enums will not be changed into their values by the C pre-processor. Thus, the enum string is exported to the format file, and this makes it useless for user space tools. The TRACE_DEFINE_ENUM() solves this by converting the enum strings in the TP_printk() format into their number, and that is what is shown to user space. For example, the tracepoint tlb_flush currently has this in its format file: __print_symbolic(REC->reason, { TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" }, { TLB_REMOTE_SHOOTDOWN, "remote shootdown" }, { TLB_LOCAL_SHOOTDOWN, "local shootdown" }, { TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" }) After adding: TRACE_DEFINE_ENUM(TLB_FLUSH_ON_TASK_SWITCH); TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN); TRACE_DEFINE_ENUM(TLB_LOCAL_SHOOTDOWN); TRACE_DEFINE_ENUM(TLB_LOCAL_MM_SHOOTDOWN); Its format file will contain this: __print_symbolic(REC->reason, { 0, "flush on task switch" }, { 1, "remote shootdown" }, { 2, "local shootdown" }, { 3, "local mm shootdown" })" * tag 'trace-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: (27 commits) tracing: Add enum_map file to show enums that have been mapped writeback: Export enums used by tracepoint to user space v4l: Export enums used by tracepoints to user space SUNRPC: Export enums in tracepoints to user space mm: tracing: Export enums in tracepoints to user space irq/tracing: Export enums in tracepoints to user space f2fs: Export the enums in the tracepoints to userspace net/9p/tracing: Export enums in tracepoints to userspace x86/tlb/trace: Export enums in used by tlb_flush tracepoint tracing/samples: Update the trace-event-sample.h with TRACE_DEFINE_ENUM() tracing: Allow for modules to convert their enums to values tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values tracing: Update trace-event-sample with TRACE_SYSTEM_VAR documentation tracing: Give system name a pointer brcmsmac: Move each system tracepoints to their own header iwlwifi: Move each system tracepoints to their own header mac80211: Move message tracepoints to their own header tracing: Add TRACE_SYSTEM_VAR to xhci-hcd tracing: Add TRACE_SYSTEM_VAR to kvm-s390 tracing: Add TRACE_SYSTEM_VAR to intel-sst ...
| * tracing/drm: Remove unused TRACE_SYSTEM_STRING defineSteven Rostedt2015-04-073-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tracing infrastructure is adding a macro TRACE_SYSTEM_STRING, and hit the following build failure: In file included from include/trace/define_trace.h:90:0, from drivers/gpu/drm/.//radeon/radeon_trace.h:209, from drivers/gpu/drm/.//radeon/radeon_trace_points.c:9: >> include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined #define TRACE_SYSTEM_STRING __app(TRACE_SYSTEM_VAR,__trace_system_name) Seems that the DRM folks have added their own use to the TRACE_SYSTEM_STRING, with: #define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM) Although, I can not find its use anywhere. I could simply use another name, but if this macro is not being used, it should be removed. Link: http://lkml.kernel.org/r/20150402123736.01eda052@gandalf.local.home Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* | Merge tag 'regulator-v4.1' of ↵Linus Torvalds2015-04-131-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator updates from Mark Brown: "Another release, another set of regulator updates. Not much of it is showing up in the code yet but there's been a lot of discussion going on about how to enhance the regulator API to work better with modern SoCs which have a microcontroller sitting between Linux and the hardware. I'm hopeful that'll start to come through into mainline for v4.2 but it's not quite there for v4.1 - what we do have (along with the usual small updates is) is: - work from Bjorn Andersson on refactoring the configuration of regulator loading interfaces to be useful for use with microcontrollers, the existing interfaces were never actually useful for anything as-is since nobody was willing to put enough data into public code. - a summary tree display in debugfs from Heiko Stübner. - support for act6000 regulators" * tag 'regulator-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (34 commits) regulator: max8660: Handle empty regulator data regulator: output current-limit for all regulators in summary regulator: add a summary tree in debugfs regulator: qcom: Tidy up probe() regulator: qcom: Rework to single platform device regulator: qcom: Refactor of-parsing code regulator: qcom: Don't enable DRMS in driver regulator: max8660: fix assignment of pdata to data that becomes dead regulator: Defer lookup of supply to regulator_get mfd: max77693: Remove unused structures regulator: max77693: Let core parse DT and drop board files support regulator: Ensure unique regulator debugfs directory names regulator: stw481x: Remove unused fields from struct stw481x regulator: palmas: Add has_regen3 check for TPS659038 regulator: constify of_device_id array regulator: fixes for regulator_set_optimum_mode name change regulator: Drop temporary regulator_set_optimum_mode wrapper usb: phy: phy-msm-usb: Rename regulator_set_optimum_mode usb: phy: ab8500-usb: Rename regulator_set_optimum_mode ufs: Rename of regulator_set_optimum_mode ...
| | \
| | \
| *-. \ Merge remote-tracking branches 'regulator/topic/mode', ↵Mark Brown2015-04-101-3/+3
| |\ \ \ | | | | | | | | | | | | | | | 'regulator/topic/notifier', 'regulator/topic/palmas', 'regulator/topic/qcom' and 'regulator/topic/stw481x' into regulator-next
| | * | | regulator: fixes for regulator_set_optimum_mode name changeStephen Rothwell2015-03-101-3/+3
| | |/ / | | | | | | | | | | | | | | | | Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mark Brown <broonie@kernel.org>
* | | | Merge tag 'drm-intel-fixes-2015-04-08' of ↵Dave Airlie2015-04-092-12/+3
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes three commits, all cc: stable, to address Baytrail suspend/resume issues. * tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel: drm/i915/vlv: remove wait for previous GFX clk disable request drm/i915/chv: Remove Wait for a previous gfx force-off drm/i915/vlv: save/restore the power context base reg
| * | | | drm/i915/vlv: remove wait for previous GFX clk disable requestJesse Barnes2015-04-071-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like it was introduced in: commit 650ad970a39f8b6164fe8613edc150f585315289 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddff7a6 "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9cd7a1 "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # c9c52e24194a: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | | drm/i915/chv: Remove Wait for a previous gfx force-offDeepak S2015-04-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by: Deepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | | drm/i915/vlv: save/restore the power context base regJesse Barnes2015-04-072-0/+3
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* / / / drm: fix drm_mode_getconnector() locking imbalance regressionTommi Rantala2015-04-081-1/+3
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regression in commit 2caa80e72b57c6216aec6f6a11fcfb4fec46daa0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Feb 22 11:38:36 2015 +0100 drm: Fix deadlock due to getconnector locking changes If the drm_connector_find() call returns NULL, we should no longer call drm_modeset_unlock() to avoid locking imbalance. Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2015-04-032-7/+8
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes Just two small fixes for radeon, both destined for stable. * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: fix wait in radeon_mn_invalidate_range_start drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr
| * | | drm/radeon: fix wait in radeon_mn_invalidate_range_startChristian König2015-04-021-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to wait for all fences, not just the exclusive one. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/radeon: add extra check in radeon_ttm_tt_unpin_userptrChristian König2015-04-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We somehow try to free the SG table twice. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734 Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | | Merge branch 'exynos-drm-fixes' of ↵Dave Airlie2015-04-032-10/+15
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Fix display on issue to Exynos5250 based Snow(1366x768) board. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm: Exynos: Respect framebuffer pitch for FIMD/Mixer
| * | | | drm: Exynos: Respect framebuffer pitch for FIMD/MixerDaniel Stone2015-04-022-10/+15
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When performing a modeset, use the framebuffer pitch value to set FIMD IMG_SIZE and Mixer SPAN registers. These are both defined as pitch - the distance between contiguous lines (bytes for FIMD, pixels for mixer). Fixes display on Snow (1366x768). Signed-off-by: Daniel Stone <daniels@collabora.com> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | | Merge tag 'drm-intel-fixes-2015-04-02' of ↵Dave Airlie2015-04-032-3/+3
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes one oops fixes and a 0-length allocation fix from next backported. * tag 'drm-intel-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel: drm/i915: Reject the colorkey ioctls for primary and cursor planes drm/i915: Skip allocating shadow batch for 0-length batches
| * | | | drm/i915: Reject the colorkey ioctls for primary and cursor planesVille Syrjälä2015-04-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legcy colorkey ioctls are only implemented for sprite planes, so reject the ioctl for primary/cursor planes. If we want to support colorkeying with these planes (assuming we have hw support of course) we should just move ahead with the colorkey property conversion. Testcase: kms_legacy_colorkey Cc: Tommi Rantala <tt.rantala@gmail.com> Cc: stable@vger.kernel.org Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.com Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | | drm/i915: Skip allocating shadow batch for 0-length batchesChris Wilson2015-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 17cabf571e50677d980e9ab2a43c5f11213003ae Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 14 11:20:57 2015 +0000 drm/i915: Trim the command parser allocations we may then try to allocate a zero-sized object and attempt to extract its pages. Understandably this fails. Note that the real offender seems to be commit b9ffd80ed659c559152c042e74741f4f60cac691 Author: Brad Volkin <bradley.d.volkin@intel.com> Date: Thu Dec 11 12:13:10 2014 -0800 drm/i915: Use batch length instead of object size in command parser Testcase: igt/gem_exec_nop #ivb,byt,hsw Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [cherry picked from commit 743e78c1d726d875b98ff9689cc77c4d3d5d9ae2 from drm-intel-next because 4.0 seems to be affected by this too, despite that the obvious culprit is definitely not in 4.0. Whatever, if fixes a bug. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* | | | | Merge tag 'topic/drm-fixes-2015-04-02' of ↵Dave Airlie2015-04-032-0/+2
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes Here's a single drm core fix, cc: stable, that affects i915 users. * tag 'topic/drm-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel: drm/edid: set ELD for firmware and debugfs override EDIDs
| * | | | drm/edid: set ELD for firmware and debugfs override EDIDsJani Nikula2015-03-272-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user supplies EDID through firmware or debugfs override, the driver callbacks are bypassed and the connector ELD does not get updated, and audio fails. Set ELD for firmware and debugfs EDIDs too. There should be no harm in gratuitously doing this for non HDMI/DP connectors, as it's still up to the driver to use the ELD, if any. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691 Reported-by: Emil <emilsvennesson@gmail.com> Reported-by: Rob Engle <grenoble@gmail.com> Tested-by: Jolan Luff <jolan@gormsby.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | | drm/radeon: programm the VCE fw BAR as wellChristian König2015-03-272-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the VCE firmware needs to be in the first 256MB of VRAM. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | | | drm/radeon: always dump the ring content if it's availableChristian König2015-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dumping is still possible if a ring isn't ready, only when it isn't allocated at all we need to abort here. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | | | radeon: Do not directly dereference pointers to BIOS area.David Miller2015-03-271-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use readb() and memcpy_fromio() accessors instead. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | | | drm/radeon/dpm: fix 120hz handling harderAlex Deucher2015-03-272-5/+18
| |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Need to expand the check to handle short circuiting if the selected state is the same as current state. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87796 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | | drm/i915: Fixup legacy plane->crtc link for initial fb configDaniel Vetter2015-03-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a very similar bug in the load detect code fixed in commit 9128b040eb774e04bc23777b005ace2b66ab2a85 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Mar 3 17:31:21 2015 +0100 drm/i915: Fix modeset state confusion in the load detect code But this time around it was the initial fb code that forgot to update the plane->crtc pointer. Otherwise it's the exact same bug, with the exact same restrains (any set_config call/ioctl that doesn't disable the pipe papers over the bug for free, so fairly hard to hit in normal testing). So if you want the full explanation just go read that one over there - it's rather long ... Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: backported to drm-intel-fixes for v4.0-rc] Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915: Fix atomic state when reusing the firmware fbDamien Lespiau2015-03-261-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, we get a warning when taking over the firmware fb: [drm:drm_atomic_plane_check] FB set but no CRTC with the following backtrace: [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm] [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm] [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper] [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff813ad444>] fbcon_init+0x4f4/0x580 That's because we update the plane state with the fb from the firmware, but we never associate the plane to that CRTC. We don't quite have the full DRM take over from HW state just yet, so fake enough of the plane atomic state to pass the checks. v2: Fix the state on which we set the CRTC in the case we're sharing the initial fb with another pipe. (Matt) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: backported to drm-intel-fixes for v4.0-rc] Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915: Keep ring->active_list and ring->requests_list consistentChris Wilson2015-03-261-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we retire requests last, we may use a later seqno and so clear the requests lists without clearing the active list, leading to confusion. Hence we should retire requests first for consistency with the early return. The order used to be important as the lifecycle for the object on the active list was determined by request->seqno. However, the requests themselves are now reference counted removing the constraint from the order of retirement. Fixes regression from commit 1b5a433a4dd967b125131da42b89b5cc0d5b1f57 Author: John Harrison <John.C.Harrison@Intel.com> Date: Mon Nov 24 18:49:42 2014 +0000 drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed ' and a WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140() WARN_ON(!list_empty(&vm->active_list)) Identified by updating WATCH_LISTS: [drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230() WARN_ON(i915_verify_lists(ring->dev)) Note that this is only a problem in evict_vm where the following happens after a retire_request has cleaned out all requests, but not all active bo: - intel_ring_idle called from i915_gpu_idle notices that no requests are outstanding and immediately returns. - i915_gem_retire_requests_ring called from i915_gem_retire_requests also immediately returns when there's no request, still leaving the bo on the active list. - evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting all active objects that there's still stuff left that shouldn't be there. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915: Don't try to reference the fb in get_initial_plane_config()Damien Lespiau2015-03-251-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tvrtko noticed a new warning on boot: WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]() Call Trace: [<ffffffff8161f10c>] dump_stack+0x4f/0x7b [<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0 [<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm] [<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915] [<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915] [<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915] [<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915] [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm] [<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm] [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915] [<ffffffff813ad59c>] pci_device_probe+0x7c/0x100 [<ffffffff81466aad>] driver_probe_device+0x16d/0x380 We cannot take a reference at this point, not before intel_framebuffer_init() and the underlying drm_framebuffer_init(). Introduced in: commit 706dc7b549175e47f23e913b7f1e52874a7d0f56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb v2: Don't move update_state_fb(). It was moved around because I originally put update_state_fb() in intel_alloc_plane_obj() before finding a better place. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From drm-next: (cherry picked from commit f55548b5af87ebfc586ca75748947f1c1b1a4a52) Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | | drm: Fixup racy refcounting in plane_force_disableDaniel Vetter2015-03-241-12/+1
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit 83f45fc360c8e16a330474860ebda872d1384c8c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: stable@vger.kernel.org Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | Merge tag 'drm-intel-fixes-2015-03-19' of ↵Dave Airlie2015-03-201-4/+28
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes Backporting a couple of plane related fixes from drm-next to v4.0. * tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel: drm/i915: Make sure the primary plane is enabled before reading out the fb state drm/i915: Ensure plane->state->fb stays in sync with plane->fb
| * | | drm/i915: Make sure the primary plane is enabled before reading out the fb stateDamien Lespiau2015-03-181-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't want to end up in a state where we track that the pipe has its primary plane enabled when primary plane registers are programmed with values that look possible but the plane actually disabled. Refuse to read out the fb state when the primary plane isn't enabled. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Reported-by: Steven Rostedt <rostedt@goodmis.org> Reference: http://mid.gmane.org/20150203191507.GA2374@crion86 Tested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | drm/i915: Ensure plane->state->fb stays in sync with plane->fbXi Ruoyao2015-03-161-0/+17
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | plane->state->fb and plane->fb should always reference the same FB so that atomic and legacy codepaths have the same view of display state. However, there are some places in kernel code that directly set plane->fb and neglect to update plane->state->fb. If we never do a successful update through the atomic pipeline, the RmFB cleanup code will look at the plane->state->fb pointer, which has never actually been set to a legitimate value, and try to clean it up, leading to BUG's. Add a quick helper function to synchronize plane->state->fb with plane->fb and call it everywhere the driver tries to manually set plane->fb outside of the atomic pipeline. In this function, use drm_atomic_set_fb_for_plane instead of writing plane->state->fb directly to keep the reference count right. This is modified from Matt Roper's patch to drm-intel-nightly with commit id commit afd65eb4cc0578a9c07d621acdb8a570e2782bf7 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb However this bug exists in mainline kernel too, so I created this to fix it in mainline kernel. A minor change is to use drm_atomic_set_fb_for_plane instead of update reference count manually. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93711 Signed-off-by: Xi Ruoyao <xry111@outlook.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [Jani: included the patch notes in the commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | Merge tag 'drm-amdkfd-fixes-2015-03-19' of ↵Dave Airlie2015-03-203-11/+23
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~gabbayo/linux into drm-fixes - Fixing SDMA initialization when in non-HWS mode (debug mode) - Memory leak fix when destroying kernel queue - Fix number of available compute pipelines according to new firmware * tag 'drm-amdkfd-fixes-2015-03-19' of git://people.freedesktop.org/~gabbayo/linux: drm/radeon: Changing number of compute pipe lines drm/amdkfd: Fix SDMA queue init. in non-HWS mode drm/amdkfd: destroy mqd when destroying kernel queue
| * | | drm/radeon: Changing number of compute pipe linesBen Goz2015-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current CP firmware can handle Usermode Queues only on MEC1. To reflect this firmware change, this commit reduces number of compute pipelines to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd). Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Cc: stable@vger.kernel.org
| * | | drm/amdkfd: Fix SDMA queue init. in non-HWS modeBen Goz2015-03-161-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the SDMA queue initialization, when running in non-HWS mode. The first fix is to move the initialization of SDMA VM parameters before the initialization of the SDMA MQD. The second fix is to load the MQD to an HQD after the initialization of the MQD. Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/amdkfd: destroy mqd when destroying kernel queueBen Goz2015-03-161-9/+13
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a missing destruction of mqd, when destroying a kernel queue. Without the destruction, there is a memory leakage when repeatedly creating and destroying kernel queues. Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2015-03-191-11/+0
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes single radeon fix. * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: drop ttm two ended allocation
| * | | drm/radeon: drop ttm two ended allocationAlex Deucher2015-03-181-11/+0
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | radeon_bo_create() calls radeon_ttm_placement_from_domain() before ttm_bo_init() is called. radeon_ttm_placement_from_domain() uses the ttm bo size to determine when to select top down allocation but since the ttm bo is not initialized yet the check is always false. It only took effect when buffers were validated later. It also seemed to regress suspend and resume on some systems possibly due to it not taking effect in radeon_bo_create(). radeon_bo_create() and radeon_ttm_placement_from_domain() need to be reworked substantially for this to be optimally effective. Re-enable it at that point. Noticed-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | Merge branch 'exynos-drm-fixes' of ↵Dave Airlie2015-03-196-287/+15
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Some urgent regression fixes to booting failures Exynos DRM occured. Summary: - Fix two urgent null pointer dereference bugs in case of enabling or disabling IOMMU. There was two cases to these issues. One is that plane->crtc is accessed by exynos_disable_plane() when device tree binding is broken so device driver tries to release, which means that the mode set operation isn't invoked yet so plane->crtc is still NULL and exynos_disable_plane() will access NULL pointer. This issue is fixed by checking if the plane->crtc is NULL or not in exynos_disable_plane() Other is that fimd_wait_for_vblank() is called to avoid from page fault with IOMMU before the ctx object is created. At this time, fimd_wait_for_vblank() tries to access ctx->crtc but the ctx->crtc is still NULL because exynos_drm_crtc_create() isn't called yet. This issue is fixed by creating a crtc object and setting it to ctx->crtc prior to fimd_wait_for_vblank() call. For more details, you can refer to below an e-mail thread, http://www.spinics.net/lists/linux-samsung-soc/msg42436.html - Remove unnecessary file not used and fix trivial issues. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: fix the initialization order in FIMD drm/exynos: fix typo config name correctly. drm/exynos: Check for NULL dereference of crtc drm/exynos: IS_ERR() vs NULL bug drm/exynos: remove unused files
| * | | drm/exynos: fix the initialization order in FIMDHyungwon Hwang2015-03-181-18/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 0f04cf8df0b20a97369cb634663fef0578cbf273 ("drm/exynos: fix wrong pipe calculation for crtc"), fimd_clear_channel() can be called when is_drm_iommu_supported() returns true. In this case, the kernel is going to be panicked because crtc is not set yet. [ 1.211156] [drm] Initialized drm 1.1.0 20060810 [ 1.216785] Unable to handle kernel NULL pointer dereference at virtual address 00000350 [ 1.223415] pgd = c0004000 [ 1.226086] [00000350] *pgd=00000000 [ 1.229649] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1.234940] Modules linked in: [ 1.237982] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.246136] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.252214] task: ee8c8000 ti: ee8d0000 task.ti: ee8d0000 [ 1.257606] PC is at fimd_wait_for_vblank+0x8/0xc8 [ 1.262370] LR is at fimd_bind+0x138/0x1a8 [ 1.266450] pc : [<c02fb63c>] lr : [<c02fb834>] psr: 20000113 [ 1.266450] sp : ee8d1d28 ip : 00000000 fp : 00000000 [ 1.277906] r10: 00000001 r9 : c09d693c r8 : c0a2d6a8 [ 1.283114] r7 : 00000034 r6 : 00000001 r5 : ee0bb400 r4 : ee244c10 [ 1.289624] r3 : 00000000 r2 : 00000000 r1 : 00000001 r0 : 00000000 [ 1.296135] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 1.303426] Control: 10c5387d Table: 4000404a DAC: 00000015 [ 1.309154] Process swapper/0 (pid: 1, stack limit = 0xee8d0210) [ 1.315143] Stack: (0xee8d1d28 to 0xee8d2000) [ 1.319486] 1d20: 00000000 c0113d18 ee0bb400 ee0bb400 ee245c30 eebbe210 [ 1.327645] 1d40: ee008a40 ee244c10 ee0bb400 00000001 00000034 c02fb834 00000000 c030a858 [ 1.335804] 1d60: ee244a10 eeb60780 ee008a40 eeb60740 ee0bb400 c03030d0 00000000 00000000 [ 1.343963] 1d80: ee244a10 ee0bb400 00000000 eeb60740 eeb60810 00000000 00000000 c02f6ba4 [ 1.352123] 1da0: ee0bb400 00000000 00000000 c02e0500 ee244a00 c0a04a14 ee0bb400 c02e1de4 [ 1.360282] 1dc0: 00000000 c030a858 00000002 eeb60820 eeb60820 00000002 eeb60780 c03033d4 [ 1.368441] 1de0: c06e9cec 00000000 ee244a10 eeb60780 c0a056f8 c03035fc c0a04b24 c0a04b24 [ 1.376600] 1e00: ee244a10 00000001 c0a049d0 c02f6d34 c0ad462c eeba0790 00000000 ee244a10 [ 1.384759] 1e20: ffffffed c0a049d0 00000000 c03090b0 ee244a10 c0ad462c c0a2d840 c03077a0 [ 1.392919] 1e40: eeb5e880 c024b738 000008db ee244a10 c0a049d0 ee244a44 00000000 c09e71d8 [ 1.401078] 1e60: 000000c6 c0307a6c c0a049d0 00000000 c03079e0 c0305ea8 ee826e5c ee1dc7b4 [ 1.409237] 1e80: c0a049d0 eeb5e880 c0a058a8 c0306e2c c0896204 c0a049d0 c06e9d10 c0a049d0 [ 1.417396] 1ea0: c06e9d10 c0ad4600 00000000 c0308360 00000000 00000003 c06e9d10 c02f6e14 [ 1.425555] 1ec0: 00000000 c0896204 ffffffff 00000000 00000000 00000000 00000000 00000000 [ 1.433714] 1ee0: 00000000 00000000 c02f6d5c c02f6d5c 00000000 eeb5d740 c09e71d8 c0008a30 [ 1.441874] 1f00: ef7fca5e 00000000 00000000 00000066 00000000 ee8d1f28 c003ff1c c02514e8 [ 1.450033] 1f20: 60000113 ffffffff c093906c ef7fca5e 000000c6 c004018c 00000000 c093906c [ 1.458192] 1f40: c08a9690 c093840c 00000006 00000006 c09eb2ac c09c0d74 00000006 c09c0d54 [ 1.466351] 1f60: c0a3d680 c09745a0 c09d693c 000000c6 00000000 c0974db4 00000006 00000006 [ 1.474510] 1f80: c09745a0 ffffffff 00000000 c0692e00 00000000 00000000 00000000 00000000 [ 1.482669] 1fa0: 00000000 c0692e08 00000000 c000f040 00000000 00000000 00000000 00000000 [ 1.490828] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.498988] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [ 1.507159] [<c02fb63c>] (fimd_wait_for_vblank) from [<c02fb834>] (fimd_bind+0x138/0x1a8) [ 1.515313] [<c02fb834>] (fimd_bind) from [<c03030d0>] (component_bind_all+0xc4/0x20c) [ 1.523209] [<c03030d0>] (component_bind_all) from [<c02f6ba4>] (exynos_drm_load+0xa0/0x140) [ 1.531632] [<c02f6ba4>] (exynos_drm_load) from [<c02e0500>] (drm_dev_register+0xa0/0xf4) [ 1.539788] [<c02e0500>] (drm_dev_register) from [<c02e1de4>] (drm_platform_init+0x44/0xcc) [ 1.548121] [<c02e1de4>] (drm_platform_init) from [<c03033d4>] (try_to_bring_up_master.part.1+0xc8/0x104) [ 1.557668] [<c03033d4>] (try_to_bring_up_master.part.1) from [<c03035fc>] (component_master_add_with_match+0xd0/0x118) [ 1.568431] [<c03035fc>] (component_master_add_with_match) from [<c02f6d34>] (exynos_drm_platform_probe+0xf0/0x118) [ 1.578847] [<c02f6d34>] (exynos_drm_platform_probe) from [<c03090b0>] (platform_drv_probe+0x48/0x98) [ 1.588052] [<c03090b0>] (platform_drv_probe) from [<c03077a0>] (driver_probe_device+0x140/0x380) [ 1.596902] [<c03077a0>] (driver_probe_device) from [<c0307a6c>] (__driver_attach+0x8c/0x90) [ 1.605321] [<c0307a6c>] (__driver_attach) from [<c0305ea8>] (bus_for_each_dev+0x54/0x88) [ 1.613480] [<c0305ea8>] (bus_for_each_dev) from [<c0306e2c>] (bus_add_driver+0xec/0x200) [ 1.621640] [<c0306e2c>] (bus_add_driver) from [<c0308360>] (driver_register+0x78/0xf4) [ 1.629625] [<c0308360>] (driver_register) from [<c02f6e14>] (exynos_drm_init+0xb8/0x11c) [ 1.637785] [<c02f6e14>] (exynos_drm_init) from [<c0008a30>] (do_one_initcall+0xac/0x1ec) [ 1.645950] [<c0008a30>] (do_one_initcall) from [<c0974db4>] (kernel_init_freeable+0x194/0x268) [ 1.654626] [<c0974db4>] (kernel_init_freeable) from [<c0692e08>] (kernel_init+0x8/0xe4) [ 1.662699] [<c0692e08>] (kernel_init) from [<c000f040>] (ret_from_fork+0x14/0x34) [ 1.670246] Code: eaffffd5 c09df884 e92d40f0 e24dd01c (e5905350) [ 1.676408] ---[ end trace 804468492f306a6f ]--- [ 1.680948] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.680948] [ 1.690035] CPU1: stopping [ 1.692727] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.702097] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.708192] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14) [ 1.715908] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8) [ 1.723108] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4) [ 1.730485] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c) [ 1.738036] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74) [ 1.745498] Exception stack(0xee8fdf98 to 0xee8fdfe0) [ 1.750533] df80: 00000000 00000000 [ 1.758695] dfa0: ee8fdfe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4 [ 1.766853] dfc0: c0a27a74 c09df940 01000000 ee8fdfe0 c00101c0 c00101c4 60000113 ffffffff [ 1.775015] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c) [ 1.782397] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324) [ 1.790639] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764) [ 1.797579] CPU0: stopping [ 1.800272] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.809642] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.815730] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14) [ 1.823450] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8) [ 1.830653] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4) [ 1.838030] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c) [ 1.845581] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74) [ 1.853043] Exception stack(0xc09ddf60 to 0xc09ddfa8) [ 1.858081] df60: 00000000 00000000 c09ddfb0 c0021780 c09df938 00000001 ffffffff c0a3d680 [ 1.866239] df80: c09c0dec c09df8d4 c0a27a74 c09df940 01000000 c09ddfa8 c00101c0 c00101c4 [ 1.874396] dfa0: 60000113 ffffffff [ 1.877872] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c) [ 1.885251] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324) [ 1.893499] [<c005e804>] (cpu_startup_entry) from [<c0974bc8>] (start_kernel+0x324/0x37c) [ 1.901655] [<c0974bc8>] (start_kernel) from [<40008074>] (0x40008074) [ 1.908161] CPU3: stopping [ 1.910855] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.920225] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.926313] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14) [ 1.934034] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8) [ 1.941237] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4) [ 1.948613] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c) [ 1.956165] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74) [ 1.963626] Exception stack(0xee901f98 to 0xee901fe0) [ 1.968661] 1f80: 00000000 00000000 [ 1.976823] 1fa0: ee901fe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4 [ 1.984982] 1fc0: c0a27a74 c09df940 01000000 ee901fe0 c00101c0 c00101c4 60000113 ffffffff [ 1.993143] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c) [ 2.000522] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324) [ 2.008765] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764) [ 2.015710] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | | drm/exynos: fix typo config name correctly.Inki Dae2015-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This patch fixes DRM_EXYNOS7DECON to DRM_EXYNOS7_DECON. Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | | drm/exynos: Check for NULL dereference of crtcCharles Keepax2015-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the use of the enabled flag, which means that the code may attempt to call win_enable on a NULL crtc. This results in the following oops on Arndale: [ 1.673479] Unable to handle kernel NULL pointer dereference at virtual address 00000368 [ 1.681500] pgd = c0004000 [ 1.684154] [00000368] *pgd=00000000 [ 1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1.693012] Modules linked in: [ 1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.19.0-07545-g57485fa #1907 [ 1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (....) [ 2.014803] [<c02f9cfc>] (exynos_plane_destroy) from [<c02e61b4>] (drm_mode_config_cleanup+0x168/0x20c) [ 2.024178] [<c02e61b4>] (drm_mode_config_cleanup) from [<c02f66fc>] (exynos_drm_load+0xac/0x12c) This patch adds in a check to ensure exynos_crtc is not NULL before it is dereferenced. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | | drm/exynos: IS_ERR() vs NULL bugDan Carpenter2015-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of_iomap() doesn't return error pointers, it returns NULL on error. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | | drm/exynos: remove unused filesAndrzej Hajda2015-03-182-265/+0
| |/ / | | | | | | | | | | | | | | | | | | These files are not used anymore. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/nouveau/bios: fix i2c table parsing for dcb 4.1Stefan Huehner2015-03-171-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Code before looked only at bit 31 to decide if a port is unused. However dcb 4.1 spec says 0x1F in bits 31-27 and 26-22 means unused. This fixed hdmi monitor detection on GM206. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)Stefan Huehner2015-03-171-0/+43
| | | | | | | | | | | | | | | | | | | | | Enough to get VGA monitor on DVI-I output have output. HDMI output not yet working Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switchBen Skeggs2015-03-171-2/+4
| | | | | | | | | | | | | | | | | | fdo#88868 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addressesBen Skeggs2015-03-173-6/+6
| | | | | | | | | | | | | | | | | | fdo#83992 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | drm/nouveau/fifo/nv04: remove the loop from the interrupt handlerBen Skeggs2015-03-171-50/+35
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Complete bong hit (and not the last...), the hardware will reassert the interrupt to PMC if it's necessary. Also potentially harmful in the face of interrupts such as the non-stall interrupt, which remain active in NV_PFIFO_INTR even when we don't care about servicing it. It appears (hopefully, fdo#87244), that under certain loads, the methods may pass quickly enough to hit the "100 spins and kill PFIFO" thing that we had going on. Not ideal ;) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | [PATCH] drm/mm: Fix support 4 GiB and larger rangesKrzysztof Kolasa2015-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | bad argument if(tmp)... in check_free_hole fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305! [airlied: excellent, this was my task for today]. Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 20:17:44 +0000