- 10 Dec, 2019 7 commits
-
-
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 <narmstrong@baylibre.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021091509.3864-7-narmstrong@baylibre.com
-
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 33 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: -
Sam Ravnborg authored
The callbacks in drm_panel_funcs are optional, so do not return an error just because no callback is assigned. v2: - Document what functions in drm_panel_funcs are optional (Laurent) - Return -EOPNOTSUPP if get_modes() is not assigned (Laurent) (Sam: -EOPNOTSUPP seems to best error code in this situation) Signed-off-by:
-
Chuhong Yuan authored
oaktrail_lvds_mode_set() misses a gma_power_end() in an error path. Add the call to fix it. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191209085747.16057-1-hslester96@gmail.com
-
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: Bruno Prémont <bonbons@linux-vserver.org> Cc: linux-input@vger.kernel.org Reviewed-by:
Bruno Prémont <bonbons@linux-vserver.org> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Boris Brezillon authored
The [pre_]enable/[post_]disable hooks are passed the old atomic state. Update the doc and rename the arguments to make it clear. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
-
Boris Brezillon authored
The drm_bridge_get_prev_bridge() helper will be useful for bridge drivers that want to do bus format negotiation with their neighbours. Signed-off-by:
-
Boris Brezillon authored
To iterate over all bridges attached to a specific encoder. Suggested-by:
-
Boris Brezillon authored
So that each element in the chain can easily access its predecessor. This will be needed to support bus format negotiation between elements of the bridge chain. Signed-off-by:
-
Boris Brezillon authored
We are about to replace the single-linked bridge list by a double-linked one based on list.h, leading to the suppression of the encoder->bridge field. But before we can do that we must provide a drm_bridge_chain_get_first_bridge() bridge helper and patch all drivers and core helpers to use it instead of directly accessing encoder->bridge. Note that we still have 2 drivers (VC4 and Exynos) manipulating the encoder->bridge field directly because they need to cut the bridge chain in order to control the enable/disable sequence. This is definitely not something we want to encourage, so let's keep those 2 oddities around until we find a better solution. Signed-off-by:
-
Boris Brezillon authored
And use it in drivers accessing the bridge->next field directly. This is part of our attempt to make the bridge chain a double-linked list based on the generic list helpers. Signed-off-by:
-
