summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-01-26drm/i915/error: Support user specified BOsextra_error_objsBen Widawsky9-4/+68
The patch collects objects specified by userspace as a result of a new flag in the exec2 object structure. Upon seeing this flag, the driver will remember the specified objects, and dump them out on GPU hang. It was tempting to use the reloc structure, but there was no space. This is primarily desirable for getting the hanging shaders, especially when the test case isn't easily reproducible. In accomplishing this, it should add no measurable overhead to the existing paths. See the associated libdrm and mesa patches for usage. Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2015-01-23drm-intel-nightly: 2015y-01m-23d-16h-04m-34s UTC integration manifestDaniel Vetter1-0/+20
2015-01-23Merge remote-tracking branch 'sound-upstream/for-next' into drm-intel-nightlyDaniel Vetter211-4170/+2922
2015-01-23Merge remote-tracking branch 'origin/topic/atomic-core' into drm-intel-nightlyDaniel Vetter7-21/+298
2015-01-23Merge remote-tracking branch 'origin/topic/core-stuff' into drm-intel-nightlyDaniel Vetter19-103/+238
2015-01-23Merge remote-tracking branch 'drm-upstream/drm-next' into drm-intel-nightlyDaniel Vetter484-3704/+12998
2015-01-23Merge remote-tracking branch 'origin/drm-intel-fixes' into drm-intel-nightlyDaniel Vetter8-41/+43
2015-01-23drm/i915: Use symbolic irqreturn for ->hpd_pulseDaniel Vetter3-9/+13
Self-explanatory code is better code. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-23drm/i915/dsi: add some constness to vbt panel driverJani Nikula1-8/+9
Const is good for you. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-23drm/i915/dsi: remove unnecessary dsi device callbacksJani Nikula3-92/+5
Remove all the trivial and/or dummy callbacks from intel dsi device ops. Merge send_otp_cmds into panel_reset as they're called back to back. This will be helpful for switching to use drm_panel for the callbacks. If we ever need the additional callbacks, we should add them to drm_panel funcs. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com> [danvet: Resolve tiny conflict with ongoing atomic work.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-23drm/i915/dsi: call wait_for_dsi_fifo_empty() for each dsi portJani Nikula2-19/+10
Add port parameter to wait_for_dsi_fifo_empty, and call it for each dsi port. We can now remove the transitional intel_dsi_pipe_to_port() function. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-23drm/i915/dsi: move wait_for_dsi_fifo_empty to intel_dsi.cJani Nikula3-17/+16
wait_for_dsi_fifo_empty can be static in intel_dsi.c. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-23drm/i915/dsi: set max return packet size for each dsi portJani Nikula1-5/+5
This seems like the right thing to do. This also gets rid of a call to intel_dsi_pipe_to_port() which we want to remove eventually. v2: add braces to fix else logic (Shobhit) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-23drm/i915/dsi: call dpi_send_cmd() for each dsi port at a higher levelJani Nikula3-19/+16
Instead of having the for each dsi port loop within dpi_send_cmd(), add a port parameter to the function and call it for each port instead. This is a rewrite of commit 4510cd779e5897eeb8691aecbd639bb62ec27d55 Author: Gaurav K Singh <gaurav.k.singh@intel.com> Date: Thu Dec 4 10:58:51 2014 +0530 drm/i915: Dual link needs Shutdown and Turn on packet for both ports to add more flexibility in using dpi_send_cmd() for just one port as necessary. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-23drm/atomic: Fix potential use of state after freeAnder Conselvan de Oliveira1-0/+3
The atomic helpers rely on drm_atomic_state_clear() to reset an atomic state if a retry is needed due to the w/w mutexes. The subsequent calls to drm_atomic_get_{crtc,plane,...}_state() would then return the stale pointers in state->{crtc,plane,...}_states. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-22drm/atomic-helper: debug output for modesetsDaniel Vetter1-1/+21
With the combination of ->enable and ->active it's a bit complicated to follow what exactly is going on sometimes within a full modeset. Add debug output to make this all traceable. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-22drm/atomic-helpers: Saner encoder/crtc callbacksDaniel Vetter2-7/+30
For historical reasons going all the way back to how the Xrandr code was implemented the semantics of the callbacks used to enable/disable crtcs and encoders are ... interesting. But with atomic helpers all that complexity has been binned, with only a well-defined on/off action left. Unfortunately the names stuck. Let's fix that by adding enable/disable hooks every, make them the preferred variant for atomic and update documentations. Later on we add debug warnings when drivers have deprecated hooks. But while everything is in-flight with lots of drivers converting to atomic that's a bit too much - better wait for things to settle a bit first. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-22drm/atomic-helpers: Recover full cursor plane behaviourDaniel Vetter2-0/+13
Cursor plane updates have historically been fully async and mutliple updates batched together for the next vsync. And userspace relies upon that. Since implementing a full queue of async atomic updates is a bit of work lets just recover the cursor specific behaviour with a hint flag and some hacks to drop the vblank wait. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-22drm/atomic-helper: add connector->dpms() implementationDaniel Vetter2-0/+77
This builds on top of the crtc->active infrastructure to implement legacy DPMS. My choice of semantics is somewhat arbitrary, but the entire pipe is enabled as along as one output is still enabled. Of course it also clamps everything that's not ON to OFF. v2: Fix spelling in one comment. v3: Don't do an async commit (Thierry) Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-22drm/atomic: Add drm_crtc_state->activeDaniel Vetter4-7/+78
This is the infrastructure for DPMS ported to the atomic world. Fundamental changes compare to legacy DPMS are: - No more per-connector dpms state, instead there's just one per each display pipeline. So if you clone either you have to unclone first if you only want to switch off one screen, or you just switch of everything (like all desktops do). This massively reduces complexity for cloning since now there's no more half-enabled cloned configs to consider. - Only on/off, dpms standby/suspend are as dead as real CRTs. Again reduces complexity a lot. Now especially for backwards compat the really important part for dpms support is that dpms on always succeeds (except for hw death and unplugged cables ofc). Which means everything that could fail (like configuration checking, resources assignments and buffer management) must be done irrespective from ->active. ->active is really only a toggle to change the hardware state. More precisely: - Drivers MUST NOT look at ->active in their ->atomic_check callbacks. Changes to ->active MUST always suceed if nothing else changes. - Drivers using the atomic helpers MUST NOT look at ->active anywhere, period. The helpers will take care of calling the respective enable/modeset/disable hooks as necessary. As before the helpers will carefully keep track of the state and not call any hooks unecessarily, so still no double-disables or enables like with crtc helpers. - ->mode_set hooks are only called when the mode or output configuration changes, not for changes in ->active state. - Drivers which reconstruct the state objects in their ->reset hooks or through some other hw state readout infrastructure must ensure that ->active reflects actual hw state. This just implements the core bits and helper logic, a subsequent patch will implement the helper code to implement legacy dpms with this. v2: Rebase on top of the drm ioctl work: - Move crtc checks to the core check function. - Also check for ->active_changed when deciding whether a modeset might happen (for the ALLOW_MODESET mode). - Expose the ->active state with an atomic prop. v3: Review from Rob - Spelling fix in comment. - Extract needs_modeset helper to consolidate the ->mode_changed || ->active_changed checks. v4: Fixup fumble between crtc->state and crtc_state. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-22drm: Add standardized boolean propsDaniel Vetter2-3/+65
Not a new type exposed to userspace, just a standard way to create them since between range, bitmask and enum there's 3 different ways to pull out a boolean prop. Also add the kerneldoc for the recently added new prop types, which Rob forgot all about. v2: Fixup kerneldoc, spotted by Rob. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-22drm/i915: Change VLV WIZ hashing mode to 16x4Ville Syrjälä1-0/+11
We set the WIZ hashing mode to 16x4 for all the other gen6+ platfotrms, so let's follow suit on VLV. My VLV is AWOL currently so I didn't test this, but since the results for all the other platforms agree that 16x4 is the fastest we might assume the same holds for VLV. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-22drm/i915: Change CHV WIZ hashing mode to 16x4Ville Syrjälä1-0/+12
I ran a few tests with xonotic and synmark2 trying out the different WIZ hashing modes on CHV. The results seem to match the results I got with IVB/HSW when I did the similar tests on them in the past. That is 16x4 is generally the fastest mode, 8x8 comes next and finally 8x4. On CHV the difference between the modes is at most ~1% in most tests. IIRC on IVB/HSW the difference was a little bigger, but as there doesn't seem to be any real downside to 16x4 let's use it by default. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-22drm/i915: Drop some more CHV pre-production workaroundsVille Syrjälä1-5/+1
Drop WaDisablePwrmtrEvent:chv as it's no longer needed. Also remove the WaSetMaskForGfxBusyness:chv note, but we still leave the GEN6_RP_MEDIA_IS_GFX bit enabled as that's still the recommended setting. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-22drm/i915: Implement Wa4x4STCOptimizationDisable:chvVille Syrjälä1-0/+4
Wa4x4STCOptimizationDisable got only implemented for BDW, but according to the w/a database CHV needs it too, so add it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-22drm/probe-helper: clamp unknown connector status in the poll workDaniel Vetter1-0/+18
On some chipset we try to avoid possibly invasive output detection methods (like load detect which can cause flickering elsewhere) in the output poll work. Drivers could hence return unknown when a previous full ->detect call returned a different state. This change will generate a hotplug event, forcing userspace to do a full scan. This in turn updates the connector->status field so that we will _again_ get a state change when the hotplug work re-runs in 10 seconds. To avoid this ping-pong loop detect this situation and clamp the connector state to the old value. Patch is inspired by a patch from Knut Peterson. Knut's patch completely ignored connector state changes if either the old or new status was unknown, which seemed to be a bit too agressive to me. v2: Rebased onto the drm_probe_helper.c extraction. References: http://lists.freedesktop.org/archives/dri-devel/2012-August/025975.html Cc: Knut Petersen <Knut_Petersen@t-online.de> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Alex Deucher <alexander.deucher@amd.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-22drm/probe-helper: don't lose hotplug eventDaniel Vetter2-2/+35
There's a race window (small for hpd, 10s large for polled outputs) where userspace could sneak in with an unrelated connnector probe ioctl call and eat the hotplug event (since neither the hpd nor the poll code see a state change). To avoid this, check whether the connector state changes in all other ->detect calls (in the current helper code that's only probe_single) and if that's the case, fire off a hotplug event. Note that we can't directly call the hotplug event handler, since that expects that no locks are held (due to reentrancy with the fb code to update the kms console). Also, this requires that drivers using the probe_single helper function set up the poll work. All current drivers do that already, and with the reworked hpd handling there'll be no downside to unconditionally setting up the poll work any more. v2: Review from Rob Clark - Don't bail out of the output poll work immediately if it's disabled to make sure we deliver the delayed hoptplug events. Instead just jump to the tail. - Don't scheduel the work when it's not set up. Would be a driver bug since using probe helpers for anything dynamic without them initialized makes them all noops. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Tested-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-22Merge remote-tracking branch 'origin/master' into drm-nextDave Airlie551-2821/+5301
Backmerge Linus tree after rc5 + drm-fixes went in. There were a few amdkfd conflicts I wanted to avoid, and Ben requested this for nouveau also. Conflicts: drivers/gpu/drm/amd/amdkfd/Makefile drivers/gpu/drm/amd/amdkfd/kfd_chardev.c drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c drivers/gpu/drm/amd/amdkfd/kfd_priv.h drivers/gpu/drm/amd/include/kgd_kfd_interface.h drivers/gpu/drm/i915/intel_runtime_pm.c drivers/gpu/drm/radeon/radeon_kfd.c
2015-01-22Merge branch 'drm-sti-next-add-dvo' of ↵Dave Airlie6-0/+920
git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next This patch enable the last big hardware feature of my driver: the connector for panel. Like for HMDI and HDA, Digital Video Out (DVO) create brige, encoder and connector drm objects. * 'drm-sti-next-add-dvo' of git://git.linaro.org/people/benjamin.gaignard/kernel: drm: sti: add DVO output connector
2015-01-22Merge tag 'atmel-hlcdc-drm-3.20' of https://github.com/bbrezillon/linux-at91 ↵Dave Airlie15-0/+3561
into drm-next Add atmel HLCDC driver. * tag 'atmel-hlcdc-drm-3.20' of https://github.com/bbrezillon/linux-at91: drm: add DT bindings documentation for atmel-hlcdc-dc driver drm: add Atmel HLCDC Display Controller support drm: panel: simple-panel: add bus format information for foxlink panel drm: panel: simple-panel: add support for bus_format retrieval drm: add bus_formats and num_bus_formats fields to drm_display_info
2015-01-22Merge tag 'drm-amdkfd-next-2015-01-21' of ↵Dave Airlie27-985/+1387
git://people.freedesktop.org/~gabbayo/linux into drm-next - Infrastructure work in amdkfd to prepare for VI support. This work mainly includes separating modules into ASIC-specific functionality, adding new properties that are relevant for VI, making sure that shared code is reused, etc. - Improve mechanism of submitting packets to HIQ (the kernel queue that amdkfd uses to issue commands to the GPU). The driver used to verify that each CS was read by the GPU. However, this proved to be both unnecessary and erroneous. Therefore, we cancelled this verification. - Moved initialization of compute VMIDs into radeon driver - Various minor fixes * tag 'drm-amdkfd-next-2015-01-21' of git://people.freedesktop.org/~gabbayo/linux: (22 commits) drm/amdkfd: Fix description of sched_policy module parameter drm/amdkfd: Remove sync_with_hw() from amdkfd drm/amdkfd: Remove unused function busy_wait() drm/amdkfd: Replace cpu_relax() with schedule() in DQM drm/amdkfd: Fix for-loop when allocating HQD (non-HWS) drm/amdkfd: Add initial VI support for KQ drm/amdkfd: Encapsulate KQ functions in ops structure drm/amdkfd: Add initial VI support for DQM drm/amdkfd: Encapsulate DQM functions in ops structure drm/amdkfd: Don't BUG on freeing GART sub-allocation drm/amdkfd: Fix logic of destroy_queue_nocpsch() MAINTAINERS: Update amdkfd files drm/amdkfd: Change MQD manager to be H/W specific drm/amdkfd: Add asic property to kfd_device_info drm/amdkfd: Make KFD_MQD_TYPE enum types H/W agnostic drm/amdkfd: Add new VI-specific queue properties drm/radeon: Use new cik_structs.h file drm/amdkfd: Don't include header files from radeon drm/amd: Put cik structures in a common place drm/radeon: Don't use relative paths in #include ...
2015-01-21drm/i915: BDW Fix Halo PCI IDs marked as ULT.Rodrigo Vivi1-2/+1
BDW with PCI-IDs ended in "2" aren't ULT, but HALO. Let's fix it and at least allow VGA to work on this units. v2: forgot ammend and v1 doesn't compile Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220 Cc: Xion Zhang <xiong.y.zhang@intel.com> Cc: Guo Jinxian <jinxianx.guo@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-01-21drm/i915: Fix and clean BDW PCH identificationRodrigo Vivi1-10/+4
It seems in the past we have BDW with PCH not been propperly identified and we force it to be LPT and we were warning !IS_HASWELL on propper identification. Now that products are out there we are receiveing logs with this incorrect WARN. And also according to local tests on all production BDW here ULT or HALO we don't need this force anymore. So let's clean this block for real. v2: Fix LPT_LP WARNs to avoid wrong warns on BDW_ULT (By Jani). Reference: https://bugs.freedesktop.org/attachment.cgi?id=110972 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Xion Zhang <xiong.y.zhang@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-01-22Merge tag 'trace-sh-3.19' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull superh tracing fix from Steven Rostedt: "It's been reported that function tracing does not work on the sh architecture because gcc 4.8 for superH does not support -m32, and the recordmcount.pl script adds "-m32" when re-compiling the object files with the mcount locations. I was not able to reproduce this problem, as it seems that -m32 works fine for my cross compiler gcc 4.6.3, but I have to assume that -m32 was deprecated somewhere between 4.6 and 4.8. As it still seems to compile fine without -m32, I have no reason not to add this patch, as having -m32 seems to cause trouble for others" * tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore
2015-01-21drm/i915: Only fence tiled region of object.Bob Paauwe1-0/+7
When creating a fence for a tiled object, only fence the area that makes up the actual tiles. The object may be larger than the tiled area and if we allow those extra addresses to be fenced, they'll get converted to addresses beyond where the object is mapped. This opens up the possiblity of writes beyond the end of object. To prevent this, we adjust the size of the fence to only encompass the area that makes up the actual tiles. The extra space is considered un-tiled and now behaves as if it was a linear object. Testcase: igt/gem_tiled_fence_overflow Reported-by: Dan Hettena <danh@ghs.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-01-21drm/i915: fix inconsistent brightness after resumeJeremiah Mahler1-1/+1
commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness introduced a bug which resulted in inconsistent brightness levels on different machines. If a suspended was entered with the screen off some machines would resume with the screen at minimum brightness and others at maximum brightness. The following commands can be used to produce this behavior. xset dpms force off sleep 1 sudo systemctl suspend (resume ...) The root cause of this problem is a comparison which checks to see if the backlight level is zero when the panel is enabled. If it is zero, it is set to the maximum level. Unfortunately, not all machines have a minimum level of zero. On those machines the level is left at the minimum instead of begin set to the maximum. Fix the bug by updating the comparison to check for the minimum backlight level instead of zero. Also, expand the comparison for the possible case when the level is less than the minimum. Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness") Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-01-21drm/i915: Init PPGTT before context enableDavid Woodhouse1-13/+6
Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing ppgtt") introduced a regression on Broadwell, triggering the following IOMMU fault at startup: vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem dmar: DRHD: handling fault status reg 2 dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000 DMAR:[fault reason 23] Unknown fbcon: inteldrmfb (fb0) is primary device Further commentary from Daniel: I sugggested this change to David after staring at the offending patch for a while. I have no idea and theory whatsoever why this would upset the gpu less than the other way round. But it seems to work. David promised to chase hw people a bit more to get a more meaningful answer. Wrt the comment that this deletes: I've done some digging and afaict loading context before ppgtt enable was once required before our recent restructuring of the context/ppgtt init code: Before that context sw setup (i.e. allocating the default context) and hw setup was smashed together. Also the setup of the default context was the bit that actually allocated the aliasing ppgtt structures. Which is the reason for the context before ppgtt depency. Or was, since with all the untangling there's no no real depency any more (functional, who knows what the hw is doing), so the comment is just stale. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-01-21drm/i915: Simplify flush_cpu_write_domainDaniel Vetter1-8/+6
We can push down the decision whether to force flushing into the implementation since in all places that matter obj->pin_display is accurate already. The only place where the optimization really matters is the sw_finish_ioctl, and that already checks for obj->pin_display on its own. I suspect that this was simply an artifact of how commit 2c22569bba8af6c2976d5f9479fe54a53a39966b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Aug 9 12:26:45 2013 +0100 drm/i915: Update rules for writing through the LLC with the cpu evolved - only v2 added the pin_display tracking. Note that we still retain the gist of this logic from the above commit with the explicit force argument for the low-level clflush function. Ville noted in his review that there's a slight behavioural change in the set_to_gtt_domain function, which now also will flush display plane data. This opens-open the potential for userspace to start doing buggy things by omitting the sw_finish_ioctl, which is why I've rejected a functional equivalent patch from Ville a while ago: http://lists.freedesktop.org/archives/intel-gfx/2013-November/036421.html But on second consideration it's not that evil, and in any case the justification here is more clarity, not allowing crazy userspace. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm/i915: Use sizeof(*fb) not sizeof(struct ...) in get_initial_plane_config()Damien Lespiau1-3/+3
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21next: drm/atomic: Use copy_from_user to copy 64 bit data from user spaceGuenter Roeck1-1/+3
Copying 64 bit data from user space using get_user is not supported on all architectures, and may result in the following build error. ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined! Avoid the problem by using copy_from_user. Fixes: d34f20d6e2f2 ("drm: Atomic modeset ioctl") Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm: Make drm_read() more robust against multithreaded racesChris Wilson1-47/+42
The current implementation of drm_read() faces a number of issues: 1. Upon an error, it consumes the event which may lead to the client blocking. 2. Upon an error, it forgets about events already copied 3. If it fails to copy a single event with O_NONBLOCK it falls into a infinite loop of reporting EAGAIN. 3. There is a race between multiple waiters and blocking reads of the events list. Here, we inline drm_dequeue_event() into drm_read() so that we can take the spinlock around the list walking and event copying, and importantly reorder the error handling to avoid the issues above. Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Takashi Iwai <tiwai@suse.de> Testcase: igt/drm_read Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm/fb-helper: Propagate errors from initial config failureThierry Reding13-51/+140
Make drm_fb_helper_initial_config() return an int rather than a bool so that the error can be properly propagated. While at it, update drivers to propagate errors further rather than just ignore them. v2: - cirrus: No cleanup is required, the top-level cirrus_driver_load() will do it as part of cirrus_driver_unload() in its cleanup path. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> [danvet: Squash in simplification patch from kbuild.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"Geert Uytterhoeven2-2/+0
commit 765d5b9c2b72f5b9 ("fbdev: fbcon: select VT_HW_CONSOLE_BINDING") made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot to remove select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE from the individual drivers' sections that already did this before. Remove it, also from new drivers. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm/i915: Fix kzalloc() smatch warnings in get_initial_plane_config()Damien Lespiau1-6/+15
Smatch doesn't like: struct drm_framebuffer *fb; fb = kzalloc(sizeof(struct intel_framebuffer), GFP_KERNEL); and warns with: warn: struct type mismatch 'drm_framebuffer vs intel_framebuffer' This implicit cast was correct as struct intel_framebuffer has struct drm_framebuffer as its first member, but in case someone want to reorder the fields for some reason, it's slightly safer to access the underlying drm_framebuffer through intel_fb->base. Also, having fewer static analysis warnings is a worthy goal. Cc: kbuild@01.org Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm/i915: Performed deferred clflush inside set-cache-levelChris Wilson2-22/+10
Currently we are hitting the WARN inside i915_gem_object_set_cache_level() as we can now have an unbound object in the GTT write domain (due to 43566dedde54f9 "drm/i915: Broaden application of set-domain(GTT)"). To avoid the warning, we need to track when we elided the clflush on a cacheable object and then evict the cache for the object when we move the object out of a cacheable domain. Reported-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Jani Nikula <jani.nikula@intel.com> Testcase: igt/gem_mmap_wc/set-cache-level Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88607 Tested-by: huax.lu@intel.com [danvet: Split if into nested if as discussion on the m-l.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm: add DT bindings documentation for atmel-hlcdc-dc driverBoris Brezillon1-0/+53
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display controller device. The HLCDC block provides a single RGB output port, and only supports LCD panels connection to LCD panels for now. The atmel,panel property link the HLCDC RGB output with the LCD panel connected on this port (note that the HLCDC RGB connector implementation makes use of the DRM panel framework). Connection to other external devices (DRM bridges) might be added later by mean of a new atmel,xxx (atmel,bridge) property. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-21drm: add Atmel HLCDC Display Controller supportBoris Brezillon11-0/+3459
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display controller device. This display controller supports at least one primary plane and might provide several overlays and an hardware cursor depending on the IP version. At the moment, this driver only implements an RGB connector to interface with LCD panels, but support for other kind of external devices might be added later. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Tested-by: Anthony Harivel <anthony.harivel@emtrion.de> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-21drm: panel: simple-panel: add bus format information for foxlink panelBoris Brezillon1-0/+1
Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Thierry Reding <treding@nvidia.com>
2015-01-21drm: panel: simple-panel: add support for bus_format retrievalBoris Brezillon1-0/+5
Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Thierry Reding <treding@nvidia.com>
2015-01-21drm: add bus_formats and num_bus_formats fields to drm_display_infoBoris Brezillon2-0/+43
Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw RGB or LVDS busses). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Thierry Reding <treding@nvidia.com>