- 19 Aug, 2019 9 commits
-
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct mmp_path { ... struct mmp_overlay overlays[0]; }; size = sizeof(struct mmp_path) + count * sizeof(struct mmp_overlay); instance = kzalloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, overlays, count), GFP_KERNEL) Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807161312.GA26835@embeddedor
-
Souptick Joarder authored
This is dead code since 3.15. If there is no plan to use it further, this can be removed forever. Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> [b.zolnierkie: fix patch summary] Signed-off-by:
-
Souptick Joarder authored
This is dead code since 3.15. If there is no plan to use it further, this can be removed forever. Signed-off-by:
-
Anders Roxell authored
Now that -Wimplicit-fallthrough is passed to GCC by default, the following warnings shows up: ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_channel_fb_init’: ../drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=] info->fix.ypanstep = 2; ~~~~~~~~~~~~~~~~~~~^~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c:2087:2: note: here case V4L2_PIX_FMT_NV16: ^~~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_overlay_fb_init’: ../drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=] info->fix.ypanstep = 2; ~~~~~~~~~~~~~~~~~~~^~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c:1597:2: note: here case V4L2_PIX_FMT_NV16: ^~~~ Rework to address a warnings due to the enablement of -Wimplicit-fallthrough. Signed-off-by:
Anders Roxell <anders.roxell@linaro.org> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com> [b.zolnierkie: fix patch summary] Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [b.zolnierkie: fix patch summary and intendation] Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
-
Gustavo A. R. Silva authored
There is no need to compare *var->xoffset* or *var->yoffset* with < 0 because such variables are of type unsigned, making it impossible to hold a negative value. Fix this by removing such comparisons. Addresses-Coverity-ID: 1451964 ("Unsigned compared against 0") Signed-off-by: -
Hans de Goede authored
For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable. Extensive testing has shown that when the info is correct, the BGRT image is always exactly centered horizontally (the yoffset variable is more variable and not always predictable). This commit simplifies / improves the bgrt_sanity_check to simply check that the BGRT image is exactly centered horizontally and skips (re)drawing it when it is not. This fixes the BGRT image sometimes being drawn in the wrong place. Cc: stable@vger.kernel.org Fixes: 88fe4ceb ("efifb: BGRT: Do not copy the boot graphics for non native resolutions") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Cc: Peter Jones <pjones@redhat.com>, Signed-off-by:
-
Nishka Dasgupta authored
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only when it is passed to drm_gem_fb_create_with_funcs() as its last argument. drm_gem_fb_create_with_funcs does not modify its lst argument (fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs constant to protect it from further modification. Issue found with Coccinelle. Signed-off-by:
Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by:
-
- 18 Aug, 2019 1 commit
-
-
Nishka Dasgupta authored
The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs, is used only when it is passed as the third argument to drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it constant to protect it from unintended modifications. Issue found with Coccinelle. Signed-off-by:
-
- 17 Aug, 2019 5 commits
-
-
Chris Wilson authored
The timestamp and the cb_list are mutually exclusive, the cb_list can only be added to prior to being signaled (and once signaled we drain), while the timestamp is only valid upon being signaled. Both the timestamp and the cb_list are only valid while the fence is alive, and as soon as no references are held can be replaced by the rcu_head. By reusing the union for the timestamp, we squeeze the base dma_fence struct to 64 bytes on x86-64. v2: Sort the union chronologically Suggested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Acked-by: Christian König <christian.koenig@amd.com>. Link: https://patchwork.freedesktop.org/patch/msgid/20190817153022.5749-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Currently dma_fence_signal() tries to avoid the spinlock and only takes it if absolutely required to walk the callback list. However, to allow for some users to surreptitiously insert lazy signal callbacks that do not depend on enabling the signaling mechanism around every fence, we always need to notify the callbacks on signaling. As such, we will always need to take the spinlock and dma_fence_signal() effectively becomes a clone of dma_fence_signal_locked(). v2: Update the test_and_set_bit() before entering the spinlock. v3: Drop the test_[and_set]_bit() before the spinlock, it's a caller error so expected to be very unlikely. Signed-off-by:
-
Chris Wilson authored
Before we notify the fence signal callback, we remove the cb from the list. However, since we are processing the entire list from underneath the spinlock, we do not need to individual delete each element, but can simply reset the link and the entire list. Signed-off-by:
-
Chris Wilson authored
Rearrange the couple of 32-bit atomics hidden amongst the field of pointers that unnecessarily caused the compiler to insert some padding, shrinks the size of the base struct dma_fence from 80 to 72 bytes on x86-64. Signed-off-by:
-
Colin Ian King authored
Variable val is initialized to a value in a for-loop that is never read and hence it is redundant. Remove it. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190817122124.29650-1-colin.king@canonical.com
-
- 16 Aug, 2019 3 commits
-
-
Laurent Pinchart authored
drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01, NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the omapdrm-specific drivers. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Laurent Pinchart authored
Standard DRM panel drivers for several panels used by omapfb2 are now available. Their module name clashes with the modules from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver is disabled, and the DRM panel drivers are useless in that case, make the omapfb2 panels depend on the standard DRM panels being disabled to fix the name clash. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: dc2e1e5b ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel") Fixes: 415b8dd0 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel") Fixes: 1c8fc3f0 ("drm/panel: Add driver for the Sony ACX565AKM panel") Fixes: c9cf4c2a ("drm/panel: Add driver for the Sharp LS037V7DW01 panel") Fixes: df439abe ("drm/panel: Add driver for the NEC NL8048HL11 panel") Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [added tags] Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-2-laurent.pinchart@ideasonboard.com
-
Chris Wilson authored
This reverts 67c97fb7 ("dma-buf: add reservation_object_fences helper") dd7a7d1f ("drm/i915: use new reservation_object_fences helper") 0e1d8083 ("dma-buf: further relax reservation_object_add_shared_fence") 5d344f58 ("dma-buf: nuke reservation_object seq number") The scenario that defeats simply grabbing a set of shared/exclusive fences and using them blissfully under RCU is that any of those fences may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this scenario, while keeping the rcu_read_lock we need to establish that no fence was changed in the dma_resv after a read (or full) memory barrier. Signed-off-by:
-
- 14 Aug, 2019 22 commits
-
-
Laurent Pinchart authored
This panel is used on the OMAP3 Pandora. The code is based on the omapdrm-specific panel-tpo-td043mtea1 driver. v2: - fix checkpatch warnings o (lcd == NULL) => (!lcd) (sam) o alignment to open '(' (sam) Signed-off-by: -
Laurent Pinchart authored
This panel is used on the OpenMoko Neo FreeRunner and Neo 1973. The code is based on the omapdrm-specific panel-tpo-td028ttec1 driver. v2: - fix checkpatch warnings: o (lcd == NULL) => (!lcd) (sam) o (1 << X) => BIT(X) (sam) Signed-off-by:
-
Laurent Pinchart authored
This panel is used on the Nokia N900. The code is based on the omapdrm-specific panel-sony-acx565akm driver. The hardware-related logic has been changed as little as possible to avoid regressions as hardware availability is lacking to test the changes. Follow-up patches should address the items listed in the TODO list. v2: - fix checkpatch warning (lcd == NULL) => (!lcd) (sam) Signed-off-by:
-
Laurent Pinchart authored
This panel is used on the TI SDP3430 board. The code is based on the omapdrm-specific panel-sharp-ls037v7dw01 driver. v2: - fix checkpatch warning (lcd == NULL) => (!lcd) (sam) - drop __exit_p() from remove. It caused a build warning. And no other panel drivers needs this (sam) Signed-off-by:
-
Laurent Pinchart authored
This panel is used on the Zoom2/3/3630 SDP boards. The code is based on the omapdrm-specific panel-nec-nl8048hl11 driver v2: - fix checkpatch warning (lcd == NULL) => (!lcd) (sam) Signed-off-by:
-
Laurent Pinchart authored
This panel is used on the Gumstix Overo Palo35. The code is based on the omapdrm-specific panel-lgphilips-lb035q02 driver. Signed-off-by:
-
Laurent Pinchart authored
The NEC NL8048HL11 is a 10.4cm WVGA (800x480) panel with a 24-bit RGB parallel data interface and an SPI control interface. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Laurent Pinchart authored
The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and document it as legacy. Signed-off-by:
-
Laurent Pinchart authored
LG Display is an LCD display manufacturer. Originally formed as a joint venture by LG Electronics and Philips Electronics, it was formerly known as LG.Philips LCD, hence the DT vendor prefix lgphilips (which is already in active use in the kernel). More information is available at https://en.wikipedia.org/wiki/LG_Display. Signed-off-by:
-
Nishka Dasgupta authored
The static structure aspeed_gfx_funcs, of type drm_simple_display_pipe_funcs, is used only as an argument to drm_simple_display_pipe_init(), which does not modify it. Hence make it constant to protect it from unintended modification. Issue found with Coccinelle. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190813063355.25549-1-nishkadg.linux@gmail.com
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file. While touching the list of include files divide them into blocks and sort within each block. Fix fallout. Signed-off-by:
Thierry Reding <treding@nvidia.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: malidp@foss.arm.com Link: https://patchwork.freedesktop.org/patch/msgid/20190804094132.29463-5-sam@ravnborg.org
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file. While touching the list of include files group them and sort them. Fix fallout from the header file removal. Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file. For all touched files divide include files into blocks, and sort them within the blocks. Fix fallout. Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file. Fix fallout. Signed-off-by:
-
Geert Uytterhoeven authored
If the VGA connector has no DDC channel, an error pointer will be dereferenced, e.g. on Salvator-XS: Unable to handle kernel NULL pointer dereference at virtual address 000000000000017d ... Call trace: sysfs_do_create_link_sd.isra.0+0x40/0x108 sysfs_create_link+0x20/0x40 drm_sysfs_connector_add+0xa8/0xc8 drm_connector_register.part.3+0x54/0xb0 drm_connector_register_all+0xb0/0xd0 drm_modeset_register_all+0x54/0x88 drm_dev_register+0x18c/0x1d8 rcar_du_probe+0xe4/0x150 ... This happens because vga->ddc either contains a valid DDC channel pointer, or -ENODEV, and drm_connector_init_with_ddc() expects a valid DDC channel pointer, or NULL. Fix this by resetting vga->ddc to NULL in case of -ENODEV, and replacing the existing error checks by non-NULL checks. This is similar to what the HDMI connector driver does. Fixes: a4f9087e ("drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory") Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jerome Brunet authored
Provide the eld to the generic hdmi-codec driver. This will let the driver enforce the maximum channel number and set the channel allocation depending on the hdmi sink. Cc: Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jonas Karlman <jonas@kwiboo.se> Reviewed-by:
-
Jerome Brunet authored
Enable the i2s lanes depending on the number of channel in the stream Reviewed-by:
-
Jerome Brunet authored
When changing the audio hw params, reset the audio fifo to make sure any old remaining data is flushed. The databook mentions that such reset should be followed by a reset of the i2s block to make sure the samples stay aligned Reviewed-by:
-
Jerome Brunet authored
setup the channel allocation provided by the generic hdmi-codec driver Reviewed-by:
-
Jerome Brunet authored
Properly setup the channel count and layout in dw-hdmi i2s driver so we are not limited to 2 channels. Also correct the maximum channel reported by the DAI from 6 to 8 ch Reviewed-by:
-
Jerome Brunet authored
Set the number of channel in the infoframes Reviewed-by:
-
Jerome Brunet authored
Part of the channel count setup done in dw-hdmi ahb should actually be done whatever the interface providing the data. Let's move it to dw-hdmi driver instead. Reviewed-by:
-
