Skip to content
  1. Apr 21, 2020
  3. Apr 17, 2020
  5. Apr 02, 2020
  7. Mar 18, 2020
  9. Mar 13, 2020
  11. Mar 12, 2020
  13. Mar 06, 2020
  15. Feb 06, 2020
  17. Jan 31, 2020
    • Thierry Reding's avatar
      drm/tegra: sor: Initialize runtime PM before use · c472a0b0
      Thierry Reding authored 
      

Commit fd67e9c6 ("drm/tegra: Do not implement runtime PM") replaced
the generic runtime PM usage by a host1x bus-specific implementation in
order to work around some assumptions baked into runtime PM that are in
conflict with the requirements in the Tegra DRM driver.

Unfortunately the new runtime PM callbacks are not setup yet at the time
when the SOR driver first needs to resume the device to register the SOR
pad clock, and accesses to register will cause the system to hang.

Note that this only happens on Tegra124 and Tegra210 because those are
the only SoCs where the SOR pad clock is registered from the SOR driver.
Later generations use a SOR pad clock provided by the BPMP.

Fix this by moving the registration of the SOR pad clock after the
host1x client has been registered. That's somewhat suboptimal because
this could potentially, though it's very unlikely, cause the Tegra DRM
to be probed if the SOR happens to be the last subdevice to register,
only to be immediately removed again if the SOR pad output clock fails
to register. That's just a minor annoyance, though, and doesn't justify
implementing a workaround.

Fixes: fd67e9c6 ("drm/tegra: Do not implement runtime PM")
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      c472a0b0
    • Thierry Reding's avatar
      drm/tegra: sor: Disable runtime PM on probe failure · ad2139cb
      Thierry Reding authored 
      

If the driver fails to probe, make sure to disable runtime PM again.

While at it, make the cleanup code in ->remove() symmetric.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      ad2139cb
    • Thierry Reding's avatar
      drm/tegra: sor: Suspend on clock registration failure · a5127a2d
      Thierry Reding authored 
      

Make sure the SOR module is suspenden after we fail to register the SOR
pad output clock.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      a5127a2d
  19. Jan 10, 2020
    • Thierry Reding's avatar
      drm/tegra: output: Implement system suspend/resume · 271502ef
      Thierry Reding authored 
      

Implement generic system suspend/resume functions that can be used with
any output type. Currently this only implements disabling and enabling
of the IRQ functionality across system suspend/resume. This prevents an
interrupt from happening before the display driver has fully resumed.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      271502ef
    • Arnd Bergmann's avatar
      drm/tegra: sor: Mark PM functions as __maybe_unused · f90965ab
      Arnd Bergmann authored 
      

Without CONFIG_PM, some functions cause harmless warnings:

drivers/gpu/drm/tegra/sor.c:3984:12: error: 'tegra_sor_resume' defined but not used [-Werror=unused-function]
 static int tegra_sor_resume(struct device *dev)
            ^~~~~~~~~~~~~~~~
drivers/gpu/drm/tegra/sor.c:3970:12: error: 'tegra_sor_suspend' defined but not used [-Werror=unused-function]
 static int tegra_sor_suspend(struct device *dev)
            ^~~~~~~~~~~~~~~~~

Mark these as __maybe_unused so the compiler can drop them
silently.

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      f90965ab
    • Thierry Reding's avatar
      drm/tegra: Do not implement runtime PM · fd67e9c6
      Thierry Reding authored 
      

The Tegra DRM driver heavily relies on the implementations for runtime
suspend/resume to be called at specific times. Unfortunately, there are
some cases where that doesn't work. One example is if the user disables
runtime PM for a given subdevice. Another example is that the PM core
acquires a reference to runtime PM during system sleep, effectively
preventing devices from going into low power modes. This is intentional
to avoid nasty race conditions, but it also causes system sleep to not
function properly on all Tegra systems.

