- 10 Dec, 2019 16 commits
-
-
Thomas Zimmermann authored
After looking up VBIOS mode information in CRTC's atomic_check(), we can reuse it in atomic_flush(). No need for a second look-up. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191202111557.15176-7-tzimmermann@suse.de
-
Thomas Zimmermann authored
AST-specific CRTC state can be placed in the new struct ast_crtc_state. The atomic check functions of the CRTC and the primary plane will store the VBIOS mode info and the framebuffer format here. The CRTC will consume these during atomic_flush(). Signed-off-by:
-
Thomas Zimmermann authored
Introducing atomic_check() for priamry and cursor plane. The functions validate the plane state and will later set format information for the CRTC's atomic_flush(). Signed-off-by:
-
Thomas Zimmermann authored
In preparation of an update of the primary-plane code, this patch changes the arguments of several register-setting functions. No functional changes are made. The function ast_set_dac_reg() has no effect and therefore gets removed entirely. Signed-off-by:
-
Thomas Zimmermann authored
Enabling and disabling the screen used to be done in the register initialization and the DPMS function. None of these places is related to the screen's output. Now the primary plane's update and disable functions handle screen display state. The primary plane can now be switched off without displaying garbage. Signed-off-by:
-
Thomas Zimmermann authored
When enabling the CRTC after waking up from a power-saving mode, the primary plane's framebuffer might be NULL, which leads to a stack trace as shown below. [ 632.624608] BUG: kernel NULL pointer dereference, address: 0000000000000048 [ 632.624631] #PF: supervisor read access in kernel mode [ 632.624639] #PF: error_code(0x0000) - not-present page [ 632.624647] PGD 0 P4D 0 [ 632.624654] Oops: 0000 [#1] SMP PTI [ 632.624662] CPU: 0 PID: 2082 Comm: gnome-shell Tainted: G E 5.4.0-rc7-1-default+ #114 [ 632.624673] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN FIRE X2270 M2, BIOS 2.05 07/01/2010 [ 632.624689] RIP: 0010:ast_crtc_helper_atomic_enable+0x7d/0x680 [ast] [ 632.624698] Code: 48 8b 80 e0 02 00 00 4c 8b 60 10 31 c0 f3 48 ab 48 8b 83 78 04 00 00 4c 89 ef 48 8d 70 18 e8 9a e9 55 ce 48 8b 83 78 04 00 00 <49> 8b 7c 24 48 4c 89 ea 4c 8d 44 24 28 48 8d 4c 24 20 48 8d 70 18 [ 632.624718] RSP: 0018:ffffbe9ec123fa40 EFLAGS: 00010246 [ 632.624726] RAX: ffff95a13cfd3400 RBX: ffff95a13cf32000 RCX: 0000000000000000 [ 632.624735] RDX: 0000000000000000 RSI: ffff95a13cfd34e8 RDI: ffffbe9ec123fb40 [ 632.624744] RBP: ffffbe9ec123fb80 R08: 0000000000000000 R09: 0000000000000003 [ 632.624753] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 632.624762] R13: ffffbe9ec123fa70 R14: ffff95a13beb7000 R15: ffff95a13cf32800 [ 632.624772] FS: 00007f6d2763e140(0000) GS:ffff95a134000000(0000) knlGS:0000000000000000 [ 632.624782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 632.624790] CR2: 0000000000000048 CR3: 00000001192f8004 CR4: 00000000000206f0 [ 632.624800] Call Trace: [ 632.624811] ? __lock_acquire+0x409/0x7c0 [ 632.624830] drm_atomic_helper_commit_modeset_enables+0x1af/0x200 [ 632.624840] drm_atomic_helper_commit_tail+0x32/0x70 [ 632.624849] commit_tail+0xc7/0x110 [ 632.624857] drm_atomic_helper_commit+0x121/0x130 [ 632.624867] drm_atomic_connector_commit_dpms+0xd7/0x100 [ 632.624878] set_property_atomic+0xaf/0x110 [ 632.624890] drm_mode_obj_set_property_ioctl+0xbb/0x190 [ 632.624899] ? drm_mode_obj_find_prop_id+0x40/0x40 [ 632.624909] drm_ioctl_kernel+0x86/0xd0 [ 632.624918] drm_ioctl+0x1e4/0x36b [ 632.624925] ? drm_mode_obj_find_prop_id+0x40/0x40 [ 632.624939] do_vfs_ioctl+0x4bd/0x6e0 [ 632.624949] ksys_ioctl+0x5e/0x90 [ 632.624957] __x64_sys_ioctl+0x16/0x20 [ 632.624966] do_syscall_64+0x5a/0x220 [ 632.624976] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 632.624984] RIP: 0033:0x7f6d2b0de387 [ 632.624991] Code: 00 00 90 48 8b 05 f9 9a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c9 9a 0c 00 f7 d8 64 89 01 48 [ 632.625011] RSP: 002b:00007fffb49def38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 632.625021] RAX: ffffffffffffffda RBX: 00007fffb49def70 RCX: 00007f6d2b0de387 [ 632.625030] RDX: 00007fffb49def70 RSI: 00000000c01864ba RDI: 0000000000000009 [ 632.625040] RBP: 00000000c01864ba R08: 0000000000000000 R09: 00000000c0c0c0c0 [ 632.625049] R10: 0000000000000030 R11: 0000000000000246 R12: 000055bc367eb920 [ 632.625058] R13: 0000000000000009 R14: 0000000000000002 R15: 0000000000000000 [ 632.625071] Modules linked in: ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) af_packet(E) scsi_transport_iscsi(E) dmi_sysfs(E) msr(E) xfs(E) intel_powerclamp(E) coretemp(E) k) [ 632.625185] CR2: 0000000000000048 The STR is * start gdm and wait for it to switch off the display * wake up the display by pressing a key CRTC modesetting depends on the new state of the CRTC and the primary plane's framebuffer. The bugfix moves the modesetting code into the CRTC's atomic_flush() function, where it is protected from the plane's framebuffer being NULL. The CRTC's atomic-enable function, which is the modesetting's original location, still contains DPMS state handling. It's exactly the inverse of the atomic-disable function. v3: * protect modesetting from from fb == NULL v2: * do an atomic check for plane * reject invisible primary planes Signed-off-by:
-
Neil Armstrong authored
Finally, setup the VIU registers and start the AFBC decoder to support displaying AFBC encoded buffers on Amlogic GXM and G12A SoCs. The RDMA is used here to reset and program the AFBC decoder unit on each vsync without involving the interrupt handler that can be masked for a long period of time, producing display glitches. The vsync irq must still be left enabled otherwise the RDMA modules isn't trigerred when the interrupt line is masked. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021091509.3864-10-narmstrong@baylibre.com
-
Neil Armstrong authored
When using an AFBC encoded frame, the AFBC Decoder must be reset, configured and enabled at each vsync IRQ. To leave time for that, use the maximum lines hold time to give time for AFBC setup and avoid visual glitches. Signed-off-by:
-
Neil Armstrong authored
The Amlogic G12A AFBC Decoder pixel input need to be routed diferently than the Amlogic GXM AFBC decoder, this adds support for routing the VIU OSD1 pixel source to the AFBC "Mali Unpack" module. This "Mali Unpack" module is also configured with a static RGBA mapping for now until we support more pixel formats. Signed-off-by:
-
Neil Armstrong authored
This adds all the OSD configuration plumbing to support the AFBC decoders path to display of the OSD1 plane. The Amlogic GXM and G12A AFBC decoders are integrated very differently. The Amlogic GXM has a direct output path to the OSD1 VIU pixel input, because the GXM AFBC decoder seem to be a custom IP developed by Amlogic. On the other side, the Amlogic G12A AFBC decoder seems to be an external IP that emit pixels on an AXI master hooked to a "Mali Unpack" block feeding the OSD1 VIU pixel input. This uses a weird "0x1000000" internal HW physical address on both sides to transfer the pixels. For Amlogic GXM, the supported pixel formats are the same as the normal linear OSD1 mode. On the other side, Amlogic added support for all AFBC v1.2 formats for the G12A AFBC integration. For simplicity, we stick to the already supported formats for now. Signed-off-by:
-
Neil Armstrong authored
This adds the driver for the ARM Framebuffer Compression decoders found in the Amlogic GXM and G12A SoCs. The Amlogic GXM and G12A AFBC decoder are totally different, the GXM only handling only the AFBC v1.0 modes and the G12A decoder handling the AFBC v1.2 modes. The G12A AFBC decoder is an external IP integrated in the video pipeline, and the GXM AFBC decoder seems to the an Amlogic custom decoder more tighly integrated in the video pipeline. The GXM AFBC decoder can handle only one AFBC plane for 2 available OSD planes available in HW, and the G12A AFBC decoder can handle up to 4 AFBC planes for up to 3 OSD planes available in HW. The Amlogic GXM supports 16x16 SPARSE and 16x16 SPLIT AFBC buffers up to 4k. On the other side, for G12A SPLIT is mandatory in 16x16 block mode, but for 4k modes 32x8+SPLIT AFBC buffers is manadatory for performances reasons. The RDMA is used here to reset and program the AFBC decoder unit on each vsync without involving the interrupt handler that can be masked for a long period of time, producing display glitches. For this we use the meson_rdma_writel_sync() which adds the register write tuple (VPU register offset and register value) to the RDMA buffer and write the value to the HW. When enabled, the RDMA is enabled to rewrite the same sequence at the next VSYNC event, until a new buffer is committed to the OSD plane. Then the Amlogic G12A is switched to RDMA, the Amlogic GXM Decoder doesn't need a reset/reprogram at each vsync, but needs to keep the vsync interrupt enabled to trigger the RDMA module. Signed-off-by:
-
Neil Armstrong authored
The VPU embeds a "Register DMA" that can write a sequence of registers on the VPU AHB bus, either manually or triggered by an internal IRQ event like VSYNC or a line input counter. The initial implementation handles a single channel (over 8), triggered by the VSYNC irq and does not handle the RDMA irq. The RDMA will be usefull to reset and program the AFBC decoder unit on each vsync without involving the interrupt handler that can be masked for a log period of time, producing display glitches. Signed-off-by:
-
Neil Armstrong authored
Also store the framebuffer width in the private common struct to be used by the AFBC decoder module driver when committing the AFBC plane. Signed-off-by:
-
Neil Armstrong authored
The Amlogic VPU embeds a "Register DMA" that can write a sequence of registers on the VPU AHB bus, either manually or triggered by an internal IRQ event like VSYNC or a line input counter. This adds the register defines. Signed-off-by:
-
Neil Armstrong authored
Add the registers used to program the ARM Framebuffer Compression decoders used in the Amlogic GXM and G12A SoCs families. This also adds the routing and pipeline configuration bits and registers needed to enable AFBC support. Signed-off-by:
-
Jani Nikula authored
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. v2: fix typo (Christophe de Dinechin) Cc: Kirti Wankhede <kwankhede@nvidia.com> Cc: kvm@vger.kernel.org Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Kirti Wankhede <kwankhede@nvidia.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ddb10df1316ef585930cda7718643a580f4fe37b.1575390741.git.jani.nikula@intel.com
-
- 09 Dec, 2019 24 commits
-
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-26-sam@ravnborg.org
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver. While touching the include files sort them and divide them up in blocks. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Reviewed-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
Use the backlight support in drm_panel to simplify the driver Signed-off-by:
-
Sam Ravnborg authored
The panel drivers used drm_panel.drm for two purposes: 1) Argument to drm_mode_duplicate() 2) drm->dev was used in error messages The first usage is replaced with drm_connector.dev - drm_connector is already connected to a drm_device and we have a valid connector The second usage is replaced with drm_panel.dev - this makes drivers more consistent in their dev argument used for dev_err() and friends With these replacements there are no more uses of drm_panel.drm, so it is removed from struct drm_panel. With this change drm_panel_attach() and drm_panel_detach() no longer have any use as they are empty functions. v2: - editorial correction in changelog (Laurent) Signed-off-by:
-
Sam Ravnborg authored
To facilitate moving connector creation to display drivers, decouple the drm_connector from drm_panel. This patch adds a connector argument to drm_panel_get_modes(). All users of drm_panel_get_modes() already had the connector available, so updating users was trivial. With this patch drm_panel no longer keeps a reference to the drm_connector. Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Stefan Agner <stefan@agner.ch> Cc: Alison Wang <alison.wang@nxp.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Torsten Duwe <duwe@lst.de> Cc: Vasily Khoruzhick <anarsoul@gmail.com> Cc: Icenowy Zheng <icenowy@aosc.io> Cc: Sean Paul <seanpaul@chromium.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Hariprasad Kelam <hariprasad.kelam@gmail.com> Cc: Alexios Zavras <alexios.zavras@intel.com> Cc: Brian Masney <masneyb@onstation.org> Cc: Rob Clark <robdclark@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Allison Randal <allison@lohutok.net> Cc: Shayenne Moura <shayenneluzmoura@gmail.com> Cc: Abhinav Kumar <abhinavk@codeaurora.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-tegra@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-7-sam@ravnborg.org
-
Sam Ravnborg authored
Today the bridge creates the drm_connector, but that is planned to be moved to the display drivers. To facilitate this, update drm_panel_funcs.get_modes() to take drm_connector as an argument. All panel drivers implementing get_modes() are updated. v2: - drop accidental change (Laurent) - update docs for get_modes (Laurent) Signed-off-by:
-
Sam Ravnborg authored
The drm_connector created by drm_panel_bridge was accessed via drm_panel.connector. Avoid the detour around drm_panel by providing a simple get method. This avoids direct access to the connector field in drm_panel in the two users. The change is done in preparation for removal of drm_panel.connector. Update pl111 and tve200 to use the new helper. Signed-off-by:
-
Sam Ravnborg authored
Use drm_panel infrastructure for backlight. Replace direct calls with drm_panel_*() calls to utilize the drm_panel support. Signed-off-by:
-
Sam Ravnborg authored
Panels often support backlight as specified in a device tree. Update the drm_panel infrastructure to support this to simplify the drivers. With this the panel driver just needs to add the following to the probe() function: err = drm_panel_of_backlight(panel); if (err) return err; Then drm_panel will handle all the rest. There is one caveat with the backlight support. If drm_panel_(enable|disable) are called multiple times in a row then backlight_(enable|disable) will be called multiple times. The above will happen when a panel drivers unconditionally calls drm_panel_disable() in their shutdown() function, whan the panel is already disabled and then shutdown() is called. Reading the backlight code it seems safe to call the backlight_(enable|disable) several times. v3: - Improve comments, fix grammar (Laurent) - Do not fail in drm_panel_of_backlight() if no DT support (Laurent) - Log if backlight_(enable|disable) fails (Laurent) - Improve drm_panel_of_backlight() docs - Updated changelog with backlight analysis (triggered by Laurent) v2: - Drop test of CONFIG_DRM_PANEL in header-file (Laurent) - do not enable backlight if ->enable() returns an error Signed-off-by:
-
