- 13 1月, 2015 1 次提交
-
-
由 Dave Airlie 提交于
Daniel merged two things in 72a36970, but he merged this code twice, Dan's static checker spotted it. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 05 1月, 2015 8 次提交
-
-
由 Daniel Vetter 提交于
Atomic doesn't really work without universal planes anyway. But make sure that evil userspace doesn't pull the kernel over the table because we didn't consider a cornercase that just doesn't make sense, just for safety. v2: Just force ->universal_planes to the same value to avoid imposing restrictions on userspace. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
This is just a bit fallout from patch polishing and moving the get_prop logic fully into the core: - Drop EXPORT_SYMBOL and make the helpers static. - Drop kerneldoc since not used by drivers. - Move the cross-file function declarations only used by drm.ko internally to an internal header. v2: keep the gist of the comments, requested by Rob. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Rob Clark 提交于
The atomic modeset ioctl can be used to push any number of new values for object properties. The driver can then check the full device configuration as single unit, and try to apply the changes atomically. The ioctl simply takes a list of object IDs and property IDs and their values. Originally based on a patch from Ville Syrjälä, although it has mutated (mutilated?) enough since then that you probably shouldn't blame it on him ;-) The atomic support is hidden behind the DRM_CLIENT_CAP_ATOMIC cap (to protect legacy userspace) and drm.atomic module param (for now). v2: Check for file_priv->atomic to make sure we only allow userspace in-the-know to use atomic. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Expose the core connector state as properties so it can be updated via atomic ioctl. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Expose the core plane state as properties, so they can be updated via atomic ioctl. v2: atomic property flag Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Getting ready to add a lot more standard properties for atomic. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> [danvet: Realign function paramaters where the lines shrunk massively.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Add functions to check core plane/crtc state. v2: comments, int-overflow checks, call from core rather than helpers to be sure drivers can't find a way to bypass core checks Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Once a driver is using atomic helpers for modeset, the next step is to switch over to atomic properties. To do this, make sure that any modeset objects have their ->atomic_{get,set}_property() vfuncs suitably populated if they have custom properties (you did already remember to plug in atomic-helper func for the legacy ->set_property() vfuncs, right?), and then set DRIVER_ATOMIC bit in driver_features flag. A new cap is introduced, DRM_CLIENT_CAP_ATOMIC, for the purposes of shielding legacy userspace from atomic properties. Mostly for the benefit of legacy DDX drivers that do silly things like getting/setting each property at startup (since some of the new atomic properties will be able to trigger modeset). Signed-off-by: NRob Clark <robdclark@gmail.com> [danvet: Squash in fixup patch to check for DRM_MODE_PROP_ATOMIC instaed of the CAP define when filtering properties. Reported by Tvrtko Uruslin, acked by Rob.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 12月, 2014 1 次提交
-
-
由 Dave Airlie 提交于
This reverts commit 355a7018. This had some bad side effects under normal operation, and should have been dropped earlier. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 12月, 2014 1 次提交
-
-
由 Dave Airlie 提交于
nouveau userspace back at 1.0.1 used to call the X server DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts to map the sarea and fails if it can't. Since 884c6dab from Daniel, this fails, but only ancient drivers would see it. Revert the nouveau bits of that fix. Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 3.18 Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 12月, 2014 9 次提交
-
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Both need to iterate a mode objects properties. Split that out into a helper shared by both ioctl handlers, since this is going to become more complicated when we add atomic properties (which will need filtering from legacy userspace). Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
We need to hold connection_mutex as we read the properties. Easiest thing is just widen the scope where connection_mutex is held. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Since we won't be using the obj->properties->values[] array to shadow property values for atomic drivers, we are going to need a vfunc for getting prop values. Add that along w/ mandatory wrapper fxns. v2: more comments and copypasta comment typo fix Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
As we add properties for all the standard plane/crtc/connector attributes (in preperation for the atomic ioctl), we are going to want to handle core state in core (rather than per driver). Intercepting the core properties will be easier if the atomic_set_property vfuncs are not called directly, but instead have a mandatory wrapper function (which will later serve as the point to intercept core properties). v2: more verbose comments and copypasta comment fix Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jilai Wang 提交于
Disable the HPD interrupt when acking it, to avoid spurious interrupt. Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>
-
由 Jilai Wang 提交于
HPD regulators need to be enabled before clocks, otherwise clock driver will report warning. Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>
-
由 Rob Clark 提交于
If crtc <-> encoder linkage changes, we could end up with the CRTC listening for the wrong error or vsync irqs. Generally this problem would correct itself relatively quickly, since we update the global irqmask after dispatching irqs, but to be sure let the CRTC trigger update_irq(). Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
We can't have multiple updates pending on a given CRTC, and we don't want a sync update to race w/ an async update that preceeded it. So keep track of which CRTCs have updates in flight, and block later updates that would conflict. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 18 12月, 2014 16 次提交
-
-
由 Matt Roper 提交于
During plane operations, we read/write some registers that only operate properly if we're not runtime suspended. At the moment we're not holding the runtime PM reference across the whole plane operation, so there's a potential for problems. This issue was already partially addressed by commit commit d6dd6843 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Aug 15 15:59:32 2014 -0300 drm/i915: fix plane/cursor handling when runtime suspended which took care of holding the runtime PM reference during the pin and fence operations for plane updates. However there are still a few actual plane registers that we also need to hold the runtime PM reference for. Recent refactoring patches in preparation for atomic have rearranged the code and made it increasingly likely that the hardware will have time to suspend between the pin/fence operation and the actual register writes. Examples of such registers are the stuff touched by ivb_get_colorkey. The solution here grabs the runtime PM reference around the 'commit' operation for planes, which should cover all the relevant register reads/writes. Note that this has only been exposed with commit 6beb8c23 Author: Matt Roper <matthew.d.roper@intel.com> Date: Mon Dec 1 15:40:14 2014 -0800 drm/i915: Consolidate plane 'prepare' functions (v2) so doesn't need to be ported to 3.19. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87180Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Testcase: igt/pm-rpm/legacy-planes Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Augment commit message with information Paulo supplied.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
For atomic drivers, we won't use the values array but instead shunt things off to obj->atomic_get_property(). So to simplify things make all read/write of properties values go through the accessors. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Keep property pointer, instead of id, in per mode-object attachments. This will simplify things in later patches. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
We can already have object properties, which technically can be fb's. Switch the property validation logic over to a get/put style interface so it can take a ref to refcnt'd objects, and then drop that ref after the driver has a chance to take it's own ref. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Useful since this way we can pass around just the state objects and will get ther real object, too. Specifically this allows us to again simplify the parameters for set_crtc_for_plane. v2: msm already has it's own specific plane_reset hook, don't forget that one! v3: Fixup kerneldoc, reported by 0-day builder. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> (v2) Tested-by: Rob Clark <robdclark@gmail.com> (v2) Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
This essentially reverts commit 934ce1c2 Author: Rob Clark <robdclark@gmail.com> Date: Wed Nov 19 16:41:33 2014 -0500 drm/atomic: check mode_changed *after* atomic_check Depending upon the driver both orders (or maybe even interleaving) is required: - If ->atomic_check updates ->mode_changed then helper_check_modeset must be run afters. - If ->atomic_check depends upon accurate adjusted dotclock values for e.g. watermarks, then helper_check_modeset must be run first. The failure mode in the first case is usually a totally angry hw because the pixel format switching doesn't happen. The failure mode in the later case is usually nothing, since in most cases the old adjusted mode from the previous modeset wont be too far off to be a problem. So just underruns and perhaps even just suboptimal (from a power consumption) watermarks. Furthermore in the transitional helpers we only call ->atomic_check after the new modeset state has been fully set up (and hence computed). Given that asymmetry in expected failure modes I think it's safer to go back to the older order. So do that and give msm a special check function to compensate. Also update kerneldoc to explain this a bit. v2: Actually add the missing hunk Rob spotted. v3: Move msm_atomic_check into msm_atomic.c, requested by Rob. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Tested-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
The default call sequence for these two parts won't fit for all drivers. So export the two pieces and explain with a bit of kerneldoc when each should be called. v2: Squash in fixup from Rob to actually add the newly exported functions to headers Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Rob Clark 提交于
When a plane is being enabled, plane->crtc has not been set yet. Use plane->state->crtc. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
Let's be optimistic that for future platforms memory management doesn't change that much and reuse gen8 function for PPGTT init. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. v2: Jani pointed out I was missing reg_830 for some gen3 platforms. So let's make this platforms subcases of Gen checks. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 12月, 2014 4 次提交
-
-
由 Markus Elfring 提交于
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: NMarkus Elfring <elfring@users.sourceforge.net> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Markus Elfring 提交于
The functions framebuffer_release() and vunmap() perform 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: NMarkus Elfring <elfring@users.sourceforge.net> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Sean Paul 提交于
In finish pageflip, the driver was not selecting the root window when dispatching events. This exposed a race where a plane update would change the window selection and cause tegra_dc_finish_page_flip to check the wrong base address. This patch also protects access to the window selection register as well as the registers affected by it. Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
If the requested buffer size wasn't a multiple of the page size, the IOMMU code would round down the size to the next multiple of the page size, thereby causing translation errors. To fix this we no longer pass around the requested size but reuse the computed size of the GEM object. This is already rounded to the next page boundary, so mapping that size works out fine. Signed-off-by: NThierry Reding <treding@nvidia.com>
-