Daniel Vetter [Tue, 24 Mar 2020 20:39:36 +0000 (21:39 +0100)]
drm: manage drm_minor cleanup with drmm_
The cleanup here is somewhat tricky, since we can't tell apart the
allocated minor index from 0. So register a cleanup action first, and
if the index allocation fails, unregister that cleanup action again to
avoid bad mistakes.
The kdev for the minor already handles NULL, so no problem there.
Hence add drmm_remove_action() to the drm_managed library.
v2: Make pointer math around void ** consistent with what Laurent
suggested.
v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
because of some questions from Thomas. This also means we need to move
the drmm_add_action_or_reset helper earlier in the series.
v4: Uh ... fix slightly embarrassing bug CI spotted.
Daniel Vetter [Mon, 23 Mar 2020 14:49:20 +0000 (15:49 +0100)]
drm: Use drmm_ for drm_dev_init cleanup
Well for the simple stuff at least, vblank, gem and minor cleanup I
want to further split up as a demonstration.
v2: We need to clear drm_device->dev otherwise the debug drm printing
after our cleanup hook (e.g. in drm_manged_release) will chase
released memory and result in a use-after-free. Not really pretty, but
oh well.
Daniel Vetter [Mon, 23 Mar 2020 14:49:18 +0000 (15:49 +0100)]
drm: Cleanups after drmm_add_final_kfree rollout
A few things:
- Update the example driver in the documentation.
- We can drop the old kfree in drm_dev_release.
- Add a WARN_ON check in drm_dev_register to make sure everyone calls
drmm_add_final_kfree and there's no leaks.
v2: Restore the full cleanup, I accidentally left some moved code
behind when fixing the bisectability of the series.
Daniel Vetter [Mon, 23 Mar 2020 14:49:12 +0000 (15:49 +0100)]
drm/vgem: Use drmm_add_final_kfree
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@chromium.org> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-14-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 23 Mar 2020 14:49:09 +0000 (15:49 +0100)]
drm/v3d: Use drmm_add_final_kfree
With this we can drop the final kfree from the release function.
I also noticed that the unwind code is wrong, after drm_dev_init the
drm_device owns the v3d allocation, so the kfree(v3d) is a double-free.
Reorder the setup to fix this issue.
After a bit more prep in drivers and drm core v3d should be able to
switch over to devm_drm_dev_init, which should clean this up further.
Daniel Vetter [Mon, 23 Mar 2020 14:49:07 +0000 (15:49 +0100)]
drm/i915: Use drmm_add_final_kfree
With this we can drop the final kfree from the release function.
The mock device in the selftests needed it's pci_device split
up from the drm_device. In the future we could simplify this again
by allocating the pci_device as a managed allocation too.
v2: I overlooked that i915_driver_destroy is also called in the
unwind code of the error path. There we need a drm_dev_put.
Similar for the mock object.
Now the problem with that is that the drm_driver->release callbacks
for both the real driver and the mock one assume everything has been
set up. Hence going through that path for a partially set up driver
will result in issues. Quickest fix is to disable the ->release() hook
until the driver is fully initialized, and keep the onion unwinding.
Long term would be cleanest to move everything over to drmm_ release
actions, but that's a lot of work for a big driver like i915. Plus
more core work needed first anyway.
v3: Fix i915_drm pointer wrangling in mock_gem_device. Also switch
over to start using drm_dev_put() to clean up even on the error path.
Aside I think the current error path is leaking the allocation.
v4: more fixes for intel-gfx-ci, some if it damage from v3 :-/
Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-9-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 23 Mar 2020 14:49:05 +0000 (15:49 +0100)]
drm/udl: Use drmm_add_final_kfree
With this we can drop the final kfree from the release function.
v2: We need drm_dev_put to unroll the driver creation (once
drm_dev_init and drmm_add_final_kfree suceeded), otherwise
the drmm_ magic doesn't happen.
v3: Actually squash in the fixup (Laurent).
Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-7-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 23 Mar 2020 14:49:04 +0000 (15:49 +0100)]
drm/mipi_dbi: Use drmm_add_final_kfree in all drivers
They all share mipi_dbi_release so we need to switch them all
together. With this we can drop the final kfree from the release
function.
Aside, I think we could perhaps have a tiny additional helper for
these mipi_dbi drivers, the first few lines around devm_drm_dev_init
are all the same (except for the drm_driver pointer).
Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Noralf Trønnes <noralf@tronnes.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-6-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 24 Mar 2020 12:45:40 +0000 (13:45 +0100)]
drm: add managed resources tied to drm_device
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after a hotunplug while userspace has open
files and mmap'ed buffers). Give people what they want, but with more
correctness.
Mostly copied from devres.c, with types adjusted to fit drm_device and
a few simplifications - I didn't (yet) copy over everything. Since
the types don't match code sharing looked like a hopeless endeavour.
For now it's only super simplified, no groups, you can't remove
actions (but kfree exists, we'll need that soon). Plus all specific to
drm_device ofc, including the logging. Which I didn't bother to make
compile-time optional, since none of the other drm logging is compile
time optional either.
One tricky bit here is the chicken&egg between allocating your
drm_device structure and initiliazing it with drm_dev_init. For
perfect onion unwinding we'd need to have the action to kfree the
allocation registered before drm_dev_init registers any of its own
release handlers. But drm_dev_init doesn't know where exactly the
drm_device is emebedded into the overall structure, and by the time it
returns it'll all be too late. And forcing drivers to be able clean up
everything except the one kzalloc is silly.
Work around this by having a very special final_kfree pointer. This
also avoids troubles with the list head possibly disappearing from
underneath us when we release all resources attached to the
drm_device.
v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless
shuffling while getting everything into shape.
v3: Add static to add/del_dr (Neil)
Move typo fix to the right patch (Neil)
v4: Enforce contract for drmm_add_final_kfree:
Use ksize() to check that the drm_device is indeed contained somewhere
in the final kfree(). Because we need that or the entire managed
release logic blows up in a pile of use-after-frees. Motivated by a
discussion with Laurent.
v5: Review from Laurent:
- %zu instead of casting size_t
- header guards
- sorting of includes
- guarding of data assignment if we didn't allocate it for a NULL
pointer
- delete spurious newline
- cast void* data parameter correctly in ->release call, no idea how
this even worked before
v6: Review from Sam
- Add the kerneldoc for the managed sub-struct back in, even if it
doesn't show up in the generated html somehow.
- Explain why __always_inline.
- Fix bisectability around the final kfree() in drm_dev_relase(). This
is just interim code which will disappear again.
- Some whitespace polish.
- Add debug output when drmm_add_action or drmm_kmalloc fail.
v7: My bisectability fix wasn't up to par as noticed by smatch.
v8: Remove unecessary {} around if else
v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr()
helper (Thomas).
v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow
we need to wrap that in kstrdup_const() too!! Also renumber revision
log, I somehow reset it midway thruh.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Neil Armstrong <narmstrong@baylibre.com Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 23 Mar 2020 14:49:01 +0000 (15:49 +0100)]
drm/i915: Don't clear drvdata in ->release
For two reasons:
- The driver core clears this already for us after we're unloaded in
__device_release_driver().
- It's way too late, the drm_device ->release callback might massively
outlive the underlying physical device, since a drm_device can be
kept alive by open drm_file or well really anything else userspace
is still hanging onto. So if we clear this ourselves, we should
clear it in the pci ->remove callback, not in the drm_device
->release callback.
Looking at git history this was fixed in the driver core with
Daniel Vetter [Mon, 23 Mar 2020 14:49:00 +0000 (15:49 +0100)]
mm/sl[uo]b: export __kmalloc_track(_node)_caller
slab does this already, and I want to use this in a memory allocation
tracker in drm for stuff that's tied to the lifetime of a drm_device,
not the underlying struct device. Kinda like devres, but for drm.
Acked-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-2-daniel.vetter@ffwll.ch
Dave Airlie [Wed, 25 Mar 2020 05:45:39 +0000 (15:45 +1000)]
Merge branch 'feature/staging_sm5' of git://people.freedesktop.org/~sroland/linux into drm-next
vmwgfx pull for for 5.7. Needed for GL4 functionality.
Sync up device headers, add support for new commands, code
refactoring around surface definition.
Dave Airlie [Wed, 25 Mar 2020 05:40:03 +0000 (15:40 +1000)]
Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next
- fix for potential out-of-bounds reads in the perfmon ioctl
implementation from Christian
- override to expose proper feature flags for the GC400 found on the
STM32MP1 SoC, also from Christian
- Guido fixed an issue where we would spuriously fail to enter
runtime suspend due to a new GPU engine status bit on GC7000
- tree-wide change from Gustavo to get rid of zero-length arrays
- fix for missed TS cache flush on GC7000, leading to spurious
MMU faults from me
- request pages from DMA32 zone on systems where we can't address
all present memory from me
Jernej Skrabec [Wed, 4 Mar 2020 23:25:12 +0000 (00:25 +0100)]
drm/bridge: dw-hdmi: rework csc related functions
is_color_space_conversion() is a misnomer. It checks not only if color
space conversion is needed, but also if format conversion is needed.
This is actually desired behaviour because result of this function
determines if CSC block should be enabled or not (CSC block can also do
format conversion).
In order to clear misunderstandings, let's rework
is_color_space_conversion() to do exactly what is supposed to do and add
another function which will determine if CSC block must be enabled or
not.
Jernej Skrabec [Wed, 4 Mar 2020 23:25:11 +0000 (00:25 +0100)]
drm/bridge: dw-hdmi: Add support for RGB limited range
CEA 861 standard requestis that RGB quantization range is "limited" for
CEA modes. Support that by adding CSC matrix which downscales values.
This allows proper color reproduction on TV and PC monitor at the same
time. In future, override property can be added, like "Broadcast RGB"
in i915 driver.
Jonas Karlman [Wed, 4 Mar 2020 23:25:10 +0000 (00:25 +0100)]
drm/bridge: dw-hdmi: do not force "none" scan mode
Setting scan mode to "none" confuses some TVs like LG B8, which randomly
change overscan percentage over time. Digital outputs like HDMI and DVI,
handled by this controller, don't really need overscan, so we can always
set scan mode to underscan. Actually, this is exactly what
drm_hdmi_avi_infoframe_from_display_mode() already does, so we can just
remove offending line.
Jernej Skrabec [Mon, 24 Feb 2020 17:39:00 +0000 (18:39 +0100)]
drm/sun4i: de2: Don't return de2_fmt_info struct
Now that de2_fmt_info contains only DRM <-> HW format mapping, it
doesn't make sense to return pointer to structure when searching by DRM
format. Rework that to return only HW format instead.
drm/vmwgfx: Use vmwgfx version 2.18 to signal SM5 compatibility
Signed-off-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
___
v2: Use 2.18 instead of 2.17
Surface define v4 added new member buffer_byte_stride. With this patch
add buffer_byte_stride in surface metadata and create surface using new
command if support is available.
Also with this patch replace device specific data types with kernel
types.
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata
Makes surface_define cleaner by sending vmw_surface_metadata instead of
all the arguments individually.
v2: fix uninitialized return value, error message
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
drm/vmwgfx: Split surface metadata from struct vmw_surface
Create a new structure vmw_surface_metadata representing the metadata
used for creating surface. With this can make the surface_define_priv
a bit cleaner.
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Deepak Rawat [Thu, 13 Dec 2018 22:04:31 +0000 (14:04 -0800)]
drm/vmwgfx: Add support for streamoutput with mob commands
With SM5 capability a new version of streamoutput is supported by device
which need backing mob and a new field. With this change the new command
is supported in command buffer.
v2: Also track streamoutput context binding in binding manager.
v3: Track only one streamoutput as only one can be set to context.
v4: Fix comment typos
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Signed-off-by: Neha Bhende <bhenden@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Previous name vmw_ctx_bindinfo_so is misleading because it actually
represent so target and stream output is a new resource type that needs
tracking for SM5 capable device. Also rename binding type enum and
internal functions to reflect these belongs to so targets.
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Deepak Rawat [Thu, 13 Dec 2018 21:51:08 +0000 (13:51 -0800)]
drm/vmwgfx: Add support for UA view commands
Virtual device now support new commands to manage unordered access
views. Allow them as part of user-space command buffer. This involves
adding UA view cotable, binding tracker info, new view type and command
verifier functions.
Deepak Rawat [Thu, 13 Dec 2018 21:43:20 +0000 (13:43 -0800)]
drm/vmwgfx: Support SM5 shader type in command buffer
Virtual device now supports new shader types, allow them as valid shader
type in command buffer. Also add per shader bind info in binding manager
state for new shader type.
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
In favor of SM4.1 multisampling capability, virtual device deprecated
old multisampling device capability. Mark legacy multisampling device
capability as dead. Rename the function that masks legacy multisample
capability to reflect that now it is masking a deprecated feature.
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Deepak Rawat [Thu, 13 Dec 2018 19:36:31 +0000 (11:36 -0800)]
drm/vmwgfx: Also check for SVGA_CAP_DX before reading DX context support
Virtual device consider SVGA_CAP_DX and SVGA3D_DEVCAP_DXCONTEXT
independent of each other. Some of the commands in cmd_buf depends on
SVGA_CAP_DX, so better to check for that as well.
Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Remove unneeded #if/#endif guards for checking whether the
CONFIG_DEBUG_FS option is set or not. If the option is not set, the
compiler optimizes the functions making the guards
unnecessary.
Lucas Stach [Wed, 26 Feb 2020 15:27:08 +0000 (16:27 +0100)]
drm/etnaviv: fix TS cache flushing on GPUs with BLT engine
As seen in the Vivante kernel driver, most GPUs with the BLT engine have
a broken TS cache flush. The workaround is to temporarily set the BLT
command to CLEAR_IMAGE, without actually executing the clear. Apparently
this state change is enough to trigger the required TS cache flush. As
the BLT engine is completely asychronous, we also need a few more stall
states to synchronize the flush with the frontend.
Root-caused-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Lucas Stach [Thu, 27 Feb 2020 11:09:25 +0000 (12:09 +0100)]
drm/etnaviv: request pages from DMA32 zone when needed
Some Vivante GPUs are found in systems that have interconnects restricted
to 32 address bits, but may have system memory mapped above the 4GB mark.
As this region isn't accessible to the GPU via DMA any GPU memory allocated
in the upper part needs to go through SWIOTLB bounce buffering. This kills
performance if it happens too often, as well as overrunning the available
bounce buffer space, as the GPU buffer may stay mapped for a long time.
Avoid bounce buffering by checking the addressing restrictions. If the
GPU is unable to access memory above the 4GB mark, request our SHM buffers
to be located in the DMA32 zone.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Randy Dunlap [Sun, 15 Mar 2020 04:10:02 +0000 (21:10 -0700)]
fbdev: via: fix -Wextra build warning and format warning
When 'VIAFB_DEBUG' and 'VIAFB_WARN' are not defined, modify the
DEBUG_MSG() &WARN_MSG() macros to use the no_printk() macro instead of
using <empty>.
This fixes a build warning when -Wextra is used and provides
printk format checking:
../drivers/video/fbdev/via/ioctl.c:88:47: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
Also use %lu to print an unsigned long instead of just %l, to fix
a printk format warning:
../drivers/video/fbdev/via/viafbdev.c: In function ‘viafb_dvp0_proc_write’:
../drivers/video/fbdev/via/viafbdev.c:1148:14: warning: unknown conversion type character ‘]’ in format [-Wformat=]
DEBUG_MSG("DVP0:reg_val[%l]=:%x\n", i,
Randy Dunlap [Sun, 15 Mar 2020 04:10:01 +0000 (21:10 -0700)]
fbdev: pm[23]fb.c: fix -Wextra build warnings and errors
When 'DEBUG' is not defined, modify the DPRINTK() macro to use the
no_printk() macro instead of using <empty>.
This fixes build warnings when -Wextra is used and provides
printk format checking:
../drivers/video/fbdev/pm2fb.c:227:38: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../drivers/video/fbdev/pm3fb.c:1039:33: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
Also drop one argument in two DPRINTK() macro uses to provide the
correct number of arguments and use the correct field in one case
to fix a build error:
../drivers/video/fbdev/pm3fb.c:353:9: error: ‘struct fb_info’ has no member named ‘current_par’
info->current_par->depth);
Randy Dunlap [Sun, 15 Mar 2020 04:10:00 +0000 (21:10 -0700)]
fbdev: savage: fix -Wextra build warning
When 'SAVAGEFB_DEBUG' is not defined, modify the DBG() macro to use the
no_printk() macro instead of using <empty>.
This fixes a build warning when -Wextra is used and provides
printk format checking:
../drivers/video/fbdev/savage/savagefb_driver.c:2411:13: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
Randy Dunlap [Sun, 15 Mar 2020 04:09:59 +0000 (21:09 -0700)]
fbdev: matrox: fix -Wextra build warnings
When 'DEBUG' is not defined, modify the dprintk() macro to use the
no_printk() macro instead of using <empty>.
This fixes build warnings when -Wextra is used and provides
printk format checking:
../drivers/video/fbdev/matrox/matroxfb_base.c:635:77: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../drivers/video/fbdev/matrox/matroxfb_Ti3026.c:632:54: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
../drivers/video/fbdev/matrox/matroxfb_Ti3026.c:654:53: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
Randy Dunlap [Sun, 15 Mar 2020 04:09:58 +0000 (21:09 -0700)]
fbdev: aty: fix -Wextra build warning
When 'DEBUG' is not defined, modify the DPRINTK() macro to use the
no_printk() macro instead of using <empty>.
This fixes a build warning when -Wextra is used and provides
printk format checking:
../drivers/video/fbdev/aty/atyfb_base.c:784:61: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
Randy Dunlap [Sun, 15 Mar 2020 04:09:57 +0000 (21:09 -0700)]
fbdev: fbmon: fix -Wextra build warnings
When 'DEBUG' is not defined, modify the DPRINTK() macro to use the
no_printk() macro instead of using <empty>.
This fixes a build warning when -Wextra is used and provides
printk format checking:
../drivers/video/fbdev/core/fbmon.c:812:47: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../drivers/video/fbdev/core/fbmon.c:842:24: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
../drivers/video/fbdev/core/fbmon.c:847:24: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
Takashi Iwai [Wed, 11 Mar 2020 09:32:30 +0000 (10:32 +0100)]
video: uvesafb: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Takashi Iwai [Wed, 11 Mar 2020 09:32:29 +0000 (10:32 +0100)]
video: omap2: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Takashi Iwai [Wed, 11 Mar 2020 09:32:28 +0000 (10:32 +0100)]
video: omapfb: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Jiri Slaby [Thu, 19 Mar 2020 10:04:21 +0000 (11:04 +0100)]
drm/virtio: fix OOB in virtio_gpu_object_create
After commit f651c8b05542 ("drm/virtio: factor out the sg_table from
virtio_gpu_object"), virtio_gpu_create_object allocates too small space
to fit everything in. It is because it allocates struct
virtio_gpu_object, but should allocate a newly added struct
virtio_gpu_object_shmem which has 2 more members.
So fix that by using correct type in virtio_gpu_create_object.
Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: http://patchwork.freedesktop.org/patch/msgid/20200319100421.16267-1-jslaby@suse.cz Fixes: f651c8b05542 ("drm/virtio: factor out the sg_table from virtio_gpu_object") Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
drm/amdgpu: Remove unnecessary variable shadow in gfx_v9_0_rlcg_wreg
clang warns:
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:6: warning: variable 'shadow'
is used uninitialized whenever 'if' condition is
false [-Wsometimes-uninitialized]
if (offset == grbm_cntl || offset == grbm_idx)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:757:6: note: uninitialized use
occurs here
if (shadow) {
^~~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:2: note: remove the 'if' if
its condition is always true
if (offset == grbm_cntl || offset == grbm_idx)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:738:13: note: initialize the
variable 'shadow' to silence this warning
bool shadow;
^
= 0
1 warning generated.
shadow is only assigned in one condition and used as the condition for
another if statement; combine the two if statements and remove shadow
to make the code cleaner and resolve this warning.
Fixes: 2e0cc4d48b91 ("drm/amdgpu: revise RLCG access path") Link: https://github.com/ClangBuiltLinux/linux/issues/936 Suggested-by: Joe Perches <joe@perches.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Zhigang Luo [Wed, 26 Feb 2020 15:30:13 +0000 (10:30 -0500)]
drm/amdgpu: add CAP fw loading
The CAP fw is for enabling driver compatibility. Currently, it only
enabled for vega10 VF.
Signed-off-by: Zhigang Luo <zhigang.luo@amd.com> Reviewed-by: Shaoyun Liu <Shaoyun.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
John Clements [Wed, 18 Mar 2020 16:22:32 +0000 (00:22 +0800)]
amd/powerplay: arcturus baco reset disable all features
issue smu cmd to disable all features upon baco entry for arcturus
to mitigate potential dirty I2C controller on boot
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yintian Tao [Mon, 16 Mar 2020 07:45:58 +0000 (15:45 +0800)]
drm/amdgpu: miss PRT case when bo update
Originally, only the PTE valid is taken in consider.
The PRT case is missied when bo update which raise problem.
We need add condition for PRT case.
v2: add PRT condition for amdgpu_vm_bo_update_mapping, too
v3: fix one typo error
Signed-off-by: Yintian Tao <yttao@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wyatt Wood [Thu, 5 Mar 2020 20:14:01 +0000 (15:14 -0500)]
drm/amd/display: Allocate scratch space for DMUB CW7
[Why]
The scratch space can be used to pass data between x86 and DMCUB. DMCUB
will manage the actually mapping of CW7 internally, driver does not
program the window.
[How]
Allocate extra space within the DMUB service's framebuffer for this
scratch space and expose them from the service for use in DC.
Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yongqiang Sun [Thu, 5 Mar 2020 18:47:26 +0000 (13:47 -0500)]
drm/amd/display: DPP DTO isn't update properly.
[Why]
before update dpp DTO, we check dppclks in context to determine it is
changed or not, but dppclks in context will be updated anyways after
flip is done, so compare dppclks in context will always get an equal
result.
[How]
Add pipe dpp clks in dccg and compare values between dccg and context.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yongqiang Sun [Thu, 5 Mar 2020 18:41:43 +0000 (13:41 -0500)]
drm/amd/display: combine watermark change and clock change for update clocks.
[Why]
underflow happened when playing video on 1366x768 + 4K clone mode due to
incorrect handle watermark change flag and lower down clocks to early.
[How]
Check watermark change flag when decide doing optimized, and check
optimized required flag to do clock update.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Sung Lee [Thu, 30 Jan 2020 16:54:52 +0000 (11:54 -0500)]
drm/amd/display: Program self refresh control register on boot
[WHY]
In headless boot cases, self refresh control registers are not
programmed on boot. In certain hybrid graphics cases this may cause
cstate entering to get blocked causing a hang.
[HOW]
Program self refresh control register on boot.
Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wenjing Liu [Fri, 28 Feb 2020 17:16:07 +0000 (12:16 -0500)]
drm/amd/display: remove magic numbers in hdcp_ddc
[why]
DP doesn't have message id as the first byte of an hdcp message,
current hdcp psp unifies HDMI and DP message so that it is required
when reading DP HDCP messages in hdcp_ddc, a message id needs to be
added as the first byte of the HDCP message.
The id is currently assigned as a magic number which is not a good
coding practice.
[how]
Replace magic numbers with macro defined in hdcp headers.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Roman Li [Fri, 28 Feb 2020 21:31:29 +0000 (16:31 -0500)]
drm/amd/display: Remove PSR dependency on swizzle mode
[Why]
The PSR enablement was dependent on swizzle as a workaround for
non-pageflipping fb console. It's no longer required.
[How]
Remove PSR-enable dependency on swizzle mode.
Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Pass triplebuffer surface flip flags down to plane state
[Why]
A "dcn20_program_front_end_for_ctx" warning is observed on Renoir.
Since the resource definition doesn't explicitly disable triplebuffer
flips like Navi10 DC actually attempts to go and setup triplebuffering
even when we pass in false to the plane state.
If we hit a full update after triplebuffering has been setup we see the
assertion since we don't expect full updates while performing
triplebuffer flips.
Normally this would get reset back to false whne we pass in the new
plane state, but since we never actually copy the flag when doing
surface updates this doesn't happen.
[How]
Copy the flag onto the plane update based on the requested surface
update state.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yongqiang Sun [Thu, 27 Feb 2020 20:36:00 +0000 (15:36 -0500)]
drm/amd/display: workaround for HDMI hotplug in DPMSOFF state
[Why]
When hotplug a HDMI monitor during entering S0i3 or DPMSOFF state due to
entering infinite loop when calling vbios to program pixel clocks. In
this scenario, pll is enabled but phy is not, and there is not a
programing guide for this case.
[How]
Before we having the proper programing guide, before disable pll, doing
a phy enable and disable to avoid the issue.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Isabel Zhang [Thu, 27 Feb 2020 16:19:13 +0000 (11:19 -0500)]
drm/amd/display: Remove redundant hdcp display state
[Why]
Due to previous code changes displays which are in active state
immediately transition to the active and added state. This makes the two
states redundant and unnecessary.
[How]
Instead of updating the device state to active and added after
successful addition, change state to inactive if addition failed. Also,
change references to active and added state to just added state.
Signed-off-by: Isabel Zhang <isabel.zhang@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Fix test pattern color space inconsistency for Linux
[why]
When reprogram MSA with updated color space, the test color space shows
inconsistency. Linux has separate routine to set up test pattern color
space, but it fails to configure RGB.
[How]
Add RGB to test pattern.
Fixes: 43563bc2e6a769 ("drm/amd/display: update MSA and VSC SDP on video test pattern request") Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Hersen Wu [Thu, 13 Feb 2020 17:44:35 +0000 (12:44 -0500)]
drm/amd/display: update connector->display_info after read edid
[Why]
drm_connector->display_info is not passed to amdgpu_dm right way after
read edid.
[How]
display_info is parsed from edid and saved into drm_connector by
drm_connector_update_edid_proerty which is called within
amdgpu_dm_update_connector_after_detect. call this function after read
edid to update drm_connector->display_info