summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2019-04-10drm: switch drm_fb_xrgb8888_to_rgb565_dstclip to accept __iomem dstGerd Hoffmann
Not all archs have the __io_virt() macro, so cirrus can't simply convert pointers that way. The drm format helpers have to use memcpy_toio() instead. This patch makes drm_fb_xrgb8888_to_rgb565_dstclip() accept a __iomem dst pointer and use memcpy_toio() instead of memcpy(). The helper function (drm_fb_xrgb8888_to_rgb565_line) has been changed to process a single scanline. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190410063815.17062-3-kraxel@redhat.com
2019-04-10drm: switch drm_fb_memcpy_dstclip to accept __iomem dstGerd Hoffmann
Not all archs have the __io_virt() macro, so cirrus can't simply convert pointers that way. The drm format helpers have to use memcpy_toio() instead. This patch makes drm_fb_memcpy_dstclip() accept a __iomem dst pointer and use memcpy_toio() instead of memcpy(). With that separating out the memcpy loop into the drm_fb_memcpy_lines() helper isn't useful any more, so move the code back into the calling functins. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190410063815.17062-2-kraxel@redhat.com
2019-04-08drm: add drm_fb_xrgb8888_to_rgb888_dstclip()Gerd Hoffmann
Simliar to drm_fb_xrgb8888_to_rgb565_dstclip() but converts to rgb888 instead of rgb565. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-5-kraxel@redhat.com
2019-04-08drm: add drm_fb_xrgb8888_to_rgb565_dstclip()Gerd Hoffmann
It is a drm_fb_xrgb8888_to_rgb565() variant which checks the clip rectangle for the destination too. Common code between drm_fb_xrgb8888_to_rgb565() and drm_fb_xrgb8888_to_rgb565_dstclip() was factored out into the drm_fb_xrgb8888_to_rgb565_lines() helper function. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-4-kraxel@redhat.com
2019-04-08drm: add drm_fb_memcpy_dstclip() helperGerd Hoffmann
It is a drm_fb_memcpy() variant which checks the clip rectangle for the destination too. Common code between drm_fb_memcpy() and drm_fb_memcpy_dstclip() was factored out into the drm_fb_memcpy_lines() helper function. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-3-kraxel@redhat.com
2019-04-08drm: move tinydrm format conversion helpers to new drm_format_helper.cGerd Hoffmann
Also rename them from tinydrm_* to drm_fb_* Pure code motion, no functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-2-kraxel@redhat.com
2019-04-03drm/gamma: Clarify gamma lut uapiDaniel Vetter
Interpreting it as a 0.16 fixed point means we can't accurately represent 1.0. Which is one of the values we really should be able to represent. Since most (all?) luts have lower precision this will only affect rounding of 0xffff. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Kumar, Kiran S" <kiran.s.kumar@intel.com> Cc: Kausal Malladi <kausalmalladi@gmail.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rob Bradford <robert.bradford@intel.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Stefan Schake <stschake@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: James (Qian) Wang <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190329092027.3430-1-daniel.vetter@ffwll.ch
2019-04-01drm/lima: driver for ARM Mali4xx GPUsQiang Yu
- Mali 4xx GPUs have two kinds of processors GP and PP. GP is for OpenGL vertex shader processing and PP is for fragment shader processing. Each processor has its own MMU so prcessors work in virtual address space. - There's only one GP but multiple PP (max 4 for mali 400 and 8 for mali 450) in the same mali 4xx GPU. All PPs are grouped togather to handle a single fragment shader task divided by FB output tiled pixels. Mali 400 user space driver is responsible for assign target tiled pixels to each PP, but mali 450 has a HW module called DLBU to dynamically balance each PP's load. - User space driver allocate buffer object and map into GPU virtual address space, upload command stream and draw data with CPU mmap of the buffer object, then submit task to GP/PP with a register frame indicating where is the command stream and misc settings. - There's no command stream validation/relocation due to each user process has its own GPU virtual address space. GP/PP's MMU switch virtual address space before running two tasks from different user process. Error or evil user space code just get MMU fault or GP/PP error IRQ, then the HW/SW will be recovered. - Use GEM+shmem for MM. Currently just alloc and pin memory when gem object creation. GPU vm map of the buffer is also done in the alloc stage in kernel space. We may delay the memory allocation and real GPU vm map to command submission stage in the furture as improvement. - Use drm_sched for GPU task schedule. Each OpenGL context should have a lima context object in the kernel to distinguish tasks from different user. drm_sched gets task from each lima context in a fair way. mesa driver can be found here before upstreamed: https://gitlab.freedesktop.org/lima/mesa v8: - add comments for in_sync - fix ctx free miss mutex unlock v7: - remove lima_fence_ops with default value - move fence slab create to device probe - check pad ioctl args to be zero - add comments for user/kernel interface v6: - fix comments by checkpatch.pl v5: - export gp/pp version to userspace - rebase on drm-misc-next v4: - use get param interface to get info - separate context create/free ioctl - remove unused max sched task param - update copyright time - use xarray instead of idr - stop using drmP.h v3: - fix comments from kbuild robot - restrict supported arch to tested ones v2: - fix syscall argument check - fix job finish fence leak since kernel 5.0 - use drm syncobj to replace native fence - move buffer object GPU va map into kernel - reserve syscall argument space for future info - remove kernel gem modifier - switch TTM back to GEM+shmem MM - use time based io poll - use whole register name - adopt gem reservation obj integration - use drm_timeout_abs_to_jiffies Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh@kernel.org> Cc: Christian König <ckoenig.leichtzumerken@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de> Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Simon Shields <simon@lineageos.org> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Rob Herring <robh@kerrnel.org> Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/291200/
2019-04-01drm: Add a helper function for printing a debugfs_regset32.Eric Anholt
The debugfs_regset32 is nice to use for reducing boilerplate in dumping a bunch of regs in debugfs, but we also want to be able to print to dmesg them at runtime for driver debugging. drm_printer lets us format debugfs and the printk the same way. v2: Add some kerneldoc for the function (requested by danvet) Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190220210343.28157-1-eric@anholt.net Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> (v1) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-04-01drm/syncobj: add timeline signal ioctl for syncobj v5Chunming Zhou
v2: individually allocate chain array, since chain node is free independently. v3: all existing points must be already signaled before cpu perform signal operation, so add check condition for that. v4: remove v3 change and add checking to prevent out-of-order v5: unify binary and timeline Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: Tobias Hector <Tobias.Hector@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295792/?series=58813&rev=1
2019-04-01drm/syncobj: add transition iotcls between binary and timeline v2Chunming Zhou
we need to import/export timeline point. v2: unify to one transfer ioctl Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295790/?series=58813&rev=1
2019-04-01drm/syncobj: add timeline payload query ioctl v6Chunming Zhou
user mode can query timeline payload. v2: check return value of copy_to_user v3: handle querying entry by entry v4: rebase on new chain container, simplify interface v5: query last signaled timeline point, not last point. v6: add unorder point check Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: Tobias Hector <Tobias.Hector@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295784/?series=58813&rev=1
2019-04-01drm/syncobj: add support for timeline point wait v8Chunming Zhou
points array is one-to-one match with syncobjs array. v2: add seperate ioctl for timeline point wait, otherwise break uapi. v3: userspace can specify two kinds waits:: a. Wait for time point to be completed. b. and wait for time point to become available v4: rebase v5: add comment for xxx_WAIT_AVAILABLE v6: rebase and rework on new container v7: drop _WAIT_COMPLETED, it is the default anyway v8: correctly handle garbage collected fences Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: Tobias Hector <Tobias.Hector@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295782/?series=58813&rev=1
2019-04-01drm/syncobj: add new drm_syncobj_add_point interface v4Christian König
Use the dma_fence_chain object to create a timeline of fence objects instead of just replacing the existing fence. v2: rebase and cleanup v3: fix garbage collection parameters v4: add unorder point check, print a warn calltrace Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295780/?series=58813&rev=1
2019-04-01dma-buf: add new dma_fence_chain container v7Christian König
Lockless container implementation similar to a dma_fence_array, but with only two elements per node and automatic garbage collection. v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno, drop prev reference during garbage collection if it's not a chain fence. v3: use head and iterator for dma_fence_chain_for_each v4: fix reference count in dma_fence_chain_enable_signaling v5: fix iteration when walking each chain node v6: add __rcu for member 'prev' of struct chain node v7: fix rcu warnings from kernel robot Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295778/?series=58813&rev=1
2019-03-27drm/fb-helper: Fixup fill_info cleanupDaniel Vetter
I forgot the !CONFIG_FBDEV case. Also some kerneldoc needed more adjusting. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Alex Deucher <alexander.deucher@amd.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190327125819.16478-1-daniel.vetter@ffwll.ch
2019-03-27drm/uapi: Remove unused DRM_DISPLAY_INFO_LENVille Syrjälä
Remove the unused DRM_DISPLAY_INFO_LEN from the uapi headers. I presume the original plan was to expose the display name via getconnector, but looks like that never happened. So we have the define for the length of the string but no string anywhere. A quick scan didn't seem to reveal userspace referencing this so hopefully we can just nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-4-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-03-27drm: Kill drm_display_info.nameVille Syrjälä
drm_display_info.name is only ever set by a few panel drivers but never actually used anywhere except in i915 debugfs code. Trash it. v2: Fix typo in commit msg (Sam Ravnborg) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-3-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-03-27drm: Fix tabs vs. spacesVille Syrjälä
A set of 8 spaces has snuck in. Replace with a tab, and toss in an extra newline while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-03-27drm: Nuke unused drm_display_info.pixel_clockVille Syrjälä
drm_display_info.pixel_clock is unused. Let's get rid of it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-03-27drm/fb-helper: Unexport fill_{var,info}Daniel Vetter
Not used by drivers anymore. v2: Rebase Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-21-daniel.vetter@ffwll.ch
2019-03-27drm/fb-helper: Add fill_info() functionsDaniel Vetter
The fbdev split between fix and var information is kinda pointless for drm drivers since everything is fixed: The fbdev emulation doesn't support changing modes at all. Create a new simplified helper and use it in the generic fbdev helper code. Follow-up patches will beef it up more and roll it out to all drivers. v2: We need to keep sizes, since they might not match the fb dimensions (Noralf) v3: Fix typo in commit message and remove extraneous line in kerneldoc (Noralf) Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-1-daniel.vetter@ffwll.ch
2019-03-25drm/doc: fix missing verbLuca Ceresoli
Add a missing "be". While there, also fix the syntax for struct drm_device. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190313153537.22654-2-luca@lucaceresoli.net
2019-03-21drm/fourcc: Fix conflicting Y41x definitionsMaarten Lankhorst
There has unfortunately been a conflict with the following 3 commits: commit e9961ab95af81b8d29054361cd5f0c575102cf87 Author: Ayan Kumar Halder <ayan.halder@arm.com> Date: Fri Nov 9 17:21:12 2018 +0000 drm: Added a new format DRM_FORMAT_XVYU2101010 commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3 Author: Brian Starkey <brian.starkey@arm.com> Date: Fri Oct 5 10:27:00 2018 +0100 drm/fourcc: Add AFBC yuv fourccs for Mali and commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b Author: Swati Sharma <swati2.sharma@intel.com> Date: Mon Mar 4 17:26:33 2019 +0530 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc Unfortunately gcc didn't warn about the redefinitions, because the double defines were the set to same value, and gcc apparently no longer warns about that. Fix this by using new XYVU for i915, without alpha, and making the Y41x definitions match msdn, with alpha. Fortunately we caught it early, and the conflict hasn't even landed in drm-next yet. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: malidp@foss.arm.com Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Dave Airlie <airlied@linux.ie> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190319121702.6814-1-maarten.lankhorst@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc Acked-by: Sean Paul <sean@poorly.run> Reviewed-by: Ayan Kumar halder <ayan.halder@arm.com>
2019-03-20tinydrm/mipi-dbi: Use dma-safe buffers for all SPI transfersNoralf Trønnes
Buffers passed to spi_sync() must be dma-safe even for tiny buffers since some SPI controllers use DMA for all transfers. Example splat with CONFIG_DMA_API_DEBUG enabled: [ 23.750467] DMA-API: dw_dmac_pci 0000:00:15.0: device driver maps memory from stack [probable addr=000000001e49185d] [ 23.750529] WARNING: CPU: 1 PID: 1296 at kernel/dma/debug.c:1161 check_for_stack+0xb7/0x190 [ 23.750533] Modules linked in: mmc_block(+) spi_pxa2xx_platform(+) pwm_lpss_pci pwm_lpss spi_pxa2xx_pci sdhci_pci cqhci intel_mrfld_pwrbtn extcon_intel_mrfld sdhci intel_mrfld_adc led_class mmc_core ili9341 mipi_dbi tinydrm backlight ti_ads7950 industrialio_triggered_buffer kfifo_buf intel_soc_pmic_mrfld hci_uart btbcm [ 23.750599] CPU: 1 PID: 1296 Comm: modprobe Not tainted 5.0.0-rc7+ #236 [ 23.750605] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 23.750620] RIP: 0010:check_for_stack+0xb7/0x190 [ 23.750630] Code: 8b 6d 50 4d 85 ed 75 04 4c 8b 6d 10 48 89 ef e8 2f 8b 44 00 48 89 c6 4a 8d 0c 23 4c 89 ea 48 c7 c7 88 d0 82 b4 e8 40 7c f9 ff <0f> 0b 8b 05 79 00 4b 01 85 c0 74 07 5b 5d 41 5c 41 5d c3 8b 05 54 [ 23.750637] RSP: 0000:ffff97bbc0292fa0 EFLAGS: 00010286 [ 23.750646] RAX: 0000000000000000 RBX: ffff97bbc0290000 RCX: 0000000000000006 [ 23.750652] RDX: 0000000000000007 RSI: 0000000000000002 RDI: ffff94b33e115450 [ 23.750658] RBP: ffff94b33c8578b0 R08: 0000000000000002 R09: 00000000000201c0 [ 23.750664] R10: 00000006ecb0ccc6 R11: 0000000000034f38 R12: 000000000000316c [ 23.750670] R13: ffff94b33c84b250 R14: ffff94b33dedd5a0 R15: 0000000000000001 [ 23.750679] FS: 0000000000000000(0000) GS:ffff94b33e100000(0063) knlGS:00000000f7faf690 [ 23.750686] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 23.750691] CR2: 00000000f7f54faf CR3: 000000000722c000 CR4: 00000000001006e0 [ 23.750696] Call Trace: [ 23.750713] debug_dma_map_sg+0x100/0x340 [ 23.750727] ? dma_direct_map_sg+0x3b/0xb0 [ 23.750739] spi_map_buf+0x25a/0x300 [ 23.750751] __spi_pump_messages+0x2a4/0x680 [ 23.750762] __spi_sync+0x1dd/0x1f0 [ 23.750773] spi_sync+0x26/0x40 [ 23.750790] mipi_dbi_typec3_command_read+0x14d/0x240 [mipi_dbi] [ 23.750802] ? spi_finalize_current_transfer+0x10/0x10 [ 23.750821] mipi_dbi_typec3_command+0x1bc/0x1d0 [mipi_dbi] Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190222124329.23046-1-noralf@tronnes.org
2019-03-14drm: Add library for shmem backed GEM objectsNoralf Trønnes
This adds a library for shmem backed GEM objects. v8: - export drm_gem_shmem_create_with_handle - call mapping_set_gfp_mask to set default zone to GFP_HIGHUSER - Add helper drm_gem_shmem_get_pages_sgt() v7: - Use write-combine for mmap instead. This is the more common case. (robher) v6: - Fix uninitialized variable issue in an error path (anholt). - Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting of the pages (anholt). v5: - Drop drm_gem_shmem_prime_mmap() (Daniel Vetter) - drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real vma->vm_pgoff - drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct v4: - Drop cache modes (Thomas Hellstrom) - Add a GEM attached vtable v3: - Grammar (Sam Ravnborg) - s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/ (Sam Ravnborg) - Add debug output in error path (Sam Ravnborg) Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190313004344.24169-1-robh@kernel.org
2019-03-14drm: Add helpers for locking an array of BO reservations.Eric Anholt
Now that we have the reservation object in the GEM object, it's easy to provide a helper for this common case. Noticed while reviewing panfrost and lima drivers. This particular version came out of v3d, which in turn was a copy from vc4. v2: Fix kerneldoc warnings. Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190308161716.2466-2-eric@anholt.net Acked-by: Rob Herring <robh@kernel.org> (v1)
2019-03-13Merge tag 'topic/hdr-formats-2019-03-13' of ↵Sean Paul
git://anongit.freedesktop.org/drm/drm-misc into drm-misc-next Add support for floating point half-width formats. Signed-off-by: Sean Paul <seanpaul@chromium.org> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/00b96cd5-91c7-5677-9620-b138c7a92303@linux.intel.com
2019-03-13drm/fourcc: Add 64 bpp half float formatsKevin Strasser
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is formatted in IEEE-754 half-precision float (binary16) 1:5:10 MSb-sign:exponent:fraction form. This patch attempts to address the feedback provided when 2 of these formats were previosly proposed: https://patchwork.kernel.org/patch/10072545/ v2: - Fixed cpp (Ville) - Added detail pixel formatting (Ville) - Ordered formats in header (Ville) v5: - .depth should be 0 for new formats (Maarten) Cc: Tina Zhang <tina.zhang@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kevin Strasser <kevin.strasser@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-2-git-send-email-kevin.strasser@intel.com
2019-03-12drm: Added a new format DRM_FORMAT_XVYU2101010Ayan Kumar Halder
This new format is supported by DP550 and DP650 Changes since v3 (series): - Added the ack - Rebased on the latest drm-misc-next Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Link: https://patchwork.freedesktop.org/patch/291758/?series=57895&rev=1
2019-03-12drm/fourcc: Add AFBC yuv fourccs for MaliBrian Starkey
As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR8888 and RGBA8888 can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA8888 + MODIFIER_AFBC) is a different format from (RGBA8888 + MODIFIER_AFBC). Possibly more controversial is that (XBGR8888 + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane ---------------------- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane ----------------------- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane ---------------------- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by V). We can use YUYV for AFBC YUV 422 8-bit. YUV 422 10-bit, 1-plane ----------------------- There is no currently-defined YUV 422 10-bit format in drm_fourcc.h DRM_FORMAT_Y210 is analogous to YUYV, but with 10-bits per sample packed into the upper 10-bits of 16-bit samples. This format is supported in both linear and AFBC by Mali GPUs. YUV 422 10-bit, 2-plane ----------------------- The recently defined DRM_FORMAT_P010 format is a 10-bit semi-planar YUV 420 format, which has the correct component ordering for an AFBC 2-plane YUV 420 buffer. The linear layout contains meaningless padding bits, which will not be encoded in an AFBC stream. YUV 420 8-bit, 1-plane ---------------------- There is no currently defined single-planar YUV 420, 8-bit format in drm_fourcc.h. There's differing opinions on whether using the existing fourcc-implied n_planes where possible is a good idea or not when using modifiers. For me, it's much more "obvious" to use NV12 for 2-plane AFBC and YUV420 for 3-plane AFBC. This keeps the aforementioned separation between the AFBC codec settings (in the modifier) and the pixel data format (in the fourcc). With different vendors using AFBC, this helps to ensure that there is no confusion in interoperation. It also ensures that the AFBC modifiers describe AFBC itself (which is a licensable component), and not implementation details which are not defined by AFBC. The proposed[1] X0L0 format which Mali-DP supports with Linear layout is unsuitable, as it contains a 4th 'X' component, and our AFBC decoder expects only 3 components. To that end, we propose a new YUV 420 8-bit format. There is no "obvious" linear encoding for a 3-component 8:8:8, 420, packed format, and so DRM_FORMAT_YUV420_8BIT defines a component order, but not a bit encoding. I'm happy to hear different naming suggestions. YUV 420 8-bit, 2-, 3-plane -------------------------- These already exist, we can use NV12 and YUV420. YUV 420 10-bit, 1-plane ----------------------- As above, no current definition exists, and X0L2 encodes a 4th 'X' channel. Analogous to DRM_FORMAT_YUV420_8BIT, we define DRM_FORMAT_YUV420_10BIT. [1] https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html [2] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats Changes since RFC v1: - Fix confusing subsampling vs bit-depth X:X:X notation in descriptions (danvet) - Rename DRM_FORMAT_AVYU1101010 to DRM_FORMAT_Y410 (Lisa Wu) - Add drm_format_info structures for the new formats, using the new 'bpp' field for those with non-integer bytes-per-pixel - Rebase, including Juha-Pekka Heikkila's format definitions Changes since RFC v2: - Rebase on top of latest changes in drm-misc-next - Change the description of DRM_FORMAT_P210 in __drm_format_info and drm_fourcc.h so as to make it consistent with other DRM_FORMAT_PXXX formats. Changes since v3: - Added the ack - Rebased on the latest drm-misc-next Signed-off-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Link: https://patchwork.freedesktop.org/patch/291759/?series=57895&rev=1
2019-03-08Merge tag 'topic/hdr-formats-2019-03-07' of ↵Sean Paul
git://anongit.freedesktop.org/drm/drm-misc into drm-misc-next Add support for Y21x and Y41x to drm core and i915, and P01x support to i915. Signed-off-by: Sean Paul <seanpaul@chromium.org> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2485309-d645-bed4-95f4-e66ff312aa05@linux.intel.com
2019-03-07drm: export drm_timeout_abs_to_jiffiesQiang Yu
For other driver like lima usage. Cc: Rob Herring <robh@kernel.org> Signed-off-by: Qiang Yu <yuq825@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190225140717.20586-2-yuq825@gmail.com
2019-03-06Merge drm/drm-next into drm-misc-nextSean Paul
Picking up v5.0 + missed misc-fixes from last release Signed-off-by: Sean Paul <seanpaul@chromium.org>
2019-03-05drm/dsc: Split DSC PPS and SDP header initialisationsDavid Francis
The DP 1.4 spec defines the SDP header and SDP contents for a Picture Parameter Set (PPS) that must be sent in advance of DSC transmission to define the encoding characteristics. This was done in one struct, drm_dsc_pps_infoframe, which conatined the SDP header and PPS. Because the PPS is a property of DSC over any connector, not just DP, and because drm drivers may have their own SDP structs they wish to use, make the functions that initialise SDP and PPS headers take the components they operate on, not drm_dsc_pps_infoframe, Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221202001.28430-4-David.Francis@amd.com
2019-03-05drm/dsc: Add native 420 and 422 support to compute_rc_paramsDavid Francis
Native 420 and 422 transfer modes are new in DSC1.2 In these modes, each two pixels of a slice are treated as one pixel, so the slice width is half as large (round down) for the purposes of calucating the groups per line and chunk size in bytes In native 422 mode, each pixel has four components, so the mux component of a group is larger by one additional mux word and one additional component Now that there is native 422 support, the configuration option previously called enable422 is renamed to simple_422 to avoid confusion Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221202001.28430-3-David.Francis@amd.com
2019-03-05drm/i915: Move dsc rate params compute into drmDavid Francis
The function intel_compute_rc_parameters is part of the dsc spec and is not driver-specific. Other drm drivers might like to use it. The function is not changed; just moved and renamed. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221202001.28430-2-David.Francis@amd.com
2019-03-05drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourccSwati Sharma
The following pixel formats are packed format that follows 4:2:2 chroma sampling. For memory represenation each component is allocated 16 bits each. Thus each pixel occupies 32bit. Y210: For each component, valid data occupies MSB 10 bits. LSB 6 bits are filled with zeroes. Y212: For each component, valid data occupies MSB 12 bits. LSB 4 bits are filled with zeroes. Y216: For each component valid data occupies 16 bits, doesn't require any padding bits. First 16 bits stores the Y value and the next 16 bits stores one of the chroma samples alternatively. The first luma sample will be accompanied by first U sample and second luma sample is accompanied by the first V sample. The following pixel formats are packed format that follows 4:4:4 chroma sampling. Channels are arranged in the order UYVA in increasing memory order. Y410: Each color component occupies 10 bits and X component takes 2 bits, thus each pixel occupies 32 bits. Y412: Each color component is 16 bits where valid data occupies MSB 12 bits. LSB 4 bits are filled with zeroes. Thus, each pixel occupies 64 bits. Y416: Each color component occupies 16 bits for valid data, doesn't require any padding bits. Thus, each pixel occupies 64 bits. v3: fixed missing tab for XYUV8888 (JP) Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1551700595-21481-5-git-send-email-swati2.sharma@intel.com
2019-03-05Merge tag 'drm-misc-fixes-2019-02-22' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-fixes for v5.0: - Block fb changes for async atomic updates to prevent a use after free. - Fix ID mismatch error on load in bochs. - Fix memory leak when drm_setup fails. - Fixes around handling of DRM_AUTH. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/42113611-e2cd-6bdd-7de5-4f8ab5a0cbe6@linux.intel.com
2019-03-04drm/tinydrm: Remove tinydrm_deviceNoralf Trønnes
No more users left so it can go alongside its helpers. Update the tinydrm docs description and remove todo entry. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-7-noralf@tronnes.org
2019-03-04drm/tinydrm: Drop using tinydrm_deviceNoralf Trønnes
Use devm_drm_dev_init() and drop using tinydrm_device. v2: devm_drm_dev_register() was dropped so add driver release callbacks. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-6-noralf@tronnes.org
2019-03-04drm: Add devm_drm_dev_init()Noralf Trønnes
This adds a resource managed (devres) version of drm_dev_init(). v2: Remove devm_drm_dev_register() since we can't touch hw in devm release functions and drivers want to disable hw on driver module unload (Daniel Vetter, Greg KH) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-3-noralf@tronnes.org
2019-03-04Merge v5.0 into drm-nextDave Airlie
There is a really hairy resolution involving amdgpu fixes, that I'd rather confirm here. Also some misc fixes are landed by me, but the pr has them as well. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-03-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds
Pull networking fixes from David Miller: 1) Fix refcount leak in act_ipt during replace, from Davide Caratti. 2) Set task state properly in tun during blocking reads, from Timur Celik. 3) Leaked reference in DSA, from Wen Yang. 4) NULL deref in act_tunnel_key, from Vlad Buslov. 5) cipso_v4_erro can reference the skb IPCB in inappropriate contexts thus referencing garbage, from Nazarov Sergey. 6) Don't accept RTA_VIA and RTA_GATEWAY in contexts where those attributes make no sense. 7) Fix hung sendto in tipc, from Tung Nguyen. 8) Out-of-bounds access in netlabel, from Paul Moore. 9) Grant reference leak in xen-netback, from Igor Druzhinin. 10) Fix tx stalls with lan743x, from Bryan Whitehead. 11) Fix interrupt storm with mv88e6xxx, from Hein Kallweit. 12) Memory leak in sit on device registry failure, from Mao Wenan. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (44 commits) net: sit: fix memory leak in sit_init_net() net: dsa: mv88e6xxx: Fix statistics on mv88e6161 geneve: correctly handle ipv6.disable module parameter net: dsa: mv88e6xxx: prevent interrupt storm caused by mv88e6390x_port_set_cmode bpf: fix sanitation rewrite in case of non-pointers ipv4: Add ICMPv6 support when parse route ipproto MIPS: eBPF: Fix icache flush end address lan743x: Fix TX Stall Issue net: phy: phylink: fix uninitialized variable in phylink_get_mac_state net: aquantia: regression on cpus with high cores: set mode with 8 queues selftests: fixes for UDP GRO bpf: drop refcount if bpf_map_new_fd() fails in map_create() net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X net: dsa: mv88e6xxx: Fix u64 statistics xen-netback: don't populate the hash cache on XenBus disconnect xen-netback: fix occasional leak of grant ref mappings under memory pressure sctp: chunk.c: correct format string for size_t in printk net: netem: fix skb length BUG_ON in __skb_to_sgvec netlabel: fix out-of-bounds memory accesses ipv4: Pass original device to ip_rcv_finish_core ...
2019-03-01ipv4: Add ICMPv6 support when parse route ipprotoHangbin Liu
For ip rules, we need to use 'ipproto ipv6-icmp' to match ICMPv6 headers. But for ip -6 route, currently we only support tcp, udp and icmp. Add ICMPv6 support so we can match ipv6-icmp rules for route lookup. v2: As David Ahern and Sabrina Dubroca suggested, Add an argument to rtm_getroute_parse_ip_proto() to handle ICMP/ICMPv6 with different family. Reported-by: Jianlin Shi <jishi@redhat.com> Fixes: eacb9384a3fe ("ipv6: support sport, dport and ip_proto in RTM_GETROUTE") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-28drm/doc: Fix copy paste error in drm_crtc_funcs.destroy()Maarten Lankhorst
The function is about cleaning up CRTC resources, not plane resources, fix this in docbook. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-02-28Merge tag 'imx-drm-next-2019-02-22' of git://git.pengutronix.de/pza/linux ↵Dave Airlie
into drm-next drm/imx: handle pending updates better, add plane zpos property support - Add a mechanism to only send commit done events once all pending updates have been applied. This closes a small race window where already armed events could fire even though the double buffered hardware update just missed the update window. - Add plane zpos property support to allow placing the overlay plane behind the primary plane. - Allow building imx-drm on all platforms under COMPILE_TEST. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Philipp Zabel <pza@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190222112350.m3ucezilqx6cyest@pengutronix.de
2019-02-27dma-buf: clarify locking documentation for reservation_object_get_exclLucas Stach
The documentation was misleading, as for a lot of use-cases holding the RCU read side lock is sufficient. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111165302.25556-2-l.stach@pengutronix.de
2019-02-27net: dev: Use unsigned integer as an argument to left-shiftAndy Shevchenko
1 << 31 is Undefined Behaviour according to the C standard. Use U type modifier to avoid theoretical overflow. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-25net: avoid use IPCB in cipso_v4_errorNazarov Sergey
Extract IP options in cipso_v4_error and use __icmp_send. Signed-off-by: Sergey Nazarov <s-nazarov@yandex.ru> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-28 08:48:06 +0000