- 17 Dec, 2014 7 commits
-
-
Thierry Reding authored
The file refers to a bunch of structure declared in drm_crtc.h, so include it to make sure the drm_crtc_helper.h header can be included standalone. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Thierry Reding authored
The .irq and .irq_enabled fields are part of the VBLANK interrupt handling infrastructure, so move them to the appropriate section within the structure. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Thierry Reding authored
The struct drm_connector_funcs kerneldoc refers to a part of struct drm_crtc_funcs that no longer exists. Signed-off-by:
-
Ville Syrjälä authored
Currently userspace is allowed to pass in basiclly any kind of garbage to setcrtc. Try to catch the cases where the timings make no sense by passing the mode through drm_mode_validate_basic(). One concern here is that we now start to block some modes that have worked in the past. It's at least possible with when using i915 with LVDS/eDP. Previously we've just ignored everything but hdisplay/vdisplay from the user mode and just overwritten the rest with the panel fixed mode. So if someone has been passing a mode with just those populated that would now stop working. If that is a real problem, we can't add these checks to the core code and each driver would have to have its own sanity checks. So fingers crossed... Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Make sure the timings of probed modes at least pass some very basic sanity checks. The checks include: - clock,hdisplay,vdisplay are non zero - sync pulse fits within the blanking period - htotal,vtotal are big enough I have not checked all the drivers to see if the modes the generate might violate these constraints. I'm hoping not, because that would mean either abandoning the idea of doing this from the core code, or fixing the drivers. I'm not entirely sure about limiting the sync pulse to the blanking period. Intel hardware doesn't support such things, but some other hardware might. However at least HDMI doesn't allow having sync pulse edges within the active period, so I'm thinking the check is probably OK to have in the common code. Signed-off-by:
-
Ville Syrjälä authored
Make drm_mode_validate_size() and drm_mode_validate_flag() deal with a single mode instead of having each iterate through the mode list. The hope is that in the future we might be able to share various mode validation functions between modeset and get_modes. Signed-off-by:
-
Thierry Reding authored
Signed-off-by:
-
- 16 Dec, 2014 2 commits
-
-
Thierry Reding authored
Commit 28a62277 ("drm: Convert proc files to seq_file and introduce debugfs") converted /proc files to debugfs and in the process dropped the entry for the vblank statistics. Since that file has been gone for almost five years, there is no use to keep the code that provides the file's content around. Signed-off-by:
-
Ben Widawsky authored
When the original drm code was written there were no centralized functions for doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so use them instead of rolling a new one. v2: On x86 UP systems the wbinvd_on_all_cpus() is defined as a static inline in smp.h. We must therefore include this file so we don't get compiler errors. This error was found by 0-DAY kernel test infrastructure. We only need this for x86. Cc: Intel GFX <intel-gfx@lists.freedesktop.org> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by:
-
- 11 Dec, 2014 2 commits
-
-
Matt Roper authored
drm_plane_helper_check_update() currently uses crtc before testing whether we're disabling the plane (fb == NULL). Move the fb test before the first crtc usage so that crtc == NULL doesn't have to be handled by the caller. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Laurent Pinchart authored
And fix a spelling mistake. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
- 10 Dec, 2014 14 commits
-
-
Rob Clark authored
Signed-off-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Thierry Reding authored
sizeof(type) is the variant used most commonly and required by checkpatch. Signed-off-by:
-
Thierry Reding authored
All prior conditional blocks return from the function, so the else block can be at the top level of the function. Signed-off-by:
-
Thierry Reding authored
Single statement blocks don't need to be enclosed in a pair of braces. Signed-off-by:
-
Thierry Reding authored
checkpatch requires the assignment and the check to be separate statements. Signed-off-by:
-
Thierry Reding authored
Fixes a couple of checkpatch warnings regarding the use of kmalloc() with a multiplication. kmalloc_array() is the preferred API. Signed-off-by:
-
Thierry Reding authored
Fixes a couple of checkpatch warnings regarding the use of kzalloc() with a multiplication. kcalloc() is the preferred API. Signed-off-by:
-
Thierry Reding authored
A couple of whitespace changes required to silent various errors and warnings flagged by checkpatch. checkpatch requires that the opening brace be on the same line as a variable declaration. Furthermore an empty line is required after a block of variable declarations. Trailing whitespace as well as using spaces before tabs is considered an error or warning, respectively. Finally, the closing parenthesis of an if condition and the opening brace of the conditional block should be separated by a space. Signed-off-by:
-
Thierry Reding authored
The ->load_lut() callback is optional, therefore a dummy implementation is not needed. Signed-off-by:
-
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:
-
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:
-