Fix this by not implementing runtime PM at all. Instead, a minimal,
reference-counted suspend/resume infrastructure is added to the host1x
bus. This has the benefit that it can be used regardless of the system
power state (or any transitions we might be in), or whether or not the
user allows runtime PM.

Atomic modesetting guarantees that these functions will end up being
called at the right point in time, so the pitfalls for the more generic
runtime PM do not apply here.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      fd67e9c6
    • Thierry Reding's avatar
      gpu: host1x: Rename "parent" to "host" · 608f43ad
      Thierry Reding authored 
      

Rename the host1x clients' parent to "host" because that more closely
describes what it is. The parent can be confused with the parent device
in terms of the device hierarchy. Subsequent patches will add a new
member that refers to the parent in that hierarchy.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      608f43ad
  21. Jan 07, 2020
  23. Dec 09, 2019
    • Sam Ravnborg's avatar
      drm/panel: decouple connector from drm_panel · 06c4a9c2
      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: default avatarSam Ravnborg <sam@ravnborg.org>
Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Acked-by: default avatarJeffrey 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
      06c4a9c2
  25. Dec 05, 2019
  27. Dec 04, 2019
  29. Dec 01, 2019
  31. Nov 25, 2019
  33. Nov 01, 2019
    • Thierry Reding's avatar
      drm/tegra: Unconditionally select IOMMU_IOVA · 84db889e
      Thierry Reding authored 
      

Currently configurations can be generated where IOMMU_SUPPORT is
disabled but IOMMU_IOVA is built as a module and DRM_TEGRA as built-in.
In such a case, the symbols guarded by IOMMU_IOVA will not be available
when linking the Tegra DRM driver and cause a linking failure.

Simplify this by unconditionally selecting IOMMU_IOVA, which makes sure
that it will be forced to =y if DRM_TEGRA=y. Technically we can now get
IOMMU_IOVA code built-in even if we don't use it (Tegra DRM only uses it
when IOMMU_SUPPORT is also enabled), but such configuration are of a
mostly academic nature. In all practical configurations we want IOMMU
support anyway.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      84db889e
  35. Oct 29, 2019
    • Thierry Reding's avatar
      drm/tegra: Optionally attach clients to the IOMMU · fa6661b7
      Thierry Reding authored 
      

If a client is already attached to an IOMMU domain that is not the
shared domain, don't try to attach it again. This allows using the
IOMMU-backed DMA API.

Since the IOMMU-backed DMA API is now supported and there's no way
to detach from it on 64-bit ARM, don't bother to detach from it on
32-bit ARM either.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      fa6661b7
    • Thierry Reding's avatar
      drm/tegra: Support DMA API for display controllers · 2e8d8749
      Thierry Reding authored 
      

If a display controller is not attached to an explicit IOMMU domain,
which usually means that it's connected to an IOMMU domain controlled by
the DMA API, make sure to map the framebuffer to the display controller
address space. This allows us to transparently handle setups where the
display controller is attached to an IOMMU or setups where it isn't. It
also allows the driver to work with a DMA API that is backed by an
IOMMU.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      2e8d8749
    • Thierry Reding's avatar
      drm/tegra: falcon: Clarify address usage · d972d624
      Thierry Reding authored 
      

Rename paddr -> iova and vaddr -> virt to make it clearer how these
addresses are used. This is important for a subsequent patch that makes
a distinction between the physical address (physical address of the
system memory from the CPU's point of view) and the IOVA (physical
address of the system memory from the device's point of view).

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      d972d624
    • Thierry Reding's avatar
      drm/tegra: Remove memory allocation from Falcon library · 20e7dce2
      Thierry Reding authored 
      

Having to provide allocator hooks to the Falcon library is somewhat
cumbersome and it doesn't give the users of the library a lot of
flexibility to deal with allocations. Instead, remove the notion of
Falcon "operations" and let drivers deal with the memory allocations
themselves.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      20e7dce2