- 09 Jan, 2017 5 commits
-
-
Chris Wilson authored
As the fence->status is an optional field that may be set before dma_fence_signal() is called to convey that the fence completed with an error, we have to ensure that it is always set to zero on initialisation so that the typical use (i.e. unset) always flags a successful completion. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by:
-
Benjamin Gaignard authored
Removing MMU configuration flag from DRM make few automatic build failed when they answer yes to all flags. Add asm/vga.h file on Blackfin architecture to not broke compilation. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Fixes: 62a0d98a ("drm: allow to use mmuless SoC") Signed-off-by:
-
Gabriel Krisman Bertazi authored
The integer returned by the unload hook is ignored by the drm core, so let's make it void. This patch was created using the following Coccinelle semantic script (except for the declaration and comment in drm_drv.h): Compile-tested only. // <smpl> @ get_name @ struct drm_driver drv; identifier fn; @@ drv.unload = fn; @ replace_type @ identifier get_name.fn; @@ - int + void fn (...) { ... } @ remove_return_param @ identifier get_name.fn; @@ void fn (...) { <... if (...) return - ... ; ...> } @ drop_final_return @ identifier get_name.fn; @@ void fn (...) { ... - return 0; } // </smpl> Suggested-by:Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Acked-by: Christian König <christian.koenig@amd.com>. Signed-off-by:
-
Shawn Guo authored
Add a bit more document for function drm_crtc_from_index() to cross link it with drm_crtc_from_index(), and explain that the function is useful in vblank code. While at it, add cross link comment for drm_plane_from_index() as well. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Vincent Abriou authored
drm_pick_cmdline_mode width and height parameters are useless. Just remove them. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
-
- 06 Jan, 2017 4 commits
-
-
Benjamin Gaignard authored
Each time new data has being added in CRC list inform reader by calling wake_up_interruptible(). This should avoid to do it in all drivers. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
-
Benjamin Gaignard authored
Some SoC without MMU have display driver where a drm/kms driver could be implemented. Before doing such kind of thing drm/kms must allow to use mmuless devices. This patch propose to remove MMU configuration flag and add a cma helper function to help implementing mmuless display driver version 4: - add documentation about drm_gem_cma_get_unmapped_area() - stub it MMU case Signed-off-by:
-
Benjamin Gaignard authored
drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU. Use a new DRM_VM to define when drm_vm.c in needed. stub drm_legacy_vma_flush() to avoid compilation issues version 4: - a "config DRM_VM" in Kconfig Signed-off-by:
-
Benjamin Gaignard authored
Allow generic frame-buffer to provide a default get_fb_unmapped_area function if specific devices need it. Usually this function is defined in architecture directories but define it here may limit code duplication especially for all ARM platforms without MMU. version 5: - set get_unmapped_area field if FB_PROVIDE_GET_FB_UNMAPPED_AREA is defined version 4: - introdude a configuration flag to be independent of architecture Signed-off-by:
-
- 05 Jan, 2017 5 commits
-
-
Tomeu Vizoso authored
Don't return from the open() call on the crc/data file until the HW has produced a first frame, as there's great variability in when the HW is able to do that and userspace shouldn't have to guess when this specific HW is ready to start giving frame CRCs. Signed-off-by:
-
Tomeu Vizoso authored
There's no reason any more for callers of this function to take the lock themselves, so just move the lock to the function to avoid confusion and bugs when more callers are contributed. Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Robert Foss <robert.foss@collabora.com> Signed-off-by:
-
Fabio Estevam authored
'ret' is never used in tve_enable/tve_disable(), so just remove it. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Daniel Vetter authored
This reverts commit a5ad0fd8. It results in kconfing complaining about recursive depencies: drivers/usb/Kconfig:39:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/Kconfig:8: symbol INPUT is selected by VT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/tty/Kconfig:12: symbol VT is selected by FB_STI For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:128: symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/arm/Kconfig:6: symbol DRM_HDLCD depends on COMMON_CLK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by X86_INTEL_QUARK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/platform/x86/Kconfig:5: symbol X86_PLATFORM_DEVICES is selected by DRM_NOUVEAU For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on LEDS_CLASS For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 && +BACKLIGHT_CLASS_DEVICE && INPUT) And there's apparently a better patch available already. Signed-off-by:
-
Daniel Vetter authored
I was lazy, rectify that! Also align with drm_atomic_state_get/put for ocd. v2: Git add helps. Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 04 Jan, 2017 5 commits
-
-
Maarten Lankhorst authored
Commit 0853695c ("drm: Add reference counting to drm_atomic_state") adds reference counting to atomic state, but didn't update the comments in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more. Fixes: 0853695c ("drm: Add reference counting to drm_atomic_state") Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+ Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
When writing the generic nonblocking commit code I assumed that through clever lifetime management I can assure that the completion (stored in drm_crtc_commit) only gets freed after it is completed. And that worked. I also wanted to make nonblocking helpers resilient against driver bugs, by having timeouts everywhere. And that worked too. Unfortunately taking boths things together results in oopses :( Well, at least sometimes: What seems to happen is that the drm event hangs around forever stuck in limbo land. The nonblocking helpers eventually time out, move on and release it. Now the bug I tested all this against is drivers that just entirely fail to deliver the vblank events like they should, and in those cases the event is simply leaked. But what seems to happen, at least sometimes, on i915 is that the event is set up correctly, but somohow the vblank fails to fire in time. Which means the event isn't leaked, it's still there waiting for eventually a vblank to fire. That tends to happen when re-enabling the pipe, and then the trap springs and the kernel oopses. The correct fix here is simply to refcount the crtc commit to make sure that the event sticks around even for drivers which only sometimes fail to deliver vblanks for some arbitrary reasons. Since crtc commits are already refcounted that's easy to do. References: https://bugs.freedesktop.org/show_bug.cgi?id=96781 Cc: Jim Rees <rees@umich.edu> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Arvind Yadav authored
Here, pci_iomap can fail, handle this case and return -ENOMEM. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
v2: - Replace discouraged with deprecated - Link to new initialization/teardown functions Signed-off-by:
-
Randy Dunlap authored
Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same kconfig value as LEDS_CLASS. drivers/built-in.o: In function `nouveau_do_suspend': nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' drivers/built-in.o: In function `nouveau_do_resume': nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' drivers/built-in.o: In function `nouveau_drm_unload': nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' drivers/built-in.o: In function `nouveau_drm_load': nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' BTW, this line in Kbuild: nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Martin Peres <martin.peres@free.fr> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
- 02 Jan, 2017 2 commits
-
-
Jani Nikula authored
No reason not to be const. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482923186-22430-1-git-send-email-jani.nikula@intel.com
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Archit Taneja <architt@codeaurora.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Archit Taneja <architt@codeaurora.org> [danvet: Remove spurious hunk that Archit spotted.] Signed-off-by:
-
- 30 Dec, 2016 19 commits
-
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Laurent: - Move misplaced doc change to the right patch. - Remove "DRM driver's", it's redundant. - Spotted 3 more places where where we could add prose reference with a real one. Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
If we store the fb funcs pointer, we can remove a bit of boilerplate. Also remove the _fbdev_ in the example code, since the fb_funcs->dirty callback has nothing to do with fbdev. It's a KMS feature, only used by the fbdev deferred_io support to implement flushing/upload. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
I reported the include issue for tracepoints a while ago, but nothing seems to have happened. Now it bit us, since the drm_mm_print conversion was broken for armada. Fix it, so I can re-enable armada in the drm-misc build configs. v2: Rebase just the compile fix on top of Chris' build fix. Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
Missed rename during v2 of b5c3714f ("drm/mm: Convert to drm_printer") Reported-by:
-
Chris Wilson authored
For a virtual device, drm_device.dev is NULL, so becareful not to dereference it unconditionally in core code such as drm_dev_register(). Fixes: 75f6dfe3 ("drm: Deduplicate driver initialization message") Signed-off-by:
-
Daniel Vetter authored
We forgot to clean this up when adding connector refcounting. Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Drive-by polish. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
The new cool is &struct foo (kernel-doc now copes with linebreaks), and structure members should be referenced using &foo.bar. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
I've forgotten to remove this when revamping the connector_list locking. Cc: seanpaul@chromium.org Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Daniel Vetter authored
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i Originally I wasnt a friend of this style because I thought a line-break between the "&struct" and "foo" part would break it. But a quick test shows that " * &struct \n * foo\n" works pefectly well with current kernel-doc. So time to mass-apply these changes! Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i Originally I wasnt a friend of this style because I thought a line-break between the "&struct" and "foo" part would break it. But a quick test shows that " * &struct \n * foo\n" works pefectly well with current kernel-doc. So time to mass-apply these changes! Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
Added some boilerplate for the structs, documented members where they are relevant and plenty of markup for hyperlinks all over. And a few small wording polish. Note that the intro needs some more love after the DRM_MM_INSERT_* patch from Chris has landed. v2: Spelling fixes (Chris). v3: Use &struct foo instead of &foo structure (Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
- Remove the outdated hunk about driver documentation which somehow got misplaced here in the split-up. - Collect all the testing&validation stuff together and give the CRC section a heading for prettier output. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Gabriel Krisman Bertazi authored
ttm_global_reference was renamed to drm_global_reference. This updates the documentation to reflect that. While we are there, document the drm_global_reference API and update the initialization interface documentation. Signed-off-by:
-
Gabriel Krisman Bertazi authored
drm_ioctl_permit is exported but missed a kernel-doc style documentation. Signed-off-by:
-
Gabriel Krisman Bertazi authored
Signed-off-by:
-
Gabriel Krisman Bertazi authored
Several DRM drivers print the same initialization message right after drm_dev_register, so move that to common code. The exception is i915, which uses its own register handle, so let it keep its own message. Notice that this was tested only with Exynos, but looks simple enough for the other drivers. Signed-off-by:
-
Chris Wilson authored
Currently at the end of drm_core_init() we print [ 0.735185] [drm] Initialized which does not provide any user information and is only a breadcrumb for developers, so reduce it from info to debug. Signed-off-by:
-
