- 16 Jun, 2021 5 commits
-
-
Zack Rusin authored
Register accesses are always 4bytes, accidently this was changed to a void pointer whwqich badly breaks 64bit archs when running on top of svga3. Fixes: 2cd80dbd ("drm/vmwgfx: Add basic support for SVGA3") Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210615182336.995192-3-zackr@vmware.com
-
Zack Rusin authored
Historically our device headers have been forked versions of the internal device headers, this has made maintaining them a bit of a burden. To fix the situation, going forward, the device headers will be verbatim copies of the internal headers. To do that the driver code has to be adapted to use pristine device headers. This will make future update to the device headers trivial and automatic. Signed-off-by:
-
Zack Rusin authored
Roland will be focusing on lavapipe over the next few months and won't have time for vmwgfx. vmwgfx is now maintained within drm-misc. Signed-off-by:
Roland Scheidegger <sroland@vmware.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210615182336.995192-1-zackr@vmware.com
-
Maxime Ripard authored
DRM currently polls for the HDMI connector status every 10s, which can be an issue when we connect/disconnect a display quickly or the device on the other end only issues a hotplug pulse (for example on EDID change). Switch the driver to rely on the internal controller logic for the BCM2711/RPi4. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524132018.264396-1-maxime@cerno.tech
-
Yu Jiahua authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Signed-off-by:
Yu Jiahua <yujiahua1@huawei.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
- 15 Jun, 2021 2 commits
-
-
Hridya Valsaraju authored
Overview ======== The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name /sys/kernel/dmabuf/buffers/<inode_number>/size /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Use Cases ========= The interface provides a way to gather DMA-BUF per-buffer statistics from production devices. These statistics will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. Background ========== Currently, there are two existing interfaces that provide information about DMA-BUFs. 1) /sys/kernel/debug/dma_buf/bufinfo debugfs is however unsuitable to be mounted in production systems and cannot be considered as an alternative to the sysfs interface being proposed. 2) proc/<pid>/fdinfo/<fd> The proc/<pid>/fdinfo/<fd> files expose information about DMA-BUF fds. However, the existing procfs interfaces can only provide information about the buffers for which processes hold fds or have the buffers mmapped into their address space. Since the procfs interfaces alone cannot provide a full picture of all DMA-BUFs in the system, there is the need for an alternate interface to provide this information on production systems. The patch contains the following major improvements over v1: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Hridya Valsaraju <hridya@google.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603214758.2955251-1-hridya@google.com
-
Ainux authored
The existence of the connector cannot be detected, so add the detect function to support. Signed-off-by:
Ainux <ainux.wang@gmail.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210526111515.40015-1-ainux.wang@gmail.com
-
- 14 Jun, 2021 7 commits
-
-
Linus Walleij authored
The SPI access to s6e63m0 is using the DBI protocol, so switch to using the elaborate DBI protocol implementation in the DRM DBI helper library. Acked-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210614181135.1124445-2-linus.walleij@linaro.org
-
Linus Walleij authored
Implement SPI reads for typec1, for SPI controllers that can support 9bpw in addition to 8bpw (such as GPIO bit-banged SPI). 9bpw emulation is not supported but we have to start with something. This is used by s6e63m0 to read display MTP information which is used by the driver for backlight control. Reviewed-by:
-
Christian König authored
Add a common allocation helper. Cleaning up the mix of kzalloc/kmalloc and some unused code in the selftest. v2: polish kernel doc a bit v3: polish kernel doc even a bit more Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Christian König authored
The callback and the irq work are never used at the same time. Putting them into an union saves us 24 bytes and makes the structure only 120 bytes in size. Signed-off-by:
-
Leandro Ribeiro authored
Add a small description and document struct fields of drm_mode_get_plane. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20210611213516.77904-2-leandro.ribeiro@collabora.com
-
Thomas Zimmermann authored
drm-misc and drm-intel pull request for topic/i915-ttm: - Convert i915 lmem handling to ttm. - Add a patch to temporarily add a driver_private member to vma_node. - Use this to allow mixed object mmap handling for i915.
-
Thomas Zimmermann authored
Backmerge to prepare for i915-ttm topic branch. Signed-off-by:
-
- 12 Jun, 2021 9 commits
-
-
Zack Rusin authored
The declarations of ttm_range_man_init and ttm_range_man_fini have been moved to ttm_range_manager.h so we have to add it to the include list. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Fixes: 3eb7d96e ("drm/ttm: flip over the range manager to self allocated nodes") Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Zack Rusin authored
vmw_chipset was duplicating pci_id. They are exactly the same variable just with two different names. Becuase pci_id was already used to detect the SVGA version, there's no point in having vmw_chipset and thus we can remove it. All references to vmw_chipset should use pci_id. Signed-off-by:
-
Martin Krastev authored
drm/vmwgfx: Refactor vmw_mksstat_remove_ioctl to expect pgid match with vmw_mksstat_add_ioctl to authorise removal. Original vmw_mksstat_remove_ioctl expected pid to match the corresponding vmw_mksstat_add_ioctl. That made impossible en-masse removals by one pid, which is a valid use case, so pid match was discarded. Current change enforces a broader pgid match as a form of protection from arbitrary processes interrupting an ongoing mks-guest-stats. Reviewed-by:
-
Zack Rusin authored
The indirection doesn't make sense because we always go through the same function pointer. Instead of the extra indirection lets inline the access to the current page. Signed-off-by:
-
Zack Rusin authored
This code has been unused for a while now. When the explicit checks for whether the driver is running on top of non-coherent swiotlb have been deprecated we lost the ability to fallback to physical mappings. Instead of trying to readd a module parameter to force usage of physical addresses it's better to just force coherent TTM pages via the force_coherent module parameter making this code pointless. Signed-off-by:
-
Zack Rusin authored
Fix some minor issues that Coverity spotted in the code. None of that are serious but they're all valid concerns so fixing them makes sense. Signed-off-by:
-
Zack Rusin authored
The has_dx variable was only set during the initialization which meant that UPDATE_SUBRESOURCE was never used. We were emulating it with UPDATE_GB_IMAGE but that's always been a stop-gap. Instead of has_dx which has been deprecated a long time ago we need to check for whether shader model 4.0 or newer is available to the device. Signed-off-by:
-
Martin Krastev authored
VMware mks-guest-stats mechanism allows the collection of performance stats from guest userland GL contexts, as well as from vmwgfx kernelspace, via a set of sw- defined performance counters. The userspace performance counters are (de)registerd with vmware-vmx-stats hypervisor via new iocts. The vmwgfx kernelspace counters are controlled at build-time via a new config DRM_VMWGFX_MKSSTATS. * Add vmw_mksstat_{add|remove|reset}_ioctl controlling the tracking of mks-guest-stats in guest winsys contexts * Add DRM_VMWGFX_MKSSTATS config to drivers/gpu/drm/vmwgfx/Kconfig controlling the instrumentation of vmwgfx for kernelspace mks-guest-stats counters * Instrument vmwgfx vmw_execbuf_ioctl to collect mks-guest-stats according to DRM_VMWGFX_MKSSTATS Signed-off-by: -
Zack Rusin authored
Make devcaps code self-contained so that it's easier to cache and operate on them. As the number of devcaps got bigger the code dealing with them got more and more tricky. Lets create a central place to deal with all the complexity. This lets us remove the lock we used to require to deal with register write races because we only read the devcaps at initialization. Signed-off-by:
-
- 11 Jun, 2021 17 commits
-
-
Douglas Anderson authored
Putting the panel under the bridge chip (under the aux-bus node) allows the panel driver to get access to the DP AUX bus, enabling all sorts of fabulous new features. While we're at this, get rid of a level of hierarchy for the panel node. It doesn't need "ports / port" and can just have a "port" child. For Linux, this patch has a hard requirement on the patches adding DP AUX bus support to the ti-sn65dsi86 bridge chip driver. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus"). Signed-off-by:Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.11.Ibdb7735fb1844561b902252215a69526a14f9abd@changeid
-
Douglas Anderson authored
As I was testing to make sure that the DEFER path worked well with my patch series, I got tired of seeing this scary message in my logs just because the panel needed to defer: [drm:ti_sn_bridge_probe] *ERROR* could not find any panel node Let's use dev_err_probe() which nicely quiets this error and also simplifies the code a tiny bit. We'll also update other places in the file which can use dev_err_probe(). Signed-off-by:
-
Douglas Anderson authored
This is really just a revert of commit 58074b08 ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts. The old code failed to read the EDID properly in a very important case: before the bridge's pre_enable() was called. The way things need to work: 1. Read the EDID. 2. Based on the EDID, decide on video settings and pixel clock. 3. Enable the bridge w/ the desired settings. The way things were working: 1. Try to read the EDID but fail; fall back to hardcoded values. 2. Based on hardcoded values, decide on video settings and pixel clock. 3. Enable the bridge w/ the desired settings. 4. Try again to read the EDID, it works now! 5. Realize that the hardcoded settings weren't quite right. 6. Disable / reenable the bridge w/ the right settings. The reasons for the failures were twofold: a) Since we never ran the bridge chip's pre-enable then we never set the bit to ignore HPD. This meant the bridge chip didn't even _try_ to go out on the bus and communicate with the panel. b) Even if we fixed things to ignore HPD, the EDID still wouldn't read if the panel wasn't on. Instead of reverting the code, we could fix it to set the HPD bit and also power on the panel. However, it also works nicely to just let the panel code read the EDID. Now that we've split the driver up we can expose the DDC AUX channel bus to the panel node. The panel can take charge of reading the EDID. NOTE: in order for things to work, anyone that needs to read the EDID will need to instantiate their panel using the new DP AUX bus (AKA by listing their panel under the "aux-bus" node of the bridge chip in the device tree). In the future if we want to use the bridge chip to provide a full external DP port (which won't have a panel) then we will have to conditinally add EDID reading back in. Suggested-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Douglas Anderson authored
We want to provide our panel with access to the DP AUX channel. The way to do this is to let our panel be a child of ours using the fancy new DP AUX bus support. Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.8.Ib5fe0638da85800141ce141bb8e441c5f25438d4@changeid
-
Douglas Anderson authored
On its own, this change looks a little strange and doesn't do too much useful. To understand why we're doing this we need to look forward to future patches where we're going to probe our panel using the new DP AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus"). Let's think about the set of steps we'll want to happen when we have the DP AUX bus: 1. We'll create the DP AUX bus. 2. We'll populate the devices on the DP AUX bus (AKA our panel). 3. For setting up the bridge-related functions of ti-sn65dsi86 we'll need to get a reference to the panel. If we do #1 - #3 in a single probe call things _mostly_ will work, but it won't be massively robust. Let's explore. First let's think of the easy case of no -EPROBE_DEFER. In that case in step #2 when we populate the devices on the DP AUX bus it will actually try probing the panel right away. Since the panel probe doesn't defer then in step #3 we'll get a reference to the panel and we're golden. Second, let's think of the case when the panel returns -EPROBE_DEFER. In that case step #2 won't synchronously create the panel (it'll just add the device to the defer list to do it later). Step #3 will fail to get the panel and the bridge sub-device will return -EPROBE_DEFER. We'll depopulate the DP AUX bus. Later we'll try the whole sequence again. Presumably the panel will eventually stop returning -EPROBE_DEFER and we'll go back to the first case where things were golden. So this case is OK too even if it's a bit ugly that we have to keep creating / deleting the AUX bus over and over. So where is the problem? As I said, it's mostly about robustness. I don't believe that step #2 (creating the sub-devices) is really guaranteed to be synchronous. This is evidenced by the fact that it's allowed to "succeed" by just sticking the device on the deferred list. If anything about the process changes in Linux as a whole and step #2 just kicks off the probe of the DP AUX endpoints (our panel) in the background then we'd be in trouble because we might never get the panel in step #3. Adding an extra sub-device means we just don't need to worry about it. We'll create the sub-device for the DP AUX bus and it won't go away until the whole ti-sn65dsi86 driver goes away. If the bridge sub-device defers (maybe because it can't find the panel) that won't depopulate the DP AUX bus and so we don't need to worry about it. NOTE: there's a little bit of a trick here. Though the AUX channel can run without the MIPI-to-eDP bits of the code, the MIPI-to-eDP bits can't run without the AUX channel. We could come up a complicated signaling scheme (have the MIPI-to-eDP bits return EPROBE_DEFER for a while or wait on some sort of completion), but it seems simple enough to just not even bother creating the bridge device until the AUX channel probes. That's what we'll do. Signed-off-by: -
Douglas Anderson authored
If panel-simple is instantiated as a DP AUX bus endpoint then we have access to the DP AUX bus. Let's stash it in the panel-simple structure, leaving it NULL for the cases where the panel is instantiated in other ways. If we happen to have access to the DP AUX bus and we weren't provided the ddc-i2c-bus in some other manner, let's use the DP AUX bus for it. Signed-off-by:
-
Douglas Anderson authored
The panel-simple driver can already have devices instantiated as platform devices or MIPI DSI devices. Let's add a 3rd way to instantiate it: as DP AUX endpoint devices. At the moment there is no benefit to instantiating it in this way, but: - In the next patch we'll give it access to the DDC channel via the DP AUX bus. - Possibly in the future we may use this channel to configure the backlight. Signed-off-by:
-
Douglas Anderson authored
Historically "simple" eDP panels have been handled by panel-simple which is a basic platform_device. In the device tree, the panel node was at the top level and not connected to anything else. Let's change it so that, instead, panels can be represented as being children of the "DP AUX bus". Essentially we're saying that the hierarchy that we're going to represent is the "control" connections between devices. The DP AUX bus is a control bus provided by an eDP controller (the parent) and consumed by a device like a panel (the child). The primary incentive here is to cleanly provide the panel driver the ability to communicate over the AUX bus while handling lifetime issues properly. The panel driver may want the AUX bus for controlling the backlight or querying the panel's EDID. The idea for this bus's design was hashed out over IRC [1]. [1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-05-11 Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Rajeev Nandan <rajeevny@codeaurora.org> Suggested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Douglas Anderson authored
The patch ("dt-bindings: drm: Introduce the DP AUX bus") talks about how using the DP AUX bus is better than learning how to slice bread. Let's add it to the ti-sn65dsi86 bindings. Signed-off-by:Rob Herring <robh@kernel.org> Reviewed-by:
-
Douglas Anderson authored
We want to be able to list an eDP panel as a child of an eDP controller node to represent the fact that the panel is connected to the controller's DP AUX bus. Though the panel and the controller are connected in several ways, the DP AUX bus is the primary control interface between the two and thus makes the most sense to model in device tree hierarchy. Listing a panel in this way makes it possible for the panel driver to easily get access to the DP AUX bus that it resides on, which can be useful to help in auto-detecting the panel and for turning on various bits. NOTE: historically eDP panels were _not_ listed under their controller but were listed at the top level of the device tree. This will still be supported for backward compatibility (and while DP controller drivers are adapted to support the new DT syntax) but should be considered deprecated since there is no downside to listing the panel under the controller. For now, the DP AUX bus bindings will only support an eDP panel underneath. It's possible it could be extended to allow having a DP connector under it in the future. NOTE: there is no "Example" in this bindings file. Yikes! This avoids duplicating the same example lots of places. See users of the aux bus (like ti-sn65dsi86) for examples. The idea for this bus's design was hashed out over IRC [1]. [1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-05-11Signed-off-by:
-
Douglas Anderson authored
The HPD (Hot Plug Detect) signal is present in many (probably even "most") eDP panels. For eDP, this signal isn't actually used for detecting hot-plugs of the panel but is more akin to a "panel ready" signal. After you provide power to the panel, panel timing diagrams typically say that you should wait for HPD to be asserted (or wait a fixed amount of time) before talking to the panel. The panel-simple bindings describes many eDP panels and many of these panels provide the HPD signal. We should add the HPD-related properties to the panel-simple bindings. The HPD properties are actually defined in panel-common.yaml, so adding them here just documents that they are OK for panels handled by the panel-simple bindings. NOTE: whether or not we'd include HPD properties in the panel node is more a property of the board design than the panel itself. For most boards using these eDP panels everything "magically" works without specifying any HPD properties and that's been why we haven't needed to allow the HPD properties earlier. On these boards the HPD signal goes directly to a dedicated "HPD" input to the eDP controller and this connection doesn't need to be described in the device tree. The only time the HPD properties are needed in the device tree are if HPD is hooked up to a GPIO or if HPD is normally on the panel but isn't used on a given board. That means that if we don't allow the HPD properties in panel-simple then one could argue that we've got to boot all eDP panels (or at least all those that someone could conceivably put on a system where HPD goes to a GPIO or isn't hooked up) from panel-simple. Signed-off-by:
-
Wei Yongjun authored
Fix the missing clk_disable_unprepare() before return from panfrost_clk_init() in the error handling case. Fixes: b681af0b ("drm: panfrost: add optional bus_clock") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Maarten Lankhorst authored
Use the ttm handlers for servicing page faults, and vm_access. We do our own validation of read-only access, otherwise use the ttm handlers as much as possible. Because the ttm handlers expect the vma_node at vma->base, we slightly need to massage the mmap handlers to look at vma_node->driver_private to fetch the bo, if it's NULL, we assume i915's normal mmap_offset uapi is used. This is the easiest way to achieve compatibility without changing ttm's semantics. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
This allows drivers to distinguish between different types of vma_node's. The readonly flag was unused and is thus removed. This is a temporary solution, until i915 is converted completely to use ttm for bo's. Signed-off-by:
-
Thomas Hellström authored
Since objects can be migrated or evicted when not pinned or locked, update the checks for lmem residency or future residency so that the value returned is not immediately stale. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Thomas Hellström authored
Most logical place to introduce TTM buffer objects is as an i915 gem object backend. We need to add some ops to account for added functionality like delayed delete and LRU list manipulation. Initially we support only LMEM and SYSTEM memory, but SYSTEM (which in this case means evicted LMEM objects) is not visible to i915 GEM yet. The plan is to move the i915 gem system region over to the TTM system memory type in upcoming patches. We set up GPU bindings directly both from LMEM and from the system region, as there is no need to use the legacy TTM_TT memory type. We reserve that for future porting of GGTT bindings to TTM. Remove the old lmem backend. Signed-off-by:
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Two cleanups - These patches make Exynos DRM driver to use pm_runtime_resume_and_get() function instead of m_runtime_get_sync() to deal with usage counter. pm_runtime_get_sync() increases the usage counter even when it failed, which could make callers to forget to decrease the usage counter. pm_runtime_resume_and_get() decreases the usage counter regardless of whether it failed or not. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210611025939.393282-1-inki.dae@samsung.com
-
