- 11 12月, 2015 2 次提交
-
-
由 Ville Syrjälä 提交于
Done with coccinelle for the most part. It choked on msm/mdp/mdp5/mdp5_plane.c like so: "BAD:!!!!! enum drm_plane_type type;" No idea how to deal with that, so I just fixed that up by hand. Also it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. I didn't convert drm_plane_init() since passing the varargs through would mean either cpp macros or va_list, and I figured we don't care about these legacy functions enough to warrant the extra pain. @@ typedef uint32_t; identifier dev, plane, possible_crtcs, funcs, formats, format_count, type; @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, unsigned long possible_crtcs, const struct drm_plane_funcs *funcs, const uint32_t *formats, unsigned int format_count, enum drm_plane_type type + ,const char *name, int DOTDOTDOT ) { ... } @@ identifier dev, plane, possible_crtcs, funcs, formats, format_count, type; @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, unsigned long possible_crtcs, const struct drm_plane_funcs *funcs, const uint32_t *formats, unsigned int format_count, enum drm_plane_type type + ,const char *name, int DOTDOTDOT ); @@ expression E1, E2, E3, E4, E5, E6, E7; @@ drm_universal_plane_init(E1, E2, E3, E4, E5, E6, E7 + ,NULL ) v2: Split crtc and plane changes apart Pass NUL for no-name instead of "" Leave drm_plane_init() alone v3: Add ', or NULL...' to @name kernel doc (Jani) Annotate the function with __printf() attribute (Jani) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449670795-2853-1-git-send-email-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. I didn't convert drm_crtc_init() since passing the varargs through would mean either cpp macros or va_list, and I figured we don't care about these legacy functions enough to warrant the extra pain. @@ identifier dev, crtc, primary, cursor, funcs; @@ int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc, struct drm_plane *primary, struct drm_plane *cursor, const struct drm_crtc_funcs *funcs + ,const char *name, int DOTDOTDOT ) { ... } @@ identifier dev, crtc, primary, cursor, funcs; @@ int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc, struct drm_plane *primary, struct drm_plane *cursor, const struct drm_crtc_funcs *funcs + ,const char *name, int DOTDOTDOT ); @@ expression E1, E2, E3, E4, E5; @@ drm_crtc_init_with_planes(E1, E2, E3, E4, E5 + ,NULL ) v2: Split crtc and plane changes apart Pass NULL for no-name instead of "" Leave drm_crtc_init() alone v3: Add ', or NULL...' to @name kernel doc (Jani) Annotate the function with __printf() attribute (Jani) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449670771-2751-1-git-send-email-ville.syrjala@linux.intel.com
-
- 09 12月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
This was in the documentation for modeset helper hooks, where it is a bit misplaced. v2: Reindent the drm_mode_status enum, inspired by Ville. v3: Suggestions from Ville and Thierry. v4: Small fixup that 0day spotted. v5: Slight change to avoid accidental headings in kerneldoc output. Cc: ville.syrjala@linux.intel.com Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-27-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3) Reviewed-by: Thierry Reding <treding@nvidia.com> (v3)
-
- 08 12月, 2015 15 次提交
-
-
由 Daniel Vetter 提交于
They have pretty kerneldoc already, but better to link to that in one of the overview sections. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-26-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
We always register the DPMS property, it's really a fundamental part of a display driver. So don't check whether the vfunc is there, it's non-optional Yes I've audited all the almost 100 drm_connector_funcs we have, no one botched this ;-) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-19-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
Yes these are internal functions and not exported and we generally don't document them. But for symmetry with the _set_property functions (which are exported for the atomic helpers) I'd like to document them. Upcoming vtable kerneldoc will reference both the set and get_property functions. v2: Suggestions from Thierry. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NThierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-17-git-send-email-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
Nouveau is the only user, and atomic drivers should do state save/restoring differently. So move it into noveau. Saves me typing some kerneldoc, too ;-) v2: Move misplaced hunk into earlier nouveau patch. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449245647-1315-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
I want to remove the core ones since with atomic drivers system suspend/resume is solved much differently. And there's only 2 drivers (gma500 besides nouveau) really using them. v2: Fixup bugs Ilia spotted. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449245618-1127-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
I want to remove the core ones since with atomic drivers system suspend/resume is solved much differently. And there's only 2 drivers (nouveau besides gma500) really using them. v2: Fixup build noise 0day reported. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-13-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Thierry Reding <treding@nvidia.com> (v1)
-
由 Rodrigo Vivi 提交于
save/restore have been removed from drm_encoder_helper_funcs by 'commit 79f13ad5d8e0 ("drm: Move encoder->save/restore into nouveau")' But this module was still defining it with empty content causing compilation fails: drivers/gpu/drm/i2c/tda998x_drv.c:1354:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] .save = tda998x_encoder_save, drivers/gpu/drm/i2c/tda998x_drv.c:1355:2: error: unknown field 'restore' specified in initializer .restore = tda998x_encoder_restore, Cc: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449513306-17309-1-git-send-email-rodrigo.vivi@intel.com
-
由 Daniel Vetter 提交于
These hooks will be gone soon. Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-12-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
These hooks will be gone soon. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-11-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
These hooks will be gone soon. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-10-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
gcc does this for us, and these hooks will be gone soon. Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-9-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
Especially document the assumptions and semantics of the callbacks carefully. Just a warm-up excercise really. v2: Spelling fixes (Eric). v3: Consolidate more with existing docs: - Remove the overview section explaining the bridge funcs, that's now all in the drm_bridge_funcs kerneldoc in much more detail. - Use & to reference structs so that kerneldoc automatically inserts hyperlinks. v4: Review from Thierry. Cc: Eric Anholt <eric@anholt.net> Cc: Archit Taneja <architt@codeaurora.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Archit Taneja <architt@codeaurora.org> (v3) Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-7-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
Duplication is bad, luckily both help texts highlighted different issues so the kerneldoc gained quite a bit! While at it also sprinkle more references to the vtable structs around and make it clear that legacy CRTC helpers are deprecated and which functions to use instead. v2: Spelling fixes and polish (Thierry). Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-6-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
Currently we have 4 helper libraries (probe, crtc, plane & atomic) that all use the same helper vtables. And that's by necessity since we don't want to litter the core structs with one ops pointer per helper library. Also often the reuse the same hooks (like atomic does, to facilite conversion from existing drivers using crtc and plane helpers). Given all that it doesn't make sense to put the docs for these next to specific helpers. Instead extract them into a new header file and section in the docbook, and add references to them everywhere. Unfortunately kernel-doc complains when an include directive doesn't find anything (and it does by dumping crap into the output file). We have to remove the now empty includes to avoid that, instead of leaving them in for future proofing. v2: More OCD in ordering functions. v3: Spelling plus collate copyright headers properly. Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-4-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Daniel Vetter 提交于
This is only used for kgdb (and previously panic) handlers in the fbdev emulation, so belongs there. Note that this means we'll leave behind a forward declaration, but once all the helper vtables are consolidated (in the next patch) that will make more sense. v2: fixup radone/amdgpu. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-3-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Thierry Reding <treding@nvidia.com> (v2)
-
- 07 12月, 2015 1 次提交
-
-
由 James Simmons 提交于
The ioctl IOC_LIBCFS_PING_TEST has not been used in ages. The recent nidstring changes which moved all the nidstring operations from libcfs to the LNet layer but this ioctl code was still using an nidstring operation that was causing a circular dependency loop between libcfs and LNet. Signed-off-by: NJames Simmons <jsimmons@infradead.org> Signed-off-by: NOleg Drokin <green@linuxhacker.ru> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 05 12月, 2015 8 次提交
-
-
由 Alex Deucher 提交于
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core more fragile to drivers which don't update hw vblank counters and vblank timestamps in sync with firing of the vblank irq and essentially at leading edge of vblank. This exposed a problem with radeon-kms/amdgpu-kms which do not satisfy above requirements: The vblank irq fires a few scanlines before start of vblank, but programmed pageflips complete at start of vblank and vblank timestamps update at start of vblank, whereas the hw vblank counter increments only later, at start of vsync. This leads to problems like off by one errors for vblank counter updates, vblank counters apparently going backwards or vblank timestamps apparently having time going backwards. The net result is stuttering of graphics in games, or little hangs, as well as total failure of timing sensitive applications. See bug #93147 for an example of the regression on Linux 4.4-rc: https://bugs.freedesktop.org/show_bug.cgi?id=93147 This patch tries to align all above events better from the viewpoint of the drm core / of external callers to fix the problem: 1. The apparent start of vblank is shifted a few scanlines earlier, so the vblank irq now always happens after start of this extended vblank interval and thereby drm_update_vblank_count() always samples the updated vblank count and timestamp of the new vblank interval. To achieve this, the reporting of scanout positions by radeon_get_crtc_scanoutpos() now operates as if the vblank starts radeon_crtc->lb_vblank_lead_lines before the real start of the hw vblank interval. This means that the vblank timestamps which are based on these scanout positions will now update at this earlier start of vblank. 2. The driver->get_vblank_counter() function will bump the returned vblank count as read from the hw by +1 if the query happens after the shifted earlier start of the vblank, but before the real hw increment at start of vsync, so the counter appears to increment at start of vblank in sync with the timestamp update. 3. Calls from vblank irq-context and regular non-irq calls are now treated identical, always simulating the shifted vblank start, to avoid inconsistent results for queries happening from vblank irq vs. happening from drm_vblank_enable() or vblank_disable_fn(). 4. The radeon_flip_work_func will delay mmio programming a pageflip until the start of the real vblank iff it happens to execute inside the shifted earlier start of the vblank, so pageflips now also appear to execute at start of the shifted vblank, in sync with vblank counter and timestamp updates. This to avoid some races between updates of vblank count and timestamps that are used for swap scheduling and pageflip execution which could cause pageflips to execute before the scheduled target vblank. The lb_vblank_lead_lines "fudge" value is calculated as the size of the display controllers line buffer in scanlines for the given video mode: Vblank irq's are triggered by the line buffer logic when the line buffer refill for a video frame ends, ie. when the line buffer source read position enters the hw vblank. This means that a vblank irq could fire at most as many scanlines before the current reported scanout position of the crtc timing generator as the number of scanlines the line buffer can maximally hold for a given video mode. This patch has been successfully tested on a RV730 card with DCE-3 display engine and on a evergreen card with DCE-4 display engine, in single-display and dual-display configuration, with different video modes. A similar patch is needed for amdgpu-kms to fix the same problem. Limitations: - Maybe replace the udelay() in the flip_work_func() by a suitable usleep_range() for a bit better efficiency? Will try that. - Line buffer sizes in pixels are hard-coded on < DCE-4 to a value i just guessed to be high enough to work ok, lacking info on the true sizes atm. Probably fixes: fdo#93147 Port of Mario's radeon fix to amdgpu. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> (v1) Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2) Refine amdgpu_flip_work_func() for better efficiency. In amdgpu_flip_work_func, replace the busy waiting udelay(5) with event lock held by a more performance and energy efficient usleep_range() until at least predicted true start of hw vblank, with some slack for scheduler happiness. Release the event lock during waits to not delay other outputs in doing their stuff, as the waiting can last up to 200 usecs in some cases. Also small fix to code comment and formatting in that function. (v2) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v3) Fix crash in crtc disabled case
-
由 Mario Kleiner 提交于
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core more fragile to drivers which don't update hw vblank counters and vblank timestamps in sync with firing of the vblank irq and essentially at leading edge of vblank. This exposed a problem with radeon-kms/amdgpu-kms which do not satisfy above requirements: The vblank irq fires a few scanlines before start of vblank, but programmed pageflips complete at start of vblank and vblank timestamps update at start of vblank, whereas the hw vblank counter increments only later, at start of vsync. This leads to problems like off by one errors for vblank counter updates, vblank counters apparently going backwards or vblank timestamps apparently having time going backwards. The net result is stuttering of graphics in games, or little hangs, as well as total failure of timing sensitive applications. See bug #93147 for an example of the regression on Linux 4.4-rc: https://bugs.freedesktop.org/show_bug.cgi?id=93147 This patch tries to align all above events better from the viewpoint of the drm core / of external callers to fix the problem: 1. The apparent start of vblank is shifted a few scanlines earlier, so the vblank irq now always happens after start of this extended vblank interval and thereby drm_update_vblank_count() always samples the updated vblank count and timestamp of the new vblank interval. To achieve this, the reporting of scanout positions by radeon_get_crtc_scanoutpos() now operates as if the vblank starts radeon_crtc->lb_vblank_lead_lines before the real start of the hw vblank interval. This means that the vblank timestamps which are based on these scanout positions will now update at this earlier start of vblank. 2. The driver->get_vblank_counter() function will bump the returned vblank count as read from the hw by +1 if the query happens after the shifted earlier start of the vblank, but before the real hw increment at start of vsync, so the counter appears to increment at start of vblank in sync with the timestamp update. 3. Calls from vblank irq-context and regular non-irq calls are now treated identical, always simulating the shifted vblank start, to avoid inconsistent results for queries happening from vblank irq vs. happening from drm_vblank_enable() or vblank_disable_fn(). 4. The radeon_flip_work_func will delay mmio programming a pageflip until the start of the real vblank iff it happens to execute inside the shifted earlier start of the vblank, so pageflips now also appear to execute at start of the shifted vblank, in sync with vblank counter and timestamp updates. This to avoid some races between updates of vblank count and timestamps that are used for swap scheduling and pageflip execution which could cause pageflips to execute before the scheduled target vblank. The lb_vblank_lead_lines "fudge" value is calculated as the size of the display controllers line buffer in scanlines for the given video mode: Vblank irq's are triggered by the line buffer logic when the line buffer refill for a video frame ends, ie. when the line buffer source read position enters the hw vblank. This means that a vblank irq could fire at most as many scanlines before the current reported scanout position of the crtc timing generator as the number of scanlines the line buffer can maximally hold for a given video mode. This patch has been successfully tested on a RV730 card with DCE-3 display engine and on a evergreen card with DCE-4 display engine, in single-display and dual-display configuration, with different video modes. A similar patch is needed for amdgpu-kms to fix the same problem. Limitations: - Line buffer sizes in pixels are hard-coded on < DCE-4 to a value i just guessed to be high enough to work ok, lacking info on the true sizes atm. Fixes: fdo#93147 Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Tested-by: Dave Witbrodt <dawitbro@sbcglobal.net> (v2) Refine radeon_flip_work_func() for better efficiency: In radeon_flip_work_func, replace the busy waiting udelay(5) with event lock held by a more performance and energy efficient usleep_range() until at least predicted true start of hw vblank, with some slack for scheduler happiness. Release the event lock during waits to not delay other outputs in doing their stuff, as the waiting can last up to 200 usecs in some cases. Retested on DCE-3 and DCE-4 to verify it still works nicely. (v2) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude 提交于
HPD signals on DVI ports can be fired off before the pins required for DDC probing actually make contact, due to the pins for HPD making contact first. This results in a HPD signal being asserted but DDC probing failing, resulting in hotplugging occasionally failing. This is somewhat rare on most cards (depending on what angle you plug the DVI connector in), but on some cards it happens constantly. The Radeon R5 on the machine used for testing this patch for instance, runs into this issue just about every time I try to hotplug a DVI monitor and as a result hotplugging almost never works. Rescheduling the hotplug work for a second when we run into an HPD signal with a failing DDC probe usually gives enough time for the rest of the connector's pins to make contact, and fixes this issue. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NLyude <cpaul@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 jimqu 提交于
there is a protection fault about freed list when OCL test. add a spin lock to protect it. v2: drop changes in vm_fini Signed-off-by: NJimQu <jim.qu@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Christian König 提交于
The gtt_end is already inclusive, we don't need to subtract one here. v2 (chk): keep the fix for the VM code, cause here it really applies. Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAnatoli Antonovitch <anatoli.antonovitch@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
No need for a GEM reference here. Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
No need for the GEM reference here. Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Not necessary for VRAM. v2: no need to check if ttm is NULL. Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 04 12月, 2015 11 次提交
-
-
由 Ilya Dryomov 提交于
Commit 4e752f0a ("rbd: access snapshot context and mapping size safely") moved ceph_get_snap_context() out of rbd_img_request_create() and into rbd_queue_workfn(), adding a ceph_put_snap_context() to the error path in rbd_queue_workfn(). However, rbd_img_request_create() consumes a ref on snapc, so calling ceph_put_snap_context() after a successful rbd_img_request_create() leads to an extra put. Fix it. Cc: stable@vger.kernel.org # 3.18+ Signed-off-by: NIlya Dryomov <idryomov@gmail.com> Reviewed-by: NJosh Durgin <jdurgin@redhat.com>
-
由 Jani Nikula 提交于
We've had human readable connector status change debug logging since commit ed7951dc Author: Lespiau, Damien <damien.lespiau@intel.com> Date: Fri May 10 12:36:42 2013 +0000 drm: Make the HPD status updates debug logs more readable but commit 162b6a57 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jan 21 08:45:21 2015 +0100 drm/probe-helper: don't lose hotplug event added a new one with just the numbers. Fix it. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449144003-2877-1-git-send-email-jani.nikula@intel.com
-
由 Daniel Vetter 提交于
Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e4 Author: Mario Kleiner <mario.kleiner.de@gmail.com> Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. Unfortunately that hack got uprooted in commit cc1ef118 Author: Thierry Reding <treding@nvidia.com> Date: Wed Aug 12 17:00:31 2015 +0200 drm/irq: Make pipe unsigned and name consistent Triggering a warning when trying to sample the vblank timestamp for a non-existing pipe. There's a few ways to fix this: - Open-code the old behaviour, which just enshrines this slight breakage of the userspace ABI. - Revert Mario's commit and again inflict broken timestamps, again not pretty. - Fix this for real by delaying the pageflip TS until the next vblank interrupt, thereby making it accurate. This patch implements the third option. Since having a page flip interrupt that happens when the pageflip gets armed and not when it completes in the next vblank seems to be fairly common (older i915 hw works very similarly) create a new helper to arm vblank events for such drivers. v2 (Mario Kleiner): - Fix function prototypes in drmP.h - Add missing vblank_put() for pageflip completion without pageflip event. - Initialize sequence number for queued pageflip event to avoid trouble in drm_handle_vblank_events(). - Remove dead code and spelling fix. v3 (Mario Kleiner): - Add a signed-off-by and cc stable tag per Ilja's advice. v4 (Thierry Reding): - Fix kerneldoc typo, discovered by Michel Dänzer - Rearrange tags and changelog Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431 Cc: Thierry Reding <treding@nvidia.com> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: NBen Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # v4.3 Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
A client calling drmSetMaster() using a file descriptor that was opened when another client was master would inherit the latter client's master object and all its authenticated clients. This is unwanted behaviour, and when this happens, instead allocate a brand new master object for the client calling drmSetMaster(). Fixes a BUG() throw in vmw_master_set(). Cc: <stable@vger.kernel.org> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Eric Anholt 提交于
It looks like these meant to be unreffing the of_parse_phandle_with_args() node, since the error paths above it don't do of_node_put. That function returns a new ref in pd_args.np, though, not a new ref on dev->of_node. Also, it would have leaked the ref in the success case. Fixes "ERROR: Bad of_node_put()" on bcm2835 in the -EPROBE_DEFER case. Fixes: aa42240a (PM / Domains: Add generic OF-based PM domain look-up) Signed-off-by: NEric Anholt <eric@anholt.net> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NKevin Hilman <khilman@linaro.org> Cc: 3.18+ <stable@vger.kernel.org> # 3.18+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Jérôme Pouiller 提交于
It is possible to address another chip on same MDIO bus. The case is correctly handled for media advertising. It is taken into account only if mii_data->phy_id == phydev->addr. However, this condition was missing for reset case. Signed-off-by: NJérôme Pouiller <jezz@sysmic.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Call bnxt_cfg_rx_mode() in bnxt_init_chip() to setup uc_list and mc_list mac address filters. Before the patch, uc_list is not setup again after chip reset (such as ethtool ring size change) and macvlans don't work any more after that. Modify bnxt_cfg_rx_mode() to return error codes appropriately so that the init chip sequence can detect any failures. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jeffrey Huang 提交于
For PF, the bp->pf.mac_addr always holds the permanent MAC addr assigned by the HW. For VF, the bp->vf.mac_addr always holds the administrator assigned VF MAC addr. The random generated VF MAC addr should never get stored to bp->vf.mac_addr. This way, when the VF wants to change the MAC address, we can tell if the adminstrator has already set it and disallow the VF from changing it. v2: Fix compile error if CONFIG_BNXT_SRIOV is not set. Signed-off-by: NJeffrey Huang <huangjw@broadcom.com> Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jeffrey Huang 提交于
The existing ndo_set_mac_address only copies the new MAC addr and didn't set the new MAC addr to the HW. The correct way is to delete the existing default MAC filter from HW and add the new one. Because of RFS filters are also dependent on the default mac filter l2 context, the driver must go thru close_nic() to delete the default MAC and RFS filters, then open_nic() to set the default MAC address to HW. Signed-off-by: NJeffrey Huang <huangjw@broadcom.com> Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Zapolskiy 提交于
If the driver is used on an ARM platform with SPARSE_IRQ defined, semantics of NR_IRQS is different (minimal value of virtual irqs) and by default it is set to 16, see arch/arm/include/asm/irq.h. This value may be less than the actual number of virtual irqs, which may break the driver initialization. The check removal allows to use the driver on such a platform, and, if irq controller driver works correctly, the check is not needed on legacy platforms. Fixes a runtime problem: lpc-eth 31060000.ethernet: error getting resources. lpc_eth: lpc-eth: not found (-6). Signed-off-by: NVladimir Zapolskiy <vz@mleia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 James Bottomley 提交于
The non-PCI builds of the O day test project are failing: On Thu, 2015-12-03 at 05:02 +0800, kbuild test robot wrote: > warning: (SCSI_MPT2SAS) selects SCSI_MPT3SAS which has unmet direct > dependencies (SCSI_LOWLEVEL && PCI && SCSI) The problem is that select and depend don't interact because Kconfig doesn't have a SAT solver, so depend picks up dependencies and select does onward selects, but select doesn't pick up dependencies. To fix this, we need to add the correct dependencies to the MPT2SAS option like this. Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Fixes: b840c362Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 03 12月, 2015 2 次提交
-
-
由 Daniel Vetter 提交于
This can happen when we run out of encoders for a multi-crtc modeset, or also when userspace is silly and tries to clone multiple connectors that need the same encoder on the same crtc. Reported-and-Tested-and-Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449136154-11588-1-git-send-email-daniel.vetter@ffwll.ch
-
由 Marcin Wojtas 提交于
Since Armada 38x SoC can support IP checksum for jumbo frames only on a single port, it means that this feature should be enabled per-port, rather than for the whole SoC. This patch enables setting custom TX IP checksum limit by adding new optional property to the mvneta device tree node. If not used, by default 1600B is set for "marvell,armada-370-neta" and 9800B for other strings, which ensures backward compatibility. Binding documentation is updated accordingly. Signed-off-by: NMarcin Wojtas <mw@semihalf.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-