- 14 Apr, 2023 2 commits
-
-
Fabio Estevam authored
i.MX6SX has a single LVDS port and share a similar LDB_CTRL register layout with i.MX8MP and i.MX93. There is no LVDS CTRL register on the i.MX6SX, so only write to this register on the appropriate SoCs. Add support for the i.MX6SX LDB. Tested on a imx6sx-sdb board with a Hannstar HSD100PXN1 LVDS panel and also on a custom i.MX6SX-based board. Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Fabio Estevam authored
i.MX6SX has a single LVDS port and share a similar LDB_CTRL register layout with i.MX8MP and i.MX93. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
- 12 Apr, 2023 3 commits
-
-
Maíra Canal authored
Use drmm_mode_config_init() instead of drm_mode_config_init(), as it allows us to assure that the resource will be properly cleaned. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230116205800.1266227-2-mcanal@igalia.com
-
Maíra Canal authored
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes() to get rid of the explicit destroy hook in struct drm_crtc_funcs. Signed-off-by:
-
Daniel Vetter authored
Otherwise core changes don't get noticed by the right people. I noticed this because a patch set from Jagan Teki seems to have fallen through the cracks. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
Jagan Teki <jagan@amarulasolutions.com> [narmstrong: fixed ordering & Daniel's SoB] Signed-off-by:
-
- 11 Apr, 2023 7 commits
-
-
Tom Rix authored
clang with W=1 reports drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:56:35: error: unused function 'vmw_overlay' [-Werror,-Wunused-function] static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev) ^ This function is not used, so remove it. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230321182414.1826372-1-trix@redhat.com
-
Martin Krastev authored
Legacy Display Unit (LDU) fb dirty support used a custom fb dirty callback. Latter handled only the DIRTYFB IOCTL presentation path but not the ADDFB2/PAGE_FLIP/RMFB IOCTL path, common for Wayland compositors. Get rid of the custom callback in favor of drm_atomic_helper_dirtyfb and unify the handling of the presentation paths inside of vmw_ldu_primary_plane_atomic_update. This also homogenizes the fb dirty callbacks across all DUs: LDU, SOU and STDU. Signed-off-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Maaz Mombasawala <mombasawalam@vmware.com> Fixes: 2f5544ff ("drm/vmwgfx: Use atomic helper function for dirty fb IOCTL") Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by:
-
Zack Rusin authored
virtualbox implemented an incomplete version of the svga device which they decided to drop soon after the initial release. The device was always broken in various ways and never supported by vmwgfx. vmwgfx should refuse to load on those configurations but currently drm has no way of reloading fbdev when the specific pci driver refuses to load, which would leave users without a usable fb. Instead of refusing to load print an error and disable a bunch of functionality that virtualbox never implemented to at least get fb to work on their setup. Signed-off-by:
-
Martin Krastev authored
This internal helper handles a type of mksstat event counter which is currently unused. Remove the routine to avoid compile warnings. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
ruanjinjie authored
The symbol is not used outside of the file, so mark it static. Fixes the following warning: ./drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c:591:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static? Signed-off-by:
ruanjinjie <ruanjinjie@huawei.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
Ben Dooks authored
Make ga100_mc_device static as it isn't exported, to fix the following sparse warning: drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c:51:1: warning: symbol 'ga100_mc_device' was not declared. Should it be static? Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
-
Tom Rix authored
smatch reports drivers/gpu/drm/vc4/vc4_irq.c:60:1: warning: symbol 'render_wait' was not declared. Should it be static? This variable is not used so remove it. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230406151203.1953812-1-trix@redhat.com
-
- 07 Apr, 2023 2 commits
-
-
Javier Martinez Canillas authored
The driver doesn't use simple-KMS helpers to set a simple display pipeline but only the drm_simple_encoder_init() function to initialize an encoder. That helper is just a wrapper of drm_encoder_init(), but passing a struct drm_encoder_funcs that sets the .destroy handler to drm_encoder_cleanup(). Since the <drm/drm_simple_kms_helper.h> header is only included for this helper and because the connector is initialized with drm_connector_init() as well, do the same for the encoder and drop the header include. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Javier Martinez Canillas authored
This helper is just a wrapper that calls drm_connector_cleanup(), there's no need to have another level of indirection. Signed-off-by:
-
- 06 Apr, 2023 21 commits
-
-
Asahi Lina authored
After a job is pushed into the queue, it is owned by the scheduler core and may be freed at any time, so we can't write nor read the submit timestamp after that point. Fixes oopses observed with the drm/asahi driver, found with kASAN. Signed-off-by:
Asahi Lina <lina@asahilina.net> Link: https://lore.kernel.org/r/20230406-scheduler-uaf-2-v1-1-972531cf0a81@asahilina.netReviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Jagan Teki authored
Samsung MIPI DSIM bridge can be found on Exynos and NXP's i.MX8M Mini/Nano/Plus SoCs. Convert exynos_dsim.txt to yaml. Used the example node from exynos5433.dtsi instead of the one used in the legacy exynos_dsim.txt. Signed-off-by:
Rob Herring <robh@kernel.org>
-
Thomas Zimmermann authored
Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform the same operation as before, so there's no change in functionality. Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to omapdrm_fbdev_setup() after omapdrm has registered its DRM device. As in most drivers, omapdrm's fbdev emulation now acts like a regular DRM client. The fbdev client setup consists of the initial preparation and the hot-plugging of the display. The latter creates the fbdev device and sets up the fbdev framebuffer. The setup performs display hot-plugging once. If no display can be detected, DRM probe helpers re-run the detection on each hotplug event. A call to drm_dev_unregister() releases the client automatically. No further action is required within omapdrm. If the fbdev framebuffer has been fully set up, struct fb_ops.fb_destroy implements the release. For partially initialized emulation, the fbdev client reverts the initial setup. v2: * init drm_client in this patch (Tomi) * don't handle non-atomic modesetting (Tomi) Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
The DRM device stores a pointer to the fbdev helper. Remove struct omap_drm_private.fbdev, which contains the same value. No functional changes. v2: * don't clear dev->fb_helper unnecessarily (Tomi) * include omap_fbdev.h in omap_fbdev.c (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
Fbdev's framebuffer stores a pointer to the GEM object. Remove struct omap_fbdev.bo, which contains the same value. No functional changes. v2: * fix commit message (Tomi) Signed-off-by:
-
Thomas Zimmermann authored
Fbdev's struct fb_helper stores a pointer to the framebuffer. Remove struct omap_fbdev.fb, which contains the same value. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Include <linux/of.h> to get the contained declarations. No functional changes. Signed-off-by:
-
Maíra Canal authored
Before commit bc0d7fde ("drm: vkms: Supports to the case where primary plane doesn't match the CRTC"), the composition was executed on top of the primary plane. Therefore, the primary plane needed to cover the entire CRTC. After commit bc0d7fde, this is no longer necessary, as the composition is now executed on top of the CRTC. Then, allow the primary plane to be positioned in such a way that it doesn't cover the entire CRTC. This patch was tested with the vkms IGT testlist and all tests passed successfully. Moreover, the test igt@kms_universal_plane@universal-plane-pageflip-windowed-pipe-A used to fail and now is passing. Signed-off-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Maíra Canal authored
Before commit bc0d7fde ("drm: vkms: Supports to the case where primary plane doesn't match the CRTC"), the composition was executed on top of the primary plane. Therefore, the primary plane needed to be visible and full screen. After commit bc0d7fde, this is no longer necessary, as the composition is now executed on top of the CRTC. Then, remove the conditional expression that forced the primary plane to be visible and full screen. This allows vkms to accept non-null framebuffers when the CRTC is disabled. This patch was tested with the vkms IGT testlist and all tests passed successfully. Moreover, the tests igt@kms_universal_plane@universal-plane-pipe-a-functional and igt@kms_universal_plane@disable-primary-vs-flip-pipe-a used to fail and now are passing. Signed-off-by:
-
Thomas Hellström authored
When swapping in, or under memory pressure ttm_tt_populate() may sleep for a substantiable amount of time. Allow interrupts during the sleep. This will also allow us to inject -EINTR errors during swapin in upcoming patches. Also avoid returning VM_FAULT_OOM, since that will confuse the core mm, making it print out a confused message and retrying the fault. Return VM_FAULT_SIGBUS also under OOM conditions. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404200650.11043-4-thomas.hellstrom@linux.intel.com
-
Thomas Hellström authored
When swapping out, we will split multi-order pages both in order to move them to the swap-cache and to be able to return memory to the swap cache as soon as possible on a page-by-page basis. Reduce the page max order to the system PMD size, as we can then be nicer to the system and avoid splitting gigantic pages. Looking forward to when we might be able to swap out PMD size folios without splitting, this will also be a benefit. v2: - Include all orders up to the PMD size (Christian König) v3: - Avoid compilation errors for architectures with special PFN_SHIFTs Signed-off-by:
-
Thomas Hellström authored
When hitting an error, the error path forgot to unmap dma mappings and could call set_pages_wb() on already uncached pages. Fix this by introducing a common ttm_pool_free_range() function that does the right thing. v2: - Simplify that common function (Christian König) v3: - Rename that common function to ttm_pool_free_range() (Christian König) Fixes: d099fc8f ("drm/ttm: new TT backend allocation pool v3") Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Jeffrey Hugo authored
Add MAINTAINERS entry for the Qualcomm Cloud AI 100 driver. Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Acked-by:
Oded Gabbay <ogabbay@kernel.org> Signed-off-by:
-
Jeffrey Hugo authored
Now that we have all the components of a minimum QAIC which can boot and run an AIC100 device, add the infrastructure that allows the QAIC driver to be built. Signed-off-by:
-
Pranjal Ramajor Asha Kanojiya authored
Some of the MHI channels for an AIC100 device need to be routed to userspace so that userspace can communicate directly with QSM. The MHI bus does not support this, and while the WWAN subsystem does (for the same reasons), AIC100 is not a WWAN device. Also, MHI is not something that other accelerators are expected to share, thus an accel subsystem function that meets this usecase is unlikely. Create a QAIC specific MHI userspace shim that exposes these channels. Start with QAIC_SAHARA which is required to boot AIC100 and is consumed by the kickstart application as documented in aic100.rst Each AIC100 instance (currently, up to 16) in a system will create a chardev for QAIC_SAHARA. This chardev will be found as /dev/<mhi instance>_QAIC_SAHARA For example - /dev/mhi0_QAIC_SAHARA Signed-off-by:
-
Jeffrey Hugo authored
Add the datapath component that manages BOs and submits them to running workloads on the qaic device via the dma_bridge hardware. This allows QAIC clients to interact with their workloads (run inferences) via the following ioctls along with mmap(): DRM_IOCTL_QAIC_CREATE_BO DRM_IOCTL_QAIC_MMAP_BO DRM_IOCTL_QAIC_ATTACH_SLICE_BO DRM_IOCTL_QAIC_EXECUTE_BO DRM_IOCTL_QAIC_PARTIAL_EXECUTE_BO DRM_IOCTL_QAIC_WAIT_BO DRM_IOCTL_QAIC_PERF_STATS_BO Signed-off-by:
-
Jeffrey Hugo authored
Add the control path component that talks to the management processor (QSM) to load workloads onto the AIC100 device. This implements the KMD portion of the NNC protocol over the QAIC_CONTROL MHI channel and the DRM_IOCTL_QAIC_MANAGE IOCTL to userspace. With this functionality, QAIC clients are able to load, run, and cleanup their workloads on the device but not interact with the workloads (run inferences). Signed-off-by:
-
Jeffrey Hugo authored
An AIC100 device contains a MHI interface with a number of different channels for controlling different aspects of the device. The MHI controller works with the MHI bus to enable and drive that interface. AIC100 uses the BHI protocol in PBL to load SBL. The MHI controller expects the SBL to be located at /lib/firmware/qcom/aic100/sbl.bin and expects the MHI bus to manage the process of loading and sending SBL to the device. Signed-off-by:
-
Jeffrey Hugo authored
Add the QAIC driver uapi file and core driver file that binds to the PCIe device. The core driver file also creates the accel device and manages all the interconnections between the different parts of the driver. The driver can be built as a module. If so, it will be called "qaic.ko". Signed-off-by:
-
Jeffrey Hugo authored
The Qualcomm Cloud AI 100 (AIC100) device is an Artificial Intelligence accelerator PCIe card. It contains a number of components both in the SoC and on the card which facilitate running workloads: QSM: management processor NSPs: workload compute units DMA Bridge: dedicated data mover for the workloads MHI: multiplexed communication channels DDR: workload storage and memory The Linux kernel driver for AIC100 is called "QAIC" and is located in the accel subsystem. Signed-off-by:
-
Daniel Vetter authored
If the crtc is being switched on or off then the semantics of computing the timestampe of the next vblank is somewhat ill-defined. And indeed, the code splats with a warning in the timestamp computation code. Specifically it hits the check to make sure that atomic drivers have full set up the timing constants in the drm_vblank structure, and that's just not the case before the crtc is actually on. For robustness it seems best to just not set deadlines for modesets. v2: Also skip on inactive crtc (Ville) Link: https://lore.kernel.org/dri-devel/dfc21f18-7e1e-48f0-c05a-d659b9c90b91@linaro.org/ Fixes: d39e48ca ("drm/atomic-helper: Set fence deadline for vblank") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rob Clark <robdclark@chromium.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reported-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # test patch only Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
- 05 Apr, 2023 5 commits
-
-
Ville Syrjälä authored
Include the device and connector information in the SCDC debugs. Makes it easier to figure out who did what. v2: Rely on connector->ddc (Maxime) Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Emma Anholt <emma@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Cc: intel-gfx@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Thierry Reding <treding@nvidia.com>
-
Daniel Vetter authored
Apparently drivers need to check all this stuff themselves, which for most things makes sense I guess. And for everything else we luck out, because modern distros stopped supporting any other fbdev drivers than drm ones and I really don't want to argue anymore about who needs to check stuff. Therefore fixing all this just for drm fbdev emulation is good enough. Note that var->active is not set or validated. This is just control flow for fbmem.c and needs to be validated in there as needed. Reviewed-by:
-
Daniel Vetter authored
The fb_check_var hook is supposed to validate all this stuff. Any errors from fb_set_par are considered driver/hw issues and resulting in dmesg warnings. Luckily we do fix up the pixclock already, so this is all fine. Signed-off-by:
-
Daniel Vetter authored
Drivers are supposed to fix this up if needed if they don't outright reject it. Uncovered by 6c11df58 ("fbmem: Check virtual screen sizes in fb_set_var()"). Reported-by: syzbot+20dcf81733d43ddff661@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc Cc: stable@vger.kernel.org # v5.4+ Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Alexander Stein authored
There is no need to require non-sleeping GPIO access. Silence the WARN_ON() if GPIO is using e.g. I2C expanders. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
