Re: [PATCH 0/6] Support second Image Signal Processor on rk3399
Hey Heiko, On 10.02.2021 12:15, Heiko Stübner wrote: Hi Sebastian, Am Freitag, 5. Februar 2021, 15:55:56 CET schrieb Heiko Stübner: Hi Sebastian, I did some tests myself today as well and can confirm your hdmi related finding - at least when plugged in on boot. I tried some combinations of camera vs. hdmi and it seems really only when hdmi is plugged in on boot as you can see in v2, it should work now even with hdmi connected on boot. My patch ignored the grf-clock when doing the grf-based init. All clocks are on during boot and I guess the hdmi-driver did disable it after its probe. The phy_power_on functions did handle it correctly already, so it was only happening with hdmi connected on boot. Thank you very much for solving that problem, I've tested the scenarios described below and it works like a charm. (With your V2) Btw. do you plan on submitting your ov13850 driver soonish? Actually, I have posted the patch already see here: https://patchwork.kernel.org/project/linux-media/patch/20210130182313.32903-2-sebastian.fri...@posteo.net/ I currently review the requested changes and questions and will soon post a second version, but I expect quite some time until it is actually merged. Heiko Greetings, Sebastian (1) - boot - camera --> works (2) - boot - camera - hdmi plugged in - hdmi works - camera --> works (3) - hdmi plugged in - boot - hdmi works - camera --> camera doesn't work (4) - boot - hdmi plugged in - hdmi works - camera -> camera works With a bit of brute-force [0] it seems the camera also works again even with hdmi connected on boot. So conclusion would be that some clock is misbehaving. Now we'll "only" need to find out which one that is. Heiko [0] Don't disable any clock gates diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c index 070dc47e95a1..8daf1fc3388c 100644 --- a/drivers/clk/clk-gate.c +++ b/drivers/clk/clk-gate.c @@ -61,6 +61,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable) set ^= enable; +if (!enable) +return; + if (gate->lock) spin_lock_irqsave(gate->lock, flags); else Am Freitag, 5. Februar 2021, 09:15:47 CET schrieb Heiko Stübner: > Hi Sebastian, > > Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke: > > On 03.02.2021 20:54, Heiko Stübner wrote: > > >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke: > > >> I have tested your patch set on my nanoPC-T4, here is a complete log > > >> with: > > >> - relevant kernel log entries > > >> - system information > > >> - media ctl output > > >> - sysfs entry information > > >> > > >> https://paste.debian.net/1183874/ > > >> > > >> Additionally, to your patchset I have applied the following patches: > > >> https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup > > >> > > >> And just to not cause confusion the `media_dev` entries come from this > > >> unmerged series: > > >> https://patchwork.kernel.org/project/linux-media/list/?series=426269 > > >> > > >> I have actually been able to stream with both of my cameras at the same > > >> time using the libcamera cam command. > > >> I would like to thank you a lot for making this possible. > > > > > >Thanks for testing a dual camera setup. On my board I could only test > > >the second ISP. And really glad it works for you tool :-) . > > > > > >Out of curiosity, do you also see that green tint in the images the cameras > > >produce? > > > > Yes, I do. Actually, I currently have two forms of a green tint, on my > > OV13850 everything is quite dark and greenish, which is caused by the > > missing 3A algorithms. On my OV4689, I have big patches of the image > > with bright green color and flickering, I investigated if this is > > connected to the 2nd ISP instance, but that doesn't seem to be the case > > as I have the same results when I switch the CSI ports of the cameras. > > > > I have found another issue, while testing I discovered following > > issue: > > When I start the system with an HDMI monitor connected, then the camera > > on the 2nd port doesn't work. This is probably because the RX/TX is > > reserved as a TX. > > But it made me wonder because if the system has an RX, a TX, and > > an RX/TX, why isn't the pure TX used by the monitor and the > > cameras take RX and RX/TX? > > Or do you think that this is maybe a malfunction of this patch? > > I don't think it is an issue with this specific series, but still puzzling. > > I.e. the DPHYs are actually only relevant to the DSI controllers, > with TX0 being connected to DSI0 and TX1RX1 being connected > to DSI1. So having an hdmi display _in theory_ shouldn't matter at all. > > Out of curiosity what happens, when you boot without hdmi connected > turn on the cameras, connect the hdmi after this, try the cameras again? > > > Heiko > > > > > > > > >Thanks > > >Heiko > > > > Greetings, > > Sebastian > > > > > > > > > > >> If you like to you can add: > > >> Tested-by: Seba
[PATCH v2] drm/gem: Move drm_gem_fb_prepare_fb() to GEM atomic helpers
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
but currently located next to framebuffer helpers. Move it to GEM atomic
helpers, rename it slightly and adopt the drivers. Same for the rsp
simple-pipe helper.
Compile-tested with x86-64, aarch64 and arm. The patch is fairly large,
but there are no functional changes.
v2:
* rename to drm_gem_plane_helper_prepare_fb() (Daniel)
* add tutorial-style documentation
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 4 +-
drivers/gpu/drm/drm_gem_atomic_helper.c | 96 +++-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 63 -
drivers/gpu/drm/drm_gem_vram_helper.c| 4 +-
drivers/gpu/drm/imx/dcss/dcss-plane.c| 4 +-
drivers/gpu/drm/imx/ipuv3-plane.c| 4 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 3 +-
drivers/gpu/drm/ingenic/ingenic-ipu.c| 4 +-
drivers/gpu/drm/mcde/mcde_display.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 6 +-
drivers/gpu/drm/meson/meson_overlay.c| 8 +-
drivers/gpu/drm/meson/meson_plane.c | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 4 +-
drivers/gpu/drm/msm/msm_atomic.c | 4 +-
drivers/gpu/drm/mxsfb/mxsfb_kms.c| 6 +-
drivers/gpu/drm/pl111/pl111_display.c| 4 +-
drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 4 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +-
drivers/gpu/drm/stm/ltdc.c | 4 +-
drivers/gpu/drm/sun4i/sun4i_layer.c | 4 +-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 4 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4 +-
drivers/gpu/drm/tegra/plane.c| 4 +-
drivers/gpu/drm/tidss/tidss_plane.c | 4 +-
drivers/gpu/drm/tiny/hx8357d.c | 4 +-
drivers/gpu/drm/tiny/ili9225.c | 4 +-
drivers/gpu/drm/tiny/ili9341.c | 4 +-
drivers/gpu/drm/tiny/ili9486.c | 4 +-
drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
drivers/gpu/drm/tiny/repaper.c | 3 +-
drivers/gpu/drm/tiny/st7586.c| 4 +-
drivers/gpu/drm/tiny/st7735r.c | 4 +-
drivers/gpu/drm/tve200/tve200_display.c | 4 +-
drivers/gpu/drm/vc4/vc4_plane.c | 4 +-
drivers/gpu/drm/vkms/vkms_plane.c| 3 +-
drivers/gpu/drm/xen/xen_drm_front_kms.c | 3 +-
include/drm/drm_gem_atomic_helper.h | 8 ++
include/drm/drm_gem_framebuffer_helper.h | 6 +-
include/drm/drm_modeset_helper_vtables.h | 2 +-
include/drm/drm_plane.h | 4 +-
include/drm/drm_simple_kms_helper.h | 2 +-
41 files changed, 178 insertions(+), 142 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index e54686c31a90..d8f214e0be82 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -9,8 +9,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
#include
@@ -219,7 +219,7 @@ static const struct drm_simple_display_pipe_funcs
aspeed_gfx_funcs = {
.enable = aspeed_gfx_pipe_enable,
.disable= aspeed_gfx_pipe_disable,
.update = aspeed_gfx_pipe_update,
- .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+ .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
.enable_vblank = aspeed_gfx_enable_vblank,
.disable_vblank = aspeed_gfx_disable_vblank,
};
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index fa4eae492b81..a005c5a0ba46 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -1,6 +1,10 @@
// SPDX-License-Identifier: GPL-2.0-or-later
+#include
+
#include
+#include
+#include
#include
#include
#include
@@ -12,8 +16,33 @@
*
* The GEM atomic helpers library implements generic atomic-commit
* functions for drivers that use GEM objects. Currently, it provides
- * plane state and framebuffer BO mappings for planes with shadow
- * buffers.
+ * synchronization helpers, and plane state and framebuffer BO mappings
+ * for planes with shadow buffers.
+ *
+ * Before scanout, a plane's framebuffer needs to be synchronized with
+ * possible writers that draw into the framebuffer. All drivers should
+ * call drm_gem_plane_helper_prepare_fb() from their implementation of
+ * struct &drm_plane_helper.prepare_fb . It sets the plane's fence from
+ * the framebuffer so that the DRM core can synchronize access automatically.
+ *
+ * drm_gem_plane_helper_prepare_fb() can also be used directly as
+ * implementation of prepare_fb. For drivers based on
+ * struct drm_simple_display_pipe, drm_gem_simple_display_pipe_prepare_fb()
+ * provides equivalent functionality.
+ *
+ * .. code-block:: c
+ *
+ *
[PULL] drm-intel-fixes
Hi Dave & Daniel - Calming down, just a couple of Cc: stable fixes now. drm-intel-fixes-2021-02-11: drm/i915 fixes for v5.11 final: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking BR, Jani. The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-02-11 for you to fetch changes up to 5feba0e905c495a217aea9db4ea91093d8fe5dde: drm/i915: Fix overlay frontbuffer tracking (2021-02-10 11:03:56 +0200) drm/i915 fixes for v5.11 final: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking Imre Deak (1): drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it Ville Syrjälä (1): drm/i915: Fix overlay frontbuffer tracking drivers/gpu/drm/i915/display/intel_overlay.c | 17 --- drivers/gpu/drm/i915/display/intel_tc.c | 67 +++- 2 files changed, 45 insertions(+), 39 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm/sprd: add Unisoc's drm display controller driver
Daniel Vetter 于2021年2月3日周三 下午10:15写道： > On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote: > > Adds DPU(Display Processor Unit) support for the Unisoc's display > subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and > more. > > > > Cc: Orson Zhai > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > > > v2: > > - Use drm_xxx to replace all DRM_XXX. > > - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. > > > > v3: > > - Remove dpu_layer stuff layer and commit layers by aotmic_update > > Scrolling through the code looks very tidy&neat, only thing I spotted is > that you could use the new drmm_ infrastructure we just landed. See > comments below, with that addressed: > Hi daniel, drmm_helpers seem still on drm-misc, so i need to switch to drm-misc(not mainline) and then update my patch on drm-misc? > > Acked-by: Daniel Vetter > > --- > > drivers/gpu/drm/sprd/Kconfig| 1 + > > drivers/gpu/drm/sprd/Makefile | 4 +- > > drivers/gpu/drm/sprd/sprd_dpu.c | 985 > > > drivers/gpu/drm/sprd/sprd_dpu.h | 120 + > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > 6 files changed, insertions(+), 2 deletions(-) > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > > index 6e80cc9..9b4ef9a 100644 > > --- a/drivers/gpu/drm/sprd/Kconfig > > +++ b/drivers/gpu/drm/sprd/Kconfig > > @@ -3,6 +3,7 @@ config DRM_SPRD > > depends on ARCH_SPRD || COMPILE_TEST > > depends on DRM && OF > > select DRM_KMS_HELPER > > + select VIDEOMODE_HELPERS > > select DRM_GEM_CMA_HELPER > > select DRM_KMS_CMA_HELPER > > select DRM_MIPI_DSI > > diff --git a/drivers/gpu/drm/sprd/Makefile > b/drivers/gpu/drm/sprd/Makefile > > index 86d95d9..6c25bfa 100644 > > --- a/drivers/gpu/drm/sprd/Makefile > > +++ b/drivers/gpu/drm/sprd/Makefile > > @@ -1,5 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -subdir-ccflags-y += -I$(srctree)/$(src) > > +obj-y := sprd_drm.o \ > > + sprd_dpu.o > > > > -obj-y := sprd_drm.o > > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c > b/drivers/gpu/drm/sprd/sprd_dpu.c > > new file mode 100644 > > index 000..d562d44 > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c > > @@ -0,0 +1,985 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2020 Unisoc Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "sprd_drm.h" > > +#include "sprd_dpu.h" > > + > > +/* Global control registers */ > > +#define REG_DPU_CTRL 0x04 > > +#define REG_DPU_CFG0 0x08 > > +#define REG_PANEL_SIZE 0x20 > > +#define REG_BLEND_SIZE 0x24 > > +#define REG_BG_COLOR 0x2C > > + > > +/* Layer0 control registers */ > > +#define REG_LAY_BASE_ADDR0 0x30 > > +#define REG_LAY_BASE_ADDR1 0x34 > > +#define REG_LAY_BASE_ADDR2 0x38 > > +#define REG_LAY_CTRL 0x40 > > +#define REG_LAY_SIZE 0x44 > > +#define REG_LAY_PITCH0x48 > > +#define REG_LAY_POS 0x4C > > +#define REG_LAY_ALPHA0x50 > > +#define REG_LAY_CROP_START 0x5C > > + > > +/* Interrupt control registers */ > > +#define REG_DPU_INT_EN 0x1E0 > > +#define REG_DPU_INT_CLR 0x1E4 > > +#define REG_DPU_INT_STS 0x1E8 > > + > > +/* DPI control registers */ > > +#define REG_DPI_CTRL 0x1F0 > > +#define REG_DPI_H_TIMING 0x1F4 > > +#define REG_DPI_V_TIMING 0x1F8 > > + > > +/* MMU control registers */ > > +#define REG_MMU_EN 0x800 > > +#define REG_MMU_VPN_RANGE0x80C > > +#define REG_MMU_VAOR_ADDR_RD 0x818 > > +#define REG_MMU_VAOR_ADDR_WR 0x81C > > +#define REG_MMU_INV_ADDR_RD 0x820 > > +#define REG_MMU_INV_ADDR_WR 0x824 > > +#define REG_MMU_PPN1 0x83C > > +#define REG_MMU_RANGE1 0x840 > > +#define REG_MMU_PPN2 0x844 > > +#define REG_MMU_RANGE2 0x848 > > + > > +/* Global control bits */ > > +#define BIT_DPU_RUN BIT(0) > > +#define BIT_DPU_STOP BIT(1) > > +#define BIT_DPU_REG_UPDATE BIT(2) > > +#define BIT_DPU_IF_EDPI BIT(0) > > + > > +/* Layer control bits */ > > +#define BIT_DPU_LAY_EN BIT(0) > > +#define BIT_DPU_LAY_LAYER_ALPHA (0x01 << 2) > > +#define BIT_DPU_LAY_COMBO_ALPHA (0x02 << 2) > > +#define BIT_DPU_LAY_FORMAT_YUV422_2PLANE (0x00 << 4) > > +#define BIT_DPU_LAY_FORMAT_YUV420_2P
Not 100% sure if I correctly fixed drm-tip
Hi guys, I had a conflict this morning in the ttm pool while pushing an important fix to drm-misc-fixes. I'm not 100% sure if I correctly fixed up drm-tip. How can this be double checked? And how can it be fixed if the merge has gone bad? Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Wednesday, February 10th, 2021 at 11:02 PM, Mario Kleiner wrote: > I'll prepare patches with the same fix for libdrm and igt as well soon. Please don't submit patches for drm_fourcc.h to downstream if they vendor the whole file. Instead, update it from the kernel once your patch is merged to drm-next. For instance, see [1] for libdrm. Simon [1]: https://gitlab.freedesktop.org/mesa/drm/-/blob/master/include/drm/README ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/omap: hdmi5: add CEC support
Add HDMI CEC support for OMAP5.
Many thanks to Tomi for helping out how to enable CEC for omap5.
Signed-off-by: Hans Verkuil
Thanks-to: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/Kconfig | 8 +
drivers/gpu/drm/omapdrm/dss/Makefile | 1 +
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 +
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 63 +--
drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c | 201 +++
drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h | 42 +
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 28 +++-
drivers/gpu/drm/omapdrm/dss/hdmi5_core.h | 33 +++-
8 files changed, 358 insertions(+), 19 deletions(-)
create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c
create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h
diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig
b/drivers/gpu/drm/omapdrm/dss/Kconfig
index e11b258a2294..67a1ba14703b 100644
--- a/drivers/gpu/drm/omapdrm/dss/Kconfig
+++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
@@ -83,6 +83,14 @@ config OMAP5_DSS_HDMI
Definition Multimedia Interface. See https://www.hdmi.org/ for HDMI
specification.
+config OMAP5_DSS_HDMI_CEC
+ bool "Enable HDMI CEC support for OMAP5"
+ depends on OMAP5_DSS_HDMI
+ select CEC_CORE
+ default y
+ help
+ When selected the HDMI transmitter will support the CEC feature.
+
config OMAP2_DSS_SDI
bool "SDI support"
default n
diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile
b/drivers/gpu/drm/omapdrm/dss/Makefile
index f967e6948f2e..94fe0fa3b3c2 100644
--- a/drivers/gpu/drm/omapdrm/dss/Makefile
+++ b/drivers/gpu/drm/omapdrm/dss/Makefile
@@ -17,4 +17,5 @@ omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o
hdmi_wp.o hdmi_pll.o \
omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
omapdss-$(CONFIG_OMAP4_DSS_HDMI_CEC) += hdmi4_cec.o
omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
+omapdss-$(CONFIG_OMAP5_DSS_HDMI_CEC) += hdmi5_cec.o
ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index c4a4e07f0b99..72d8ae441da6 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -261,6 +261,7 @@ struct hdmi_core_data {
struct hdmi_wp_data *wp;
unsigned int core_pwr_cnt;
struct cec_adapter *adap;
+ struct clk *cec_clk;
};
static inline void hdmi_write_reg(void __iomem *base_addr, const u32 idx,
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 54e5cb5aa52d..b674d8ba173f 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -29,12 +29,14 @@
#include
#include
#include
+#include
#include
#include
#include "omapdss.h"
#include "hdmi5_core.h"
+#include "hdmi5_cec.h"
#include "dss.h"
static int hdmi_runtime_get(struct omap_hdmi *hdmi)
@@ -104,6 +106,10 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data)
} else if (irqstatus & HDMI_IRQ_LINK_DISCONNECT) {
hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
}
+ if (irqstatus & HDMI_IRQ_CORE) {
+ hdmi5_cec_irq(&hdmi->core);
+ hdmi5_core_handle_irqs(&hdmi->core);
+ }
return IRQ_HANDLED;
}
@@ -112,9 +118,12 @@ static int hdmi_power_on_core(struct omap_hdmi *hdmi)
{
int r;
+ if (hdmi->core.core_pwr_cnt++)
+ return 0;
+
r = regulator_enable(hdmi->vdda_reg);
if (r)
- return r;
+ goto err_reg_enable;
r = hdmi_runtime_get(hdmi);
if (r)
@@ -129,12 +138,17 @@ static int hdmi_power_on_core(struct omap_hdmi *hdmi)
err_runtime_get:
regulator_disable(hdmi->vdda_reg);
+err_reg_enable:
+ hdmi->core.core_pwr_cnt--;
return r;
}
static void hdmi_power_off_core(struct omap_hdmi *hdmi)
{
+ if (--hdmi->core.core_pwr_cnt)
+ return;
+
hdmi->core_enabled = false;
hdmi_runtime_put(hdmi);
@@ -168,7 +182,7 @@ static int hdmi_power_on_full(struct omap_hdmi *hdmi)
pc, &hdmi_cinfo);
/* disable and clear irqs */
- hdmi_wp_clear_irqenable(&hdmi->wp, 0x);
+ hdmi_wp_clear_irqenable(&hdmi->wp, ~HDMI_IRQ_CORE);
hdmi_wp_set_irqstatus(&hdmi->wp,
hdmi_wp_get_irqstatus(&hdmi->wp));
@@ -225,7 +239,7 @@ static int hdmi_power_on_full(struct omap_hdmi *hdmi)
static void hdmi_power_off_full(struct omap_hdmi *hdmi)
{
- hdmi_wp_clear_irqenable(&hdmi->wp, 0x);
+ hdmi_wp_clear_irqenable(&hdmi->wp, ~HDMI_IRQ_CORE);
hdmi_wp_video_stop(&hdmi->wp);
@@ -273,11 +287,11 @@ static void hdmi_stop_audio_stream(struct omap_hdmi *hd)
REG_FLD_MOD(hd->wp.base, HDMI_WP_SYSCONFIG, hd->wp_idlemode, 3, 2);
}
-static int hdmi_core_enable(struct omap_hdmi *hdmi)
+int hdmi5_core_enable(struct omap_hdmi *hdmi)
{
[PATCH] drm/tiny: add driver for newhaven,1.8-128160EF
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
---
.../bindings/display/ilitek,ili9163.txt | 27 +++
drivers/gpu/drm/tiny/Kconfig | 13 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c| 224 ++
4 files changed, 265 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9163.txt
create mode 100644 drivers/gpu/drm/tiny/ili9163.c
diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
new file mode 100644
index 0..fee119991c14e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9163 display panels
+
+This binding is for display panels using an Ilitek ILI9163 controller in SPI
+mode.
+
+Required properties:
+- compatible: "newhaven,1.8-128160EF", "ilitek,ili9163"
+- dc-gpios:D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+ display@0{
+ compatible = "newhaven,1.8-128160EF", "ilitek,ili9163"
+ reg = <0>;
+ spi-max-frequency = <3200>;
+ dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+ rotation = <270>;
+ backlight = <&backlight>;
+ };
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa759..9de0c0eeea6f5 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -41,6 +41,19 @@ config TINYDRM_HX8357D
If M is selected the module will be called hx8357d.
+config TINYDRM_ILI9163
+ tristate "DRM support for ILI9163 display panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9163 panels:
+ * NHD-1.8-128160EF 128x160 TFT
+
+ If M is selected the module will be called ili9163.
+
config TINYDRM_ILI9225
tristate "DRM support for ILI9225 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35fb..78016b2ed11b5 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -3,6 +3,7 @@
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
+obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
new file mode 100644
index 0..9f90ea9556c4d
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9163_FRMCTR10xb1
+
+#define ILI9163_PWCTRL10xc0
+#define ILI9163_PWCTRL20xc1
+#define ILI9163_VMCTRL10xc5
+#define ILI9163_VMCTRL20xc7
+#define ILI9163_PWCTRLA0xcb
+#define ILI9163_PWCTRLB0xcf
+
+#define ILI9163_EN3GAM 0xf2
+
+#define ILI9163_MADCTL_BGR BIT(3)
+#define ILI9163_MADCTL_MV BIT(5)
+#define ILI9163_MADCTL_MX BIT(6)
+#define ILI9163_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ /* Gamma */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x04);
+ mipi_dbi_command(dbi, ILI9163_EN3GAM, 0x00);
+
+ /* Frame Rate */
+ mipi_dbi_command(dbi, ILI9163_FRMCTR1, 0x0a, 0x14);
+
+ /* Power Contro
[PATCH 3/5] drm/omap: hdmi4: simplify CEC Phys Addr handling
Switch to using cec_s_phys_addr_from_edid() instead of a two-step process
of calling cec_get_edid_phys_addr() followed by cec_s_phys_addr().
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 13 ++---
drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 5 +++--
3 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 765379380d4b..ac142f870109 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -432,7 +432,7 @@ static void hdmi4_bridge_hpd_notify(struct drm_bridge
*bridge,
struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
if (status == connector_status_disconnected)
- hdmi4_cec_set_phys_addr(&hdmi->core, CEC_PHYS_ADDR_INVALID);
+ hdmi4_cec_set_phys_addr(&hdmi->core, NULL);
}
static struct edid *hdmi4_bridge_get_edid(struct drm_bridge *bridge,
@@ -440,7 +440,6 @@ static struct edid *hdmi4_bridge_get_edid(struct drm_bridge
*bridge,
{
struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
struct edid *edid = NULL;
- unsigned int cec_addr;
bool need_enable;
int r;
@@ -466,15 +465,7 @@ static struct edid *hdmi4_bridge_get_edid(struct
drm_bridge *bridge,
hdmi_runtime_put(hdmi);
mutex_unlock(&hdmi->lock);
- if (edid && edid->extensions) {
- unsigned int len = (edid->extensions + 1) * EDID_LENGTH;
-
- cec_addr = cec_get_edid_phys_addr((u8 *)edid, len, NULL);
- } else {
- cec_addr = CEC_PHYS_ADDR_INVALID;
- }
-
- hdmi4_cec_set_phys_addr(&hdmi->core, cec_addr);
+ hdmi4_cec_set_phys_addr(&hdmi->core, edid);
if (need_enable)
hdmi4_core_disable(&hdmi->core);
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
index 64f5ccd0f11b..68b4c84e1864 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
@@ -329,9 +329,9 @@ static const struct cec_adap_ops hdmi_cec_adap_ops = {
.adap_transmit = hdmi_cec_adap_transmit,
};
-void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16 pa)
+void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, struct edid *edid)
{
- cec_s_phys_addr(core->adap, pa, false);
+ cec_s_phys_addr_from_edid(core->adap, edid);
}
int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data *core,
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
index b59a54c3040e..16bf259643b7 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
@@ -26,13 +26,14 @@ struct platform_device;
/* HDMI CEC funcs */
#ifdef CONFIG_OMAP4_DSS_HDMI_CEC
-void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16 pa);
+void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, struct edid *edid);
void hdmi4_cec_irq(struct hdmi_core_data *core);
int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data *core,
struct hdmi_wp_data *wp, struct drm_connector *conn);
void hdmi4_cec_uninit(struct hdmi_core_data *core);
#else
-static inline void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16 pa)
+static inline void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core,
+ struct edid *edid)
{
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] ARM: dts: dra7/omap5: add cec clock
Add cec clock to the dra7 and omap5 device trees.
Signed-off-by: Hans Verkuil
---
arch/arm/boot/dts/dra7.dtsi | 5 +++--
arch/arm/boot/dts/omap5.dtsi | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce1194744f84..efe579ddb324 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -879,8 +879,9 @@ hdmi: encoder@0 {
interrupts = ;
status = "disabled";
clocks = <&dss_clkctrl
DRA7_DSS_DSS_CORE_CLKCTRL 9>,
-<&dss_clkctrl
DRA7_DSS_DSS_CORE_CLKCTRL 10>;
- clock-names = "fck", "sys_clk";
+<&dss_clkctrl
DRA7_DSS_DSS_CORE_CLKCTRL 10>,
+<&dss_clkctrl
DRA7_DSS_DSS_CORE_CLKCTRL 11>;
+ clock-names = "fck", "sys_clk",
"cec";
dmas = <&sdma_xbar 76>;
dma-names = "audio_tx";
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5f1a8bd13880..2bb1000aeae9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -580,8 +580,9 @@ hdmi: encoder@0 {
interrupts = ;
status = "disabled";
clocks = <&dss_clkctrl
OMAP5_DSS_CORE_CLKCTRL 9>,
-<&dss_clkctrl
OMAP5_DSS_CORE_CLKCTRL 10>;
- clock-names = "fck", "sys_clk";
+<&dss_clkctrl
OMAP5_DSS_CORE_CLKCTRL 10>,
+<&dss_clkctrl
OMAP5_DSS_CORE_CLKCTRL 11>;
+ clock-names = "fck", "sys_clk",
"cec";
dmas = <&sdma 76>;
dma-names = "audio_tx";
};
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/omap: hdmi4: switch to the cec bridge ops
Implement the new CEC bridge ops. This makes it possible to associate
a CEC adapter with a drm connector, which helps userspace determine
with cec device node belongs to which drm connector.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 28 +
drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 8 ---
drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 7 ---
3 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 8de41e74e8f8..765379380d4b 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -482,6 +482,21 @@ static struct edid *hdmi4_bridge_get_edid(struct
drm_bridge *bridge,
return edid;
}
+static int hdmi4_bridge_cec_init(struct drm_bridge *bridge,
+struct drm_connector *conn)
+{
+ struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
+
+ return hdmi4_cec_init(hdmi->pdev, &hdmi->core, &hdmi->wp, conn);
+}
+
+static void hdmi4_bridge_cec_exit(struct drm_bridge *bridge)
+{
+ struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
+
+ hdmi4_cec_uninit(&hdmi->core);
+}
+
static const struct drm_bridge_funcs hdmi4_bridge_funcs = {
.attach = hdmi4_bridge_attach,
.mode_set = hdmi4_bridge_mode_set,
@@ -492,13 +507,15 @@ static const struct drm_bridge_funcs hdmi4_bridge_funcs =
{
.atomic_disable = hdmi4_bridge_disable,
.hpd_notify = hdmi4_bridge_hpd_notify,
.get_edid = hdmi4_bridge_get_edid,
+ .cec_init = hdmi4_bridge_cec_init,
+ .cec_exit = hdmi4_bridge_cec_exit,
};
static void hdmi4_bridge_init(struct omap_hdmi *hdmi)
{
hdmi->bridge.funcs = &hdmi4_bridge_funcs;
hdmi->bridge.of_node = hdmi->pdev->dev.of_node;
- hdmi->bridge.ops = DRM_BRIDGE_OP_EDID;
+ hdmi->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_CEC;
hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
drm_bridge_add(&hdmi->bridge);
@@ -647,14 +664,10 @@ static int hdmi4_bind(struct device *dev, struct device
*master, void *data)
if (r)
goto err_runtime_put;
- r = hdmi4_cec_init(hdmi->pdev, &hdmi->core, &hdmi->wp);
- if (r)
- goto err_pll_uninit;
-
r = hdmi_audio_register(hdmi);
if (r) {
DSSERR("Registering HDMI audio failed\n");
- goto err_cec_uninit;
+ goto err_pll_uninit;
}
hdmi->debugfs = dss_debugfs_create_file(dss, "hdmi", hdmi_dump_regs,
@@ -664,8 +677,6 @@ static int hdmi4_bind(struct device *dev, struct device
*master, void *data)
return 0;
-err_cec_uninit:
- hdmi4_cec_uninit(&hdmi->core);
err_pll_uninit:
hdmi_pll_uninit(&hdmi->pll);
err_runtime_put:
@@ -682,7 +693,6 @@ static void hdmi4_unbind(struct device *dev, struct device
*master, void *data)
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
- hdmi4_cec_uninit(&hdmi->core);
hdmi_pll_uninit(&hdmi->pll);
}
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
index 43592c1cf081..64f5ccd0f11b 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
@@ -335,10 +335,10 @@ void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core,
u16 pa)
}
int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data *core,
- struct hdmi_wp_data *wp)
+ struct hdmi_wp_data *wp, struct drm_connector *conn)
{
- const u32 caps = CEC_CAP_TRANSMIT | CEC_CAP_LOG_ADDRS |
-CEC_CAP_PASSTHROUGH | CEC_CAP_RC;
+ const u32 caps = CEC_CAP_DEFAULTS | CEC_CAP_CONNECTOR_INFO;
+ struct cec_connector_info conn_info;
int ret;
core->adap = cec_allocate_adapter(&hdmi_cec_adap_ops, core,
@@ -346,6 +346,8 @@ int hdmi4_cec_init(struct platform_device *pdev, struct
hdmi_core_data *core,
ret = PTR_ERR_OR_ZERO(core->adap);
if (ret < 0)
return ret;
+ cec_fill_conn_info_from_drm(&conn_info, conn);
+ cec_s_conn_info(core->adap, &conn_info);
core->wp = wp;
/* Disable clock initially, hdmi_cec_adap_enable() manages it */
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
index 0292337c97cc..b59a54c3040e 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
@@ -29,7 +29,7 @@ struct platform_device;
void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16 pa);
void hdmi4_cec_irq(struct hdmi_core_data *core);
int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data *core,
- struct hdmi_wp_data *wp);
+ struct hdmi_wp_data *wp, struct drm_connector *conn);
void hdmi4_cec_uninit(struct hdmi_core_data *core)
[PATCH 1/5] drm: drm_bridge: add cec_init/exit bridge ops
Add bridge cec_init/exit ops. These ops will be responsible for
creating and destroying the CEC adapter for the bridge that supports
CEC.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/drm_bridge_connector.c | 23 +++
include/drm/drm_bridge.h | 31 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index 791379816837..2ff90f5e468c 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -84,6 +84,13 @@ struct drm_bridge_connector {
* connector modes detection, if any (see &DRM_BRIDGE_OP_MODES).
*/
struct drm_bridge *bridge_modes;
+ /**
+* @bridge_cec:
+*
+* The last bridge in the chain (closest to the connector) that provides
+* cec adapter support, if any (see &DRM_BRIDGE_OP_CEC).
+*/
+ struct drm_bridge *bridge_cec;
};
#define to_drm_bridge_connector(x) \
@@ -204,6 +211,11 @@ static void drm_bridge_connector_destroy(struct
drm_connector *connector)
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
+ if (bridge_connector->bridge_cec) {
+ struct drm_bridge *cec = bridge_connector->bridge_cec;
+
+ cec->funcs->cec_exit(cec);
+ }
if (bridge_connector->bridge_hpd) {
struct drm_bridge *hpd = bridge_connector->bridge_hpd;
@@ -352,6 +364,8 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
bridge_connector->bridge_detect = bridge;
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
+ if (bridge->ops & DRM_BRIDGE_OP_CEC)
+ bridge_connector->bridge_cec = bridge;
if (!drm_bridge_get_next_bridge(bridge))
connector_type = bridge->type;
@@ -374,6 +388,15 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
else if (bridge_connector->bridge_detect)
connector->polled = DRM_CONNECTOR_POLL_CONNECT
| DRM_CONNECTOR_POLL_DISCONNECT;
+ if (bridge_connector->bridge_cec) {
+ struct drm_bridge *bridge = bridge_connector->bridge_cec;
+ int ret = bridge->funcs->cec_init(bridge, connector);
+
+ if (ret) {
+ drm_bridge_connector_destroy(connector);
+ return ERR_PTR(ret);
+ }
+ }
return connector;
}
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 2195daa289d2..4c83c2657e87 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -629,6 +629,30 @@ struct drm_bridge_funcs {
* the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
*/
void (*hpd_disable)(struct drm_bridge *bridge);
+
+ /**
+* @cec_init:
+*
+* Initialize the CEC adapter.
+*
+* This callback is optional and shall only be implemented by bridges
+* that support a CEC adapter. Bridges that implement it shall also
+* implement the @cec_exit callback and set the DRM_BRIDGE_OP_CEC flag
+* in their &drm_bridge->ops.
+*/
+ int (*cec_init)(struct drm_bridge *bridge, struct drm_connector *conn);
+
+ /**
+* @cec_exit:
+*
+* Terminate the CEC adapter.
+*
+* This callback is optional and shall only be implemented by bridges
+* that support a CEC adapter. Bridges that implement it shall also
+* implement the @cec_init callback and set the DRM_BRIDGE_OP_CEC flag
+* in their &drm_bridge->ops.
+*/
+ void (*cec_exit)(struct drm_bridge *bridge);
};
/**
@@ -698,6 +722,13 @@ enum drm_bridge_ops {
* this flag shall implement the &drm_bridge_funcs->get_modes callback.
*/
DRM_BRIDGE_OP_MODES = BIT(3),
+ /**
+* @DRM_BRIDGE_OP_CEC: The bridge supports a CEC adapter.
+* Bridges that set this flag shall implement the
+* &drm_bridge_funcs->cec_init and &drm_bridge_funcs->cec_exit
+* callbacks.
+*/
+ DRM_BRIDGE_OP_CEC = BIT(4),
};
/**
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/omap: hdmi: improve hdmi4 CEC, add CEC for hdmi5
This series improves the drm_bridge support for CEC by introducing two new bridge ops in the first patch, and using those in the second patch. This makes it possible to call cec_s_conn_info() and set CEC_CAP_CONNECTOR_INFO for the CEC adapter, so userspace can associate the CEC adapter with the corresponding DRM connector. The third patch simplifies CEC physical address handling by using the cec_s_phys_addr_from_edid helper function that didn't exist when this code was originally written. The fourth patch adds CEC support to the OMAP5 driver and the last patch adds the missing cec clock to the dra7 and omap5 device tree. Tested with a Pandaboard and a Beagle X15 board. Regards, Hans Hans Verkuil (5): drm: drm_bridge: add cec_init/exit bridge ops drm/omap: hdmi4: switch to the cec bridge ops drm/omap: hdmi4: simplify CEC Phys Addr handling drm/omap: hdmi5: add CEC support ARM: dts: dra7/omap5: add cec clock arch/arm/boot/dts/dra7.dtsi | 5 +- arch/arm/boot/dts/omap5.dtsi | 5 +- drivers/gpu/drm/drm_bridge_connector.c | 23 +++ drivers/gpu/drm/omapdrm/dss/Kconfig | 8 + drivers/gpu/drm/omapdrm/dss/Makefile | 1 + drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 + drivers/gpu/drm/omapdrm/dss/hdmi4.c | 41 ++--- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 12 +- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 12 +- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 63 +-- drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c | 201 +++ drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h | 42 + drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 28 +++- drivers/gpu/drm/omapdrm/dss/hdmi5_core.h | 33 +++- include/drm/drm_bridge.h | 31 15 files changed, 453 insertions(+), 53 deletions(-) create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/ttm: remove swap LRU
Hi "Christian,
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-move-swapout-logic-around/20210210-232812
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: ia64-randconfig-m031-20210209 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/ttm/ttm_device.c:144 ttm_device_swapout() warn: variable
dereferenced before check 'bo->ttm' (see line 142)
vim +144 drivers/gpu/drm/ttm/ttm_device.c
d37e3072dc32c7 Christian König 2021-02-10 125 long ttm_device_swapout(struct
ttm_device *bdev, struct ttm_operation_ctx *ctx,
d37e3072dc32c7 Christian König 2021-02-10 126 gfp_t
gfp_flags)
d37e3072dc32c7 Christian König 2021-02-10 127 {
d37e3072dc32c7 Christian König 2021-02-10 128 struct ttm_global *glob
= &ttm_glob;
d37e3072dc32c7 Christian König 2021-02-10 129 struct
ttm_resource_manager *man;
22b09b650f7486 Christian König 2021-02-10 130 struct
ttm_buffer_object *bo;
d37e3072dc32c7 Christian König 2021-02-10 131 unsigned i, j;
22b09b650f7486 Christian König 2021-02-10 132 int ret;
22b09b650f7486 Christian König 2021-02-10 133
22b09b650f7486 Christian König 2021-02-10 134
spin_lock(&glob->lru_lock);
d37e3072dc32c7 Christian König 2021-02-10 135 for (i = TTM_PL_SYSTEM;
i < TTM_NUM_MEM_TYPES; ++i) {
d37e3072dc32c7 Christian König 2021-02-10 136 man =
ttm_manager_type(bdev, i);
d37e3072dc32c7 Christian König 2021-02-10 137 if (!man ||
!man->use_tt)
d37e3072dc32c7 Christian König 2021-02-10 138
continue;
d37e3072dc32c7 Christian König 2021-02-10 139
d37e3072dc32c7 Christian König 2021-02-10 140 for (j = 0; j <
TTM_MAX_BO_PRIORITY; ++j) {
d37e3072dc32c7 Christian König 2021-02-10 141
list_for_each_entry(bo, &man->lru[j], lru) {
d37e3072dc32c7 Christian König 2021-02-10 @142
long num_pages = bo->ttm->num_pages;
^
Dereferenced
d37e3072dc32c7 Christian König 2021-02-10 143
d37e3072dc32c7 Christian König 2021-02-10 @144
if (!bo->ttm ||
Checked too late
d37e3072dc32c7 Christian König 2021-02-10 145
bo->ttm->page_flags & TTM_PAGE_FLAG_SG ||
d37e3072dc32c7 Christian König 2021-02-10 146
bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)
d37e3072dc32c7 Christian König 2021-02-10 147
continue;
22b09b650f7486 Christian König 2021-02-10 148
22b09b650f7486 Christian König 2021-02-10 149
ret = ttm_bo_swapout(bo, ctx, gfp_flags);
22b09b650f7486 Christian König 2021-02-10 150
/* ttm_bo_swapout has dropped the lru_lock */
22b09b650f7486 Christian König 2021-02-10 151
if (!ret)
22b09b650f7486 Christian König 2021-02-10 152
return num_pages;
22b09b650f7486 Christian König 2021-02-10 153
if (ret != -EBUSY)
22b09b650f7486 Christian König 2021-02-10 154
return ret;
22b09b650f7486 Christian König 2021-02-10 155 }
22b09b650f7486 Christian König 2021-02-10 156 }
d37e3072dc32c7 Christian König 2021-02-10 157 }
22b09b650f7486 Christian König 2021-02-10 158
spin_unlock(&glob->lru_lock);
22b09b650f7486 Christian König 2021-02-10 159 return 0;
22b09b650f7486 Christian König 2021-02-10 160 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 18/18] drm/i915/display13: Enabling dithering after the CC1 pipe
On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
> From: Nischal Varide
>
> If the panel is 12bpc then Dithering is not enabled in the Legacy
> dithering block , instead its Enabled after the C1 CC1 pipe post
> color space conversion.For a 6bpc pannel Dithering is enabled in
> Legacy block.
Dithering is probably going to require a whole uapi bikeshed.
Not sure we can just enable it unilaterally.
Ccing dri-devel, and Mario who had issues with dithering in the
past...
>
> Cc: Uma Shankar
> Signed-off-by: Nischal Varide
> Signed-off-by: Bhanuprakash Modem
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 16
> drivers/gpu/drm/i915/display/intel_display.c | 9 -
> drivers/gpu/drm/i915/i915_reg.h | 3 ++-
> 3 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ff7dcb7088bf..9a0572bbc5db 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1604,6 +1604,20 @@ static u32 icl_csc_mode(const struct intel_crtc_state
> *crtc_state)
> return csc_mode;
> }
>
> +static u32 dither_after_cc1_12bpc(const struct intel_crtc_state *crtc_state)
> +{
> + u32 gamma_mode = crtc_state->gamma_mode;
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> + if (HAS_DISPLAY13(i915)) {
> + if (!crtc_state->dither_force_disable &&
> + (crtc_state->pipe_bpp == 36))
> + gamma_mode |= GAMMA_MODE_DITHER_AFTER_CC1;
> + }
> +
> + return gamma_mode;
> +}
> +
> static int icl_color_check(struct intel_crtc_state *crtc_state)
> {
> int ret;
> @@ -1614,6 +1628,8 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
>
> crtc_state->gamma_mode = icl_gamma_mode(crtc_state);
>
> + crtc_state->gamma_mode = dither_after_cc1_12bpc(crtc_state);
> +
> crtc_state->csc_mode = icl_csc_mode(crtc_state);
>
> crtc_state->preload_luts = intel_can_preload_luts(crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4dc4b1be0809..e3dbcd956fc6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8098,9 +8098,15 @@ static void bdw_set_pipemisc(const struct
> intel_crtc_state *crtc_state)
> break;
> }
>
> - if (crtc_state->dither)
> + /*
> + * If 12bpc panel then, Enables dithering after the CC1 pipe
> + * post color space conversion and not here
> + */
> +
> + if (crtc_state->dither && (crtc_state->pipe_bpp != 36))
> val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
>
> +
> if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> val |= PIPEMISC_OUTPUT_COLORSPACE_YUV;
> @@ -10760,6 +10766,7 @@ intel_modeset_pipe_config(struct intel_atomic_state
> *state,
>*/
> pipe_config->dither = (pipe_config->pipe_bpp == 6*3) &&
> !pipe_config->dither_force_disable;
> +
> drm_dbg_kms(&i915->drm,
> "hw max bpp: %i, pipe bpp: %i, dithering: %i\n",
> base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 128b835c0adb..27f25214a839 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6132,7 +6132,7 @@ enum {
> #define PIPEMISC_DITHER_8_BPC (0 << 5)
> #define PIPEMISC_DITHER_10_BPC (1 << 5)
> #define PIPEMISC_DITHER_6_BPC (2 << 5)
> -#define PIPEMISC_DITHER_12_BPC (3 << 5)
> +#define PIPEMISC_DITHER_12_BPC (4 << 5)
> #define PIPEMISC_DITHER_ENABLE (1 << 4)
> #define PIPEMISC_DITHER_TYPE_MASK (3 << 2)
> #define PIPEMISC_DITHER_TYPE_SP(0 << 2)
> @@ -7668,6 +7668,7 @@ enum {
> #define GAMMA_MODE_MODE_12BIT (2 << 0)
> #define GAMMA_MODE_MODE_SPLIT (3 << 0) /* ivb-bdw */
> #define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0) /* icl + */
> +#define GAMMA_MODE_DITHER_AFTER_CC1 (1 << 26)
>
> /* DMC/CSR */
> #define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
> --
> 2.25.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211651] Dual screen not working with Nvidia GTX 1050ti in a notebook
https://bugzilla.kernel.org/show_bug.cgi?id=211651 --- Comment #4 from fily1212 (ker...@fily.com.de) --- Thank you for your reply. Are we sure that this is outside of control of the kernel, since it works with Kernel 5.3 and not with 5.8 and later, same drivers? Best, Filippo -- You may reply to this email to add a comment. 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
[PATCH 1/4] drm/vram-helper: cleanup drm_gem_vram_bo_driver_move_notify
Swapping bo->mem was completely unecessary. Cleanup the function which
is just a leftover from a TTM cleanup.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index a0992f0b8afd..0c2233ee6029 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -564,9 +564,7 @@ static void drm_gem_vram_bo_driver_evict_flags(struct
drm_gem_vram_object *gbo,
*pl = gbo->placement;
}
-static void drm_gem_vram_bo_driver_move_notify(struct drm_gem_vram_object *gbo,
- bool evict,
- struct ttm_resource *new_mem)
+static void drm_gem_vram_bo_driver_move_notify(struct drm_gem_vram_object *gbo)
{
struct ttm_buffer_object *bo = &gbo->bo;
struct drm_device *dev = bo->base.dev;
@@ -582,16 +580,8 @@ static int drm_gem_vram_bo_driver_move(struct
drm_gem_vram_object *gbo,
struct ttm_operation_ctx *ctx,
struct ttm_resource *new_mem)
{
- int ret;
-
- drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
- ret = ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
- if (ret) {
- swap(*new_mem, gbo->bo.mem);
- drm_gem_vram_bo_driver_move_notify(gbo, false, new_mem);
- swap(*new_mem, gbo->bo.mem);
- }
- return ret;
+ drm_gem_vram_bo_driver_move_notify(gbo);
+ return ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
}
/*
@@ -947,7 +937,7 @@ static void bo_driver_delete_mem_notify(struct
ttm_buffer_object *bo)
gbo = drm_gem_vram_of_bo(bo);
- drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
+ drm_gem_vram_bo_driver_move_notify(gbo);
}
static int bo_driver_move(struct ttm_buffer_object *bo,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/qxl: clean up qxl_bo_move_notify
Remove the unused evict parameter and drop swapping bo->mem.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index b7f77eb685cb..47afe95d04a1 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -121,7 +121,6 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
ttm_buffer_object *bo,
}
static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
- bool evict,
struct ttm_resource *new_mem)
{
struct qxl_bo *qbo;
@@ -144,29 +143,22 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool
evict,
struct ttm_resource *old_mem = &bo->mem;
int ret;
- qxl_bo_move_notify(bo, evict, new_mem);
+ qxl_bo_move_notify(bo, new_mem);
ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
- goto out;
+ return ret;
if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
ttm_bo_move_null(bo, new_mem);
return 0;
}
- ret = ttm_bo_move_memcpy(bo, ctx, new_mem);
-out:
- if (ret) {
- swap(*new_mem, bo->mem);
- qxl_bo_move_notify(bo, false, new_mem);
- swap(*new_mem, bo->mem);
- }
- return ret;
+ return ttm_bo_move_memcpy(bo, ctx, new_mem);
}
static void qxl_bo_delete_mem_notify(struct ttm_buffer_object *bo)
{
- qxl_bo_move_notify(bo, false, NULL);
+ qxl_bo_move_notify(bo, NULL);
}
static struct ttm_device_funcs qxl_bo_driver = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/vmwgfx: clean up vmw_move_notify
Instead of swapping bo->mem just give old and new as parameters.
Also drop unused parameters and code.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 9 +---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 26 +++---
3 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index e65b00f8336d..21a72fa7b9fd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -775,7 +775,8 @@ extern void vmw_resource_unreserve(struct vmw_resource *res,
struct vmw_buffer_object *new_backup,
unsigned long new_backup_offset);
extern void vmw_query_move_notify(struct ttm_buffer_object *bo,
- struct ttm_resource *mem);
+ struct ttm_resource *old_mem,
+ struct ttm_resource *new_mem);
extern int vmw_query_readback_all(struct vmw_buffer_object *dx_query_mob);
extern void vmw_resource_evict_all(struct vmw_private *dev_priv);
extern void vmw_resource_unbind_list(struct vmw_buffer_object *vbo);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index c3a724e37104..35f02958ee2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -847,13 +847,15 @@ int vmw_query_readback_all(struct vmw_buffer_object
*dx_query_mob)
* vmw_query_move_notify - Read back cached query states
*
* @bo: The TTM buffer object about to move.
- * @mem: The memory region @bo is moving to.
+ * @old_mem: The memory region @bo is moving from.
+ * @new_mem: The memory region @bo is moving to.
*
* Called before the query MOB is swapped out to read back cached query
* states from the device.
*/
void vmw_query_move_notify(struct ttm_buffer_object *bo,
- struct ttm_resource *mem)
+ struct ttm_resource *old_mem,
+ struct ttm_resource *new_mem)
{
struct vmw_buffer_object *dx_query_mob;
struct ttm_device *bdev = bo->bdev;
@@ -871,7 +873,8 @@ void vmw_query_move_notify(struct ttm_buffer_object *bo,
}
/* If BO is being moved from MOB to system memory */
- if (mem->mem_type == TTM_PL_SYSTEM && bo->mem.mem_type == VMW_PL_MOB) {
+ if (new_mem->mem_type == TTM_PL_SYSTEM &&
+ old_mem->mem_type == VMW_PL_MOB) {
struct vmw_fence_obj *fence;
(void) vmw_query_readback_all(dx_query_mob);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 63f10c865061..38801462134e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -692,20 +692,19 @@ static int vmw_ttm_io_mem_reserve(struct ttm_device
*bdev, struct ttm_resource *
*
* @bo: The TTM buffer object about to move.
* @evict: Unused
- * @mem: The struct ttm_resource indicating to what memory
+ * @old_mem: The old memory where we move from
+ * @new_mem: The struct ttm_resource indicating to what memory
* region the move is taking place.
*
* Calls move_notify for all subsystems needing it.
* (currently only resources).
*/
static void vmw_move_notify(struct ttm_buffer_object *bo,
- bool evict,
- struct ttm_resource *mem)
+ struct ttm_resource *old_mem,
+ struct ttm_resource *new_mem)
{
- if (!mem)
- return;
- vmw_bo_move_notify(bo, mem);
- vmw_query_move_notify(bo, mem);
+ vmw_bo_move_notify(bo, new_mem);
+ vmw_query_move_notify(bo, old_mem, new_mem);
}
@@ -736,7 +735,7 @@ static int vmw_move(struct ttm_buffer_object *bo,
return ret;
}
- vmw_move_notify(bo, evict, new_mem);
+ vmw_move_notify(bo, &bo->mem, new_mem);
if (old_man->use_tt && new_man->use_tt) {
if (bo->mem.mem_type == TTM_PL_SYSTEM) {
@@ -758,18 +757,10 @@ static int vmw_move(struct ttm_buffer_object *bo,
}
return 0;
fail:
- swap(*new_mem, bo->mem);
- vmw_move_notify(bo, false, new_mem);
- swap(*new_mem, bo->mem);
+ vmw_move_notify(bo, new_mem, &bo->mem);
return ret;
}
-static void
-vmw_delete_mem_notify(struct ttm_buffer_object *bo)
-{
- vmw_move_notify(bo, false, NULL);
-}
-
struct ttm_device_funcs vmw_bo_driver = {
.ttm_tt_create = &vmw_ttm_tt_create,
.ttm_tt_populate = &vmw_ttm_populate,
@@ -779,7 +770,6 @@ struct ttm_device_funcs vmw_bo_driver = {
.evict_flags = vmw_evict_flags,
.move = vmw_move,
.verify_access = vmw_verify_access,
- .delete_mem_notify =
[PATCH 3/4] drm/nouveau: clean up nouveau_bo_move_ntfy
Just another leftover from a TTM cleanup.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index ca2a8ae1938e..9bb8cee3df40 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -861,9 +861,8 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
NV_INFO(drm, "MM: using %s for buffer copies\n", name);
}
-static void
-nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool evict,
-struct ttm_resource *new_reg)
+static void nouveau_bo_move_ntfy(struct ttm_buffer_object *bo,
+struct ttm_resource *new_reg)
{
struct nouveau_mem *mem = new_reg ? nouveau_mem(new_reg) : NULL;
struct nouveau_bo *nvbo = nouveau_bo(bo);
@@ -949,7 +948,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
return ret;
}
- nouveau_bo_move_ntfy(bo, evict, new_reg);
+ nouveau_bo_move_ntfy(bo, new_reg);
ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
goto out_ntfy;
@@ -1014,9 +1013,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
}
out_ntfy:
if (ret) {
- swap(*new_reg, bo->mem);
- nouveau_bo_move_ntfy(bo, false, new_reg);
- swap(*new_reg, bo->mem);
+ nouveau_bo_move_ntfy(bo, &bo->mem);
}
return ret;
}
@@ -1290,7 +1287,7 @@ nouveau_bo_fence(struct nouveau_bo *nvbo, struct
nouveau_fence *fence, bool excl
static void
nouveau_bo_delete_mem_notify(struct ttm_buffer_object *bo)
{
- nouveau_bo_move_ntfy(bo, false, NULL);
+ nouveau_bo_move_ntfy(bo, NULL);
}
struct ttm_device_funcs nouveau_bo_driver = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm: a6xx: Make sure the SQE microcode is safe
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
v2: Add more informative error messages and fix typos
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 77 ++-
1 file changed, 64 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..064b7face504 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -522,28 +522,73 @@ static int a6xx_cp_init(struct msm_gpu *gpu)
return a6xx_idle(gpu, ring) ? 0 : -EINVAL;
}
-static void a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
+/*
+ * Check that the microcode version is new enough to include several key
+ * security fixes. Return true if the ucode is safe.
+ */
+static bool a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
struct drm_gem_object *obj)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
u32 *buf = msm_gem_get_vaddr(obj);
+ bool ret = false;
if (IS_ERR(buf))
- return;
+ return false;
/*
-* If the lowest nibble is 0xa that is an indication that this microcode
-* has been patched. The actual version is in dword [3] but we only care
-* about the patchlevel which is the lowest nibble of dword [3]
-*
-* Otherwise check that the firmware is greater than or equal to 1.90
-* which was the first version that had this fix built in
+* Targets up to a640 (a618, a630 and a640) need to check for a
+* microcode version that is patched to support the whereami opcode or
+* one that is new enough to include it by default.
*/
- if (((buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1)
- a6xx_gpu->has_whereami = true;
- else if ((buf[0] & 0xfff) > 0x190)
- a6xx_gpu->has_whereami = true;
+ if (adreno_is_a618(adreno_gpu) || adreno_is_a630(adreno_gpu) ||
+ adreno_is_a640(adreno_gpu)) {
+ /*
+* If the lowest nibble is 0xa that is an indication that this
+* microcode has been patched. The actual version is in dword
+* [3] but we only care about the patchlevel which is the lowest
+* nibble of dword [3]
+*
+* Otherwise check that the firmware is greater than or equal
+* to 1.90 which was the first version that had this fix built
+* in
+*/
+ if buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1) ||
+ (buf[0] & 0xfff) >= 0x190) {
+ a6xx_gpu->has_whereami = true;
+ ret = true;
+ goto out;
+ }
+ DRM_DEV_ERROR(&gpu->pdev->dev,
+ "a630 SQE ucode is too old. Have version %x need at least
%x\n",
+ buf[0] & 0xfff, 0x190);
+ } else {
+ /*
+* a650 tier targets don't need whereami but still need to be
+* equal to or newer than 1.95 for other security fixes
+*/
+ if (adreno_is_a650(adreno_gpu)) {
+ if ((buf[0] & 0xfff) >= 0x195) {
+ ret = true;
+ goto out;
+ }
+
+ DRM_DEV_ERROR(&gpu->pdev->dev,
+ "a650 SQE ucode is too old. Have version %x need at
least %x\n",
+ buf[0] & 0xfff, 0x195);
+ }
+
+ /*
+* When a660 is added those targets should return true here
+* since those have all the critical security fixes built in
+* from the start
+*/
Or we can just initialize 'ret' as true.
-Akhil
+ }
+out:
msm_gem_put_vaddr(obj);
+ return ret;
}
static int a6xx_ucode_init(struct msm_gpu *gpu)
@@ -566,7 +611,13 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
}
msm_gem_object_set_name(a6xx_gpu->sqe_bo, "sqefw");
- a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo);
+ if (!a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo)) {
+ msm_gem_unpin_iova(a6xx_gpu->sqe_bo, gpu->aspace);
+ drm_gem_object_put(a6xx_gpu->sqe_bo);
+
+ a6xx_gpu->sqe_bo = NULL;
+ return -EPERM;
+ }
}
gpu_write64(gpu, REG_A6XX_CP_SQE_INSTR_BASE_LO,
___
[PATCH 1/3] drm/ttm: move swapout logic around
Move the iteration of the global lru into the new function
ttm_global_swapout() and use that instead in drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 57 -
drivers/gpu/drm/ttm/ttm_device.c| 29 +++
drivers/gpu/drm/ttm/ttm_tt.c| 2 +-
drivers/gpu/drm/vmwgfx/ttm_memory.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 3 +-
include/drm/ttm/ttm_device.h| 2 +
7 files changed, 53 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e38102282fd5..d33578a112b4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1184,56 +1184,35 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_wait);
-/*
- * A buffer object shrink method that tries to swap out the first
- * buffer object on the bo_global::swap_lru list.
- */
-int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
+int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
+ gfp_t gfp_flags)
{
struct ttm_global *glob = &ttm_glob;
- struct ttm_buffer_object *bo;
- int ret = -EBUSY;
bool locked;
- unsigned i;
-
- spin_lock(&glob->lru_lock);
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- list_for_each_entry(bo, &glob->swap_lru[i], swap) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked,
- NULL))
- continue;
-
- if (!ttm_bo_get_unless_zero(bo)) {
- if (locked)
- dma_resv_unlock(bo->base.resv);
- continue;
- }
+ int ret;
- ret = 0;
- break;
- }
- if (!ret)
- break;
- }
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, NULL))
+ return -EBUSY;
- if (ret) {
- spin_unlock(&glob->lru_lock);
- return ret;
+ if (!ttm_bo_get_unless_zero(bo)) {
+ if (locked)
+ dma_resv_unlock(bo->base.resv);
+ return -EBUSY;
}
if (bo->deleted) {
- ret = ttm_bo_cleanup_refs(bo, false, false, locked);
+ ttm_bo_cleanup_refs(bo, false, false, locked);
ttm_bo_put(bo);
- return ret;
+ return 0;
}
ttm_bo_del_from_lru(bo);
+ /* TODO: Cleanup the locking */
spin_unlock(&glob->lru_lock);
- /**
+ /*
* Move to system cached
*/
-
if (bo->mem.mem_type != TTM_PL_SYSTEM) {
struct ttm_operation_ctx ctx = { false, false };
struct ttm_resource evict_mem;
@@ -1253,29 +1232,26 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
}
}
- /**
+ /*
* Make sure BO is idle.
*/
-
ret = ttm_bo_wait(bo, false, false);
if (unlikely(ret != 0))
goto out;
ttm_bo_unmap_virtual(bo);
- /**
+ /*
* Swap out. Buffer will be swapped in again as soon as
* anyone tries to access a ttm page.
*/
-
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
out:
- /**
-*
+ /*
* Unreserve without putting on LRU to avoid swapping out an
* already swapped buffer.
*/
@@ -1284,7 +1260,6 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
ttm_bo_put(bo);
return ret;
}
-EXPORT_SYMBOL(ttm_bo_swapout);
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
{
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 95e1b7b1f2e6..dfc2a7e4e490 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -102,6 +102,35 @@ static int ttm_global_init(void)
return ret;
}
+/**
+ * A buffer object shrink method that tries to swap out the first
+ * buffer object on the global::swap_lru list.
+ */
+long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
+{
+ struct ttm_global *glob = &ttm_glob;
+ struct ttm_buffer_object *bo;
+ unsigned i;
+ int ret;
+
+ spin_lock(&glob->lru_lock);
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ list_for_each_entry(bo, &glob->swap_lru[i], swap) {
+ uint32_t num_pages = bo->ttm->num_pages;
+
+ ret = ttm_bo_swapout(bo, ctx, gfp_flags);
+ /* ttm_bo_swapout has dropped th
[PATCH 3/3] drm/ttm: switch to per device LRU lock
Instead of having a global lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
drivers/gpu/drm/ttm/ttm_bo.c | 49 --
drivers/gpu/drm/ttm/ttm_device.c | 12 +++
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
include/drm/ttm/ttm_bo_driver.h| 4 +--
include/drm/ttm/ttm_device.h | 4 +--
8 files changed, 43 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9d19078246c8..ae18c0e32347 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
*adev,
struct amdgpu_vm_bo_base *bo_base;
if (vm->bulk_moveable) {
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&adev->mman.bdev.lru_lock);
ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&adev->mman.bdev.lru_lock);
return;
}
memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&adev->mman.bdev.lru_lock);
list_for_each_entry(bo_base, &vm->idle, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
@@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
&bo->shadow->tbo.mem,
&vm->lru_bulk_move);
}
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&adev->mman.bdev.lru_lock);
vm->bulk_moveable = true;
}
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 6ed673d75f9f..29ad72cb6b54 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -417,16 +417,13 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
release->id | 0xf000, release->base.seqno);
trace_dma_fence_emit(&release->base);
- spin_lock(&ttm_glob.lru_lock);
-
list_for_each_entry(entry, &release->bos, head) {
bo = entry->bo;
dma_resv_add_shared_fence(bo->base.resv, &release->base);
- ttm_bo_move_to_lru_tail(bo, &bo->mem, NULL);
+ ttm_bo_move_to_lru_tail_unlocked(bo);
dma_resv_unlock(bo->base.resv);
}
- spin_unlock(&ttm_glob.lru_lock);
ww_acquire_fini(&release->ticket);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a1be88be357b..a8103c8718a3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -242,9 +242,9 @@ static int ttm_bo_individualize_resv(struct
ttm_buffer_object *bo)
* reference it any more. The only tricky case is the trylock on
* the resv object while holding the lru_lock.
*/
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&bo->bdev->lru_lock);
bo->base.resv = &bo->base._resv;
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
}
return r;
@@ -303,7 +303,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
if (unlock_resv)
dma_resv_unlock(bo->base.resv);
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,
30 * HZ);
@@ -313,7 +313,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
else if (lret == 0)
return -EBUSY;
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&bo->bdev->lru_lock);
if (unlock_resv && !dma_resv_trylock(bo->base.resv)) {
/*
* We raced, and lost, someone else holds the
reservation now,
@@ -323,7 +323,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
* delayed destruction would succeed, so just return
success
* here.
*/
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
return 0;
}
ret = 0;
@@ -332,13 +332,13 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo,
if (ret || unlikely(list_empty(&bo->ddestroy))) {
if (unlock_resv)
dma_resv_unlock(bo->base.resv);
- spin_unlock(&ttm_glob.lru_lock);
[PATCH 2/3] drm/ttm: remove swap LRU v2
Instead evict round robin from each devices SYSTEM and TT domain.
v2: reorder num_pages access reported by Dan's script
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 31 ++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_device.c| 60 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 1 -
include/drm/ttm/ttm_bo_driver.h | 1 -
include/drm/ttm/ttm_device.h| 7 +---
7 files changed, 52 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d33578a112b4..a1be88be357b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -73,7 +73,6 @@ static void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
{
struct ttm_device *bdev = bo->bdev;
- list_del_init(&bo->swap);
list_del_init(&bo->lru);
if (bdev->funcs->del_from_lru_notify)
@@ -104,14 +103,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
man = ttm_manager_type(bdev, mem->mem_type);
list_move_tail(&bo->lru, &man->lru[bo->priority]);
- if (man->use_tt && bo->ttm &&
- !(bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
-TTM_PAGE_FLAG_SWAPPED))) {
- struct list_head *swap;
-
- swap = &ttm_glob.swap_lru[bo->priority];
- list_move_tail(&bo->swap, swap);
- }
if (bdev->funcs->del_from_lru_notify)
bdev->funcs->del_from_lru_notify(bo);
@@ -126,9 +117,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
ttm_bo_bulk_move_set_pos(&bulk->vram[bo->priority], bo);
break;
}
- if (bo->ttm && !(bo->ttm->page_flags &
-(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED)))
- ttm_bo_bulk_move_set_pos(&bulk->swap[bo->priority], bo);
}
}
EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
@@ -166,20 +154,6 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
list_bulk_move_tail(&man->lru[i], &pos->first->lru,
&pos->last->lru);
}
-
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- struct ttm_lru_bulk_move_pos *pos = &bulk->swap[i];
- struct list_head *lru;
-
- if (!pos->first)
- continue;
-
- dma_resv_assert_held(pos->first->base.resv);
- dma_resv_assert_held(pos->last->base.resv);
-
- lru = &ttm_glob.swap_lru[i];
- list_bulk_move_tail(lru, &pos->first->swap, &pos->last->swap);
- }
}
EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
@@ -1056,7 +1030,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
kref_init(&bo->kref);
INIT_LIST_HEAD(&bo->lru);
INIT_LIST_HEAD(&bo->ddestroy);
- INIT_LIST_HEAD(&bo->swap);
bo->bdev = bdev;
bo->type = type;
bo->mem.mem_type = TTM_PL_SYSTEM;
@@ -1191,6 +1164,10 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
bool locked;
int ret;
+ if (!bo->ttm || bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
+ TTM_PAGE_FLAG_SWAPPED))
+ return false;
+
if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, NULL))
return -EBUSY;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e5819fec4..a2a17c84ceb3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -303,7 +303,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
atomic_inc(&ttm_glob.bo_count);
INIT_LIST_HEAD(&fbo->base.ddestroy);
INIT_LIST_HEAD(&fbo->base.lru);
- INIT_LIST_HEAD(&fbo->base.swap);
fbo->base.moving = NULL;
drm_vma_node_reset(&fbo->base.base.vma_node);
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index dfc2a7e4e490..2c280fb1e992 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -67,7 +67,6 @@ static int ttm_global_init(void)
unsigned long num_pages;
struct sysinfo si;
int ret = 0;
- unsigned i;
mutex_lock(&ttm_global_mutex);
if (++ttm_glob_use_count > 1)
@@ -90,8 +89,6 @@ static int ttm_global_init(void)
goto out;
}
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
- INIT_LIST_HEAD(&glob->swap_lru[i]);
INIT_LIST_HEAD(&glob->device_list);
atomic_set(&glob->bo_count, 0);
@@ -109,27 +106,60 @@ static int ttm_global_init(void)
long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
{
struct ttm_global *glob = &ttm_glob;
+ struct t
Re: Not 100% sure if I correctly fixed drm-tip
(cc'ing Jani) Am 11.02.21 um 11:01 schrieb Christian König: Hi guys, I had a conflict this morning in the ttm pool while pushing an important fix to drm-misc-fixes. I'm not 100% sure if I correctly fixed up drm-tip. How can this be double checked? And how can it be fixed if the merge has gone bad? Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Support second Image Signal Processor on rk3399
Hi Sebastian, Am Donnerstag, 11. Februar 2021, 06:25:15 CET schrieb Sebastian Fricke: > Hey Heiko, > > On 10.02.2021 12:15, Heiko Stübner wrote: > >Hi Sebastian, > > > >Am Freitag, 5. Februar 2021, 15:55:56 CET schrieb Heiko Stübner: > >> Hi Sebastian, > >> > >> I did some tests myself today as well and can confirm your > >> hdmi related finding - at least when plugged in on boot. > >> > >> I tried some combinations of camera vs. hdmi and it seems > >> really only when hdmi is plugged in on boot > > > >as you can see in v2, it should work now even with hdmi > >connected on boot. My patch ignored the grf-clock when > >doing the grf-based init. > > > >All clocks are on during boot and I guess the hdmi-driver > >did disable it after its probe. The phy_power_on functions > >did handle it correctly already, so it was only happening > >with hdmi connected on boot. > > Thank you very much for solving that problem, I've tested the scenarios > described below and it works like a charm. (With your V2) > > > > > >Btw. do you plan on submitting your ov13850 driver > >soonish? > > Actually, I have posted the patch already see here: > https://patchwork.kernel.org/project/linux-media/patch/20210130182313.32903-2-sebastian.fri...@posteo.net/ very cool to see > I currently review the requested changes and questions and will soon > post a second version, but I expect quite some time until it is actually > merged. could you Cc me on future versions? Thanks Heiko > > Greetings, > Sebastian > > > > > > >> > >> (1) > >> - boot > >> - camera > >> --> works > >> > >> (2) > >> - boot > >> - camera > >> - hdmi plugged in > >> - hdmi works > >> - camera > >> --> works > >> > >> (3) > >> - hdmi plugged in > >> - boot > >> - hdmi works > >> - camera > >> --> camera doesn't work > >> > >> (4) > >> - boot > >> - hdmi plugged in > >> - hdmi works > >> - camera > >> -> camera works > >> > >> > >> With a bit of brute-force [0] it seems the camera also works again even > >> with hdmi connected on boot. So conclusion would be that some clock > >> is misbehaving. > >> > >> Now we'll "only" need to find out which one that is. > >> > >> > >> Heiko > >> > >> > >> [0] > >> Don't disable any clock gates > >> > >> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c > >> index 070dc47e95a1..8daf1fc3388c 100644 > >> --- a/drivers/clk/clk-gate.c > >> +++ b/drivers/clk/clk-gate.c > >> @@ -61,6 +61,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int > >> enable) > >> > >> set ^= enable; > >> > >> +if (!enable) > >> +return; > >> + > >> if (gate->lock) > >> spin_lock_irqsave(gate->lock, flags); > >> else > >> > >> > >> > >> Am Freitag, 5. Februar 2021, 09:15:47 CET schrieb Heiko Stübner: > >> > Hi Sebastian, > >> > > >> > Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke: > >> > > On 03.02.2021 20:54, Heiko Stübner wrote: > >> > > >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke: > >> > > >> I have tested your patch set on my nanoPC-T4, here is a complete log > >> > > >> with: > >> > > >> - relevant kernel log entries > >> > > >> - system information > >> > > >> - media ctl output > >> > > >> - sysfs entry information > >> > > >> > >> > > >> https://paste.debian.net/1183874/ > >> > > >> > >> > > >> Additionally, to your patchset I have applied the following patches: > >> > > >> https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup > >> > > >> > >> > > >> And just to not cause confusion the `media_dev` entries come from > >> > > >> this > >> > > >> unmerged series: > >> > > >> https://patchwork.kernel.org/project/linux-media/list/?series=426269 > >> > > >> > >> > > >> I have actually been able to stream with both of my cameras at the > >> > > >> same > >> > > >> time using the libcamera cam command. > >> > > >> I would like to thank you a lot for making this possible. > >> > > > > >> > > >Thanks for testing a dual camera setup. On my board I could only test > >> > > >the second ISP. And really glad it works for you tool :-) . > >> > > > > >> > > >Out of curiosity, do you also see that green tint in the images the > >> > > >cameras > >> > > >produce? > >> > > > >> > > Yes, I do. Actually, I currently have two forms of a green tint, on my > >> > > OV13850 everything is quite dark and greenish, which is caused by the > >> > > missing 3A algorithms. On my OV4689, I have big patches of the image > >> > > with bright green color and flickering, I investigated if this is > >> > > connected to the 2nd ISP instance, but that doesn't seem to be the case > >> > > as I have the same results when I switch the CSI ports of the cameras. > >> > > > >> > > I have found another issue, while testing I discovered following > >> > > issue: > >> > > When I start the system with an HDMI monitor connected, then the camera > >> > > on the 2nd port doesn't work. This is probably because the RX/TX is > >> > > reserved as a TX. > >> > > But it made m
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #40 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Jan Kokemüller from comment #39) > Created attachment 295225 [details] > Call DC_FP_START() / DC_FP_END() in dcn21_validate_bandwidth > > Could it be that DC_FP_START()/DC_FP_END() aka > kernel_fpu_begin()/kernel_fpu_end() are not called in the > *_validate_bandwidth code path on AMD Renoir systems? To my untrained eye it > looks like it is missing, while it _is_ there for dcn20. > > I've been running the attached patch for 2 days now with some KVM VMs open > and the system seems stable. Previously, I had similar crashes/backtraces > @krakopo described. > > I'm happy to help testing any patches. I'm running a Thinkpad T14 with a AMD > Ryzen 7 PRO 4750U (Renoir). Looks correct. Care to send out a proper git patch? -- You may reply to this email to add a comment. 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
[PATCH v3 1/9] drm/dp: add MSO related DPCD registers
Add DPCD register definitions for eDP 1.4 Multi-SST Operation. Cc: Nischal Varide Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index edffd1dcca3e..632ad7faa006 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1016,6 +1016,11 @@ struct drm_device; #define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ #define DP_EDP_REGIONAL_BACKLIGHT_00x741/* eDP 1.4 */ +#define DP_EDP_MSO_LINK_CAPABILITIES0x7a4/* eDP 1.4 */ +# define DP_EDP_MSO_NUMBER_OF_LINKS_MASK(7 << 0) +# define DP_EDP_MSO_NUMBER_OF_LINKS_SHIFT 0 +# define DP_EDP_MSO_INDEPENDENT_LINK_BIT(1 << 3) + /* Sideband MSG Buffers */ #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/vram-helper: cleanup drm_gem_vram_bo_driver_move_notify
Hi
Am 11.02.21 um 14:16 schrieb Christian König:
Swapping bo->mem was completely unecessary. Cleanup the function which
is just a leftover from a TTM cleanup.
Yes this was introduced in a recent cleanup effort. Can you explain what
the code intends to do? It seems as if it tries to "re-unmap the BO" if
the move_memcpy fails.
If the move_memcpy fails now, it seems like we can live without
reverting that call to drm_gem_vram_bo_driver_move_notify(). (?)
Best regards
Thomas
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index a0992f0b8afd..0c2233ee6029 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -564,9 +564,7 @@ static void drm_gem_vram_bo_driver_evict_flags(struct
drm_gem_vram_object *gbo,
*pl = gbo->placement;
}
-static void drm_gem_vram_bo_driver_move_notify(struct drm_gem_vram_object *gbo,
- bool evict,
- struct ttm_resource *new_mem)
+static void drm_gem_vram_bo_driver_move_notify(struct drm_gem_vram_object *gbo)
{
struct ttm_buffer_object *bo = &gbo->bo;
struct drm_device *dev = bo->base.dev;
@@ -582,16 +580,8 @@ static int drm_gem_vram_bo_driver_move(struct
drm_gem_vram_object *gbo,
struct ttm_operation_ctx *ctx,
struct ttm_resource *new_mem)
{
- int ret;
-
- drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
- ret = ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
- if (ret) {
- swap(*new_mem, gbo->bo.mem);
- drm_gem_vram_bo_driver_move_notify(gbo, false, new_mem);
- swap(*new_mem, gbo->bo.mem);
- }
- return ret;
+ drm_gem_vram_bo_driver_move_notify(gbo);
+ return ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
}
/*
@@ -947,7 +937,7 @@ static void bo_driver_delete_mem_notify(struct
ttm_buffer_object *bo)
gbo = drm_gem_vram_of_bo(bo);
- drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
+ drm_gem_vram_bo_driver_move_notify(gbo);
}
static int bo_driver_move(struct ttm_buffer_object *bo,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/qxl: clean up qxl_bo_move_notify
Hi
Am 11.02.21 um 14:16 schrieb Christian König:
Remove the unused evict parameter and drop swapping bo->mem.
Could you provide the same patch for vram-helpers as well?
Best regards
Thomas
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index b7f77eb685cb..47afe95d04a1 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -121,7 +121,6 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
ttm_buffer_object *bo,
}
static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
- bool evict,
struct ttm_resource *new_mem)
{
struct qxl_bo *qbo;
@@ -144,29 +143,22 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool
evict,
struct ttm_resource *old_mem = &bo->mem;
int ret;
- qxl_bo_move_notify(bo, evict, new_mem);
+ qxl_bo_move_notify(bo, new_mem);
ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
- goto out;
+ return ret;
if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
ttm_bo_move_null(bo, new_mem);
return 0;
}
- ret = ttm_bo_move_memcpy(bo, ctx, new_mem);
-out:
- if (ret) {
- swap(*new_mem, bo->mem);
- qxl_bo_move_notify(bo, false, new_mem);
- swap(*new_mem, bo->mem);
- }
- return ret;
+ return ttm_bo_move_memcpy(bo, ctx, new_mem);
}
static void qxl_bo_delete_mem_notify(struct ttm_buffer_object *bo)
{
- qxl_bo_move_notify(bo, false, NULL);
+ qxl_bo_move_notify(bo, NULL);
}
static struct ttm_device_funcs qxl_bo_driver = {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] PCI: Also set up legacy files only after sysfs init
On Wed, Feb 10, 2021 at 10:40 PM Bjorn Helgaas wrote:
>
> On Fri, Feb 05, 2021 at 02:36:32PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > no problem, but in the next patch I want to wire up iomem revoke
> > support. That needs the vfs up and running already to make sure that
> > iomem_get_mapping() works.
> >
> > Wire it up exactly like the existing code in
> > pci_create_sysfs_dev_files(). Note that pci_remove_legacy_files()
> > doesn't need a check since the one for pci_bus->legacy_io is
> > sufficient.
> >
> > An alternative solution would be to implement a callback in sysfs to
> > set up the address space from iomem_get_mapping() when userspace calls
> > mmap(). This also works, but Greg didn't really like that just to work
> > around an ordering issue when the kernel loads initially.
> >
> > v2: Improve commit message (Bjorn)
> >
> > Signed-off-by: Daniel Vetter
>
> Acked-by: Bjorn Helgaas
>
> I wish we weren't extending a known-racy mechanism to do this, but at
> least we're not *adding* a brand new race.
Yeah it's not great. Thanks for looking at both again, I'll fix up the
typos on the 2nd one and merge them both.
Cheers, Daniel
>
> > Cc: Stephen Rothwell
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: Greg Kroah-Hartman
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/pci/pci-sysfs.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index fb072f4b3176..0c45b4f7b214 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> > {
> > int error;
> >
> > + if (!sysfs_initialized)
> > + return;
> > +
> > b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> > GFP_ATOMIC);
> > if (!b->legacy_io)
> > @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
> > static int __init pci_sysfs_init(void)
> > {
> > struct pci_dev *pdev = NULL;
> > + struct pci_bus *pbus = NULL;
> > int retval;
> >
> > sysfs_initialized = 1;
> > @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> > }
> > }
> >
> > + while ((pbus = pci_find_next_bus(pbus)))
> > + pci_create_legacy_files(pbus);
> > +
> > return 0;
> > }
> > late_initcall(pci_sysfs_init);
> > --
> > 2.30.0
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 4/4] drm/vmwgfx: clean up vmw_move_notify
On Thu, Feb 11, 2021 at 8:17 AM Christian König
wrote:
>
> Instead of swapping bo->mem just give old and new as parameters.
>
> Also drop unused parameters and code.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 3 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 9 +---
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 26 +++---
> 3 files changed, 16 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index e65b00f8336d..21a72fa7b9fd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -775,7 +775,8 @@ extern void vmw_resource_unreserve(struct vmw_resource
> *res,
>struct vmw_buffer_object *new_backup,
>unsigned long new_backup_offset);
> extern void vmw_query_move_notify(struct ttm_buffer_object *bo,
> - struct ttm_resource *mem);
> + struct ttm_resource *old_mem,
> + struct ttm_resource *new_mem);
> extern int vmw_query_readback_all(struct vmw_buffer_object *dx_query_mob);
> extern void vmw_resource_evict_all(struct vmw_private *dev_priv);
> extern void vmw_resource_unbind_list(struct vmw_buffer_object *vbo);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index c3a724e37104..35f02958ee2c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -847,13 +847,15 @@ int vmw_query_readback_all(struct vmw_buffer_object
> *dx_query_mob)
> * vmw_query_move_notify - Read back cached query states
> *
> * @bo: The TTM buffer object about to move.
> - * @mem: The memory region @bo is moving to.
> + * @old_mem: The memory region @bo is moving from.
> + * @new_mem: The memory region @bo is moving to.
> *
> * Called before the query MOB is swapped out to read back cached query
> * states from the device.
> */
> void vmw_query_move_notify(struct ttm_buffer_object *bo,
> - struct ttm_resource *mem)
> + struct ttm_resource *old_mem,
> + struct ttm_resource *new_mem)
> {
> struct vmw_buffer_object *dx_query_mob;
> struct ttm_device *bdev = bo->bdev;
> @@ -871,7 +873,8 @@ void vmw_query_move_notify(struct ttm_buffer_object *bo,
> }
>
> /* If BO is being moved from MOB to system memory */
> - if (mem->mem_type == TTM_PL_SYSTEM && bo->mem.mem_type == VMW_PL_MOB)
> {
> + if (new_mem->mem_type == TTM_PL_SYSTEM &&
> + old_mem->mem_type == VMW_PL_MOB) {
> struct vmw_fence_obj *fence;
>
> (void) vmw_query_readback_all(dx_query_mob);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 63f10c865061..38801462134e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -692,20 +692,19 @@ static int vmw_ttm_io_mem_reserve(struct ttm_device
> *bdev, struct ttm_resource *
> *
> * @bo: The TTM buffer object about to move.
> * @evict: Unused
Evict is removed now. Can be dropped from the documentation.
Alex
> - * @mem: The struct ttm_resource indicating to what memory
> + * @old_mem: The old memory where we move from
> + * @new_mem: The struct ttm_resource indicating to what memory
> * region the move is taking place.
> *
> * Calls move_notify for all subsystems needing it.
> * (currently only resources).
> */
> static void vmw_move_notify(struct ttm_buffer_object *bo,
> - bool evict,
> - struct ttm_resource *mem)
> + struct ttm_resource *old_mem,
> + struct ttm_resource *new_mem)
> {
> - if (!mem)
> - return;
> - vmw_bo_move_notify(bo, mem);
> - vmw_query_move_notify(bo, mem);
> + vmw_bo_move_notify(bo, new_mem);
> + vmw_query_move_notify(bo, old_mem, new_mem);
> }
>
>
> @@ -736,7 +735,7 @@ static int vmw_move(struct ttm_buffer_object *bo,
> return ret;
> }
>
> - vmw_move_notify(bo, evict, new_mem);
> + vmw_move_notify(bo, &bo->mem, new_mem);
>
> if (old_man->use_tt && new_man->use_tt) {
> if (bo->mem.mem_type == TTM_PL_SYSTEM) {
> @@ -758,18 +757,10 @@ static int vmw_move(struct ttm_buffer_object *bo,
> }
> return 0;
> fail:
> - swap(*new_mem, bo->mem);
> - vmw_move_notify(bo, false, new_mem);
> - swap(*new_mem, bo->mem);
> + vmw_move_notify(bo, new_mem, &bo->mem);
> return ret;
> }
>
> -static void
> -vmw_delete_mem_notify(struct ttm_buffer_object *bo)
> -{
> - vmw_move_notify(bo, fal
Re: Not 100% sure if I correctly fixed drm-tip
On Thu, 11 Feb 2021, Christian König wrote:
> Hi guys,
>
> I had a conflict this morning in the ttm pool while pushing an important
> fix to drm-misc-fixes.
>
> I'm not 100% sure if I correctly fixed up drm-tip. How can this be
> double checked? And how can it be fixed if the merge has gone bad?
I'm afraid there's a problem; bb52cb0dec8d ("drm/ttm: make the pool
shrinker lock a mutex") in upstream and drm-misc-fixes creates a silent
conflict with ba051901d10f ("drm/ttm: add a debugfs file for the global
page pools") in drm-misc-next, causing the latter to use
spin_lock/unlock on a mutex.
But while you hit a conflict, it does look like the conflict breaking
the build is silent, AFAICT the spinlock part does not conflict. So a
fixup patch in drm-rerere is probably needed until there are some
backmerges.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/vram-helper: cleanup drm_gem_vram_bo_driver_move_notify
Am 11.02.21 um 15:52 schrieb Thomas Zimmermann:
Hi
Am 11.02.21 um 14:16 schrieb Christian König:
Swapping bo->mem was completely unecessary. Cleanup the function which
is just a leftover from a TTM cleanup.
Yes this was introduced in a recent cleanup effort. Can you explain
what the code intends to do? It seems as if it tries to "re-unmap the
BO" if the move_memcpy fails.
If the move_memcpy fails now, it seems like we can live without
reverting that call to drm_gem_vram_bo_driver_move_notify(). (?)
I think so, but I'm not 100% sure either.
The swap() -> notify -> swap() was just how TTM did it and that was
moved into the drivers.
I'm now just trying to remove all the hard write accesses to bo->mem
from drivers and stumbled over this here.
Thanks for the comments,
Christian.
Best regards
Thomas
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index a0992f0b8afd..0c2233ee6029 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -564,9 +564,7 @@ static void
drm_gem_vram_bo_driver_evict_flags(struct drm_gem_vram_object *gbo,
*pl = gbo->placement;
}
-static void drm_gem_vram_bo_driver_move_notify(struct
drm_gem_vram_object *gbo,
- bool evict,
- struct ttm_resource *new_mem)
+static void drm_gem_vram_bo_driver_move_notify(struct
drm_gem_vram_object *gbo)
{
struct ttm_buffer_object *bo = &gbo->bo;
struct drm_device *dev = bo->base.dev;
@@ -582,16 +580,8 @@ static int drm_gem_vram_bo_driver_move(struct
drm_gem_vram_object *gbo,
struct ttm_operation_ctx *ctx,
struct ttm_resource *new_mem)
{
- int ret;
-
- drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
- ret = ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
- if (ret) {
- swap(*new_mem, gbo->bo.mem);
- drm_gem_vram_bo_driver_move_notify(gbo, false, new_mem);
- swap(*new_mem, gbo->bo.mem);
- }
- return ret;
+ drm_gem_vram_bo_driver_move_notify(gbo);
+ return ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
}
/*
@@ -947,7 +937,7 @@ static void bo_driver_delete_mem_notify(struct
ttm_buffer_object *bo)
gbo = drm_gem_vram_of_bo(bo);
- drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
+ drm_gem_vram_bo_driver_move_notify(gbo);
}
static int bo_driver_move(struct ttm_buffer_object *bo,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/vram-helper: cleanup drm_gem_vram_bo_driver_move_notify
Hi
Am 11.02.21 um 16:05 schrieb Christian König:
Am 11.02.21 um 15:52 schrieb Thomas Zimmermann:
Hi
Am 11.02.21 um 14:16 schrieb Christian König:
Swapping bo->mem was completely unecessary. Cleanup the function which
is just a leftover from a TTM cleanup.
Yes this was introduced in a recent cleanup effort. Can you explain
what the code intends to do? It seems as if it tries to "re-unmap the
BO" if the move_memcpy fails.
If the move_memcpy fails now, it seems like we can live without
reverting that call to drm_gem_vram_bo_driver_move_notify(). (?)
I think so, but I'm not 100% sure either.
The swap() -> notify -> swap() was just how TTM did it and that was
moved into the drivers.
I'm now just trying to remove all the hard write accesses to bo->mem
from drivers and stumbled over this here.
We already have a vmap count of zero; so unmapping the BO pages is fine
at any time. The next caller of vmap will simple instantiate a new mapping.
Let me give this patch a test run tomorrow, but it seems correct.
Best regards
Thomas
Thanks for the comments,
Christian.
Best regards
Thomas
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index a0992f0b8afd..0c2233ee6029 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -564,9 +564,7 @@ static void
drm_gem_vram_bo_driver_evict_flags(struct drm_gem_vram_object *gbo,
*pl = gbo->placement;
}
-static void drm_gem_vram_bo_driver_move_notify(struct
drm_gem_vram_object *gbo,
- bool evict,
- struct ttm_resource *new_mem)
+static void drm_gem_vram_bo_driver_move_notify(struct
drm_gem_vram_object *gbo)
{
struct ttm_buffer_object *bo = &gbo->bo;
struct drm_device *dev = bo->base.dev;
@@ -582,16 +580,8 @@ static int drm_gem_vram_bo_driver_move(struct
drm_gem_vram_object *gbo,
struct ttm_operation_ctx *ctx,
struct ttm_resource *new_mem)
{
- int ret;
-
- drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
- ret = ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
- if (ret) {
- swap(*new_mem, gbo->bo.mem);
- drm_gem_vram_bo_driver_move_notify(gbo, false, new_mem);
- swap(*new_mem, gbo->bo.mem);
- }
- return ret;
+ drm_gem_vram_bo_driver_move_notify(gbo);
+ return ttm_bo_move_memcpy(&gbo->bo, ctx, new_mem);
}
/*
@@ -947,7 +937,7 @@ static void bo_driver_delete_mem_notify(struct
ttm_buffer_object *bo)
gbo = drm_gem_vram_of_bo(bo);
- drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
+ drm_gem_vram_bo_driver_move_notify(gbo);
}
static int bo_driver_move(struct ttm_buffer_object *bo,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Not 100% sure if I correctly fixed drm-tip
Am 11.02.21 um 16:02 schrieb Jani Nikula:
On Thu, 11 Feb 2021, Christian König wrote:
Hi guys,
I had a conflict this morning in the ttm pool while pushing an important
fix to drm-misc-fixes.
I'm not 100% sure if I correctly fixed up drm-tip. How can this be
double checked? And how can it be fixed if the merge has gone bad?
I'm afraid there's a problem; bb52cb0dec8d ("drm/ttm: make the pool
shrinker lock a mutex") in upstream and drm-misc-fixes creates a silent
conflict with ba051901d10f ("drm/ttm: add a debugfs file for the global
page pools") in drm-misc-next, causing the latter to use
spin_lock/unlock on a mutex.
But while you hit a conflict, it does look like the conflict breaking
the build is silent, AFAICT the spinlock part does not conflict. So a
fixup patch in drm-rerere is probably needed until there are some
backmerges.
Well exactly that's the issue. I've already had a fixup in drm-rerere
for this.
But today I've pushed another fix to drm-misc-fixes which also conflicts
with ba051901d10f ("drm/ttm: add a debugfs file for the global page pools").
I've fixed this up as well and committed the solution. But dim then
complained that the original fixup is now not applicable any more (which
is true as far as I know).
This somehow went away when I said that dim should assume patch
reversal, but I'm not sure if that's the right thing to do.
Thanks,
Christian.
BR,
Jani.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [v2] drm/msm/disp/dpu1: turn off vblank irqs aggressively in dpu driver
On 2021-02-11 01:56, Rob Clark wrote: On Wed, Feb 10, 2021 at 3:41 AM wrote: On 2021-02-01 00:46, Rob Clark wrote: > On Fri, Dec 18, 2020 at 2:27 AM Kalyan Thota > wrote: >> >> Set the flag vblank_disable_immediate = true to turn off vblank irqs >> immediately as soon as drm_vblank_put is requested so that there are >> no irqs triggered during idle state. This will reduce cpu wakeups >> and help in power saving. >> >> To enable vblank_disable_immediate flag the underlying KMS driver >> needs to support high precision vblank timestamping and also a >> reliable way of providing vblank counter which is incrementing >> at the leading edge of vblank. >> >> This patch also brings in changes to support vblank_disable_immediate >> requirement in dpu driver. >> >> Changes in v1: >> - Specify reason to add vblank timestamp support. (Rob) >> - Add changes to provide vblank counter from dpu driver. >> >> Signed-off-by: Kalyan Thota > > This seems to be triggering: > > [ +0.032668] [ cut here ] > [ +0.004759] msm ae0.mdss: drm_WARN_ON_ONCE(cur_vblank != > vblank->last) > [ +0.24] WARNING: CPU: 0 PID: 362 at > drivers/gpu/drm/drm_vblank.c:354 drm_update_vblank_count+0x1e4/0x258 > [ +0.017154] Modules linked in: joydev > [ +0.003784] CPU: 0 PID: 362 Comm: frecon Not tainted > 5.11.0-rc5-00037-g33d3504871dd #2 > [ +0.008135] Hardware name: Google Lazor (rev1 - 2) with LTE (DT) > [ +0.006167] pstate: 60400089 (nZCv daIf +PAN -UAO -TCO BTYPE=--) > [ +0.006169] pc : drm_update_vblank_count+0x1e4/0x258 > [ +0.005105] lr : drm_update_vblank_count+0x1e4/0x258 > [ +0.005106] sp : ffc010003b70 > [ +0.003409] x29: ffc010003b70 x28: ff80855d9d98 > [ +0.005466] x27: x26: 00fe502a > [ +0.005458] x25: 0001 x24: 0001 > [ +0.005466] x23: 0001 x22: ff808561ce80 > [ +0.005465] x21: x20: > [ +0.005468] x19: ff80850d6800 x18: > [ +0.005466] x17: x16: > [ +0.005465] x15: 000a x14: 263b > [ +0.005466] x13: 0006 x12: > [ +0.005465] x11: 0010 x10: ffc090003797 > [ +0.005466] x9 : ffed200e2a8c x8 : > [ +0.005466] x7 : x6 : ffed213b2b51 > [ +0.005465] x5 : c000dfff x4 : ffed21218048 > [ +0.005465] x3 : x2 : > [ +0.005465] x1 : x0 : > [ +0.005466] Call trace: > [ +0.002520] drm_update_vblank_count+0x1e4/0x258 > [ +0.004748] drm_handle_vblank+0xd0/0x35c > [ +0.004130] drm_crtc_handle_vblank+0x24/0x30 > [ +0.004487] dpu_crtc_vblank_callback+0x3c/0xc4 > [ +0.004662] dpu_encoder_vblank_callback+0x70/0xc4 > [ +0.004931] dpu_encoder_phys_vid_vblank_irq+0x50/0x12c > [ +0.005378] dpu_core_irq_callback_handler+0xf4/0xfc > [ +0.005107] dpu_hw_intr_dispatch_irq+0x100/0x120 > [ +0.004834] dpu_core_irq+0x44/0x5c > [ +0.003597] dpu_irq+0x1c/0x28 > [ +0.003141] msm_irq+0x34/0x40 > [ +0.003153] __handle_irq_event_percpu+0xfc/0x254 > [ +0.004838] handle_irq_event_percpu+0x3c/0x94 > [ +0.004574] handle_irq_event+0x54/0x98 > [ +0.003944] handle_level_irq+0xa0/0xd0 > [ +0.003943] generic_handle_irq+0x30/0x48 > [ +0.004131] dpu_mdss_irq+0xe4/0x118 > [ +0.003684] generic_handle_irq+0x30/0x48 > [ +0.004127] __handle_domain_irq+0xa8/0xac > [ +0.004215] gic_handle_irq+0xdc/0x150 > [ +0.003856] el1_irq+0xb4/0x180 > [ +0.003237] dpu_encoder_vsync_time+0x78/0x230 > [ +0.004574] dpu_encoder_kickoff+0x190/0x354 > [ +0.004386] dpu_crtc_commit_kickoff+0x194/0x1a0 > [ +0.004748] dpu_kms_flush_commit+0xf4/0x108 > [ +0.004390] msm_atomic_commit_tail+0x2e8/0x384 > [ +0.004661] commit_tail+0x80/0x108 > [ +0.003588] drm_atomic_helper_commit+0x118/0x11c > [ +0.004834] drm_atomic_commit+0x58/0x68 > [ +0.004033] drm_atomic_helper_set_config+0x70/0x9c > [ +0.005018] drm_mode_setcrtc+0x390/0x584 > [ +0.004131] drm_ioctl_kernel+0xc8/0x11c > [ +0.004035] drm_ioctl+0x2f8/0x34c > [ +0.003500] drm_compat_ioctl+0x48/0xe8 > [ +0.003945] __arm64_compat_sys_ioctl+0xe8/0x104 > [ +0.004750] el0_svc_common.constprop.0+0x114/0x188 > [ +0.005019] do_el0_svc_compat+0x28/0x38 > [ +0.004031] el0_svc_compat+0x20/0x30 > [ +0.003772] el0_sync_compat_handler+0x104/0x18c > [ +0.004749] el0_sync_compat+0x178/0x180 > [ +0.004034] ---[ end trace 2959d178e74f2555 ]--- > > > BR, > -R > Hi Rob, on DPU HW, with prefetch enabled, the frame count increment and vsync irq are not happening at same instance. This is causing the frame count to mismatch. Example: |###--^--|###--^--| for the above vsync cycle with prefetch enabled "^" --> marks a fetch counter where in we are asking the hw to start fetching in the front porch so that we will have more time to fetch data by first active line of next f
Re: [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote: > > On 2/9/2021 2:54 AM, Daniel Vetter wrote: > > On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote: > >> This patch adds tracking of which cgroup to make charges against for a > >> given GEM object. We associate the current task's cgroup with GEM objects > >> as they are created. First user of this is for charging DRM cgroup for > >> device memory allocations. The intended behavior is for device drivers to > >> make the cgroup charging calls at the time that backing store is allocated > >> or deallocated for the object. > >> > >> Exported functions are provided for charging memory allocations for a > >> GEM object to DRM cgroup. To aid in debugging, we store how many bytes > >> have been charged inside the GEM object. Add helpers for setting and > >> clearing the object's associated cgroup which will check that charges are > >> not being leaked. > >> > >> For shared objects, this may make the charge against a cgroup that is > >> potentially not the same cgroup as the process using the memory. Based > >> on the memory cgroup's discussion of "memory ownership", this seems > >> acceptable [1]. > >> > >> [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory > >> Ownership" > >> > >> Signed-off-by: Brian Welty > > > > Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that > > counts everything, why don't we also charge in these gem functions? > > I'm not sure what you mean exactly. You want to merge/move the charging logic > proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into > drm_gem_object_charge_mem() ? > > Or reading below, I think you are okay keeping the logic separated as is, but > you want much of the code in kernel/cgroup/drm.c moved to drivers/gpu/cgroup ? > Yes, I see that should allow to reduce number of exported functions. Both. I mean we'd need to look at the code again when it's shuffled, but I'd say: - cgroup code and the charging for general gpu memory moves to drivers/gpu/cgroup, so dma-buf heaps can use it too. - the charging for gem buffers moves into core gem code, so it happens for all gpu drivers and all gem buffer allocations. - this might or might not mean a bunch less exported stuff from the cgroups files (since you don't need separate steps for linking a gem object to a cgroup from the actual charging), and probably no exports anymore for drivers (since they charge nothing). That will change when we add charging for specific memory pools I guess, but we add that when we add tha functionality. > > Also, that would remove the need for all these functions exported to > > drivers. Plus the cgroups setup could also move fully into drm core code, > > since all drivers (*) support it > > That way this would really be a fully > > generic cgroups controller, and we could land it. > > > Patch #2 proposed to have a few setup functions called during drm device > registration. > You are suggesting to have this more tightly integrated? Yeah essentially if DRIVER_GEM is set drm core would simply set this all up. Since with this we'd always account all gem buffers in cgroups, and it would make basic cgroup support a non-optional part of drm drivers. > Okay, can see what that looks like. It's true most of the exported functions > from > kernel/cgroup/drm.c were taking a struct drm_device pointer, so seems it can > be > restructured as you suggest. But I guess we will always need some logic in > kernel/cgroup/drm.c to encapsulate the allocation of the 'struct > cgroup_subsys_state' > for this new controller. > But I'm not sure I see how this makes the controller 'fully generic' as you > describe. All DRIVER_GEM would automatacially support it. And yes there'll still be some encapsulation ofc. > > The other things I'd do: > > - drop gpu scheduling controller from the initial patch series. Yes we'll > > need it, but we also need vram limits and all these things for full > > featured controller. Having the minimal viable cgroup controller in > > upstream would unblock all these other things, and we could discuss them > > in separate patch series, instead of one big bikeshed that never reaches > > full consensus. > > > > - the xpu thing is probably real, I just chatted with Android people for > > their gpu memory accounting needs, and cgroups sounds like a solution > > for them too. But unlike on desktop/server linux, on Android all shared > > buffers are allocated from dma-buf heaps, so outside of drm, and hence a > > cgroup controller that's tightly tied to drm isn't that useful. So I > > think we should move the controller/charge functions up one level into > > drivers/gpu/cgroups. > > Hmm, so for this, you are asking for the cgroup logic to not directly use > DRM data structures? Okay, that's why you suggest drivers/gpu/cgroups and > not drivers/gpu/drm/cgroups. So this is your angle to make it 'fully > gener
Re: [PATCH v3 4/6] drm/sprd: add Unisoc's drm display controller driver
On Thu, Feb 11, 2021 at 04:21:51PM +0800, Kevin Tang wrote: > Daniel Vetter 于2021年2月3日周三 下午10:15写道： > > > On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote: > > > Adds DPU(Display Processor Unit) support for the Unisoc's display > > subsystem. > > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and > > more. > > > > > > Cc: Orson Zhai > > > Cc: Chunyan Zhang > > > Signed-off-by: Kevin Tang > > > > > > v2: > > > - Use drm_xxx to replace all DRM_XXX. > > > - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. > > > > > > v3: > > > - Remove dpu_layer stuff layer and commit layers by aotmic_update > > > > Scrolling through the code looks very tidy&neat, only thing I spotted is > > that you could use the new drmm_ infrastructure we just landed. See > > comments below, with that addressed: > > > > Hi daniel, drmm_helpers seem still on drm-misc, so i need to switch to > drm-misc(not mainline) and then update my patch on drm-misc? Best practice is generally to base your work on top of linux-next, but drm-misc-next for drm drivers is usally a good target too. The code should all land in 5.12, plus new drivers will land for 5.13 only anyway (5.12 is in feature freeze already). -Daniel > > > > > Acked-by: Daniel Vetter > > > --- > > > drivers/gpu/drm/sprd/Kconfig| 1 + > > > drivers/gpu/drm/sprd/Makefile | 4 +- > > > drivers/gpu/drm/sprd/sprd_dpu.c | 985 > > > > > drivers/gpu/drm/sprd/sprd_dpu.h | 120 + > > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > > 6 files changed, insertions(+), 2 deletions(-) > > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > > > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > > > index 6e80cc9..9b4ef9a 100644 > > > --- a/drivers/gpu/drm/sprd/Kconfig > > > +++ b/drivers/gpu/drm/sprd/Kconfig > > > @@ -3,6 +3,7 @@ config DRM_SPRD > > > depends on ARCH_SPRD || COMPILE_TEST > > > depends on DRM && OF > > > select DRM_KMS_HELPER > > > + select VIDEOMODE_HELPERS > > > select DRM_GEM_CMA_HELPER > > > select DRM_KMS_CMA_HELPER > > > select DRM_MIPI_DSI > > > diff --git a/drivers/gpu/drm/sprd/Makefile > > b/drivers/gpu/drm/sprd/Makefile > > > index 86d95d9..6c25bfa 100644 > > > --- a/drivers/gpu/drm/sprd/Makefile > > > +++ b/drivers/gpu/drm/sprd/Makefile > > > @@ -1,5 +1,5 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > -subdir-ccflags-y += -I$(srctree)/$(src) > > > +obj-y := sprd_drm.o \ > > > + sprd_dpu.o > > > > > > -obj-y := sprd_drm.o > > > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c > > b/drivers/gpu/drm/sprd/sprd_dpu.c > > > new file mode 100644 > > > index 000..d562d44 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c > > > @@ -0,0 +1,985 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Copyright (C) 2020 Unisoc Inc. > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include "sprd_drm.h" > > > +#include "sprd_dpu.h" > > > + > > > +/* Global control registers */ > > > +#define REG_DPU_CTRL 0x04 > > > +#define REG_DPU_CFG0 0x08 > > > +#define REG_PANEL_SIZE 0x20 > > > +#define REG_BLEND_SIZE 0x24 > > > +#define REG_BG_COLOR 0x2C > > > + > > > +/* Layer0 control registers */ > > > +#define REG_LAY_BASE_ADDR0 0x30 > > > +#define REG_LAY_BASE_ADDR1 0x34 > > > +#define REG_LAY_BASE_ADDR2 0x38 > > > +#define REG_LAY_CTRL 0x40 > > > +#define REG_LAY_SIZE 0x44 > > > +#define REG_LAY_PITCH0x48 > > > +#define REG_LAY_POS 0x4C > > > +#define REG_LAY_ALPHA0x50 > > > +#define REG_LAY_CROP_START 0x5C > > > + > > > +/* Interrupt control registers */ > > > +#define REG_DPU_INT_EN 0x1E0 > > > +#define REG_DPU_INT_CLR 0x1E4 > > > +#define REG_DPU_INT_STS 0x1E8 > > > + > > > +/* DPI control registers */ > > > +#define REG_DPI_CTRL 0x1F0 > > > +#define REG_DPI_H_TIMING 0x1F4 > > > +#define REG_DPI_V_TIMING 0x1F8 > > > + > > > +/* MMU control registers */ > > > +#define REG_MMU_EN 0x800 > > > +#define REG_MMU_VPN_RANGE0x80C > > > +#define REG_MMU_VAOR_ADDR_RD 0x818 > > > +#define REG_MMU_VAOR_ADDR_WR 0x81C > > > +#define REG_MMU_INV_ADDR_RD 0x820 > > > +#define REG_MMU_INV_ADDR_WR 0x824 > > > +#define REG_MMU_PPN1 0x83C > > > +#define REG_MMU_RANGE1 0x840 > > > +#define REG_MMU_PPN2 0x844 > > > +#define REG_MMU_RANGE2 0
Re: [PATCH] video: use getter/setter functions
On Wed, Feb 10, 2021 at 04:12:58PM +, Lee Jones wrote:
> On Wed, 10 Feb 2021, Daniel Vetter wrote:
>
> > On Wed, Feb 10, 2021 at 08:23:41AM +, Lee Jones wrote:
> > > On Tue, 09 Feb 2021, Julia Lawall wrote:
> > >
> > > > Use getter and setter functions, for platform_device structures and a
> > > > spi_device structure.
> > > >
> > > > Signed-off-by: Julia Lawall
> > > >
> > > > ---
> > > > drivers/video/backlight/qcom-wled.c |
> > > >2 +-
> > >
> > > This patch is fine.
> > >
> > > Could you please split it out and submit it separately though please.
> >
> > Or just apply the entire patch through backlight tree, there's nothing
> > going on in fbdev anyway I think.
> >
> > Acked-by: Daniel Vetter
>
> I can do that. Is that an fbdev Ack?
Yeah defacto I'm somehow stuck with that as maintainer of last resort :-)
Iirc we've got an S: orphaned entry pointing at drm.git trees.
-Daniel
>
> > > > drivers/video/fbdev/amifb.c |
> > > >4 ++--
> > > > drivers/video/fbdev/da8xx-fb.c |
> > > >4 ++--
> > > > drivers/video/fbdev/imxfb.c |
> > > >2 +-
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c |
> > > >6 +++---
> > > > drivers/video/fbdev/omap2/omapfb/dss/dpi.c |
> > > >4 ++--
> > > > drivers/video/fbdev/omap2/omapfb/dss/dsi.c |
> > > >4 ++--
> > > > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c |
> > > >2 +-
> > > > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c |
> > > >2 +-
> > > > drivers/video/fbdev/xilinxfb.c |
> > > >2 +-
> > > > 10 files changed, 16 insertions(+), 16 deletions(-)
> > >
> > > ...]
> > >
> > > > diff --git a/drivers/video/backlight/qcom-wled.c
> > > > b/drivers/video/backlight/qcom-wled.c
> > > > index 3bc7800eb0a9..091f07e7c145 100644
> > > > --- a/drivers/video/backlight/qcom-wled.c
> > > > +++ b/drivers/video/backlight/qcom-wled.c
> > > > @@ -1692,7 +1692,7 @@ static int wled_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > static int wled_remove(struct platform_device *pdev)
> > > > {
> > > > - struct wled *wled = dev_get_drvdata(&pdev->dev);
> > > > + struct wled *wled = platform_get_drvdata(pdev);
> > > >
> > > > mutex_destroy(&wled->lock);
> > > > cancel_delayed_work_sync(&wled->ovp_work);
> > >
> > > For my own reference (apply this as-is to your sign-off block):
> > >
> > > Acked-for-Backlight-by: Lee Jones
> > >
> >
>
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog
> ___
> 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
[PULL] drm-misc-next-fixes
hi Dave, Here a pull request for drm-misc-next-fixes, I'm not 100% sure about all the CEC fixes, but seems like it wouldn't hurt. We could revert the flag that enables CEC if needed. I just picked everything that looked like fixes from drm-misc-next. drm-misc-next-fixes-2021-02-11: drm-misc-next-fixes cherry picked from drm-misc-next for v5.12: - Assorted small fixes. - Disable and remove gma3600 support. - Fix CEC for vc4/hdmi. The following changes since commit 4c3a3292730c56591472717d8c5c0faf74f6c6bb: drm/amd/display: fix unused variable warning (2021-02-05 09:49:44 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-02-11 for you to fetch changes up to e2183fb135a7f62d317aa1c61eb3d1919080edba: Revert "drm/scheduler: Job timeout handler returns status (v3)" (2021-02-10 15:26:00 +0100) drm-misc-next-fixes cherry picked from drm-misc-next for v5.12: - Assorted small fixes. - Disable and remove gma3600 support. - Fix CEC for vc4/hdmi. Bernard Zhao (1): drm/vc4: remove unneeded variable: "ret" Dan Carpenter (2): drm/vmwgfx/vmwgfx_drv: Fix an error path in vmw_setup_pci_resources() drm/virtio: fix an error code in virtio_gpu_init() Daniel Vetter (1): drm/todo: Add entry for moving to dma_resv_lock Dom Cobley (5): drm/vc4: hdmi: Move hdmi reset to bind drm/vc4: hdmi: Fix register offset with longer CEC messages drm/vc4: hdmi: Fix up CEC registers drm/vc4: hdmi: Restore cec physical address on reconnect drm/vc4: hdmi: Remove cec_available flag Imre Deak (1): drm/dp_mst: Don't cache EDIDs for physical ports Joe Perches (1): dma-buf: Avoid comma separated statements Joseph Schulte (1): drm: replace drm_modeset_lock_all() in drm_client_modeset_dpms_legacy() Luben Tuikov (1): drm/scheduler: Job timeout handler returns status (v3) Maarten Lankhorst (1): Revert "drm/scheduler: Job timeout handler returns status (v3)" Maxime Ripard (7): drm/vc4: hdmi: Compute the CEC clock divider from the clock rate drm/vc4: hdmi: Update the CEC clock divider on HSM rate change drm/vc4: hdmi: Introduce a CEC clock drm/vc4: hdmi: Split the interrupt handlers drm/vc4: hdmi: Support BCM2711 CEC interrupt setup drm/vc4: hdmi: Don't register the CEC adapter if there's no interrupts dt-binding: display: bcm2711-hdmi: Add CEC and hotplug interrupts Qinglang Miao (1): drm/lima: fix reference leak in lima_pm_busy Thomas Zimmermann (4): drm/gma500: Remove Medfield support drm/gma500: Drop DRM_GMA3600 config option drm/gma500: Remove CONFIG_X86 conditionals from source files drm/gma500: Remove dependency on TTM Ye Bin (1): drm/nouveau: remove set but not used variable ‘pdev’ in nouveau_bios_init Zack Rusin (1): drm/vmwgfx: Fix some memory leaks on errors .../bindings/display/brcm,bcm2711-hdmi.yaml| 20 +- Documentation/gpu/todo.rst | 19 + drivers/dma-buf/st-dma-fence.c |7 +- drivers/gpu/drm/drm_client_modeset.c |7 +- drivers/gpu/drm/drm_dp_mst_topology.c |3 +- drivers/gpu/drm/gma500/Kconfig | 17 +- drivers/gpu/drm/gma500/Makefile| 37 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c|4 - drivers/gpu/drm/gma500/mdfld_device.c | 564 --- drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 1017 drivers/gpu/drm/gma500/mdfld_dsi_dpi.h | 79 -- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 603 drivers/gpu/drm/gma500/mdfld_dsi_output.h | 377 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 679 - drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.h | 80 -- drivers/gpu/drm/gma500/mdfld_intel_display.c | 966 --- drivers/gpu/drm/gma500/mdfld_output.c | 74 -- drivers/gpu/drm/gma500/mdfld_output.h | 76 -- drivers/gpu/drm/gma500/mdfld_tmd_vid.c | 197 drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 83 -- drivers/gpu/drm/gma500/mmu.c | 21 - drivers/gpu/drm/gma500/psb_drv.c | 16 +- drivers/gpu/drm/gma500/psb_drv.h | 66 -- drivers/gpu/drm/gma500/psb_intel_reg.h | 12 +- drivers/gpu/drm/gma500/psb_irq.c | 72 +- drivers/gpu/drm/gma500/psb_irq.h |2 - drivers/gpu/drm/gma500/psb_reg.h | 14 - drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 805 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.h | 38 - drivers/gpu/drm/lima/lima_sched.c
Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
On Wed, Feb 10, 2021 at 03:26:00PM -0800, Navare, Manasi wrote: > On Wed, Feb 10, 2021 at 05:07:03PM +0200, Ville Syrjälä wrote: > > On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote: > > > On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter > > > wrote: > > > > > > > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote: > > > > > > > > > These additional checks added to avoid EBUSY give unnecessary WARN_ON > > > > > in case of big joiner used in i915 in which case even if the modeset > > > > > is requested on a single pipe, internally another consecutive > > > > > pipe is stolen and used to drive half of the transcoder timings. > > > > > So in this case it is expected that requested crtc and affected crtcs > > > > > do not match. Hence the added WARN ON becomes irrelevant. > > > > > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == > > > true, > > > then the driver is allowed to steal an unrelated pipe. > > > > > > Maybe i915 is stealing a pipe without allow_modeset? > > > > No. All page flips etc. will have to get split up internally > > between multiple crtcs. > > > > So I think there's basically three options: > > a) massive rewrite of i915 to bypass even more of drm_atomic stuff > > b) allow i915 to silence that warning, which opens up the question > >whether the warn is doing any good if it can just be bypassed > > c) nuke the warning entirely > > > > a) is not going to happen, and it would any way allow i915 to > > do things any which way it wants without tripping the warn, > > rendering the warn entirely toothless. > > > > Hmm. Maybe there is a d) which would be to ignore all crtcs > > that are not logically enabled in the warn? Not sure if that > > could allow something to slit through that people want it to > > catch? Yeah it's option d), because the warning is meant to catch funny uapi that compositors don't want to deal with. So if this bigjoiner stuff in i915 is _really_ fully transparent, then it's ok. And excluding completely disabled CRTC from this check makes imo sense, since userspace - is not allowed to issue an atomic flip on these (it's off) - is required to set allow_modeset to enable (at which point i915 can internally move CRTC assignments around however it feels like and it's all fine). Once that fully modeset is done we'd again be in sync with userspace's understanding of what's going on. - hence there cannot be a spurious EBUSY to userspace I think what this needs is a big comment in the code explaining why we can afford to not check this. > So as per the offline IRC discussions, > - We can check for crtc_state->enable and only use the enabled crtcs > in the affected crtc calculation. And this enable would only > be set when modeset is done. So in case of bigjoiner no modeset on Pipe A, > even if Pipe B is stolen, since no modeset and because that pipe doesnt > get enabled the affected crtcs would still be 0x1. > > This should solve the problem. > Ville, Danvet - I will make this change? I think you volunteered :-) Pls Cc: all the people involved in the original patch discussion, so that they can ack the change too. 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: [PATCH] drm/ttm: make sure pool pages are cleared
On Wed, Feb 10, 2021 at 09:23:52PM +0100, Christian König wrote:
>
>
> Am 10.02.21 um 19:15 schrieb Daniel Vetter:
> > On Wed, Feb 10, 2021 at 5:05 PM Christian König
> > wrote:
> > > The old implementation wasn't consistend on this.
> > >
> > > But it looks like we depend on this so better bring it back.
> > >
> > > Signed-off-by: Christian König
> > > Reported-and-tested-by: Mike Galbraith
> > > Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
> > Well I think in general there's a bit an issue in ttm with not
> > clearing stuff everywhere. So definitely in favour of clearing stuff.
> > Looking at the code this only fixes the clearing, at alloc time we're
> > still very optional with clearing. I think we should just set
> > __GFP_ZERO unconditionally there too.
>
> No, the alloc handling is actually correct.
>
> We are clearing only when we allocate pages for userspace. Not for the
> kernel nor for eviction when pages are overwritten anyway.
>
> The key point is that the old page pool was ignoring the flag for this in
> some code paths and I wasn't sure if that's still necessary or not.
>
> Turned out it was necessary after all.
Somehow my git grep went wrong and I didn't find the users. You're right,
and I learned a few things more :-)
I'm kinda wondering, should we perhaps move the clearing to the use side,
and then only do when required? Might allow us to save it quite a few
times when we're thrashing around buffers in/out of vram, at the cost of
moving it to the alloc side for other cases.
Just an idea.
-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: [PATCH] drm/tiny: add driver for newhaven,1.8-128160EF
On Thu, Feb 11, 2021 at 10:50:58AM +0100, Daniel Mack wrote:
> This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
> an Ilitek ILI9163 controller.
>
> Signed-off-by: Daniel Mack
> ---
> .../bindings/display/ilitek,ili9163.txt | 27 +++
I think the dt stuff needs to be split up and cc'ed to dt maintainers for
ack.
> drivers/gpu/drm/tiny/Kconfig | 13 +
> drivers/gpu/drm/tiny/Makefile | 1 +
> drivers/gpu/drm/tiny/ili9163.c| 224 ++
> 4 files changed, 265 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/ilitek,ili9163.txt
> create mode 100644 drivers/gpu/drm/tiny/ili9163.c
>
> diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
> b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
> new file mode 100644
> index 0..fee119991c14e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
> @@ -0,0 +1,27 @@
> +Ilitek ILI9163 display panels
> +
> +This binding is for display panels using an Ilitek ILI9163 controller in SPI
> +mode.
> +
> +Required properties:
> +- compatible:"newhaven,1.8-128160EF", "ilitek,ili9163"
> +- dc-gpios: D/C pin
> +- reset-gpios: Reset pin
> +
> +The node for this driver must be a child node of a SPI controller, hence
> +all mandatory properties described in ../spi/spi-bus.txt must be specified.
> +
> +Optional properties:
> +- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> + display@0{
> + compatible = "newhaven,1.8-128160EF", "ilitek,ili9163"
> + reg = <0>;
> + spi-max-frequency = <3200>;
> + dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
> + rotation = <270>;
> + backlight = <&backlight>;
> + };
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index 2b6414f0fa759..9de0c0eeea6f5 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -41,6 +41,19 @@ config TINYDRM_HX8357D
>
> If M is selected the module will be called hx8357d.
>
> +config TINYDRM_ILI9163
> + tristate "DRM support for ILI9163 display panels"
> + depends on DRM && SPI
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DBI
> + select BACKLIGHT_CLASS_DEVICE
> + help
> + DRM driver for the following Ilitek ILI9163 panels:
> + * NHD-1.8-128160EF 128x160 TFT
> +
> + If M is selected the module will be called ili9163.
> +
> config TINYDRM_ILI9225
> tristate "DRM support for ILI9225 display panels"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
> index 6ae4e9e5a35fb..78016b2ed11b5 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -3,6 +3,7 @@
> obj-$(CONFIG_DRM_CIRRUS_QEMU)+= cirrus.o
> obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
> obj-$(CONFIG_TINYDRM_HX8357D)+= hx8357d.o
> +obj-$(CONFIG_TINYDRM_ILI9163)+= ili9163.o
> obj-$(CONFIG_TINYDRM_ILI9225)+= ili9225.o
> obj-$(CONFIG_TINYDRM_ILI9341)+= ili9341.o
> obj-$(CONFIG_TINYDRM_ILI9486)+= ili9486.o
> diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
> new file mode 100644
> index 0..9f90ea9556c4d
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/ili9163.c
> @@ -0,0 +1,224 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ILI9163_FRMCTR1 0xb1
> +
> +#define ILI9163_PWCTRL1 0xc0
> +#define ILI9163_PWCTRL2 0xc1
> +#define ILI9163_VMCTRL1 0xc5
> +#define ILI9163_VMCTRL2 0xc7
> +#define ILI9163_PWCTRLA 0xcb
> +#define ILI9163_PWCTRLB 0xcf
> +
> +#define ILI9163_EN3GAM 0xf2
> +
> +#define ILI9163_MADCTL_BGR BIT(3)
> +#define ILI9163_MADCTL_MVBIT(5)
> +#define ILI9163_MADCTL_MXBIT(6)
> +#define ILI9163_MADCTL_MYBIT(7)
> +
> +static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
> + struct drm_crtc_state *crtc_state,
> + struct drm_plane_state *plane_state)
> +{
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
> + struct mipi_dbi *dbi = &dbidev->dbi;
> + u8 addr_mode;
> + int ret, idx;
> +
> + if (!drm_dev_enter(pipe->crtc.dev, &idx))
> + return;
> +
> + DRM_DEBUG_KMS("\n");
> +
> + ret = mipi_dbi_poweron_con
Re: [PATCH v2] drm/msm: a6xx: Make sure the SQE microcode is safe
On Thu, Feb 11, 2021 at 06:50:28PM +0530, Akhil P Oommen wrote:
> On 2/10/2021 6:22 AM, Jordan Crouse wrote:
> >Most a6xx targets have security issues that were fixed with new versions
> >of the microcode(s). Make sure that we are booting with a safe version of
> >the microcode for the target and print a message and error if not.
> >
> >v2: Add more informative error messages and fix typos
> >
> >Signed-off-by: Jordan Crouse
> >---
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 77 ++-
> > 1 file changed, 64 insertions(+), 13 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >index ba8e9d3cf0fe..064b7face504 100644
> >--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >@@ -522,28 +522,73 @@ static int a6xx_cp_init(struct msm_gpu *gpu)
> > return a6xx_idle(gpu, ring) ? 0 : -EINVAL;
> > }
> >-static void a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
> >+/*
> >+ * Check that the microcode version is new enough to include several key
> >+ * security fixes. Return true if the ucode is safe.
> >+ */
> >+static bool a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
> > struct drm_gem_object *obj)
> > {
> >+struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> >+struct msm_gpu *gpu = &adreno_gpu->base;
> > u32 *buf = msm_gem_get_vaddr(obj);
> >+bool ret = false;
> > if (IS_ERR(buf))
> >-return;
> >+return false;
> > /*
> >- * If the lowest nibble is 0xa that is an indication that this microcode
> >- * has been patched. The actual version is in dword [3] but we only care
> >- * about the patchlevel which is the lowest nibble of dword [3]
> >- *
> >- * Otherwise check that the firmware is greater than or equal to 1.90
> >- * which was the first version that had this fix built in
> >+ * Targets up to a640 (a618, a630 and a640) need to check for a
> >+ * microcode version that is patched to support the whereami opcode or
> >+ * one that is new enough to include it by default.
> > */
> >-if (((buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1)
> >-a6xx_gpu->has_whereami = true;
> >-else if ((buf[0] & 0xfff) > 0x190)
> >-a6xx_gpu->has_whereami = true;
> >+if (adreno_is_a618(adreno_gpu) || adreno_is_a630(adreno_gpu) ||
> >+adreno_is_a640(adreno_gpu)) {
> >+/*
> >+ * If the lowest nibble is 0xa that is an indication that this
> >+ * microcode has been patched. The actual version is in dword
> >+ * [3] but we only care about the patchlevel which is the lowest
> >+ * nibble of dword [3]
> >+ *
> >+ * Otherwise check that the firmware is greater than or equal
> >+ * to 1.90 which was the first version that had this fix built
> >+ * in
> >+ */
> >+if buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1) ||
> >+(buf[0] & 0xfff) >= 0x190) {
> >+a6xx_gpu->has_whereami = true;
> >+ret = true;
> >+goto out;
> >+}
> >+DRM_DEV_ERROR(&gpu->pdev->dev,
> >+"a630 SQE ucode is too old. Have version %x need at
> >least %x\n",
> >+buf[0] & 0xfff, 0x190);
> >+} else {
> >+/*
> >+ * a650 tier targets don't need whereami but still need to be
> >+ * equal to or newer than 1.95 for other security fixes
> >+ */
> >+if (adreno_is_a650(adreno_gpu)) {
> >+if ((buf[0] & 0xfff) >= 0x195) {
> >+ret = true;
> >+goto out;
> >+}
> >+
> >+DRM_DEV_ERROR(&gpu->pdev->dev,
> >+"a650 SQE ucode is too old. Have version %x
> >need at least %x\n",
> >+buf[0] & 0xfff, 0x195);
> >+}
> >+
> >+/*
> >+ * When a660 is added those targets should return true here
> >+ * since those have all the critical security fixes built in
> >+ * from the start
> >+ */
> Or we can just initialize 'ret' as true.
I thought about it and I think I want to force an accept list here instead of
letting new targets get by with an implicit pass.
Jordan
> -Akhil
> >+}
> >+out:
> > msm_gem_put_vaddr(obj);
> >+return ret;
> > }
> > static int a6xx_ucode_init(struct msm_gpu *gpu)
> >@@ -566,7 +611,13 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
> > }
> > msm_gem_object_set_name(a6xx_gpu->sqe_bo, "sqefw");
> >-a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo);
> >+if (!a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo)) {
> >+msm_gem_unpin_iova(a
Re: [PATCH] drm/ttm: make sure pool pages are cleared
Am 11.02.21 um 16:58 schrieb Daniel Vetter:
On Wed, Feb 10, 2021 at 09:23:52PM +0100, Christian König wrote:
Am 10.02.21 um 19:15 schrieb Daniel Vetter:
On Wed, Feb 10, 2021 at 5:05 PM Christian König
wrote:
The old implementation wasn't consistend on this.
But it looks like we depend on this so better bring it back.
Signed-off-by: Christian König
Reported-and-tested-by: Mike Galbraith
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Well I think in general there's a bit an issue in ttm with not
clearing stuff everywhere. So definitely in favour of clearing stuff.
Looking at the code this only fixes the clearing, at alloc time we're
still very optional with clearing. I think we should just set
__GFP_ZERO unconditionally there too.
No, the alloc handling is actually correct.
We are clearing only when we allocate pages for userspace. Not for the
kernel nor for eviction when pages are overwritten anyway.
The key point is that the old page pool was ignoring the flag for this in
some code paths and I wasn't sure if that's still necessary or not.
Turned out it was necessary after all.
Somehow my git grep went wrong and I didn't find the users. You're right,
and I learned a few things more :-)
I'm kinda wondering, should we perhaps move the clearing to the use side,
and then only do when required? Might allow us to save it quite a few
times when we're thrashing around buffers in/out of vram, at the cost of
moving it to the alloc side for other cases.
I was playing with that idea in my mind as well.
The key argument against it is that the pool can optimize by clearing on
free instead of during allocation.
This way we also implement a bit heuristic in the pool and have a list
of cleared and not cleared pages.
Regards,
Christian.
Just an idea.
-Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä wrote: > On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote: > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == > > true, > > then the driver is allowed to steal an unrelated pipe. > > > > Maybe i915 is stealing a pipe without allow_modeset? > > No. All page flips etc. will have to get split up internally > between multiple crtcs. I think this is the salient point. > So I think there's basically three options: > a) massive rewrite of i915 to bypass even more of drm_atomic stuff > b) allow i915 to silence that warning, which opens up the question >whether the warn is doing any good if it can just be bypassed > c) nuke the warning entirely > > a) is not going to happen, and it would any way allow i915 to > do things any which way it wants without tripping the warn, > rendering the warn entirely toothless. > > Hmm. Maybe there is a d) which would be to ignore all crtcs > that are not logically enabled in the warn? Not sure if that > could allow something to slit through that people want it to > catch? So from what I understand, if I enable CRTC 44 and the driver magically decides to split it up as a 'big-joiner' output, it will also steal CRTC 50 to work as the other half of the output. Then if I attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me getting atomic completion events for both CRTC 44 and CRTC 50? That's not OK from a userspace perspective. If you want to do magic to create the illusion of a single CRTC, then that magic needs to be consistent. At the moment it's the worst kind of magic: it does implicit things under the hood for you, but then leaks all of the behind-the-scenes detail into userspace. Continuing with that would force us all to just ignore whatever events we see, because we can't reason about what they may be or why they're generated. Which doesn't allow for any kind of best practice in userspace. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
On Thu, Feb 11, 2021 at 04:14:02PM +, Daniel Stone wrote: > On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä > wrote: > > On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote: > > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == > > > true, > > > then the driver is allowed to steal an unrelated pipe. > > > > > > Maybe i915 is stealing a pipe without allow_modeset? > > > > No. All page flips etc. will have to get split up internally > > between multiple crtcs. > > I think this is the salient point. > > > So I think there's basically three options: > > a) massive rewrite of i915 to bypass even more of drm_atomic stuff > > b) allow i915 to silence that warning, which opens up the question > >whether the warn is doing any good if it can just be bypassed > > c) nuke the warning entirely > > > > a) is not going to happen, and it would any way allow i915 to > > do things any which way it wants without tripping the warn, > > rendering the warn entirely toothless. > > > > Hmm. Maybe there is a d) which would be to ignore all crtcs > > that are not logically enabled in the warn? Not sure if that > > could allow something to slit through that people want it to > > catch? > > So from what I understand, if I enable CRTC 44 and the driver > magically decides to split it up as a 'big-joiner' output, it will > also steal CRTC 50 to work as the other half of the output. Then if I > attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me > getting atomic completion events for both CRTC 44 and CRTC 50? > > That's not OK from a userspace perspective. If you want to do magic to > create the illusion of a single CRTC, then that magic needs to be > consistent. At the moment it's the worst kind of magic: it does > implicit things under the hood for you, but then leaks all of the > behind-the-scenes detail into userspace. > > Continuing with that would force us all to just ignore whatever events > we see, because we can't reason about what they may be or why they're > generated. Which doesn't allow for any kind of best practice in > userspace. You should only get externally visibile events for stuff in your request. Or at least if that's not the case then the atomic code is already bork regardless of bigjoiner. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Not 100% sure if I correctly fixed drm-tip
On Thu, Feb 11, 2021 at 4:27 PM Christian König
wrote:
>
>
>
> Am 11.02.21 um 16:02 schrieb Jani Nikula:
> > On Thu, 11 Feb 2021, Christian König wrote:
> >> Hi guys,
> >>
> >> I had a conflict this morning in the ttm pool while pushing an important
> >> fix to drm-misc-fixes.
> >>
> >> I'm not 100% sure if I correctly fixed up drm-tip. How can this be
> >> double checked? And how can it be fixed if the merge has gone bad?
> > I'm afraid there's a problem; bb52cb0dec8d ("drm/ttm: make the pool
> > shrinker lock a mutex") in upstream and drm-misc-fixes creates a silent
> > conflict with ba051901d10f ("drm/ttm: add a debugfs file for the global
> > page pools") in drm-misc-next, causing the latter to use
> > spin_lock/unlock on a mutex.
> >
> > But while you hit a conflict, it does look like the conflict breaking
> > the build is silent, AFAICT the spinlock part does not conflict. So a
> > fixup patch in drm-rerere is probably needed until there are some
> > backmerges.
>
> Well exactly that's the issue. I've already had a fixup in drm-rerere
> for this.
>
> But today I've pushed another fix to drm-misc-fixes which also conflicts
> with ba051901d10f ("drm/ttm: add a debugfs file for the global page pools").
>
> I've fixed this up as well and committed the solution. But dim then
> complained that the original fixup is now not applicable any more (which
> is true as far as I know).
>
> This somehow went away when I said that dim should assume patch
> reversal, but I'm not sure if that's the right thing to do.
Nothing, it's all still broken. You need to delete the now unecessary
fixup. As a rule, when rebuilding drm-tip failed always try again to
confirm that what you've done actually fixed things (since sometimes
git can also not remember where to apply the resolution for some odd
reasons).
I'm fixing this now.
-Daniel
>
> Thanks,
> Christian.
>
> >
> >
> > BR,
> > Jani.
> >
> >
>
--
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 v4 24/80] drm/omap: dsi: move TE GPIO handling into core
* Tomi Valkeinen [210211 07:35]: > On 08/02/2021 19:55, Tony Lindgren wrote: > > Hi, > > > > * Tomi Valkeinen [201124 12:47]: > >> From: Sebastian Reichel > >> > >> In preparation for removing custom DSS calls from the DSI > >> panel driver, this moves support for external tearing event > >> GPIOs into the DSI host driver. This way tearing events are > >> always handled in the core resulting in simplification of > >> the panel drivers. > >> > >> The TE GPIO acquisition follows works in the same way as the > >> exynos DSI implementation. > > > > Looks like this patch causes the following warnings: > > > > DSI: omapdss DSI error: Failed to receive BTA > > DSI: omapdss DSI error: bta sync failed > > DSI: omapdss DSI error: vc(0) busy when trying to config for VP > > DSI: omapdss DSI error: Failed to receive BTA > > DSI: omapdss DSI error: bta sync failed > > DSI: omapdss DSI error: vc(0) busy when trying to config for VP > > DSI: omapdss DSI error: Failed to receive BTA > > DSI: omapdss DSI error: bta sync failed > > DSI: omapdss DSI error: vc(0) busy when trying to config for VP > > ... > > > > Any ideas? The display works for me despite the constant > > warnings. > > Which board is that? Do the errors start right from the boot, or only > after running something in userspace? This is with droid4, that's about the only device I use with a display on regular basis. I'm pretty sure some earlier version of Sebastian's patches worked fine. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] arm64: dts: qcom: sm8250: fix display nodes
Add sm8150/sm8250 compatibles to drm/msm and fix the sm8250 display nodes. Jonathan Marek (2): drm/msm: add compatibles for sm8150/sm8250 display arm64: dts: qcom: sm8250: fix display nodes .../devicetree/bindings/display/msm/dpu.txt | 4 +-- arch/arm64/boot/dts/qcom/sm8250.dtsi | 34 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 ++ drivers/gpu/drm/msm/msm_drv.c | 6 ++-- 4 files changed, 16 insertions(+), 30 deletions(-) -- 2.26.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm: add compatibles for sm8150/sm8250 display
The driver already has support for sm8150/sm8250, but the compatibles were
never added.
Also inverse the non-mdp4 condition in add_display_components() to avoid
having to check every new compatible in the condition.
Signed-off-by: Jonathan Marek
---
Documentation/devicetree/bindings/display/msm/dpu.txt | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 ++
drivers/gpu/drm/msm/msm_drv.c | 6 +++---
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index 551ae26f60da..5763f43200a0 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -8,7 +8,7 @@ The DPU display controller is found in SDM845 SoC.
MDSS:
Required properties:
-- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss"
+- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss", "qcom,sm8150-mdss",
"qcom,sm8250-mdss"
- reg: physical base address and length of contoller's registers.
- reg-names: register region names. The following region is required:
* "mdss"
@@ -41,7 +41,7 @@ Optional properties:
MDP:
Required properties:
-- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu"
+- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu", "qcom,sm8150-dpu",
"qcom,sm8250-dpu"
- reg: physical base address and length of controller's registers.
- reg-names : register region names. The following region is required:
* "mdp"
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5a8e3e1fc48c..fff12a4c8bfc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1219,6 +1219,8 @@ static const struct dev_pm_ops dpu_pm_ops = {
static const struct of_device_id dpu_dt_match[] = {
{ .compatible = "qcom,sdm845-dpu", },
{ .compatible = "qcom,sc7180-dpu", },
+ { .compatible = "qcom,sm8150-dpu", },
+ { .compatible = "qcom,sm8250-dpu", },
{}
};
MODULE_DEVICE_TABLE(of, dpu_dt_match);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..928f13d4bfbc 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1185,9 +1185,7 @@ static int add_display_components(struct device *dev,
* Populate the children devices, find the MDP5/DPU node, and then add
* the interfaces to our components list.
*/
- if (of_device_is_compatible(dev->of_node, "qcom,mdss") ||
- of_device_is_compatible(dev->of_node, "qcom,sdm845-mdss") ||
- of_device_is_compatible(dev->of_node, "qcom,sc7180-mdss")) {
+ if (!of_device_is_compatible(dev->of_node, "qcom,mdp4")) {
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
DRM_DEV_ERROR(dev, "failed to populate children
devices\n");
@@ -1320,6 +1318,8 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
{ .compatible = "qcom,sdm845-mdss", .data = (void *)KMS_DPU },
{ .compatible = "qcom,sc7180-mdss", .data = (void *)KMS_DPU },
+ { .compatible = "qcom,sm8150-mdss", .data = (void *)KMS_DPU },
+ { .compatible = "qcom,sm8250-mdss", .data = (void *)KMS_DPU },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Feb 11 (drivers/gpu/drm/i915/display/intel_panel.o)
On 2/11/21 3:26 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20210210: > > The powerpc tree still had its build failure in the allyesconfig for > which I applied a supplied patch. > > The v4l-dvb tree lost its build failure. > > The drm-misc tree lost its build failure. > > The modules tree lost its build failure. > > The device-mapper tree gained a build failure so I used the version > from next-20210210. > > The tip tree lost its boot failure. > > The rcu tree gained conflicts against the block tree. > > The driver-core tree lost its build failure. > > The akpm-current tree gained conflicts against the fscache tree. > > Non-merge commits (relative to Linus' tree): 9533 > 9470 files changed, 385794 insertions(+), 266880 deletions(-) > > > > I have created today's linux-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you > are tracking the linux-next tree using git, you should not use "git pull" > to do so as that will try to merge the new linux-next release with the > old one. You should use "git fetch" and checkout or reset to the new > master. > > You can see which trees have been included by looking in the Next/Trees > file in the source. There are also quilt-import.log and merge.log > files in the Next directory. Between each merge, the tree was built > with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a > multi_v7_defconfig for arm and a native build of tools/perf. After > the final fixups (if any), I do an x86_64 modules_install followed by > builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), > ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc > and sparc64 defconfig and htmldocs. And finally, a simple boot test > of the powerpc pseries_le_defconfig kernel in qemu (with and without > kvm enabled). > > Below is a summary of the state of the merge. > > I am currently merging 333 trees (counting Linus' and 87 trees of bug > fix patches pending for the current merge release). > > Stats about the size of the tree over time can be seen at > http://neuling.org/linux-next-size.html . > > Status of my local build tests will be at > http://kisskb.ellerman.id.au/linux-next . If maintainers want to give > advice about cross compilers/configs that work, we are always open to add > more builds. > > Thanks to Randy Dunlap for doing many randconfig builds. And to Paul > Gortmaker for triage and bug fixes. > on x86_64: # CONFIG_ACPI is not set ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_register': intel_panel.c:(.text+0x40fb): undefined reference to `backlight_device_register' ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_unregister': intel_panel.c:(.text+0x41a4): undefined reference to `backlight_device_unregister' Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap config-r7779.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Wed, 2021-02-10 at 23:15 -0500, Rodrigo Vivi wrote:
> On Mon, Feb 08, 2021 at 06:39:00PM -0500, Lyude Paul wrote:
> > Since we're about to implement eDP backlight support in nouveau using the
> > standard protocol from VESA, we might as well just take the code that's
> > already written for this and move it into a set of shared DRM helpers.
> >
> > Note that these helpers are intended to handle DPCD related backlight
> > control bits such as setting the brightness level over AUX, probing the
> > backlight's TCON, enabling/disabling the backlight over AUX if supported,
> > etc. Any PWM-related portions of backlight control are explicitly left up
> > to the driver, as these will vary from platform to platform.
> >
> > The only exception to this is the calculation of the PWM frequency
> > pre-divider value. This is because the only platform-specific information
> > required for this is the PWM frequency of the panel, which the driver is
> > expected to provide if available. The actual algorithm for calculating this
> > value is standard and is defined in the eDP specification from VESA.
> >
> > Note that these helpers do not yet implement the full range of features
> > the VESA backlight interface provides, and only provide the following
> > functionality (all of which was already present in i915's DPCD backlight
> > support):
> >
> > * Basic control of brightness levels
> > * Basic probing of backlight capabilities
> > * Helpers for enabling and disabling the backlight
> >
> > v3:
> > * Split out changes to i915's backlight code to separate patches to make it
> > easier to review
> > v4:
> > * Style/spelling changes from Thomas Zimmermann
> >
> > Signed-off-by: Lyude Paul
> > Cc: Jani Nikula
> > Cc: Dave Airlie
> > Cc: greg.depo...@gmail.com
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 332 ++
> > .../drm/i915/display/intel_display_types.h | 5 +-
> > .../drm/i915/display/intel_dp_aux_backlight.c | 285 ++-
> > include/drm/drm_dp_helper.h | 48 +++
> > 4 files changed, 412 insertions(+), 258 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index eedbb48815b7..1a3d4679d720 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -3082,3 +3082,335 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct
> > drm_dp_aux *aux, u8 color_spc)
> > return 0;
> > }
> > EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> > +
> > +/**
> > + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel
> > via AUX
> > + * @aux: The DP AUX channel to use
> > + * @bl: Backlight capability info from drm_edp_backlight_init()
> > + * @level: The brightness level to set
> > + *
> > + * Sets the brightness level of an eDP panel's backlight. Note that the
> > panel's backlight must
> > + * already have been enabled by the driver by calling
> > drm_edp_backlight_enable().
> > + *
> > + * Returns: %0 on success, negative error code on failure
> > + */
> > +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + u16 level)
> > +{
> > + int ret;
> > + u8 buf[2] = { 0 };
> > +
> > + if (bl->lsb_reg_used) {
> > + buf[0] = (level & 0xff00) >> 8;
> > + buf[1] = (level & 0x00ff);
> > + } else {
> > + buf[0] = level;
> > + }
> > +
> > + ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
> > sizeof(buf));
> > + if (ret != sizeof(buf)) {
> > + DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
> > aux->name, ret);
> > + return ret < 0 ? ret : -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> > +
> > +static int
> > +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + bool enable)
> > +{
> > + int ret;
> > + u8 buf;
> > +
> > + /* The panel uses something other then DPCD for enabling its
> > backlight */
> > + if (!bl->aux_enable)
> > + return 0;
> > +
> > + ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, &buf);
> > + if (ret != 1) {
> > + DRM_ERROR("%s: Failed to read eDP display control register:
> > %d\n", aux->name, ret);
> > + return ret < 0 ? ret : -EIO;
> > + }
> > + if (enable)
> > + buf |= DP_EDP_BACKLIGHT_ENABLE;
> > + else
> > + buf &= ~DP_EDP_BACKLIGHT_ENABLE;
> > +
> > + ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
> > + if (ret != 1) {
> > + DRM_ERROR("%s: Failed to write eDP display control register:
> > %d\n", aux->name, ret);
> > + return ret < 0 ? ret : -EIO;
> > + }
> > +
> > +
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #41 from Jan Kokemüller (jan.kokemuel...@gmail.com) --- > Looks correct. Care to send out a proper git patch? Thank you for having a look at the patch! I've sent it to the amd-gfx list. -- You may reply to this email to add a comment. 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
Fw: [Bug 211707] New: BUG: unable to handle page fault for address: ffffa147bdf6b91d
Looks like a recent regression? Begin forwarded message: Date: Thu, 11 Feb 2021 14:27:43 + From: bugzilla-dae...@bugzilla.kernel.org To: a...@linux-foundation.org Subject: [Bug 211707] New: BUG: unable to handle page fault for address: a147bdf6b91d https://bugzilla.kernel.org/show_bug.cgi?id=211707 Bug ID: 211707 Summary: BUG: unable to handle page fault for address: a147bdf6b91d Product: Memory Management Version: 2.5 Kernel Version: 5.11-rc7 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Page Allocator Assignee: a...@linux-foundation.org Reporter: erhar...@mailbox.org CC: mic...@daenzer.net Regression: No Created attachment 295231 --> https://bugzilla.kernel.org/attachment.cgi?id=295231&action=edit kernel dmesg (5.11-rc7, eMachines E620) [...] BUG: unable to handle page fault for address: a147bdf6b91d #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 52001067 P4D 52001067 PUD 0 Oops: [#1] SMP NOPTI CPU: 1 PID: 623 Comm: udevd Not tainted 5.11.0-rc7-E620 #2 Hardware name: eMachineseMachines E620 /Nile , BIOS V1.03 09/30/2008 RIP: 0010:get_freepointer+0x6/0x1a Code: 89 f0 48 89 d6 48 89 ca 48 83 ef 70 49 8b 48 30 48 c7 c0 fb ff ff ff 48 85 c9 74 07 e8 f2 47 87 00 48 98 c3 8b 47 28 48 01 c6 <48> 8b 06 48 89 f2 48 33 87 b0 00 00 00 48 0f ca 48 31 d0 c3 48 8b RSP: 0018:ac5c807cb898 EFLAGS: 00010286 RAX: 0030 RBX: a14707082078 RCX: 022a RDX: a14702180980 RSI: a147bdf6b91d RDI: a14700042a00 RBP: 0dc0 R08: a147bdf6b8ed R09: 0229 R10: R11: a147070822d0 R12: a14700042a00 R13: a14700042a00 R14: 0050 R15: c08b1d88 FS: 7ff6aaf13b68() GS:a1472df0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: a147bdf6b91d CR3: 000104156000 CR4: 06e0 Call Trace: kmem_cache_alloc_trace+0x97/0x157 radeon_ttm_tt_create+0x21/0x66 [radeon] ttm_tt_create+0x8d/0xa3 [ttm] ttm_bo_handle_move_mem+0x85/0xf9 [ttm] ? radeon_update_memory_usage+0x4b/0x4b [radeon] ttm_bo_validate+0x138/0x1aa [ttm] ttm_bo_init_reserved+0x282/0x2ba [ttm] ttm_bo_init+0x56/0x8f [ttm] ? radeon_update_memory_usage+0x4b/0x4b [radeon] radeon_bo_create+0x17d/0x255 [radeon] ? radeon_update_memory_usage+0x4b/0x4b [radeon] radeon_ring_init+0x3e/0x12d [radeon] r100_cp_init+0x1ea/0x469 [radeon] rs690_startup+0x114/0x196 [radeon] ? radeon_pm_init+0x607/0x626 [radeon] rs690_init+0x29f/0x2eb [radeon] radeon_device_init+0x899/0xa7d [radeon] radeon_driver_load_kms+0x83/0x15c [radeon] drm_dev_register+0xf4/0x1bc [drm] radeon_pci_probe+0x134/0x178 [radeon] pci_device_probe+0x95/0x104 really_probe+0x144/0x326 driver_probe_device+0x63/0x92 device_driver_attach+0x37/0x50 __driver_attach+0x8d/0x93 ? device_driver_attach+0x50/0x50 bus_for_each_dev+0x71/0xa7 bus_add_driver+0x106/0x1b7 driver_register+0x99/0xd2 ? 0xc09da000 do_one_initcall+0xe2/0x24a ? trace_kmalloc+0x9a/0xc7 ? kmem_cache_alloc_trace+0x130/0x157 do_init_module+0x56/0x1f5 __do_sys_finit_module+0x94/0xbb do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7ff6aaea39d8 Code: 4c 89 4c 24 48 4c 8b 4c 24 60 48 89 54 24 10 48 8b 7e 08 48 89 74 24 18 48 8b 51 18 c7 44 24 08 08 00 00 00 48 8b 76 10 0f 05 <48> 89 c7 e8 40 08 fe ff 48 83 c4 58 c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fd2e470 EFLAGS: 0202 ORIG_RAX: 0139 RAX: ffda RBX: 7ff6aae1c9d0 RCX: 7ff6aaea39d8 RDX: RSI: 7ff6aae168e7 RDI: 001b RBP: 0002 R08: R09: 7ff6aaebb6dd R10: 001b R11: 0202 R12: R13: 7ff6aa487d30 R14: 7ff6aae168e7 R15: Modules linked in: radeon(+) snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mac80211 snd_hda_intel evdev snd_intel_dspcfg input_leds snd_hda_codec led_class ath snd_hwdep psmouse snd_hda_core i2c_algo_bit lm83 drm_ttm_helper snd_pcm ohci_pci ttm snd_timer k8temp drm_kms_helper adm1021 hwmon snd ohci_hcd ehci_pci cfbfillrect soundcore syscopyarea cfbimgblt cfg80211 ehci_hcd sysfillrect i2c_piix4 sysimgblt fb_sys_fops sr_mod usbcore cfbcopyarea usb_common cdrom drm video drm_panel_orientation_quirks rfkill fb battery libarc4 ac font fbdev backlight thermal button processor CR2: a147bdf6b91d ---[ end trace 1a80b76ad6066c81 ]--- Some data about the machine: # inxi -b System:Kernel: 5.11.0-rc7-E620 x86_64 bits: 64 Desktop: MATE 1.24.0 Distro: Gentoo Base System release 2.7 Machine: Type: Laptop System: eMachines product: eMachines E620 v: V1.03 serial: LXN270Y0048480D
Proposed Changes to Elida-KD35T133 Panel Driver
I'd like to make the following changes to this panel driver. The first patch is to add rotation support (rotates only the DRM connector at this time). The panel is currently rotated 270 degrees in the Odroid Go Advance, and this change allows us to describe that hardware better. The second patch just fixes a typo. The panel in question is 3.5 inches in size not 5.5 inches. Thank you. 0001-drm-panel-add-rotation-support-for-Elida-KD35T133-pa.patch Description: 0001-drm-panel-add-rotation-support-for-Elida-KD35T133-pa.patch 0002-drm-panel-correct-typo-in-comments-for-Elida-KD35T13.patch Description: 0002-drm-panel-correct-typo-in-comments-for-Elida-KD35T13.patch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
2021 X.Org Foundation Membership renewal and election schedule
The 2021 X.Org Foundation elections are rapidly approaching. In preparation of the elections we would like to remind you that members will need to renew their membership each year in order to vote. Please take the time to renew your membership by logging into https://members.x.org and clicking on the "Apply" button to apply for the 2021-2022 membership. We would also like to encourage you to start considering yourself or someone else for nomination to the board. We will send another email to start the official nomination period when it opens. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes
On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++-
> 1 file changed, 21 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..31662c3a8c9e 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool
> write_only)
> {
> const struct v4l2_fmtdesc *p = arg;
>
> - pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c,
> mbus_code=0x%04x, description='%.*s'\n",
> + pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc,
> mbus_code=0x%04x, description='%.*s'\n",
Is %p4cc really acceptable here?
The original code printed only the 4 characters. The original code
would print something like:
index=21, type=bla, flags=0x0, pixelformat=BG12, mbus_code=0x0a9f,
descrition="bla bla bla"
while the new code will do:
index=21, type=bla, flags=0x0, pixelformat=BG12 little-endian (0x32314742),
mbus_code=0x0a9f, descrition="bla bla bla"
This is much harder to parse because there are spaces also inside
pixel_format=
> p->index, prt_names(p->type, v4l2_type_names),
> - p->flags, (p->pixelformat & 0xff),
> - (p->pixelformat >> 8) & 0xff,
> - (p->pixelformat >> 16) & 0xff,
> - (p->pixelformat >> 24) & 0xff,
> - p->mbus_code,
> + p->flags, &p->pixelformat, p->mbus_code,
> (int)sizeof(p->description), p->description);
> }
>
Best Regards,
Petr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> Hi Andy,
>
> On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > > wrote:
> >
> > ...
> >
> > > > > + %p4cc BG12 little-endian (0x32314742)
> > > >
> > > > This misses examples of the (strange) escaping cases and wiped
> > > > whitespaces to make sure everybody understands that 'D 12' will be the
> > > > same as 'D1 2' (side note: which I disagree on, perhaps something
> > > > should be added into documentation why).
> > >
> > > The spaces are expected to be at the end only. I can add such example if
> > > you like. There are no fourcc codes with spaces in the middle in neither
> > > V4L2 nor DRM, and I don't think the expectation is to have them either.
> >
> > But then the code suggests otherwise. Perhaps we need to extract
> > skip_trailing_spaces() from strim() and use it here.
>
> But this wouldn't affect the result in this case, would it?
Is there any existing implementation that would skip spaces, please?
IMHO, this might just hide problems. We should show exactly what
is stored unless anyone explicitly ask for skipping that spaces.
> >
> > ...
> >
> > > > > +static noinline_for_stack
> > > > > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > > > > + struct printf_spec spec, const char *fmt)
> > > > > +{
> > > >
> > > > > + char output[sizeof("(xx)(xx)(xx)(xx) little-endian
> > > > > (0x01234567)")];
> > > >
> > > > Do we have any evidence / document / standard that the above format is
> > > > what people would find good? From existing practices (I consider other
> > > > printings elsewhere and users in this series) I find '(xx)' form for
> > > > hex numbers is weird. The standard practice is to use \xHH (without
> > > > parentheses).
> > >
> > > Earlier in the review it was proposed that special handling of codes below
> > > 32 should be added, which I did. Using the parentheses is apparently an
> > > existing practice elsewhere.
> >
> > Where? \xHH is quite well established format for escaping. Never heard about
> > '(xx)' variant before this very series.
> Mauro referred to FourCC codes while reviewing an earlier version of this,
> such as RGB(15).
This is quite easy to parse. The problem is that it is not clear
whether it is hexa or decimal number.
> Does \× imply only the next two characters are hexadecimal? I have to admit
> I don't remember seeting that, nor \x notation is common.
Hmm, the /xyy format might be hard to parse.
What about using the same approach as drm_get_format_name()?
I mean printing '?' when the character is not printable.
The exact value is printed later anyway.
The advantage is that it will always printk 4 characters.
> > > Note that neither DRM nor V4L2 currently has such fourcc codes currently.
> >
> > ...
> >
> > > > > + p = special_hex_number(p, output + sizeof(output) - 2,
> > > > > *fourcc,
> > > > > + sizeof(u32));
> > > >
> > > > This is perfectly one line (in this file we have even longer lines).
Ailus, please do not take this as a criticism of your patch.
I understand that it might have sounded like this but Andy did
not mean it.
Andy prefers slightly longer lines over wrapping only few characters.
It makes sense to me. There are more people with the same opinion.
Even checkpatch.pl tolerates lines up to 100 characters these days.
Of course, this is a subsystem specific preference. You did not have
any chance to know it. There is no need to fight over it.
Best Regards,
Petr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/kms: Use nested locking for crtc lock instead of custom classes
We don't need to make up custom lock classes here, we can simply use
mutex_lock_nested() and pass in the index of the crtc to the locking
APIs instead. This helps lockdep understand that these are really
different locks while avoiding having to allocate custom lockdep
classes.
Cc: Krishna Manikandan
Suggested-by: Daniel Vetter
Fixes: b3d91800d9ac ("drm/msm: Fix race condition in msm driver with async
layer updates")
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/msm_atomic.c | 7 +--
drivers/gpu/drm/msm/msm_kms.h| 8 ++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 6a326761dc4a..edcaccaa27e6 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -57,10 +57,13 @@ static void vblank_put(struct msm_kms *kms, unsigned
crtc_mask)
static void lock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
{
+ int crtc_index;
struct drm_crtc *crtc;
- for_each_crtc_mask(kms->dev, crtc, crtc_mask)
- mutex_lock(&kms->commit_lock[drm_crtc_index(crtc)]);
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ crtc_index = drm_crtc_index(crtc);
+ mutex_lock_nested(&kms->commit_lock[crtc_index], crtc_index);
+ }
}
static void unlock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 4735251a394d..d8151a89e163 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -157,7 +157,6 @@ struct msm_kms {
* from the crtc's pending_timer close to end of the frame:
*/
struct mutex commit_lock[MAX_CRTCS];
- struct lock_class_key commit_lock_keys[MAX_CRTCS];
unsigned pending_crtc_mask;
struct msm_pending_timer pending_timers[MAX_CRTCS];
};
@@ -167,11 +166,8 @@ static inline int msm_kms_init(struct msm_kms *kms,
{
unsigned i, ret;
- for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++) {
- lockdep_register_key(&kms->commit_lock_keys[i]);
- __mutex_init(&kms->commit_lock[i], "&kms->commit_lock[i]",
-&kms->commit_lock_keys[i]);
- }
+ for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++)
+ mutex_init(&kms->commit_lock[i]);
kms->funcs = funcs;
base-commit: 182b4a2d251305201b6f9cae29067f7112f05835
--
https://chromeos.dev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211717] New: WARNING: CPU: 5 PID: 430 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:833 rn_clk_mgr_construct+0x2dd/0x440 [amdgpu]
https://bugzilla.kernel.org/show_bug.cgi?id=211717 Bug ID: 211717 Summary: WARNING: CPU: 5 PID: 430 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21 /rn_clk_mgr.c:833 rn_clk_mgr_construct+0x2dd/0x440 [amdgpu] Product: Drivers Version: 2.5 Kernel Version: 5.11.0-rc7-00084-g291009f656e8 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: gdam...@gmail.com Regression: No The CPU/GPU: AMD Ryzen 5 PRO 4650G Motherboard: MSI MS-7C94/MAG B550M MORTAR WIFI (MS-7C94), BIOS 1.20 08/03/2020 on boot I get this nasty message, although after that everything seems to work fine (running KDE/Plasma on Arch Linux). [ 10.328515] [drm] reserve 0x40 from 0xf41f80 for PSP TMR [ 10.526216] amdgpu :30:00.0: amdgpu: RAS: optional ras ta ucode is not available [ 10.546197] amdgpu :30:00.0: amdgpu: RAP: optional rap ta ucode is not available [ 10.547009] amdgpu :30:00.0: amdgpu: SMU is initialized successfully! [ 10.548329] [drm] kiq ring mec 2 pipe 1 q 0 [ 10.549171] [ cut here ] [ 10.549175] WARNING: CPU: 5 PID: 430 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:833 rn_clk_mgr_construct+0x2dd/0x440 [amdgpu] [ 10.549422] Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack amdgpu(+) nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ccm algif_aead des_generic libdes ecb algif_skcipher cmac md4 algif_hash af_alg iwlmvm hid_logitech_hidpp snd_hda_codec_realtek btrfs mac80211 snd_hda_codec_generic raid1 snd_hda_codec_hdmi ledtrig_audio snd_hda_intel dm_raid snd_intel_dspcfg raid456 soundwire_intel soundwire_generic_allocation intel_rapl_msr soundwire_cadence gpu_sched intel_rapl_common snd_hda_codec i2c_algo_bit async_raid6_recov drm_ttm_helper async_memcpy ttm async_pq snd_hda_core async_xor blake2b_generic async_tx md_mod edac_mce_amd joydev libarc4 mousedev input_leds snd_hwdep hid_logitech_dj xor drm_kms_helper soundwire_bus kvm_amd iwlwifi dm_thin_pool snd_soc_core kvm cfg80211 dm_persistent_data hid_generic wmi_bmof r8169 cec snd_compress dm_bio_prison ac97_bus dm_bufio raid6_pq realtek snd_pcm_dmaengine mdio_devres libcrc32c [ 10.549474] snd_pcm bridge rc_core of_mdio snd_timer fixed_phy irqbypass syscopyarea libphy sp5100_tco snd rapl sysfillrect drm k10temp pcspkr i2c_piix4 rfkill sysimgblt usbhid soundcore fb_sys_fops wmi tpm_tis tpm_tis_core evdev acpi_cpufreq stp pinctrl_amd gpio_amdpt mac_hid llc fuse pkcs8_key_parser nct6683 msr crypto_user agpgart ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys trusted uas usb_storage dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel xhci_pci ghash_clmulni_intel xhci_pci_renesas aesni_intel xhci_hcd ccp crypto_simd cryptd glue_helper tpm_crb tpm rng_core hid_lenovo hid vfat fat [ 10.549541] CPU: 5 PID: 430 Comm: systemd-udevd Not tainted 5.11.0-rc7-00084-g291009f656e8-dirty #120 [ 10.549543] Hardware name: Micro-Star International Co., Ltd. MS-7C94/MAG B550M MORTAR WIFI (MS-7C94), BIOS 1.20 08/03/2020 [ 10.549545] RIP: 0010:rn_clk_mgr_construct+0x2dd/0x440 [amdgpu] [ 10.549731] Code: ff ff b8 03 00 00 00 41 8b 8c c5 80 00 00 00 41 89 c1 89 c7 85 c9 74 0c 41 8b 94 c5 84 00 00 00 85 d2 75 75 48 83 e8 01 73 dd <0f> 0b e9 31 fe ff ff 48 c7 c6 e0 c1 77 c1 b9 14 00 00 00 48 89 c7 [ 10.549733] RSP: 0018:acf40175f638 EFLAGS: 00010297 [ 10.549734] RAX: RBX: a2391cea43c0 RCX: 0640 [ 10.549735] RDX: RSI: acf40175f660 RDI: [ 10.549736] RBP: a238c5579000 R08: R09: [ 10.549737] R10: 7fc9117f R11: a238d11a6000 R12: a2391cea4e40 [ 10.549738] R13: acf40175f660 R14: a2391b39 R15: fff0 [ 10.549740] FS: 7f33d7799ec0() GS:a23faf34() knlGS: [ 10.549741] CS: 0010 DS: ES: CR0: 80050033 [ 10.549742] CR2: 561d9f864070 CR3: 000111c0a000 CR4: 00350ee0 [ 10.549744] Call Trace: [ 10.549750] dc_clk_mgr_create+0x178/0x260 [amdgpu] [ 10.549893] dc_create+0x253/0x810 [amdgpu] [ 10.550035] ? amdgpu_cgs_create_device+0x23/0x50 [amdgpu] [ 10.550167] ? kmem_cache_alloc_trace+0x150/0x290 [ 10.550171] amdgpu_dm_init.isra.0+0x1c6/0x260 [amdgpu] [ 10.550313] ? wake_up_klogd.part.0+0x4f/0x70 [ 10.550316] ? vprintk_emit+0xcb/0x1b0 [ 10.550319] dm_hw_init+0xe/0x20 [amdgpu] [ 10.550458] amdgpu_device_init.cold+0x1741/0x1aad [amdgpu] [ 10.550602] amdgpu_driver_load_kms+0x64/0x270 [amdgpu] [ 10.550718] amdgpu_pci_prob
Re: [Intel-gfx] [PATCH v5 4/4] drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos
On Wed, Feb 10, 2021 at 10:23:58PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 09, 2021 at 04:28:31PM -0500, Lyude Paul wrote:
> > Apparently the new gen9_bc platforms that Intel has introduced don't
> > provide us with a STRAP config register to read from for initializing DDI
> > B, C, and D detection. So, workaround this by hard-coding our strap config
> > in intel_setup_outputs().
> >
> > Changes since v4:
> > * Split this into it's own commit
> >
> > Cc: Matt Roper
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > [originally from Tejas's work]
> > Signed-off-by: Tejas Upadhyay
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index beed08c00b6c..4dee37f8659d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -11943,7 +11943,14 @@ static void intel_setup_outputs(struct
> > drm_i915_private *dev_priv)
> >
> > /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
> > * register */
> > - found = intel_de_read(dev_priv, SFUSE_STRAP);
> > + if (HAS_PCH_TGP(dev_priv)) {
> > + /* W/A due to lack of STRAP config on TGP PCH*/
> > + found = (SFUSE_STRAP_DDIB_DETECTED |
> > +SFUSE_STRAP_DDIC_DETECTED |
> > +SFUSE_STRAP_DDID_DETECTED);
>
> we have somewhere in this function these forced fuse straps for gen9
> platform...
> don't we have a ways to combine them?
>
> Afterall, the reason that we need these forced bits is
> because it is a gen9, not because it is a TGP...
just ignore my non-sense comment... I confused with the
/* WaIgnoreDDIAStrap: skl */
above...
thought it was for all the ports... not just for port A...
Reviewed-by: Rodrigo Vivi
>
> > + } else {
> > + found = intel_de_read(dev_priv, SFUSE_STRAP);
> > + }
> >
> > if (found & SFUSE_STRAP_DDIB_DETECTED)
> > intel_ddi_init(dev_priv, PORT_B);
> > --
> > 2.29.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.
(JFYI I have seen this email, but haven't gotten a chance to actually read
through it yet. I should have the time to do so tomorrow)
On Thu, 2021-02-11 at 06:56 +, Almahallawy, Khaled wrote:
> On Wed, 2021-02-10 at 13:03 -0500, Lyude Paul wrote:
> > On Wed, 2021-02-10 at 00:33 -0800, Khaled Almahallawy wrote:
> > > The number of AUX retries specified in the DP specs is 7.
> > > Currently, to make
> > > Dell 4k monitors happier, the number of retries are 32.
> > > i915 also retries 5 times (intel_dp_aux_xfer) which means in the
> > > case of AUX
> > > timeout we actually retries 32 * 5 = 160 times.
> >
> > Is there any good reason for i915 to actually be doing retries
> > itself? It seems
> > like an easier solution here might just to be to fix i915 so it
> > doesn't retry,
> > and just rely on DRM to do the retries as appropriate.
> >
> > That being said though, I'm open to this if there is a legitimate
> > reason for
> > i915 to be handling retries on its own
>
> i915 or others may benefit from controlling AUX retries to optimize and
> minimize timing spent on the aux transactions.
>
> drm_dpcd_access handles multiple aux retries cases the same way (retry
> 32 times at worst case). The 4 cases are:
> 1- *AUX receive or IO error*. I believe it is up to specific
> implementation/HW once it detects a receive error to retry based on
> their internal understanding using the timeout appropriate to the HW
> capabilities.
>
> 2- *AUX Timeout* As the driver follows the specs for the recommended
> timeout timer as defined in section (2.11.2 AUX Transaction
> Response/Reply Timeouts), the driver has more intelligence to know how
> many retries it needs. This is more useful in case of DP-ALT if some
> issues happen in Type-C stack that cause AUX timeout (e.g. USB3 dock
> detected as high speed (USB2) causing SBU/AUX lines to be disabled).
> Also the disconnect of MST hub/docks is dependent how fast a userspace
> disconnect all MST connectors. Not all user spaces do it as fast like
> Chrome (ubuntu is an example):
> https://chromium-review.googlesource.com/c/chromium/src/+/2512550/
>
> 3- *AUX_NACK* DP spec mentions retry 3 times for NACK(2.16.1.3 GTC Lock
> Acquisition). However, sometimes we really don’t need any retry for
> NACK, if DPRX replied AUX_NACK for DPCD that it doesn’t support (e.g.
> reading LTTPR Capability and ID Field at DPCD Fh ~ F0007).
>
> 4- *AUX_DEFER* The specs stated we may retry 7 times on AUX_DEFER
> (3.5.1.2.3 LANEx_CHANNEL_EQ_DONE Sequence) and may terminate LT. Also
> with the increased usage of USB4, TBT/Type-C Docks/Displays, and active
> cables, the use of LTTPR becomes common which adds more challenge
> especially if we have multiple LTTPRs and all operate in non-LTTPR
> mode. In this case all LTTPRs will reply AUX_DEFER in 300us if it did
> not receive any aux response from other LTTPRs and DPRX. The SCR states
> we need to retry 7 times and not more than 50ms (DP v2.0 SCR on 8b/10b
> DPTX and LTTPR Requirements Update to Section 3.6)
>
> In addition I believe this function is not correct in treating
> AUX_DEFER and AUX_NACK as -EIO. Especially for AUX_DEFER, it is a valid
> 1 byte response that can provide a valuable debugging information
> especially in the case of on-board LTTPR where there is no way to
> capture this AUX response between the SoC and LTTPR unless you solder
> two wires on AUX_P and AUX_N lines and use i2c/aux analyzer to decode.
> At least we should provide the same debug information as we do in
> drm_dp_i2c_do_msg by printing AUX_DEFER and AUX_NACK.
>
> Thank you for your feedback and review.
>
> --Khaled
> >
> > > So making the number of aux retires a variable to allow for fine
> > > tuning and
> > > optimization of aux timing.
> > >
> > > Signed-off-by: Khaled Almahallawy
> > > ---
> > > drivers/gpu/drm/drm_dp_helper.c | 10 +++---
> > > include/drm/drm_dp_helper.h | 1 +
> > > 2 files changed, 4 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index eedbb48815b7..8fdf57b4a06c 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -249,13 +249,7 @@ static int drm_dp_dpcd_access(struct
> > > drm_dp_aux *aux, u8
> > > request,
> > >
> > > mutex_lock(&aux->hw_mutex);
> > >
> > > - /*
> > > - * The specification doesn't give any recommendation on how
> > > often to
> > > - * retry native transactions. We used to retry 7 times like
> > > for
> > > - * aux i2c transactions but real world devices this wasn't
> > > - * sufficient, bump to 32 which makes Dell 4k monitors
> > > happier.
> > > - */
> > > - for (retry = 0; retry < 32; retry++) {
> > > + for (retry = 0; retry < aux->num_retries; retry++) {
> > > if (ret != 0 && ret != -ETIMEDOUT) {
> > > usleep_range(AUX_RETRY_INTERVAL,
> > >
Re: [PATCH v3 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
Quoting Jernej Skrabec (2021-02-09 09:58:56)
> CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> one. Fix that.
>
> Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> allowed")
> Reviewed-by: Chen-Yu Tsai
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
> ---
Ok, Applied to clk-fixes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[no subject]
Hi Linus, Regular fixes for final, there is a ttm regression fix, dp-mst fix, one amdgpu revert, two i915 fixes, and some misc fixes for sun4i, xlnx, and vc4. All pretty quiet and don't think we have any known outstanding regressions. Dave. drm-fixes-2021-02-12: drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-12 for you to fetch changes up to 551c81853d6d3ff016269d62612e7cd0a53104ab: Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-02-12 13:38:51 +1000) drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak Alex Deucher (1): Revert "drm/amd/display: Update NV1x SR latency values" Christian König (1): drm/ttm: make sure pool pages are cleared Dave Airlie (3): Merge tag 'amd-drm-fixes-5.11-2021-02-10' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-02-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Imre Deak (2): drm/dp_mst: Don't report ports connected if nothing is attached to them drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it Jernej Skrabec (4): drm/sun4i: tcon: set sync polarity for tcon1 channel drm/sun4i: dw-hdmi: always set clock rate drm/sun4i: Fix H6 HDMI PHY configuration drm/sun4i: dw-hdmi: Fix max. frequency for H6 Maxime Ripard (1): drm/vc4: hvs: Fix buffer overflow with the dlist handling Quanyang Wang (1): drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable Ville Syrjälä (1): drm/i915: Fix overlay frontbuffer tracking .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 +- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/i915/display/intel_overlay.c | 17 +++--- drivers/gpu/drm/i915/display/intel_tc.c| 67 -- drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 ++ drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 10 +--- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 - drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +++-- drivers/gpu/drm/ttm/ttm_pool.c | 10 drivers/gpu/drm/vc4/vc4_plane.c| 18 -- drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++-- 12 files changed, 122 insertions(+), 78 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.11 final
(resent with a subject this time) Hi Linus, Regular fixes for final, there is a ttm regression fix, dp-mst fix, one amdgpu revert, two i915 fixes, and some misc fixes for sun4i, xlnx, and vc4. All pretty quiet and don't think we have any known outstanding regressions. Dave. drm-fixes-2021-02-12: drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-12 for you to fetch changes up to 551c81853d6d3ff016269d62612e7cd0a53104ab: Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-02-12 13:38:51 +1000) drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak Alex Deucher (1): Revert "drm/amd/display: Update NV1x SR latency values" Christian König (1): drm/ttm: make sure pool pages are cleared Dave Airlie (3): Merge tag 'amd-drm-fixes-5.11-2021-02-10' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-02-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Imre Deak (2): drm/dp_mst: Don't report ports connected if nothing is attached to them drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it Jernej Skrabec (4): drm/sun4i: tcon: set sync polarity for tcon1 channel drm/sun4i: dw-hdmi: always set clock rate drm/sun4i: Fix H6 HDMI PHY configuration drm/sun4i: dw-hdmi: Fix max. frequency for H6 Maxime Ripard (1): drm/vc4: hvs: Fix buffer overflow with the dlist handling Quanyang Wang (1): drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable Ville Syrjälä (1): drm/i915: Fix overlay frontbuffer tracking .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 +- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/i915/display/intel_overlay.c | 17 +++--- drivers/gpu/drm/i915/display/intel_tc.c| 67 -- drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 ++ drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 10 +--- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 - drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +++-- drivers/gpu/drm/ttm/ttm_pool.c | 10 drivers/gpu/drm/vc4/vc4_plane.c| 18 -- drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++-- 12 files changed, 122 insertions(+), 78 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Thu, Feb 11, 2021 at 11:44 AM Simon Ser wrote: > On Wednesday, February 10th, 2021 at 11:02 PM, Mario Kleiner < > mario.kleiner...@gmail.com> wrote: > > > I'll prepare patches with the same fix for libdrm and igt as well soon. > > Please don't submit patches for drm_fourcc.h to downstream if they vendor > the > whole file. Instead, update it from the kernel once your patch is merged to > drm-next. For instance, see [1] for libdrm. > > Simon > > [1]: > https://gitlab.freedesktop.org/mesa/drm/-/blob/master/include/drm/README > Ok. Thanks for the info, -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amdkfd: Cleanup kfd_process if init_cwsr_apu fails
If init_cwsr_apu fails, we currently leave the kfd_process structure in
place anyway. The next kfd_open will then succeed, using the existing
kfd_process structure. Fix that by cleaning up the kfd_process after a
failure in init_cwsr_apu.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 145cd0a17d50..a4d7682289bb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -775,10 +775,8 @@ struct kfd_process *kfd_create_process(struct file *filep)
goto out;
ret = kfd_process_init_cwsr_apu(process, filep);
- if (ret) {
- process = ERR_PTR(ret);
- goto out;
- }
+ if (ret)
+ goto out_destroy;
if (!procfs.kobj)
goto out;
@@ -826,6 +824,14 @@ struct kfd_process *kfd_create_process(struct file *filep)
mutex_unlock(&kfd_processes_mutex);
return process;
+
+out_destroy:
+ hash_del_rcu(&process->kfd_processes);
+ mutex_unlock(&kfd_processes_mutex);
+ synchronize_srcu(&kfd_processes_srcu);
+ /* kfd_process_free_notifier will trigger the cleanup */
+ mmu_notifier_put(&process->mmu_notifier);
+ return ERR_PTR(ret);
}
struct kfd_process *kfd_get_process(const struct task_struct *thread)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amdkfd: Use mmu_notifier_get
We use mmu_notifier_put to free the MMU notifier. That needs to be
paired with mmu_notifier_get to work correctly. Othewrise the next patch
would cause a kernel oops.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 33 +++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 2807e1c4d59b..145cd0a17d50 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -1011,6 +1011,16 @@ static void kfd_process_ref_release(struct kref *ref)
queue_work(kfd_process_wq, &p->release_work);
}
+static struct mmu_notifier *kfd_process_alloc_notifier(struct mm_struct *mm)
+{
+ int idx = srcu_read_lock(&kfd_processes_srcu);
+ struct kfd_process *p = find_process_by_mm(mm);
+
+ srcu_read_unlock(&kfd_processes_srcu, idx);
+
+ return p ? &p->mmu_notifier : ERR_PTR(-ESRCH);
+}
+
static void kfd_process_free_notifier(struct mmu_notifier *mn)
{
kfd_unref_process(container_of(mn, struct kfd_process, mmu_notifier));
@@ -1075,6 +1085,7 @@ static void kfd_process_notifier_release(struct
mmu_notifier *mn,
static const struct mmu_notifier_ops kfd_process_mmu_notifier_ops = {
.release = kfd_process_notifier_release,
+ .alloc_notifier = kfd_process_alloc_notifier,
.free_notifier = kfd_process_free_notifier,
};
@@ -1152,6 +1163,7 @@ static int kfd_process_device_init_cwsr_dgpu(struct
kfd_process_device *pdd)
static struct kfd_process *create_process(const struct task_struct *thread)
{
struct kfd_process *process;
+ struct mmu_notifier *mn;
int err = -ENOMEM;
process = kzalloc(sizeof(*process), GFP_KERNEL);
@@ -1182,19 +1194,28 @@ static struct kfd_process *create_process(const struct
task_struct *thread)
if (err != 0)
goto err_init_apertures;
- /* Must be last, have to use release destruction after this */
- process->mmu_notifier.ops = &kfd_process_mmu_notifier_ops;
- err = mmu_notifier_register(&process->mmu_notifier, process->mm);
- if (err)
+ /* alloc_notifier needs to find the process in the hash table */
+ hash_add_rcu(kfd_processes_table, &process->kfd_processes,
+ (uintptr_t)process->mm);
+
+ /* MMU notifier registration must be the last call that can fail
+* because after this point we cannot unwind the process creation.
+* After this point, mmu_notifier_put will trigger the cleanup by
+* dropping the last process reference in the free_notifier.
+*/
+ mn = mmu_notifier_get(&kfd_process_mmu_notifier_ops, process->mm);
+ if (IS_ERR(mn)) {
+ err = PTR_ERR(mn);
goto err_register_notifier;
+ }
+ BUG_ON(mn != &process->mmu_notifier);
get_task_struct(process->lead_thread);
- hash_add_rcu(kfd_processes_table, &process->kfd_processes,
- (uintptr_t)process->mm);
return process;
err_register_notifier:
+ hash_del_rcu(&process->kfd_processes);
kfd_process_free_outstanding_kfd_bos(process);
kfd_process_destroy_pdds(process);
err_init_apertures:
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tiny: add driver for newhaven,1.8-128160EF
Hi
thanks for the driver. I only have some minor comments
Am 11.02.21 um 10:50 schrieb Daniel Mack:
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
---
.../bindings/display/ilitek,ili9163.txt | 27 +++
drivers/gpu/drm/tiny/Kconfig | 13 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c| 224 ++
4 files changed, 265 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ilitek,ili9163.txt
create mode 100644 drivers/gpu/drm/tiny/ili9163.c
diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
new file mode 100644
index 0..fee119991c14e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9163 display panels
+
+This binding is for display panels using an Ilitek ILI9163 controller in SPI
+mode.
+
+Required properties:
+- compatible: "newhaven,1.8-128160EF", "ilitek,ili9163"
+- dc-gpios:D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+ display@0{
+ compatible = "newhaven,1.8-128160EF", "ilitek,ili9163"
+ reg = <0>;
+ spi-max-frequency = <3200>;
+ dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+ rotation = <270>;
+ backlight = <&backlight>;
+ };
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa759..9de0c0eeea6f5 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -41,6 +41,19 @@ config TINYDRM_HX8357D
If M is selected the module will be called hx8357d.
+config TINYDRM_ILI9163
+ tristate "DRM support for ILI9163 display panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9163 panels:
+ * NHD-1.8-128160EF 128x160 TFT
+
+ If M is selected the module will be called ili9163.
+
config TINYDRM_ILI9225
tristate "DRM support for ILI9225 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35fb..78016b2ed11b5 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -3,6 +3,7 @@
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320)+= gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
+obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
new file mode 100644
index 0..9f90ea9556c4d
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9163_FRMCTR10xb1
+
+#define ILI9163_PWCTRL10xc0
+#define ILI9163_PWCTRL20xc1
+#define ILI9163_VMCTRL10xc5
+#define ILI9163_VMCTRL20xc7
+#define ILI9163_PWCTRLA0xcb
+#define ILI9163_PWCTRLB0xcf
+
+#define ILI9163_EN3GAM 0xf2
+
+#define ILI9163_MADCTL_BGR BIT(3)
+#define ILI9163_MADCTL_MV BIT(5)
+#define ILI9163_MADCTL_MX BIT(6)
+#define ILI9163_MADCTL_MY BIT(7)
The indention is inconsistent. Or maybe it's just my email client.
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
We now use drm_debug_kms() and similar helpers.
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ /* Gam
Re: Proposed Changes to Elida-KD35T133 Panel Driver
Hi Am 11.02.21 um 18:51 schrieb Christopher Morgan: I'd like to make the following changes to this panel driver. The first patch is to add rotation support (rotates only the DRM connector at this time). The panel is currently rotated 270 degrees in the Odroid Go Advance, and this change allows us to describe that hardware better. The second patch just fixes a typo. The panel in question is 3.5 inches in size not 5.5 inches. The patches are attached as files. Could you re-send them as inline attachments? Best regards Thomas Thank you. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm: a6xx: Make sure the SQE microcode is safe
On 2/11/2021 9:32 PM, Jordan Crouse wrote:
On Thu, Feb 11, 2021 at 06:50:28PM +0530, Akhil P Oommen wrote:
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
v2: Add more informative error messages and fix typos
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 77 ++-
1 file changed, 64 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..064b7face504 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -522,28 +522,73 @@ static int a6xx_cp_init(struct msm_gpu *gpu)
return a6xx_idle(gpu, ring) ? 0 : -EINVAL;
}
-static void a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
+/*
+ * Check that the microcode version is new enough to include several key
+ * security fixes. Return true if the ucode is safe.
+ */
+static bool a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
struct drm_gem_object *obj)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
u32 *buf = msm_gem_get_vaddr(obj);
+ bool ret = false;
if (IS_ERR(buf))
- return;
+ return false;
/*
-* If the lowest nibble is 0xa that is an indication that this microcode
-* has been patched. The actual version is in dword [3] but we only care
-* about the patchlevel which is the lowest nibble of dword [3]
-*
-* Otherwise check that the firmware is greater than or equal to 1.90
-* which was the first version that had this fix built in
+* Targets up to a640 (a618, a630 and a640) need to check for a
+* microcode version that is patched to support the whereami opcode or
+* one that is new enough to include it by default.
*/
- if (((buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1)
- a6xx_gpu->has_whereami = true;
- else if ((buf[0] & 0xfff) > 0x190)
- a6xx_gpu->has_whereami = true;
+ if (adreno_is_a618(adreno_gpu) || adreno_is_a630(adreno_gpu) ||
+ adreno_is_a640(adreno_gpu)) {
nit: I feel a 'switch(revn)' would be more readable.
Reviewed-by: Akhil P Oommen
-Akhil
+ /*
+* If the lowest nibble is 0xa that is an indication that this
+* microcode has been patched. The actual version is in dword
+* [3] but we only care about the patchlevel which is the lowest
+* nibble of dword [3]
+*
+* Otherwise check that the firmware is greater than or equal
+* to 1.90 which was the first version that had this fix built
+* in
+*/
+ if buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1) ||
+ (buf[0] & 0xfff) >= 0x190) {
+ a6xx_gpu->has_whereami = true;
+ ret = true;
+ goto out;
+ }
+ DRM_DEV_ERROR(&gpu->pdev->dev,
+ "a630 SQE ucode is too old. Have version %x need at least
%x\n",
+ buf[0] & 0xfff, 0x190);
+ } else {
+ /*
+* a650 tier targets don't need whereami but still need to be
+* equal to or newer than 1.95 for other security fixes
+*/
+ if (adreno_is_a650(adreno_gpu)) {
+ if ((buf[0] & 0xfff) >= 0x195) {
+ ret = true;
+ goto out;
+ }
+
+ DRM_DEV_ERROR(&gpu->pdev->dev,
+ "a650 SQE ucode is too old. Have version %x need at
least %x\n",
+ buf[0] & 0xfff, 0x195);
+ }
+
+ /*
+* When a660 is added those targets should return true here
+* since those have all the critical security fixes built in
+* from the start
+*/
Or we can just initialize 'ret' as true.
I thought about it and I think I want to force an accept list here instead of
letting new targets get by with an implicit pass.
Jordan
-Akhil
+ }
+out:
msm_gem_put_vaddr(obj);
+ return ret;
}
static int a6xx_ucode_init(struct msm_gpu *gpu)
@@ -566,7 +611,13 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
}
msm_gem_object_set_name(a6xx_gpu->sqe_bo, "sqefw");
- a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo);
+ if (!a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo)) {
+
Re: Not 100% sure if I correctly fixed drm-tip
Am 11.02.21 um 18:22 schrieb Daniel Vetter:
On Thu, Feb 11, 2021 at 4:27 PM Christian König
wrote:
Am 11.02.21 um 16:02 schrieb Jani Nikula:
On Thu, 11 Feb 2021, Christian König wrote:
Hi guys,
I had a conflict this morning in the ttm pool while pushing an important
fix to drm-misc-fixes.
I'm not 100% sure if I correctly fixed up drm-tip. How can this be
double checked? And how can it be fixed if the merge has gone bad?
I'm afraid there's a problem; bb52cb0dec8d ("drm/ttm: make the pool
shrinker lock a mutex") in upstream and drm-misc-fixes creates a silent
conflict with ba051901d10f ("drm/ttm: add a debugfs file for the global
page pools") in drm-misc-next, causing the latter to use
spin_lock/unlock on a mutex.
But while you hit a conflict, it does look like the conflict breaking
the build is silent, AFAICT the spinlock part does not conflict. So a
fixup patch in drm-rerere is probably needed until there are some
backmerges.
Well exactly that's the issue. I've already had a fixup in drm-rerere
for this.
But today I've pushed another fix to drm-misc-fixes which also conflicts
with ba051901d10f ("drm/ttm: add a debugfs file for the global page pools").
I've fixed this up as well and committed the solution. But dim then
complained that the original fixup is now not applicable any more (which
is true as far as I know).
This somehow went away when I said that dim should assume patch
reversal, but I'm not sure if that's the right thing to do.
Nothing, it's all still broken. You need to delete the now unecessary
fixup. As a rule, when rebuilding drm-tip failed always try again to
confirm that what you've done actually fixed things (since sometimes
git can also not remember where to apply the resolution for some odd
reasons).
My question is how to I remove the fixup now?
E.g. where can I find it?
Thanks,
Christian.
I'm fixing this now.
-Daniel
Thanks,
Christian.
BR,
Jani.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
