- 03 Aug, 2020 15 commits
-
-
Thomas Zimmermann authored
The modesetting code initialized the memory-related register CRTCEXT4. Move this code to MM initialization. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200730102844.10995-7-tzimmermann@suse.de
-
Thomas Zimmermann authored
The modesetting code initialized several memory-related flags in the MISC register. Move this code to MM initialization. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200730102844.10995-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
MGA cards can run in traditional VGA mode or an enhanced MGA mode; with the latter being required for KMS. So far, MGA mode was enabled during modesetting. As it's fundamental for device operation, the patch moves it next to the device register setup. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200730102844.10995-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
So far, PCI option registers were initialized as part of modesetting, which is late in the process. As these registers control fundamental operation, they should be set early. The patch moves the PCI option handling into device register setup, before even the device MMIO memory is being mapped. No functional changes made. Moving the PCI code next to the device-register setup also allows to remove the has_sdram field from struct mga_device. The state is now local to the init helper. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200730102844.10995-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
The mgag200 driver maps registers into the address space. Move the code into a separate helper function. No functional changes. One small difference is in the handling of SDRAM/SGRAM. MGA devices can come with either SDRAM or SGRAM. So far, the driver checked for SDRAM, which is the common case. The patch moves this code into a separate helper and checks for SGRAM, which is the special case. The test itself is the same as before. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200730102844.10995-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
SHMEM pages use write-combine caching by default, but can also use the platform's default page caching. Doing so may improve the performance of I/O on the framebuffer. Mgag200's hardware does not access framebuffer pages directly (i.e., via DMA), so enabling caching does not have an effect on consistency of the framebuffer memory or the displayed data. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200730102844.10995-2-tzimmermann@suse.de
-
Thomas Zimmermann authored
This turns the ast's device cleanup code into a managed release helper function. Note that the code uses devres helpers. The release function switches the device back to VGA mode and therefore runs during HW device cleanup; not at DRM device cleanup. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-10-tzimmermann@suse.de
-
Thomas Zimmermann authored
The ast driver keeps a backup copy of the DP501 encoder's firmware. This patch adds managed release of the allocated memory. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
The ast driver loads firmware for the DP501 display encoder. The patch replaces the removal code with a managed release function. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-8-tzimmermann@suse.de
-
Thomas Zimmermann authored
Turns struct ast_private into a subclass of struct drm_device by embedding the latter. This allows for using DRM's managed device allocation. The use of struct drm_device.dev_private is deprecated. The patch converts the last remaining users to to_ast_private(). Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-7-tzimmermann@suse.de
-
Thomas Zimmermann authored
Several places in ast use ast->dev, when a dev pointer is already available within the function. Remove the extra indirection. No functional changes made. This is just a small cleanup before embedding the DRM device instance in struct ast_private. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
The ast code still references dev_private in several place when looking up the ast device structure. Convert the remaining locations to use to_ast_private(). Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
The ast driver's load and unload functions are left-overs from when struct drm_driver.load/unload was still in use. The PCI probe helper allocated the DRM device and ran load to initialize it. This patch replaces this code with device create and destroy. The main difference is that the device's create function allocates the DRM device and ast structures in the same place. This will be required for switching ast to managed allocations. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
Putting the DRM driver to the top of the file and the PCI code to the bottom makes ast_drv.c more readable. While at it, the patch prefixes file-scope variables with ast_. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Only single instances of CRTC and connector are supported per device. Embed both in ast's structure and remove the individual memory allocations. DRM's CRTC cleanup helpers replace the rsp. destroy function in ast. While at it, also convert to_ast_connector() to a function. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200730135206.30239-2-tzimmermann@suse.de
-
- 02 Aug, 2020 6 commits
-
-
Daniel Vetter authored
Userspace can provoke this, we generally don't allow userspace to spam dmesg. Tune it down to debug. Unfortunately we don't have easy access to the drm_device here (not at all without changing a few things), so leave it as old style dmesg output for now. References: https://patchwork.freedesktop.org/series/80146/Acked-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: "Christian König" <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200801092625.1107609-1-daniel.vetter@ffwll.ch
-
Melissa Wen authored
The previous memset operation was not correctly zeroing the alpha channel to compute the crc, and as a result, the IGT subtest kms_cursor_crc/pipe-A-cursor-alpha-transparent fails. Fixes: db7f419c ("drm/vkms: Compute CRC with Cursor Plane") Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200730202524.5upzuh4irboru7my@smtp.gmail.com
-
Marek Vasut authored
Add support for the Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel, connected over LVDS. Timings are taken from the datasheet version P0.5. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: dri-devel@lists.freedesktop.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728201242.4336-3-marex@denx.de
-
Marek Vasut authored
Add DT bindings for Chefree CH101OLHLWH-002 10.1" 1280x800 LCD. This panel is connected via LVDS. Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Rob Herring <robh@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728201242.4336-2-marex@denx.de
-
Marek Vasut authored
The Chefree Technology Corp. is an LCD panel manufacturer. Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Rob Herring <robh@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728201242.4336-1-marex@denx.de
-
Bernard Zhao authored
The function "int drm_panel_add(struct drm_panel *panel)" always returns 0, this return value is meaningless. Also, there is no need to check return value which calls "drm_panel_add and", error branch code will never run. Signed-off-by:
Bernard Zhao <bernard@vivo.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200801120216.8488-1-bernard@vivo.com
-
- 31 Jul, 2020 9 commits
-
-
Christian König authored
It is a very strange concept to call a function which just calls back the caller for the functions parameters. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382085/
-
Christian König authored
Instead just initialize the memory type parameters before calling ttm_bo_init_mm. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382086/
-
Christian König authored
Instead just initialize the memory type parameters before calling ttm_bo_init_mm. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382083/
-
Christian König authored
Instead just initialize the memory type parameters before calling ttm_bo_init_mm. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382081/
-
Christian König authored
Instead just initialize the memory type parameters before calling ttm_bo_init_mm. v2: keep extra system domain handling Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382082/
-
Christian König authored
Instead just initialize the memory type parameters before calling ttm_bo_init_mm. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382084/
-
Christian König authored
Instead just initialize the memory type parameters before calling ttm_bo_init_mm. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382080/
-
Christian König authored
Instead use a boolean field in the memory manager structure. Also invert the meaning of the field since the use of a TT structure is the special case here. v2: cleanup zero init. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/382079/
-
Christian König authored
Instead of repeating that in each driver. v2: keep the caching limitation for VMWGFX for now. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/382078/
-
- 30 Jul, 2020 4 commits
-
-
Paul Cercueil authored
Instead of keeping the IPU clock enabled constantly, enable and disable it on demand, when the IPU plane is used. That way, we won't use any extra power when the IPU is not used. v2: Explain the reason of this patch Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200730144830.10479-4-paul@crapouillou.net
-
Paul Cercueil authored
When configuring the IPU for packed YUV 4:2:2, depending on the scaling ratios given by the source and destination resolutions, it is possible to crash the IPU block, to the point where a software reset of the IP does not fix it. This can happen anytime, in the first few frames, or after dozens of minutes. The same crash also happens when the IPU is fully controlled by the LCD controller (in that case no HW register is written at any moment after startup), which points towards a hardware bug. Thanksfully multiplanar YUV is not affected. Until this bug is fixed or worked around, address this issue by removing support for YUV 4:2:2 on the IPU of the JZ4725B. v2: Update commit message (remove the "crash beyond repair" bit) Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200730144830.10479-3-paul@crapouillou.net
-
Paul Cercueil authored
On older SoCs, it is necessary to restart manually the IPU when a frame is done processing. Doing so on newer SoCs (JZ4760/70) kinds of work too, until the input or output resolutions or the framerate are too high. Make it work properly on newer SoCs by letting the LCD controller trigger the IPU frame restart signal. Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200730144830.10479-2-paul@crapouillou.net
-
Pekka Paalanen authored
Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . A related Wayland protocol change proposal is at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: Simon Ser <contact@emersion.fr> Cc: Ben Skeggs <skeggsb@gmail.com> Cc: Karol Herbst <kherbst@redhat.com> Acked-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200707113805.30936-1-ppaalanen@gmail.com
-
- 29 Jul, 2020 3 commits
-
-
Tian Tao authored
fixed the following warning: hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable. hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable. v2: using the pci_dev.msi_enabled instead of priv->msi_enabled. v3: just call pci_enable_msi() and pci_disable_msi(), it's no need to set dev->pdev->msi_enabled again. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-By:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1595940907-17874-1-git-send-email-tiantao6@hisilicon.com
-
Paul Cercueil authored
Validate modes in the drm_crtc_helper_funcs.mode_valid() callback, which is designed for this purpose, instead of doing it in drm_crtc_helper_funcs.atomic_check(). Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728151641.26124-3-paul@crapouillou.net
-
Paul Cercueil authored
drm_atomic_get_plane_state() can return errors, so we need to handle these. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728151641.26124-2-paul@crapouillou.net
-
- 28 Jul, 2020 3 commits
-
-
Marek Vasut authored
Add support for Powertip PH800480T013 800x480 parallel LCD, this one is used in the Raspberry Pi 7" touchscreen display unit. Signed-off-by:
Marek Vasut <marex@denx.de> To: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728121246.23304-3-marex@denx.de
-
Marek Vasut authored
Add DT bindings for Powertip PH800480T013 800x480 parallel LCD, this one is used in the Raspberry Pi 7" touchscreen display unit. Signed-off-by:
Marek Vasut <marex@denx.de> To: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728121246.23304-2-marex@denx.de
-
Marek Vasut authored
The Powertip Tech. Corp. is an LCD panel manufacturer. Signed-off-by:
Marek Vasut <marex@denx.de> To: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728121246.23304-1-marex@denx.de
-