Re: [git pull] drm for 5.8-rc1
On Tue, Aug 18, 2020 at 04:37:51PM +0200, Thierry Reding wrote: > On Fri, Aug 14, 2020 at 07:25:17PM +0200, Daniel Vetter wrote: > > On Fri, Aug 14, 2020 at 7:17 PM Daniel Stone wrote: > > > > > > Hi, > > > > > > On Fri, 14 Aug 2020 at 17:22, Thierry Reding > > > wrote: > > > > I suspect that the reason why this works in X but not in Wayland is > > > > because X passes the right usage flags, whereas Weston may not. But I'll > > > > have to investigate more in order to be sure. > > > > > > Weston allocates its own buffers for displaying the result of > > > composition through GBM with USE_SCANOUT, which is definitely correct. > > > > > > Wayland clients (common to all compositors, in Mesa's > > > src/egl/drivers/dri2/platform_wayland.c) allocate with USE_SHARED but > > > _not_ USE_SCANOUT, which is correct in that they are guaranteed to be > > > shared, but not guaranteed to be scanned out. The expectation is that > > > non-scanout-compatible buffers would be rejected by gbm_bo_import if > > > not drmModeAddFB2. > > > > > > One difference between Weston and all other compositors (GNOME Shell, > > > KWin, Sway, etc) is that Weston uses KMS planes for composition when > > > it can (i.e. when gbm_bo_import from dmabuf + drmModeAddFB2 from > > > gbm_bo handle + atomic check succeed), but the other compositors only > > > use the GPU. So if you have different assumptions about the layout of > > > imported buffers between the GPU and KMS, that would explain a fair > > > bit. > > > > Yeah non-modifiered multi-gpu (of any kind) is pretty much hopeless I > > think. I guess the only option is if the tegra mesa driver forces > > linear and an extra copy on everything that's USE_SHARED or > > USE_SCANOUT. > > I ended up trying this, but this fails for the X case, unfortunately, > because there doesn't seem to be a good synchronization point at which > the de-tiling blit could be done. Weston and kmscube end up calling a > gallium driver's ->flush_resource() implementation, but that never > happens for X and glamor. > > But after looking into this some more, I don't think that's even the > problem that we're facing here. The root of the problem that causes the > glxgears crash that Karol was originally reporting is because we end up > allocating the glxgears pixmaps using the dri3 loader from Mesa. But the > dri3 loader will unconditionally pass both __DRI_IMAGE_USE_SHARE and > __DRI_IMAGE_USE_SCANOUT, irrespective of whether the buffer will end up > being scanned out directly or whether it will be composited onto the > root window. > > What exactly happens depends on whether I run glxgears in fullscreen > mode or windowed mode. In windowed mode, the glxgears buffers will be > composited onto the root window, so there's no need for the buffers to > be scanout-capable. If I modify the dri3 loader to not pass those flags > I can make this work just fine. > > When I run glxgears in fullscreen mode, the modesetting driver ends up > wanting to display the glxgears buffer directly on screen, without > compositing it onto the root window. This ends up working if I leave out > the _USE_SHARE and _USE_SCANOUT flags, but I notice that the kernel then > complains about being unable to create a framebuffer, which in turn is > caused by the fact that those buffers are not exported (the Tegra Mesa > driver only exports/imports buffers that are meant for scanout, under > the assumption that those are the only ones that will ever need to be > used by KMS) and therefore Tegra DRM doesn't have a valid handle for > them. > > So I think an ideal solution would probably be for glxgears to somehow > pass better usage information when allocating buffers, but I suspect > that that's just not possible, or would be way too much work and require > additional protocol at the DRI level, so it's not really a good option > when all we want to fix is backwards-compatibility with pre-modifiers > userspace. > > Given that glamor also doesn't have any synchronization points, I don't > see how I can implement the de-tiling blit reliably. I was wondering if > it shouldn't be possible to flush the framebuffer resource (and perform > the blit) at presentation time, but I couldn't find a good entry point > to do this. > > One other solution that occurred to me was to reintroduce an old IOCTL > that we used to have in the Tegra DRM driver. That IOCTL was meant to > attach tiling meta data to an imported buffer and was basically a > simplified, driver-specific way of doing framebuffer modifiers. That's > a very ugly solution, but it would allow us to be backwards-compatible > with pre-modifiers userspace and even use an optimal path for rendering > and scanning out. The only prerequisite would be that the driver IOCTL > was implemented and that a recent enough Mesa was used to make use of > it. I don't like this very much because framebuffer modifiers are a much > more generic solution, but all of the other options above are pretty > much just as ugly
Re: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes
On Mon, Aug 17, 2020 at 02:23:47AM -0400, Marek Olšák wrote: > On Wed, Aug 12, 2020 at 9:54 AM Daniel Vetter wrote: > > > On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote: > > > There are a few cases when the flags can change, for example DCC can be > > > disabled due to a hw limitation in the 3d engine. Modifiers give the > > > misleading impression that they help with that, but they don't. They > > don't > > > really help with anything. > > > > But if that happens, how do you tell the other side that it needs to > > sample new flags? Does that just happen all the time? > > > > Also do the DDC state changes happen for shared buffers too? > > > > I thought we were only talking about shared buffers. > > If the other side is only a consumer and the producer must disable DCC, the > producer decompresses DCC and then disables it and updates the BO flags. > The consumer doesn't need the new flags, because even if DCC stays enabled > in the consumer, it's in a decompressed state (it has no effect). Only the > producer knows it's disabled, and any new consumer will also know it when > it queries the latest BO flags. > > It doesn't work if both sides use writes, because it's not communicated > that DCC is disabled (BO flags are queried only once). This hasn't been a > problem so far. > > Is there a way to disable DCC correctly and safely across processes? Yes. > So why don't we do it? Because it would add more GPU overhead. Yeah but in this case you can get away with just sampling the bo flags once (which is what you're doing), so doing that at addfb time should be perfectly fine. Ofc you might waste a bit of $something also scanning out the compression metadata (which tells the hw that it's all uncompressed), but that doesn't seem to be a problem for you. So treating the legacy bo flags as invariant for shared buffers should be perfectly fine. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v3] drm/nouveau: utilize subconnector property for DP
Hi Ben Skeggs,
Gentle Reminder, Can you please take a look at the patch and provide your ack.
Thanks
Jeevan B
>-Original Message-
>From: B, Jeevan
>Sent: Sunday, August 16, 2020 12:22 PM
>To: nouv...@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: bske...@redhat.com; airl...@redhat.com;
>maarten.lankho...@linux.intel.com; Nikula, Jani ;
>Shankar, Uma ; Oleg Vasilev
>; B, Jeevan
>Subject: [v3] drm/nouveau: utilize subconnector property for DP
>
>From: Oleg Vasilev
>
>Since DP-specific information is stored in driver's structures, every driver
>needs to implement subconnector property by itself.
>
>v2: rebase
>
>v3: renamed a function call
>
>Cc: Ben Skeggs
>Cc: nouv...@lists.freedesktop.org
>Signed-off-by: Jeevan B
>Signed-off-by: Oleg Vasilev
>Reviewed-by: Emil Velikov
>---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
> drivers/gpu/drm/nouveau/nouveau_dp.c| 9 +
> drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
> 3 files changed, 23 insertions(+)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
>b/drivers/gpu/drm/nouveau/nouveau_connector.c
>index 7674025..955afed 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
>@@ -654,6 +654,17 @@ nouveau_connector_detect(struct drm_connector
>*connector, bool force)
> pm_runtime_mark_last_busy(dev->dev);
> pm_runtime_put_autosuspend(dev->dev);
>
>+ if (connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort ||
>+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>+ enum drm_mode_subconnector subconnector =
>+DRM_MODE_SUBCONNECTOR_Unknown;
>+
>+ if (conn_status == connector_status_connected &&
>nv_encoder)
>+ subconnector = nv_encoder->dp.subconnector;
>+ drm_object_property_set_value(&connector->base,
>+ connector->dev-
>>mode_config.dp_subconnector_property,
>+ subconnector);
>+ }
>+
> return conn_status;
> }
>
>@@ -1390,6 +1401,8 @@ nouveau_connector_create(struct drm_device *dev,
> kfree(nv_connector);
> return ERR_PTR(ret);
> }
>+
>+
> drm_connector_attach_dp_subconnector_property(connector);
> funcs = &nouveau_connector_funcs;
> break;
> default:
>diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
>b/drivers/gpu/drm/nouveau/nouveau_dp.c
>index 8a0f799..3eff884 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
>@@ -62,6 +62,7 @@ nouveau_dp_detect(struct nouveau_encoder
>*nv_encoder)
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct nvkm_i2c_aux *aux;
> u8 dpcd[8];
>+ u8 port_cap[DP_MAX_DOWNSTREAM_PORTS] = {};
> int ret;
>
> aux = nv_encoder->aux;
>@@ -72,6 +73,14 @@ nouveau_dp_detect(struct nouveau_encoder
>*nv_encoder)
> if (ret)
> return ret;
>
>+ if (dpcd[DP_DPCD_REV] > 0x10) {
>+ ret = nvkm_rdaux(aux, DP_DOWNSTREAM_PORT_0,
>+ port_cap, DP_MAX_DOWNSTREAM_PORTS);
>+ if (ret)
>+ memset(port_cap, 0,
>DP_MAX_DOWNSTREAM_PORTS);
>+ }
>+ nv_encoder->dp.subconnector = drm_dp_subconnector_type(dpcd,
>+port_cap);
>+
> nv_encoder->dp.link_bw = 27000 * dpcd[1];
> nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
>b/drivers/gpu/drm/nouveau/nouveau_encoder.h
>index a72c412..49b5c10 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
>+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
>@@ -64,6 +64,7 @@ struct nouveau_encoder {
> struct nv50_mstm *mstm;
> int link_nr;
> int link_bw;
>+ enum drm_mode_subconnector subconnector;
> } dp;
> };
>
>--
>2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/19] drm/msm: show process names in gem_describe
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> In $debugfs/gem we already show any vma(s) associated with an object.
> Also show process names if the vma's address space is a per-process
> address space.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 25 +
> drivers/gpu/drm/msm/msm_gem.h | 5 +
> drivers/gpu/drm/msm/msm_gem_vma.c | 1 +
> drivers/gpu/drm/msm/msm_gpu.c | 8 +---
> drivers/gpu/drm/msm/msm_gpu.h | 2 +-
> 6 files changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 8e70d220bba8..8d5c4f98c332 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -597,7 +597,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> kref_init(&ctx->ref);
> msm_submitqueue_init(dev, ctx);
>
> - ctx->aspace = msm_gpu_create_private_address_space(priv->gpu);
> + ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
> file->driver_priv = ctx;
>
> return 0;
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 3cb7aeb93fd3..76a6c5271e57 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -842,11 +842,28 @@ void msm_gem_describe(struct drm_gem_object *obj,
> struct seq_file *m)
>
> seq_puts(m, " vmas:");
>
> - list_for_each_entry(vma, &msm_obj->vmas, list)
> - seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
> - vma->aspace != NULL ? vma->aspace->name : NULL,
> - vma->iova, vma->mapped ? "mapped" : "unmapped",
> + list_for_each_entry(vma, &msm_obj->vmas, list) {
> + const char *name, *comm;
> + if (vma->aspace) {
> + struct msm_gem_address_space *aspace =
> vma->aspace;
> + struct task_struct *task =
> + get_pid_task(aspace->pid, PIDTYPE_PID);
> + if (task) {
> + comm = kstrdup(task->comm, GFP_KERNEL);
> + } else {
> + comm = NULL;
> + }
> + name = aspace->name;
> + } else {
> + name = comm = NULL;
> + }
> + seq_printf(m, " [%s%s%s: aspace=%p,
> %08llx,%s,inuse=%d]",
> + name, comm ? ":" : "", comm ? comm : "",
> + vma->aspace, vma->iova,
> + vma->mapped ? "mapped" : "unmapped",
> vma->inuse);
> + kfree(comm);
> + }
>
> seq_puts(m, "\n");
> }
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 9c573c4269cb..7b1c7a5f8eef 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -24,6 +24,11 @@ struct msm_gem_address_space {
> spinlock_t lock; /* Protects drm_mm node allocation/removal */
> struct msm_mmu *mmu;
> struct kref kref;
> +
> + /* For address spaces associated with a specific process, this
> + * will be non-NULL:
> + */
> + struct pid *pid;
> };
>
> struct msm_gem_vma {
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
> b/drivers/gpu/drm/msm/msm_gem_vma.c
> index 29cc1305cf37..80a8a266d68f 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -17,6 +17,7 @@ msm_gem_address_space_destroy(struct kref *kref)
> drm_mm_takedown(&aspace->mm);
> if (aspace->mmu)
> aspace->mmu->funcs->destroy(aspace->mmu);
> + put_pid(aspace->pid);
> kfree(aspace);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 951850804d77..ac8961187a73 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -825,10 +825,9 @@ static int get_clocks(struct platform_device *pdev,
> struct msm_gpu *gpu)
>
> /* Return a new address space for a msm_drm_private instance */
> struct msm_gem_address_space *
> -msm_gpu_create_private_address_space(struct msm_gpu *gpu)
> +msm_gpu_create_private_address_space(struct msm_gpu *gpu, struct task_struct
> *task)
> {
> struct msm_gem_address_space *aspace = NULL;
> -
> if (!gpu)
> return NULL;
>
> @@ -836,8 +835,11 @@ msm_gpu_create_private_address_space(struct msm_gpu *gpu)
>* If the target doesn't support private address spaces then return
>* the global one
>*/
> - if (gpu->funcs->create_priva
Re: [PATCH v6 2/2] drm: panel: Add novatek nt36672a panel driver
On Mon 31 Aug 13:02 UTC 2020, Sumit Semwal wrote: > Novatek NT36672a is a generic DSI IC that drives command and video mode > panels. Add the driver for it. > > Right now adding support for some Poco F1 phones that have an LCD panel > from Tianma connected with this IC, with a resolution of 1080x2246 that > operates in DSI video mode. > > During testing, Benni Steini helped us fix > the reset sequence timing (from 10ms to 20ms), to get the bootanimation > to work on Android. > > With current AOSP, we need to increase it to 200ms - this seems to be a > safe high value to avoid a white screen occasionally. > > Signed-off-by: Sumit Semwal > Cc: Benni Steini > > --- > v2: increase reset sequence timing to a safe 200ms > v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate > vrefresh on demand. Update for it. > v5: Fixed review comments from Sam: > - rebased on top of drm-misc-next >remove return of drm_panel_add() >remove drm_panel_detach() > - renamed the panel driver file to reflect that this is a novatek >nt36672a display driver and not only for tianma panels. >Adjusted some internal names also to reflect the same. > - corrected changelog to add info about the generic Novatek DSI IC > - corrected compatible string accordingly > - removed pinctrl > - used drm_panel* API for prepare/unprepare/disable/remove > v6: Fixed few review comments on v5 from Sam: > - add dev_err_probe() support > - move DRM_* error printing to dev_err() > - removed a few unnecessary bits > --- > MAINTAINERS | 7 + > drivers/gpu/drm/panel/Kconfig | 10 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-novatek-nt36672a.c| 740 ++ > 4 files changed, 758 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01fb9ee6b951..aeecade2d65f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F: Documentation/devicetree/bindings/display/ste,mcde.txt > F: drivers/gpu/drm/mcde/ > > +DRM DRIVER FOR TIANMA NT36672A PANELS > +M: Sumit Semwal > +S: Maintained > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: > Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml > +F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c > + > DRM DRIVER FOR TDFX VIDEO CARDS > S: Orphan / Obsolete > F: drivers/gpu/drm/tdfx/ > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 8d97d07c5871..02600f12a063 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 > around the Novatek NT35510 display controller, such as some > Hydis panels. > > +config DRM_PANEL_NOVATEK_NT36672A > + tristate "Novatek NT36672A DSI panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + help > + Say Y here if you want to enable support for the panels built > + around the Novatek NT36672A display controller, such as some > + Tianma panels used in a few Xiaomi Poco F1 mobile phone. > + > config DRM_PANEL_NOVATEK_NT39016 > tristate "Novatek NT39016 RGB/SPI panel" > depends on OF && SPI > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index 15a4e7752951..4a36eb45f670 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o > +obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o > obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o > obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o > diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > new file mode 100644 > index ..675e9d52f3c4 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > @@ -0,0 +1,740 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2020 Linaro Ltd > + * Author: Sumit Semwal > + * > + * This driver is for the DSI interface to panels using the NT36672A display > driver IC > + * from Novatek. > + * Currently supported are the Tianma FHD+ panels found in some Xiaomi > phones, including > + * some variants of the Poco F1 phone. > + * > + * Panels using the Novatek NT37762A IC should add appropriate config
Re: [PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control
Hi Hoegeun,
It looks good to me. But, just one comment.
On 9/1/20 1:07 PM, Hoegeun Kwon wrote:
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
>
> Signed-off-by: Hoegeun Kwon
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 95ec5eedea39..eb3192d1fd86 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -80,6 +80,7 @@
> # define VC4_HD_M_ENABLE BIT(0)
>
> #define CEC_CLOCK_FREQ 4
> +#define VC4_HSM_MID_CLOCK 149985000
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
> drm_encoder *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
> clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder)
> return;
> }
>
> + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
> + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
> + if (ret) {
> + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
Generally, enable the clock before using clk and then change the clock rate.
I think that you better to change the order between clk_prepare_enable and
clk_set_rate.
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->audio_clock);
> }
>
> + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> + DRM_ERROR("Failed to get pixel bvb clock\n");
> + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> + }
> +
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(vc4_hdmi->reset)) {
> DRM_ERROR("Failed to get HDMI reset line\n");
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0806c6d9f24e..63c6f8bddf1d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -147,6 +147,7 @@ struct vc4_hdmi {
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> struct clk *audio_clock;
> + struct clk *pixel_bvb_clock;
>
> struct reset_control *reset;
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/19] iommu: add private interface for adreno-smmu
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> This interface will be used for drm/msm to coordinate with the
> qcom_adreno_smmu_impl to enable/disable TTBR0 translation.
>
> Once TTBR0 translation is enabled, the GPU's CP (Command Processor)
> will directly switch TTBR0 pgtables (and do the necessary TLB inv)
> synchronized to the GPU's operation. But help from the SMMU driver
> is needed to initially bootstrap TTBR0 translation, which cannot be
> done from the GPU.
>
> Since this is a very special case, a private interface is used to
> avoid adding highly driver specific things to the public iommu
> interface.
>
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
> ---
> include/linux/adreno-smmu-priv.h | 36
> 1 file changed, 36 insertions(+)
> create mode 100644 include/linux/adreno-smmu-priv.h
>
> diff --git a/include/linux/adreno-smmu-priv.h
> b/include/linux/adreno-smmu-priv.h
> new file mode 100644
> index ..a889f28afb42
> --- /dev/null
> +++ b/include/linux/adreno-smmu-priv.h
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 Google, Inc
> + */
> +
> +#ifndef __ADRENO_SMMU_PRIV_H
> +#define __ADRENO_SMMU_PRIV_H
> +
> +#include
> +
> +/**
> + * struct adreno_smmu_priv - private interface between adreno-smmu and GPU
> + *
> + * @cookie:An opque token provided by adreno-smmu and passed
> + * back into the callbacks
> + * @get_ttbr1_cfg: Get the TTBR1 config for the GPUs context-bank
> + * @set_ttbr0_cfg: Set the TTBR0 config for the GPUs context bank. A
> + * NULL config disables TTBR0 translation, otherwise
> + * TTBR0 translation is enabled with the specified cfg
> + *
> + * The GPU driver (drm/msm) and adreno-smmu work together for controlling
> + * the GPU's SMMU instance. This is by necessity, as the GPU is directly
> + * updating the SMMU for context switches, while on the other hand we do
> + * not want to duplicate all of the initial setup logic from arm-smmu.
> + *
> + * This private interface is used for the two drivers to coordinate. The
> + * cookie and callback functions are populated when the GPU driver attaches
> + * it's domain.
> + */
> +struct adreno_smmu_priv {
> +const void *cookie;
> +const struct io_pgtable_cfg *(*get_ttbr1_cfg)(const void *cookie);
> +int (*set_ttbr0_cfg)(const void *cookie, const struct io_pgtable_cfg
> *cfg);
> +};
> +
> +#endif /* __ADRENO_SMMU_PRIV_H */
> \ No newline at end of file
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
> From: Rob Clark
>
> Currently it doesn't matter, since we free the ctx immediately. But
> when we start refcnt'ing the ctx, we don't want old dangling list
> entries to hang around.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> b/drivers/gpu/drm/msm/msm_submitqueue.c
> index a1d94be7883a..90c9d84e6155 100644
> --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx)
>* No lock needed in close and there won't
>* be any more user ioctls coming our way
>*/
> - list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node)
> + list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node) {
> + list_del(&entry->node);
If you refcount ctx, what does that do for the entries in the submit
queue?
"entry" here is kref'ed, but you're popping it off the list regardless
of the put ends up freeing the object or not - which afaict would mean
leaking the object.
On the other hand, with the current implementation an object with higher
refcount with adjacent objects of single refcount would end up with
dangling pointers after the put. So in itself this change seems like a
net gain, but I'm wondering about the plan described in the commit
message.
Regards,
Bjorn
> msm_submitqueue_put(entry);
> + }
> }
>
> int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
> *ctx,
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/4] MAINTAINERS: add files for Mediatek DRM drivers
On Tue, 2020-09-01 at 00:02 +0800, Chun-Kuang Hu wrote: > Hi, Chunfeng: > > Chunfeng Yun 於 2020年8月31日 週一 上午9:50寫道： > > > > On Sun, 2020-08-23 at 09:48 +0800, Chun-Kuang Hu wrote: > > > Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to > > > drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers' > > > information. > > > > > > Signed-off-by: Chun-Kuang Hu > > > Reviewed-by: Matthias Brugger > > > --- > > > MAINTAINERS | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index deaafb617361..191bacf02209 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -5793,6 +5793,7 @@ L: dri-devel@lists.freedesktop.org > > > S: Supported > > > F: Documentation/devicetree/bindings/display/mediatek/ > > > F: drivers/gpu/drm/mediatek/ > > > +F: drivers/phy/mediatek/phy-mtk-hdmi* > > > > > > DRM DRIVERS FOR NVIDIA TEGRA > > > M: Thierry Reding > > > > Reviewed-by: Chunfeng Yun > > > > Could you give an 'Acked-by' tag on this patch? So I could apply the > whole series into my tree. Acked-by: Chunfeng Yun Thanks > > Regards, > Chun-Kuang. > > > Thanks > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/1] drm/bridge: ps8640: Rework power state handling
Hi Enric,
On Thu, 27 Aug 2020 10:59:11 +0200
Enric Balletbo i Serra wrote:
> The get_edid() callback can be triggered anytime by an ioctl, i.e
>
> drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
> -> ps8640_bridge_get_edid
>
> Actually if the bridge pre_enable() function was not called before
> get_edid(), the driver will not be able to get the EDID properly and
> display will not work until a second get_edid() call is issued and if
> pre_enable() is called before. The side effect of this, for example,
> is that you see anything when `Frecon` starts, neither the splash
> screen, until the graphical session manager starts.
>
> To fix this we need to make sure that all we need is enabled before
> reading the EDID. This means the following:
>
> 1. If get_edid() is called before having the device powered we need to
>power on the device. In such case, the driver will power off again
> the device.
>
> 2. If get_edid() is called after having the device powered, all should
>just work. We added a powered flag in order to avoid recurrent
> calls to ps8640_bridge_poweron() and unneeded delays.
>
> 3. This seems to be specific for this device, but we need to make sure
>the panel is powered on before do a power on cycle on this device.
>Otherwise the device fails to retrieve the EDID.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v3:
> - Make poweron/poweroff and pre_enable/post_disable reverse one to
> each other (Sam Ravnborg)
>
> Changes in v2:
> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam
> Ravnborg)
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 68
> ++ 1 file changed, 58 insertions(+), 10
> deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c index
> 9f7b7a9c53c5..7bd0affa057a 100644 ---
> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -65,6 +65,7 @@ struct
> ps8640 { struct regulator_bulk_data supplies[2];
> struct gpio_desc *gpio_reset;
> struct gpio_desc *gpio_powerdown;
> + bool powered;
> };
>
> static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct
> ps8640 *ps_bridge, return 0;
> }
>
> -static void ps8640_pre_enable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
> {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
> unsigned long timeout;
> int ret, status;
>
> + if (ps_bridge->powered)
> + return;
> +
> ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
> ps_bridge->supplies);
> if (ret < 0) {
> @@ -152,10 +155,6 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) goto err_regulators_disable;
> }
>
> - ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
> - if (ret)
> - goto err_regulators_disable;
> -
> /* Switch access edp panel's edid through i2c */
> ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
> I2C_BYPASS_EN);
> @@ -164,6 +163,8 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) goto err_regulators_disable;
> }
>
> + ps_bridge->powered = true;
> +
> return;
>
> err_regulators_disable:
> @@ -171,12 +172,12 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) ps_bridge->supplies);
> }
>
> -static void ps8640_post_disable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
> {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> int ret;
>
> - ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (!ps_bridge->powered)
> + return;
>
> gpiod_set_value(ps_bridge->gpio_reset, 1);
> gpiod_set_value(ps_bridge->gpio_powerdown, 1);
> @@ -184,6 +185,28 @@ static void ps8640_post_disable(struct
> drm_bridge *bridge) ps_bridge->supplies);
> if (ret < 0)
> DRM_ERROR("cannot disable regulators %d\n", ret);
> +
> + ps_bridge->powered = false;
> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + int ret;
> +
> + ps8640_bridge_poweron(ps_bridge);
> +
> + ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
> + if (ret < 0)
> + ps8640_bridge_poweroff(ps_bridge);
> +}
> +
> +static void ps8640_post_disable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +
> + ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + ps8640_bridge_poweroff(ps_bridge);
> }
>
> static int ps8640_bridge_attach(struct drm_bridge *bridge,
>
Re: [PATCH v2 2/3] drm: bridge: add support for lontium LT9611UXC bridge
On 28/08/2020 22:58, Sam Ravnborg wrote:
Hi Dmitry
On Fri, Aug 28, 2020 at 06:49:05PM +0300, Dmitry Baryshkov wrote:
Add support for Lontium LT9611UXC HDMI bridge. Lontium LT9611UXC is a
DSI to HDMI bridge which supports two DSI ports and I2S port as an input
and HDMI port as output. Despite name being similar to LT9611, these
devices are different enough to warrant separate driver.
Signed-off-by: Dmitry Baryshkov
I have browsed the driver - most looks good but the way modes are
handled looks fishy.
The code either relies on edid or modes returned by a panel-timings
node. The panel-timings node seems to be used to override the edid info.
We do not need this in any other bridge driver today - and thus it is
questionaable if this driver needs it. If it is needed then please
document the rationale behind it - in the source code.
The binding does not exaplin anything about a panel-timings node.
If the panel-timins stuff is not needed, then remember to drop include
files that are no logner used.
Fine with me, I'll drop panel-timings then. If there are issues with
EDID handling, we can readd them back later.
And then there is mode_valid which uses a set of modes obtained from
a static list which also looks strange.
The last part can also be found in lontium-lt9611.c but that does
not make it correct.
The lt9611uxc firmware supports only a fixed set of modes. Thus
lt9611uxc driver has to check if the mode is supported by the fw.
Unsupported modes would result in HDMI display not receiving valid signal.
Please see other bridge drivers.
The extra patch that makes connector creation optinal should be
merged with the first patch - there is no gain to split it in two.
Ok, I'll squash it.
There was also a few style issues, see comments in the following.
Looks forward to see a new revision.
Sam
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 774 +
3 files changed, 788 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611uxc.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e11af4e9f63..8343fb054652 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -61,6 +61,19 @@ config DRM_LONTIUM_LT9611
HDMI signals
Please say Y if you have such hardware.
+config DRM_LONTIUM_LT9611UXC
+ tristate "Lontium LT9611UXC DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611UXC DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c589a6a7cbe1..306850a5899b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
new file mode 100644
index ..77c5aa5c6ad7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -0,0 +1,774 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
Sort this block
+
+#define EDID_BLOCK_SIZE128
+#define EDID_NUM_BLOCKS2
+
+struct lt9611uxc {
+ struct device *dev;
+ struct drm_bridge bridge;
+
+ struct regmap *regmap;
+ /* Protects all accesses to registers by stopping the on-chip MCU */
+ struct mutex ocm_lock;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ bool hpd_supporte
Re: [PATCH 15/19] drm/msm: Add support for private address space instances
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add support for allocating private address space instances. Targets that
> support per-context pagetables should implement their own function to
> allocate private address spaces.
>
> The default will return a pointer to the global address space.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 13 +++--
> drivers/gpu/drm/msm/msm_drv.h | 5 +
> drivers/gpu/drm/msm/msm_gem_vma.c | 9 +
> drivers/gpu/drm/msm/msm_gpu.c | 22 ++
> drivers/gpu/drm/msm/msm_gpu.h | 5 +
> 5 files changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 01845a3b8d52..8e70d220bba8 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -597,7 +597,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> kref_init(&ctx->ref);
> msm_submitqueue_init(dev, ctx);
>
> - ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
> + ctx->aspace = msm_gpu_create_private_address_space(priv->gpu);
> file->driver_priv = ctx;
>
> return 0;
> @@ -780,18 +780,19 @@ static int msm_ioctl_gem_cpu_fini(struct drm_device
> *dev, void *data,
> }
>
> static int msm_ioctl_gem_info_iova(struct drm_device *dev,
> - struct drm_gem_object *obj, uint64_t *iova)
> + struct drm_file *file, struct drm_gem_object *obj,
> + uint64_t *iova)
> {
> - struct msm_drm_private *priv = dev->dev_private;
> + struct msm_file_private *ctx = file->driver_priv;
>
> - if (!priv->gpu)
> + if (!ctx->aspace)
> return -EINVAL;
>
> /*
>* Don't pin the memory here - just get an address so that userspace can
>* be productive
>*/
> - return msm_gem_get_iova(obj, priv->gpu->aspace, iova);
> + return msm_gem_get_iova(obj, ctx->aspace, iova);
> }
>
> static int msm_ioctl_gem_info(struct drm_device *dev, void *data,
> @@ -830,7 +831,7 @@ static int msm_ioctl_gem_info(struct drm_device *dev,
> void *data,
> args->value = msm_gem_mmap_offset(obj);
> break;
> case MSM_INFO_GET_IOVA:
> - ret = msm_ioctl_gem_info_iova(dev, obj, &args->value);
> + ret = msm_ioctl_gem_info_iova(dev, file, obj, &args->value);
> break;
> case MSM_INFO_SET_NAME:
> /* length check should leave room for terminating null: */
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 4561bfb5e745..2ca9c3c03845 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -249,6 +249,10 @@ int msm_gem_map_vma(struct msm_gem_address_space *aspace,
> void msm_gem_close_vma(struct msm_gem_address_space *aspace,
> struct msm_gem_vma *vma);
>
> +
> +struct msm_gem_address_space *
> +msm_gem_address_space_get(struct msm_gem_address_space *aspace);
> +
> void msm_gem_address_space_put(struct msm_gem_address_space *aspace);
>
> struct msm_gem_address_space *
> @@ -434,6 +438,7 @@ static inline void __msm_file_private_destroy(struct kref
> *kref)
> struct msm_file_private *ctx = container_of(kref,
> struct msm_file_private, ref);
>
> + msm_gem_address_space_put(ctx->aspace);
> kfree(ctx);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
> b/drivers/gpu/drm/msm/msm_gem_vma.c
> index 5f6a11211b64..29cc1305cf37 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -27,6 +27,15 @@ void msm_gem_address_space_put(struct
> msm_gem_address_space *aspace)
> kref_put(&aspace->kref, msm_gem_address_space_destroy);
> }
>
> +struct msm_gem_address_space *
> +msm_gem_address_space_get(struct msm_gem_address_space *aspace)
> +{
> + if (!IS_ERR_OR_NULL(aspace))
> + kref_get(&aspace->kref);
> +
> + return aspace;
> +}
> +
> /* Actually unmap memory for the vma */
> void msm_gem_purge_vma(struct msm_gem_address_space *aspace,
> struct msm_gem_vma *vma)
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index e1a3cbe25a0c..951850804d77 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -823,6 +823,28 @@ static int get_clocks(struct platform_device *pdev,
> struct msm_gpu *gpu)
> return 0;
> }
>
> +/* Return a new address space for a msm_drm_private instance */
> +struct msm_gem_address_space *
> +msm_gpu_create_private_address_space(struct msm_gpu *gpu)
> +{
> + struct msm_gem_address_space *aspace = NULL;
> +
> + if (!gpu)
> + return NULL;
> +
> + /*
> + * If the target doesn't support private address spaces then return
> + * the global one
> +
Re: [PATCH 13/19] drm/msm: Set the global virtual address range from the IOMMU domain
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Use the aperture settings from the IOMMU domain to set up the virtual
> address range for the GPU. This allows us to transparently deal with
> IOMMU side features (like split pagetables).
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
> drivers/gpu/drm/msm/msm_iommu.c | 7 +++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 533a34b4cce2..34e6242c1767 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -192,9 +192,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> struct iommu_domain *iommu = iommu_domain_alloc(&platform_bus_type);
> struct msm_mmu *mmu = msm_iommu_new(&pdev->dev, iommu);
> struct msm_gem_address_space *aspace;
> + u64 start, size;
>
> - aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> - 0x - SZ_16M);
> + /*
> + * Use the aperture start or SZ_16M, whichever is greater. This will
> + * ensure that we align with the allocated pagetable range while still
> + * allowing room in the lower 32 bits for GMEM and whatnot
> + */
> + start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
> + size = iommu->geometry.aperture_end - start + 1;
> +
> + aspace = msm_gem_address_space_create(mmu, "gpu",
> + start & GENMASK(48, 0), size);
>
> if (IS_ERR(aspace) && !IS_ERR(mmu))
> mmu->funcs->destroy(mmu);
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 3a381a9674c9..1b6635504069 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -36,6 +36,10 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t
> iova,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> size_t ret;
>
> + /* The arm-smmu driver expects the addresses to be sign extended */
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> WARN_ON(!ret);
>
> @@ -46,6 +50,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t
> iova, size_t len)
> {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> iommu_unmap(iommu->domain, iova, len);
>
> return 0;
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/4] phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder
On Tue, 2020-09-01 at 00:01 +0800, Chun-Kuang Hu wrote:
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年8月31日 週一 上午9:48寫道：
> >
> > On Mon, 2020-08-31 at 07:03 +0800, Chun-Kuang Hu wrote:
> > > Hi, Chunfeng & Kishon:
> > >
> > > How do you feel about this patch?
> > It's fine to me,
> >
> > Reviewed-by: Chunfeng Yun
> >
>
> Could you give an 'Acked-by' tag on this patch? So I could apply the
> whole series into my tree.
Acked-by: Chunfeng Yun
Thanks
>
> Regards,
> Chun-Kuang.
>
> > Thanks a lot
> >
> > >
> > > Regards,
> > > Chun-Kuang.
> > >
> > > Chun-Kuang Hu 於 2020年8月23日 週日 上午9:48寫道：
> > > >
> > > > From: CK Hu
> > > >
> > > > mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> > > > more suitable to place a phy driver into phy driver folder, so move
> > > > mtk_hdmi_phy driver into phy driver folder.
> > > >
> > > > Signed-off-by: CK Hu
> > > > Signed-off-by: Chun-Kuang Hu
> > > > ---
> > > > drivers/gpu/drm/mediatek/Kconfig | 7 ---
> > > > drivers/gpu/drm/mediatek/Makefile | 6 --
> > > > drivers/phy/mediatek/Kconfig | 7 +++
> > > > drivers/phy/mediatek/Makefile | 5 +
> > > > .../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
> > > > .../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
> > > > .../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
> > > > .../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
> > > > 8 files changed, 15 insertions(+), 16 deletions(-)
> > > > rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
> > > > phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
> > > > rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
> > > > phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
> > > > rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
> > > > phy/mediatek/phy-mtk-hdmi.c} (99%)
> > > > rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
> > > > phy/mediatek/phy-mtk-hdmi.h} (100%)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/Kconfig
> > > > b/drivers/gpu/drm/mediatek/Kconfig
> > > > index 6363f2c1cdbc..65cd03a4be29 100644
> > > > --- a/drivers/gpu/drm/mediatek/Kconfig
> > > > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > > > @@ -27,10 +27,3 @@ config DRM_MEDIATEK_HDMI
> > > > select PHY_MTK_HDMI
> > > > help
> > > > DRM/KMS HDMI driver for Mediatek SoCs
> > > > -
> > > > -config PHY_MTK_HDMI
> > > > - tristate "MediaTek HDMI-PHY Driver"
> > > > - depends on ARCH_MEDIATEK && OF
> > > > - select GENERIC_PHY
> > > > - help
> > > > - Support HDMI PHY for Mediatek SoCs.
> > > > diff --git a/drivers/gpu/drm/mediatek/Makefile
> > > > b/drivers/gpu/drm/mediatek/Makefile
> > > > index fcbef23aa6ce..77b0fd86063d 100644
> > > > --- a/drivers/gpu/drm/mediatek/Makefile
> > > > +++ b/drivers/gpu/drm/mediatek/Makefile
> > > > @@ -22,9 +22,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> > > > mtk_hdmi_ddc.o
> > > >
> > > > obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> > > > -
> > > > -phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
> > > > -mtk_mt2701_hdmi_phy.o \
> > > > -mtk_mt8173_hdmi_phy.o
> > > > -
> > > > -obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > > > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > > > index dee757c957f2..50c5e9306e19 100644
> > > > --- a/drivers/phy/mediatek/Kconfig
> > > > +++ b/drivers/phy/mediatek/Kconfig
> > > > @@ -35,3 +35,10 @@ config PHY_MTK_XSPHY
> > > > Enable this to support the SuperSpeedPlus XS-PHY transceiver
> > > > for
> > > > USB3.1 GEN2 controllers on MediaTek chips. The driver supports
> > > > multiple USB2.0, USB3.1 GEN2 ports.
> > > > +
> > > > +config PHY_MTK_HDMI
> > > > + tristate "MediaTek HDMI-PHY Driver"
> > > > + depends on ARCH_MEDIATEK && OF
> > > > + select GENERIC_PHY
> > > > + help
> > > > + Support HDMI PHY for Mediatek SoCs.
> > > > diff --git a/drivers/phy/mediatek/Makefile
> > > > b/drivers/phy/mediatek/Makefile
> > > > index 08a8e6a97b1e..6325e38709ed 100644
> > > > --- a/drivers/phy/mediatek/Makefile
> > > > +++ b/drivers/phy/mediatek/Makefile
> > > > @@ -6,3 +6,8 @@
> > > > obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> > > > obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> > > > obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o
> > > > +
> > > > +phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> > > > +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> > > > +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> > > > +obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > > b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > > > similarity i
Re: [PATCH v3 1/1] drm/bridge: ps8640: Rework power state handling
Hi Bilal,
On 31/8/20 11:32, Bilal Wasim wrote:
>
> Hi Enric,
>
> On Thu, 27 Aug 2020 10:59:11 +0200
> Enric Balletbo i Serra wrote:
>
>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>
>> drm_mode_getconnector (ioctl)
>> -> drm_helper_probe_single_connector_modes
>>-> drm_bridge_connector_get_modes
>> -> ps8640_bridge_get_edid
>>
>> Actually if the bridge pre_enable() function was not called before
>> get_edid(), the driver will not be able to get the EDID properly and
>> display will not work until a second get_edid() call is issued and if
>> pre_enable() is called before. The side effect of this, for example,
>> is that you see anything when `Frecon` starts, neither the splash
>> screen, until the graphical session manager starts.
>>
>> To fix this we need to make sure that all we need is enabled before
>> reading the EDID. This means the following:
>>
>> 1. If get_edid() is called before having the device powered we need to
>>power on the device. In such case, the driver will power off again
>> the device.
>>
>> 2. If get_edid() is called after having the device powered, all should
>>just work. We added a powered flag in order to avoid recurrent
>> calls to ps8640_bridge_poweron() and unneeded delays.
>>
>> 3. This seems to be specific for this device, but we need to make sure
>>the panel is powered on before do a power on cycle on this device.
>>Otherwise the device fails to retrieve the EDID.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>>
>> Changes in v3:
>> - Make poweron/poweroff and pre_enable/post_disable reverse one to
>> each other (Sam Ravnborg)
>>
>> Changes in v2:
>> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam
>> Ravnborg)
>>
>> drivers/gpu/drm/bridge/parade-ps8640.c | 68
>> ++ 1 file changed, 58 insertions(+), 10
>> deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
>> b/drivers/gpu/drm/bridge/parade-ps8640.c index
>> 9f7b7a9c53c5..7bd0affa057a 100644 ---
>> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
>> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -65,6 +65,7 @@ struct
>> ps8640 { struct regulator_bulk_data supplies[2];
>> struct gpio_desc *gpio_reset;
>> struct gpio_desc *gpio_powerdown;
>> +bool powered;
>> };
>>
>> static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
>> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct
>> ps8640 *ps_bridge, return 0;
>> }
>>
>> -static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>> {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
>> unsigned long timeout;
>> int ret, status;
>>
>> +if (ps_bridge->powered)
>> +return;
>> +
>> ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>> ps_bridge->supplies);
>> if (ret < 0) {
>> @@ -152,10 +155,6 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge) goto err_regulators_disable;
>> }
>>
>> -ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
>> -if (ret)
>> -goto err_regulators_disable;
>> -
>> /* Switch access edp panel's edid through i2c */
>> ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
>> I2C_BYPASS_EN);
>> @@ -164,6 +163,8 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge) goto err_regulators_disable;
>> }
>>
>> +ps_bridge->powered = true;
>> +
>> return;
>>
>> err_regulators_disable:
>> @@ -171,12 +172,12 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge) ps_bridge->supplies);
>> }
>>
>> -static void ps8640_post_disable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
>> {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> int ret;
>>
>> -ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>> +if (!ps_bridge->powered)
>> +return;
>>
>> gpiod_set_value(ps_bridge->gpio_reset, 1);
>> gpiod_set_value(ps_bridge->gpio_powerdown, 1);
>> @@ -184,6 +185,28 @@ static void ps8640_post_disable(struct
>> drm_bridge *bridge) ps_bridge->supplies);
>> if (ret < 0)
>> DRM_ERROR("cannot disable regulators %d\n", ret);
>> +
>> +ps_bridge->powered = false;
>> +}
>> +
>> +static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +{
>> +struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> +int ret;
>> +
>> +ps8640_bridge_poweron(ps_bridge);
>> +
>> +ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
>> +if (ret < 0)
>> +ps8640_bridge_poweroff(ps_bridge);
>> +}
>> +
>> +static void ps8640_post_disable(struct drm_bridge *bridge)
>> +{
>> +struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> +
>> +ps8640_bridge_vdo_co
Re: [PATCH 18/19] iommu/arm-smmu: add a way for implementations to influence SCTLR
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
> pending translations are not terminated on iova fault. Otherwise
> a terminated CP read could hang the GPU by returning invalid
> command-stream data.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 6 ++
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 3 +++
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 3 +++
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 5640d9960610..2aa6249050ff 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -127,6 +127,12 @@ static int qcom_adreno_smmu_init_context(struct
> arm_smmu_domain *smmu_domain,
> (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH64))
> pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_ARM_TTBR1;
>
> + /*
> + * On the GPU device we want to process subsequent transactions after a
> + * fault to keep the GPU from hanging
> + */
> + smmu_domain->cfg.sctlr_set |= ARM_SMMU_SCTLR_HUPCF;
> +
> /*
>* Initialize private interface with GPU:
>*/
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index e63a480d7f71..bbec5793faf8 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -617,6 +617,9 @@ void arm_smmu_write_context_bank(struct arm_smmu_device
> *smmu, int idx)
> if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
> reg |= ARM_SMMU_SCTLR_E;
>
> + reg |= cfg->sctlr_set;
> + reg &= ~cfg->sctlr_clr;
> +
> arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, reg);
> }
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index cd75a33967bb..2df3a70a8a41 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -144,6 +144,7 @@ enum arm_smmu_cbar_type {
> #define ARM_SMMU_CB_SCTLR0x0
> #define ARM_SMMU_SCTLR_S1_ASIDPNEBIT(12)
> #define ARM_SMMU_SCTLR_CFCFG BIT(7)
> +#define ARM_SMMU_SCTLR_HUPCF BIT(8)
> #define ARM_SMMU_SCTLR_CFIE BIT(6)
> #define ARM_SMMU_SCTLR_CFRE BIT(5)
> #define ARM_SMMU_SCTLR_E BIT(4)
> @@ -341,6 +342,8 @@ struct arm_smmu_cfg {
> u16 asid;
> u16 vmid;
> };
> + u32 sctlr_set;/* extra bits to set in
> SCTLR */
> + u32 sctlr_clr;/* bits to mask in SCTLR
> */
> enum arm_smmu_cbar_type cbar;
> enum arm_smmu_context_fmt fmt;
> };
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/19] iommu/arm-smmu: Add support for split pagetables
On Thu 13 Aug 21:40 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Enable TTBR1 for a context bank if IO_PGTABLE_QUIRK_ARM_TTBR1 is selected
> by the io-pgtable configuration.
>
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 21 -
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 25 +++--
> 2 files changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 37d8d49299b4..976d43a7f2ff 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -552,11 +552,15 @@ static void arm_smmu_init_context_bank(struct
> arm_smmu_domain *smmu_domain,
> cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
> cb->ttbr[1] = 0;
> } else {
> - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> - cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> - cfg->asid);
> + cb->ttbr[0] = FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> + cfg->asid);
> cb->ttbr[1] = FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> - cfg->asid);
> + cfg->asid);
The old indentation seems more appropriate.
Apart from that this looks sensible.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> +
> + if (pgtbl_cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
> + cb->ttbr[1] |= pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> + else
> + cb->ttbr[0] |= pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> }
> } else {
> cb->ttbr[0] = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
> @@ -822,7 +826,14 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
>
> /* Update the domain's page sizes to reflect the page table format */
> domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap;
> - domain->geometry.aperture_end = (1UL << ias) - 1;
> +
> + if (pgtbl_cfg.quirks & IO_PGTABLE_QUIRK_ARM_TTBR1) {
> + domain->geometry.aperture_start = ~0UL << ias;
> + domain->geometry.aperture_end = ~0UL;
> + } else {
> + domain->geometry.aperture_end = (1UL << ias) - 1;
> + }
> +
> domain->geometry.force_aperture = true;
>
> /* Initialise the context bank with our page table cfg */
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 83294516ac08..f3e456893f28 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -169,10 +169,12 @@ enum arm_smmu_cbar_type {
> #define ARM_SMMU_CB_TCR 0x30
> #define ARM_SMMU_TCR_EAE BIT(31)
> #define ARM_SMMU_TCR_EPD1BIT(23)
> +#define ARM_SMMU_TCR_A1 BIT(22)
> #define ARM_SMMU_TCR_TG0 GENMASK(15, 14)
> #define ARM_SMMU_TCR_SH0 GENMASK(13, 12)
> #define ARM_SMMU_TCR_ORGN0 GENMASK(11, 10)
> #define ARM_SMMU_TCR_IRGN0 GENMASK(9, 8)
> +#define ARM_SMMU_TCR_EPD0BIT(7)
> #define ARM_SMMU_TCR_T0SZGENMASK(5, 0)
>
> #define ARM_SMMU_VTCR_RES1 BIT(31)
> @@ -350,12 +352,23 @@ struct arm_smmu_domain {
>
> static inline u32 arm_smmu_lpae_tcr(struct io_pgtable_cfg *cfg)
> {
> - return ARM_SMMU_TCR_EPD1 |
> -FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> -FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> -FIELD_PREP(ARM_SMMU_TCR_ORGN0, cfg->arm_lpae_s1_cfg.tcr.orgn) |
> -FIELD_PREP(ARM_SMMU_TCR_IRGN0, cfg->arm_lpae_s1_cfg.tcr.irgn) |
> -FIELD_PREP(ARM_SMMU_TCR_T0SZ, cfg->arm_lpae_s1_cfg.tcr.tsz);
> + u32 tcr = FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> + FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> + FIELD_PREP(ARM_SMMU_TCR_ORGN0, cfg->arm_lpae_s1_cfg.tcr.orgn) |
> + FIELD_PREP(ARM_SMMU_TCR_IRGN0, cfg->arm_lpae_s1_cfg.tcr.irgn) |
> + FIELD_PREP(ARM_SMMU_TCR_T0SZ, cfg->arm_lpae_s1_cfg.tcr.tsz);
> +
> + /*
> + * When TTBR1 is selected shift the TCR fields by 16 bits and disable
> + * translation in TTBR0
> + */
> + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1) {
> + tcr = (tcr << 16) & ~ARM_SMMU_TCR_A1;
> + tcr |= ARM_SMMU_TCR_EPD0;
> + } else
> + tcr |= ARM_SMMU_TCR_EPD1;
> +
> + return tcr;
> }
>
> static inline u32 arm_smmu_lpae_tcr2(struct io_pgtable_cfg *cfg)
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
Re: [PATCH 07/19] drm/msm: set adreno_smmu as gpu's drvdata
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> This will be populated by adreno-smmu, to provide a way for coordinating
> enabling/disabling TTBR0 translation.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 2 --
> drivers/gpu/drm/msm/msm_gpu.c | 2 +-
> drivers/gpu/drm/msm/msm_gpu.h | 6 +-
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 26664e1b30c0..58e03b20e1c7 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -417,8 +417,6 @@ static int adreno_bind(struct device *dev, struct device
> *master, void *data)
> return PTR_ERR(gpu);
> }
>
> - dev_set_drvdata(dev, gpu);
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 6aa9e04e52e7..806eb0957280 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -892,7 +892,7 @@ int msm_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
> gpu->gpu_cx = NULL;
>
> gpu->pdev = pdev;
> - platform_set_drvdata(pdev, gpu);
> + platform_set_drvdata(pdev, &gpu->adreno_smmu);
>
> msm_devfreq_init(gpu);
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 8bda7beaed4b..f91b141add75 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -7,6 +7,7 @@
> #ifndef __MSM_GPU_H__
> #define __MSM_GPU_H__
>
> +#include
> #include
> #include
> #include
> @@ -73,6 +74,8 @@ struct msm_gpu {
> struct platform_device *pdev;
> const struct msm_gpu_funcs *funcs;
>
> + struct adreno_smmu_priv adreno_smmu;
> +
> /* performance counters (hw & sw): */
> spinlock_t perf_lock;
> bool perfcntr_active;
> @@ -143,7 +146,8 @@ struct msm_gpu {
>
> static inline struct msm_gpu *dev_to_gpu(struct device *dev)
> {
> - return dev_get_drvdata(dev);
> + struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(dev);
> + return container_of(adreno_smmu, struct msm_gpu, adreno_smmu);
> }
>
> /* It turns out that all targets use the same ringbuffer size */
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/19] iommu/arm-smmu: Pass io-pgtable config to implementation specific function
On Thu 13 Aug 21:40 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Construct the io-pgtable config before calling the implementation specific
> init_context function and pass it so the implementation specific function
> can get a chance to change it before the io-pgtable is created.
>
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 ++-
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 11 ++-
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 3 ++-
> 3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index f4ff124a1967..a9861dcd0884 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -68,7 +68,8 @@ static int cavium_cfg_probe(struct arm_smmu_device *smmu)
> return 0;
> }
>
> -static int cavium_init_context(struct arm_smmu_domain *smmu_domain)
> +static int cavium_init_context(struct arm_smmu_domain *smmu_domain,
> + struct io_pgtable_cfg *pgtbl_cfg)
> {
> struct cavium_smmu *cs = container_of(smmu_domain->smmu,
> struct cavium_smmu, smmu);
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 09c42af9f31e..37d8d49299b4 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -795,11 +795,6 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> cfg->asid = cfg->cbndx;
>
> smmu_domain->smmu = smmu;
> - if (smmu->impl && smmu->impl->init_context) {
> - ret = smmu->impl->init_context(smmu_domain);
> - if (ret)
> - goto out_unlock;
> - }
>
> pgtbl_cfg = (struct io_pgtable_cfg) {
> .pgsize_bitmap = smmu->pgsize_bitmap,
> @@ -810,6 +805,12 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> .iommu_dev = smmu->dev,
> };
>
> + if (smmu->impl && smmu->impl->init_context) {
> + ret = smmu->impl->init_context(smmu_domain, &pgtbl_cfg);
> + if (ret)
> + goto out_clear_smmu;
> + }
> +
> if (smmu_domain->non_strict)
> pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index d890a4a968e8..83294516ac08 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -386,7 +386,8 @@ struct arm_smmu_impl {
> u64 val);
> int (*cfg_probe)(struct arm_smmu_device *smmu);
> int (*reset)(struct arm_smmu_device *smmu);
> - int (*init_context)(struct arm_smmu_domain *smmu_domain);
> + int (*init_context)(struct arm_smmu_domain *smmu_domain,
> + struct io_pgtable_cfg *cfg);
> void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
>int status);
> int (*def_domain_type)(struct device *dev);
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/19] drm/msm: Drop context arg to gpu->submit()
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Now that we can get the ctx from the submitqueue, the extra arg is
> redundant.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> [split out of previous patch to reduce churny noise]
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 +--
> drivers/gpu/drm/msm/msm_gem_submit.c| 2 +-
> drivers/gpu/drm/msm/msm_gpu.c | 9 -
> drivers/gpu/drm/msm/msm_gpu.h | 6 ++
> 7 files changed, 17 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 9e63a190642c..eff2439ea57b 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -43,8 +43,7 @@ static void a5xx_flush(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring)
> gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
> }
>
> -static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit)
> {
> struct msm_drm_private *priv = gpu->dev->dev_private;
> struct msm_ringbuffer *ring = submit->ring;
> @@ -57,7 +56,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> @@ -103,8 +102,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> msm_gpu_retire(gpu);
> }
>
> -static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
> @@ -114,7 +112,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
>
> if (IS_ENABLED(CONFIG_DRM_MSM_GPU_SUDO) && submit->in_rb) {
> priv->lastctx = NULL;
> - a5xx_submit_in_rb(gpu, submit, ctx);
> + a5xx_submit_in_rb(gpu, submit);
> return;
> }
>
> @@ -148,7 +146,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index c5a3e4d4c007..5eabb0109577 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -81,8 +81,7 @@ static void get_stats_counter(struct msm_ringbuffer *ring,
> u32 counter,
> OUT_RING(ring, upper_32_bits(iova));
> }
>
> -static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> unsigned int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
> struct msm_drm_private *priv = gpu->dev->dev_private;
> @@ -115,7 +114,7 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index d2dbb6968cba..533a34b4cce2 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -457,8 +457,7 @@ void adreno_recover(struct msm_gpu *gpu)
> }
> }
>
> -void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gp
Re: [PATCH v4 75/78] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
Hi Maxime,
On 7/9/20 2:42 AM, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109
> -
> 1 file changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id:
> https://protect2.fireeye.com/url?k=556aeb05-08b8fda0-556b604a-0cc47a31bee8-c3a0ebd1d22c3183&q=1&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> +$schema:
> https://protect2.fireeye.com/url?k=24fa660c-792870a9-24fbed43-0cc47a31bee8-0bf16f4fd60f0ab4&q=1&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt
> +
> +properties:
> + compatible:
> +enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
> +
> + reg:
> +items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> +items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> +description: The HDMI state machine clock
I'm not sure the following description is correct.
But, this description doesn't contain the information of audio clock.
description: The HDMI state machine and audio clock
> +
> + clock-names:
> +const: hdmi
This patch is missing the following clock information for audio clock.
const: clk-108M
> +
> + ddc:
> +allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> + Phandle of the I2C controller used for DDC EDID probing
> +
> + hpd-gpios:
> +description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
> +
> + dmas:
> +maxItems: 1
> +description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> +const: audio-rx
> +
> + resets:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> +"packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <&firmware_clocks 13>;
> +clock-names = "hdmi";
Also, this example doesn't include the instance of audio clock.
Need to edit them as following:
clock-names = "hdmi", "clk-108M";
clocks = <&firmware_clocks 13>, <&dvp 0>;
> +resets = <&dvp 0>;
> +ddc = <&ddc0>;
> +};
> +
> +...
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 3/8] drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
On 8/28/2020 11:37 AM, Viresh Kumar wrote:
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Its a little tricky to call things unconditionally for this driver, more below.
While at it, also create a label to put clkname.
Signed-off-by: Viresh Kumar
---
V2:
- Compare with -ENODEV only for failures.
- Create new label to put clkname.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_host.c | 8 ++--
3 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c0a4d4e16d82..c8287191951f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1010,12 +1010,9 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
return PTR_ERR(dpu_kms->opp_table);
/* OPP table is optional */
ret = dev_pm_opp_of_add_table(dev);
- if (!ret) {
- dpu_kms->has_opp_table = true;
- } else if (ret != -ENODEV) {
+ if (ret && ret != -ENODEV) {
dev_err(dev, "invalid OPP table in device tree\n");
- dev_pm_opp_put_clkname(dpu_kms->opp_table);
- return ret;
+ goto put_clkname;
So FWIU, dpu_unbind() gets called even when dpu_bind() fails for some reason.
I tried to address that earlier [1] which I realized did not land. But with
these changes
it will be even more broken unless we identify if we failed dpu_bind() before
adding the OPP table, while adding it, or all went well with opps and handle
things
accordingly in dpu_unbind.
[1] https://lore.kernel.org/patchwork/patch/1275632/
}
mp = &dpu_kms->mp;
@@ -1037,8 +1034,8 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
priv->kms = &dpu_kms->base;
return ret;
err:
- if (dpu_kms->has_opp_table)
- dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_of_remove_table(dev);
+put_clkname:
dev_pm_opp_put_clkname(dpu_kms->opp_table);
return ret;
}
@@ -1056,8 +1053,7 @@ static void dpu_unbind(struct device *dev, struct device
*master, void *data)
if (dpu_kms->rpm_enabled)
pm_runtime_disable(&pdev->dev);
- if (dpu_kms->has_opp_table)
- dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_of_remove_table(dev);
dev_pm_opp_put_clkname(dpu_kms->opp_table);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index e140cd633071..8295979a7165 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -129,7 +129,6 @@ struct dpu_kms {
bool rpm_enabled;
struct opp_table *opp_table;
- bool has_opp_table;
struct dss_module_power mp;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index b17ac6c27554..4335fe33250c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -113,7 +113,6 @@ struct msm_dsi_host {
struct clk *byte_intf_clk;
struct opp_table *opp_table;
- bool has_opp_table;
u32 byte_clk_rate;
u32 pixel_clk_rate;
@@ -1891,9 +1890,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
return PTR_ERR(msm_host->opp_table);
/* OPP table is optional */
ret = dev_pm_opp_of_add_table(&pdev->dev);
- if (!ret) {
- msm_host->has_opp_table = true;
- } else if (ret != -ENODEV) {
+ if (ret && ret != -ENODEV) {
dev_err(&pdev->dev, "invalid OPP table in device tree\n");
dev_pm_opp_put_clkname(msm_host->opp_table);
return ret;
@@ -1934,8 +1931,7 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
mutex_destroy(&msm_host->cmd_mutex);
mutex_destroy(&msm_host->dev_mutex);
- if (msm_host->has_opp_table)
- dev_pm_opp_of_remove_table(&msm_host->pdev->dev);
+ dev_pm_opp_of_remove_table(&msm_host->pdev->dev);
dev_pm_opp_put_clkname(msm_host->opp_table);
pm_runtime_disable(&msm_host->pdev->dev);
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] iommu/vt-d: Move intel_iommu_gfx_mapped to Intel IOMMU header
Hi Andy,
On 8/29/20 12:12 AM, Andy Shevchenko wrote:
Static analyzer is not happy about intel_iommu_gfx_mapped declaration:
.../drivers/iommu/intel/iommu.c:364:5: warning: symbol 'intel_iommu_gfx_mapped'
was not declared. Should it be static?
Move its declaration to Intel IOMMU header file.
Signed-off-by: Andy Shevchenko
---
include/drm/intel-gtt.h | 5 +
include/linux/intel-iommu.h | 1 +
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 71d81923e6b0..abfefaaf897a 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -5,6 +5,7 @@
#define _DRM_INTEL_GTT_H
#include
+#include
#include
void intel_gtt_get(u64 *gtt_total,
@@ -33,8 +34,4 @@ void intel_gtt_clear_range(unsigned int first_entry, unsigned
int num_entries);
/* flag for GFDT type */
#define AGP_USER_CACHED_MEMORY_GFDT (1 << 3)
-#ifdef CONFIG_INTEL_IOMMU
-extern int intel_iommu_gfx_mapped;
-#endif
-
#endif
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 64fa5c56c825..fbd3bb64649b 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -794,6 +794,7 @@ extern int iommu_calculate_max_sagaw(struct intel_iommu
*iommu);
extern int dmar_disabled;
extern int intel_iommu_enabled;
extern int intel_iommu_tboot_noforce;
+extern int intel_iommu_gfx_mapped;
#else
static inline int iommu_calculate_agaw(struct intel_iommu *iommu)
{
Looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Reset ASIC if suspend is not managed by platform firmware
Suspend with s2idle or by the following steps cause screen frozen:
# echo devices > /sys/power/pm_test
# echo freeze > /sys/power/mem
[ 289.625461] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait timed
out.
[ 289.625494] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
testing IB on ring 5 (-110).
The issue doesn't happen on traditional S3, probably because firmware or
hardware provides extra power management.
Inspired by Daniel Drake's patch [1] on amdgpu, using a similar approach
can fix the issue.
[1] https://patchwork.freedesktop.org/patch/335839/
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 266e3cbbd09b..df823b9ad79f 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1643,6 +1644,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool
suspend,
rdev->asic->asic_reset(rdev, true);
pci_restore_state(dev->pdev);
} else if (suspend) {
+ if (pm_suspend_no_platform())
+ rdev->asic->asic_reset(rdev, true);
/* Shut down the device */
pci_disable_device(dev->pdev);
pci_set_power_state(dev->pdev, PCI_D3hot);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/sun4i: Fix dsi dcs long write function
On Fri, Aug 28, 2020 at 02:50:32PM +0200, Ondrej Jirman wrote:
> It's writing too much data. regmap_bulk_write expects number of
> register sized chunks to write, not a byte sized length of the
> bounce buffer. Bounce buffer needs to be padded too, so that
> regmap_bulk_write will not read past the end of the buffer.
>
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller
> support")
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Jernej Skrabec
Applied, thanks
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 (resend)] video: fbdev: fix OOB read in vga_8planes_imageblit()
syzbot is reporting OOB read at vga_8planes_imageblit() [1], for "cdat[y] >> 4" can become a negative value due to "const char *cdat". [1] https://syzkaller.appspot.com/bug?id=0d7a0da1557dcd1989e00cb3692b26d4173b4132 Reported-by: syzbot Signed-off-by: Tetsuo Handa --- drivers/video/fbdev/vga16fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c index a20eeb8308ff..578d3541e3d6 100644 --- a/drivers/video/fbdev/vga16fb.c +++ b/drivers/video/fbdev/vga16fb.c @@ -1121,7 +1121,7 @@ static void vga_8planes_imageblit(struct fb_info *info, const struct fb_image *i char oldop = setop(0); char oldsr = setsr(0); char oldmask = selectmask(); -const char *cdat = image->data; + const unsigned char *cdat = image->data; u32 dx = image->dx; char __iomem *where; int y; -- 2.18.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 62/78] drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
Hi Maxime,
On 7/9/20 2:42 AM, Maxime Ripard wrote:
> The HSM clock needs to be setup at around 101% of the pixel rate. This
> was done previously by setting the clock rate to 163.7MHz at probe time and
> only check in mode_valid whether the mode pixel clock was under the pixel
> clock +1% or not.
>
> However, with 4k we need to change that frequency to a higher frequency
> than 163.7MHz, and yet want to have the lowest clock as possible to have a
> decent power saving.
>
> Let's change that logic a bit by setting the clock rate of the HSM clock
> to the pixel rate at encoder_enable time. This would work for the
> BCM2711 that support 4k resolutions and has a clock that can provide it,
> but we still have to take care of a 4k panel plugged on a BCM283x SoCs
> that wouldn't be able to use those modes, so let's define the limit in
> the variant.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 79 ---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +-
> 2 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 17797b14cde4..9f30fab744f2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -53,7 +53,6 @@
> #include "vc4_hdmi_regs.h"
> #include "vc4_regs.h"
>
> -#define HSM_CLOCK_FREQ 163682864
> #define CEC_CLOCK_FREQ 4
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> @@ -326,6 +325,7 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
> *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> ret = pm_runtime_put(&vc4_hdmi->pdev->dev);
> @@ -423,6 +423,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> bool debug_dump_regs = false;
> + unsigned long pixel_rate, hsm_rate;
> int ret;
>
> ret = pm_runtime_get_sync(&vc4_hdmi->pdev->dev);
> @@ -431,9 +432,8 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
> - ret = clk_set_rate(vc4_hdmi->pixel_clock,
> -mode->clock * 1000 *
> -((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));
> + pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
> ? 2 : 1);
> + ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
> if (ret) {
> DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
> return;
> @@ -445,6 +445,36 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
> + /*
> + * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
> + * be faster than pixel clock, infinitesimally faster, tested in
> + * simulation. Otherwise, exact value is unimportant for HDMI
> + * operation." This conflicts with bcm2835's vc4 documentation, which
> + * states HSM's clock has to be at least 108% of the pixel clock.
> + *
> + * Real life tests reveal that vc4's firmware statement holds up, and
> + * users are able to use pixel clocks closer to HSM's, namely for
> + * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> + * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
> + * 162MHz.
> + *
> + * Additionally, the AXI clock needs to be at least 25% of
> + * pixel clock, but HSM ends up being the limiting factor.
> + */
> + hsm_rate = max_t(unsigned long, 12000, (pixel_rate / 100) * 101);
> + ret = clk_set_rate(vc4_hdmi->hsm_clock, hsm_rate);
> + if (ret) {
> + DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->hsm_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on HSM clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
About vc4_hdmi->hsm_clock instance, usually, we need to enable the clock
with clk_prepare_enable() and then touch the clock like clk_set_rate().
I think that need to enable the clock before calling clk_set_rate().
When I tested this patchset, it is well working because I think that
vc4_hdmi->hsm_clock was already enabled on other side.
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> @@ -559,23 +589,9 @@ static enum drm_mode_status
> vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> const struct drm_display_mode *mode)
> {
> - /*
> - * As stated in RPi's vc4 firm
Re: [PATCH 09/19] iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add a special implementation for the SMMU attached to most Adreno GPU
> target triggered from the qcom,adreno-smmu compatible string.
>
> The new Adreno SMMU implementation will enable split pagetables
> (TTBR1) for the domain attached to the GPU device (SID 0) and
> hard code it context bank 0 so the GPU hardware can implement
> per-instance pagetables.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Rob Clark
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 +
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 149 -
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
> 3 files changed, 151 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index 88f17cc33023..d199b4bff15d 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -223,6 +223,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
> arm_smmu_device *smmu)
> of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
> return qcom_smmu_impl_init(smmu);
>
> + if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
> + return qcom_adreno_smmu_impl_init(smmu);
> +
> if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
> smmu->impl = &mrvl_mmu500_impl;
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index be4318044f96..5640d9960610 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> */
>
> +#include
> #include
> #include
>
> @@ -12,6 +13,132 @@ struct qcom_smmu {
> struct arm_smmu_device smmu;
> };
>
> +#define QCOM_ADRENO_SMMU_GPU_SID 0
> +
> +static bool qcom_adreno_smmu_is_gpu_device(struct device *dev)
> +{
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> + int i;
> +
> + /*
> + * The GPU will always use SID 0 so that is a handy way to uniquely
> + * identify it and configure it for per-instance pagetables
> + */
> + for (i = 0; i < fwspec->num_ids; i++) {
> + u16 sid = FIELD_GET(ARM_SMMU_SMR_ID, fwspec->ids[i]);
> +
> + if (sid == QCOM_ADRENO_SMMU_GPU_SID)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static const struct io_pgtable_cfg *qcom_adreno_smmu_get_ttbr1_cfg(
> + const void *cookie)
> +{
> + struct arm_smmu_domain *smmu_domain = (void *)cookie;
> + struct io_pgtable *pgtable =
> + io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> + return &pgtable->cfg;
> +}
> +
> +/*
> + * Local implementation to configure TTBR0 with the specified pagetable
> config.
> + * The GPU driver will call this to enable TTBR0 when per-instance pagetables
> + * are active
> + */
> +
> +static int qcom_adreno_smmu_set_ttbr0_cfg(const void *cookie,
> + const struct io_pgtable_cfg *pgtbl_cfg)
> +{
> + struct arm_smmu_domain *smmu_domain = (void *)cookie;
> + struct io_pgtable *pgtable =
> io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> + struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
> + struct arm_smmu_cb *cb = &smmu_domain->smmu->cbs[cfg->cbndx];
> +
> + /* The domain must have split pagetables already enabled */
> + if (cb->tcr[0] & ARM_SMMU_TCR_EPD1)
> + return -EINVAL;
> +
> + /* If the pagetable config is NULL, disable TTBR0 */
> + if (!pgtbl_cfg) {
> + /* Do nothing if it is already disabled */
> + if ((cb->tcr[0] & ARM_SMMU_TCR_EPD0))
> + return -EINVAL;
> +
> + /* Set TCR to the original configuration */
> + cb->tcr[0] = arm_smmu_lpae_tcr(&pgtable->cfg);
> + cb->ttbr[0] = FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
> + } else {
> + u32 tcr = cb->tcr[0];
> +
> + /* Don't call this again if TTBR0 is already enabled */
> + if (!(cb->tcr[0] & ARM_SMMU_TCR_EPD0))
> + return -EINVAL;
> +
> + tcr |= arm_smmu_lpae_tcr(pgtbl_cfg);
> + tcr &= ~(ARM_SMMU_TCR_EPD0 | ARM_SMMU_TCR_EPD1);
> +
> + cb->tcr[0] = tcr;
> + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> + cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
> + }
> +
> + arm_smmu_write_context_bank(smmu_domain->smmu, cb->cfg->cbndx);
> +
> + return 0;
> +}
> +
> +static int qcom_adreno_smmu_alloc_context_bank(struct arm_smmu_domain
> *smmu_domain,
> + struct device *dev, int start, int count)
> +{
> + struct arm_smmu_device *smmu = smmu_domain->smm
Re: [PATCH V2 0/8] opp: Unconditionally call dev_pm_opp_of_remove_table()
On 28-08-20, 11:37, Viresh Kumar wrote: > Hello, > > This cleans up some of the user code around calls to > dev_pm_opp_of_remove_table(). > > All the patches can be picked by respective maintainers directly except > for the last patch, which needs the previous two to get merged first. > > These are based for 5.9-rc1. > Viresh Kumar (8): > cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table() > drm/lima: Unconditionally call dev_pm_opp_of_remove_table() > drm/msm: Unconditionally call dev_pm_opp_of_remove_table() > mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table() > spi: spi-geni-qcom: Unconditionally call dev_pm_opp_of_remove_table() > spi: spi-qcom-qspi: Unconditionally call dev_pm_opp_of_remove_table() > tty: serial: qcom_geni_serial: Unconditionally call > dev_pm_opp_of_remove_table() > qcom-geni-se: remove has_opp_table During testing by some of the Linaro folks on linux-next, we found out that there was a bug in the OPP core (which makes the kernel crash in some corner cases with these patches) for which I have sent a fix today which should be part of 5.9-rc4: https://lore.kernel.org/lkml/922ff0759a16299e24cacfc981ac07914d8f1826.1598865786.git.viresh.ku...@linaro.org/ Please apply the patches over rc4 only once it comes out (I will confirm by that time once the patch gets merged). Else you guys can provide your Ack and I can take the patches through OPP tree. -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
> From: Rob Clark
>
> Currently it doesn't matter, since we free the ctx immediately. But
> when we start refcnt'ing the ctx, we don't want old dangling list
> entries to hang around.
>
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
> ---
> drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> b/drivers/gpu/drm/msm/msm_submitqueue.c
> index a1d94be7883a..90c9d84e6155 100644
> --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx)
>* No lock needed in close and there won't
>* be any more user ioctls coming our way
>*/
> - list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node)
> + list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node) {
> + list_del(&entry->node);
> msm_submitqueue_put(entry);
> + }
> }
>
> int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
> *ctx,
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/19] drm/msm: Add support to create a local pagetable
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add support to create a io-pgtable for use by targets that support
> per-instance pagetables. In order to support per-instance pagetables the
> GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
> split pagetables enabled.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpummu.c | 2 +-
> drivers/gpu/drm/msm/msm_iommu.c | 199 ++-
> drivers/gpu/drm/msm/msm_mmu.h| 16 ++-
> 3 files changed, 214 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpummu.c
> b/drivers/gpu/drm/msm/msm_gpummu.c
> index 310a31b05faa..aab121f4beb7 100644
> --- a/drivers/gpu/drm/msm/msm_gpummu.c
> +++ b/drivers/gpu/drm/msm/msm_gpummu.c
> @@ -102,7 +102,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, struct
> msm_gpu *gpu)
> }
>
> gpummu->gpu = gpu;
> - msm_mmu_init(&gpummu->base, dev, &funcs);
> + msm_mmu_init(&gpummu->base, dev, &funcs, MSM_MMU_GPUMMU);
>
> return &gpummu->base;
> }
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 1b6635504069..697cc0a059d6 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -4,15 +4,210 @@
> * Author: Rob Clark
> */
>
> +#include
> +#include
> #include "msm_drv.h"
> #include "msm_mmu.h"
>
> struct msm_iommu {
> struct msm_mmu base;
> struct iommu_domain *domain;
> + atomic_t pagetables;
> };
> +
> #define to_msm_iommu(x) container_of(x, struct msm_iommu, base)
>
> +struct msm_iommu_pagetable {
> + struct msm_mmu base;
> + struct msm_mmu *parent;
> + struct io_pgtable_ops *pgtbl_ops;
> + phys_addr_t ttbr;
> + u32 asid;
> +};
> +static struct msm_iommu_pagetable *to_pagetable(struct msm_mmu *mmu)
> +{
> + return container_of(mmu, struct msm_iommu_pagetable, base);
> +}
> +
> +static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64 iova,
> + size_t size)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + size_t unmapped = 0;
> +
> + /* Unmap the block one page at a time */
> + while (size) {
> + unmapped += ops->unmap(ops, iova, 4096, NULL);
> + iova += 4096;
> + size -= 4096;
> + }
> +
> + iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> +
> + return (unmapped == size) ? 0 : -EINVAL;
> +}
> +
> +static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64 iova,
> + struct sg_table *sgt, size_t len, int prot)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + struct scatterlist *sg;
> + size_t mapped = 0;
> + u64 addr = iova;
> + unsigned int i;
> +
> + for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> + size_t size = sg->length;
> + phys_addr_t phys = sg_phys(sg);
> +
> + /* Map the block one page at a time */
> + while (size) {
> + if (ops->map(ops, addr, phys, 4096, prot, GFP_KERNEL)) {
> + msm_iommu_pagetable_unmap(mmu, iova, mapped);
> + return -EINVAL;
> + }
> +
> + phys += 4096;
> + addr += 4096;
> + size -= 4096;
> + mapped += 4096;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void msm_iommu_pagetable_destroy(struct msm_mmu *mmu)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct msm_iommu *iommu = to_msm_iommu(pagetable->parent);
> + struct adreno_smmu_priv *adreno_smmu =
> + dev_get_drvdata(pagetable->parent->dev);
> +
> + /*
> + * If this is the last attached pagetable for the parent,
> + * disable TTBR0 in the arm-smmu driver
> + */
> + if (atomic_dec_return(&iommu->pagetables) == 0)
> + adreno_smmu->set_ttbr0_cfg(adreno_smmu->cookie, NULL);
> +
> + free_io_pgtable_ops(pagetable->pgtbl_ops);
> + kfree(pagetable);
> +}
> +
> +int msm_iommu_pagetable_params(struct msm_mmu *mmu,
> + phys_addr_t *ttbr, int *asid)
> +{
> + struct msm_iommu_pagetable *pagetable;
> +
> + if (mmu->type != MSM_MMU_IOMMU_PAGETABLE)
> + return -EINVAL;
> +
> + pagetable = to_pagetable(mmu);
> +
> + if (ttbr)
> + *ttbr = pagetable->ttbr;
> +
> + if (asid)
> + *asid = pagetable->asid;
> +
> + return 0;
> +}
> +
> +static const struct msm_mmu_funcs pagetable_funcs = {
> + .map = msm_iommu_pagetable_map,
> + .unmap = msm_iommu_pagetable_unmap,
> + .destroy = msm_iommu_pagetable_destroy,
>
Re: [PATCH 10/19] dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote: > From: Jordan Crouse > > Every Qcom Adreno GPU has an embedded SMMU for its own use. These > devices depend on unique features such as split pagetables, > different stall/halt requirements and other settings. Identify them > with a compatible string so that they can be identified in the > arm-smmu implementation specific code. > Reviewed-by: Bjorn Andersson > Signed-off-by: Jordan Crouse > Reviewed-by: Rob Herring > Signed-off-by: Rob Clark > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > index 503160a7b9a0..5ec5d0d691f6 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > @@ -40,6 +40,10 @@ properties: >- qcom,sm8150-smmu-500 >- qcom,sm8250-smmu-500 >- const: arm,mmu-500 > + - description: Qcom Adreno GPUs implementing "arm,smmu-v2" > +items: > + - const: qcom,adreno-smmu > + - const: qcom,smmu-v2 >- description: Marvell SoCs implementing "arm,mmu-500" > items: >- const: marvell,ap806-smmu-500 > -- > 2.26.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/19] iommu/arm-smmu: constify some helpers
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> Sprinkle a few `const`s where helpers don't need write access.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 59ff3fc5c6c8..27c8fc50 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -377,7 +377,7 @@ struct arm_smmu_master_cfg {
> s16 smendx[];
> };
>
> -static inline u32 arm_smmu_lpae_tcr(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_tcr(const struct io_pgtable_cfg *cfg)
> {
> u32 tcr = FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> @@ -398,13 +398,13 @@ static inline u32 arm_smmu_lpae_tcr(struct
> io_pgtable_cfg *cfg)
> return tcr;
> }
>
> -static inline u32 arm_smmu_lpae_tcr2(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_tcr2(const struct io_pgtable_cfg *cfg)
> {
> return FIELD_PREP(ARM_SMMU_TCR2_PASIZE, cfg->arm_lpae_s1_cfg.tcr.ips) |
> FIELD_PREP(ARM_SMMU_TCR2_SEP, ARM_SMMU_TCR2_SEP_UPSTREAM);
> }
>
> -static inline u32 arm_smmu_lpae_vtcr(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_vtcr(const struct io_pgtable_cfg *cfg)
> {
> return ARM_SMMU_VTCR_RES1 |
> FIELD_PREP(ARM_SMMU_VTCR_PS, cfg->arm_lpae_s2_cfg.vtcr.ps) |
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/19] drm/msm/gpu: add dev_to_gpu() helper
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> In a later patch, the drvdata will not directly be 'struct msm_gpu *',
> so add a helper to reduce the churn.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 10 --
> drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
> drivers/gpu/drm/msm/msm_gpu.h | 5 +
> 3 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 9eeb46bf2a5d..26664e1b30c0 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -282,7 +282,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> int ret;
>
> if (pdev)
> - gpu = platform_get_drvdata(pdev);
> + gpu = dev_to_gpu(&pdev->dev);
>
> if (!gpu) {
> dev_err_once(dev->dev, "no GPU device was found\n");
> @@ -425,7 +425,7 @@ static int adreno_bind(struct device *dev, struct device
> *master, void *data)
> static void adreno_unbind(struct device *dev, struct device *master,
> void *data)
> {
> - struct msm_gpu *gpu = dev_get_drvdata(dev);
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> pm_runtime_force_suspend(dev);
> gpu->funcs->destroy(gpu);
> @@ -490,16 +490,14 @@ static const struct of_device_id dt_match[] = {
> #ifdef CONFIG_PM
> static int adreno_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> return gpu->funcs->pm_resume(gpu);
> }
>
> static int adreno_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> return gpu->funcs->pm_suspend(gpu);
> }
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index d5645472b25d..6aa9e04e52e7 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -24,7 +24,7 @@
> static int msm_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> {
> - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> + struct msm_gpu *gpu = dev_to_gpu(dev);
> struct dev_pm_opp *opp;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> @@ -45,7 +45,7 @@ static int msm_devfreq_target(struct device *dev, unsigned
> long *freq,
> static int msm_devfreq_get_dev_status(struct device *dev,
> struct devfreq_dev_status *status)
> {
> - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> + struct msm_gpu *gpu = dev_to_gpu(dev);
> ktime_t time;
>
> if (gpu->funcs->gpu_get_freq)
> @@ -64,7 +64,7 @@ static int msm_devfreq_get_dev_status(struct device *dev,
>
> static int msm_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
> {
> - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> if (gpu->funcs->gpu_get_freq)
> *freq = gpu->funcs->gpu_get_freq(gpu);
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 0db117a7339b..8bda7beaed4b 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -141,6 +141,11 @@ struct msm_gpu {
> struct msm_gpu_state *crashstate;
> };
>
> +static inline struct msm_gpu *dev_to_gpu(struct device *dev)
That's a fairly generic name for a driver-global helper :)
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> +{
> + return dev_get_drvdata(dev);
> +}
> +
> /* It turns out that all targets use the same ringbuffer size */
> #define MSM_GPU_RINGBUFFER_SZ SZ_32K
> #define MSM_GPU_RINGBUFFER_BLKSIZE 32
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Tue 01 Sep 03:42 UTC 2020, Rob Clark wrote:
> On Mon, Aug 31, 2020 at 7:35 PM Bjorn Andersson
> wrote:
> >
> > On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
> >
> > > From: Rob Clark
> > >
> > > Currently it doesn't matter, since we free the ctx immediately. But
> > > when we start refcnt'ing the ctx, we don't want old dangling list
> > > entries to hang around.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > > index a1d94be7883a..90c9d84e6155 100644
> > > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > > @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private
> > > *ctx)
> > >* No lock needed in close and there won't
> > >* be any more user ioctls coming our way
> > >*/
> > > - list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node)
> > > + list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node) {
> > > + list_del(&entry->node);
> >
> > If you refcount ctx, what does that do for the entries in the submit
> > queue?
> >
> > "entry" here is kref'ed, but you're popping it off the list regardless
> > of the put ends up freeing the object or not - which afaict would mean
> > leaking the object.
> >
>
> What ends up happening is the submit has reference to submit-queue,
> which has reference to the ctx.. the submitqueue could be alive still
> pending in-flight submits (in a later patch), but dead from the PoV of
> userspace interface.
>
> We aren't relying (or at least aren't in the end, and I *think* I
> didn't miss anything in the middle) relying on ctx->submitqueues list
> to clean anything up in the end, just track what is still a valid
> submitqueue from userspace PoV
>
Looks reasonable, thanks for the explanation.
> BR,
> -R
>
> >
> > On the other hand, with the current implementation an object with higher
> > refcount with adjacent objects of single refcount would end up with
> > dangling pointers after the put. So in itself this change seems like a
> > net gain, but I'm wondering about the plan described in the commit
> > message.
> >
> > Regards,
> > Bjorn
> >
> > > msm_submitqueue_put(entry);
> > > + }
> > > }
> > >
> > > int msm_submitqueue_create(struct drm_device *drm, struct
> > > msm_file_private *ctx,
> > > --
> > > 2.26.2
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/19] drm/msm: Add a context pointer to the submitqueue
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Each submitqueue is attached to a context. Add a pointer to the
> context to the submitqueue at create time and refcount it so
> that it stays around through the life of the queue.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Rob Clark
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> drivers/gpu/drm/msm/msm_drv.h | 20
> drivers/gpu/drm/msm/msm_gem.h | 1 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 6 +++---
> drivers/gpu/drm/msm/msm_gpu.h | 1 +
> drivers/gpu/drm/msm/msm_submitqueue.c | 3 +++
> 6 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 7d641c7e3514..01845a3b8d52 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -594,6 +594,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> if (!ctx)
> return -ENOMEM;
>
> + kref_init(&ctx->ref);
> msm_submitqueue_init(dev, ctx);
>
> ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
> @@ -615,7 +616,7 @@ static int msm_open(struct drm_device *dev, struct
> drm_file *file)
> static void context_close(struct msm_file_private *ctx)
> {
> msm_submitqueue_close(ctx);
> - kfree(ctx);
> + msm_file_private_put(ctx);
> }
>
> static void msm_postclose(struct drm_device *dev, struct drm_file *file)
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index af259b0573ea..4561bfb5e745 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -57,6 +57,7 @@ struct msm_file_private {
> struct list_head submitqueues;
> int queueid;
> struct msm_gem_address_space *aspace;
> + struct kref ref;
> };
>
> enum msm_mdp_plane_property {
> @@ -428,6 +429,25 @@ void msm_submitqueue_close(struct msm_file_private *ctx);
>
> void msm_submitqueue_destroy(struct kref *kref);
>
> +static inline void __msm_file_private_destroy(struct kref *kref)
> +{
> + struct msm_file_private *ctx = container_of(kref,
> + struct msm_file_private, ref);
> +
> + kfree(ctx);
> +}
> +
> +static inline void msm_file_private_put(struct msm_file_private *ctx)
> +{
> + kref_put(&ctx->ref, __msm_file_private_destroy);
> +}
> +
> +static inline struct msm_file_private *msm_file_private_get(
> + struct msm_file_private *ctx)
> +{
> + kref_get(&ctx->ref);
> + return ctx;
> +}
>
> #define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> #define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 972490b14ba5..9c573c4269cb 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -142,6 +142,7 @@ struct msm_gem_submit {
> bool valid; /* true if no cmdstream patching needed */
> bool in_rb; /* "sudo" mode, copy cmds into RB */
> struct msm_ringbuffer *ring;
> + struct msm_file_private *ctx;
> unsigned int nr_cmds;
> unsigned int nr_bos;
> u32 ident; /* A "identifier" for the submit for logging */
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 8cb9aa15ff90..1464b04d25d3 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -27,7 +27,7 @@
> #define BO_PINNED 0x2000
>
> static struct msm_gem_submit *submit_create(struct drm_device *dev,
> - struct msm_gpu *gpu, struct msm_gem_address_space *aspace,
> + struct msm_gpu *gpu,
> struct msm_gpu_submitqueue *queue, uint32_t nr_bos,
> uint32_t nr_cmds)
> {
> @@ -43,7 +43,7 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return NULL;
>
> submit->dev = dev;
> - submit->aspace = aspace;
> + submit->aspace = queue->ctx->aspace;
> submit->gpu = gpu;
> submit->fence = NULL;
> submit->cmd = (void *)&submit->bos[nr_bos];
> @@ -677,7 +677,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> }
> }
>
> - submit = submit_create(dev, gpu, ctx->aspace, queue, args->nr_bos,
> + submit = submit_create(dev, gpu, queue, args->nr_bos,
> args->nr_cmds);
> if (!submit) {
> ret = -ENOMEM;
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index f91b141add75..97c527e98391 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -190,6 +190,7 @@ struct msm_gpu_submitqueue {
> u32 flags;
> u32 prio;
> int faults;
> + struct msm_file_private *ctx;
> struct list_head node;
>
Re: [RFC] Experimental DMA-BUF Device Heaps
On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote:
> This heap is basically a wrapper around DMA-API dma_alloc_attrs,
> which will allocate memory suitable for the given device.
>
> The implementation is mostly a port of the Contiguous Videobuf2
> memory allocator (see videobuf2/videobuf2-dma-contig.c)
> over to the DMA-BUF Heap interface.
>
> The intention of this allocator is to provide applications
> with a more system-agnostic API: the only thing the application
> needs to know is which device to get the buffer for.
>
> Whether the buffer is backed by CMA, IOMMU or a DMA Pool
> is unknown to the application.
>
> I'm not really expecting this patch to be correct or even
> a good idea, but just submitting it to start a discussion on DMA-BUF
> heap discovery and negotiation.
>
> Given Plumbers is just a couple weeks from now, I've submitted
> a BoF proposal to discuss this, as perhaps it would make
> sense to discuss this live?
>
> Not-signed-off-by: Ezequiel Garcia
I think on the uapi/constraint solving side there's been already tons of
discussions while I enjoyed vacations, so different concern from me
entirely on the implementation side:
In the past the only thing we had in upstream was subsystem/driver
specific allocators, and dma-buf for sharing. With dma-buf heaps we kinda
get a central allocator, which duplicates large chunks of of all these
allocators. And since it's a central allocator by design, the reason for
having per-subsystem allocators is kinda gone.
I think there's two approaches here:
- we convert e.g. drm allocator helpers to internally use the right heap
implementation. That would also give us some fairly direct way to expose
these constraints in sysfs so a userspace allocator knows which dma-buf
heap to pick for shared stuff.
- we require that any heap is just a different uapi for an existing driver
allocator, e.g. by having a dma-buf wrapper for all gem drivers.
Otherwise I think what we end up with is a pile of dma-buf heaps for
android's blob gpu driver world, and not used anywhere else. Not something
even remotely interesting for upstream :-)
tldr; I'd like to see how dma-buf heaps closely integrate with all the
existing buffer management code we have. Both kernel (and throuhg some
allocator library effort) in userspace.
Cheers, Daniel
> ---
> drivers/dma-buf/heaps/Kconfig | 9 +
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/device_heap.c | 268
> include/linux/device.h | 5 +
> include/linux/dma-heap.h| 6 +
> 5 files changed, 289 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/device_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06c4226..2bb3604184bd 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -12,3 +12,12 @@ config DMABUF_HEAPS_CMA
> Choose this option to enable dma-buf CMA heap. This heap is backed
> by the Contiguous Memory Allocator (CMA). If your system has these
> regions, you should say Y here.
> +
> +config DMABUF_HEAPS_DEVICES
> + bool "DMA-BUF Device DMA Heap (Experimental)"
> + depends on DMABUF_HEAPS
> + help
> + Choose this option to enable dma-buf per-device heap. This heap is
> backed
> + by the DMA-API and it's an Experimental feature, meant mostly for
> testing
> + and experimentation.
> + Just say N here.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 6e54cdec3da0..c691d85b3044 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -2,3 +2,4 @@
> obj-y+= heap-helpers.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_DEVICES) += device_heap.o
> diff --git a/drivers/dma-buf/heaps/device_heap.c
> b/drivers/dma-buf/heaps/device_heap.c
> new file mode 100644
> index ..1803dc622dd8
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/device_heap.c
> @@ -0,0 +1,268 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF Device DMA heap exporter
> + *
> + * Copyright (C) 2020, Collabora Ltd.
> + *
> + * Based on:
> + * videobuf2-dma-contig.c - DMA contig memory allocator for videobuf2
> + * Copyright (C) 2010 Samsung Electronics
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct dev_dmabuf_attachment {
> + struct sg_table sgt;
> + enum dma_data_direction dma_dir;
> +};
> +
> +struct dev_dmabuf {
> + struct dma_heap *heap;
> + struct dma_buf *dmabuf;
> + struct device *dev;
> + size_t size;
> + void *vaddr;
> + dma_addr_t dma_addr;
> + unsigned long attrs;
> +
> + struct sg_table sgt;
> +};
> +
> +static struct sg_table *dev_dmabuf_ops_map(struc
fotg210-udc: Error in type cast in fotg210_in_fifo_handler()
If in fotg210_udc_probe() after initialization INIT_LIST_HEAD(&ep->queue) and after a registration of an interrupt handler in fotg210_irq() fotg210_in_fifo_handler() is calling then in fotg210_in_fifo_handler() list_entry() tries to get struct fotg210_request from ep->queue.next, but after initialization ep->queue.next is from struct fotg210_udc. Also this problem appears in fotg210_out_fifo_handler(). In fotg210_ep0in() and fotg210_ep0out() there is checking by list_empty() before calling list_entry (). Found by Linux Driver Verification project (linuxtesting.org). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/virtio: fix unblank
On Fri, Aug 28, 2020 at 01:27:59PM +0200, Gerd Hoffmann wrote:
> On Mon, Aug 24, 2020 at 09:24:40AM +0200, Jiri Slaby wrote:
> > On 18. 08. 20, 9:25, Gerd Hoffmann wrote:
> > > When going through a disable/enable cycle without changing the
> > > framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
> > > skip set_scanout if framebuffer didn't change") causes the screen stay
> > > blank. Add a bool to force an update to fix that.
> > >
> > > v2: use drm_atomic_crtc_needs_modeset() (Daniel).
> > >
> > > Cc: 1882...@bugs.launchpad.net
> > > Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't
> > > change")
> > > Signed-off-by: Gerd Hoffmann
> >
> > Tested-by: Jiri Slaby
>
> Ping. Need an ack or an review to merge this.
In case you still need that, on both patches:
Acked-by: Daniel Vetter
>
> thanks,
> Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 00/17] drm/i915: Add support for HDCP 1.4 over MST
On 2020-08-18 at 11:38:48 -0400, Sean Paul wrote: > From: Sean Paul > > Only one functional change, reversed the hdcp_1x/2x_present bits in the > QUERY_STREAM_ENCRYPTION_STATUS parsing with a comment explaining my > confusion. > > Other than that, lots of rebasing, the most notable being the > s/intel_dig_port/dig_port/ rename. > > Every patch now has a Reviewed-by tag now, I've done build tests on each > patch and tested the set as a whole. Hopefully we can get this landed. Thanks for the change. Merged into dinq. Ram > > Sean > > Sean Paul (17): > drm/i915: Fix sha_text population code > drm/i915: Clear the repeater bit on HDCP disable > drm/i915: WARN if HDCP signalling is enabled upon disable > drm/i915: Intercept Aksv writes in the aux hooks > drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP > signalling > drm/i915: Factor out hdcp->value assignments > drm/i915: Protect workers against disappearing connectors > drm/i915: Clean up intel_hdcp_disable > drm/i915: Don't fully disable HDCP on a port if multiple pipes are > using it > drm/i915: Support DP MST in enc_to_dig_port() function > drm/i915: Use ddi_update_pipe in intel_dp_mst > drm/i915: Factor out HDCP shim functions from dp for use by dp_mst > drm/i915: Plumb port through hdcp init > drm/i915: Add connector to hdcp_shim->check_link() > drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband > message > drm/i915: Print HDCP version info for all connectors > drm/i915: Add HDCP 1.4 support for MST connectors > > drivers/gpu/drm/drm_dp_mst_topology.c | 150 > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > drivers/gpu/drm/i915/display/intel_ddi.h | 2 + > .../drm/i915/display/intel_display_debugfs.c | 21 +- > .../drm/i915/display/intel_display_types.h| 30 +- > drivers/gpu/drm/i915/display/intel_dp.c | 646 +--- > drivers/gpu/drm/i915/display/intel_dp.h | 9 + > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 703 ++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + > drivers/gpu/drm/i915/display/intel_hdcp.c | 217 -- > drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +- > .../drm/selftests/test-drm_dp_mst_helper.c| 17 + > include/drm/drm_dp_helper.h | 3 + > include/drm/drm_dp_mst_helper.h | 44 ++ > include/drm/drm_hdcp.h| 3 + > 17 files changed, 1202 insertions(+), 724 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c > > -- > Sean Paul, Software Engineer, Google / Chromium OS > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm: allow limiting the scatter list size.
On Tue, Aug 18, 2020 at 11:20:16AM +0200, Gerd Hoffmann wrote:
> Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
> through to the __sg_alloc_table_from_pages() call, otherwise use
> SCATTERLIST_MAX_SEGMENT.
>
> Also add max_segment field to drm driver and pass it to
> drm_prime_pages_to_sg() calls in drivers and helpers.
>
> v2: place max_segment in drm driver not gem object.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_device.h| 8
> include/drm/drm_prime.h | 3 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++-
> drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
> drivers/gpu/drm/drm_prime.c | 10 +++---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++-
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++-
> drivers/gpu/drm/msm/msm_gem.c | 3 ++-
> drivers/gpu/drm/msm/msm_gem_prime.c | 3 ++-
> drivers/gpu/drm/nouveau/nouveau_prime.c | 3 ++-
> drivers/gpu/drm/radeon/radeon_prime.c | 3 ++-
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 6 --
> drivers/gpu/drm/tegra/gem.c | 3 ++-
> drivers/gpu/drm/vgem/vgem_drv.c | 3 ++-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++-
> 15 files changed, 43 insertions(+), 17 deletions(-)
>
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 0988351d743c..47cb547a8115 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -329,6 +329,14 @@ struct drm_device {
>*/
> struct drm_fb_helper *fb_helper;
>
> + /**
> + * @max_segment:
> + *
> + * Max size for scatter list segments. When unset the default
> + * (SCATTERLIST_MAX_SEGMENT) is used.
> + */
> + size_t max_segment;
Is there no better place for this then "at the bottom"? drm_device is a
huge structure, piling stuff up randomly doesn't make it better :-)
I think ideally we'd have a gem substruct like we have on the modeset side
at least.
-Daniel
> +
> /* Everything below here is for legacy driver, never use! */
> /* private: */
> #if IS_ENABLED(CONFIG_DRM_LEGACY)
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> index 9af7422b44cf..2c3689435cb4 100644
> --- a/include/drm/drm_prime.h
> +++ b/include/drm/drm_prime.h
> @@ -88,7 +88,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
> *vaddr);
> int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct
> *vma);
> int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
>
> -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
> nr_pages);
> +struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
> nr_pages,
> +size_t max_segment);
> struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
>int flags);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 519ce4427fce..8f6a647757e7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -303,7 +303,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct
> dma_buf_attachment *attach,
> switch (bo->tbo.mem.mem_type) {
> case TTM_PL_TT:
> sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
> - bo->tbo.num_pages);
> + bo->tbo.num_pages,
> + obj->dev->max_segment);
> if (IS_ERR(sgt))
> return sgt;
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 4b7cfbac4daa..8f47b41b0b2f 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -656,7 +656,8 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
> drm_gem_object *obj)
>
> WARN_ON(shmem->base.import_attach);
>
> - return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
> + return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT,
> + obj->dev->max_segment);
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 1693aa7c14b5..27c783fd6633 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -802,7 +802,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops
> = {
> *
> * This is useful for implementing &drm_gem_object_funcs.get_sg_table.
> */
> -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
> nr_pages)
> +struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
> nr_pages,
> +size_t max_seg
Re: [PATCH 3/3] drm/amdgpu: Embed drm_device into amdgpu_device (v2)
On Wed, Aug 19, 2020 at 01:00:42AM -0400, Luben Tuikov wrote:
> a) Embed struct drm_device into struct amdgpu_device.
> b) Modify the inline-f drm_to_adev() accordingly.
> c) Modify the inline-f adev_to_drm() accordingly.
> d) Eliminate the use of drm_device.dev_private,
>in amdgpu.
> e) Switch from using drm_dev_alloc() to
>drm_dev_init().
> f) Add a DRM driver release function, which frees
>the container amdgpu_device after all krefs on
>the contained drm_device have been released.
>
> v2: Split out adding adev_to_drm() into its own
> patch (previous commit), making this patch
> more succinct and clear. More detailed commit
> description.
>
> Signed-off-by: Luben Tuikov
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 ++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 43 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 20 +++---
> 4 files changed, 43 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 735480cc7dcf..107a6ec920f7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -724,8 +724,8 @@ struct amd_powerplay {
> #define AMDGPU_MAX_DF_PERFMONS 4
> struct amdgpu_device {
> struct device *dev;
> - struct drm_device *ddev;
> struct pci_dev *pdev;
> + struct drm_device ddev;
>
> #ifdef CONFIG_DRM_AMD_ACP
> struct amdgpu_acp acp;
> @@ -990,12 +990,12 @@ struct amdgpu_device {
>
> static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
> {
> - return ddev->dev_private;
> + return container_of(ddev, struct amdgpu_device, ddev);
> }
>
> static inline struct drm_device *adev_to_drm(struct amdgpu_device *adev)
> {
> - return adev->ddev;
> + return &adev->ddev;
> }
>
> static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device
> *bdev)
> @@ -1004,8 +1004,6 @@ static inline struct amdgpu_device
> *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
> }
>
> int amdgpu_device_init(struct amdgpu_device *adev,
> -struct drm_device *ddev,
> -struct pci_dev *pdev,
> uint32_t flags);
> void amdgpu_device_fini(struct amdgpu_device *adev);
> int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
> @@ -1195,7 +1193,7 @@ static inline void *amdgpu_atpx_get_dhandle(void) {
> return NULL; }
> extern const struct drm_ioctl_desc amdgpu_ioctls_kms[];
> extern const int amdgpu_max_kms_ioctl;
>
> -int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags);
> +int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags);
> void amdgpu_driver_unload_kms(struct drm_device *dev);
> void amdgpu_driver_lastclose_kms(struct drm_device *dev);
> int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file
> *file_priv);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 07012d71eeea..6e529548e708 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1216,7 +1216,8 @@ static int amdgpu_device_check_arguments(struct
> amdgpu_device *adev)
> * Callback for the switcheroo driver. Suspends or resumes the
> * the asics before or after it is powered up using ACPI methods.
> */
> -static void amdgpu_switcheroo_set_state(struct pci_dev *pdev, enum
> vga_switcheroo_state state)
> +static void amdgpu_switcheroo_set_state(struct pci_dev *pdev,
> + enum vga_switcheroo_state state)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
> int r;
> @@ -2977,8 +2978,6 @@ static const struct attribute *amdgpu_dev_attributes[]
> = {
> * amdgpu_device_init - initialize the driver
> *
> * @adev: amdgpu_device pointer
> - * @ddev: drm dev pointer
> - * @pdev: pci dev pointer
> * @flags: driver flags
> *
> * Initializes the driver info and hw (all asics).
> @@ -2986,18 +2985,15 @@ static const struct attribute
> *amdgpu_dev_attributes[] = {
> * Called at driver startup.
> */
> int amdgpu_device_init(struct amdgpu_device *adev,
> -struct drm_device *ddev,
> -struct pci_dev *pdev,
> uint32_t flags)
> {
> + struct drm_device *ddev = adev_to_drm(adev);
> + struct pci_dev *pdev = adev->pdev;
> int r, i;
> bool boco = false;
> u32 max_MBps;
>
> adev->shutdown = false;
> - adev->dev = &pdev->dev;
> - adev->ddev = ddev;
> - adev->pdev = pdev;
> adev->flags = flags;
>
> if (amdgpu_force_asic_type >= 0 && amdgpu_force_asic_type < CHIP_LAST)
> @@ -3451,9 +3447,8 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
> fbcon)
Re: [PATCH] drm/crc-debugfs: Fix memleak in crc_control_write
On Wed, Aug 19, 2020 at 02:55:15PM +0300, Laurent Pinchart wrote:
> Hi Dinghao,
>
> Thank you for the patch.
>
> On Wed, Aug 19, 2020 at 04:22:28PM +0800, Dinghao Liu wrote:
> > When verify_crc_source() fails, source needs to be freed.
> > However, current code is returning directly and ends up
> > leaking memory.
> >
> > Fixes: c0811a7d5befe ("drm/crc: Cleanup crtc_crc_open function")
>
> I think the issue was introduced in d5cc15a0c66e ("drm: crc: Introduce
> verify_crc_source callback"). Apart from that,
>
> Reviewed-by: Laurent Pinchart
Pushed to drm-misc-next.
-Daniel
>
> > Signed-off-by: Dinghao Liu
> > ---
> > drivers/gpu/drm/drm_debugfs_crc.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> > b/drivers/gpu/drm/drm_debugfs_crc.c
> > index 5d67a41f7c3a..3dd70d813f69 100644
> > --- a/drivers/gpu/drm/drm_debugfs_crc.c
> > +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> > @@ -144,8 +144,10 @@ static ssize_t crc_control_write(struct file *file,
> > const char __user *ubuf,
> > source[len - 1] = '\0';
> >
> > ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
> > - if (ret)
> > + if (ret) {
> > + kfree(source);
> > return ret;
> > + }
> >
> > spin_lock_irq(&crc->lock);
> >
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
On Wed, Aug 26, 2020 at 11:24:23AM +0300, Pekka Paalanen wrote: > On Tue, 25 Aug 2020 12:58:19 -0400 > "Kazlauskas, Nicholas" wrote: > > > On 2020-08-22 5:59 a.m., Michel Dänzer wrote: > > > On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: > > >> On 2020-08-21 12:57 p.m., Michel Dänzer wrote: > > >>> From: Michel Dänzer > > >>> > > >>> Don't check drm_crtc_state::active for this either, per its > > >>> documentation in include/drm/drm_crtc.h: > > >>> > > >>> * Hence drivers must not consult @active in their various > > >>> * &drm_mode_config_funcs.atomic_check callback to reject an atomic > > >>> * commit. > > >>> > > >>> The atomic helpers disable the CRTC as needed for disabling the primary > > >>> plane. > > >>> > > >>> This prevents at least the following problems if the primary plane gets > > >>> disabled (e.g. due to destroying the FB assigned to the primary plane, > > >>> as happens e.g. with mutter in Wayland mode): > > >>> > > >>> * Toggling CRTC active to 1 failed if the cursor plane was enabled > > >>> (e.g. via legacy DPMS property & cursor ioctl). > > >>> * Enabling the cursor plane failed, e.g. via the legacy cursor ioctl. > > >> > > >> We previously had the requirement that the primary plane must be enabled > > >> but some userspace expects that they can enable just the overlay plane > > >> without anything else. > > >> > > >> I think the chromuiumos atomictest validates that this works as well: > > >> > > >> So is DRM going forward then with the expectation that this is wrong > > >> behavior from userspace? > > >> > > >> We require at least one plane to be enabled to display a cursor, but it > > >> doesn't necessarily need to be the primary. > > > > > > It's a "pick your poison" situation: > > > > > > 1) Currently the checks are invalid (atomic_check must not decide based > > > on drm_crtc_state::active), and it's easy for legacy KMS userspace to > > > accidentally hit errors trying to enable/move the cursor or switch DPMS > > > off → on. > > > > > > 2) Accurately rejecting only atomic states where the cursor plane is > > > enabled but all other planes are off would break the KMS helper code, > > > which can only deal with the "CRTC on & primary plane off is not > > > allowed" case specifically. > > > > > > 3) This patch addresses 1) & 2) but may break existing atomic userspace > > > which wants to enable an overlay plane while disabling the primary plane. > > > > > > > > > I do think in principle atomic userspace is expected to handle case 3) > > > and leave the primary plane enabled. However, this is not ideal from an > > > energy consumption PoV. Therefore, here's another idea for a possible > > > way out of this quagmire: > > > > > > amdgpu_dm does not reject any atomic states based on which planes are > > > enabled in it. If the cursor plane is enabled but all other planes are > > > off, amdgpu_dm internally either: > > > > > > a) Enables an overlay plane and makes it invisible, e.g. by assigning a > > > minimum size FB with alpha = 0. > > > > > > b) Enables the primary plane and assigns a minimum size FB (scaled up to > > > the required size) containing all black, possibly using compression. > > > (Trying to minimize the memory bandwidth) > > > > > > > > > Does either of these seem feasible? If both do, which one would be > > > preferable? > > > > > > > > > > It's really the same solution since DCN doesn't make a distinction > > between primary or overlay planes in hardware. DCE doesn't have overlay > > planes enabled so this is not relevant there. > > > > The old behavior (pre 5.1?) was to silently accept the commit even > > though the screen would be completely black instead of outright > > rejecting the commit. > > > > I almost wonder if that makes more sense in the short term here since > > the only "userspace" affected here is IGT. We'll fail the CRC checks, > > but no userspace actually tries to actively use a cursor with no primary > > plane enabled from my understanding. > > Hi, > > I believe that there exists userspace that will *accidentally* attempt > to update the cursor plane while primary plane or whole CRTC is off. > Some versions of Mutter might do that on racy conditions, I suspect. > These are legacy KMS users, not atomic KMS. > > However, I do not believe there exists any userspace that would > actually expect the display to show the cursor plane alone without a > primary plane. Therefore I'd be ok with legacy cursor ioctls silently > succeeding. Atomic commits not. So the difference has to be in the > translation from legacy UAPI to kernel internal atomic interface. > > > In the long term I think we can work on getting cursor actually on the > > screen in this case, though I can't say I really like having to reserve > > some small buffer (eg. 16x16) for allowing lightup on this corner case. > > Why would you bother implementing that? > > Is there really an IGT test that unconditionally demands cursor plan
Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
On Tue, Aug 25, 2020 at 04:55:28PM +0200, Michel Dänzer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2020-08-24 9:43 a.m., Pekka Paalanen wrote: > > On Sat, 22 Aug 2020 11:59:26 +0200 Michel Dänzer > > wrote: > >> On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: > >>> On 2020-08-21 12:57 p.m., Michel Dänzer wrote: > From: Michel Dänzer > > Don't check drm_crtc_state::active for this either, per its > documentation in include/drm/drm_crtc.h: > > * Hence drivers must not consult @active in their various * > &drm_mode_config_funcs.atomic_check callback to reject an > atomic * commit. > > The atomic helpers disable the CRTC as needed for disabling > the primary plane. > > This prevents at least the following problems if the primary > plane gets disabled (e.g. due to destroying the FB assigned > to the primary plane, as happens e.g. with mutter in Wayland > mode): > > * Toggling CRTC active to 1 failed if the cursor plane was > enabled (e.g. via legacy DPMS property & cursor ioctl). * > Enabling the cursor plane failed, e.g. via the legacy cursor > ioctl. > >>> > >>> We previously had the requirement that the primary plane must > >>> be enabled but some userspace expects that they can enable > >>> just the overlay plane without anything else. > >>> > >>> I think the chromuiumos atomictest validates that this works > >>> as well: > >>> > >>> So is DRM going forward then with the expectation that this is > >>> wrong behavior from userspace? > >>> > >>> We require at least one plane to be enabled to display a > >>> cursor, but it doesn't necessarily need to be the primary. > >> > >> It's a "pick your poison" situation: > >> > >> 1) Currently the checks are invalid (atomic_check must not > >> decide based on drm_crtc_state::active), and it's easy for legacy > >> KMS userspace to accidentally hit errors trying to enable/move > >> the cursor or switch DPMS off → on. > >> > >> 2) Accurately rejecting only atomic states where the cursor > >> plane is enabled but all other planes are off would break the > >> KMS helper code, which can only deal with the "CRTC on & primary > >> plane off is not allowed" case specifically. > >> > >> 3) This patch addresses 1) & 2) but may break existing atomic > >> userspace which wants to enable an overlay plane while disabling > >> the primary plane. > >> > >> > >> I do think in principle atomic userspace is expected to handle > >> case 3) and leave the primary plane enabled. > > > > Hi, > > > > my opinion as a userspace developer is that enabling a CRTC > > without a primary plane has traditionally not worked, so userspace > > cannot *rely* on it ever working. I think legacy KMS API does not > > even allow to express that really, or has built-in assumptions that > > it doesn't work - you can call the legacy cursor ioctls, they > > don't fail, but also the CRTC remains off. Correct me if this is > > not true. > > > > Atomic userspace OTOH is required to test the strange (and all!) > > cases like this to see if they work or not, and carry on with a > > fallback if they don't. Userspace that wants to use a CRTC without > > a primary plane likely needs other CRTC properties as well, like > > background color. > > > > I would guess that when two regressions conflict, the older > > userspace would win. Hence legacy KMS using Mutter should keep > > working, while atomic userspace is left with increased power > > consumption. Not using a hardware cursor (Mutter) is much more > > easily an end-user visible regression than slightly shorter > > battery life. > > > > Atomic test commits are allowed to fail at any time for any reason > > and something that previously worked can fail on the next frame or > > on the next kernel, as far as I understand. > > All of this basically matches my understanding. > > > > Sounds like the helpers you refer to are inadequate for your case. > > Can't you fix the helpers in the long run and land this patch as an > > immediate fix? > > I'd rather leave working on those helpers to KMS developers. :) I thought the issue is the rmfb ioctl trickery, which has this assumption fully backed in. The wiggle room in there for semantic changes is iirc pretty much nil, it took us a pile of patches to just get to the current state. So it's not helper code, it's core legacy ioctl code for atomic drivers. -Daniel > > > - -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and X developer > -BEGIN PGP SIGNATURE- > > iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCX0UmXAAKCRBaga+Oatuy > AIeNAJoC9UgOrF+qBq08uOyjaV7Vfp+PgACfSp3nXB3un3LUZQxrvaxMAON+eIs= > =Pbd2 > -END PGP SIGNATURE- > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel --
Re: [PATCH] Documentation: fix dma-buf.rst underline length warning
On Sun, Aug 23, 2020 at 04:41:59PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> /home/rdunlap/lnx/lnx-59-rc2/Documentation/driver-api/dma-buf.rst:182:
> WARNING: Title underline too short.
> Indefinite DMA Fences
>
>
> Fixes: 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad
> idea")
> Signed-off-by: Randy Dunlap
> Cc: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Dave Airlie
Applied to drm-misc-fixes, thanks for your patch.
-Daniel
> ---
> Documentation/driver-api/dma-buf.rst |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- lnx-59-rc2.orig/Documentation/driver-api/dma-buf.rst
> +++ lnx-59-rc2/Documentation/driver-api/dma-buf.rst
> @@ -179,7 +179,7 @@ DMA Fence uABI/Sync File
> :internal:
>
> Indefinite DMA Fences
> -
> +~
>
> At various times &dma_fence with an indefinite time until dma_fence_wait()
> finishes have been proposed. Examples include:
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
On 2020-09-01 9:57 a.m., Daniel Vetter wrote: > On Tue, Aug 25, 2020 at 04:55:28PM +0200, Michel Dänzer wrote: >> On 2020-08-24 9:43 a.m., Pekka Paalanen wrote: >> >>> Sounds like the helpers you refer to are inadequate for your case. >>> Can't you fix the helpers in the long run and land this patch as an >>> immediate fix? >> >> I'd rather leave working on those helpers to KMS developers. :) > > I thought the issue is the rmfb ioctl trickery, which has this assumption > fully backed in. The wiggle room in there for semantic changes is iirc > pretty much nil, it took us a pile of patches to just get to the current > state. So it's not helper code, it's core legacy ioctl code for atomic > drivers. My bad. Should I respin with an amended commit log? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Monday, August 31, 2020 3:48 PM, Ville Syrjälä wrote: > > > It doesn't seem like this IGT test's goal is to exercise support for > > > gamma LUTs. Does the test just tries to reset the gamma LUT to linear? > > > If so, I think the IGT test should be fixed to ignore "I don't support > > > gamma" errors. > > > > It seems like that IGT test pixel-format is to make gamma lut like below. > > for (i = 0; i < lut_size; i++) > > lut[i] = (i * 0x / (lut_size - 1)) & mask; > > And set this table to drm driver. and test begins. It's the test about pixel > > format. I think you're right. It's not about gamma lut. > > The point of the gamma LUT stuff in the pixel format test is to throw > away a bunch of the lsbs so that the test passes when the result is > "close enough" to the 8bpc RGB reference image. Without it we would > never get a crc match when testing non-8bpc or YCbCr formats. OK, that makes sense. Would it be sensible to: - Don't set gamma if the pixel format being tested is 8bpc - Make the test skip if the pixel format is >8bpc and gamma isn't supported ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: Support remote i2c writes
On Mon, Jul 27, 2020 at 04:03:37PM +1000, Sam McNally wrote:
> For DP MST outputs, the i2c device currently only supports transfers
> that can be implemented using remote i2c reads. Such transfers must
> consist of zero or more write transactions followed by one read
> transaction. DDC/CI commands require standalone write transactions and
> hence aren't supported.
>
> Since each remote i2c write is handled as a separate transfer, remote
> i2c writes can support transfers consisting of write transactions, where
> all but the last have I2C_M_STOP set. According to the DDC/CI 1.1
> standard, DDC/CI commands only require a single write or read
> transaction in a transfer, so this is sufficient.
>
> For i2c transfers meeting the above criteria, generate and send a remote
> i2c write message for each transaction. Add the trivial remote i2c write
> reply parsing support so remote i2c write acks bubble up correctly.
Looks great.
For good measure I bounced this to intel-gfx so we got
the CI to check it. Seems to have passed.
Amended with
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/37
and pushed to drm-misc-next. Thanks!
>
> Signed-off-by: Sam McNally
> ---
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 106 ++
> 1 file changed, 90 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 09b32289497e..1ac874e4e7a1 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -961,6 +961,8 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
> return drm_dp_sideband_parse_remote_dpcd_write(raw, msg);
> case DP_REMOTE_I2C_READ:
> return drm_dp_sideband_parse_remote_i2c_read_ack(raw, msg);
> + case DP_REMOTE_I2C_WRITE:
> + return true; /* since there's nothing to parse */
> case DP_ENUM_PATH_RESOURCES:
> return drm_dp_sideband_parse_enum_path_resources_ack(raw, msg);
> case DP_ALLOCATE_PAYLOAD:
> @@ -5326,29 +5328,29 @@ static bool remote_i2c_read_ok(const struct i2c_msg
> msgs[], int num)
> msgs[num - 1].len <= 0xff;
> }
>
> -/* I2C device */
> -static int drm_dp_mst_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg
> *msgs,
> -int num)
> +static bool remote_i2c_write_ok(const struct i2c_msg msgs[], int num)
> +{
> + int i;
> +
> + for (i = 0; i < num - 1; i++) {
> + if (msgs[i].flags & I2C_M_RD || !(msgs[i].flags & I2C_M_STOP) ||
> + msgs[i].len > 0xff)
> + return false;
> + }
> +
> + return !(msgs[num - 1].flags & I2C_M_RD) && msgs[num - 1].len <= 0xff;
> +}
> +
> +static int drm_dp_mst_i2c_read(struct drm_dp_mst_branch *mstb,
> +struct drm_dp_mst_port *port,
> +struct i2c_msg *msgs, int num)
> {
> - struct drm_dp_aux *aux = adapter->algo_data;
> - struct drm_dp_mst_port *port = container_of(aux, struct
> drm_dp_mst_port, aux);
> - struct drm_dp_mst_branch *mstb;
> struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> unsigned int i;
> struct drm_dp_sideband_msg_req_body msg;
> struct drm_dp_sideband_msg_tx *txmsg = NULL;
> int ret;
>
> - mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
> - if (!mstb)
> - return -EREMOTEIO;
> -
> - if (!remote_i2c_read_ok(msgs, num)) {
> - DRM_DEBUG_KMS("Unsupported I2C transaction for MST device\n");
> - ret = -EIO;
> - goto out;
> - }
> -
> memset(&msg, 0, sizeof(msg));
> msg.req_type = DP_REMOTE_I2C_READ;
> msg.u.i2c_read.num_transactions = num - 1;
> @@ -5389,6 +5391,78 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter
> *adapter, struct i2c_msg *msgs
> }
> out:
> kfree(txmsg);
> + return ret;
> +}
> +
> +static int drm_dp_mst_i2c_write(struct drm_dp_mst_branch *mstb,
> + struct drm_dp_mst_port *port,
> + struct i2c_msg *msgs, int num)
> +{
> + struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> + unsigned int i;
> + struct drm_dp_sideband_msg_req_body msg;
> + struct drm_dp_sideband_msg_tx *txmsg = NULL;
> + int ret;
> +
> + txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> + if (!txmsg) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + for (i = 0; i < num; i++) {
> + memset(&msg, 0, sizeof(msg));
> + msg.req_type = DP_REMOTE_I2C_WRITE;
> + msg.u.i2c_write.port_number = port->port_num;
> + msg.u.i2c_write.write_i2c_device_id = msgs[i].addr;
> + msg.u.i2c_write.num_bytes = msgs[i].len;
> + msg.u.i2c_write.bytes = msgs[i].buf;
> +
> + memset(txmsg, 0, sizeof(*txmsg));
> + txmsg->dst = m
Re: [PATCH V2 3/8] drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
On 9/1/2020 2:08 PM, Viresh Kumar wrote: On 01-09-20, 13:01, Rajendra Nayak wrote: So FWIU, dpu_unbind() gets called even when dpu_bind() fails for some reason. Ahh, I see. I tried to address that earlier [1] which I realized did not land. I don't think that patch was required, as you can call dev_pm_opp_put_clkname() multiple times and it will return without any errors/crash. We did see a crash (Sai had reported it), perhaps with dsi [1] and not this driver. But it was the same scenario that was possible here as well, which is dev_pm_opp_put_clkname() getting called without dev_pm_opp_set_clkname() being done. I think we ended up passing a NULL as opp_table in that case and the function tries de-referencing it. But with these changes it will be even more broken unless we identify if we failed dpu_bind() before adding the OPP table, while adding it, or all went well with opps and handle things accordingly in dpu_unbind. Maybe not as dev_pm_opp_of_remove_table() can be called multiple times as well without any errors or crash. Can it be called without the driver ever doing a dev_pm_opp_of_add_table()? [1] https://lore.kernel.org/patchwork/patch/1275628/ -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties
On Sat, Aug 29, 2020 at 04:24:52PM +0200, Krzysztof Kozlowski wrote: > Additional properties actually might appear (e.g. assigned-clocks) so > use unevaluatedProperties to fix dtbs_check warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: > system-controller@105c: > 'assigned-clock-parents', 'assigned-clocks' do not match any of the > regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Hi Rob, Could you pick all of my dt-bindings schema patches if they are ok? From this and other series. You already have few of them in your tree so it will help to avoid conflicts. I am afraid that subsystem maintainers can leave them to you and vice versa :) Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/10] arm64: dts: exynos: Replace deprecated "gpios" i2c-gpio property in Exynos5433
On Sat, Aug 29, 2020 at 04:24:58PM +0200, Krzysztof Kozlowski wrote: > "gpios" property is deprecated. Update the Exynos5433 DTS to fix > dtbs_checks warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'sda-gpios' > is a required property > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'scl-gpios' > is a required property > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 4 ++-- Applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] arm64: dts: exynos: Add compatibles to sysreg nodes
On Sat, Aug 29, 2020 at 04:24:59PM +0200, Krzysztof Kozlowski wrote: > System register nodes, implementing syscon binding, should use > appropriate compatible. This fixes dtbs_check warnings: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: syscon@13b8: > compatible: ['syscon'] is not valid under any of the given schemas > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++--- Applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 2/4] ARM: dts: exynos: Move fixed clocks under root node in Exynos3250
On Sat, Aug 29, 2020 at 07:25:30PM +0200, Krzysztof Kozlowski wrote: > The fixed clocks are kept under dedicated node fixed-rate-clocks, thus a > fake "reg" was added. This is not correct with dtschema as fixed-clock > binding does not have a "reg" property: > > arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock@0: 'reg' does not > match any of the regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/boot/dts/exynos3250.dtsi | 42 +-- > 1 file changed, 17 insertions(+), 25 deletions(-) Applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/virtio: fix unblank
On Tue, Aug 18, 2020 at 09:25:10AM +0200, Gerd Hoffmann wrote:
> When going through a disable/enable cycle without changing the
> framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
> skip set_scanout if framebuffer didn't change") causes the screen stay
> blank. Add a bool to force an update to fix that.
>
> v2: use drm_atomic_crtc_needs_modeset() (Daniel).
>
> Cc: 1882...@bugs.launchpad.net
> Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't
> change")
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++
> drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +++-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 9ff9f4ac0522..4ab1b0ba2925 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -138,6 +138,7 @@ struct virtio_gpu_output {
> int cur_x;
> int cur_y;
> bool enabled;
> + bool needs_modeset;
Maybe for a follow-up in -next: The clean atomic way of doing this is to
put this into a virtio_crtc_state, compute it in atomic_check, and then
fish it out (through old_state->state lookup, somewhat contrived I know)
in the commit side. Putting random atomic commit state tracking stuff into
non-state structures without appropriate amounts of locks is kinda iffy
and means more work for reviewers pondering whether it all works
correctly.
Cheers, Daniel
> };
> #define drm_crtc_to_virtio_gpu_output(x) \
> container_of(x, struct virtio_gpu_output, crtc)
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index 2c2742b8d657..6c26b41f4e0d 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -123,6 +123,17 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc
> *crtc,
> static void virtio_gpu_crtc_atomic_flush(struct drm_crtc *crtc,
>struct drm_crtc_state *old_state)
> {
> + struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
> +
> + /*
> + * virtio-gpu can't do modeset and plane update operations
> + * independant from each other. So the actual modeset happens
> + * in the plane update callback, and here we just check
> + * whenever we must force the modeset.
> + */
> + if (drm_atomic_crtc_needs_modeset(crtc->state)) {
> + output->needs_modeset = true;
> + }
> }
>
> static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index 52d24179bcec..65757409d9ed 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -163,7 +163,9 @@ static void virtio_gpu_primary_plane_update(struct
> drm_plane *plane,
> plane->state->src_w != old_state->src_w ||
> plane->state->src_h != old_state->src_h ||
> plane->state->src_x != old_state->src_x ||
> - plane->state->src_y != old_state->src_y) {
> + plane->state->src_y != old_state->src_y ||
> + output->needs_modeset) {
> + output->needs_modeset = false;
> DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
> bo->hw_res_handle,
> plane->state->crtc_w, plane->state->crtc_h,
> --
> 2.18.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property
Hello, On Wed, Aug 26, 2020 at 06:58:50AM +, Biju Das wrote: > > Subject: Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: > > Document vcc-supply property > > > > On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote: > > > Document optional vcc-supply property that may be used as VCC source. > > > > > > Signed-off-by: Biju Das > > > --- > > > New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/ > > > --- > > > .../devicetree/bindings/display/bridge/lvds-codec.yaml | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > index 68951d56ebba..3248be31eceb 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > @@ -79,6 +79,9 @@ properties: > > >The GPIO used to control the power down line of this device. > > > maxItems: 1 > > > > > > + vcc-supply: > > > +maxItems: 1 > > > > Probably should be 'power-supply' to align with the 'simple' panels. > > That's also to signify there's only 1 supply. Using 'vcc' would encourage > > adding 'vdd-supply', 'vddio-supply', etc. A second supply I'll NAK because > > at > > that point it's not a simple bridge with no configuration (it's arguably > > already > > there). > > Yes, I am ok with 'power-supply', since LVDS CODEC driver is generic > and also to align with terminology used in generic 'simple' panels. > > In our case this Receiver converts LVDS signals to RGB signals and fed > this signal to simple panel. > On the receiver part, We need to supply power to TTL output, PLL and > LVDS input. It all derived from the single power source. > > Laurent, Please share you opinion on this. Acked-by: Laurent Pinchart That is, I think it's a good idea to rename it, and I agree with Rob about not adding a second supply. I've applied the modified patch to my tree, and will send a pull request this week. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property
Hi Rob, On Mon, Aug 24, 2020 at 05:04:58PM -0600, Rob Herring wrote: > On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote: > > Document optional vcc-supply property that may be used as VCC source. > > > > Signed-off-by: Biju Das > > --- > > New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/ > > --- > > .../devicetree/bindings/display/bridge/lvds-codec.yaml | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > index 68951d56ebba..3248be31eceb 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > @@ -79,6 +79,9 @@ properties: > >The GPIO used to control the power down line of this device. > > maxItems: 1 > > > > + vcc-supply: > > +maxItems: 1 > > Probably should be 'power-supply' to align with the 'simple' panels. > That's also to signify there's only 1 supply. Using 'vcc' would > encourage adding 'vdd-supply', 'vddio-supply', etc. A second supply I'll > NAK because at that point it's not a simple bridge with no configuration > (it's arguably already there). Fully agreed. Do I get your Ab or Rb line with s/vcc/power/ and the commit message updated to dt-bindings: display: bridge: lvds-codec: Document power-supply property Document optional power-supply property that may be used to specify the regulator powering up the device. ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
On Tue, Sep 01, 2020 at 10:56:42AM +0200, Michel Dänzer wrote: > On 2020-09-01 9:57 a.m., Daniel Vetter wrote: > > On Tue, Aug 25, 2020 at 04:55:28PM +0200, Michel Dänzer wrote: > >> On 2020-08-24 9:43 a.m., Pekka Paalanen wrote: > >> > >>> Sounds like the helpers you refer to are inadequate for your case. > >>> Can't you fix the helpers in the long run and land this patch as an > >>> immediate fix? > >> > >> I'd rather leave working on those helpers to KMS developers. :) > > > > I thought the issue is the rmfb ioctl trickery, which has this assumption > > fully backed in. The wiggle room in there for semantic changes is iirc > > pretty much nil, it took us a pile of patches to just get to the current > > state. So it's not helper code, it's core legacy ioctl code for atomic > > drivers. > > My bad. Should I respin with an amended commit log? Yeah if it's not yet merged then I think would be good to clarify that this assumption is baked into rmfb, and that together with the assumption the the legacy cursor ioctls just work we have fallout. If (and hey I've been on vacations for 2 weeks, so good chances I remebers this all wrong) this is indeed what we discussed a few weeks ago. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
Hi, On Tue, 1 Sep 2020 at 08:13, Daniel Vetter wrote: > I think right thing to do is *shrug*, please use modifiers. They're meant > to solve these kind of problems for real, adding more hacks to paper over > userspace not using modifiers doesn't seem like a good idea. > > Wrt dri3, since we do client-side allocations and don't have modifiers, we > have to pessimistically assume we'll get scanned out. Modifiers and > relevant protocol is fixing this again, but for tegra where we essentially > can't get this right that leaves us in a very tough spot. DRI3 has had modifiers for a couple/few years now ... Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 16/16] drm: Replace mode->export_head with a boolean
On Thu, Apr 30, 2020 at 02:50:52PM +0100, Emil Velikov wrote: > Hi Ville > > I don't fully grok the i915 changes to provide meaningful review. > There are couple of small comments below, but regardless of those Sorry, forgot to reply to this in a timely manner. > > Patches 01-11 and 14-16 are: > Reviewed-by: Emil Velikov > > On Tue, 28 Apr 2020 at 18:20, Ville Syrjala > wrote: > > > The downside is that drm_mode_expose_to_userspace() gets to > > iterate a few more modes. It already was O(n^2), now it's > > a slightly worse O(n^2). > > > Personally I'd drop the O() sentence, or change it to > It already was O(n^2), now it's slightly worse O((n+y)^2). Dropped. > > > Another alternative would be a temp bitmask so we wouldn't have > > to have anything in the mode struct itself. The main issue is > > how large of a bitmask do we need? I guess we could allocate > > it dynamically but that means an extra kcalloc() and an extra > > loop through the modes to count them first (or grow the bitmask > > with krealloc() as needed). > > > If the walk is even remotely close to being an issue, we could > consider the bitmask. > I don't think that's the case yet. > > > Hmm the original code never discards any entries from export_head. > I wonder if there's some corner case where we could end with an "old" > mode showing in the list? No. export_list starts out empty so only the modes we explicitly add to the list can be reached. Thus any dangling pointers in some other mode's export_head are of no concern. Pushed the last few patches to drm-misc-next. Thanks for the reviews everyone. > > For example: > - creates a user mode via drmModeCreatePropertyBlob() > - calls drmModeGetConnector() and sees their mode > - optional (?) does a modeset to and away from said mode > - removes their blob drmModeDestroyPropertyBlob() > - calls drmModeGetConnector() and still sees their removed mode. > > If this is a bug (?) that we care about, we might want to add an igt > test for it. > Conversely, if this is a behaviour we want to keep this patch needs some work. > > HTH > > Emil -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] dt-bindings: sound: samsung-i2s: Use unevaluatedProperties
On Sat, Aug 29, 2020 at 04:24:57PM +0200, Krzysztof Kozlowski wrote: > Additional properties actually might appear (e.g. power-domains) so use > unevaluatedProperties to fix dtbs_check warnings like: Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
On Tue, Sep 1, 2020 at 9:13 AM Daniel Vetter wrote: > > On Tue, Aug 18, 2020 at 04:37:51PM +0200, Thierry Reding wrote: > > On Fri, Aug 14, 2020 at 07:25:17PM +0200, Daniel Vetter wrote: > > > On Fri, Aug 14, 2020 at 7:17 PM Daniel Stone wrote: > > > > > > > > Hi, > > > > > > > > On Fri, 14 Aug 2020 at 17:22, Thierry Reding > > > > wrote: > > > > > I suspect that the reason why this works in X but not in Wayland is > > > > > because X passes the right usage flags, whereas Weston may not. But > > > > > I'll > > > > > have to investigate more in order to be sure. > > > > > > > > Weston allocates its own buffers for displaying the result of > > > > composition through GBM with USE_SCANOUT, which is definitely correct. > > > > > > > > Wayland clients (common to all compositors, in Mesa's > > > > src/egl/drivers/dri2/platform_wayland.c) allocate with USE_SHARED but > > > > _not_ USE_SCANOUT, which is correct in that they are guaranteed to be > > > > shared, but not guaranteed to be scanned out. The expectation is that > > > > non-scanout-compatible buffers would be rejected by gbm_bo_import if > > > > not drmModeAddFB2. > > > > > > > > One difference between Weston and all other compositors (GNOME Shell, > > > > KWin, Sway, etc) is that Weston uses KMS planes for composition when > > > > it can (i.e. when gbm_bo_import from dmabuf + drmModeAddFB2 from > > > > gbm_bo handle + atomic check succeed), but the other compositors only > > > > use the GPU. So if you have different assumptions about the layout of > > > > imported buffers between the GPU and KMS, that would explain a fair > > > > bit. > > > > > > Yeah non-modifiered multi-gpu (of any kind) is pretty much hopeless I > > > think. I guess the only option is if the tegra mesa driver forces > > > linear and an extra copy on everything that's USE_SHARED or > > > USE_SCANOUT. > > > > I ended up trying this, but this fails for the X case, unfortunately, > > because there doesn't seem to be a good synchronization point at which > > the de-tiling blit could be done. Weston and kmscube end up calling a > > gallium driver's ->flush_resource() implementation, but that never > > happens for X and glamor. > > > > But after looking into this some more, I don't think that's even the > > problem that we're facing here. The root of the problem that causes the > > glxgears crash that Karol was originally reporting is because we end up > > allocating the glxgears pixmaps using the dri3 loader from Mesa. But the > > dri3 loader will unconditionally pass both __DRI_IMAGE_USE_SHARE and > > __DRI_IMAGE_USE_SCANOUT, irrespective of whether the buffer will end up > > being scanned out directly or whether it will be composited onto the > > root window. > > > > What exactly happens depends on whether I run glxgears in fullscreen > > mode or windowed mode. In windowed mode, the glxgears buffers will be > > composited onto the root window, so there's no need for the buffers to > > be scanout-capable. If I modify the dri3 loader to not pass those flags > > I can make this work just fine. > > > > When I run glxgears in fullscreen mode, the modesetting driver ends up > > wanting to display the glxgears buffer directly on screen, without > > compositing it onto the root window. This ends up working if I leave out > > the _USE_SHARE and _USE_SCANOUT flags, but I notice that the kernel then > > complains about being unable to create a framebuffer, which in turn is > > caused by the fact that those buffers are not exported (the Tegra Mesa > > driver only exports/imports buffers that are meant for scanout, under > > the assumption that those are the only ones that will ever need to be > > used by KMS) and therefore Tegra DRM doesn't have a valid handle for > > them. > > > > So I think an ideal solution would probably be for glxgears to somehow > > pass better usage information when allocating buffers, but I suspect > > that that's just not possible, or would be way too much work and require > > additional protocol at the DRI level, so it's not really a good option > > when all we want to fix is backwards-compatibility with pre-modifiers > > userspace. > > > > Given that glamor also doesn't have any synchronization points, I don't > > see how I can implement the de-tiling blit reliably. I was wondering if > > it shouldn't be possible to flush the framebuffer resource (and perform > > the blit) at presentation time, but I couldn't find a good entry point > > to do this. > > > > One other solution that occurred to me was to reintroduce an old IOCTL > > that we used to have in the Tegra DRM driver. That IOCTL was meant to > > attach tiling meta data to an imported buffer and was basically a > > simplified, driver-specific way of doing framebuffer modifiers. That's > > a very ugly solution, but it would allow us to be backwards-compatible > > with pre-modifiers userspace and even use an optimal path for rendering > > and scanning out. The only prerequisite would be that the driver IOCTL > > w
Re: [PATCH v6 1/7] drm/i915: Add enable/disable flip done and flip done handler
On Fri, Aug 07, 2020 at 03:05:45PM +0530, Karthik B S wrote:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
>
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
>
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
> flips without pageflip events.
>
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the beginning of
> flip_done_handler to remove sporadic WARN_ON that is seen.
>
> v4: -Calculate timestamps using flip done time stamp and current
> timestamp for async flips (Ville)
>
> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
> static.(Reported-by: kernel test robot )
> -Fix the typo in commit message.
>
> v6: -Revert back to old time stamping code.
> -Remove the break while calling skl_enable_flip_done. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +++
> drivers/gpu/drm/i915/i915_irq.c | 52
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 522c772a2111..1ac2e6f27597 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15562,6 +15562,11 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>
> intel_dbuf_pre_plane_update(state);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_enable_flip_done(&crtc->base);
> + }
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.commit_modeset_enables(state);
>
> @@ -15583,6 +15588,9 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> drm_atomic_helper_wait_for_flip_done(dev, &state->base);
>
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(&crtc->base);
Where do we wait for the flip done? Can't see such code anywhere.
> +
> if (new_crtc_state->hw.active &&
> !needs_modeset(new_crtc_state) &&
> !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f113fe44572b..6cc129b031d3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1296,6 +1296,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_pending_vblank_event *e = crtc_state->event;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + crtc_state->event = NULL;
> +
> + drm_crtc_send_vblank_event(&crtc->base, e);
> +
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> +}
>
> static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> @@ -2390,6 +2407,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> if (iir & GEN8_PIPE_VBLANK)
> intel_handle_vblank(dev_priv, pipe);
>
> + if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
> + flip_done_handler(dev_priv, pipe);
> +
> if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
> hsw_pipe_crc_irq_handler(dev_priv, pipe);
>
> @@ -2711,6 +2731,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
> return 0;
> }
>
> +void skl_enable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pip
Re: [PATCH v6 2/7] drm/i915: Add support for async flips in I915
On Fri, Aug 07, 2020 at 03:05:46PM +0530, Karthik B S wrote:
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
>
> v2: -Move the Async flip enablement to individual patch (Paulo)
>
> v3: -Rebased.
>
> v4: -Add separate plane hook for async flip case (Ville)
>
> v5: -Rebased.
>
> v6: -Move the plane hook to separate patch. (Paulo)
> -Remove the early return in skl_plane_ctl. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 3 +++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1ac2e6f27597..ce2b0c14a073 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4768,6 +4768,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state
> *crtc_state,
>
> plane_ctl = PLANE_CTL_ENABLE;
>
> + if (crtc_state->uapi.async_flip)
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;
Hmm. We might want to put that into skl_plane_ctl_crtc() since it's
a crtc-wide thing,
> +
> if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv)) {
> plane_ctl |= skl_plane_ctl_alpha(plane_state);
> plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e85c6fc1f3cb..3f88d9ac90a8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6924,6 +6924,7 @@ enum {
> #define PLANE_CTL_TILED_X (1 << 10)
> #define PLANE_CTL_TILED_Y (4 << 10)
> #define PLANE_CTL_TILED_YF (5 << 10)
> +#define PLANE_CTL_ASYNC_FLIP (1 << 9)
> #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8)
> #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
> #define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/7] drm/i915: Add checks specific to async flips
On Fri, Aug 07, 2020 at 03:05:47PM +0530, Karthik B S wrote:
> If flip is requested on any other plane, reject it.
>
> Make sure there is no change in fbc, offset and framebuffer modifiers
> when async flip is requested.
>
> If any of these are modified, reject async flip.
>
> v2: -Replace DRM_ERROR (Paulo)
> -Add check for changes in OFFSET, FBC, RC(Paulo)
>
> v3: -Removed TODO as benchmarking tests have been run now.
>
> v4: -Added more state checks for async flip (Ville)
> -Moved intel_atomic_check_async to the end of intel_atomic_check
> as the plane checks needs to pass before this. (Ville)
> -Removed crtc_state->enable_fbc check. (Ville)
> -Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async
> flip case as scanline counter is not reliable here.
>
> v5: -Fix typo and other check patch errors seen in CI
> in 'intel_atomic_check_async' function.
>
> v6: -Don't call intel_atomic_check_async multiple times. (Ville)
> -Remove the check for n_planes in intel_atomic_check_async
> -Added documentation for async flips. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 113 +++
> 1 file changed, 113 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ce2b0c14a073..9629c751d2af 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14832,6 +14832,110 @@ static bool
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
> return false;
> }
>
> +/**
> + * DOC: asynchronous flip implementation
> + *
> + * Asynchronous page flip is the implementation for the
> DRM_MODE_PAGE_FLIP_ASYNC
> + * flag. Currently async flip is only supported via the drmModePageFlip
> IOCTL.
> + * Correspondingly, support is currently added for primary plane only.
> + *
> + * Async flip can only change the plane surface address, so anything else
> + * changing is rejected from the intel_atomic_check_async() function.
> + * Once this check is cleared, flip done interrupt is enabled using
> + * the skl_enable_flip_done() function.
> + *
> + * As soon as the surface address register is written, flip done interrupt is
> + * generated and the requested events are sent to the usersapce in the
> interrupt
> + * handler itself. The timestamp and sequence sent during the flip done event
> + * correspond to the last vblank and have no relation to the actual time when
> + * the flip done event was sent.
> + */
> +
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> + struct intel_plane_state *new_plane_state, *old_plane_state;
> + struct intel_crtc *crtc;
> + struct intel_plane *intel_plane;
s/intel_plane/plane/
> + int i;
> +
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (needs_modeset(new_crtc_state)) {
> + DRM_DEBUG_KMS("Modeset Required. Async flip not
> supported\n");
> + return -EINVAL;
> + }
> +
> + if (!new_crtc_state->uapi.active) {
> + DRM_DEBUG_KMS("CRTC inactive\n");
> + return -EINVAL;
> + }
All the uapi.foo stuff should be hw.foo most likely.
> + if (old_crtc_state->active_planes !=
> new_crtc_state->active_planes) {
> + DRM_DEBUG_KMS("Active planes cannot be changed during
> async flip\n");
> + return -EINVAL;
> + }
> + }
> +
> + for_each_oldnew_intel_plane_in_state(state, intel_plane,
> old_plane_state,
> + new_plane_state, i) {
> + /*TODO: Async flip is only supported through the page flip IOCTL
> + * as of now. So support currently added for primary plane only.
> + * Support for other planes should be added when async flip is
> + * enabled in the atomic IOCTL path.
> + */
> + if (intel_plane->id != PLANE_PRIMARY)
> + return -EINVAL;
> +
> + if (old_plane_state->color_plane[0].x !=
> + new_plane_state->color_plane[0].x ||
> + old_plane_state->color_plane[0].y !=
> + new_plane_state->color_plane[0].y) {
> + DRM_DEBUG_KMS("Offsets cannot be changed in async
> flip\n");
> + return -EINVAL;
> + }
> +
> + if (old_plane_state->uapi.fb->modifier !=
> + new_plane_state->uapi.fb->modifier) {
> + DRM_DEBUG_KMS("Framebuffer modifiers cannot be changed
> in async flip\n");
> + return -EINVAL;
> +
Re: [PATCH v6 4/7] drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
On Fri, Aug 07, 2020 at 03:05:48PM +0530, Karthik B S wrote:
> Since the flip done event will be sent in the flip_done_handler,
> no need to add the event to the list and delay it for later.
>
> v2: -Moved the async check above vblank_get as it
> was causing issues for PSR.
>
> v3: -No need to wait for vblank to pass, as this wait was causing a
> 16ms delay once every few flips.
>
> v4: -Rebased.
>
> v5: -Rebased.
>
> v6: -Rebased.
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index c26ca029fc0a..2b2d96c59d7f 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -93,6 +93,9 @@ void intel_pipe_update_start(const struct intel_crtc_state
> *new_crtc_state)
> DEFINE_WAIT(wait);
> u32 psr_status;
>
> + if (new_crtc_state->uapi.async_flip)
> + goto irq_disable;
We shouldn't really need the irq disable at all if we don't do the
vblank evade. And if we only write ctl+surf then atomicity is already
guaranteed by the hw.
> +
> vblank_start = adjusted_mode->crtc_vblank_start;
> if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> vblank_start = DIV_ROUND_UP(vblank_start, 2);
> @@ -206,7 +209,7 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
>* Would be slightly nice to just grab the vblank count and arm the
>* event outside of the critical section - the spinlock might spin for a
>* while ... */
> - if (new_crtc_state->uapi.event) {
> + if (new_crtc_state->uapi.event && !new_crtc_state->uapi.async_flip) {
> drm_WARN_ON(&dev_priv->drm,
> drm_crtc_vblank_get(&crtc->base) != 0);
>
> @@ -220,6 +223,9 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
>
> local_irq_enable();
>
> + if (new_crtc_state->uapi.async_flip)
> + return;
> +
> if (intel_vgpu_active(dev_priv))
> return;
>
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/7] drm/i915: Add dedicated plane hook for async flip case
On Fri, Aug 07, 2020 at 03:05:49PM +0530, Karthik B S wrote:
> This hook is added to avoid writing other plane registers in case of
> async flips, so that we do not write the double buffered registers
> during async surface address update.
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 2b2d96c59d7f..1c03546a4d2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -609,6 +609,24 @@ icl_program_input_csc(struct intel_plane *plane,
> PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
> }
>
> +static void
> +skl_program_async_surface_address(struct drm_i915_private *dev_priv,
> + const struct intel_plane_state *plane_state,
> + enum pipe pipe, enum plane_id plane_id,
> + u32 surf_addr)
> +{
> + unsigned long irqflags;
> + u32 plane_ctl = plane_state->ctl;
Need the bits from skl_plane_ctl_crtc() too.
> +
> + spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
> + intel_plane_ggtt_offset(plane_state) + surf_addr);
> +
> + spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> +}
> +
> static void
> skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -637,6 +655,13 @@ skl_program_plane(struct intel_plane *plane,
> u32 keymsk, keymax;
> u32 plane_ctl = plane_state->ctl;
>
> + /* During Async flip, no other updates are allowed */
> + if (crtc_state->uapi.async_flip) {
> + skl_program_async_surface_address(dev_priv, plane_state,
> + pipe, plane_id, surf_addr);
> + return;
> + }
I'd suggest adding a vfunc for this. Should be able to call it from
intel_update_plane(). That way we don't need to patch it into each
and every .update_plane() implementation.
> +
> plane_ctl |= skl_plane_ctl_crtc(crtc_state);
>
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/7] drm/i915: Add enable/disable flip done and flip done handler
On Fri, Aug 07, 2020 at 03:05:45PM +0530, Karthik B S wrote:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
>
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
>
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
> flips without pageflip events.
>
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the beginning of
> flip_done_handler to remove sporadic WARN_ON that is seen.
>
> v4: -Calculate timestamps using flip done time stamp and current
> timestamp for async flips (Ville)
>
> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
> static.(Reported-by: kernel test robot )
> -Fix the typo in commit message.
>
> v6: -Revert back to old time stamping code.
> -Remove the break while calling skl_enable_flip_done. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +++
> drivers/gpu/drm/i915/i915_irq.c | 52
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 522c772a2111..1ac2e6f27597 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15562,6 +15562,11 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>
> intel_dbuf_pre_plane_update(state);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_enable_flip_done(&crtc->base);
> + }
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.commit_modeset_enables(state);
>
> @@ -15583,6 +15588,9 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> drm_atomic_helper_wait_for_flip_done(dev, &state->base);
>
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(&crtc->base);
> +
> if (new_crtc_state->hw.active &&
> !needs_modeset(new_crtc_state) &&
> !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f113fe44572b..6cc129b031d3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1296,6 +1296,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_pending_vblank_event *e = crtc_state->event;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + crtc_state->event = NULL;
> +
> + drm_crtc_send_vblank_event(&crtc->base, e);
The timestamp is going to be wrong here. We should perhaps just sample
the current time+frame counter here.
> +
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> +}
>
> static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> @@ -2390,6 +2407,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> if (iir & GEN8_PIPE_VBLANK)
> intel_handle_vblank(dev_priv, pipe);
>
> + if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
> + flip_done_handler(dev_priv, pipe);
> +
> if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
> hsw_pipe_crc_irq_handler(dev_priv, pipe);
>
> @@ -2711,6 +2731,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
> return 0;
> }
>
> +void skl_enable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> +
Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi Swapnil,
On 31/08/2020 11:23, Swapnil Jakhade wrote:
> +static int cdns_mhdp_validate_mode_params(struct cdns_mhdp_device *mhdp,
> + const struct drm_display_mode *mode,
> + struct drm_bridge_state *bridge_state)
> +{
> + u32 tu_size = 30, line_thresh1, line_thresh2, line_thresh = 0;
> + u32 rate, vs, vs_f, required_bandwidth, available_bandwidth;
> + struct cdns_mhdp_bridge_state *state;
> + int pxlclock;
> + u32 bpp;
> +
> + state = to_cdns_mhdp_bridge_state(bridge_state);
> +
> + pxlclock = mode->crtc_clock;
> +
> + /* Get rate in MSymbols per second per lane */
> + rate = mhdp->link.rate / 1000;
> +
> + bpp = cdns_mhdp_get_bpp(&mhdp->display_fmt);
None of the above are used when calling cdns_mhdp_bandwidth_ok(). For clarity,
I'd move the above
lines a bit closer to where they are needed, as currently it makes me think the
above values are
used when checking the bandwidth.
> + if (!cdns_mhdp_bandwidth_ok(mhdp, mode, mhdp->link.num_lanes,
> + mhdp->link.rate)) {
> + dev_err(mhdp->dev, "%s: Not enough BW for %s (%u lanes at %u
> Mbps)\n",
> + __func__, mode->name, mhdp->link.num_lanes,
> + mhdp->link.rate / 100);
> + return -EINVAL;
> + }
> +
> + /* find optimal tu_size */
> + required_bandwidth = pxlclock * bpp / 8;
> + available_bandwidth = mhdp->link.num_lanes * rate;
> + do {
> + tu_size += 2;
> +
> + vs_f = tu_size * required_bandwidth / available_bandwidth;
> + vs = vs_f / 1000;
> + vs_f = vs_f % 1000;
> + /* Downspreading is unused currently */
> + } while ((vs == 1 || ((vs_f > 850 || vs_f < 100) && vs_f != 0) ||
> + tu_size - vs < 2) && tu_size < 64);
> +
> + if (vs > 64) {
> + dev_err(mhdp->dev,
> + "%s: No space for framing %s (%u lanes at %u Mbps)\n",
> + __func__, mode->name, mhdp->link.num_lanes,
> + mhdp->link.rate / 100);
> + return -EINVAL;
> + }
> +
> + if (vs == tu_size)
> + vs = tu_size - 1;
> +
> + line_thresh1 = ((vs + 1) << 5) * 8 / bpp;
> + line_thresh2 = (pxlclock << 5) / 1000 / rate * (vs + 1) - (1 << 5);
> + line_thresh = line_thresh1 - line_thresh2 / mhdp->link.num_lanes;
> + line_thresh = (line_thresh >> 5) + 2;
> +
> + state->vs = vs;
> + state->tu_size = tu_size;
> + state->line_thresh = line_thresh;
> +
> + return 0;
> +}
> +
> +static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
> + const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
> + int ret;
> +
> + mutex_lock(&mhdp->link_mutex);
> +
> + if (!mhdp->plugged) {
> + mhdp->link.rate = mhdp->host.link_rate;
> + mhdp->link.num_lanes = mhdp->host.lanes_cnt;
> + }
> +
> + ret = cdns_mhdp_validate_mode_params(mhdp, mode, bridge_state);
> +
> + mutex_unlock(&mhdp->link_mutex);
> +
> + return ret;
> +}
Laurent mentioned that atomic_check should not change state. Note that
cdns_mhdp_validate_mode_params also changes state, as it calculates tu_size, vs
and line_thresh.
There seems to be issues with mode changes, but I think the first step would be
to clarify the
related code a bit. cdns_mhdp_validate_mode_params() is misnamed, I think it
should be renamed to
calculate_tu or something like that.
cdns_mhdp_bandwidth_ok() should take display_fmt or bpp as a parameter, as
currently it digs that up
from the current state.
Probably cdns_mhdp_validate_mode_params() would be better if it doesn't write
the result to the
state, but returns the values. That way it could also be used to verify if
suitable settings can be
found, without changing the state.
The are two issues I see with some testing, which are probably related.
The first one is that if I run kmstest with a new mode, I see tu-size & co
being calculated. But the
calculation happens before link training, which doesn't make sense. So I think
what's done here is
that atomic_check causes tu-size calculations, then atomic_enable does link
training and enables the
video.
The second happens when my monitor fails with the first CR after power-on, and
the driver drops
number-of-lanes to 2. It goes like this:
The driver is loaded. Based on EDID, fbdev is created with 1920x1200. Link
training is done, which
has the CR issue, and because of that the actual mode that we get is 1280x960.
I get a proper
picture here, so far so good.
Then if I run kmstest, it only
Re: [PATCH 02/23] drm/radeon/ttm: don't store driver copy of device pointer.
On Wed, Aug 26, 2020 at 11:44:07AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This can be gotten back from bdev.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index f6311f404db8..0923a8601112 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -412,7 +412,6 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device
> *bdev, struct ttm_reso
> */
> struct radeon_ttm_tt {
> struct ttm_dma_tt ttm;
> - struct radeon_device*rdev;
At least for amdgpu the drm_device embedding stuff landed, so I think we
can drop a lot more of these all over because upcasting from a struct
drm_device * to tha adev is just a container_of.
Entirely separate bikeshed cleanup, but I think it'd help to make ttm feel
a bit more like a helper for gpu drivers than it's entirely separate world
:-)
Cheers, Daniel
> u64 offset;
>
> uint64_tuserptr;
> @@ -515,6 +514,7 @@ static int radeon_ttm_backend_bind(struct ttm_tt *ttm,
> struct ttm_resource *bo_mem)
> {
> struct radeon_ttm_tt *gtt = (void*)ttm;
> + struct radeon_device *rdev = radeon_get_rdev(ttm->bdev);
> uint32_t flags = RADEON_GART_PAGE_VALID | RADEON_GART_PAGE_READ |
> RADEON_GART_PAGE_WRITE;
> int r;
> @@ -531,7 +531,7 @@ static int radeon_ttm_backend_bind(struct ttm_tt *ttm,
> }
> if (ttm->caching_state == tt_cached)
> flags |= RADEON_GART_PAGE_SNOOP;
> - r = radeon_gart_bind(gtt->rdev, gtt->offset, ttm->num_pages,
> + r = radeon_gart_bind(rdev, gtt->offset, ttm->num_pages,
>ttm->pages, gtt->ttm.dma_address, flags);
> if (r) {
> DRM_ERROR("failed to bind %lu pages at 0x%08X\n",
> @@ -544,8 +544,9 @@ static int radeon_ttm_backend_bind(struct ttm_tt *ttm,
> static void radeon_ttm_backend_unbind(struct ttm_tt *ttm)
> {
> struct radeon_ttm_tt *gtt = (void *)ttm;
> + struct radeon_device *rdev = radeon_get_rdev(ttm->bdev);
>
> - radeon_gart_unbind(gtt->rdev, gtt->offset, ttm->num_pages);
> + radeon_gart_unbind(rdev, gtt->offset, ttm->num_pages);
>
> if (gtt->userptr)
> radeon_ttm_tt_unpin_userptr(ttm);
> @@ -584,7 +585,6 @@ static struct ttm_tt *radeon_ttm_tt_create(struct
> ttm_buffer_object *bo,
> return NULL;
> }
> gtt->ttm.ttm.func = &radeon_backend_func;
> - gtt->rdev = rdev;
> if (ttm_dma_tt_init(>t->ttm, bo, page_flags)) {
> kfree(gtt);
> return NULL;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
On 01/09/2020 10:46, Tomi Valkeinen wrote: > I think the above suggests that the driver is not properly updating all the > registers based on the > new mode and link. I tried adding cdns_mhdp_validate_mode_params() call to > cdns_mhdp_atomic_enable(), so that tu-size etc will be calculated, but that > did not fix the problem. Oh, it actually did fix the problem. It was just that my first hack updated the old state, but after changing the code to call cdns_mhdp_atomic_enable() with new_state I see it helps with the issue. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: start using more of the extended receiver caps
In the future, we'll be needing more of the extended receiver capability
field starting at DPCD address 0x2200. (Specifically, we'll need main
link channel coding cap for DP 2.0.) Start using it now to not miss out
later on.
Cc: Lyude Paul
Signed-off-by: Jani Nikula
---
I guess this can be merged after the topic branch to drm-misc-next or
so, but I'd prefer to have this fairly early on to catch any potential
issues.
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c8..3a3c238452df 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- u8 dpcd_ext[6];
+ u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
int ret;
/*
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi Swapnil, On 31/08/2020 11:23, Swapnil Jakhade wrote: > + line_thresh1 = ((vs + 1) << 5) * 8 / bpp; > + line_thresh2 = (pxlclock << 5) / 1000 / rate * (vs + 1) - (1 << 5); > + line_thresh = line_thresh1 - line_thresh2 / mhdp->link.num_lanes; > + line_thresh = (line_thresh >> 5) + 2; These calculations do not seem to go correctly. There's no comment what's the logic here, but e.g. for 640x480 (pxlclock 31500) with 1.62Gbps link, I get vs=4, and then the second line above comes to: (31500 << 5) / 1000 / 162 * (4+1) - (1<<5) = -0.8893 The result is line_thresh of 100663299. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
On Tue, Sep 01, 2020 at 03:30:17PM +0800, crj wrote:
> Hi,
>
> 在 2020/9/1 3:53, Ville Syrjälä 写道:
> > On Fri, Aug 28, 2020 at 09:07:13AM +0800, crj wrote:
> > > Hi Ville Syrjälä,
> > >
> > > 在 2020/8/27 18:57, Ville Syrjälä 写道:
> > > > On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
> > > > > CEA 861.3 spec adds colorimetry data block for HDMI.
> > > > > Parsing the block to get the colorimetry data from
> > > > > panel.
> > > > And what exactly do you want to do with that data?
> > >
> > > We can get colorimetry data block from edid then support
> > >
> > > HDMI colorimetry such as BT2020.
> > But what do you want to do with it? The patch does nothing
> > functional.
>
> If we want to output BT2020 in HDMI driver, we can know whether TV support
> BT2020
>
> via connector->display_info.hdmi.colorimetry. If TV don't support BT2020,
> HDMI shouldn't
>
> ouput in BT2020.
You need to include these driver patches in your series, not just the core
changes. We don't review/merge just core enabling patches, we need an
entire functional slice.
-Daniel
>
> > > > > Signed-off-by: Algea Cao
> > > > > ---
> > > > >
> > > > >drivers/gpu/drm/drm_edid.c | 45
> > > > > +
> > > > >include/drm/drm_connector.h | 3 +++
> > > > >include/drm/drm_edid.h | 14
> > > > >3 files changed, 62 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > > index 31496b6cfc56..67e607c04492 100644
> > > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > > @@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector
> > > > > *connector, struct edid *edid,
> > > > >#define VIDEO_BLOCK 0x02
> > > > >#define VENDOR_BLOCK0x03
> > > > >#define SPEAKER_BLOCK 0x04
> > > > > +#define COLORIMETRY_DATA_BLOCK 0x5
> > > > >#define HDR_STATIC_METADATA_BLOCK 0x6
> > > > >#define USE_EXTENDED_TAG 0x07
> > > > >#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> > > > > @@ -4309,6 +4310,48 @@ static void
> > > > > fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
> > > > > mode->clock = clock;
> > > > >}
> > > > > +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> > > > > +{
> > > > > + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> > > > > + return false;
> > > > > +
> > > > > + if (db[1] != COLORIMETRY_DATA_BLOCK)
> > > > > + return false;
> > > > > +
> > > > > + if (cea_db_payload_len(db) < 2)
> > > > > + return false;
> > > > > +
> > > > > + return true;
> > > > > +}
> > > > > +
> > > > > +static void
> > > > > +drm_parse_colorimetry_data_block(struct drm_connector *connector,
> > > > > const u8 *db)
> > > > > +{
> > > > > + struct drm_hdmi_info *info = &connector->display_info.hdmi;
> > > > > +
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> > > > > + if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> > > > > + /* Byte 4 Bit 7: DCI-P3 */
> > > > > + if (db[3] & BIT(7))
> > > > > + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> > > > > +
> > > > > + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n",
> > > > > info->colorimetry);
> > > > > +}
> > > > > +
> > > > >static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> > > > >{
> > > > > if (cea_db_tag(db) != USE_EXTENDED_TAG)
> > > > > @@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct
> > > > > drm_connector *connector,
> > > > > drm_parse_vcdb(connector, db);
> > > > > if (cea_db_is_hdmi_hdr_metadata_block(db))
> > > > > drm_parse_hdr_metadata_block(connector, db);
> > > > > + if (cea_db_is_hdmi_colorimetry_data_block(db))
> > > > > + drm_parse_colorimetry_data_block(connector, db);
> > > > > }
> > > > >}
> > > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > > index af145608b5ed.
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Tue, Sep 01, 2020 at 08:57:37AM +, Simon Ser wrote: > On Monday, August 31, 2020 3:48 PM, Ville Syrjälä > wrote: > > > > > It doesn't seem like this IGT test's goal is to exercise support for > > > > gamma LUTs. Does the test just tries to reset the gamma LUT to linear? > > > > If so, I think the IGT test should be fixed to ignore "I don't support > > > > gamma" errors. > > > > > > It seems like that IGT test pixel-format is to make gamma lut like below. > > > for (i = 0; i < lut_size; i++) > > > lut[i] = (i * 0x / (lut_size - 1)) & mask; > > > And set this table to drm driver. and test begins. It's the test about > > > pixel > > > format. I think you're right. It's not about gamma lut. > > > > The point of the gamma LUT stuff in the pixel format test is to throw > > away a bunch of the lsbs so that the test passes when the result is > > "close enough" to the 8bpc RGB reference image. Without it we would > > never get a crc match when testing non-8bpc or YCbCr formats. > > OK, that makes sense. Would it be sensible to: > > - Don't set gamma if the pixel format being tested is 8bpc Hm not sure what 8bpc format you mean here, because we have C8 (needs gamma table or doesn't work) and the 8b greyscale one with the R8 one. If you ask for legacy 8bpc you get C8. > - Make the test skip if the pixel format is >8bpc and gamma isn't > supported Yeah the test should skip if gamma isn't there. -Daniel > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix kernel-doc warning in dma-fence.c
On Mon, Aug 31, 2020 at 12:02:03PM +0200, Christian König wrote: > Am 31.08.20 um 06:17 schrieb Randy Dunlap: > > Add @cookie to dma_fence_end_signalling() to prevent kernel-doc > > warning in drivers/dma-buf/dma-fence.c: > > > > ../drivers/dma-buf/dma-fence.c:291: warning: Function parameter or member > > 'cookie' not described in 'dma_fence_end_signalling' > > > > Signed-off-by: Randy Dunlap > > Cc: Sumit Semwal > > Cc: Gustavo Padovan > > Cc: Christian König > > Cc: linux-me...@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Acked-by: Christian König Will you merge these two to drm-misc-fixes or should someone else? Always a bit confusing when maintainers reply with acks/r-b but not what they'll do with the patch :-) Cheers, Daniel > > > --- > > drivers/dma-buf/dma-fence.c |1 + > > 1 file changed, 1 insertion(+) > > > > --- lnx-59-rc3.orig/drivers/dma-buf/dma-fence.c > > +++ lnx-59-rc3/drivers/dma-buf/dma-fence.c > > @@ -283,6 +283,7 @@ EXPORT_SYMBOL(dma_fence_begin_signalling > > /** > >* dma_fence_end_signalling - end a critical DMA fence signalling section > > + * @cookie: opaque cookie from dma_fence_begin_signalling() > >* > >* Closes a critical section annotation opened by > > dma_fence_begin_signalling(). > >*/ > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: tosa_bl: Include the right header
On Wed, Aug 26, 2020 at 09:05:40AM +0200, Linus Walleij wrote:
> The Tosa backlight driver was converted to use GPIO descriptors
> in 0b0cb52bd80eda76c4b9921f5cf9c1b709d44e83
> ("video: backlight: tosa: Use GPIO lookup table") but
> still includes rather than .
> Fix it.
>
> Cc: Arnd Bergmann
> Cc: Robert Jarzmik
> Signed-off-by: Linus Walleij
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/tosa_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/tosa_bl.c
> b/drivers/video/backlight/tosa_bl.c
> index cff5e96fd988..6df6fcd132e3 100644
> --- a/drivers/video/backlight/tosa_bl.c
> +++ b/drivers/video/backlight/tosa_bl.c
> @@ -11,7 +11,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: tosa_lcd: Include the right header
On Wed, Aug 26, 2020 at 09:09:17AM +0200, Linus Walleij wrote:
> The Tosa backlight LCDE driver was converted to use GPIO descriptors
> in 0b0cb52bd80eda76c4b9921f5cf9c1b709d44e83
> ("video: backlight: tosa: Use GPIO lookup table") but
> still includes rather than .
> Fix it.
>
> Cc: Arnd Bergmann
> Cc: Robert Jarzmik
> Signed-off-by: Linus Walleij
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/tosa_lcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/tosa_lcd.c
> b/drivers/video/backlight/tosa_lcd.c
> index 113116d3585c..38765544345b 100644
> --- a/drivers/video/backlight/tosa_lcd.c
> +++ b/drivers/video/backlight/tosa_lcd.c
> @@ -12,7 +12,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix kernel-doc warning in dma-fence.c
Am 01.09.20 um 15:32 schrieb Daniel Vetter: On Mon, Aug 31, 2020 at 12:02:03PM +0200, Christian König wrote: Am 31.08.20 um 06:17 schrieb Randy Dunlap: Add @cookie to dma_fence_end_signalling() to prevent kernel-doc warning in drivers/dma-buf/dma-fence.c: ../drivers/dma-buf/dma-fence.c:291: warning: Function parameter or member 'cookie' not described in 'dma_fence_end_signalling' Signed-off-by: Randy Dunlap Cc: Sumit Semwal Cc: Gustavo Padovan Cc: Christian König Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Acked-by: Christian König Will you merge these two to drm-misc-fixes or should someone else? I was wondering the same thing and just waiting for Randy to reply with please pick them up or I'm going to push them because I have commit access. Regards, Christian. Always a bit confusing when maintainers reply with acks/r-b but not what they'll do with the patch :-) Cheers, Daniel --- drivers/dma-buf/dma-fence.c |1 + 1 file changed, 1 insertion(+) --- lnx-59-rc3.orig/drivers/dma-buf/dma-fence.c +++ lnx-59-rc3/drivers/dma-buf/dma-fence.c @@ -283,6 +283,7 @@ EXPORT_SYMBOL(dma_fence_begin_signalling /** * dma_fence_end_signalling - end a critical DMA fence signalling section + * @cookie: opaque cookie from dma_fence_begin_signalling() * * Closes a critical section annotation opened by dma_fence_begin_signalling(). */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C4d8d43fbbb06475f964308d84e7b6a05%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637345639254630346&sdata=hxraBxca4oxH%2BsvRJaDT44kFp%2BAXlun2GaLYY6L6LdA%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amdgpu: Embed drm_device into amdgpu_device (v2)
On Tue, Sep 1, 2020 at 3:44 AM Daniel Vetter wrote:
>
> On Wed, Aug 19, 2020 at 01:00:42AM -0400, Luben Tuikov wrote:
> > a) Embed struct drm_device into struct amdgpu_device.
> > b) Modify the inline-f drm_to_adev() accordingly.
> > c) Modify the inline-f adev_to_drm() accordingly.
> > d) Eliminate the use of drm_device.dev_private,
> >in amdgpu.
> > e) Switch from using drm_dev_alloc() to
> >drm_dev_init().
> > f) Add a DRM driver release function, which frees
> >the container amdgpu_device after all krefs on
> >the contained drm_device have been released.
> >
> > v2: Split out adding adev_to_drm() into its own
> > patch (previous commit), making this patch
> > more succinct and clear. More detailed commit
> > description.
> >
> > Signed-off-by: Luben Tuikov
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 ++---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 43 ++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 20 +++---
> > 4 files changed, 43 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 735480cc7dcf..107a6ec920f7 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -724,8 +724,8 @@ struct amd_powerplay {
> > #define AMDGPU_MAX_DF_PERFMONS 4
> > struct amdgpu_device {
> > struct device *dev;
> > - struct drm_device *ddev;
> > struct pci_dev *pdev;
> > + struct drm_device ddev;
> >
> > #ifdef CONFIG_DRM_AMD_ACP
> > struct amdgpu_acp acp;
> > @@ -990,12 +990,12 @@ struct amdgpu_device {
> >
> > static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
> > {
> > - return ddev->dev_private;
> > + return container_of(ddev, struct amdgpu_device, ddev);
> > }
> >
> > static inline struct drm_device *adev_to_drm(struct amdgpu_device *adev)
> > {
> > - return adev->ddev;
> > + return &adev->ddev;
> > }
> >
> > static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device
> > *bdev)
> > @@ -1004,8 +1004,6 @@ static inline struct amdgpu_device
> > *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
> > }
> >
> > int amdgpu_device_init(struct amdgpu_device *adev,
> > -struct drm_device *ddev,
> > -struct pci_dev *pdev,
> > uint32_t flags);
> > void amdgpu_device_fini(struct amdgpu_device *adev);
> > int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
> > @@ -1195,7 +1193,7 @@ static inline void *amdgpu_atpx_get_dhandle(void) {
> > return NULL; }
> > extern const struct drm_ioctl_desc amdgpu_ioctls_kms[];
> > extern const int amdgpu_max_kms_ioctl;
> >
> > -int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags);
> > +int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long
> > flags);
> > void amdgpu_driver_unload_kms(struct drm_device *dev);
> > void amdgpu_driver_lastclose_kms(struct drm_device *dev);
> > int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file
> > *file_priv);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 07012d71eeea..6e529548e708 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -1216,7 +1216,8 @@ static int amdgpu_device_check_arguments(struct
> > amdgpu_device *adev)
> > * Callback for the switcheroo driver. Suspends or resumes the
> > * the asics before or after it is powered up using ACPI methods.
> > */
> > -static void amdgpu_switcheroo_set_state(struct pci_dev *pdev, enum
> > vga_switcheroo_state state)
> > +static void amdgpu_switcheroo_set_state(struct pci_dev *pdev,
> > + enum vga_switcheroo_state state)
> > {
> > struct drm_device *dev = pci_get_drvdata(pdev);
> > int r;
> > @@ -2977,8 +2978,6 @@ static const struct attribute
> > *amdgpu_dev_attributes[] = {
> > * amdgpu_device_init - initialize the driver
> > *
> > * @adev: amdgpu_device pointer
> > - * @ddev: drm dev pointer
> > - * @pdev: pci dev pointer
> > * @flags: driver flags
> > *
> > * Initializes the driver info and hw (all asics).
> > @@ -2986,18 +2985,15 @@ static const struct attribute
> > *amdgpu_dev_attributes[] = {
> > * Called at driver startup.
> > */
> > int amdgpu_device_init(struct amdgpu_device *adev,
> > -struct drm_device *ddev,
> > -struct pci_dev *pdev,
> > uint32_t flags)
> > {
> > + struct drm_device *ddev = adev_to_drm(adev);
> > + struct pci_dev *pdev = adev->pdev;
> > int r, i;
> > bool boco = false;
> > u32 max_MBps;
> >
> > adev->shutdown = false;
> >
Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
On 2020-09-01 3:54 a.m., Daniel Vetter wrote: > On Wed, Aug 26, 2020 at 11:24:23AM +0300, Pekka Paalanen wrote: >> On Tue, 25 Aug 2020 12:58:19 -0400 >> "Kazlauskas, Nicholas" wrote: >> >>> On 2020-08-22 5:59 a.m., Michel Dänzer wrote: On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: > On 2020-08-21 12:57 p.m., Michel Dänzer wrote: >> From: Michel Dänzer >> >> Don't check drm_crtc_state::active for this either, per its >> documentation in include/drm/drm_crtc.h: >> >> * Hence drivers must not consult @active in their various >> * &drm_mode_config_funcs.atomic_check callback to reject an atomic >> * commit. >> >> The atomic helpers disable the CRTC as needed for disabling the primary >> plane. >> >> This prevents at least the following problems if the primary plane gets >> disabled (e.g. due to destroying the FB assigned to the primary plane, >> as happens e.g. with mutter in Wayland mode): >> >> * Toggling CRTC active to 1 failed if the cursor plane was enabled >> (e.g. via legacy DPMS property & cursor ioctl). >> * Enabling the cursor plane failed, e.g. via the legacy cursor ioctl. > > We previously had the requirement that the primary plane must be enabled > but some userspace expects that they can enable just the overlay plane > without anything else. > > I think the chromuiumos atomictest validates that this works as well: > > So is DRM going forward then with the expectation that this is wrong > behavior from userspace? > > We require at least one plane to be enabled to display a cursor, but it > doesn't necessarily need to be the primary. It's a "pick your poison" situation: 1) Currently the checks are invalid (atomic_check must not decide based on drm_crtc_state::active), and it's easy for legacy KMS userspace to accidentally hit errors trying to enable/move the cursor or switch DPMS off → on. 2) Accurately rejecting only atomic states where the cursor plane is enabled but all other planes are off would break the KMS helper code, which can only deal with the "CRTC on & primary plane off is not allowed" case specifically. 3) This patch addresses 1) & 2) but may break existing atomic userspace which wants to enable an overlay plane while disabling the primary plane. I do think in principle atomic userspace is expected to handle case 3) and leave the primary plane enabled. However, this is not ideal from an energy consumption PoV. Therefore, here's another idea for a possible way out of this quagmire: amdgpu_dm does not reject any atomic states based on which planes are enabled in it. If the cursor plane is enabled but all other planes are off, amdgpu_dm internally either: a) Enables an overlay plane and makes it invisible, e.g. by assigning a minimum size FB with alpha = 0. b) Enables the primary plane and assigns a minimum size FB (scaled up to the required size) containing all black, possibly using compression. (Trying to minimize the memory bandwidth) Does either of these seem feasible? If both do, which one would be preferable? >>> >>> It's really the same solution since DCN doesn't make a distinction >>> between primary or overlay planes in hardware. DCE doesn't have overlay >>> planes enabled so this is not relevant there. >>> >>> The old behavior (pre 5.1?) was to silently accept the commit even >>> though the screen would be completely black instead of outright >>> rejecting the commit. >>> >>> I almost wonder if that makes more sense in the short term here since >>> the only "userspace" affected here is IGT. We'll fail the CRC checks, >>> but no userspace actually tries to actively use a cursor with no primary >>> plane enabled from my understanding. >> >> Hi, >> >> I believe that there exists userspace that will *accidentally* attempt >> to update the cursor plane while primary plane or whole CRTC is off. >> Some versions of Mutter might do that on racy conditions, I suspect. >> These are legacy KMS users, not atomic KMS. >> >> However, I do not believe there exists any userspace that would >> actually expect the display to show the cursor plane alone without a >> primary plane. Therefore I'd be ok with legacy cursor ioctls silently >> succeeding. Atomic commits not. So the difference has to be in the >> translation from legacy UAPI to kernel internal atomic interface. >> >>> In the long term I think we can work on getting cursor actually on the >>> screen in this case, though I can't say I really like having to reserve >>> some small buffer (eg. 16x16) for allowing lightup on this corner case. >> >> Why would you bother implementing that? >> >> Is there really an IGT test that unconditionally demands cursor plane >> to be usable with
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 Evgeniy A. Dushistov (dushis...@mail.ru) changed: What|Removed |Added CC||dushis...@mail.ru --- Comment #36 from Evgeniy A. Dushistov (dushis...@mail.ru) --- Linux kernel 5.4.61/amd64 / Radeon RX 560 got the same problem today: [86631.543134] [drm] Fence fallback timer expired on ring gfx [86642.133543] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=1349762, emitted seq=1349767 [86642.133628] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 8032 thread Xorg:cs0 pid 8155 [86642.133634] amdgpu :41:00.0: GPU reset begin! [86642.134073] amdgpu: [powerplay] last message was failed ret is 65535 [86642.134075] amdgpu: [powerplay] failed to send message 281 ret is 65535 I have never seen a similar problem before. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Reset ASIC if suspend is not managed by platform firmware
On Tue, Sep 1, 2020 at 3:32 AM Kai-Heng Feng
wrote:
>
> Suspend with s2idle or by the following steps cause screen frozen:
> # echo devices > /sys/power/pm_test
> # echo freeze > /sys/power/mem
>
> [ 289.625461] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait
> timed out.
> [ 289.625494] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
> testing IB on ring 5 (-110).
>
> The issue doesn't happen on traditional S3, probably because firmware or
> hardware provides extra power management.
>
> Inspired by Daniel Drake's patch [1] on amdgpu, using a similar approach
> can fix the issue.
It doesn't actually fix the issue. The device is never powered down
so you are using more power than you would if you did not suspend in
the first place. The reset just works around the fact that the device
is never powered down.
Alex
>
> [1] https://patchwork.freedesktop.org/patch/335839/
>
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 266e3cbbd09b..df823b9ad79f 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1643,6 +1644,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool
> suspend,
> rdev->asic->asic_reset(rdev, true);
> pci_restore_state(dev->pdev);
> } else if (suspend) {
> + if (pm_suspend_no_platform())
> + rdev->asic->asic_reset(rdev, true);
> /* Shut down the device */
> pci_disable_device(dev->pdev);
> pci_set_power_state(dev->pdev, PCI_D3hot);
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
On 9/1/20 3:59 AM, Karol Herbst wrote: On Tue, Sep 1, 2020 at 9:13 AM Daniel Vetter wrote: On Tue, Aug 18, 2020 at 04:37:51PM +0200, Thierry Reding wrote: On Fri, Aug 14, 2020 at 07:25:17PM +0200, Daniel Vetter wrote: On Fri, Aug 14, 2020 at 7:17 PM Daniel Stone wrote: Hi, On Fri, 14 Aug 2020 at 17:22, Thierry Reding wrote: I suspect that the reason why this works in X but not in Wayland is because X passes the right usage flags, whereas Weston may not. But I'll have to investigate more in order to be sure. Weston allocates its own buffers for displaying the result of composition through GBM with USE_SCANOUT, which is definitely correct. Wayland clients (common to all compositors, in Mesa's src/egl/drivers/dri2/platform_wayland.c) allocate with USE_SHARED but _not_ USE_SCANOUT, which is correct in that they are guaranteed to be shared, but not guaranteed to be scanned out. The expectation is that non-scanout-compatible buffers would be rejected by gbm_bo_import if not drmModeAddFB2. One difference between Weston and all other compositors (GNOME Shell, KWin, Sway, etc) is that Weston uses KMS planes for composition when it can (i.e. when gbm_bo_import from dmabuf + drmModeAddFB2 from gbm_bo handle + atomic check succeed), but the other compositors only use the GPU. So if you have different assumptions about the layout of imported buffers between the GPU and KMS, that would explain a fair bit. Yeah non-modifiered multi-gpu (of any kind) is pretty much hopeless I think. I guess the only option is if the tegra mesa driver forces linear and an extra copy on everything that's USE_SHARED or USE_SCANOUT. I ended up trying this, but this fails for the X case, unfortunately, because there doesn't seem to be a good synchronization point at which the de-tiling blit could be done. Weston and kmscube end up calling a gallium driver's ->flush_resource() implementation, but that never happens for X and glamor. But after looking into this some more, I don't think that's even the problem that we're facing here. The root of the problem that causes the glxgears crash that Karol was originally reporting is because we end up allocating the glxgears pixmaps using the dri3 loader from Mesa. But the dri3 loader will unconditionally pass both __DRI_IMAGE_USE_SHARE and __DRI_IMAGE_USE_SCANOUT, irrespective of whether the buffer will end up being scanned out directly or whether it will be composited onto the root window. What exactly happens depends on whether I run glxgears in fullscreen mode or windowed mode. In windowed mode, the glxgears buffers will be composited onto the root window, so there's no need for the buffers to be scanout-capable. If I modify the dri3 loader to not pass those flags I can make this work just fine. When I run glxgears in fullscreen mode, the modesetting driver ends up wanting to display the glxgears buffer directly on screen, without compositing it onto the root window. This ends up working if I leave out the _USE_SHARE and _USE_SCANOUT flags, but I notice that the kernel then complains about being unable to create a framebuffer, which in turn is caused by the fact that those buffers are not exported (the Tegra Mesa driver only exports/imports buffers that are meant for scanout, under the assumption that those are the only ones that will ever need to be used by KMS) and therefore Tegra DRM doesn't have a valid handle for them. So I think an ideal solution would probably be for glxgears to somehow pass better usage information when allocating buffers, but I suspect that that's just not possible, or would be way too much work and require additional protocol at the DRI level, so it's not really a good option when all we want to fix is backwards-compatibility with pre-modifiers userspace. Given that glamor also doesn't have any synchronization points, I don't see how I can implement the de-tiling blit reliably. I was wondering if it shouldn't be possible to flush the framebuffer resource (and perform the blit) at presentation time, but I couldn't find a good entry point to do this. One other solution that occurred to me was to reintroduce an old IOCTL that we used to have in the Tegra DRM driver. That IOCTL was meant to attach tiling meta data to an imported buffer and was basically a simplified, driver-specific way of doing framebuffer modifiers. That's a very ugly solution, but it would allow us to be backwards-compatible with pre-modifiers userspace and even use an optimal path for rendering and scanning out. The only prerequisite would be that the driver IOCTL was implemented and that a recent enough Mesa was used to make use of it. I don't like this very much because framebuffer modifiers are a much more generic solution, but all of the other options above are pretty much just as ugly. One other idea that I haven't explored yet is to be a little more clever about the export/import dance that we do for buffers. Currently we export/import at allocation time, and that seems to
Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties
On Sat, 29 Aug 2020 16:24:52 +0200, Krzysztof Kozlowski wrote: > Additional properties actually might appear (e.g. assigned-clocks) so > use unevaluatedProperties to fix dtbs_check warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: > system-controller@105c: > 'assigned-clock-parents', 'assigned-clocks' do not match any of the > regexes: 'pinctrl-[0-9]+' Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: samsung-i2s: Use unevaluatedProperties commit: 8187d8300251a99e40e288be80bef6a15b7b22e4 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/3] xen: add helpers to allocate unpopulated memory
On 01.09.20 16:45, Roger Pau Monné wrote:
On Tue, Sep 01, 2020 at 10:33:26AM +0200, Roger Pau Monne wrote:
+static int fill_list(unsigned int nr_pages)
+{
+ struct dev_pagemap *pgmap;
+ void *vaddr;
+ unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
+ int nid, ret;
+
+ pgmap = kzalloc(sizeof(*pgmap), GFP_KERNEL);
+ if (!pgmap)
+ return -ENOMEM;
+
+ pgmap->type = MEMORY_DEVICE_GENERIC;
+ pgmap->res.name = "Xen scratch";
+ pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+
+ ret = allocate_resource(&iomem_resource, &pgmap->res,
+ alloc_pages * PAGE_SIZE, 0, -1,
+ PAGES_PER_SECTION * PAGE_SIZE, NULL, NULL);
+ if (ret < 0) {
+ pr_err("Cannot allocate new IOMEM resource\n");
+ kfree(pgmap);
+ return ret;
+ }
+
+ nid = memory_add_physaddr_to_nid(pgmap->res.start);
I think this is not needed ...
+
+#ifdef CONFIG_XEN_HAVE_PVMMU
+/*
+ * memremap will build page tables for the new memory so
+ * the p2m must contain invalid entries so the correct
+ * non-present PTEs will be written.
+ *
+ * If a failure occurs, the original (identity) p2m entries
+ * are not restored since this region is now known not to
+ * conflict with any devices.
+ */
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ xen_pfn_t pfn = PFN_DOWN(pgmap->res.start);
+
+ for (i = 0; i < alloc_pages; i++) {
+ if (!set_phys_to_machine(pfn + i, INVALID_P2M_ENTRY)) {
+ pr_warn("set_phys_to_machine() failed, no memory
added\n");
+ release_resource(&pgmap->res);
+ kfree(pgmap);
+ return -ENOMEM;
+ }
+}
+ }
+#endif
+
+ vaddr = memremap_pages(pgmap, nid);
... and NUMA_NO_NODE should be used here instead, as this memory is just
fictitious space to map foreign memory, and shouldn't be related to
any NUMA node.
The following chunk should be folded in, or I can resend.
I can fold it in.
Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/ttm: make sure that we always zero init mem.bus v2
We are trying to remove the io_lru handling and depend
on zero init base, offset and addr here.
v2: init addr as well
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e3931e515906..772c640a6046 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -650,6 +650,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
evict_mem.mm_node = NULL;
evict_mem.bus.io_reserved_vm = false;
evict_mem.bus.io_reserved_count = 0;
+ evict_mem.bus.base = 0;
+ evict_mem.bus.offset = 0;
+ evict_mem.bus.addr = NULL;
ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx);
if (ret) {
@@ -1084,6 +1087,9 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
mem.page_alignment = bo->mem.page_alignment;
mem.bus.io_reserved_vm = false;
mem.bus.io_reserved_count = 0;
+ mem.bus.base = 0;
+ mem.bus.offset = 0;
+ mem.bus.addr = NULL;
mem.mm_node = NULL;
/*
@@ -1243,6 +1249,9 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->mem.page_alignment = page_alignment;
bo->mem.bus.io_reserved_vm = false;
bo->mem.bus.io_reserved_count = 0;
+ bo->mem.bus.base = 0;
+ bo->mem.bus.offset = 0;
+ bo->mem.bus.addr = NULL;
bo->moving = NULL;
bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
bo->acc_size = acc_size;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/nouveau: move io_reserve_lru handling into the driver v5
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve
v3: rebased and use both base and offset in the check
v4: fix small typos and test the patch
v5: rebased and keep the mem.bus init in TTM.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 101 --
drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 44 ++-
4 files changed, 127 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 9140387f30dc..f74988771ed8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -137,6 +137,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct nouveau_bo *nvbo = nouveau_bo(bo);
WARN_ON(nvbo->pin_refcnt > 0);
+ nouveau_bo_del_io_reserve_lru(bo);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
/*
@@ -304,6 +305,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
align, u32 flags,
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, flags, 0);
+ INIT_LIST_HEAD(&nvbo->io_reserve_lru);
ret = ttm_bo_init(nvbo->bo.bdev, &nvbo->bo, size, type,
&nvbo->placement, align >> PAGE_SHIFT, false,
@@ -574,6 +576,26 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
PAGE_SIZE, DMA_FROM_DEVICE);
}
+void nouveau_bo_add_io_reserve_lru(struct ttm_buffer_object *bo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+ struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+ mutex_lock(&drm->ttm.io_reserve_mutex);
+ list_move_tail(&nvbo->io_reserve_lru, &drm->ttm.io_reserve_lru);
+ mutex_unlock(&drm->ttm.io_reserve_mutex);
+}
+
+void nouveau_bo_del_io_reserve_lru(struct ttm_buffer_object *bo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+ struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+ mutex_lock(&drm->ttm.io_reserve_mutex);
+ list_del_init(&nvbo->io_reserve_lru);
+ mutex_unlock(&drm->ttm.io_reserve_mutex);
+}
+
int
nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -888,6 +910,8 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool
evict,
if (bo->destroy != nouveau_bo_del_ttm)
return;
+ nouveau_bo_del_io_reserve_lru(bo);
+
if (mem && new_reg->mem_type != TTM_PL_SYSTEM &&
mem->mem.page == nvbo->page) {
list_for_each_entry(vma, &nvbo->vma_list, head) {
@@ -1018,17 +1042,42 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo,
struct file *filp)
filp->private_data);
}
+static void
+nouveau_ttm_io_mem_free_locked(struct nouveau_drm *drm,
+ struct ttm_resource *reg)
+{
+ struct nouveau_mem *mem = nouveau_mem(reg);
+
+ if (drm->client.mem->oclass >= NVIF_CLASS_MEM_NV50) {
+ switch (reg->mem_type) {
+ case TTM_PL_TT:
+ if (mem->kind)
+ nvif_object_unmap_handle(&mem->mem.object);
+ break;
+ case TTM_PL_VRAM:
+ nvif_object_unmap_handle(&mem->mem.object);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
static int
nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_resource
*reg)
{
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct nvkm_device *device = nvxx_device(&drm->client.device);
struct nouveau_mem *mem = nouveau_mem(reg);
+ int ret;
+ mutex_lock(&drm->ttm.io_reserve_mutex);
+retry:
switch (reg->mem_type) {
case TTM_PL_SYSTEM:
/* System memory */
- return 0;
+ ret = 0;
+ goto out;
case TTM_PL_TT:
#if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge) {
@@ -1037,9 +1086,12 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
reg->bus.is_iomem = !drm->agp.cma;
}
#endif
- if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 || !mem->kind)
+ if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 ||
+ !mem->kind) {
/* untiled */
+ ret = 0;
break;
+ }
fallthrough;/* tiled memory */
[PATCH 3/3] drm/ttm: remove io_reserve_lru handling v2
From: Christian König
That is not used any more.
v2: keep the NULL checks in TTM.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_bo.c | 34 +
drivers/gpu/drm/ttm/ttm_bo_util.c | 113 +++--
drivers/gpu/drm/ttm/ttm_bo_vm.c| 39 +++---
drivers/gpu/drm/ttm/ttm_resource.c | 3 -
include/drm/ttm/ttm_bo_api.h | 1 -
include/drm/ttm/ttm_bo_driver.h| 5 --
include/drm/ttm/ttm_resource.h | 16
7 files changed, 24 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 772c640a6046..89d8ab6edd40 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -263,11 +263,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
struct ttm_resource_manager *new_man = ttm_manager_type(bdev,
mem->mem_type);
int ret;
- ret = ttm_mem_io_lock(old_man, true);
- if (unlikely(ret != 0))
- goto out_err;
- ttm_bo_unmap_virtual_locked(bo);
- ttm_mem_io_unlock(old_man);
+ ttm_bo_unmap_virtual(bo);
/*
* Create and bind a ttm if required.
@@ -538,7 +534,6 @@ static void ttm_bo_release(struct kref *kref)
struct ttm_buffer_object *bo =
container_of(kref, struct ttm_buffer_object, kref);
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_resource_manager *man = ttm_manager_type(bdev,
bo->mem.mem_type);
size_t acc_size = bo->acc_size;
int ret;
@@ -556,9 +551,7 @@ static void ttm_bo_release(struct kref *kref)
bo->bdev->driver->release_notify(bo);
drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node);
- ttm_mem_io_lock(man, false);
- ttm_mem_io_free_vm(bo);
- ttm_mem_io_unlock(man);
+ ttm_mem_io_free(bdev, &bo->mem);
}
if (!dma_resv_test_signaled_rcu(bo->base.resv, true) ||
@@ -648,8 +641,6 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
- evict_mem.bus.io_reserved_vm = false;
- evict_mem.bus.io_reserved_count = 0;
evict_mem.bus.base = 0;
evict_mem.bus.offset = 0;
evict_mem.bus.addr = NULL;
@@ -1085,8 +1076,6 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
mem.num_pages = bo->num_pages;
mem.size = mem.num_pages << PAGE_SHIFT;
mem.page_alignment = bo->mem.page_alignment;
- mem.bus.io_reserved_vm = false;
- mem.bus.io_reserved_count = 0;
mem.bus.base = 0;
mem.bus.offset = 0;
mem.bus.addr = NULL;
@@ -1238,7 +1227,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(&bo->lru);
INIT_LIST_HEAD(&bo->ddestroy);
INIT_LIST_HEAD(&bo->swap);
- INIT_LIST_HEAD(&bo->io_reserve_lru);
bo->bdev = bdev;
bo->type = type;
bo->num_pages = num_pages;
@@ -1247,8 +1235,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->mem.num_pages = bo->num_pages;
bo->mem.mm_node = NULL;
bo->mem.page_alignment = page_alignment;
- bo->mem.bus.io_reserved_vm = false;
- bo->mem.bus.io_reserved_count = 0;
bo->mem.bus.base = 0;
bo->mem.bus.offset = 0;
bo->mem.bus.addr = NULL;
@@ -1554,25 +1540,13 @@ EXPORT_SYMBOL(ttm_bo_device_init);
* buffer object vm functions.
*/
-void ttm_bo_unmap_virtual_locked(struct ttm_buffer_object *bo)
-{
- struct ttm_bo_device *bdev = bo->bdev;
-
- drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
- ttm_mem_io_free_vm(bo);
-}
-
void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_resource_manager *man = ttm_manager_type(bdev,
bo->mem.mem_type);
- ttm_mem_io_lock(man, false);
- ttm_bo_unmap_virtual_locked(bo);
- ttm_mem_io_unlock(man);
+ drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
+ ttm_mem_io_free(bdev, &bo->mem);
}
-
-
EXPORT_SYMBOL(ttm_bo_unmap_virtual);
int ttm_bo_wait(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ee04716b2603..40ded10055d2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,122 +91,42 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_move_ttm);
-int ttm_mem_io_lock(struct ttm_resource_manager *man, bool interruptible)
-{
- if (likely(!man->use_io_reserve_lru))
- return 0;
-
- if (interruptible)
- return mutex_lock_interruptible(&man->io_reserve_mutex);
-
- mutex_lock(&man->io_reserve_mutex);
- return 0;
-}
-
-void ttm_mem_io_unlock(struct ttm_resource_manager *man)
-{
- if (likely(!man->use_io_reserve
[PATCH 0/3] drm/msm: More GPU tracepoints
From: Rob Clark Various extra tracepoints that I've been collecting. Rob Clark (3): drm/msm/gpu: Add GPU freq_change traces drm/msm: Convert shrinker msgs to tracepoints drm/msm/gpu: Add suspend/resume tracepoints drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 3 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++ drivers/gpu/drm/msm/msm_gem_shrinker.c | 5 +- drivers/gpu/drm/msm/msm_gpu.c | 4 ++ drivers/gpu/drm/msm/msm_gpu_trace.h| 83 ++ 5 files changed, 97 insertions(+), 2 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/msm/gpu: Add GPU freq_change traces
From: Rob Clark
Technically the GMU specific one is a bit redundant, but it was useful
to track down a bug.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
drivers/gpu/drm/msm/msm_gpu_trace.h | 31 +++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 46a29e383bfd..ab1e9eb619e0 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -11,6 +11,7 @@
#include "a6xx_gpu.h"
#include "a6xx_gmu.xml.h"
#include "msm_gem.h"
+#include "msm_gpu_trace.h"
#include "msm_mmu.h"
static void a6xx_gmu_fault(struct a6xx_gmu *gmu)
@@ -124,6 +125,8 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct
dev_pm_opp *opp)
gmu->current_perf_index = perf_index;
gmu->freq = gmu->gpu_freqs[perf_index];
+ trace_msm_gmu_freq_change(gmu->freq, perf_index);
+
/*
* This can get called from devfreq while the hardware is idle. Don't
* bring up the power if it isn't already active
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d5645472b25d..b02866527386 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -32,6 +32,8 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
if (IS_ERR(opp))
return PTR_ERR(opp);
+ trace_msm_gpu_freq_change(dev_pm_opp_get_freq(opp));
+
if (gpu->funcs->gpu_set_freq)
gpu->funcs->gpu_set_freq(gpu, opp);
else
diff --git a/drivers/gpu/drm/msm/msm_gpu_trace.h
b/drivers/gpu/drm/msm/msm_gpu_trace.h
index 122b84789238..07572ab179fa 100644
--- a/drivers/gpu/drm/msm/msm_gpu_trace.h
+++ b/drivers/gpu/drm/msm/msm_gpu_trace.h
@@ -83,6 +83,37 @@ TRACE_EVENT(msm_gpu_submit_retired,
__entry->start_ticks, __entry->end_ticks)
);
+
+TRACE_EVENT(msm_gpu_freq_change,
+ TP_PROTO(u32 freq),
+ TP_ARGS(freq),
+ TP_STRUCT__entry(
+ __field(u32, freq)
+ ),
+ TP_fast_assign(
+ /* trace freq in MHz to match intel_gpu_freq_change, to
make life easier
+* for userspace
+*/
+ __entry->freq = DIV_ROUND_UP(freq, 100);
+ ),
+ TP_printk("new_freq=%u", __entry->freq)
+);
+
+
+TRACE_EVENT(msm_gmu_freq_change,
+ TP_PROTO(u32 freq, u32 perf_index),
+ TP_ARGS(freq, perf_index),
+ TP_STRUCT__entry(
+ __field(u32, freq)
+ __field(u32, perf_index)
+ ),
+ TP_fast_assign(
+ __entry->freq = freq;
+ __entry->perf_index = perf_index;
+ ),
+ TP_printk("freq=%u, perf_index=%u", __entry->freq,
__entry->perf_index)
+);
+
#endif
#undef TRACE_INCLUDE_PATH
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/msm/gpu: Add suspend/resume tracepoints
From: Rob Clark
Signed-off-by: Rob Clark
---
I'm not sure if there is a better way to do no-arg tracepoints? The
trace framework seems to go out of it's way to make this difficult.
Or maybe there is a more obvious thing that I'm not seeing.
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
drivers/gpu/drm/msm/msm_gpu_trace.h | 26 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c5a3e4d4c007..2de280e45077 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -923,6 +923,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
gpu->needs_hw_init = true;
+ trace_msm_gpu_resume(0);
+
ret = a6xx_gmu_resume(a6xx_gpu);
if (ret)
return ret;
@@ -937,6 +939,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ trace_msm_gpu_suspend(0);
+
devfreq_suspend_device(gpu->devfreq.devfreq);
return a6xx_gmu_stop(a6xx_gpu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index b02866527386..5ceb2a966a87 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -202,6 +202,7 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
int ret;
DBG("%s", gpu->name);
+ trace_msm_gpu_resume(0);
ret = enable_pwrrail(gpu);
if (ret)
@@ -227,6 +228,7 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
int ret;
DBG("%s", gpu->name);
+ trace_msm_gpu_suspend(0);
devfreq_suspend_device(gpu->devfreq.devfreq);
diff --git a/drivers/gpu/drm/msm/msm_gpu_trace.h
b/drivers/gpu/drm/msm/msm_gpu_trace.h
index 1079fe551279..03e0c2536b94 100644
--- a/drivers/gpu/drm/msm/msm_gpu_trace.h
+++ b/drivers/gpu/drm/msm/msm_gpu_trace.h
@@ -140,6 +140,32 @@ TRACE_EVENT(msm_gem_purge_vmaps,
TP_printk("Purging %u vmaps", __entry->unmapped)
);
+
+TRACE_EVENT(msm_gpu_suspend,
+ TP_PROTO(int dummy),
+ TP_ARGS(dummy),
+ TP_STRUCT__entry(
+ __field(u32, dummy)
+ ),
+ TP_fast_assign(
+ __entry->dummy = dummy;
+ ),
+ TP_printk("%u", __entry->dummy)
+);
+
+
+TRACE_EVENT(msm_gpu_resume,
+ TP_PROTO(int dummy),
+ TP_ARGS(dummy),
+ TP_STRUCT__entry(
+ __field(u32, dummy)
+ ),
+ TP_fast_assign(
+ __entry->dummy = dummy;
+ ),
+ TP_printk("%u", __entry->dummy)
+);
+
#endif
#undef TRACE_INCLUDE_PATH
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/msm: Convert shrinker msgs to tracepoints
From: Rob Clark
This reduces the spam in dmesg when we start hitting the shrinker, and
replaces it with something we can put on a timeline while profiling or
debugging system issues.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 5 +++--
drivers/gpu/drm/msm/msm_gpu_trace.h| 26 ++
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 722d61668a97..482576d7a39a 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -6,6 +6,7 @@
#include "msm_drv.h"
#include "msm_gem.h"
+#include "msm_gpu_trace.h"
static bool msm_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
{
@@ -87,7 +88,7 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
mutex_unlock(&dev->struct_mutex);
if (freed > 0)
- pr_info_ratelimited("Purging %lu bytes\n", freed << PAGE_SHIFT);
+ trace_msm_gem_purge(freed << PAGE_SHIFT);
return freed;
}
@@ -123,7 +124,7 @@ msm_gem_shrinker_vmap(struct notifier_block *nb, unsigned
long event, void *ptr)
*(unsigned long *)ptr += unmapped;
if (unmapped > 0)
- pr_info_ratelimited("Purging %u vmaps\n", unmapped);
+ trace_msm_gem_purge_vmaps(unmapped);
return NOTIFY_DONE;
}
diff --git a/drivers/gpu/drm/msm/msm_gpu_trace.h
b/drivers/gpu/drm/msm/msm_gpu_trace.h
index 07572ab179fa..1079fe551279 100644
--- a/drivers/gpu/drm/msm/msm_gpu_trace.h
+++ b/drivers/gpu/drm/msm/msm_gpu_trace.h
@@ -114,6 +114,32 @@ TRACE_EVENT(msm_gmu_freq_change,
TP_printk("freq=%u, perf_index=%u", __entry->freq,
__entry->perf_index)
);
+
+TRACE_EVENT(msm_gem_purge,
+ TP_PROTO(u32 bytes),
+ TP_ARGS(bytes),
+ TP_STRUCT__entry(
+ __field(u32, bytes)
+ ),
+ TP_fast_assign(
+ __entry->bytes = bytes;
+ ),
+ TP_printk("Purging %u bytes", __entry->bytes)
+);
+
+
+TRACE_EVENT(msm_gem_purge_vmaps,
+ TP_PROTO(u32 unmapped),
+ TP_ARGS(unmapped),
+ TP_STRUCT__entry(
+ __field(u32, unmapped)
+ ),
+ TP_fast_assign(
+ __entry->unmapped = unmapped;
+ ),
+ TP_printk("Purging %u vmaps", __entry->unmapped)
+);
+
#endif
#undef TRACE_INCLUDE_PATH
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.8 213/255] drm/modeset-lock: Take the modeset BKL for legacy drivers
From: Daniel Vetter
commit 77ef38574beb3e0b414db48e9c0f04633df68ba6 upstream.
This fell off in the conversion in
commit 9bcaa3fe58ab7559e71df798bcff6e0795158695
Author: Michal Orzel
Date: Tue Apr 28 19:10:04 2020 +0200
drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
but it's caught by the drm_warn_on_modeset_not_all_locked() that the
legacy modeset code uses. Since this is the bkl and it's unclear
what's all protected, play it safe and grab it again for legacy
drivers.
Unfortunately this means we need to sprinkle a few more #includes
around.
Also we need to add the drm_device as a parameter to the _END macro.
Finally remove the mute_lock() from setcrtc, since that's now done by
the macro.
Cc: Alex Deucher
Fixes: 9bcaa3fe58ab ("drm: Replace drm_modeset_lock/unlock_all with
DRM_MODESET_LOCK_ALL_* helpers")
Cc: Michal Orzel
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.8+
Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20200814093842.3048472-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_helper.c |7 ---
drivers/gpu/drm/drm_color_mgmt.c|2 +-
drivers/gpu/drm/drm_crtc.c |4 +---
drivers/gpu/drm/drm_mode_object.c |4 ++--
drivers/gpu/drm/drm_plane.c |2 +-
include/drm/drm_modeset_lock.h |9 +++--
6 files changed, 16 insertions(+), 12 deletions(-)
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3105,7 +3106,7 @@ void drm_atomic_helper_shutdown(struct d
if (ret)
DRM_ERROR("Disabling all crtc's during unload failed with
%i\n", ret);
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
EXPORT_SYMBOL(drm_atomic_helper_shutdown);
@@ -3245,7 +3246,7 @@ struct drm_atomic_state *drm_atomic_help
}
unlock:
- DRM_MODESET_LOCK_ALL_END(ctx, err);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, err);
if (err)
return ERR_PTR(err);
@@ -3326,7 +3327,7 @@ int drm_atomic_helper_resume(struct drm_
err = drm_atomic_helper_commit_duplicated_state(state, &ctx);
- DRM_MODESET_LOCK_ALL_END(ctx, err);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, err);
drm_atomic_state_put(state);
return err;
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -294,7 +294,7 @@ int drm_mode_gamma_set_ioctl(struct drm_
crtc->gamma_size, &ctx);
out:
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -561,7 +561,6 @@ int drm_mode_setcrtc(struct drm_device *
if (crtc_req->mode_valid && !drm_lease_held(file_priv, plane->base.id))
return -EACCES;
- mutex_lock(&crtc->dev->mode_config.mutex);
DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
@@ -728,8 +727,7 @@ out:
fb = NULL;
mode = NULL;
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
- mutex_unlock(&crtc->dev->mode_config.mutex);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -428,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(st
out_unref:
drm_mode_object_put(obj);
out:
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
@@ -470,7 +470,7 @@ static int set_property_legacy(struct dr
break;
}
drm_property_change_valid_put(prop, ref);
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -791,7 +791,7 @@ static int setplane_internal(struct drm_
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h, &ctx);
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(plane->dev, ctx, ret);
return ret;
}
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -164,6 +164,8 @@ int drm_modeset_lock_all_ctx(struct drm_
* is 0, so no error checking is necessary
*/
#define DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, flags, ret) \
+ if (!drm_drv_uses_atomic_modeset(dev)) \
+ mutex_lock(&dev->mode_config.mutex);
Re: [PATCH 06/19] drm/msm/gpu: add dev_to_gpu() helper
On Mon, Aug 31, 2020 at 9:32 PM Bjorn Andersson
wrote:
>
> On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
>
> > From: Rob Clark
> >
> > In a later patch, the drvdata will not directly be 'struct msm_gpu *',
> > so add a helper to reduce the churn.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_device.c | 10 --
> > drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
> > drivers/gpu/drm/msm/msm_gpu.h | 5 +
> > 3 files changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > index 9eeb46bf2a5d..26664e1b30c0 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > @@ -282,7 +282,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> > int ret;
> >
> > if (pdev)
> > - gpu = platform_get_drvdata(pdev);
> > + gpu = dev_to_gpu(&pdev->dev);
> >
> > if (!gpu) {
> > dev_err_once(dev->dev, "no GPU device was found\n");
> > @@ -425,7 +425,7 @@ static int adreno_bind(struct device *dev, struct
> > device *master, void *data)
> > static void adreno_unbind(struct device *dev, struct device *master,
> > void *data)
> > {
> > - struct msm_gpu *gpu = dev_get_drvdata(dev);
> > + struct msm_gpu *gpu = dev_to_gpu(dev);
> >
> > pm_runtime_force_suspend(dev);
> > gpu->funcs->destroy(gpu);
> > @@ -490,16 +490,14 @@ static const struct of_device_id dt_match[] = {
> > #ifdef CONFIG_PM
> > static int adreno_resume(struct device *dev)
> > {
> > - struct platform_device *pdev = to_platform_device(dev);
> > - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> > + struct msm_gpu *gpu = dev_to_gpu(dev);
> >
> > return gpu->funcs->pm_resume(gpu);
> > }
> >
> > static int adreno_suspend(struct device *dev)
> > {
> > - struct platform_device *pdev = to_platform_device(dev);
> > - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> > + struct msm_gpu *gpu = dev_to_gpu(dev);
> >
> > return gpu->funcs->pm_suspend(gpu);
> > }
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > index d5645472b25d..6aa9e04e52e7 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > @@ -24,7 +24,7 @@
> > static int msm_devfreq_target(struct device *dev, unsigned long *freq,
> > u32 flags)
> > {
> > - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> > + struct msm_gpu *gpu = dev_to_gpu(dev);
> > struct dev_pm_opp *opp;
> >
> > opp = devfreq_recommended_opp(dev, freq, flags);
> > @@ -45,7 +45,7 @@ static int msm_devfreq_target(struct device *dev,
> > unsigned long *freq,
> > static int msm_devfreq_get_dev_status(struct device *dev,
> > struct devfreq_dev_status *status)
> > {
> > - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> > + struct msm_gpu *gpu = dev_to_gpu(dev);
> > ktime_t time;
> >
> > if (gpu->funcs->gpu_get_freq)
> > @@ -64,7 +64,7 @@ static int msm_devfreq_get_dev_status(struct device *dev,
> >
> > static int msm_devfreq_get_cur_freq(struct device *dev, unsigned long
> > *freq)
> > {
> > - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> > + struct msm_gpu *gpu = dev_to_gpu(dev);
> >
> > if (gpu->funcs->gpu_get_freq)
> > *freq = gpu->funcs->gpu_get_freq(gpu);
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> > index 0db117a7339b..8bda7beaed4b 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.h
> > +++ b/drivers/gpu/drm/msm/msm_gpu.h
> > @@ -141,6 +141,11 @@ struct msm_gpu {
> > struct msm_gpu_state *crashstate;
> > };
> >
> > +static inline struct msm_gpu *dev_to_gpu(struct device *dev)
>
> That's a fairly generic name for a driver-global helper :)
tbf, it is only global to the gpu part of the driver..
thanks for the review
BR,
-R
> Reviewed-by: Bjorn Andersson
>
> Regards,
> Bjorn
>
> > +{
> > + return dev_get_drvdata(dev);
> > +}
> > +
> > /* It turns out that all targets use the same ringbuffer size */
> > #define MSM_GPU_RINGBUFFER_SZ SZ_32K
> > #define MSM_GPU_RINGBUFFER_BLKSIZE 32
> > --
> > 2.26.2
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Reset ASIC if suspend is not managed by platform firmware
On Tue, Sep 1, 2020 at 12:21 PM Kai-Heng Feng
wrote:
>
>
>
> > On Sep 1, 2020, at 22:19, Alex Deucher wrote:
> >
> > On Tue, Sep 1, 2020 at 3:32 AM Kai-Heng Feng
> > wrote:
> >>
> >> Suspend with s2idle or by the following steps cause screen frozen:
> >> # echo devices > /sys/power/pm_test
> >> # echo freeze > /sys/power/mem
> >>
> >> [ 289.625461] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait
> >> timed out.
> >> [ 289.625494] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
> >> testing IB on ring 5 (-110).
> >>
> >> The issue doesn't happen on traditional S3, probably because firmware or
> >> hardware provides extra power management.
> >>
> >> Inspired by Daniel Drake's patch [1] on amdgpu, using a similar approach
> >> can fix the issue.
> >
> > It doesn't actually fix the issue. The device is never powered down
> > so you are using more power than you would if you did not suspend in
> > the first place. The reset just works around the fact that the device
> > is never powered down.
>
> So how do we properly suspend/resume the device without help from platform
> firmware?
I guess you don't?
Alex
>
> Kai-Heng
>
> >
> > Alex
> >
> >>
> >> [1] https://patchwork.freedesktop.org/patch/335839/
> >>
> >> Signed-off-by: Kai-Heng Feng
> >> ---
> >> drivers/gpu/drm/radeon/radeon_device.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> >> b/drivers/gpu/drm/radeon/radeon_device.c
> >> index 266e3cbbd09b..df823b9ad79f 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_device.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> >> @@ -33,6 +33,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
> >> @@ -1643,6 +1644,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool
> >> suspend,
> >>rdev->asic->asic_reset(rdev, true);
> >>pci_restore_state(dev->pdev);
> >>} else if (suspend) {
> >> + if (pm_suspend_no_platform())
> >> + rdev->asic->asic_reset(rdev, true);
> >>/* Shut down the device */
> >>pci_disable_device(dev->pdev);
> >>pci_set_power_state(dev->pdev, PCI_D3hot);
> >> --
> >> 2.17.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
Hi Maxime, Am 01.09.20 um 11:58 schrieb Maxime Ripard: > Hi Stefan > > On Tue, Aug 25, 2020 at 11:30:58PM +0200, Stefan Wahren wrote: >> Am 25.08.20 um 17:06 schrieb Maxime Ripard: >>> Hi Stefan, >>> >>> On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote: Am 29.07.20 um 16:42 schrieb Maxime Ripard: > Hi, > > On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: >> On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: >>> In order to avoid pixels getting stuck in the (unflushable) FIFO between >>> the HVS and the PV, we need to add some delay after disabling the PV >>> output >>> and before disabling the HDMI controller. 20ms seems to be good enough >>> so >>> let's use that. >>> >>> Signed-off-by: Maxime Ripard >>> --- >>> drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c >>> b/drivers/gpu/drm/vc4/vc4_crtc.c >>> index d0b326e1df0a..7b178d67187f 100644 >>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c >>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c >>> @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc >>> *crtc, >>> ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), >>> 1); >>> WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); >>> >>> + mdelay(20); >> mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we >> not msleep instead? > Since the timing was fairly critical, sleeping didn't seem like a good > solution since there's definitely some chance you overshoot and end up > with a higher time than the one you targeted. usleep_range(min, max) isn't a solution? >>> My understanding of usleep_range was that you can still overshoot, even >>> though it's backed by an HR timer so the resolution is not a jiffy. Are >>> we certain that we're going to be in that range? >> you are right there is no guarantee about the upper wake up time. >> >> And it's not worth the effort to poll the FIFO state until its empty >> (using 20 ms as timeout)? > I know this isn't really a great argument there, but getting this to > work has been quite painful, and the timing is very sensitive. If we > fail to wait for enough time, there's going to be a pixel shift that we > can't get rid of unless we reboot, which is pretty bad (and would fail > any CI test that checks for the output integrity). > > I know busy-looping for 20ms isn't ideal, but it's not really in a > hot-path (it's only done when changing a mode), with the sync time of > the display likely to be much more than that, and if it can avoid having > to look into it ever again or avoid random failures, I'd say it's worth > it. i don't want to delay this series. Could you please add a small comment to the delay to clarify the timing is very sensitive? Thanks > > Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 75/78] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
Hi,
On Tue, Sep 01, 2020 at 01:45:07PM +0900, Chanwoo Choi wrote:
> Hi Maxime,
>
> On 7/9/20 2:42 AM, Maxime Ripard wrote:
> > The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> > bindings, especially since the registers have been shuffled around in more
> > register ranges.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Maxime Ripard
> > ---
> > Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109
> > -
> > 1 file changed, 109 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > new file mode 100644
> > index ..6091fe3d315b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > @@ -0,0 +1,109 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id:
> > https://protect2.fireeye.com/url?k=556aeb05-08b8fda0-556b604a-0cc47a31bee8-c3a0ebd1d22c3183&q=1&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> > +$schema:
> > https://protect2.fireeye.com/url?k=24fa660c-792870a9-24fbed43-0cc47a31bee8-0bf16f4fd60f0ab4&q=1&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> > +
> > +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Eric Anholt
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - brcm,bcm2711-hdmi0
> > + - brcm,bcm2711-hdmi1
> > +
> > + reg:
> > +items:
> > + - description: HDMI controller register range
> > + - description: DVP register range
> > + - description: HDMI PHY register range
> > + - description: Rate Manager register range
> > + - description: Packet RAM register range
> > + - description: Metadata RAM register range
> > + - description: CSC register range
> > + - description: CEC register range
> > + - description: HD register range
> > +
> > + reg-names:
> > +items:
> > + - const: hdmi
> > + - const: dvp
> > + - const: phy
> > + - const: rm
> > + - const: packet
> > + - const: metadata
> > + - const: csc
> > + - const: cec
> > + - const: hd
> > +
> > + clocks:
> > +description: The HDMI state machine clock
>
> I'm not sure the following description is correct.
> But, this description doesn't contain the information of audio clock.
>
> description: The HDMI state machine and audio clock
>
> > +
> > + clock-names:
> > +const: hdmi
>
> This patch is missing the following clock information for audio clock.
>
> const: clk-108M
>
> > +
> > + ddc:
> > +allOf:
> > + - $ref: /schemas/types.yaml#/definitions/phandle
> > +description: >
> > + Phandle of the I2C controller used for DDC EDID probing
> > +
> > + hpd-gpios:
> > +description: >
> > + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> > + as an interrupt/status bit in the HDMI controller itself)
> > +
> > + dmas:
> > +maxItems: 1
> > +description: >
> > + Should contain one entry pointing to the DMA channel used to
> > + transfer audio data.
> > +
> > + dma-names:
> > +const: audio-rx
> > +
> > + resets:
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - clocks
> > + - resets
> > + - ddc
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +hdmi0: hdmi@7ef00700 {
> > +compatible = "brcm,bcm2711-hdmi0";
> > +reg = <0x7ef00700 0x300>,
> > + <0x7ef00300 0x200>,
> > + <0x7ef00f00 0x80>,
> > + <0x7ef00f80 0x80>,
> > + <0x7ef01b00 0x200>,
> > + <0x7ef01f00 0x400>,
> > + <0x7ef00200 0x80>,
> > + <0x7ef04300 0x100>,
> > + <0x7ef2 0x100>;
> > +reg-names = "hdmi",
> > +"dvp",
> > +"phy",
> > +"rm",
> > +"packet",
> > +"metadata",
> > +"csc",
> > +"cec",
> > +"hd";
> > +clocks = <&firmware_clocks 13>;
> > +clock-names = "hdmi";
>
> Also, this example doesn't include the instance of audio clock.
> Need to edit them as following:
>
> clock-names = "hdmi", "clk-108M";
> clocks = <&firmware_clocks 13>, <&dvp 0>;
Indeed, thanks for pointing it out
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 3/8] drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
On 01-09-20, 13:01, Rajendra Nayak wrote: > So FWIU, dpu_unbind() gets called even when dpu_bind() fails for some reason. Ahh, I see. > I tried to address that earlier [1] which I realized did not land. I don't think that patch was required, as you can call dev_pm_opp_put_clkname() multiple times and it will return without any errors/crash. > But with these changes > it will be even more broken unless we identify if we failed dpu_bind() before > adding the OPP table, while adding it, or all went well with opps and handle > things > accordingly in dpu_unbind. Maybe not as dev_pm_opp_of_remove_table() can be called multiple times as well without any errors or crash. > [1] https://lore.kernel.org/patchwork/patch/1275632/ -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
Hi Stefan On Tue, Aug 25, 2020 at 11:30:58PM +0200, Stefan Wahren wrote: > Am 25.08.20 um 17:06 schrieb Maxime Ripard: > > Hi Stefan, > > > > On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote: > >> Am 29.07.20 um 16:42 schrieb Maxime Ripard: > >>> Hi, > >>> > >>> On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: > On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to avoid pixels getting stuck in the (unflushable) FIFO between > > the HVS and the PV, we need to add some delay after disabling the PV > > output > > and before disabling the HDMI controller. 20ms seems to be good enough > > so > > let's use that. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c > > b/drivers/gpu/drm/vc4/vc4_crtc.c > > index d0b326e1df0a..7b178d67187f 100644 > > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > > @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc > > *crtc, > > ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), > > 1); > > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > > > + mdelay(20); > mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we > not msleep instead? > >>> Since the timing was fairly critical, sleeping didn't seem like a good > >>> solution since there's definitely some chance you overshoot and end up > >>> with a higher time than the one you targeted. > >> usleep_range(min, max) isn't a solution? > > My understanding of usleep_range was that you can still overshoot, even > > though it's backed by an HR timer so the resolution is not a jiffy. Are > > we certain that we're going to be in that range? > > you are right there is no guarantee about the upper wake up time. > > And it's not worth the effort to poll the FIFO state until its empty > (using 20 ms as timeout)? I know this isn't really a great argument there, but getting this to work has been quite painful, and the timing is very sensitive. If we fail to wait for enough time, there's going to be a pixel shift that we can't get rid of unless we reboot, which is pretty bad (and would fail any CI test that checks for the output integrity). I know busy-looping for 20ms isn't ideal, but it's not really in a hot-path (it's only done when changing a mode), with the sync time of the display likely to be much more than that, and if it can avoid having to look into it ever again or avoid random failures, I'd say it's worth it. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
