- 29 Apr, 2020 4 commits
-
-
Arnd Bergmann authored
Some older versions of gcc badly optimize code that passes an inline function argument into another function by reference, causing huge stack usage: drivers/gpu/drm/bridge/tc358768.c: In function 'tc358768_bridge_pre_enable': drivers/gpu/drm/bridge/tc358768.c:840:1: error: the frame size of 2256 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Use a temporary variable as a workaround and add a comment pointing to the gcc bug. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200428215408.4111675-1-arnd@arndb.de
-
Bartlomiej Zolnierkiewicz authored
powerpc allyesconfig fails like this: drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap': drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of function 'pgprot_cached_wthru'; did you mean 'pgprot_cached'? [-Werror=implicit-function-declaration] 756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot); | ^~~~~~~~~~~~~~~~~~~ | pgprot_cached drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when assigning to type 'pgprot_t' {aka 'struct <anonymous>'} from type 'int' Fix it by adding missing PPC32 dependency. Fixes: a07a63b0 ("video: fbdev: controlfb: add COMPILE_TEST support") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kbuild test robot <lkp@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Ville Syrjälä authored
Let's just calculate the hsync rate on demand. No point in wasting space storing it and risking the cached value getting out of sync with reality. v2: Move drm_mode_hsync() next to its only users Drop the TODO Reviewed-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-2-ville.syrjala@linux.intel.com
-
Thomas Zimmermann authored
MAINTAINERS got sorted in commit 4400b7d6 ("MAINTAINERS: sort entries by entry name") Merging from drm-next into drm-misc-next duplicated some of the entries by restoring old, unsorted sections. Restore the sorted list by removing the duplicates. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Fixes: 08d99b2c ("Merge drm/drm-next into drm-misc-next") Acked-by:
-
- 28 Apr, 2020 36 commits
-
-
Rob Herring authored
Since the VExpress setup in pl111_vexpress.c is now just a single function call, let's move it into pl111_versatile.c and we can further simplify pl111_versatile_init() by moving the other pieces for VExpress into pl111_vexpress_clcd_init(). Cc: Eric Anholt <eric@anholt.net> Cc: dri-devel@lists.freedesktop.org Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200409013947.12667-4-robh@kernel.org
-
Rob Herring authored
The init VExpress variants currently instantiates a 'muxfpga' driver for the sole purpose of getting a regmap for it. There's no reason to instantiate a driver and doing so just complicates things. The muxfpga driver also isn't unregistered properly on module unload. Let's just simplify all this this by just calling devm_regmap_init_vexpress_config() directly. Cc: Eric Anholt <eric@anholt.net> Cc: dri-devel@lists.freedesktop.org Acked-by:
-
Rob Herring authored
Add a missing MODULE_DEVICE_TABLE entry to fix module autoloading. Cc: Eric Anholt <eric@anholt.net> Cc: dri-devel@lists.freedesktop.org Acked-by:
-
Daniel Vetter authored
Luckily we're already well set up in the main driver, with drm_dev_put() being the last thing in both the unload error case and the pci remove function. Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-39-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
-
Daniel Vetter authored
Also need to remove the drm_dev_put from the remove hook. Acked-by:
-
Kenny Levinsen authored
Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP. As drm_file uses unkeyed wakeups, such a poll receives many spurious wakeups from uninteresting events. Use keyed wakeups to allow the wakeup target to more efficiently discard these uninteresting events. Signed-off-by:
Kenny Levinsen <kl@kl.wtf> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200424145103.3048-1-kl@kl.wtf
-
Daniel Vetter authored
This is leftovers from the old drm_driver->load callback upside-down issues. It doesn't do anything for not-hotplugged connectors since drm_dev_register takes care of that. Acked-by:
-
Daniel Vetter authored
This is only needed for hotpluggable connectors set up after drm_dev_register(). Reviewed-by:
-
Daniel Vetter authored
As usual, we can drop the drm_dev_put() and need to embed the drm_device. Since it's so few, also go right ahead and leave drm_device->dev_private set to NULL, so that we always use the container_of() upcast, which is faster anyway. Acked-by:
-
Daniel Vetter authored
No longer used since the conversion to generic fbdev. Acked-by:
-
Daniel Vetter authored
Because it is. Huge congrats to everyone who made this kind of refactoring happen! Acked-by:
-
Daniel Vetter authored
Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Acked-by:
Eric Anholt <eric@anholt.net> Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
-
Daniel Vetter authored
Komeda uses the component framework, which does open/close a new devres group around all the bind callbacks. Which means we can use devm_ functions for managing the drm_device cleanup, with leaking stuff in case of deferred probes or other reasons to unbind components, or the component_master. Also note that this fixes a double-free in the probe unroll code, bot drm_dev_put and kfree(kms) result in the kms allocation getting freed. Aside: komeda_bind could be cleaned up a lot, devm_kfree is a bit redundant. Plus I'm not clear on why there's suballocations for mdrv->mdev and mdrv->kms. Plus I'm not sure the lifetimes are correct with all that devm_kzalloc usage ... That structure layout is also the reason why komeda still uses drm_device->dev_private and can't easily be replaced with a proper container_of upcasting. I'm pretty sure that there's endless amounts of hotunplug/hotremove bugs in there with all the unprotected dereferencing of drm_device->dev_private. Reviewed-by:
James Qian Wang <james.qian.wang@arm.com> Signed-off-by:
-
Daniel Vetter authored
Entirely not used, just copypasta. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. v2: Move misplaced removal of double-assignment to this patch (Sam) Reviewed-by: Linus Walleij <linus.walleij@linaro.org> (v1) Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. v2: Move misplaced double-assignement to next patch (Sam) Acked-by:
-
Daniel Vetter authored
Not used anymore since the switch to suspend/resume helpers. Tested-by:
Jyri Sarha <jsarha@ti.com> Acked-by:
-
Daniel Vetter authored
Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Tested-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Tested-by:
-
Daniel Vetter authored
Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
David Lechner <david@lechnology.com> Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Acked-by:
-
Daniel Vetter authored
Already using devm_drm_dev_init, so very simple replacment. Aside: There was an oddity in the old code, we allocated priv but in the error path we've freed priv->dbidev ... Acked-by:
-
Daniel Vetter authored
We're mostly there already, just a handful of places that didn't use the to_udl container_of cast. To make sure no new appear, don't set ->dev_private. Reviewed-by:
-
Daniel Vetter authored
With Thomas' patch to clean up fbdev init this is a rather standard conversion to the new wrapper macro. v2: Rebase on top of Thomas' patches to remove the return value from drm_fbdev_generic_setup() v3: Update commit message to reflect the reality of the rebased patch (Sam) Reviewed-by:
-
Daniel Vetter authored
We already have it in v3d_dev->drm.dev with zero additional pointer chasing. Personally I don't like duplicated pointers like this because: - reviewers need to check whether the pointer is for the same or different objects if there's multiple - compilers have an easier time too To avoid having to pull in some big headers I implemented the casting function as a macro instead of a static inline. Typechecking thanks to container_of still assured. But also a bit a bikeshed, so feel free to ignore. v2: More parens for v3d_to_pdev macro (checkpatch) Acked-by:
-
Daniel Vetter authored
We already have it in v3d_dev->drm.dev with zero additional pointer chasing. Personally I don't like duplicated pointers like this because: - reviewers need to check whether the pointer is for the same or different objects if there's multiple - compilers have an easier time too But also a bit a bikeshed, so feel free to ignore. Acked-by:
-
