- 27 Nov, 2014 3 commits
-
-
Rob Clark authored
Signed-off-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rob Clark authored
Add helper macros to iterate the current, or incoming set of planes attached to a crtc. These helpers are only available for drivers converted to use atomic-helpers. Signed-off-by:
-
Rob Clark authored
Chasing plane->state->crtc of planes that are *not* part of the same atomic update is racy, making it incredibly awkward (or impossible) to do something simple like iterate over all planes and figure out which ones are attached to a crtc. Solve this by adding a bitmask of currently attached planes in the crtc-state. Note that the transitional helpers do not maintain the plane_mask. But they only support the legacy ioctls, which have sufficient brute-force locking around plane updates that they can continue to loop over all planes to see what is attached to a crtc the old way. Signed-off-by:
-
- 25 Nov, 2014 10 commits
-
-
Thierry Reding authored
The current state of CRTCs, planes and connectors currently leaks during DRM driver ->unload() unless drivers explicitly clean it up. Since there is nothing driver-specific about it, that cleanup can be done within the DRM core. Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Thierry Reding authored
This header file makes use of a bunch of structures declared in the drm_crtc.h header file. Include that to make sure the drm_atomic.h header can be included standalone. Signed-off-by:
-
Thierry Reding authored
This header uses a bunch of declarations from the drm/drm_crtc.h header, so make sure to include that as well so that drm_atomic_helper.h can be included standalone. Reviewed-by:
-
Thierry Reding authored
The plane helpers aren't pulled into the DocBook yet, so these weren't noticed. Reviewed-by:
-
Thierry Reding authored
In most situations it will be useful to have the old state passed to the ->atomic_update() callback. For example if a plane is being disabled the new state's .crtc field will be NULL, but some drivers may rely on this field to program the CRTCs registers. v2: rename variable to old_plane_state and remove redundant comment as suggested by Daniel Vetter, remove an Exynos hunk that doesn't apply to drm-next and add a hunk for pending MSM mdp5 changes Reviewed-by:
-
Jasper St. Pierre authored
The drm core can call the plane disable hook multiple times, which means it can get called when plane->crtc is already NULL. That in turn means we can't get at the implicit acquire ctx we use in the atomic helpers for legacy entries points. We could try to pass drm_modeset_legacy_acquire_ctx a drm_device pointer so that it can cope with a NULL crtc. But that still doesn't work since the cursor ioctls (remapped with the universal cursor plane support code) only grabs the crtc locks. So the global acquire context isn't set eitehr. The real solution here would be to bite the bullet and wire up explicit acquire context parameters to all relevant functions. We need to do that anyway (to be able to get rid of some small allocations which we can't cope with failing). But that's a lot of work and better done once atomic has settled a bit. So meanwhile just catch this case in the helper and bail out. Signed-off-by:
Jasper St. Pierre <jstpierre@mecheye.net> Reviewed-by:
-
Daniel Vetter authored
I've forgotten to remove that in my per-plane locking patch. Reported-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Especially with legacy cursor ioctls existing userspace assumes that you can pile up lots of updates in one go. The super-proper way to support this would be a special commit mode which overwrites the last update. But getting there will be quite a bit of work. Meanwhile do what pretty much all the drivers have done for the plane update functions: Simply skip the vblank wait for the buffer cleanup if the buffer is the same. Since the universal cursor plane code will not recreate framebuffers needlessly this allows us to not slow down legacy pageflip events while someone moves the cursor around. v2: Drop the async plane update hunk from a previous attempt at this issue. v3: Fix up kerneldoc. v4: Don't oops so badly. Reported by Jasper. Cc: Rob Clark <robdclark@gmail.com> Cc: "Jasper St. Pierre" <jstpierre@mecheye.net> Reviewed-by:
-
Daniel Vetter authored
Possible for purely virtual debug devices. Signed-off-by: -
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
Now that we have the bits needed for mdp5 atomic, here is the followup pull request I mentioned. Main highlights are: 1) mdp5 multiple crtc and public plane support (no more hard-coded mixer setup!) 2) mdp5 atomic conversion 3) couple atomic helper fixes for issues found during mdp5 atomic debug (reviewed by danvet.. but he didn't plane to send an atomic-fixes pull request so I agreed to tack them on to mine) * 'msm-next' of git://people.freedesktop.org/~robclark/linux: drm/atomic: shutdown *current* encoder drm/atomic: check mode_changed *after* atomic_check drm/msm/mdp4: fix mixer setup for multi-crtc + planes drm/msm/mdp5: dpms(OFF) cleanups drm/msm/mdp5: atomic drm/msm: atomic fixes drm/msm/mdp5: remove global mdp5_ctl_mgr drm/msm/mdp5: don't use void * for opaque types drm/msm: add multiple CRTC and overlay support drm/msm/mdp5: set rate before enabling clk drm/msm/mdp5: introduce mdp5_cfg module drm/msm/mdp5: make SMP module dynamically configurable drm/msm/hdmi: remove useless kref drm/msm/mdp5: get the core clock rate from MDP5 config drm/msm/mdp5: use irqdomains
-
- 21 Nov, 2014 22 commits
-
-
Rob Clark authored
In disable_outputs() we need to shut down the outgoing encoder, not the incoming one (we have already swapped-state at this point). Without this, we end up telling the driver to crtc->dpms(OFF) without first encoder->dpms(OFF), and that makes some hw quite unhappy. v2: missing WARN_ON() hunk and comment Reviewed-by:
-
Rob Clark authored
The intention is that drivers can set crtc_state->mode_changed in their atomic_check() fxns if they encounter a scenario that requires full modeset. Signed-off-by:
-
Rob Clark authored
On mdp4 there is a single global LAYERMIXER_IN_CFG register. The previous logic to share that between multiple crtcs didn't actually handle plane-disable very well. Easier just to look at all of the crtcs each time. Signed-off-by: -
Rob Clark authored
When disabling the interface (INTF), the change doesn't latch until next vblank, so we need to wait for vblank. Also, to be pedantic, in the crtc, set all the mixer stages to unused. It shouldn't really matter, since at this point we have already disabled the INTF and waited for necessary vblank. Signed-off-by: -
Rob Clark authored
Convert mdp5 over to atomic helpers. Extend/wrap drm_plane_state to track plane zpos and to keep track of the needed when applying the atomic update. In mdp5's plane->atomic_check() we also need to check for updates which require SMP reallocation, in order to trigger full modeset. Signed-off-by: -
Rob Clark authored
Fixes for a couple little issues found in testing. Signed-off-by: -
Rob Clark authored
A bit cleaner.. and won't resulting in an attempt to kfree() a static global in unload path. Signed-off-by: -
Rob Clark authored
For example, use 'struct mdp5_smp *' everywhere instead of 'void *', but only declare it as 'struct mdp5_smp;' in common headers, so the struct body is still private. The accomplishes the desired modularity while still letting the compiler provide some type checking for us. Signed-off-by: -
Stephane Viau authored
MDP5 currently support one single CRTC with its private pipe. This change allows the configuration of multiple CRTCs with the possibility to attach several public planes to these CRTCs. Signed-off-by:
Stephane Viau <sviau@codeaurora.org> Signed-off-by:
-
Rob Clark authored
Set a "safe" rate at first, in order to read out the hw revision. And then after set the optimal value. Signed-off-by: -
Stephane Viau authored
The hardware configuration modification from a version to another is quite consequent. Introducing a configuration module (mdp5_cfg) may make things more clear and easier to access when a new hardware version comes up. Signed-off-by:
-
Stephane Viau authored
The Shared Memory Pool (SMP) has its own limitation, features and state. Some examples are: - the number of Memory Macro Block (MMB) and their size - the number of lines that can be fetched - the state of MMB currently allocated - the computation of number of blocks required per plane - client IDs ... In order to avoid private data to be overwritten by other modules, let's make these private to the SMP module. Some of these depend on the hardware configuration, let's add them to the mdp5_config struct. In some hw configurations, some MMBs are statically tied to RGB pipes and cannot be re-allocated dynamically. This change introduces the concept of MMB static usage and makes sure that dynamic MMB requests are dimensioned accordingly. A note on passing a pipe pointer, instead of client IDs: Client IDs are SMP-related information. Passing PIPE information to SMP lets SMP module to find out which SMP client(s) are used. This allows the SMP module to access the PIPE pointer, which can be used for FIFO watermark configuration. By the way, even though REG_MDP5_PIPE_REQPRIO_FIFO_WM_* registers are part of the PIPE registers, their functionality is to reflect the behavior of the SMP block. These registers access is now restricted to the SMP module. Signed-off-by:
-
Rob Clark authored
A left-over from prior to component framework. The original intent was to deal with hdmi getting unloaded before the master component, but that isn't really going to work anyways. These days with the component framework taking care to unload the master component first, we don't have to worry about this. Signed-off-by: -
Stephane Viau authored
The core clock rate depends on the hw configuration. Once we have read the hardware revision, we can set the core clock to its maximum value. Before then, the clock is set at a rate supported by all MDP5 revisions. Signed-off-by:
-
Rob Clark authored
For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the mdp block. In order to decouple hdmi/eDP/etc, register an irq domain in mdp5. When hdmi/dsi/etc are used with mdp4, they can directly setup their irqs in their DT nodes as normal. When used with mdp5, instead set the mdp device as the interrupt-parent, as in: mdp: qcom,mdss_mdp@fd900000 { compatible = "qcom,mdss_mdp"; interrupt-controller; #interrupt-cells = <1>; ... }; hdmi: qcom,hdmi_tx@fd922100 { compatible = "qcom,hdmi-tx-8074"; interrupt-parent = <&mdp>; interrupts = <8 0>; /* MDP5_HW_INTR_STATUS.INTR_HDMI */ ... }; There is a slight awkwardness, in that we cannot disable child irqs at the mdp level, they can only be cleared in the child block. So you must not use threaded irq handlers in the child. I'm not sure if there is a better way to deal with that. Signed-off-by: -
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
- More CI dpm fixes - Initial DPM fan control for SI/CI (disabled by default) - GPUVM multi-ring efficiency improvements - Some cursor fixes * 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux: (22 commits) drm/radeon: update the VM after setting BO address v4 drm/radeon: sync PT updates as shared v2 drm/radeon: sync PD updates as shared drm/radeon: fence BO_VAs manually drm/radeon: use one VMID for each ring drm/radeon: track VM update fences separately drm/radeon: fence PT updates manually v2 drm/radeon: split semaphore and sync object handling v2 drm/radeon: remove unnecessary VM syncs drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr drm/radeon: rework vm_flush parameters drm/radeon/ci: disable needless sclk changes drm/radeon/ci: force pcie level before sclk and mclk drm/radeon/ci: use different smc command for pcie dpm drm/radeon/ci: apply disp voltage changes before clk changes drm/radeon: fix PCC debugging message for CI DPM drm/radeon/dpm: add thermal dpm support for CI drm/radeon/dpm: add smc fan control for CI (v2) drm/radeon/dpm: add smc fan control for SI (v2) drm/radeon: work around a hw bug in MGCG on CIK ...
-
Markus Elfring authored
The vfree() function performes also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Reviewed-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Markus Elfring authored
The vunmap() function performes also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Daniel Vetter authored
This is an oversight from commit f52b69f1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Nov 19 18:38:08 2014 +0100 drm/atomic: Don't overrun the connector array when hotplugging Cc: Dave Airlie <airlied@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Thomas Hellstrom authored
It happens on occasion that developers of generic user-space applications abuse the dumb buffer API to get hold of drm buffers that they can both mmap() and use for GPU acceleration, using the assumptions that dumb buffers and buffers available for GPU are a) The same type and can be aribtrarily type-casted. b) fully coherent. This patch makes the most widely used drivers warn nicely when that happens, the next step will be to fail. v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 20 Nov, 2014 5 commits
-
-
Christian König authored
This way the necessary VM update is kicked off immediately if all BOs involved are in GPU accessible memory. v2: fix vm lock v3: immediately update unmaps as well v4: use drm_free_large instead of kfree Tested-by:
Kai Wasserbäch <kai@dev.carbon-project.org> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Christian König authored
Only invalidating PTEs needs to be executed synchronized to using the PT. v2: fix sync to uses Signed-off-by:
-
Christian König authored
We never invalidate PD entries and making them valid can run with other users in parallel. Signed-off-by:
-
Christian König authored
This allows us to finally remove the VM fence and so allow concurrent use of it from different engines. Signed-off-by:
-
Christian König authored
Use multiple VMIDs for each VM, one for each ring. That allows us to execute flushes separately on each ring, still not ideal cause in a lot of cases rings can share IDs. Signed-off-by:
-
