- 10 Dec, 2014 6 commits
-
-
Thierry Reding authored
The ->load_lut() callback is optional, therefore a dummy implementation is not needed. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Thierry Reding authored
The ->load_lut() callback is optional, therefore a dummy implementation is not needed. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Thierry Reding authored
The ->load_lut() callback is optional, therefore a dummy implementation is not needed. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Thierry Reding authored
The ->load_lut() callback is optional, therefore a dummy implementation is not needed. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Thierry Reding authored
The ->load_lut() callback is optional, therefore a dummy implementation is not needed. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Thierry Reding authored
Drivers where the DRM objects have a lifetime that extends beyond that of the DRM device need to zero out the DRM object memory to void stale data such as properties. The DRM core code expects to operate on newly allocated and zeroed out objects and will behave unexpectedly, such as add duplicate properties, otherwise. Signed-off-by:
-
- 09 Dec, 2014 2 commits
-
-
Martin Peres authored
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Martin Peres authored
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. CC: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 04 Dec, 2014 2 commits
-
-
Takashi Iwai authored
Note that the read manpages explicitly states that the read position is undefined on error. Since EFAULT is just a userspace bug we are therefore fine with just dropping the event on the floor. Signed-off-by:
Takashi Iwai <tiwai@suse.de> [danvet: Add note that just dropping the event is ok.] Signed-off-by:
-
Sean Paul authored
The "DRM" rowspan wasn't updated in commit cc7096fb (drm/mode: document path property and function to set it. (v1.1)), so increment it by one to fix the table. Cc: Dave Airlie <airlied@linux.ie> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
- 03 Dec, 2014 1 commit
-
-
Thierry Reding authored
Commit 18df89fe ("drm: Decouple EDID parsing from I2C adapter") renamed the adapter parameter of the drm_do_probe_ddc_edid function to data but didn't update the kerneldoc accordingly. Signed-off-by:
-
- 01 Dec, 2014 3 commits
-
-
Stefan Brüns authored
The function will also be used by a later patch, so factor it out. V2: make raw_edid const, define/declare before first use V3: fix erroneuos removal of csum variable Signed-off-by:
Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Stefan Brüns authored
There is no need to dump the whole EDID block in case it contains no information. Just print a single line stating the block is empty instead of 8 lines containing only zeroes. Signed-off-by:
-
Stefan Brüns authored
drm_edid_is_zero will be used by drm_edid_block valid, move it up. raw_edid argument can be const. Signed-off-by:
-
- 27 Nov, 2014 7 commits
-
-
Rob Clark authored
Otherwise we'd still end up w/ the plane attached to the CRTC, and seemingly active, but without an FB. Which ends up going *boom* in the drivers. Slightly modified version of Daniel's irc suggestion. Note that the big problem isn't drivers going *boom* here (since we already have the situation of planes being left enabled when the crtc goes down). The real issue is that the core assumes the primary plane always goes down when calling ->set_config with a NULL mode. Ignoring that assumption leads to the legacy state pointers plane->fb/crtc getting out of sync with atomic, and that then leads to the subsequent *boom* all over the place. CC: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Rob Clark <robdclark@gmail.com> [danvet: Drop my opinion of what's going sidewides here into the commit message as a note.] Signed-off-by:
-
Daniel Vetter authored
So the problem with async commit (especially async modeset commit) is that the legacy pointers only get updated after the point of no return, in the async part of the modeset sequence. At least as implemented by the current helper functions. This is done in the set_routing_links function in drm_atomic_helper.c. Which also means that access isn't protected by locks but only coordinated by synchronizing with async workers. No problem thus far, until we lock at the getconnector/encoder ioctls. So fix this up by adding special cases for atomic drivers: For those we need to look at state objects. Unfortunately digging out the correct encoder->crtc link is a bit of work, so wrap this up in a helper function. Moving the assignments of connector->encoder and encoder->crtc earlier isn't a good idea because the point of the atomic helpers is that we stage the state updates. That way the disable functions can still inspect the links and rely upon them. v2: Extract full encoder->crtc lookup into helper (Rob). v3: Extract drm_connector_get_encoder too since - we need to always return state->best_encoder when there is a state otherwise we might return stale data if there's a pending async disable (and chase unlocked pointers, too). Same issue with encoder_get_crtc but there it's a bit more tricky to handle. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Rob Clark authored
Signed-off-by:
-
Rob Clark authored
Signed-off-by:
-
Rob Clark authored
Signed-off-by:
-
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 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 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 9 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:
-
