- 29 Aug, 2016 14 commits
-
-
Daniel Vetter authored
This just contains the base property classes and all the code to handle blobs. I think for any kind of standardized/shared properties it's better to have separate files - this is fairly big already as-is. v2: resurrect misplaced hunk (Daniel Stone) Cc: Daniel Stone <daniel@fooishbar.org> Reviewed-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-7-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's part of the drm fourcc handling code, mapping the old depth/bpp values to new fourcc codes. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
I figured an overview section here is overkill, and better to just document the 2 structures themselves well enough. v2: Review from Archit: - Appease checkpatch in moved code. - Spelling fixes in the kerneldoc. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-5-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's only used in drm_mode_object_get_properties, and we can compute it there directly with a bit of code shuffling. Reviewed-by:
-
Daniel Vetter authored
Just for the struct drm_mode_object base class. The header file was already partially extracted to help untangle the include loops. v2: - Also move the generic get/set property ioctls. At first this seemed like a bad idea since it requires making drm_mode_crtc_set_obj_prop non-static. But eventually that will get split away too (like the connector version already is) for both crtc and planes. Hence I reconsidered. - drm_mode_object.[hc] instead of drm_modeset.[hc], which requires renaming the drm_modeset.h header I already started building up. This is more consistent (matches the name of the main structure), and I want to be able to use drm_modeset.[hc] for the basic modeset init/cleanup functionality like drm_mode_config_init. Reviewed-by:
-
Daniel Vetter authored
- Move missing bits into struct drm_encoder docs. - Explain that encoders are 95% internal and only 5% uapi, and that in general the uapi part is broken. - Remove verbose comments for functions not exposed to drivers. v2: Review from Archit: - Appease checkpatch in the moved code. - Make it clearer that bridges are not exposed to userspace. Reviewed-by:
-
Daniel Vetter authored
Same treatment as before. Only hiccup is drm_crtc_mask, which unfortunately can't be resolved until drm_crtc.h is less of a monster. Untangle the header loop with a forward declaration for that static inline. Reviewed-by:
-
Arnd Bergmann authored
When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration in which some DRM drivers are built-in, but the framebuffer core is a loadable module. This results in a link error, such as: drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe': radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe': amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init': mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe': mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to `remove_conflicting_framebuffers' Makefile:969: recipe for target 'vmlinux' failed This changes the compile-time check to IS_REACHABLE, which means we end up not calling remove_conflicting_framebuffers() in the configuration, which seems good enough, as we know that no framebuffer driver is loaded by the time that the built-in DRM driver calls remove_conflicting_framebuffers. We could alternatively avoid the link error by forcing CONFIG_FB to not be a module in this case, but that wouldn't change anything at runtime, and just make the already convoluted set of dependencies worse here. I could not find out what happens if the fbdev driver gets loaded as a module after the DRM driver is already initialized, but that is a case that can happen with or without this patch. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 0a3bfe29 ("drm/fb-helper: Fix the dummy remove_conflicting_framebuffers") Signed-off-by:
-
Liu Ying authored
Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter of the helper drm_atomic_helper_commit_planes() if the relevant display controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes when the CRTC is disabled. The helper would skip the ->atomic_disable call for a plane if the CRTC of the old plane state needs a modesetting operation. Of course, the drivers need to disable the planes in their CRTC disable callbacks since no one else would do that. Suggested-by:
Liu Ying <gnuiyl@gmail.com> Signed-off-by:
-
Liu Ying authored
Currently, the helper drm_atomic_helper_disable_planes_on_crtc() calls ->atomic_disable for all planes _to be_ enabled on a particular CRTC. This is obviously wrong for those planes which are not scanning out frames when the helper is called. Instead, it's sane to disable active planes of old_crtc_state in the helper. Suggested-by:
-
Liu Ying authored
Some display controllers need plane(s) to be disabled together with the relevant CRTC, e.g., the IPUv3 display controller for imx-drm. This patch adds atomic_disable CRTC helper callback so that old_crtc_state(as a parameter of the callback) could be used to get the active plane(s) of the old CRTC state for disable operation. Suggested-by:
-
Andrea Merello authored
Introduce drm_simple_display_pipe_attach_bridge() and drm_simple_display_pipe_detach_bridge() in order to make it possible to use drm encoders with the simple display pipes managed by simple_kms_helpers Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Andrea Merello <andrea.merello@gmail.com> Reviewed-by:
-
Andrea Merello authored
drm_simple_display_pipe_init() pretends to attach a connector to the display pipe. In case a drm bridge has to be used, then it's the bridge that takes care of connectors. This patch makes the connector parameter optional for drm_simple_display_pipe_init(), so that a drm bridge could handle connector by itself later. Signed-off-by:
-
Andrea Merello authored
Up to now, once a bridge has been attached to a DRM device, it cannot be undone. In particular you couldn't rmmod/insmod a DRM driver that uses a bridge, because the bridge would remain bound to the first (dead) driver instance. This patch fixes this by introducing drm_encoder_detach() and a ->detach callback in drm_bridge_funcs for the bridge to be notified about detaches. It's DRM/KMS driver responsibility to call drm_encoder_detach(). While adding the bridge detach callback, with its kerneldoc, I also added kerneldoc for attach callback. Few other kerneldocs fixes around there are included. Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
- 25 Aug, 2016 4 commits
-
-
Daniel Vetter authored
Our update function is hooked to the single plane, which might not get called for crtc-only updates. Which is surprising, so fix this by always adding the plane. While at it document how&when the event should be sent out better in the kerneldoc. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: andrea.merello@gmail.com Tested-and-Reported-by: andrea.merello@gmail.com Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
David Herrmann authored
The *only* known user of GETCLIENT is libva, which uses it to check whether its own context is authenticated. It used to iterate all clients, look for one that matches its own pid and then check its state. The entire purpose for us to still have a GETCLIENT implementation is to serve libva. So lets not pretend we do anything else: Make this function return information on the caller's context only, fake the PID to the caller's pid so they always match, and just fill in the "authenticated" bit, nothing else. This patch reduces the complexity of GETCLIENT to a bare minimum, avoids any dependency on priv->uid or priv->pid (allows us to get rid of them), and makes libva happy by always *exactly* returning the information it wants. Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
David Herrmann authored
The legacy DRI1 drivers expose highly broken interfaces to user-space. No modern system should enable them, or you will effectively allow user-space to circumvent most of your kernel security measures. The DRI1 kernel APIs are simply broken. User-space can always use vesafb/efifb/simplefb and friends to get working graphics. Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to be still used (really?), we can easily revert this and figure out a way to move them out of sight (e.g., moving all DRI1 drivers to drivers/gpu/dri1/). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
David Herrmann authored
Lets move forward and hide the remaining DRI1 drivers behind a config option, so we have a central place to disable them all. Furthermore, we can provide a clear warning to anyone enabling them. Signed-off-by:
-
- 24 Aug, 2016 2 commits
-
-
Daniel Vetter authored
Reported-by:
-
Masahiro Yamada authored
Commit d112a816 ("gma500/cdv: Add eDP support") replaced the code inside this if-conditional with gma_backlight_set(), which becomes a nop stub if CONFIG_BACKLIGHT_CLASS_DEVICE is disabled. So, there is no need to guard the caller with config_enabled(). Note: This is one of remaining TODOs to deprecate config_enabled() macro. Refer to commit 97f2645f ("tree-wide: replace config_enabled() with IS_ENABLED()"). Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
- 23 Aug, 2016 9 commits
-
-
Daniel Vetter authored
Everyone knows them, except all the new folks joining from the ARM side haven't lived through all the pain of the past years and are entirely surprised when I raise this. Definitely time to document this. Last time this was a big discussion was about 6 years ago, when qcom tried to land a kernel driver without userspace. Dave Airlie made the rules really clear: http://airlied.livejournal.com/73115.html This write-up here is essentially what I've put into a presentation a while ago, which was also reviewed by Dave: http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html v2: Fix typos Eric&Rob spotted. v3: Nitpick from Jani. Cc: Dave Airlie <airlied@gmail.com> Cc: Oded Gabbay <oded.gabbay@gmail.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Eric Anholt <eric@anholt.net> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Stefan Agner <stefan@agner.ch> Cc: Inki Dae <inki.dae@samsung.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Acked-by:
Dave Airlie <airlied@gmail.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
A few bigger things: - start of splitting drm_crtc.c into more manageable and better documneted chunks - DRM_DEV_* logging (Sean) * tag 'topic/drm-misc-2016-08-23' of git://anongit.freedesktop.org/drm-intel: (46 commits) drm/fb-helper: Make docs for fb_set_suspend wrappers consistent drm/rockchip: Delete unnecessary assignment for the field "owner" drm/bridge: dw-hdmi: Delete unnecessary assignment for the field "owner" drm/rockchip: Don't continue trying to enable crtc on failure drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked() drm/fb-helper: Fix the dummy remove_conflicting_framebuffers drm/udl: Ensure channel is selected before using the device. drm: Avoid calling dev_printk(.dev = NULL) drm: avoid exposing kernel stack in compat_drm_getstats reservation: fix small comment typo drm: Don't implement empty prepare_fb()/cleanup_fb() virtio-gpu: Use memdup_user() rather than duplicating its implementation GPU-DRM-Savage: Use memdup_user() rather than duplicating drm: Allow drivers to modify plane_state in prepare_fb/cleanup_fb drm/rockchip: Use DRM_DEV_ERROR in vop drm: Introduce DRM_DEV_* log messages drm/edid: CEA mode 64 1080p100 vsync pulse width incorrect Revert "drm/hisilicon: Don't set drm_device->platformdev" dma-buf: fix kernel-doc warning and typos drm: Fix kerneldoc in drm_plane_helper.c ...
-
Daniel Vetter authored
I figured I might as well go ocd and make them booleans and rename the locked version too. v2: Review from Noralf. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Fixes: cfe63423 ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()") Acked-by:
-
Markus Elfring authored
The field "owner" is set by the core. Thus delete an unneeded initialisation. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/41e48fd3-f713-7225-1df2-3b1f4758f949@users.sourceforge.net
-
Markus Elfring authored
The field "owner" is set by the core. Thus delete an unneeded initialisation. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by:
-
Sean Paul authored
If vop_enable fails, don't continue on, it causes system hangs. Reviewed-by:
Yakir Yank <ykk@rock-chips.com> Tested-by:
-
Noralf Trønnes authored
This adds a function that also takes the console lock before calling fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is a plain wrapper around fb_set_suspend(). Resume is run asynchronously using a worker if the console lock is already taken. This is modelled after the i915 driver. Signed-off-by:
-
Chris Wilson authored
We always need to remove conflicting framebuffers if any other fb driver is enabled, and not just if we are setting up an fbdev ourselves. Unfortunately remove_conflicting_framebuffers() was incorrectly stubbed out if !fbdev rather than !fb leading to major memory corruption (and corrupt filesystems) upon boot. Fixes: 44adece5 ("drm/fb-helper: Add a dummy remove_conflicting_framebuffers") Signed-off-by:
-
Jamie Lentin authored
Lift configuration command from udlfb. This appears to be essential for at least a Rextron VCUD-60, without which no URB communication occurs. Signed-off-by:
Jamie Lentin <jm@lentin.co.uk> Signed-off-by:
-
- 22 Aug, 2016 3 commits
-
-
Chris Wilson authored
Since dev_printk likes to print "(NULL device *):" when passed in a NULL pointer, we have to manually call printk() ourselves. Fixes: c4e68a58 ("drm: Introduce DRM_DEV_* log messages") Signed-off-by:
-
Heinrich Schuchardt authored
The C standard does not specify the size of the integer used to store an enum. Hence in structure drm_stats32_t alignment bytes may exist. To avoid exposing bytes from the kernel stack it is necessary to initialize variable s32 completely. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
-
Rob Clark authored
Signed-off-by:
-
- 19 Aug, 2016 4 commits
-
-
Laurent Pinchart authored
The plane .prepare_fb() and .cleanup_fb() helpers are optional, there's no need to implement empty stubs, and no need to explicitly set the function pointers to NULL either. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [danvet: Resolved conflicts with Chris' patch.] Signed-off-by:
-
Markus Elfring authored
Reuse existing functionality from memdup_user() instead of keeping duplicate source code. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
Reuse existing functionality from memdup_user() instead of keeping duplicate source code. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Chris Wilson authored
The drivers have to modify the atomic plane state during the prepare_fb callback so they track allocations, reservations and dependencies for this atomic operation involving this fb. In particular, how else do we set the plane->fence from the framebuffer! Signed-off-by:
-
- 18 Aug, 2016 3 commits
-
-
Sean Paul authored
Since we can have multiple vops, use DRM_DEV_ERROR to make logs easier to process. Acked-by:
Mark Yao <mark.yao@rockchip.com> Signed-off-by:
-
Sean Paul authored
This patch consolidates all the various log functions/macros into one uber function, drm_log. It also introduces some new DRM_DEV_* variants that print the device name to delineate multiple devices of the same type. Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by:
-
Clint Taylor authored
In the CEA-861 specification VIC 64 specifies a vsync pulse of 5 and a backporch of 36. Adjust vsync pulse width to match specification. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
- 17 Aug, 2016 1 commit
-
-
Daniel Vetter authored
This reverts commit d25bcfb8. I somehow missed that it only compiles on arm64 and broke the driver rather badly. Signed-off-by:
-
