- 31 Jul, 2020 5 commits
-
-
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 authored
Instead just initialize the memory type parameters before calling ttm_bo_init_mm. Signed-off-by:
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Christian König authored
Instead of repeating that in each driver. v2: keep the caching limitation for VMWGFX for now. Signed-off-by:
-
- 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:
-
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:
-
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:
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:
-
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 authored
drm_atomic_get_plane_state() can return errors, so we need to handle these. Signed-off-by:
-
- 28 Jul, 2020 28 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:
-
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 authored
The Powertip Tech. Corp. is an LCD panel manufacturer. Signed-off-by:
-
Laurent Pinchart authored
The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha plane. Support it. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Laurent Pinchart authored
This is a cosmetic change only, no code change is included. Signed-off-by:
-
Laurent Pinchart authored
The mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt() functions both deal with format configuration, are always called in a row from mxsfb_crtc_mode_set_nofb(), and set fields from the LCDC_CTRL register. This requires a read-modify-update cycle in mxsfb_set_bus_fmt(). Make this more efficient by merging them together. Signed-off-by:
-
Laurent Pinchart authored
The mxsfb_set_pixel_fmt() function returns an error when the selected pixel format is unsupported. This can never happen, as such errors are caught by the DRM core. Remove the error check. Signed-off-by:
-
Laurent Pinchart authored
The mxsfb driver is only used by OF platforms. Drop non-OF support. Signed-off-by:
-
Laurent Pinchart authored
The LCDIF present in the i.MX6SX has extra features compared to the i.MX28. It has however lost its IP version register, so no official version number is known. Bump the version to MXSFB_V6 following the i.MX version, in preparation for support for the additional features. Signed-off-by:
-
Laurent Pinchart authored
Extend the Kconfig option description by listing the i.MX7 and i.MX8M SoCs, as they are supported by the same driver. Replace the list of SoCs in the short description with just "(e)LCDIF LCD controller" to avoid expanding it further in the future as support for more SoCs is added. Signed-off-by:
-
Laurent Pinchart authored
The debug0 and ipversion fields of the mxsfb_devdata structure are unused. Remove them. Signed-off-by:
-
Laurent Pinchart authored
Enable vblank handling when the CRTC is turned on and disable it when it is turned off. This requires moving vblank init after the KMS pipeline initialisation, otherwise drm_vblank_init() gets called with 0 CRTCs. Signed-off-by:
-
Laurent Pinchart authored
The driver attempts agressive power management by enabling and disabling the AXI clock around register accesses. This results in attempts to enable and disable the clock in the IRQ handler, which is a no-go as preparing or unpreparing the clock may sleep. On the other hand, the driver enables the AXI clock when enabling the CRTC and keeps it enabled until the CRTC is disabled. This is correct, and renders the power management attempt pointless, as interrupts are not supposed to occur when the CRTC is off. The same reasoning can be applied to the CRTC .enable_vblank() and .disable_vblank() that are not supposed to be called when the CRTC off and thus don't require manual handling of the AXI clock. Furthermore, vblank handling is never enabled, which results in the vblank enable and disable handlers never being called. To fix this, remove the manual clock handling in the IRQ, the CRTC .enable_vblank() and .disable_vblank() handlers and the plane .atomic_update() handler. We however need to handle the clock manually in mxsfb_irq_disable() as is calls .disable_vblank() manually and is used both at probe and remove time. The clock disabling is also moved to the last step of the mxsfb_crtc_atomic_disable() function, to prepare for enabling vblank handling. Signed-off-by:
-
Laurent Pinchart authored
The vblank event is armed in the plane .atomic_update(). This works fine as we have a single plane, and was the only option when the driver was using the drm_simple_kms_helper helper, but will break as soon as multiple planes are supported. Move it to CRTC .atomic_flush(). Signed-off-by:
-
Laurent Pinchart authored
The DRM simple display pipeline helper only supports a single plane. In order to prepare for support of the alpha plane on i.MX6SX and i.MX7, move away from the helper. No new feature is added. Signed-off-by:
-
Laurent Pinchart authored
The mxsfb_crtc.c file doesn't handle just the CRTC, but also the other KMS objects. Rename it accordingly. Signed-off-by:
-
Laurent Pinchart authored
A fair number of includes are not needed. Drop them, and add a couple of required includes that were included indirectly. Signed-off-by:
-
Laurent Pinchart authored
mxsfb_crtc.c defines several macros related to register addresses and bit, which duplicates macros from mxsfb_regs.h. Use the macros from mxsfb_regs.h instead and remove them. Signed-off-by:
-
Laurent Pinchart authored
The LCDC_CTRL register is located at address 0x0000. Some of the accesses to the register simply use the mxsfb->base address. Reference the LCDC_CTRL register explicitly instead to clarify the code. Signed-off-by:
-
Laurent Pinchart authored
The mxsfb_reset_block() function isn't special, pass it the mxsfb_drm_private pointer instead of a pointer to the base address. Signed-off-by:
-
Laurent Pinchart authored
Replace the convoluted way to set the format and bus width through difficult to read macros with more explicit ones. Also remove the outdated comment related to the limitations on bus width setting as it doesn't apply anymore (the bus width can be specified through the display_info bus format). Signed-off-by:
-
Laurent Pinchart authored
mxsfb_regs.h defines macros related to register bits. Some of them are not used and don't clearly map to any particular register, so their purpose isn't known. Remove them. Signed-off-by:
-
Laurent Pinchart authored
Using BIT() is preferred over manual shifts as it's more readable, handles the 1 << 31 case properly, and avoids other mistakes as shown by the DEBUG0_HSYNC and DEBUG0_VSYNC bits (that are currently unused). Use it. Signed-off-by:
-
Laurent Pinchart authored
Replace the manual connector implementation based on drm_panel with the drm_panel_bridge helper. This simplifies the mxsfb driver by removing connector-related code, and standardizing all pipeline control operations on bridges. A hack is needed to get hold of the connector, as that's our only source of bus flags and formats for now. As soon as the bridge API provides us with that information this can be fixed. Signed-off-by:
-
Laurent Pinchart authored
Commit 8e93f102 ("drm/mxsfb: Use drm_fbdev_generic_setup()") replaced fbdev handling with drm_fbdev_generic_setup() but left inclusion of the drm/drm_fb_cma_helper.h header. Remove it. Fixes: 8e93f102 ("drm/mxsfb: Use drm_fbdev_generic_setup()") Signed-off-by:
-
Christian König authored
We can't pipeline that during eviction because the memory needs to be available immediately. v2: fix how we cleanup the BOs resources Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Tested-by:
Alex Sierra <alex.sierra@amd.com> Link: https://patchwork.freedesktop.org/patch/379039/
-
Paul Menzel authored
The newly added hexint helper is more convenient for bitmasks. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xffffbfff Cc: amd-gfx@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by:Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by:
-
Paul Menzel authored
For bitmasks printing values in hex is more convenient. Prefix with `0x` to make it clear, that it’s a hex value, and pad it out. Using the helper for `amdgpu.ppfeaturemask`, it will look like below. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xffffbfff Cc: linux-kernel@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by:
-
