- 30 Jul, 2021 3 commits
-
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
An early pull for v5.15 (there'll be more coming in a week or two), consisting of the drm/scheduler conversion and a couple other small series that one was based one. Mostly sending this now because IIUC danvet wanted it in drm-next so he could rebase on it. (Daniel, if you disagree then speak up, and I'll instead include this in the main pull request once that is ready.) This also has a core patch to drop drm_gem_object_put_locked() now that the last use of it is removed. [airlied: add NULL to drm_sched_init] Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGumRk7H88bqV=H9Fb1SM0zPBo5B7NsCU3jFFKBYxf5k+Q@mail.gmail.com
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v5.15: UAPI Changes: - Add modifiers for arm fixed rate compression. Cross-subsystem Changes: - Assorted dt binding fixes. - Convert ssd1307fb to json-schema. - Update a lot of irc channels to point to OFTC, as everyone moved there. - Fix the same divide by zero for asilantfb, kyro, rivafb. Core Changes: - Document requirements for new atomic properties. - Add drm_gem_fb_(begin/end)_cpu_access helpers, and use them in some drivers. - Document drm_property_enum.value for bitfields. - Add explicit _NO_ for MIPI_DSI flags that disable features. - Assorted documentation fixes. - Update fb_damage handling, and move drm_plane_enable_fb_damage_clips to core. - Add logging and docs to RMFB ioctl. - Assorted small fixes to dp_mst, master handling. - Clarify drm lease usage. Driver Changes: - Assorted small fixes to panfrost, hibmc, bridge/nwl-dsi, rockchip, vc4. - More drm -> linux irq conversions. - Add support for some Logic Technologies and Multi-Inno panels. - Expose phy-functionality for drm/rockchip, to allow controlling from the media subsystem. - Add support for 2 AUO panels. - Add damage handling to ssd1307fb. - Improve FIFO handling on mxsfb. - Assorted small fixes to vmwgfx, and bump version to 2.19 for the new ioctls. - Improve sony acx424akp backlight handling. Signed-off-by:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
- R-Car DU shutdown fixes - R-Car DU conversion to bridge connector helper - Misc small fixes Signed-off-by:
-
- 29 Jul, 2021 3 commits
-
-
Maxime Ripard authored
Commit 91e99e11 ("drm/vc4: hdmi: Register HDMI codec") removed the references to the vc4_hdmi_audio_component_drv structure, but not the structure itself resulting in a warning. Remove it. Fixes: 91e99e11 ("drm/vc4: hdmi: Register HDMI codec") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707093632.1468127-2-maxime@cerno.tech
-
Maxime Ripard authored
The vc4_hdmi_audio_prepare function and the functions it's calling have in several occurences multiple dereferences of either the sample rate or the number of channels. It turns out that these variables are also passed through the hdmi codec parameters structure. Convert all the users to use this structure, and if it's used multiple times use a variable to store it instead of dereferencing it every time. Reviewed-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by:
-
Desmond Cheong Zhi Xi authored
We make the following changes to the documentation of drm leases to make it easier to reason about their usage. In particular, we clarify the lifetime and locking rules of lease fields in drm_master: 1. Make it clear that &drm_device.mode_config.idr_mutex protects the lease idr and list structures for drm_master. The lessor field itself doesn't need to be protected as it doesn't change after it's set in drm_lease_create. 2. Add descriptions for the lifetime of lessors and leases. 3. Add an overview DOC: section in drm-uapi.rst that defines the terminology for drm leasing, and explains how leases work and why they're used. Signed-off-by:
Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 28 Jul, 2021 34 commits
-
-
Linus Walleij authored
This converts the internal backlight in the Sony ACX424AKP driver to do it the canonical way: - Assign the panel->backlight during probe. - Let the panel framework handle the backlight. - Make the backlight .set_brightness() turn the backlight off completely if blank. - Fix some dev_err_probe() use cases along the way. Tested on the U8500 HREF520 reference design. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210715092808.1100106-1-linus.walleij@linaro.org
-
Desmond Cheong Zhi Xi authored
Inside drm_is_current_master, using the outer drm_device.master_mutex to protect reads of drm_file.master makes the function prone to creating lock hierarchy inversions. Instead, we can use the drm_file.master_lookup_lock that sits at the bottom of the lock hierarchy. Reported-by:
-
Zack Rusin authored
To let the userspace recognize that it's running on top of a vmwgfx that supports mks-stat ioctls we need to bump the version number. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Neha Bhende <bhenden@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-4-zackr@vmware.com
-
Zack Rusin authored
The code was trying to keep a strict limit on the amount of mob memory that was used in the guest by making it match the host settings. There's technically no reason to do that (guests can certainly use more than the host can have resident in renderers at the same time). In particular this is problematic because our userspace is not great at handling OOM conditions and running out of MOB space results in GL apps crashing, e.g. gnome-shell likes to allocate huge surfaces (~61MB for the desktop on 2560x1600 with two workspaces) and running out of memory there means that the gnome-shell crashes on startup taking us back to the login and resulting in a system where one can not login in graphically anymore. Instead of letting the userspace crash we can extend available MOB space, we just don't want to use all of the RAM for graphics, so we're going to limit it to half of RAM. With the addition of some extra logging this should make the "guest has been configured with not enough graphics memory" errors a lot easier to diagnose in cases where the automatic expansion of MOB space fails. Signed-off-by:
-
Zack Rusin authored
The code was using the old DRM logging functions, which made it hard to figure out what was coming from vmwgfx. The newer logging helpers include the driver name in the logs and make it explicit which driver they're coming from. This allows us to standardize our logging a bit and clean it up in the process. vmwgfx is a little special because technically the hardware it's running on can be anything from the last 12 years or so which is why we need to include capabilities in the logs in the first place or otherwise we'd have no way of knowing what were the capabilities of the platform the guest was running in. Signed-off-by:
-
Zack Rusin authored
The macro has been accounting for DRM_COMMAND_BASE for a long time now so there's no reason to still be duplicating it. Plus we were leaving the name undefined which meant that all the DRM ioctl warnings/errors were always listing "null" ioctl at the culprit. This fixes the undefined ioctl name and removes duplicated code. Signed-off-by:
-
Rob Clark authored
Mark all the bos in the submit as active, before pinning, to prevent evicting a buffer in the same submit to make room for a buffer earlier in the table. Signed-off-by:
Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20210728010632.2633470-14-robdclark@gmail.comSigned-off-by:
-
Rob Clark authored
The drm/scheduler provides additional prioritization on top of that provided by however many number of ringbuffers (each with their own priority level) is supported on a given generation. Expose the additional levels of priority to userspace and map the userspace priority back to ring (first level of priority) and schedular priority (additional priority levels within the ring). Signed-off-by:
Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210728010632.2633470-13-robdclark@gmail.comSigned-off-by:
-
Rob Clark authored
It is sufficient to serialize on the submit queue now. Signed-off-by:
-
Rob Clark authored
This was only used to detect userspace including the same bo multiple times in a submit. But ww_mutex can already tell us this. When we drop struct_mutex around the submit ioctl, we'd otherwise need to lock the bo before adding it to the bo_list. But since ww_mutex can already tell us this, it is simpler just to remove the bo_list. Signed-off-by:
-
Rob Clark authored
For existing adrenos, there is one or more ringbuffer, depending on whether preemption is supported. When preemption is supported, each ringbuffer has it's own priority. A submitqueue (which maps to a gl context or vk queue in userspace) is mapped to a specific ring- buffer at creation time, based on the submitqueue's priority. Each ringbuffer has it's own drm_gpu_scheduler. Each submitqueue maps to a drm_sched_entity. And each submit maps to a drm_sched_job. Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/4Signed-off-by:
-
Laurent Pinchart authored
Simplify error handling by using the dev_err_probe() function. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The drm_bridge.driver_private field is set but never used. Don't set it. Signed-off-by:
-
Laurent Pinchart authored
Use the drm_bridge_connector_init() helper to create a drm_connector for each output, instead of relying on the bridge drivers doing so. Attach the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct them not to create a connector. Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by:
-
Laurent Pinchart authored
Report the DT output port number in dw_hdmi_plat_data to connect to the next bridge in the dw-hdmi driver. Signed-off-by:
-
Laurent Pinchart authored
Replace the manual panel handling with usage of the DRM panel bridge helper. This simplifies the driver, and brings support for DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus. Signed-off-by:
-
Laurent Pinchart authored
On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings require a video output port connected to an HDMI sink (most likely an HDMI connector, in rare cases another bridges converting HDMI to another protocol). For those platforms, retrieve the next bridge and attach it from the dw-hdmi bridge attach handler. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by:
-
Laurent Pinchart authored
Being informed of a failure to attach a bridge is useful, and many drivers prints an error message in that case. Move the message to drm_bridge_attach() to avoid code duplication. Suggested-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Jyri Sarha <jyri.sarha@iki.fi>
-
Laurent Pinchart authored
When the device is unbound from the driver (the DU being a platform device, this occurs either when removing the DU module, or when unbinding the device manually through sysfs), the display may be active. Make sure it gets shut down. Signed-off-by:
-
Laurent Pinchart authored
The reference to the drm_device that was acquired by devm_drm_dev_alloc() is released automatically by the devres infrastructure. It must not be released manually, as that causes a reference underflow.. Fixes: ea6aae15 ("drm: rcar-du: Embed drm_device in rcar_du_device") Signed-off-by:
-
Laurent Pinchart authored
When the system shuts down or warm reboots, the display may be active, with the hardware accessing system memory. Upon reboot, the DDR will not be accessible, which may cause issues. Implement the platform_driver .shutdown() operation and shut down the display to fix this. Signed-off-by:
-
Colin Ian King authored
Don't populate the const array frs_limits on the stack but instead make it static. Makes the object code smaller by 128 bytes: Before: text data bss dec hex filename 24845 7440 64 32349 7e5d ./drivers/gpu/drm/bridge/tc358768.o After: text data bss dec hex filename 24749 7408 64 32221 7ddd ./drivers/gpu/drm/bridge/tc358768.o (gcc version 10.2.0) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Rob Clark authored
In the next patch, we start having more than a single potential failure reason. Signed-off-by:
-
Rob Clark authored
Previously the (non-fd) fence returned from submit ioctl was a raw seqno, which is scoped to the ring. But from UABI standpoint, the ioctls related to seqno fences all specify a submitqueue. We can take advantage of that to replace the seqno fences with a cyclic idr handle. This is in preperation for moving to drm scheduler, at which point the submit ioctl will return after queuing the submit job to the scheduler, but before the submit is written into the ring (and therefore before a ring seqno has been assigned). Which means we need to replace the dma_fence that userspace may need to wait on with a scheduler fence. Signed-off-by:
-
Rob Clark authored
Move all the locked/active/pinned state handling to msm_gem_submit.c. In particular, for drm/scheduler, we'll need to do all this before pushing the submit job to the scheduler. But while we're at it we can get rid of the dupicate pin and refcnt. Signed-off-by:
-
Rob Clark authored
No need for this to be split in two parts. Signed-off-by:
-
Rob Clark authored
Now that no one is using it, remove it. Signed-off-by:
-
Rob Clark authored
No idea why we were still using this. It certainly hasn't been needed for some time. So drop the pointless twin codepaths. Signed-off-by:
-
Rob Clark authored
If we don't have a gpu, there is no need to create a submitqueue, which lets us simplify the error handling and submitqueue creation. Signed-off-by:
-
Rob Clark authored
Fix a couple incorrect or misspelt comments, and add submitqueue doc comment. Signed-off-by:
-
Rob Clark authored
This adds a few things to try and make frequency scaling better match the workload: 1) Longer polling interval to avoid whip-lashing between too-high and too-low frequencies in certain workloads, like mobile games which throttle themselves to 30fps. Previously our polling interval was short enough to let things ramp down to minimum freq in the "off" frame, but long enough to not react quickly enough when rendering started on the next frame, leading to uneven frame times. (Ie. rather than a consistent 33ms it would alternate between 16/33/48ms.) 2) Awareness of when the GPU is active vs idle. Since we know when the GPU is active vs idle, we can clamp the frequency down to the minimum while it is idle. (If it is idle for long enough, then the autosuspend delay will eventually kick in and power down the GPU.) Since devfreq has no knowledge of powered-but-idle, this takes a small bit of trickery to maintain a "fake" frequency while idle. This, combined with the longer polling period allows devfreq to arrive at a reasonable "active" frequency, while still clamping to minimum freq when idle to reduce power draw. 3) Boost. Because simple_ondemand needs to see a certain threshold of busyness to ramp up, we could end up needing multiple polling cycles before it reacts appropriately on interactive workloads (ex. scrolling a web page after reading for some time), on top of the already lengthened polling interval, when we see a idle to active transition after a period of idle time we boost the frequency that we return to. Signed-off-by:
-
Rob Clark authored
In the next patch, it grows a bit more, so lets not duplicate the logic in multiple places. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210726144653.2180096-3-robdclark@gmail.comSigned-off-by:
-
Rob Clark authored
Before we start adding more cleverness, split it into it's own file. Signed-off-by:
-
Rob Clark authored
Nothing we do to in update_fences() can't be done in an atomic context, so move this into the GPU's irq context to reduce latency (and call dma_fence_signal() so we aren't relying on dma_fence_is_signaled() which would defeat the purpose). Signed-off-by:
-
