[Bug 107784] [AMD tahiti XT] displayport broken
https://bugs.freedesktop.org/show_bug.cgi?id=107784 --- Comment #25 from Dmitrii Tcvetkov --- The fix for TSC is merged: 17f6bac2249356c795 (x86/tsc: Prevent result truncation on 32bit) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 0/5] Fix A64 HDMI PHY device tree binding
On Fri, Sep 7, 2018 at 3:22 PM Icenowy Zheng wrote: > > When adding support for A64 HDMI PHY in 4.19, we assumed that the two > PLL-VIDEOs can both feed the HDMI PHY clock. However experiments show > that the mux bit discovered in R40 blob is not applicable on A64. This > is not discovered, as normally with a single display pipeline only > PLL-VIDEO0 will be used. > > In this patchset the second PLL is dropped, and a binding specially for > R40 HDMI PHY is added (which seems to have the mux). > > PATCH 1 and 2 are dropping second PLL for A64 HDMI PHY, and PATCH 3 to 5 > are adding R40 HDMI PHY binding. > > This patchset targets v4.19 fixes tree, because the binding is > introduced in v4.19, and if we don't fix it there a wrong binding will > be left in a stable version released. Please add fixes tags. The patches look good, though I'm not sure about patches 3 and 4 going in fixes. ChenYu > Icenowy Zheng (5): > dt-bindings: sun4i-drm: drop second PLL from A64 HDMI PHY binding > drm: sun4i: drop second PLL from A64 HDMI PHY > dt-bindings: sun4i-drm: add compatible for R40 HDMI PHY > drm/sun4i: add support for R40 HDMI PHY > ARM: sun8i: dts: drop A64 HDMI PHY fallback compatible from R40 DT > > .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 +++-- > arch/arm/boot/dts/sun8i-r40.dtsi| 3 +-- > drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 13 - > 3 files changed, 16 insertions(+), 5 deletions(-) > > -- > 2.18.0 > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930
https://bugs.freedesktop.org/show_bug.cgi?id=105760 --- Comment #66 from Daniel Drake --- (In reply to Thomas Martitz from comment #65) > https://patchwork.kernel.org/patch/10583229/ (modified such that the quirk > is applied unconditionally) fixes GPU resume on my laptop as well. I think > it's got the same PCIe bridge as the ASUS machines mentioned in that post. Thanks for testing! That issue is now being tracked at https://bugzilla.kernel.org/show_bug.cgi?id=201069 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102962] GPU crash running Overwatch in wine-staging
https://bugs.freedesktop.org/show_bug.cgi?id=102962 --- Comment #15 from Tobias Auerochs --- (In reply to Timothy Arceri from comment #13) > (In reply to Tobias Auerochs from comment #12) > > (In reply to Timothy Arceri from comment #11) > > > (In reply to gloriouseggroll from comment #9) > > > > Created attachment 138466 [details] > > > > broken colors with mesa override > > > > > > > > This was originally able to be resolved using > > > > MESA_GL_VERSION_OVERRIDE=4.0COMPAT, however commit > > > > 72de747c6a6cdd0be84a24932a4452f453861dbe broke that functionality, so > > > > that > > > > MESA-GL_VERSION_OVERRIDE no longer renders properly, at least on my > > > > system. > > > > See attached. > > > > > > radeonsi now has compat 4.4 enabled by default (in git and upcoming 18.2 > > > release). Does the game now work for you with a recent Mesa from git? > > > > Tried launching the game with mesa-git 103535.88e56804a7 (unofficial Arch > > repo), rendering in menus (including backgrounds) worked correctly, however > > the system still hangs the same way as before (e.g. when selecting > > Symmetra). > > Picked the game up as part of Humble bundle, I seem to be able to select > Symmetra without any freeze. Is this still happening for you? Tested using mesa 18.2.0 (Arch testing repository) without any mesa overrides and still froze (on second attempt selection worked, but right click shot still froze). Specifically I was also using wine-staging 3.15, llvm 6.0.1 and a customized linux 4.18.3 kernel, maybe newer llvm yields better results (have not gotten around to testing that). Interestingly I am able to run the game perfectly stable when dxvk is installed (and radv), aside from the expected poor-ish performance. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103300] Tear rendering bug in Bioshock Infinite
https://bugs.freedesktop.org/show_bug.cgi?id=103300 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Timothy Arceri --- Hi Ian, Is this still a problem with a recent version of Mesa? If so do you think you could get an apitrace [1] of the problem? [1] https://github.com/apitrace/apitrace/wiki/Steam -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104906] Mesa crashes randomly during Youtube playback
https://bugs.freedesktop.org/show_bug.cgi?id=104906 --- Comment #2 from rhodichelic...@aol.com --- Honestly, could not say. In the time between submittal and now, I've built and started using a new computer with a new graphics card. Feel free to close, I haven't had the issue with the new setup. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/13] drm/mediatek: separae hdmi phy to different file
Hi, Bibby:
On Wed, 2018-09-05 at 16:31 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> Different IC has different phy setting of HDMI.
> This patch separaes the phy hardware relate part for mt8173.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/Makefile | 15 +--
> drivers/gpu/drm/mediatek/mtk_hdmi.c| 30 +++--
> drivers/gpu/drm/mediatek/mtk_hdmi.h| 26 +
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 154
> +
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 129 ++---
> 5 files changed, 216 insertions(+), 138 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index ce83c396a742..7f947979d68f 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -1,4 +1,12 @@
> # SPDX-License-Identifier: GPL-2.0
> +mediatek-drm-hdmi-objs := mtk_cec.o \
> + mtk_hdmi.o \
> + mtk_hdmi_ddc.o \
> + mtk_mt8173_hdmi_phy.o \
> + mtk_hdmi_phy.o
> +
> +obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> +
It looks like you just want to add mtk_hdmi_phy.o, I think you need not
to move mediatek-drm-hdmi-objs.
> mediatek-drm-y := mtk_disp_color.o \
> mtk_disp_ovl.o \
> mtk_disp_rdma.o \
> @@ -14,10 +22,3 @@ mediatek-drm-y := mtk_disp_color.o \
> mtk_dpi.o
>
> obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
> -
> -mediatek-drm-hdmi-objs := mtk_cec.o \
> - mtk_hdmi.o \
> - mtk_hdmi_ddc.o \
> - mtk_mt8173_hdmi_phy.o
> -
> -obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 2d45d1dd9554..7c022f3f53ec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -233,6 +233,7 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi,
> bool black)
> static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
> {
> struct arm_smccc_res res;
> + struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
>
> /*
>* MT8173 HDMI hardware has an output control bit to enable/disable HDMI
> @@ -240,8 +241,13 @@ static void mtk_hdmi_hw_make_reg_writable(struct
> mtk_hdmi *hdmi, bool enable)
>* The ARM trusted firmware provides an API for the HDMI driver to set
>* this control bit to enable HDMI output in supervisor mode.
>*/
> - arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904, 0x8000,
> - 0, 0, 0, 0, 0, );
> + if (hdmi_phy->conf && hdmi_phy->conf->tz_enabled)
> + arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
> + 0x8000, 0, 0, 0, 0, 0, );
> + else
> + regmap_update_bits(hdmi->sys_regmap,
> +hdmi->sys_offset + HDMI_SYS_CFG20,
> +0x80008005, enable ? 0x8005 : 0x8000);
I think this should be moved to 'drm/mediatek: add hdmi driver for
MT2701 and MT7623'. If you change the variable name to tz_disabled, you
could modify this in just one patch.
>
> regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
> HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
> @@ -1437,6 +1443,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi
> *hdmi,
> struct platform_device *cec_pdev;
> struct regmap *regmap;
> struct resource *mem;
> + const char *phy_name;
> int ret;
>
> ret = mtk_hdmi_get_all_clk(hdmi, np);
> @@ -1445,6 +1452,18 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi
> *hdmi,
> return ret;
> }
>
> + ret = of_property_read_string(np, "phy-names", _name);
> + if (ret < 0) {
> + dev_err(dev, "Failed to read phy-names: %d\n", ret);
> + return ret;
> + }
> + hdmi->phy = devm_phy_get(dev, phy_name);
> + if (IS_ERR(hdmi->phy)) {
> + ret = PTR_ERR(hdmi->phy);
> + dev_err(dev, "Failed to get HDMI PHY: %d\n", ret);
> + return ret;
> + }
> +
I think this part is not related to 'separate hdmi phy to different
file' and I don't know why you do this? If you really need this,
separate this to an independent patch and describe why you do this.
Regards,
CK
> /* The CEC module handles HDMI hotplug detection */
> cec_np = of_find_compatible_node(np->parent, NULL,
>"mediatek,mt8173-cec");
> @@ -1677,13 +1696,6 @@ static int mtk_drm_hdmi_probe(struct platform_device
> *pdev)
> if (ret)
> return ret;
>
> - hdmi->phy =
Re: [PATCH 19/20] drm/zte: Use drm_fbdev_generic_setup()
On Sat, Sep 08, 2018 at 03:46:47PM +0200, Noralf Trønnes wrote: > The CMA helper is already using the drm_fb_helper_generic_probe part of > the generic fbdev emulation. This patch makes full use of the generic > fbdev emulation by using its drm_client callbacks. This means that > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > now handled by the emulation code. Additionally fbdev unregister happens > automatically on drm_dev_unregister(). > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > driver. This is done to highlight the fact that fbdev emulation is an > internal client that makes use of the driver, it is not part of the > driver as such. If fbdev setup fails, an error is printed, but the driver > succeeds probing. > > Cc: Shawn Guo > Signed-off-by: Noralf Trønnes Acked-by: Shawn Guo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] gpu/radeon: use HMM mirror instead of mmu_notifier
From: Jérôme Glisse
HMM provide a sets of helpers to avoid individual drivers re-doing
their own. This patch convert the radeon to use HMM mirror to track
CPU page table update and invalidate accordingly for userptr object.
Signed-off-by: Jérôme Glisse
Cc: dri-devel@lists.freedesktop.org
Cc: Alex Deucher
Cc: Christian König
Cc: Felix Kuehling
Cc: David (ChunMing) Zhou
Cc: Nicolai Hähnle
Cc: amd-...@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_mn.c | 126 ++---
1 file changed, 63 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
b/drivers/gpu/drm/radeon/radeon_mn.c
index f8b35df44c60..a3bf74c1a3fc 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -30,7 +30,7 @@
#include
#include
-#include
+#include
#include
#include
@@ -40,7 +40,7 @@ struct radeon_mn {
/* constant after initialisation */
struct radeon_device*rdev;
struct mm_struct*mm;
- struct mmu_notifier mn;
+ struct hmm_mirror mirror;
/* only used on destruction */
struct work_struct work;
@@ -87,72 +87,67 @@ static void radeon_mn_destroy(struct work_struct *work)
}
mutex_unlock(>lock);
mutex_unlock(>mn_lock);
- mmu_notifier_unregister(>mn, rmn->mm);
+ hmm_mirror_unregister(>mirror);
kfree(rmn);
}
/**
* radeon_mn_release - callback to notify about mm destruction
*
- * @mn: our notifier
- * @mn: the mm this callback is about
+ * @mirror: our mirror struct
*
* Shedule a work item to lazy destroy our notifier.
*/
-static void radeon_mn_release(struct mmu_notifier *mn,
- struct mm_struct *mm)
+static void radeon_mirror_release(struct hmm_mirror *mirror)
{
- struct radeon_mn *rmn = container_of(mn, struct radeon_mn, mn);
+ struct radeon_mn *rmn = container_of(mirror, struct radeon_mn, mirror);
INIT_WORK(>work, radeon_mn_destroy);
schedule_work(>work);
}
/**
- * radeon_mn_invalidate_range_start - callback to notify about mm change
+ * radeon_sync_cpu_device_pagetables - callback to synchronize with mm changes
*
- * @mn: our notifier
- * @mn: the mm this callback is about
- * @start: start of updated range
- * @end: end of updated range
+ * @mirror: our HMM mirror
+ * @update: update informations (start, end, event, blockable, ...)
*
- * We block for all BOs between start and end to be idle and
- * unmap them by move them into system domain again.
+ * We block for all BOs between start and end to be idle and unmap them by
+ * moving them into system domain again (trigger a call to ttm_backend_func.
+ * unbind see radeon_ttm.c).
*/
-static int radeon_mn_invalidate_range_start(struct mmu_notifier *mn,
-struct mm_struct *mm,
-unsigned long start,
-unsigned long end,
-bool blockable)
+static int radeon_sync_cpu_device_pagetables(struct hmm_mirror *mirror,
+const struct hmm_update *update)
{
- struct radeon_mn *rmn = container_of(mn, struct radeon_mn, mn);
+ struct radeon_mn *rmn = container_of(mirror, struct radeon_mn, mirror);
struct ttm_operation_ctx ctx = { false, false };
struct interval_tree_node *it;
+ unsigned long end;
int ret = 0;
/* notification is exclusive, but interval is inclusive */
- end -= 1;
+ end = update->end - 1;
/* TODO we should be able to split locking for interval tree and
* the tear down.
*/
- if (blockable)
+ if (update->blockable)
mutex_lock(>lock);
else if (!mutex_trylock(>lock))
return -EAGAIN;
- it = interval_tree_iter_first(>objects, start, end);
+ it = interval_tree_iter_first(>objects, update->start, end);
while (it) {
struct radeon_mn_node *node;
struct radeon_bo *bo;
long r;
- if (!blockable) {
+ if (!update->blockable) {
ret = -EAGAIN;
goto out_unlock;
}
node = container_of(it, struct radeon_mn_node, it);
- it = interval_tree_iter_next(it, start, end);
+ it = interval_tree_iter_next(it, update->start, end);
list_for_each_entry(bo, >bos, mn_list) {
@@ -178,16 +173,16 @@ static int radeon_mn_invalidate_range_start(struct
mmu_notifier *mn,
radeon_bo_unreserve(bo);
}
}
-
+
out_unlock:
mutex_unlock(>lock);
return ret;
}
-static const struct mmu_notifier_ops radeon_mn_ops = {
- .release =
[PATCH 2/2] gpu/radeon: use HMM mirror for userptr buffer object.
From: Jérôme Glisse
This replace existing code that rely on get_user_page() aka GUP with
code that now use HMM mirror to mirror a range of virtual address as
a buffer object accessible by the GPU. There is no functional changes
from userspace point of view.
From kernel point of view we no longer pin pages for userptr buffer
object which is a welcome change (i am assuming that everyone dislike
page pin as i do).
Signed-off-by: Jérôme Glisse
Cc: dri-devel@lists.freedesktop.org
Cc: Alex Deucher
Cc: Christian König
Cc: Felix Kuehling
Cc: David (ChunMing) Zhou
Cc: Nicolai Hähnle
Cc: amd-...@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 14 ++-
drivers/gpu/drm/radeon/radeon_gem.c | 16 +--
drivers/gpu/drm/radeon/radeon_mn.c | 157 +++-
drivers/gpu/drm/radeon/radeon_ttm.c | 129 +++
4 files changed, 196 insertions(+), 120 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1a6f6edb3515..6c83bf911e9c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -514,6 +514,8 @@ struct radeon_bo {
pid_t pid;
struct radeon_mn*mn;
+ uint64_t*pfns;
+ unsigned long userptr;
struct list_headmn_list;
};
#define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, gem_base)
@@ -1787,12 +1789,22 @@ void radeon_test_syncing(struct radeon_device *rdev);
#if defined(CONFIG_MMU_NOTIFIER)
int radeon_mn_register(struct radeon_bo *bo, unsigned long addr);
void radeon_mn_unregister(struct radeon_bo *bo);
+int radeon_mn_bo_map(struct radeon_bo *bo, struct ttm_dma_tt *dma, bool write);
+void radeon_mn_bo_unmap(struct radeon_bo *bo, struct ttm_dma_tt *dma,
+ bool write);
#else
static inline int radeon_mn_register(struct radeon_bo *bo, unsigned long addr)
{
return -ENODEV;
}
static inline void radeon_mn_unregister(struct radeon_bo *bo) {}
+static int radeon_mn_bo_map(struct radeon_bo *bo, struct ttm_dma_tt *dma,
+ bool write)
+{
+ return -ENODEV;
+}
+static void radeon_mn_bo_unmap(struct radeon_bo *bo, struct ttm_dma_tt *dma,
+ bool write) {}
#endif
/*
@@ -2818,7 +2830,7 @@ extern void radeon_legacy_set_clock_gating(struct
radeon_device *rdev, int enabl
extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int
enable);
extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain);
extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
-extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
+extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, struct radeon_bo *bo,
uint32_t flags);
extern bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm);
extern bool radeon_ttm_tt_is_readonly(struct ttm_tt *ttm);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 27d8e7dd2d06..b489025086c4 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -323,15 +323,19 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
goto handle_lockup;
bo = gem_to_radeon_bo(gobj);
- r = radeon_ttm_tt_set_userptr(bo->tbo.ttm, args->addr, args->flags);
+
+ /*
+* Always register an HMM mirror (if one is not already registered).
+* This means ignoring RADEON_GEM_USERPTR_REGISTER flag but that flag
+* is already made mandatory by flags sanity check above.
+*/
+ r = radeon_mn_register(bo, args->addr);
if (r)
goto release_object;
- if (args->flags & RADEON_GEM_USERPTR_REGISTER) {
- r = radeon_mn_register(bo, args->addr);
- if (r)
- goto release_object;
- }
+ r = radeon_ttm_tt_set_userptr(bo->tbo.ttm, bo, args->flags);
+ if (r)
+ goto release_object;
if (args->flags & RADEON_GEM_USERPTR_VALIDATE) {
down_read(>mm->mmap_sem);
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
b/drivers/gpu/drm/radeon/radeon_mn.c
index a3bf74c1a3fc..ff53ffa5deef 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -262,9 +262,18 @@ int radeon_mn_register(struct radeon_bo *bo, unsigned long
addr)
struct list_head bos;
struct interval_tree_node *it;
+ bo->userptr = addr;
+ bo->pfns = kvmalloc_array(bo->tbo.num_pages, sizeof(uint64_t),
+ GFP_KERNEL | __GFP_ZERO);
+ if (bo->pfns == NULL)
+ return -ENOMEM;
+
rmn = radeon_mn_get(rdev);
- if (IS_ERR(rmn))
+ if (IS_ERR(rmn)) {
+ kvfree(bo->pfns);
+
[PATCH 2/2] gpu/i915: use HMM mirror for userptr buffer object.
From: Jérôme Glisse
This replace existing code that rely on get_user_page() aka GUP with
code that now use HMM mirror to mirror a range of virtual address as
a buffer object accessible by the GPU. There is no functional changes
from userspace point of view.
From kernel point of view we no longer pin pages for userptr buffer
object which is a welcome change (i am assuming that everyone dislike
page pin as i do).
Another change, from kernel point of view, is that it does no longer
have a fast path with get_user_pages_fast() this can eventually added
back through HMM.
Signed-off-by: Jérôme Glisse
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Lionel Landwerlin
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 206
1 file changed, 102 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 5e09b654b5ad..378aab438ebd 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -464,7 +464,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
static int
__i915_gem_userptr_set_active(struct drm_i915_gem_object *obj,
- bool value)
+ struct hmm_range *range)
{
int ret = 0;
@@ -486,86 +486,120 @@ __i915_gem_userptr_set_active(struct drm_i915_gem_object
*obj,
/* In order to serialise get_pages with an outstanding
* cancel_userptr, we must drop the struct_mutex and try again.
*/
- if (!value)
+ if (range) {
+ if (!hmm_vma_range_done(range))
+ ret = -EAGAIN;
+ else
+ add_object(obj->userptr.mmu_object);
+ } else
del_object(obj->userptr.mmu_object);
- else if (!work_pending(>userptr.mmu_object->work))
- add_object(obj->userptr.mmu_object);
- else
- ret = -EAGAIN;
spin_unlock(>userptr.mmu_object->mirror->lock);
#endif
return ret;
}
-static void
-__i915_gem_userptr_get_pages_worker(struct work_struct *_work)
+static int
+i915_gem_userptr_map(struct drm_i915_gem_object *obj, bool try)
{
- struct get_pages_work *work = container_of(_work, typeof(*work), work);
- struct drm_i915_gem_object *obj = work->obj;
- const int npages = obj->base.size >> PAGE_SHIFT;
+#if defined(CONFIG_HMM_MIRROR)
+ static const uint64_t i915_range_flags[HMM_PFN_FLAG_MAX] = {
+ (1 << 0), /* HMM_PFN_VALID */
+ (1 << 1), /* HMM_PFN_WRITE */
+ 0 /* HMM_PFN_DEVICE_PRIVATE */
+ };
+ static const uint64_t i915_range_values[HMM_PFN_VALUE_MAX] = {
+ 0xfffeUL, /* HMM_PFN_ERROR */
+ 0, /* HMM_PFN_NONE */
+ 0xfffcUL /* HMM_PFN_SPECIAL */
+ };
+
+ const unsigned long npages = obj->base.size >> PAGE_SHIFT;
+ struct mm_struct *mm = obj->userptr.mm->mm;
+ struct sg_table *pages;
+ struct hmm_range range;
struct page **pvec;
- int pinned, ret;
-
- ret = -ENOMEM;
- pinned = 0;
-
- pvec = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
- if (pvec != NULL) {
- struct mm_struct *mm = obj->userptr.mm->mm;
- unsigned int flags = 0;
-
- if (!i915_gem_object_is_readonly(obj))
- flags |= FOLL_WRITE;
-
- ret = -EFAULT;
- if (mmget_not_zero(mm)) {
- down_read(>mmap_sem);
- while (pinned < npages) {
- ret = get_user_pages_remote
- (work->task, mm,
-obj->userptr.ptr + pinned * PAGE_SIZE,
-npages - pinned,
-flags,
-pvec + pinned, NULL, NULL);
- if (ret < 0)
- break;
-
- pinned += ret;
- }
- up_read(>mmap_sem);
- mmput(mm);
- }
+ unsigned long i;
+ bool write = !i915_gem_object_is_readonly(obj);
+ int err;
+
+ range.pfns = kvmalloc_array(npages, sizeof(uint64_t),
+ try ? GFP_KERNEL | __GFP_NORETRY |
__GFP_NOWARN : GFP_KERNEL);
+ if (range.pfns == NULL)
+ return try ? -EAGAIN : -ENOMEM;
+
+ range.pfn_shift = 12;
+ range.start = obj->userptr.ptr;
+ range.flags = i915_range_flags;
+ range.values = i915_range_values;
+ range.end = range.start + obj->base.size;
+
+
[PATCH 0/2] [i915] Getting rid of GUP and use HMM for user ptr features.
From: Jérôme Glisse [This depends on some HMM patchset queued upstream see branch [1]] This is simple change to switch to use HMM for user ptr buffer object which conveniently avoid to pin pages. I have more things in the pipe to make HMM more usefull for such cases (like sharing more resources accross multiple mirror of a same process). Beside avoiding pining, this is also an attempt to isolate core mm from device drivers by having clearly define API and boundary where we can set expection of everyone and thus having mm folks to have to read and understand driver code and conversly having driver folks understand mm maze. This is also part of what i want to discuss during XDC2018. Consider this as an RFC to start the discussion. [1] https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-intel-v00 Cc: dri-devel@lists.freedesktop.org Cc: David Airlie Cc: Daniel Vetter Cc: Chris Wilson Cc: Lionel Landwerlin Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: intel-...@lists.freedesktop.org Jérôme Glisse (2): gpu/i915: use HMM mirror instead of mmu_notifier gpu/i915: use HMM mirror for userptr buffer object. drivers/gpu/drm/i915/Kconfig| 4 +- drivers/gpu/drm/i915/i915_gem_userptr.c | 395 2 files changed, 199 insertions(+), 200 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] [radeon] Getting rid of GUP and use HMM for user ptr features.
From: Jérôme Glisse [This depends on some HMM patchset queued upstream see branch [1]] This is simple change to switch to use HMM for user ptr buffer object which conveniently avoid to pin pages. I have more things in the pipe to make HMM more usefull for such cases (like sharing more resources accross multiple mirror of a same process). Beside avoiding pining, this is also an attempt to isolate core mm from device drivers by having clearly define API and boundary where we can set expection of everyone and thus having mm folks to have to read and understand driver code and conversly having driver folks understand mm maze. This is also part of what i want to discuss during XDC2018. Consider this as an RFC to start the discussion. [1] https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-radeon-v00 Cc: dri-devel@lists.freedesktop.org Cc: Alex Deucher Cc: Christian König Cc: Felix Kuehling Cc: David (ChunMing) Zhou Cc: Nicolai Hähnle Cc: amd-...@lists.freedesktop.org Cc: David Airlie Cc: Daniel Vetter Jérôme Glisse (2): gpu/radeon: use HMM mirror instead of mmu_notifier gpu/radeon: use HMM mirror for userptr buffer object. drivers/gpu/drm/radeon/radeon.h | 14 +- drivers/gpu/drm/radeon/radeon_gem.c | 16 +- drivers/gpu/drm/radeon/radeon_mn.c | 283 +--- drivers/gpu/drm/radeon/radeon_ttm.c | 129 ++--- 4 files changed, 259 insertions(+), 183 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] gpu/i915: use HMM mirror instead of mmu_notifier
From: Jérôme Glisse
HMM provide a sets of helpers to avoid individual drivers re-doing
their own. This patch convert the radeon to use HMM mirror to track
CPU page table update and invalidate accordingly for userptr object.
Signed-off-by: Jérôme Glisse
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Lionel Landwerlin
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/Kconfig| 4 +-
drivers/gpu/drm/i915/i915_gem_userptr.c | 189
2 files changed, 97 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 33a458b7f1fc..40bba0bd8124 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -87,10 +87,10 @@ config DRM_I915_COMPRESS_ERROR
config DRM_I915_USERPTR
bool "Always enable userptr support"
depends on DRM_I915
- select MMU_NOTIFIER
+ select HMM_MIRROR
default y
help
- This option selects CONFIG_MMU_NOTIFIER if it isn't already
+ This option selects CONFIG_HMM_MIRROR if it isn't already
selected to enabled full userptr support.
If in doubt, say "Y".
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 2c9b284036d1..5e09b654b5ad 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -28,7 +28,7 @@
#include "i915_trace.h"
#include "intel_drv.h"
#include
-#include
+#include
#include
#include
#include
@@ -36,25 +36,25 @@
struct i915_mm_struct {
struct mm_struct *mm;
struct drm_i915_private *i915;
- struct i915_mmu_notifier *mn;
+ struct i915_mirror *mirror;
struct hlist_node node;
struct kref kref;
struct work_struct work;
};
-#if defined(CONFIG_MMU_NOTIFIER)
+#if defined(CONFIG_HMM_MIRROR)
#include
-struct i915_mmu_notifier {
+struct i915_mirror {
spinlock_t lock;
struct hlist_node node;
- struct mmu_notifier mn;
+ struct hmm_mirror mirror;
struct rb_root_cached objects;
struct workqueue_struct *wq;
};
struct i915_mmu_object {
- struct i915_mmu_notifier *mn;
+ struct i915_mirror *mirror;
struct drm_i915_gem_object *obj;
struct interval_tree_node it;
struct list_head link;
@@ -99,7 +99,7 @@ static void add_object(struct i915_mmu_object *mo)
if (mo->attached)
return;
- interval_tree_insert(>it, >mn->objects);
+ interval_tree_insert(>it, >mirror->objects);
mo->attached = true;
}
@@ -108,33 +108,29 @@ static void del_object(struct i915_mmu_object *mo)
if (!mo->attached)
return;
- interval_tree_remove(>it, >mn->objects);
+ interval_tree_remove(>it, >mirror->objects);
mo->attached = false;
}
-static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
- struct mm_struct *mm,
- unsigned long start,
- unsigned long end,
- bool blockable)
+static int i915_sync_cpu_device_pagetables(struct hmm_mirror *_mirror,
+ const struct hmm_update *update)
{
- struct i915_mmu_notifier *mn =
- container_of(_mn, struct i915_mmu_notifier, mn);
+ struct i915_mirror *mirror =
+ container_of(_mirror, struct i915_mirror, mirror);
+ /* interval ranges are inclusive, but invalidate range is exclusive */
+ unsigned long end = update->end - 1;
struct i915_mmu_object *mo;
struct interval_tree_node *it;
LIST_HEAD(cancelled);
- if (RB_EMPTY_ROOT(>objects.rb_root))
+ if (RB_EMPTY_ROOT(>objects.rb_root))
return 0;
- /* interval ranges are inclusive, but invalidate range is exclusive */
- end--;
-
- spin_lock(>lock);
- it = interval_tree_iter_first(>objects, start, end);
+ spin_lock(>lock);
+ it = interval_tree_iter_first(>objects, update->start, end);
while (it) {
- if (!blockable) {
- spin_unlock(>lock);
+ if (!update->blockable) {
+ spin_unlock(>lock);
return -EAGAIN;
}
/* The mmu_object is released late when destroying the
@@ -148,50 +144,56 @@ static int
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
*/
mo = container_of(it, struct i915_mmu_object, it);
if (kref_get_unless_zero(>obj->base.refcount))
- queue_work(mn->wq, >work);
+
[Bug 68059] with radeon.dpm=1, Xorg crashed a while after resume
https://bugs.freedesktop.org/show_bug.cgi?id=68059 --- Comment #13 from mirh --- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a16f7614e33c080bbece39527bde144dcca4ec7 dpm=1 doesn't seem to be explicitly required for the hardware since 3.13. If you confirm me it's so (and if we put aside the guy with an HD 4670, the one with the HD 6950, and the last with a 390x) we can close this bug in my experience. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101278] Severe slowdown on Shadow of Mordor between 17.1.0 and 17.1.1
https://bugs.freedesktop.org/show_bug.cgi?id=101278 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #6 from Timothy Arceri --- No reply so assuming fixed and closing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104906] Mesa crashes randomly during Youtube playback
https://bugs.freedesktop.org/show_bug.cgi?id=104906 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Timothy Arceri --- Is this still a problem? Various KDE/Mesa related bugs have been fixed on both side in the months since this bug was reported. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102962] GPU crash running Overwatch in wine-staging
https://bugs.freedesktop.org/show_bug.cgi?id=102962 Timothy Arceri changed: What|Removed |Added CC||coolo...@gmail.com --- Comment #14 from Timothy Arceri --- *** Bug 104475 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104475] Xorg Completely stops Respondng when running Overwatch in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=104475 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Timothy Arceri --- *** This bug has been marked as a duplicate of bug 102962 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99765] Make Octopus OpenCL support work on Clover and RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=99765 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94273] Clover on RadeonSI OpenCL segfault during testing of clBLAS
https://bugs.freedesktop.org/show_bug.cgi?id=94273 Timothy Arceri changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91305] [clover/kaveri] When running JohnTheRipper OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=100105 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105950] radeonsi: OpenCL not working correctly on a big endian machine
https://bugs.freedesktop.org/show_bug.cgi?id=105950 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Timothy Arceri --- These patches were committed. Closing as fixed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102009] [clover, amdgcn] Blender crashes when compiling OpenCL kernel
https://bugs.freedesktop.org/show_bug.cgi?id=102009 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 82717] OpenCL support for mandelbulber-opencl
https://bugs.freedesktop.org/show_bug.cgi?id=82717 Timothy Arceri changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107115] Make darktable OpenCL support work on Clover and RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=107115 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 --- Comment #7 from Timothy Arceri --- (In reply to Axel Davy from comment #6) > Given the regression bisect found the issue came with a radeonsi patch, I > reassign to radeonsi. Maybe the patch introduces a small difference in the > driver behaviour that regresses nine ? Well you can do that but it's unlikely to be investigated by anyone not interested in gallium-nine which is why I moved it there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
On Tue, 4 Sep 2018 00:15:23 +0200 Henrik Austad wrote: > I don't really have an opinion to whether or not we /should/ have 00-INDEX, > but the above 00-INDEX should either be removed or be kept up to date. If > we should keep the files, I can try to keep them updated, but I rather not > if we just want to delete them anyway. > > As a starting point, remove all index-files and references to 00-INDEX and > see where the discussion is going. Applied, thanks. jon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107876] GPU lockup with Radeon HD 7850 in 18.1.6 driver
https://bugs.freedesktop.org/show_bug.cgi?id=107876 --- Comment #4 from Lukasz Krotowski --- I'm pretty sure that this bug exists also in 18.2 (I've build git snapshot and had similar issues but attached logs are from 18.1). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107876] GPU lockup with Radeon HD 7850 in 18.1.6 driver
https://bugs.freedesktop.org/show_bug.cgi?id=107876 Lukasz Krotowski changed: What|Removed |Added Version|18.2|18.1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107876] GPU lockup with Radeon HD 7850 in 18.1.6 driver
https://bugs.freedesktop.org/show_bug.cgi?id=107876 Lukasz Krotowski changed: What|Removed |Added Product|xorg|Mesa QA Contact|xorg-t...@lists.x.org |dri-devel@lists.freedesktop ||.org Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Version|git |18.2 Component|Driver/Radeon |Drivers/Gallium/radeonsi -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #14 from Jon (jon...@gmail.com) --- Just had another crash. Moved the mouse to wake it from sleep, hdmi and dvi-d monitors came on, displayport monitor never did, mouse frozen and num lock light frozen on keyboard. I was able to still ping the computer, but couldn't ssh. It timed out eventually but oddly enough an nmap showed the port open. Here's the output directly before the reboot from journalctl. Running the same 4.18.5 kernel and the cmdline from my previous post. Sep 09 12:41:52 pc003 kernel: general protection fault: [#1] SMP NOPTI Sep 09 12:41:52 pc003 kernel: CPU: 9 PID: 2585 Comm: jstat Tainted: GW 4.18.5-pc003 #2 Sep 09 12:41:52 pc003 kernel: Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 TOMAHAWK ARCTIC (MS-7A34), BIOS H.D0 05/02/2018 Sep 09 12:41:52 pc003 kernel: RIP: 0010:prefetch_freepointer+0x10/0x20 Sep 09 12:41:52 pc003 kernel: Code: 89 d3 e8 d3 46 68 00 85 c0 0f 85 61 7b 00 00 48 83 c4 08 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 48 85 f6 74 13 8b 47 20 48 01 c6 <48> 33 36 48 33 b7 38 0> Sep 09 12:41:52 pc003 kernel: RSP: 0018:b094a0c57c78 EFLAGS: 00010282 Sep 09 12:41:52 pc003 kernel: RAX: RBX: ad0c9b2034c927e3 RCX: f44b Sep 09 12:41:52 pc003 kernel: RDX: f44a RSI: ad0c9b2034c927e3 RDI: 9936de807600 Sep 09 12:41:52 pc003 kernel: RBP: 006000c0 R08: 9936dee660c0 R09: 007080c0 Sep 09 12:41:52 pc003 kernel: R10: 993532c9 R11: 993532c91e40 R12: 9936de807600 Sep 09 12:41:52 pc003 kernel: R13: R14: 9936868a8d96 R15: 9936de807600 Sep 09 12:41:52 pc003 kernel: FS: 7f4c6fddd740() GS:9936dee4() knlGS: Sep 09 12:41:52 pc003 kernel: CS: 0010 DS: ES: CR0: 80050033 Sep 09 12:41:52 pc003 kernel: CR2: 556770d12310 CR3: 000672fb8000 CR4: 003406e0 Sep 09 12:41:52 pc003 kernel: Call Trace: Sep 09 12:41:52 pc003 kernel: kmem_cache_alloc_node_trace+0x146/0x1f0 Sep 09 12:41:52 pc003 kernel: ? alloc_vmap_area+0x75/0x370 Sep 09 12:41:52 pc003 kernel: alloc_vmap_area+0x75/0x370 Sep 09 12:41:52 pc003 kernel: ? kmem_cache_alloc_node_trace+0x1c1/0x1f0 Sep 09 12:41:52 pc003 kernel: __get_vm_area_node+0xb0/0x160 Sep 09 12:41:52 pc003 kernel: __vmalloc_node_range+0x6a/0x290 Sep 09 12:41:52 pc003 kernel: ? _do_fork+0xe2/0x390 Sep 09 12:41:52 pc003 kernel: copy_process.part.36+0x5cd/0x1ae0 Sep 09 12:41:52 pc003 kernel: ? _do_fork+0xe2/0x390 Sep 09 12:41:52 pc003 kernel: _do_fork+0xe2/0x390 Sep 09 12:41:52 pc003 kernel: ? __set_current_blocked+0x3d/0x60 Sep 09 12:41:52 pc003 kernel: ? sigprocmask+0x72/0xa0 Sep 09 12:41:52 pc003 kernel: do_syscall_64+0x5b/0x160 Sep 09 12:41:52 pc003 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 09 12:41:52 pc003 kernel: RIP: 0033:0x7f4c6f4be8a3 Sep 09 12:41:52 pc003 kernel: Code: db 45 85 f6 0f 85 ad 01 00 00 64 4c 8b 04 25 10 00 00 00 31 d2 4d 8d 90 d0 02 00 00 31 f6 bf 11 00 20 01 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 8> Sep 09 12:41:52 pc003 kernel: RSP: 002b:7fff66d76bf0 EFLAGS: 0246 ORIG_RAX: 0038 Sep 09 12:41:52 pc003 kernel: RAX: ffda RBX: RCX: 7f4c6f4be8a3 Sep 09 12:41:52 pc003 kernel: RDX: RSI: RDI: 01200011 Sep 09 12:41:52 pc003 kernel: RBP: 7fff66d76c30 R08: 7f4c6fddd740 R09: 277d372420746e69 Sep 09 12:41:52 pc003 kernel: R10: 7f4c6fddda10 R11: 0246 R12: Sep 09 12:41:52 pc003 kernel: R13: 7fff66d76ce0 R14: R15: Sep 09 12:41:52 pc003 kernel: Modules linked in: fuse xt_CHECKSUM ipt_MASQUERADE tun devlink rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache nf_conntrack_netbios_n> Sep 09 12:41:52 pc003 kernel: irqbypass snd_seq_device crct10dif_pclmul wmi_bmof crc32_pclmul snd_pcm ghash_clmulni_intel snd_timer sp5100_tco joydev ccp pcspkr k10temp i2c_piix4 snd so> Sep 09 12:41:52 pc003 kernel: ---[ end trace fb8b01a46fe5951a ]--- Sep 09 12:41:52 pc003 kernel: RIP: 0010:prefetch_freepointer+0x10/0x20 Sep 09 12:41:52 pc003 kernel: Code: 89 d3 e8 d3 46 68 00 85 c0 0f 85 61 7b 00 00 48 83 c4 08 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 48 85 f6 74 13 8b 47 20 48 01 c6 <48> 33 36 48 33 b7 38 0> Sep 09 12:41:52 pc003 kernel: RSP: 0018:b094a0c57c78 EFLAGS: 00010282 Sep 09 12:41:52 pc003 kernel: RAX: RBX: ad0c9b2034c927e3 RCX: f44b Sep 09 12:41:52 pc003 kernel: RDX: f44a RSI: ad0c9b2034c927e3 RDI: 9936de807600 Sep 09 12:41:52 pc003 kernel: RBP: 006000c0 R08: 9936dee660c0 R09: 007080c0 Sep 09 12:41:52 pc003 kernel: R10: 993532c9 R11: 993532c91e40 R12: 9936de807600 Sep 09 12:41:52 pc003 kernel: R13: R14: 9936868a8d96 R15: 9936de807600 Sep 09 12:41:52 pc003 kernel: FS:
[Bug 201067] [bisected] [4.19-rc2 regression] Display corruption with Vega 64 in 4.19-rc2
https://bugzilla.kernel.org/show_bug.cgi?id=201067 Nick Sarnie (sar...@gentoo.org) changed: What|Removed |Added Regression|No |Yes -- 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
[Bug 201067] New: [bisected] [4.19-rc2 regression] Display corruption with Vega 64 in 4.19-rc2
https://bugzilla.kernel.org/show_bug.cgi?id=201067 Bug ID: 201067 Summary: [bisected] [4.19-rc2 regression] Display corruption with Vega 64 in 4.19-rc2 Product: Drivers Version: 2.5 Kernel Version: 4.19-rc2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: sar...@gentoo.org Regression: No Created attachment 278389 --> https://bugzilla.kernel.org/attachment.cgi?id=278389=edit dmesg Hi all, When using a kernel after the below commit, I get visual corruption only on the right most vertical column of my screen: Author: Nicholas Kazlauskas Date: Mon Jul 23 14:13:23 2018 -0400 drm/amd/display: Use calculated disp_clk_khz value for dce110 Video: https://www.youtube.com/watch?v=HrJUrBWMRXU Using a kernel without this commit does not have the issue. My GPU is a Sapphire Nitro+ Vega 64. I am using Gentoo with Mesa git and KDE Plasma 5. My main monitor is connected over DP and runs at 2560x1440 at 144hz. My second monitor is connected over HDMI and runs at 1920x1080 at 60hz. I tried disabling the second monitor in KDE, but the issue still occurs. It also occurs in fullscreen applications. I will also attach dmesg. I can test any patches or answer any questions. Thanks, Sarnex -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/16] drm: rcar-du: Perform the initial CRTC setup from rcar_du_crtc_get()
Hi Jacopo,
On Friday, 7 September 2018 21:19:38 EEST jacopo mondi wrote:
> On Tue, Sep 04, 2018 at 03:10:17PM +0300, Laurent Pinchart wrote:
> > The rcar_du_crtc_get() function is always immediately followed by a call
> > to rcar_du_crtc_setup(). Call the later from the former to simplify the
> > code, and add a comment to explain how the get and put calls are
> > balanced.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 107 +++-
> > 1 file changed, 56 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 4c9572d7ea89..1d81eb21
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -66,39 +66,6 @@ static void rcar_du_crtc_clr_set(struct rcar_du_crtc
> > *rcrtc, u32 reg,
> > rcar_du_write(rcdu, rcrtc->mmio_offset + reg, (value & ~clr) | set);
> > }
> >
> > -static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> > -{
> > - int ret;
> > -
> > - ret = clk_prepare_enable(rcrtc->clock);
> > - if (ret < 0)
> > - return ret;
> > -
> > - ret = clk_prepare_enable(rcrtc->extclock);
> > - if (ret < 0)
> > - goto error_clock;
> > -
> > - ret = rcar_du_group_get(rcrtc->group);
> > - if (ret < 0)
> > - goto error_group;
> > -
> > - return 0;
> > -
> > -error_group:
> > - clk_disable_unprepare(rcrtc->extclock);
> > -error_clock:
> > - clk_disable_unprepare(rcrtc->clock);
> > - return ret;
> > -}
> > -
> > -static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
>
> For what I see, rcar_du_crtc_stop() is also called once just before
> _put(). Have you considered doing with them what you've done with
> _get() and _setup() ?
I have, but given that we have an explicit get(); start(); sequence in
rcar_du_crtc_atomic_enable(), I'd rather keep the stop(); put(); sequence in
rcar_du_crtc_atomic_disable().
> > -{
> > - rcar_du_group_put(rcrtc->group);
> > -
> > - clk_disable_unprepare(rcrtc->extclock);
> > - clk_disable_unprepare(rcrtc->clock);
> > -}
> > -
> >
> > /*
> >
> > ->
> > * Hardware Setup
> > */
> >
> > @@ -546,6 +513,51 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc
> > *rcrtc)>
> > drm_crtc_vblank_on(>crtc);
> >
> > }
> >
> > +static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> > +{
> > + int ret;
> > +
> > + /*
> > +* Guard against double-get, as the function is called from both the
> > +* .atomic_enable() and .atomic_begin() handlers.
> > +*/
> > + if (rcrtc->initialized)
> > + return 0;
> > +
> > + ret = clk_prepare_enable(rcrtc->clock);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = clk_prepare_enable(rcrtc->extclock);
> > + if (ret < 0)
> > + goto error_clock;
> > +
> > + ret = rcar_du_group_get(rcrtc->group);
> > + if (ret < 0)
> > + goto error_group;
> > +
> > + rcar_du_crtc_setup(rcrtc);
> > + rcrtc->initialized = true;
> > +
> > + return 0;
> > +
> > +error_group:
> > + clk_disable_unprepare(rcrtc->extclock);
> > +error_clock:
> > + clk_disable_unprepare(rcrtc->clock);
> > + return ret;
> > +}
> > +
> > +static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> > +{
> > + rcar_du_group_put(rcrtc->group);
> > +
> > + clk_disable_unprepare(rcrtc->extclock);
> > + clk_disable_unprepare(rcrtc->clock);
> > +
> > + rcrtc->initialized = false;
> > +}
> > +
> >
> > static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
> > {
> >
> > bool interlaced;
> >
> > @@ -639,16 +651,7 @@ static void rcar_du_crtc_atomic_enable(struct
> > drm_crtc *crtc,>
> > {
> >
> > struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> >
> > - /*
> > -* If the CRTC has already been setup by the .atomic_begin() handler we
> > -* can skip the setup stage.
> > -*/
> > - if (!rcrtc->initialized) {
> > - rcar_du_crtc_get(rcrtc);
> > - rcar_du_crtc_setup(rcrtc);
> > - rcrtc->initialized = true;
> > - }
> > -
> > + rcar_du_crtc_get(rcrtc);
> >
> > rcar_du_crtc_start(rcrtc);
> >
> > }
> >
> > @@ -667,7 +670,6 @@ static void rcar_du_crtc_atomic_disable(struct
> > drm_crtc *crtc,>
> > }
> > spin_unlock_irq(>dev->event_lock);
> >
> > - rcrtc->initialized = false;
> >
> > rcrtc->outputs = 0;
> >
> > }
> >
> > @@ -680,14 +682,17 @@ static void rcar_du_crtc_atomic_begin(struct
> > drm_crtc *crtc,>
> > /*
> >
> > * If a mode set is in progress we can be called with the CRTC
disabled.
> >
> > -* We then need to first setup the CRTC in order to configure planes.
> > -* The .atomic_enable() handler will notice and skip the CRTC setup.
> > +* We thus need to first get and setup the CRTC in order to configure
> > +*
[Bug 107784] [AMD tahiti XT] displayport broken
https://bugs.freedesktop.org/show_bug.cgi?id=107784 --- Comment #24 from Sylvain BERTRAND --- Yep, it manifest also on 32 bits x86. I posted also a bug report. Since it's critical we'll probably get a new rc very soon. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 107784] [AMD tahiti XT] displayport broken
Yep, it manifest also on 32 bits x86. I posted also a bug report. Since it's critical we'll probably get a new rc very soon. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/20] drm/rcar-du: Use drm_fbdev_generic_setup()
Hi Noralf,
Thank you for the patch.
On Saturday, 8 September 2018 16:46:35 EEST Noralf Trønnes wrote:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> driver. This is done to highlight the fact that fbdev emulation is an
> internal client that makes use of the driver, it is not part of the
> driver as such. If fbdev setup fails, an error is printed, but the driver
> succeeds probing.
>
> Use the drm_mode_config_helper_suspend/resume helpers instead of open
> coding it.
As Sam already pointed out, shouldn't this change be split to a separate patch
?
Apart from that this patch looks good to me.
Reviewed-by: Laurent Pinchart
I assume you will push the entire series through drm-misc. If you'd like me to
take this patch in my tree instead please let me know.
> drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
> In that case it retries fbdev setup on the next .output_poll_changed.
>
> Cc: Laurent Pinchart
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 34 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
> 3 files changed, 6 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 02aee6cb0e53..bcb01d7b4a89
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -25,7 +25,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
>
> #include "rcar_du_drv.h"
> #include "rcar_du_kms.h"
> @@ -316,19 +318,11 @@ MODULE_DEVICE_TABLE(of, rcar_du_of_table);
> * DRM operations
> */
>
> -static void rcar_du_lastclose(struct drm_device *dev)
> -{
> - struct rcar_du_device *rcdu = dev->dev_private;
> -
> - drm_fbdev_cma_restore_mode(rcdu->fbdev);
> -}
> -
> DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
>
> static struct drm_driver rcar_du_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
>
> | DRIVER_ATOMIC,
>
> - .lastclose = rcar_du_lastclose,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_vm_ops = _gem_cma_vm_ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> @@ -357,30 +351,15 @@ static struct drm_driver rcar_du_driver = {
> static int rcar_du_pm_suspend(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
> - struct drm_atomic_state *state;
>
> - drm_kms_helper_poll_disable(rcdu->ddev);
> - drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, true);
> -
> - state = drm_atomic_helper_suspend(rcdu->ddev);
> - if (IS_ERR(state)) {
> - drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
> - drm_kms_helper_poll_enable(rcdu->ddev);
> - return PTR_ERR(state);
> - }
> -
> - rcdu->suspend_state = state;
> -
> - return 0;
> + return drm_mode_config_helper_suspend(rcdu->ddev);
> }
>
> static int rcar_du_pm_resume(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
>
> - drm_atomic_helper_resume(rcdu->ddev, rcdu->suspend_state);
> - drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
> - drm_kms_helper_poll_enable(rcdu->ddev);
> + drm_mode_config_helper_resume(rcdu->ddev);
>
> return 0;
> }
> @@ -401,9 +380,6 @@ static int rcar_du_remove(struct platform_device *pdev)
>
> drm_dev_unregister(ddev);
>
> - if (rcdu->fbdev)
> - drm_fbdev_cma_fini(rcdu->fbdev);
> -
> drm_kms_helper_poll_fini(ddev);
> drm_mode_config_cleanup(ddev);
>
> @@ -463,6 +439,8 @@ static int rcar_du_probe(struct platform_device *pdev)
>
> DRM_INFO("Device %s probed\n", dev_name(>dev));
>
> + drm_fbdev_generic_setup(ddev, 32);
> +
> return 0;
>
> error:
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index b3a25e8e07d0..58d5c730d2d2
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -24,7 +24,6 @@
> struct clk;
> struct device;
> struct drm_device;
> -struct drm_fbdev_cma;
> struct rcar_du_device;
>
> #define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK (1 << 0)/* Per-CRTC IRQ
> and clock
> */ @@ -77,8 +76,6 @@ struct rcar_du_device {
> void __iomem *mmio;
>
> struct drm_device *ddev;
> - struct drm_fbdev_cma *fbdev;
Re: [PATCH 00/20] drm/cma-helper drivers: Use drm_fbdev_generic_setup()
Hi Noralf. On Sat, Sep 08, 2018 at 03:46:28PM +0200, Noralf Trønnes wrote: > This patchset moves the drivers using the CMA helper fully over to the > generic fbdev emulation. The unused fbdev code is removed from the CMA > helper. The full series looks good. I have browsed all the code changes, and with one minor note where one patch could have been split up all the rest looked good. Feel free to add my: Acked-by: Sam Ravnborg to the full series. > 32 files changed, 56 insertions(+), 492 deletions(-) This kind of diffstat is always a pleasure to see. Especially as in this case where functionality is not removed, just made smarter. I know this set does not include the infrastructure parts, so in reality more lines added. But anyway. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/20] drm/rcar-du: Use drm_fbdev_generic_setup()
On Sat, Sep 08, 2018 at 03:46:35PM +0200, Noralf Trønnes wrote: > The CMA helper is already using the drm_fb_helper_generic_probe part of > the generic fbdev emulation. This patch makes full use of the generic > fbdev emulation by using its drm_client callbacks. This means that > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > now handled by the emulation code. Additionally fbdev unregister happens > automatically on drm_dev_unregister(). > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > driver. This is done to highlight the fact that fbdev emulation is an > internal client that makes use of the driver, it is not part of the > driver as such. If fbdev setup fails, an error is printed, but the driver > succeeds probing. > > Use the drm_mode_config_helper_suspend/resume helpers instead of open > coding it. Seems a bit un-related to the rest of the patch. But the changes looks fine (from my limited DRM experience that is). Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: Make i915 check for panel orient quirks on eDP and add one such quirk
Hi, On 09-09-18 15:34, Hans de Goede wrote: Hi All, This series fixes (works around) the gpd win 2's eDP panel being a portait mode panel being used in a landscape case (clamshell model). I plan to merge the i915 bit through dinq and the actual quirk through drm-misc. These 2 are related in the sense that the quirk will not do anything without the i915 bits and the i915 bits only actually do anything once at least 1 quirk entry for an eDP panel is present. But they can be merged independently. Off-topic/meta: I got a number of bounces for all the @linux.intel.com addresses, but according to MAINTAINERS those are still the one to use ? Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107784] [AMD tahiti XT] displayport broken
https://bugs.freedesktop.org/show_bug.cgi?id=107784 --- Comment #23 from Dmitrii Tcvetkov --- > Relevant discussion about cf7a63ef4e0203f (x86/tsc: Calibrate tsc only once) > http://lkml.iu.edu/hypermail/linux/kernel/1809.0/03226.html And there is a patch http://lkml.iu.edu/hypermail/linux/kernel/1809.0/04424.html which is on it's way to mainline as I understand. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107784] [AMD tahiti XT] displayport broken
https://bugs.freedesktop.org/show_bug.cgi?id=107784 --- Comment #22 from Dmitrii Tcvetkov --- (In reply to Dmitrii Tcvetkov from comment #21) > (In reply to Sylvain BERTRAND from comment #20) > > Roughly, if you have a cpu with a frequency above 4.2GHz (max unsigned > > 32bits), > > linux time subsystem gets broken leading to the timeouts in displayport > > programming. Ofc, my cpu runs at 4.7GHz. > > I hit the bug on AMD FX-9590 machine with RX 580 and 2 displayport monitors. > As for you bisect wasn't successful for me and led me to network merge > commit. > > Looks like you're right! If I downclock the CPU to 4.2 GHz then current > mainline master (f8f65382c98a28e3c2b20) boots fine. Relevant discussion about cf7a63ef4e0203f (x86/tsc: Calibrate tsc only once) http://lkml.iu.edu/hypermail/linux/kernel/1809.0/03226.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 Axel Davy changed: What|Removed |Added Component|Gallium/StateTracker/galliu |Drivers/Gallium/radeonsi |mnine | Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org CC||mar...@gmail.com QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Update todo.rst
On Thu, Sep 06, 2018 at 02:28:32PM +0100, Emil Velikov wrote: > On 6 September 2018 at 10:40, Heiko Stuebner wrote: > > Am Mittwoch, 5. September 2018, 20:15:09 CEST schrieb Daniel Vetter: > >> - drmP.h is now fully split up. > >> - vkms is happening (and will gain its own todo and docs under a new > >> vkms.rst file real soon) > >> - legacy cruft is completely hidden now, drm_vblank.c is split out > >> from drm_irq.c now. I've decided to drop the task to split out > >> drm_legacy.ko, partially because Dave already rejected a patch to > >> hide the old dri1 drivers better. Current state feels good enough to > >> me. > >> - best_encoder atomic cleanup is done (it's now the default, not even > >> exported anymore) > >> - bunch of smaller things > >> > >> v2: > >> - Explain why the drm_legacy.ko task is dropped (Emil). > >> - typos (Sam). > >> > >> v3: Fix typo (Ilia) > >> > >> Cc: Ilia Mirkin > >> Cc: Sam Ravnborg > >> Cc: Emil Velikov > >> Signed-off-by: Daniel Vetter > >> Cc: Gustavo Padovan > >> Cc: Maarten Lankhorst > >> Cc: Sean Paul > >> Cc: David Airlie > > > > I've read through the text changes and didn't spot any glaring typos > > [beware non-native speaker], so fwiw > Most of the people in the CC list are ;-) > > Fwiw > Reviewed-by: Emil Velikov Thanks to both of you for reviewing, entire series pulled into drm-misc-next. -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 v2 0/4] Add support for Arm Framebuffer Compression(AFBC)
On Sat, Sep 08, 2018 at 03:58:53PM +0200, Neil Armstrong wrote: > Hi Ayan, > > On 10/07/2018 15:18, Ayan Kumar Halder wrote: > > In the current series of patches, we are trying to add support for AFBC > > modifiers in malidp. AFBC modifiers adds some constraints to framebuffer > > size, alignment, pitch, formats, etc. Here we are trying to add support > > for one combination of AFBC modifier ie AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | > > AFBC_FORMAT_MOD_SPARSE | AFBC_FORMAT_MOD_YTR. > > In future, we intend to add support for more combination of AFBC modifiers. > > Currently, we are trying to enable a basic support of AFBC in malidp. > > Thanks for pushing AFBC support, this will help supporting it on other SoCs > implementing support > like Amlogic, Rockchip or Samsung. > > I have one question, is there a way to generate such AFBC buffers without the > Mali GPU ? > I mean, is there a way to generate some sample buffers with some of the > modifier features > to validate it without having the complete Mali GPU -> DRM chain ? An igt would be perfect. We've done that for i915 compressed buffers. Note that it just needs to be an afbc buffer, not actually compressed. Setting all the bits to indicate "uncompressed" for each block is what we did for the i915 test. As long as the igt uses DRIVER_GENERIC and kms driver could then use it to validate the basics of afbc support. -Daniel > > Thanks in advance, > Neil > > > > > Changes from v2: > > - Added ack by Maarten Lankhorst > > for patch 1. However, this has been kept in this series in order to help > > reviewers review the other patches (which are related to patch 1) > > - For patches 2 and 4, replaced DRM_ERROR() with DRM_DEBUG_KMS() > > - For patch 3, reworked malidp_de_set_plane_afbc() so as to consolidate > > all afbc specific register configuration in this. > > > > Ayan Kumar Halder (4): > > drm/arm/malidp: Add modifier definitions for describing Arm > > Framebuffer Compression (AFBC). > > drm/arm/malidp: Implemented the size validation for AFBC framebuffers > > drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC > > modifier > > drm/arm/malidp: Added support for AFBC modifiers for all layers except > > DE_SMART > > > > drivers/gpu/drm/arm/malidp_drv.c| 129 > > +++- > > drivers/gpu/drm/arm/malidp_hw.c | 27 +--- > > drivers/gpu/drm/arm/malidp_hw.h | 7 ++ > > drivers/gpu/drm/arm/malidp_planes.c | 129 > > +--- > > drivers/gpu/drm/arm/malidp_regs.h | 20 ++ > > include/uapi/drm/drm_fourcc.h | 83 +++ > > 6 files changed, 373 insertions(+), 22 deletions(-) > > > > ___ > 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
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #13 from Jon (jon...@gmail.com) --- Alex: Thanks for the reply. I just added that parameter and rebooted. Here's my /proc/cmdline now: BOOT_IMAGE=/boot/vmlinuz-4.18.5-pc003 root=/dev/mapper/fedora_ssd_vg00-root ro resume=/dev/mapper/fedora_ssd_vg00-swap rd.lvm.lv=fedora_ssd_vg00/root rd.lvm.lv=fedora_ssd_vg00/swap rcu_nocbs=0-15 idle=nowait rhgb quiet -- 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
[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps
https://bugs.freedesktop.org/show_bug.cgi?id=100742 --- Comment #4 from Christoph Haag --- The situation has massively improved since I opened this issue at least with very recent kernels. I'm hesitant to close it, at least not before doing some testing to see if it can still be reproduced. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #12 from Alex Deucher (alexdeuc...@gmail.com) --- Does adding idle=nomwait on the kernel command line in grub help? -- 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
