Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

[Daniel Vetter]

On Wed, Nov 22, 2017 at 07:21:00PM +0100, Boris Brezillon wrote:
> On Wed, 22 Nov 2017 19:13:09 +0100
> Daniel Vetter <dan...@ffwll.ch> wrote:
> 
> > On Wed, Nov 22, 2017 at 6:51 PM, Boris Brezillon
> > <boris.brezil...@free-electrons.com> wrote:
> > > Hi Stefan,
> > >
> > > On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
> > > Stefan Wahren <stefan.wah...@i2se.com> wrote:
> > >  
> > >> Hi Boris,
> > >> if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with 
> > >> sufficient CMA memory (32 MB), i'll get this warning during boot:
> > >>
> > >> [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops 
> > >> [vc4])
> > >> [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops 
> > >> [vc4])
> > >> [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops 
> > >> [vc4])
> > >> [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops 
> > >> vc4_crtc_ops [vc4])
> > >> [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops 
> > >> vc4_crtc_ops [vc4])
> > >> [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops 
> > >> vc4_crtc_ops [vc4])
> > >> [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops 
> > >> [vc4])
> > >> [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor > > >> 0
> > >> [7.750841] [drm] Supports vblank timestamp caching Rev 2 
> > >> (21.10.2013).
> > >> [7.757620] [drm] Driver supports precise vblank timestamp query.
> > >> [7.811775] [ cut here ]
> > >> [7.811780] refcount_t: increment on 0; use-after-free.
> > >> [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 
> > >> refcount_inc+0x44/0x50
> > >> [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper 
> > >> smsc95xx usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma 
> > >> crc32_ce i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6
> > >> [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 
> > >> 4.14.0-next-20171122 #1
> > >> [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
> > >> [7.811958] task: 800036b91c00 task.stack: 0d6f
> > >> [7.811967] pstate: 2005 (nzCv daif -PAN -UAO)
> > >> [7.811974] pc : refcount_inc+0x44/0x50
> > >> [7.811981] lr : refcount_inc+0x44/0x50
> > >> [7.811984] sp : 0d6f3300
> > >> [7.811988] x29: 0d6f3300 x28: 
> > >> [7.811996] x27: 0003 x26: 800037107800
> > >> [7.812004] x25: 0001 x24: 800035afdc00
> > >> [7.812012] x23:  x22: 800035dfa600
> > >> [7.812020] x21: 800035afd9b0 x20: 800035afd9a4
> > >> [7.812027] x19:  x18: 
> > >> [7.812034] x17: 0001 x16: 0019
> > >> [7.812042] x15: 0001 x14: fff0
> > >> [7.812049] x13: 090ae840 x12: 08fa2d50
> > >> [7.812057] x11: 08fa2000 x10: 090ad000
> > >> [7.812064] x9 :  x8 : 090b5c2f
> > >> [7.812072] x7 :  x6 : 0015ee00
> > >> [7.812079] x5 :  x4 : 
> > >> [7.812087] x3 :  x2 : 800030047000
> > >> [7.812094] x1 : 800036b91c00 x0 : 002b
> > >> [7.812102] Call trace:
> > >> [7.812109]  refcount_inc+0x44/0x50
> > >> [7.812226]  vc4_bo_inc_usecnt+0x84/0x88 [vc4]
> > >> [7.812310]  vc4_prepare_fb+0x40/0xf0 [vc4]
> > >> [7.812460]  drm_atomic_helper_prepare_planes+0x54/0xf0 
> > >> [drm_kms_helper]
> > >> [7.812543]  vc4_atomic_commit+0x88/0x130 [vc4]
> > >> [7.812868]  drm_atomic_commit+0x48/0x68 [drm]
> > >> [7.813002]  restore_fbdev_mode_atomic+0x1d8/0x1e8 [drm_kms_helper]
> > >> [7.813113]  restore_fbdev_mode+0x28/0x160 [drm_kms_helper]
> > >> [7.813223]  
> > >> drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 
> > >> [drm_kms_helper]
> > >> [7.813331]  drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper]
> > >> [   

Re: [PATCH 1/6] drm/i915: export the stolen region as a resource

[Joonas Lahtinen]

+ Dave as a heads-up

On Thu, 2017-11-23 at 07:17 +0100, Ingo Molnar wrote:
> * Matthew Auld  wrote:
> 
> > We duplicate the stolen discovery code in early-quirks and in i915,
> > however if we just export the region as a resource from early-quirks we
> > can nuke the duplication.
> > 
> > Suggested-by: Joonas Lahtinen 
> > Suggested-by: Chris Wilson 
> > Signed-off-by: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > Cc: Chris Wilson 
> > Cc: Paulo Zanoni 
> > Cc: Ingo Molnar 
> > Cc: H. Peter Anvin 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: x...@kernel.org
> > ---
> >  arch/x86/kernel/early-quirks.c |   6 ++
> >  drivers/gpu/drm/i915/i915_gem_gtt.c|  51 +--
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 109 
> > +
> >  include/drm/i915_drm.h |   3 +
> >  4 files changed, 13 insertions(+), 156 deletions(-)
> 
> If it's truly identical:
> 
>   Acked-by: Ingo Molnar 

Are you fine with us merging this together with the rest of the series
through the DRM tree once it's all reviewed?

That'd help not requiring so many backmerges.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/8] drm/mediatek: mt2701: switch to mfd probing.

[CK Hu]

Hi, Matthias:

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> With the mtk-mmsys MFD device in place, we switch the probing for
> mt2701 from device-tree to mfd.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index dd249cf5121e..5a263aa3ab6e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -392,9 +393,10 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = 
> {
>  
>  static int mtk_drm_probe(struct platform_device *pdev)
>  {
> + struct mmsys_dev *mmsys_private;
>   struct device *dev = >dev;
>   struct mtk_drm_private *private;
> - struct device_node *node;
> + struct device_node *node, *parent_node;
>   struct component_match *match = NULL;
>   int ret;
>   int i;
> @@ -407,12 +409,23 @@ static int mtk_drm_probe(struct platform_device *pdev)
>   INIT_WORK(>commit.work, mtk_atomic_work);
>   private->data = of_device_get_match_data(dev);
>  
> - private->config_regs = syscon_node_to_regmap(dev->of_node);
> - if (IS_ERR(private->config_regs))
> - return PTR_ERR(private->config_regs);
> + /* Check if called from mfd */
> + if (!dev->of_node) {
> + mmsys_private = dev_get_drvdata(pdev->dev.parent);

Why do you directly access parent's driver data? You just need the
device node of mmsys, maybe you could refer to [1].

[1]
https://elixir.free-electrons.com/linux/latest/source/drivers/reset/reset-berlin.c#L78

Regards,
CK

> + private->data = (struct mtk_mmsys_driver_data *)
> + platform_get_device_id(pdev)->driver_data;
> + private->config_regs =
> + syscon_node_to_regmap(mmsys_private->of_node);
> + parent_node = mmsys_private->of_node->parent;
> + } else {
> + private->config_regs = syscon_node_to_regmap(dev->of_node);
> + if (IS_ERR(private->config_regs))
> + return PTR_ERR(private->config_regs);
> + parent_node = dev->of_node->parent;
> + }
>  
>   /* Iterate over sibling DISP function blocks */
> - for_each_child_of_node(dev->of_node->parent, node) {
> + for_each_child_of_node(parent_node, node) {
>   const struct of_device_id *of_id;
>   enum mtk_ddp_comp_type comp_type;
>   int comp_id;
> @@ -553,13 +566,17 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, 
> mtk_drm_sys_suspend,
>mtk_drm_sys_resume);
>  
>  static const struct of_device_id mtk_drm_of_ids[] = {
> - { .compatible = "mediatek,mt2701-mmsys",
> -   .data = _mmsys_driver_data},
>   { .compatible = "mediatek,mt8173-mmsys",
> .data = _mmsys_driver_data},
>   { }
>  };
>  
> +static const struct platform_device_id mtk_drm_ids[] = {
> + { "drm-mt2701-mm", (kernel_ulong_t)_mmsys_driver_data },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
> +
>  static struct platform_driver mtk_drm_platform_driver = {
>   .probe  = mtk_drm_probe,
>   .remove = mtk_drm_remove,
> @@ -568,6 +585,7 @@ static struct platform_driver mtk_drm_platform_driver = {
>   .of_match_table = mtk_drm_of_ids,
>   .pm = _drm_pm_ops,
>   },
> + .id_table = mtk_drm_ids,
>  };
>  
>  static struct platform_driver * const mtk_drm_drivers[] = {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/8] drm/mediatek: Use regmap for register access

[CK Hu]

Hi, Matthias:

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> The mmsys memory space is shared between the drm and the
> clk driver. Use regmap to access it.
> 
> Signed-off-by: Matthias Brugger 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 30 +-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 13 -
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  2 +-
>  5 files changed, 26 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 658b8dd45b83..4c65873b4867 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -33,7 +33,7 @@
>   * @enabled: records whether crtc_enable succeeded
>   * @planes: array of 4 drm_plane structures, one for each overlay plane
>   * @pending_planes: whether any plane has pending changes to be applied
> - * @config_regs: memory mapped mmsys configuration register space
> + * @config_regs: regmap mapped mmsys configuration register space
>   * @mutex: handle to one of the ten disp_mutex streams
>   * @ddp_comp_nr: number of components in ddp_comp
>   * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
> @@ -48,7 +48,7 @@ struct mtk_drm_crtc {
>   struct drm_planeplanes[OVL_LAYER_NR];
>   boolpending_planes;
>  
> - void __iomem*config_regs;
> + struct regmap   *config_regs;
>   struct mtk_disp_mutex   *mutex;
>   unsigned intddp_comp_nr;
>   struct mtk_ddp_comp **ddp_comp;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8130f3dab661..1227d6db07da 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -185,16 +185,16 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
> cur,
>   return value;
>  }
>  
> -static void mtk_ddp_sout_sel(void __iomem *config_regs,
> +static void mtk_ddp_sout_sel(struct regmap *config_regs,
>enum mtk_ddp_comp_id cur,
>enum mtk_ddp_comp_id next)
>  {
>   if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
> - writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> -config_regs + DISP_REG_CONFIG_OUT_SEL);
> + regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
> + BLS_TO_DSI_RDMA1_TO_DPI1);
>  }
>  
> -void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> +void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next)
>  {
> @@ -202,20 +202,22 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
>  
>   value = mtk_ddp_mout_en(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) | value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg |= value;
> + regmap_write(config_regs, addr, reg);
>   }
>  
>   mtk_ddp_sout_sel(config_regs, cur, next);
>  
>   value = mtk_ddp_sel_in(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) | value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg |= value;
> + regmap_write(config_regs, addr, reg);
>   }
>  }
>  
> -void mtk_ddp_remove_comp_from_path(void __iomem *config_regs,
> +void mtk_ddp_remove_comp_from_path(struct regmap *config_regs,
>  enum mtk_ddp_comp_id cur,
>  enum mtk_ddp_comp_id next)
>  {
> @@ -223,14 +225,16 @@ void mtk_ddp_remove_comp_from_path(void __iomem 
> *config_regs,
>  
>   value = mtk_ddp_mout_en(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) & ~value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg &= ~value;
> + regmap_write(config_regs, addr, reg);
>   }
>  
>   value = mtk_ddp_sel_in(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) & ~value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg &= ~value;
> + regmap_write(config_regs, addr, reg);
>   }
>  }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> index f9a799168077..32e12f33b76a 100644
> 

Re: [PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Inki Dae]

2017년 11월 22일 22:14에 Marek Szyprowski 이(가) 쓴 글:
> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
> are contiguous, because of the underlying dma_alloc_attrs() function
> provides only such buffers. In such case it makes no sense to keep
> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
> failures for buffer contiguity checks in the subsequent operations on GEM
> objects.
> 
> Signed-off-by: Marek Szyprowski 
> CC: sta...@vger.kernel.org # v4.4+
> ---
> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
> support for exynos drm framework"), but this patch applies cleanly
> only to v4.4+ kernel releases due changes in the surrounding code.
> 
> Changelog:
> v2:
> - added warning message when buffer flags are updadated (requested by Inki)
> 
> v1: https://patchwork.kernel.org/patch/10034919/
> - initial version
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 077de014d610..4400efe3974a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
> drm_device *dev,
>   if (IS_ERR(exynos_gem))
>   return exynos_gem;
>  
> + if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) {
> + /*
> +  * when no IOMMU is available, all allocated buffers are
> +  * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag
> +  */
> + flags &= ~EXYNOS_BO_NONCONTIG;
> + DRM_WARN("Non-contiguous allocation is not supported without 
> IOMMU, falling back to contiguous buffer\n");

WARNING: line over 80 characters

I wil change above a warning like below if you are ok,
DRM_WARN("Changed to CONTIG buffer due to no IOMMU support.\n");


Thanks,
Inki Dae

> + }
> +
>   /* set memory type and cache attribute from user side. */
>   exynos_gem->flags = flags;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm for v4.15 (fixes/cleanups/one small feature)

[Dave Airlie]

Hi Linus,

This is just some bits and pieces for the second half of the merge window,

1. Remove the MSM dt-bindings file Rob managed to push in the previous pull.
2. Add a property/edid quirk to denote HMD devices, I had these
hanging around for a few weeks and Keith had done some work on them,
they are fairly self contained and small, and only affect people using
HTC Vive VR headsets so far.
3. amdgpu, tegra, tilcdc, fsl fixes
4. some imx-drm cleanups I missed, these seemed pretty small, and no
reason to hold off.

I have one TTM regression fix (fixes bochs-vga in qemu) sitting
locally awaiting review I'll probably send that in a separate pull
request tomorrow.

Dave.

The following changes since commit f150891fd9878ef0d9197c4e8451ce67c3bdd014:

  Merge tag 'exynos-drm-next-for-v4.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-next (2017-11-14 14:12:43 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.15-part2

for you to fetch changes up to 98ecf1a308977505381b5c360b039a84cf67513c:

  dt-bindings: remove file that was added accidentally (2017-11-23
14:10:39 +1000)


fixes/cleanups for rc1, non-desktop flags for VR


Alex Deucher (2):
  Revert "drm/radeon: dont switch vt on suspend"
  drm/amdgpu: don't skip attributes when powerplay is enabled

Christian König (2):
  drm/amdgpu: make AMDGPU_VA_RESERVED_SIZE 64bit
  drm/amdgpu: set f_mapping on exported DMA-bufs

Cihangir Akturk (1):
  drm/imx: switch to drm_*_get(), drm_*_put() helpers

Colin Ian King (1):
  drm/amd/powerplay: fix copy-n-paste error on vddci_buf index

Dave Airlie (9):
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-fsl-dcu-fixes-for-v4.15' of
http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next
  Merge tag 'drm/tegra/for-4.15-rc1-fixes' of
git://anongit.freedesktop.org/tegra/linux into drm-next
  Merge tag 'imx-drm-next-2017-10-18' of
git://git.pengutronix.de/git/pza/linux into drm-next
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'tilcdc-4.15-fixes' of https://github.com/jsarha/linux
into drm-next
  drm: add connector info/property for non-desktop displays [v2]
  drm/fb: add support for not enabling fbcon on non-desktop displays [v2]
  drm/edid: quirk HTC vive headset as non-desktop. [v2]

Emily Deng (1):
  drm/amdgpu: Fix null pointer issue in amdgpu_cs_wait_any_fence

Eric Huang (1):
  drm/amd/powerplay: fix unfreeze level smc message for smu7

Fabio Estevam (1):
  gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

Jyri Sarha (1):
  drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding support

Ken Wang (2):
  drm/amdgpu: Remove check which is not valid for certain VBIOS
  drm/amdgpu: Add common golden settings for GFX9

Laurent Pinchart (1):
  drm/fsl-dcu: Don't set connector DPMS property

Lucas Stach (1):
  drm/imx: parallel-display: use correct connector enum

Marco Franchi (1):
  dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

Monk Liu (2):
  drm/amdgpu:fix memleak in takedown
  drm/amdgpu:fix memleak

Nicolai Hähnle (1):
  drm/amdgpu/gfx9: implement wave VGPR reading

Rex Zhu (2):
  drm/amd/pp: fix dpm randomly failed on Vega10
  drm/amd/pp: fix typecast error in powerplay.

Rob Clark (1):
  dt-bindings: remove file that was added accidentally

Roger He (2):
  drm/amd/amdgpu: if visible VRAM allocation fail, fall back to
invisible try again
  drm/amd/amdgpu: fix over-bound accessing in amdgpu_cs_wait_any_fence

Stefan Agner (2):
  drm/fsl-dcu: avoid disabling pixel clock twice on suspend
  drm/fsl-dcu: enable IRQ before drm_atomic_helper_resume()

Thierry Reding (1):
  drm/tegra: sor: Reimplement pad clock

Tom St Denis (1):
  drm/amd/amdgpu: Fix wave mask in amdgpu_debugfs_wave_read() (v2)

Wang Hongcheng (1):
  drm/amdgpu: fix rmmod KCQ disable failed error

Xiangliang.Yu (1):
  drm/amdgpu: fix kernel hang when starting VNC server

ozeng (1):
  drm/amdgpu: Properly allocate VM invalidate eng v2

 .../bindings/display/imx/fsl-imx-drm.txt   |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c   |   6 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  43 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c|   6 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |   3 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|   2 -
 

[PATCH] drm/ttm: don't attempt to use hugepages if dma32 requested (v2)

[Dave Airlie]

From: Dave Airlie 

The commit below introduced thp support for ttm allocations, however it didn't
take into account the case where dma32 was requested. Some drivers always 
request
dma32, and the bochs driver is one of those.

This fixes an oops:

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns 
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge 
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw 
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables 
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev 
snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev 
drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport 
i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc 
virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio 
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006
[   30.120840] RDX:  RSI: 0009 RDI: 
[   30.121443] RBP: 923a760d6000 R08:  R09: 0006
[   30.122039] R10: 0040 R11: 0300 R12: 923a729273c0
[   30.122629] R13:  R14:  R15: 923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0() 
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI: 7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09: 0001
[   30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff 
ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 
0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

v2: handle free path as well.

Reported-by: Laura Abbott 
Reported-by: Adam Williamson 
Fixes: 0284f1ead87463bc17cf5e81a24fc65c052486f3 (drm/ttm: add transparent huge 
page support for cached allocations v2)
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 316f831..b0551aa 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -744,12 +744,14 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
}
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   for (j = 0; j < HPAGE_PMD_NR; ++j)
-   if (p++ != pages[i + j])
-   break;
+   if (!(flags & TTM_PAGE_FLAG_DMA32)) {
+   for (j = 0; j < HPAGE_PMD_NR; ++j)
+   if (p++ != pages[i + j])
+   break;
 
-   if (j == HPAGE_PMD_NR)
-   

[PATCH] drm/ttm: don't attempt to use hugepages if dma32 requested

[Dave Airlie]

From: Dave Airlie 

The commit below introduced thp support for ttm allocations, however it didn't
take into account the case where dma32 was requested. Some drivers always 
request
dma32, and the bochs driver is one of those.

This fixes an oops:

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns 
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge 
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw 
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables 
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev 
snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev 
drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport 
i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc 
virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio 
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006
[   30.120840] RDX:  RSI: 0009 RDI: 
[   30.121443] RBP: 923a760d6000 R08:  R09: 0006
[   30.122039] R10: 0040 R11: 0300 R12: 923a729273c0
[   30.122629] R13:  R14:  R15: 923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0() 
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI: 7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09: 0001
[   30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff 
ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 
0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

Reported-by: Laura Abbott 
Reported-by: Adam Williamson 
Fixes: 0284f1ead87463bc17cf5e81a24fc65c052486f3 (drm/ttm: add transparent huge 
page support for cached allocations v2)
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 316f831..1d3dfce 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -865,20 +865,22 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 
i = 0;
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   while (npages >= HPAGE_PMD_NR) {
-   gfp_t huge_flags = gfp_flags;
+   if (!(gfp_flags & GFP_DMA32)) {
+   while (npages >= HPAGE_PMD_NR) {
+   gfp_t huge_flags = gfp_flags;
 
-   huge_flags |= GFP_TRANSHUGE;
-   huge_flags &= ~__GFP_MOVABLE;
-   huge_flags &= ~__GFP_COMP;
-   p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
-   

Re: Regression in TTM driver w/Linus' master

[Dave Airlie]

On 23 November 2017 at 11:17, Laura Abbott  wrote:
> Hi,
>
> Fedora QA testing reported a panic when booting up VMs
> using qmeu vga drivers
> (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)
>
> [   30.108507] [ cut here ]
> [   30.108920] kernel BUG at ./include/linux/gfp.h:408!
> [   30.109356] invalid opcode:  [#1] SMP
> [   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
> nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
> ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
> iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
> snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass
> ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm
> joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore
> parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp
> mrp stp llc virtio_net
> [   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul
> crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio
> ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
> [   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
> 4.15.0-0.rc0.git6.1.fc28.x86_64 #1
> [   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-2.fc27 04/01/2014
> [   30.118866] task: 923a77e03380 task.stack: a78182228000
> [   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
> [   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
> [   30.120250] RAX: 0001 RBX: 014382c6 RCX:
> 0006
> [   30.120840] RDX:  RSI: 0009 RDI:
> 
> [   30.121443] RBP: 923a760d6000 R08:  R09:
> 0006
> [   30.122039] R10: 0040 R11: 0300 R12:
> 923a729273c0
> [   30.122629] R13:  R14:  R15:
> 923a7483d400
> [   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
> knlGS:
> [   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
> [   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
> 06f0
> [   30.124968] Call Trace:
> [   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
> [   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
> [   30.125964]  __do_fault+0x19/0x11e
> [   30.126255]  __handle_mm_fault+0xcd3/0x1260
> [   30.126609]  handle_mm_fault+0x14c/0x310
> [   30.126947]  __do_page_fault+0x28c/0x530
> [   30.127282]  do_page_fault+0x32/0x270
> [   30.127593]  async_page_fault+0x22/0x30
> [   30.127922] RIP: 0033:0x7fe48aae39a8
> [   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
> [   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
> 7fe457b73040
> [   30.129259] RDX: 0030 RSI:  RDI:
> 7fe457b73000
> [   30.129855] RBP: 0300 R08: 000c R09:
> 0001
> [   30.130457] R10: 0001 R11: 0246 R12:
> 55cd4c1041a0
> [   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
> 0400
> [   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f
> ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff
> <0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
> [   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
> [   30.133836] ---[ end trace d4f1deb60784f40a ]---
>
> This is based off of Linus' master branch at
> c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
> Configs are at
> https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0
>

Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc huge
dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression in TTM driver w/Linus' master

[Adam Williamson]

On Wed, 2017-11-22 at 17:17 -0800, Laura Abbott wrote:
> Hi,
> 
> Fedora QA testing reported a panic when booting up VMs
> using qmeu vga drivers 
> (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)
> 
> [   30.108507] [ cut here ]
> [   30.108920] kernel BUG at ./include/linux/gfp.h:408!
> [   30.109356] invalid opcode:  [#1] SMP
> [   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns 
> nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
> xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge 
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
> ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
> nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw 
> iptable_security ebtable_filter ebtables ip6table_filter ip6_tables 
> snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass 
> ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm 
> joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore 
> parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp 
> mrp stp llc virtio_net
> [   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul 
> crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio 
> ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
> [   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 
> 4.15.0-0.rc0.git6.1.fc28.x86_64 #1
> [   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-2.fc27 04/01/2014
> [   30.118866] task: 923a77e03380 task.stack: a78182228000
> [   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
> [   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
> [   30.120250] RAX: 0001 RBX: 014382c6 RCX: 
> 0006
> [   30.120840] RDX:  RSI: 0009 RDI: 
> 
> [   30.121443] RBP: 923a760d6000 R08:  R09: 
> 0006
> [   30.122039] R10: 0040 R11: 0300 R12: 
> 923a729273c0
> [   30.122629] R13:  R14:  R15: 
> 923a7483d400
> [   30.123223] FS:  7fe48da7dac0() GS:923a7cc0() 
> knlGS:
> [   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
> [   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 
> 06f0
> [   30.124968] Call Trace:
> [   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
> [   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
> [   30.125964]  __do_fault+0x19/0x11e
> [   30.126255]  __handle_mm_fault+0xcd3/0x1260
> [   30.126609]  handle_mm_fault+0x14c/0x310
> [   30.126947]  __do_page_fault+0x28c/0x530
> [   30.127282]  do_page_fault+0x32/0x270
> [   30.127593]  async_page_fault+0x22/0x30
> [   30.127922] RIP: 0033:0x7fe48aae39a8
> [   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
> [   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 
> 7fe457b73040
> [   30.129259] RDX: 0030 RSI:  RDI: 
> 7fe457b73000
> [   30.129855] RBP: 0300 R08: 000c R09: 
> 0001
> [   30.130457] R10: 0001 R11: 0246 R12: 
> 55cd4c1041a0
> [   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 
> 0400
> [   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff 
> ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 
> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
> [   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
> [   30.133836] ---[ end trace d4f1deb60784f40a ]---
> 
> This is based off of Linus' master branch at 
> c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
> Configs are at 
> https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0

To be as precise as I can at present, this appeared somewhere between
these two Fedora kernel package builds:

Package:  kernel-4.15.0-0.rc0.git6.1.fc28
Old package:  kernel-4.15.0-0.rc0.git3.1.fc28

(that is, 'git3' did not have the issue, 'git6' does). Laura could
translate that to a delta that'd mean more to you folks, I expect.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Regression in TTM driver w/Linus' master

[Laura Abbott]

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers 
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns 
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge 
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw 
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables 
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev 
snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev 
drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport 
i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc 
virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio 
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006
[   30.120840] RDX:  RSI: 0009 RDI: 
[   30.121443] RBP: 923a760d6000 R08:  R09: 0006
[   30.122039] R10: 0040 R11: 0300 R12: 923a729273c0
[   30.122629] R13:  R14:  R15: 923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0() 
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI: 7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09: 0001
[   30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff ff ff 
40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 0f ff 
e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at 
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at 
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0


Thanks,
Laura
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[John Stultz]

On Tue, Nov 21, 2017 at 12:17 AM, Hans Verkuil  wrote:
> If the device tree for a board did not specify a cec clock, then
> adv7511_cec_init would return an error, which would cause adv7511_probe()
> to fail and thus there is no HDMI output.
>
> There is no need to have adv7511_probe() fail if the CEC initialization
> fails, so just change adv7511_cec_init() to a void function. In addition,
> adv7511_cec_init() should just return silently if the cec clock isn't
> found and show a message for any other errors.
>
> An otherwise correct cleanup patch from Dan Carpenter turned this broken
> failure handling into a kernel Oops, so bisection points to commit
> 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
> than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").
>
> Based on earlier patches from Arnd and John.
>
> Reported-by: Naresh Kamboju 
> Cc: Xinliang Liu 
> Cc: Dan Carpenter 
> Cc: Sean Paul 
> Cc: Archit Taneja 
> Cc: John Stultz 
> Link: https://bugs.linaro.org/show_bug.cgi?id=3345
> Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
> Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
> Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
> Signed-off-by: Hans Verkuil 
> Tested-by: Hans Verkuil 
> ---
> This rework of Arnd and John's patches goes a bit further and just silently
> exits if there is no cec clock defined in the dts. I'm sure that's the
> reason why the kirin board failed on this. BTW: if the kirin board DOES
> support cec, then it would be nice if it can be hooked up in the dts!
>
> Tested with my Dragonboard and Renesas Koelsch board. Also tested what
> happens when probing is deferred due to missing cec clock.
>
> John, can you test this again?

Sorry I didn't get back to you yesterday on this!

Seems to be working ok for me!

Tested-by: John Stultz 

thanks!
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage

[Eric Anholt]

Boris Brezillon  writes:

> On Wed, 22 Nov 2017 13:16:08 -0800
> Eric Anholt  wrote:
>
>> Boris Brezillon  writes:
>> 
>> > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
>> > passed a refcount object that has its counter set to 0. In this driver,
>> > this is a valid use case since we want to increment ->usecnt only when
>> > the BO object starts to be used by real HW components and this is
>> > definitely not the case when the BO is created.
>> >
>> > Fix the problem by using refcount_inc_not_zero() instead of
>> > refcount_inc() and fallback to refcount_set(1) when
>> > refcount_inc_not_zero() returns false. Note that this 2-steps operation
>> > is not racy here because the whole section is protected by a mutex
>> > which guarantees that the counter does not change between the
>> > refcount_inc_not_zero() and refcount_set() calls.  
>> 
>> If we're not following the model, and protecting the refcount by a
>> mutex, shouldn't we just be using addition and subtraction instead of
>> refcount's atomics?
>
> Actually, this mutex is protecting the bo->madv value which has to be
> checked when the counter reaches 0 (when decrementing) or 1 (when
> incrementing). We just benefit from this protection here, but ideally
> it would be better to have an refcount_inc_allow_zero() as suggested by
> Daniel.

Let me restate this to see if it makes sense: The refcount is always >=
0, this is is the only path that increases the refcount from 0 to 1, and
it's (incidentally) protected by a mutex, so there's no race between the
attempted increase from nonzero and the set from nonzero to 1.

This seems fine to me as a bugfix.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage

[Boris Brezillon]

On Wed, 22 Nov 2017 13:16:08 -0800
Eric Anholt  wrote:

> Boris Brezillon  writes:
> 
> > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
> > passed a refcount object that has its counter set to 0. In this driver,
> > this is a valid use case since we want to increment ->usecnt only when
> > the BO object starts to be used by real HW components and this is
> > definitely not the case when the BO is created.
> >
> > Fix the problem by using refcount_inc_not_zero() instead of
> > refcount_inc() and fallback to refcount_set(1) when
> > refcount_inc_not_zero() returns false. Note that this 2-steps operation
> > is not racy here because the whole section is protected by a mutex
> > which guarantees that the counter does not change between the
> > refcount_inc_not_zero() and refcount_set() calls.  
> 
> If we're not following the model, and protecting the refcount by a
> mutex, shouldn't we just be using addition and subtraction instead of
> refcount's atomics?

Actually, this mutex is protecting the bo->madv value which has to be
checked when the counter reaches 0 (when decrementing) or 1 (when
incrementing). We just benefit from this protection here, but ideally
it would be better to have an refcount_inc_allow_zero() as suggested by
Daniel.

Anyway, I can also use a regular counter and protect it with the madv
mutex, it's just that I thought using the existing refcount
infrastructure would be safer than open-coding it (actually, I found
several unbalanced refcounting issues thanks to this API while
developing the feature).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/6] drm/i915: export the stolen region as a resource

[Matthew Auld]

We duplicate the stolen discovery code in early-quirks and in i915,
however if we just export the region as a resource from early-quirks we
can nuke the duplication.

Suggested-by: Joonas Lahtinen 
Suggested-by: Chris Wilson 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: dri-devel@lists.freedesktop.org
Cc: x...@kernel.org
---
 arch/x86/kernel/early-quirks.c |   6 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c|  51 +--
 drivers/gpu/drm/i915/i915_gem_stolen.c | 109 +
 include/drm/i915_drm.h |   3 +
 4 files changed, 13 insertions(+), 156 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 1e82f787c160..a98a51cd15a7 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -531,6 +531,9 @@ static const struct pci_device_id intel_early_ids[] 
__initconst = {
INTEL_CNL_IDS(_early_ops),
 };
 
+struct resource intel_graphics_stolen_res = DEFINE_RES_MEM(0, 0);
+EXPORT_SYMBOL(intel_graphics_stolen_res);
+
 static void __init
 intel_graphics_stolen(int num, int slot, int func,
  const struct intel_early_ops *early_ops)
@@ -548,6 +551,9 @@ intel_graphics_stolen(int num, int slot, int func,
printk(KERN_INFO "Reserving Intel graphics memory at %pa-%pa\n",
   , );
 
+   intel_graphics_stolen_res.start = base;
+   intel_graphics_stolen_res.end = end;
+
/* Mark this space as reserved */
e820__range_add(base, size, E820_TYPE_RESERVED);
e820__update_table(e820_table);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e101b9a98957..cccd0cb51e09 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2949,50 +2949,6 @@ static unsigned int chv_get_total_gtt_size(u16 gmch_ctrl)
return 0;
 }
 
-static size_t gen6_get_stolen_size(u16 snb_gmch_ctl)
-{
-   snb_gmch_ctl >>= SNB_GMCH_GMS_SHIFT;
-   snb_gmch_ctl &= SNB_GMCH_GMS_MASK;
-   return (size_t)snb_gmch_ctl << 25; /* 32 MB units */
-}
-
-static size_t gen8_get_stolen_size(u16 bdw_gmch_ctl)
-{
-   bdw_gmch_ctl >>= BDW_GMCH_GMS_SHIFT;
-   bdw_gmch_ctl &= BDW_GMCH_GMS_MASK;
-   return (size_t)bdw_gmch_ctl << 25; /* 32 MB units */
-}
-
-static size_t chv_get_stolen_size(u16 gmch_ctrl)
-{
-   gmch_ctrl >>= SNB_GMCH_GMS_SHIFT;
-   gmch_ctrl &= SNB_GMCH_GMS_MASK;
-
-   /*
-* 0x0  to 0x10: 32MB increments starting at 0MB
-* 0x11 to 0x16: 4MB increments starting at 8MB
-* 0x17 to 0x1d: 4MB increments start at 36MB
-*/
-   if (gmch_ctrl < 0x11)
-   return (size_t)gmch_ctrl << 25;
-   else if (gmch_ctrl < 0x17)
-   return (size_t)(gmch_ctrl - 0x11 + 2) << 22;
-   else
-   return (size_t)(gmch_ctrl - 0x17 + 9) << 22;
-}
-
-static size_t gen9_get_stolen_size(u16 gen9_gmch_ctl)
-{
-   gen9_gmch_ctl >>= BDW_GMCH_GMS_SHIFT;
-   gen9_gmch_ctl &= BDW_GMCH_GMS_MASK;
-
-   if (gen9_gmch_ctl < 0xf0)
-   return (size_t)gen9_gmch_ctl << 25; /* 32 MB units */
-   else
-   /* 4MB increments starting at 0xf0 for 4MB */
-   return (size_t)(gen9_gmch_ctl - 0xf0 + 1) << 22;
-}
-
 static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
 {
struct drm_i915_private *dev_priv = ggtt->base.i915;
@@ -3343,14 +3299,13 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
+   ggtt->stolen_size = resource_size(_graphics_stolen_res);
+
if (INTEL_GEN(dev_priv) >= 9) {
-   ggtt->stolen_size = gen9_get_stolen_size(snb_gmch_ctl);
size = gen8_get_total_gtt_size(snb_gmch_ctl);
} else if (IS_CHERRYVIEW(dev_priv)) {
-   ggtt->stolen_size = chv_get_stolen_size(snb_gmch_ctl);
size = chv_get_total_gtt_size(snb_gmch_ctl);
} else {
-   ggtt->stolen_size = gen8_get_stolen_size(snb_gmch_ctl);
size = gen8_get_total_gtt_size(snb_gmch_ctl);
}
 
@@ -3408,7 +3363,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
-   ggtt->stolen_size = gen6_get_stolen_size(snb_gmch_ctl);
+   ggtt->stolen_size = resource_size(_graphics_stolen_res);
 
size = gen6_get_total_gtt_size(snb_gmch_ctl);
ggtt->base.total = (size / sizeof(gen6_pte_t)) << PAGE_SHIFT;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 

Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage

[Eric Anholt]

Boris Brezillon  writes:

> With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
> passed a refcount object that has its counter set to 0. In this driver,
> this is a valid use case since we want to increment ->usecnt only when
> the BO object starts to be used by real HW components and this is
> definitely not the case when the BO is created.
>
> Fix the problem by using refcount_inc_not_zero() instead of
> refcount_inc() and fallback to refcount_set(1) when
> refcount_inc_not_zero() returns false. Note that this 2-steps operation
> is not racy here because the whole section is protected by a mutex
> which guarantees that the counter does not change between the
> refcount_inc_not_zero() and refcount_set() calls.

If we're not following the model, and protecting the refcount by a
mutex, shouldn't we just be using addition and subtraction instead of
refcount's atomics?


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

--- Comment #9 from Gregor Münch  ---
Created attachment 135674
  --> https://bugs.freedesktop.org/attachment.cgi?id=135674=edit
Shadow of Mordor benchmark current amd-staging kernel shader cache

This is the situation after the shader cache kicked in. Seems to be not any
different.

-- 
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 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

--- Comment #8 from Gregor Münch  ---
Created attachment 135673
  --> https://bugs.freedesktop.org/attachment.cgi?id=135673=edit
Shadow of Mordor benchmark older amd-staging kernel

-- 
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 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

--- Comment #7 from Gregor Münch  ---
Created attachment 135672
  --> https://bugs.freedesktop.org/attachment.cgi?id=135672=edit
Shadow of Mordor benchmark current amd-staging kernel

This is current situation...
I dont know if this helps.

-- 
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

[PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage

[Boris Brezillon]

With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
passed a refcount object that has its counter set to 0. In this driver,
this is a valid use case since we want to increment ->usecnt only when
the BO object starts to be used by real HW components and this is
definitely not the case when the BO is created.

Fix the problem by using refcount_inc_not_zero() instead of
refcount_inc() and fallback to refcount_set(1) when
refcount_inc_not_zero() returns false. Note that this 2-steps operation
is not racy here because the whole section is protected by a mutex
which guarantees that the counter does not change between the
refcount_inc_not_zero() and refcount_set() calls.

Fixes: b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
Reported-by: Stefan Wahren 
Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 4ae45d7dac42..2decc8e2c79f 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -637,7 +637,8 @@ int vc4_bo_inc_usecnt(struct vc4_bo *bo)
mutex_lock(>madv_lock);
switch (bo->madv) {
case VC4_MADV_WILLNEED:
-   refcount_inc(>usecnt);
+   if (!refcount_inc_not_zero(>usecnt))
+   refcount_set(>usecnt, 1);
ret = 0;
break;
case VC4_MADV_DONTNEED:
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103850

--- Comment #1 from yunt...@gmail.com ---
Created attachment 135671
  --> https://bugs.freedesktop.org/attachment.cgi?id=135671=edit
Unturned crash - bt full

-- 
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 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103850

Bug ID: 103850
   Summary: "Quern" game crashes on start-up
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: yunt...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135670
  --> https://bugs.freedesktop.org/attachment.cgi?id=135670=edit
Quern crash - bt full

Quern crashes before showing the main menu. 
Same happens with "Unturned" game, with pretty much identical stack.

Started through Steam, on Fedora 26 with self-compiled mesa 17.3.0-rc5.
AMD Vega 64.

Possibly duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=101675

Backtrace (bt full in attachment):

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fb8d09d3800 in __GI_abort () at abort.c:89
#2  0x7fb8cdfbec4a in ?? ()
   from /home/yunta/.local/share/Steam/steamapps/common/Quern - Undying
Thoughts/Quern_Data/Mono/x86_64/libmono.so
#3  
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5  0x7fb8d09d3800 in __GI_abort () at abort.c:89
#6  0x7fb8d0a17bb1 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7fb8d0b379f8 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
#7  0x7fb8d0a22a59 in malloc_printerr (ar_ptr=,
ptr=, str=0x7fb8d0b345e6 "free(): invalid size",
action=) at malloc.c:5077
#8  _int_free (av=, p=, have_lock=0) at
malloc.c:3873
#9  0x7fb8d0a283be in __GI___libc_free (mem=) at
malloc.c:2947
#10 0x7fb8c57d2bb6 in check_explicit_uniform_locations (ctx=0x3605410,
prog=0x7fb8ac003b60) at glsl/linker.cpp:3532
#11 0x7fb8c57d6029 in link_shaders (ctx=0x3605410, prog=0x7fb8ac003b60) at
glsl/linker.cpp:4968
#12 0x7fb8c56bfcde in _mesa_glsl_link_shader (ctx=0x3605410,
prog=0x7fb8ac003b60) at program/ir_to_mesa.cpp:3111
#13 0x7fb8c54dcc6d in create_new_program (ctx=0x3605410,
key=0x7fb8b3ffe520) at main/ff_fragment_shader.cpp:1126
#14 0x7fb8c54dcd26 in _mesa_get_fixed_func_fragment_program (ctx=0x3605410)
at main/ff_fragment_shader.cpp:1156
#15 0x7fb8c55c626a in update_program (ctx=ctx@entry=0x3605410) at
main/state.c:134
#16 0x7fb8c55c6528 in _mesa_update_state_locked (ctx=ctx@entry=0x3605410)
at main/state.c:356
#17 0x7fb8c55c65c1 in _mesa_update_state (ctx=ctx@entry=0x3605410) at
main/state.c:386
#18 0x7fb8c55dd258 in texture_sub_image (ctx=ctx@entry=0x3605410,
dims=dims@entry=2, texObj=0x7fb8ac000fd0,
texImage=texImage@entry=0x7fb8ac001480, target=target@entry=3553,
level=level@entry=0, xoffset=0, yoffset=0, zoffset=0, width=4,
height=4, depth=1, format=6408, type=5121, pixels=0x3670590, dsa=false) at
main/teximage.c:3227
#19 0x7fb8c55dff7a in texsubimage_err (ctx=0x3605410, dims=2, target=3553,
level=0, xoffset=0, yoffset=0, zoffset=0, width=4, height=4,
depth=1, format=6408, type=5121, pixels=0x3670590,
callerName=0x7fb8c5dc32a6 "glTexSubImage2D") at main/teximage.c:3304
#20 0x7fb8c55e4368 in _mesa_TexSubImage2D (target=,
level=, xoffset=,
yoffset=, width=, height=,
format=6408, type=5121, pixels=0x3670590) at main/teximage.c:3522
#21 0x00f86cbd in ?? ()
#22 0x00f6072f in ?? ()
#23 0x00f0480a in ?? ()
#24 0x00f09c4f in ?? ()
#25 0x00f002f7 in ?? ()
#26 0x008e0158 in ?? ()
#27 0x7fb8d221536d in start_thread (arg=0x7fb8b3fff700) at
pthread_create.c:456
#28 0x7fb8d0aabe1f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

-- 
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 103814] incorrect dust rendering in hl2ep1 without some R600_DEBUG options

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103814

Hleb Valoshka <375...@gmail.com> changed:

   What|Removed |Added

Summary|incorrect dust rendering in |incorrect dust rendering in
   |hl2ep1 with mesa 17.2 and   |hl2ep1 without some
   |above   |R600_DEBUG options

--- Comment #1 from Hleb Valoshka <375...@gmail.com> ---
Actually it's caused by *absence* of one or more R600_DEBUG options.
When I run the game with
R600_DEBUG=forcedma,hyperz,llvm,precompile,sisched,sbcl,sbsafemath I have good
rendering. Without it I have the described problem. I'll try to figure out
which option fixes rendering.

-- 
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 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100745

--- Comment #8 from Benjamin Bellec  ---
I hit the same problem today after enabling amdgpu.dc=1
The screen doesn't light up at all if I boot the kernel with amdgpu.dc=1

Config is:
Fedora 27 + kernel 4.15.0-0.rc0.git7.1.fc28.x86_64
Radeon R9 380X
Dell U2414H


dmesg error is:
kernel: [drm:dm_logger_write [amdgpu]] *ERROR* perform_clock_recovery_sequence:
Link Training Error, could not  get CR after 100 tries.

-- 
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 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100745

Benjamin Bellec  changed:

   What|Removed |Added

 CC||b.bel...@gmail.com

--- Comment #7 from Benjamin Bellec  ---
Created attachment 135668
  --> https://bugs.freedesktop.org/attachment.cgi?id=135668=edit
dmesg log error

-- 
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 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Ville Syrjälä]

On Fri, Nov 17, 2017 at 08:40:02AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/16/2017 9:51 PM, Ville Syrjälä wrote:
> > On Thu, Nov 16, 2017 at 08:10:55PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> >>> 3D to 2D mode in a timely fashion if the source simply stops sending the
> >>> HDMI infoframe. The suggested workaround is to keep sending the
> >>> infoframe even when strictly not necessary (ie. no VIC and no S3D).
> >>> HDMI 1.4 does allow for this behaviour, stating that sending the
> >>> infoframe is optional in this case.
> >>>
> >>> The infoframe was first specified in HDMI 1.4, so in theory sinks
> >>> predating that may not appreciate us sending an uknown infoframe
> >>> their way. To avoid regressions let's try to determine if the sink
> >>> supports the infoframe or not. Unfortunately there's no direct way
> >>> to do that, so instead we'll just check if we managed to parse any
> >>> HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
> >>> sink will accept the infoframe. Also if the EDID contains the HDMI
> >>> 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
> >>> the infoframe.
> >> I am trying to get some sense from HDMI 2.0 spec section 10.2.1, which
> >> talks about
> >> switch from 3D to 2D.  To me it looks like:
> >> If (sending_to_hdmi2_sinks) {
> >>   - for 3d modes send HF-VSIF
> >>   - for 2d modes && defined in H14b HFVSIF, send H14B-VSIF
> >> When you switch from 3d->2d {
> >>- send_HF-VSIF with 3D_valid bit = 0/1
> >>}
> >> } else { /* HDMI 1.4b sinks from Appendix F */
> >>   -  send H14b-VSIF with HDMI_video_format[2:0 = 0 OR 1]
> >> }
> >>
> >> Should we add a is_hdmi2 check and separate these cases ?
> > We don't support the HDMI forum infoframe. Maybe someone forgot to
> > implement that when adding the rest of HDMI 2.0 support? ;)
> How to make an 'embarrassed smile ' smiley :) ?
> Will start looking into it. Meanwhile
> Reviewed-by: Shashank Sharma 

Patches 1-2 pushed to drm-misc-next. Thanks for the review.

> >>> v2: Fix the getting has_hdmi_infoframe from display_info
> >>>   Always fail constructing the infoframe if the display
> >>>   possibly can't handle it
> >>>
> >>> Cc: Shashank Sharma 
> >>> Cc: Andrzej Hajda 
> >>> Cc: Laurent Pinchart 
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
> >>>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
> >>>drivers/gpu/drm/drm_edid.c| 34 
> >>> +--
> >>>drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >>>drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
> >>>drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
> >>>drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
> >>>drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
> >>>drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
> >>>drivers/gpu/drm/zte/zx_hdmi.c |  1 +
> >>>include/drm/drm_connector.h   |  5 +
> >>>include/drm/drm_edid.h|  1 +
> >>>12 files changed, 57 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> >>> b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>> index b7eb704d0a8a..4417276ba02e 100644
> >>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>> @@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge 
> >>> *bridge,
> >>>   union hdmi_infoframe frm;
> >>>   u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
> >>>
> >>> + /* FIXME: We need the connector here */
> >>>   drm_hdmi_vendor_infoframe_from_display_mode(
> >>> - , adjusted_mode);
> >>> + , NULL, adjusted_mode);
> >>>   vic = frm.vendor.hdmi.vic;
> >>>   if (vic >= ARRAY_SIZE(mhl_vic))
> >>>   vic = 0;
> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> index a64ce7112288..b172139502d6 100644
> >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> @@ -1437,7 +1437,9 @@ static void 
> >>> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> >>>   u8 buffer[10];
> >>>   ssize_t err;
> >>>
> >>> - err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);
> >>> + err = 

Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

[Boris Brezillon]

On Wed, 22 Nov 2017 19:13:09 +0100
Daniel Vetter <dan...@ffwll.ch> wrote:

> On Wed, Nov 22, 2017 at 6:51 PM, Boris Brezillon
> <boris.brezil...@free-electrons.com> wrote:
> > Hi Stefan,
> >
> > On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
> > Stefan Wahren <stefan.wah...@i2se.com> wrote:
> >  
> >> Hi Boris,
> >> if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with 
> >> sufficient CMA memory (32 MB), i'll get this warning during boot:
> >>
> >> [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops 
> >> [vc4])
> >> [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
> >> [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
> >> [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops 
> >> vc4_crtc_ops [vc4])
> >> [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops 
> >> vc4_crtc_ops [vc4])
> >> [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops 
> >> vc4_crtc_ops [vc4])
> >> [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops [vc4])
> >> [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
> >> [7.750841] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >> [7.757620] [drm] Driver supports precise vblank timestamp query.
> >> [7.811775] [ cut here ]
> >> [7.811780] refcount_t: increment on 0; use-after-free.
> >> [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 
> >> refcount_inc+0x44/0x50
> >> [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper 
> >> smsc95xx usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma 
> >> crc32_ce i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6
> >> [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 
> >> 4.14.0-next-20171122 #1
> >> [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
> >> [7.811958] task: 800036b91c00 task.stack: 0d6f
> >> [7.811967] pstate: 2005 (nzCv daif -PAN -UAO)
> >> [7.811974] pc : refcount_inc+0x44/0x50
> >> [7.811981] lr : refcount_inc+0x44/0x50
> >> [7.811984] sp : 0d6f3300
> >> [7.811988] x29: 0d6f3300 x28: 
> >> [7.811996] x27: 0003 x26: 800037107800
> >> [7.812004] x25: 0001 x24: 800035afdc00
> >> [7.812012] x23:  x22: 800035dfa600
> >> [7.812020] x21: 800035afd9b0 x20: 800035afd9a4
> >> [7.812027] x19:  x18: 
> >> [7.812034] x17: 0001 x16: 0019
> >> [7.812042] x15: 0001 x14: fff0
> >> [7.812049] x13: 090ae840 x12: 08fa2d50
> >> [7.812057] x11: 08fa2000 x10: 090ad000
> >> [7.812064] x9 :  x8 : 090b5c2f
> >> [7.812072] x7 :  x6 : 0015ee00
> >> [7.812079] x5 :  x4 : 
> >> [7.812087] x3 :  x2 : 800030047000
> >> [7.812094] x1 : 800036b91c00 x0 : 002b
> >> [7.812102] Call trace:
> >> [7.812109]  refcount_inc+0x44/0x50
> >> [7.812226]  vc4_bo_inc_usecnt+0x84/0x88 [vc4]
> >> [7.812310]  vc4_prepare_fb+0x40/0xf0 [vc4]
> >> [7.812460]  drm_atomic_helper_prepare_planes+0x54/0xf0 [drm_kms_helper]
> >> [7.812543]  vc4_atomic_commit+0x88/0x130 [vc4]
> >> [7.812868]  drm_atomic_commit+0x48/0x68 [drm]
> >> [7.813002]  restore_fbdev_mode_atomic+0x1d8/0x1e8 [drm_kms_helper]
> >> [7.813113]  restore_fbdev_mode+0x28/0x160 [drm_kms_helper]
> >> [7.813223]  
> >> drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 
> >> [drm_kms_helper]
> >> [7.813331]  drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper]
> >> [7.813346]  fbcon_init+0x4e8/0x538
> >> [7.813357]  visual_init+0xb4/0x108
> >> [7.813366]  do_bind_con_driver+0x1b8/0x3a0
> >> [7.813373]  do_take_over_console+0x150/0x1d0
> >> [7.813380]  do_fbcon_takeover+0x6c/0xf0
> >> [7.813387]  fbcon_event_notify+0x8fc/0x928
> >> [7.813399]  notifier_call_chain+0x50/0x90
> >> [7.813406]  __blocking_notifier_call_chain+0x4c/0x90
> >> [7.813413]  blocking_notifier_call_chain+0x14/0x20
> >> 

Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

[Daniel Vetter]

On Wed, Nov 22, 2017 at 6:51 PM, Boris Brezillon
<boris.brezil...@free-electrons.com> wrote:
> Hi Stefan,
>
> On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
> Stefan Wahren <stefan.wah...@i2se.com> wrote:
>
>> Hi Boris,
>> if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with 
>> sufficient CMA memory (32 MB), i'll get this warning during boot:
>>
>> [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
>> [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
>> [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
>> [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops 
>> [vc4])
>> [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops 
>> [vc4])
>> [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops 
>> [vc4])
>> [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops [vc4])
>> [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
>> [7.750841] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [7.757620] [drm] Driver supports precise vblank timestamp query.
>> [7.811775] [ cut here ]
>> [7.811780] refcount_t: increment on 0; use-after-free.
>> [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 
>> refcount_inc+0x44/0x50
>> [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper 
>> smsc95xx usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma 
>> crc32_ce i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6
>> [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 
>> 4.14.0-next-20171122 #1
>> [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
>> [7.811958] task: 800036b91c00 task.stack: 0d6f
>> [7.811967] pstate: 2005 (nzCv daif -PAN -UAO)
>> [7.811974] pc : refcount_inc+0x44/0x50
>> [7.811981] lr : refcount_inc+0x44/0x50
>> [7.811984] sp : 0d6f3300
>> [7.811988] x29: 0d6f3300 x28: 
>> [7.811996] x27: 0003 x26: 800037107800
>> [7.812004] x25: 0001 x24: 800035afdc00
>> [7.812012] x23:  x22: 800035dfa600
>> [7.812020] x21: 800035afd9b0 x20: 800035afd9a4
>> [7.812027] x19:  x18: 
>> [7.812034] x17: 0001 x16: 0019
>> [7.812042] x15: 0001 x14: fff0
>> [7.812049] x13: 090ae840 x12: 08fa2d50
>> [7.812057] x11: 08fa2000 x10: 090ad000
>> [7.812064] x9 :  x8 : 090b5c2f
>> [7.812072] x7 :  x6 : 0015ee00
>> [7.812079] x5 :  x4 : 
>> [7.812087] x3 :  x2 : 800030047000
>> [7.812094] x1 : 800036b91c00 x0 : 002b
>> [7.812102] Call trace:
>> [7.812109]  refcount_inc+0x44/0x50
>> [7.812226]  vc4_bo_inc_usecnt+0x84/0x88 [vc4]
>> [7.812310]  vc4_prepare_fb+0x40/0xf0 [vc4]
>> [7.812460]  drm_atomic_helper_prepare_planes+0x54/0xf0 [drm_kms_helper]
>> [7.812543]  vc4_atomic_commit+0x88/0x130 [vc4]
>> [7.812868]  drm_atomic_commit+0x48/0x68 [drm]
>> [7.813002]  restore_fbdev_mode_atomic+0x1d8/0x1e8 [drm_kms_helper]
>> [7.813113]  restore_fbdev_mode+0x28/0x160 [drm_kms_helper]
>> [7.813223]  drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 
>> [drm_kms_helper]
>> [7.813331]  drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper]
>> [7.813346]  fbcon_init+0x4e8/0x538
>> [7.813357]  visual_init+0xb4/0x108
>> [7.813366]  do_bind_con_driver+0x1b8/0x3a0
>> [7.813373]  do_take_over_console+0x150/0x1d0
>> [7.813380]  do_fbcon_takeover+0x6c/0xf0
>> [7.813387]  fbcon_event_notify+0x8fc/0x928
>> [7.813399]  notifier_call_chain+0x50/0x90
>> [7.813406]  __blocking_notifier_call_chain+0x4c/0x90
>> [7.813413]  blocking_notifier_call_chain+0x14/0x20
>> [7.813420]  fb_notifier_call_chain+0x1c/0x28
>> [7.813426]  register_framebuffer+0x1d0/0x2d8
>> [7.813533]  __drm_fb_helper_initial_config_and_unlock+0x1e8/0x350 
>> [drm_kms_helper]
>> [7.813639]  drm_fb_helper_initial_config+0x40/0x58 [drm_kms_helper]
>> [7.813747]  drm_fbdev_cma_init_with_funcs+0x88/0x158 [drm_kms_helper]
>> [7.813855]  drm_fbdev_cma_init+0x14/0x28 [drm_kms_helper]
>> [7.813943]  vc4_kms_load+0xa4/

Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

[Boris Brezillon]

Hi Stefan,

On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
Stefan Wahren <stefan.wah...@i2se.com> wrote:

> Hi Boris,
> if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with 
> sufficient CMA memory (32 MB), i'll get this warning during boot:
> 
> [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
> [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
> [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
> [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops 
> [vc4])
> [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops 
> [vc4])
> [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops 
> [vc4])
> [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops [vc4])
> [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
> [7.750841] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [7.757620] [drm] Driver supports precise vblank timestamp query.
> [7.811775] [ cut here ]
> [7.811780] refcount_t: increment on 0; use-after-free.
> [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 
> refcount_inc+0x44/0x50
> [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper smsc95xx 
> usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma crc32_ce 
> i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6
> [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 
> 4.14.0-next-20171122 #1
> [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
> [7.811958] task: 800036b91c00 task.stack: 0d6f
> [7.811967] pstate: 2005 (nzCv daif -PAN -UAO)
> [7.811974] pc : refcount_inc+0x44/0x50
> [7.811981] lr : refcount_inc+0x44/0x50
> [7.811984] sp : 0d6f3300
> [7.811988] x29: 0d6f3300 x28:  
> [7.811996] x27: 0003 x26: 800037107800 
> [7.812004] x25: 0001 x24: 800035afdc00 
> [7.812012] x23:  x22: 800035dfa600 
> [7.812020] x21: 800035afd9b0 x20: 800035afd9a4 
> [7.812027] x19:  x18:  
> [7.812034] x17: 0001 x16: 0019 
> [7.812042] x15: 0001 x14: fff0 
> [7.812049] x13: 090ae840 x12: 08fa2d50 
> [7.812057] x11: 08fa2000 x10: 090ad000 
> [7.812064] x9 :  x8 : 090b5c2f 
> [7.812072] x7 :  x6 : 0015ee00 
> [7.812079] x5 :  x4 :  
> [7.812087] x3 :  x2 : 800030047000 
> [7.812094] x1 : 800036b91c00 x0 : 002b 
> [7.812102] Call trace:
> [7.812109]  refcount_inc+0x44/0x50
> [7.812226]  vc4_bo_inc_usecnt+0x84/0x88 [vc4]
> [7.812310]  vc4_prepare_fb+0x40/0xf0 [vc4]
> [7.812460]  drm_atomic_helper_prepare_planes+0x54/0xf0 [drm_kms_helper]
> [7.812543]  vc4_atomic_commit+0x88/0x130 [vc4]
> [7.812868]  drm_atomic_commit+0x48/0x68 [drm]
> [7.813002]  restore_fbdev_mode_atomic+0x1d8/0x1e8 [drm_kms_helper]
> [7.813113]  restore_fbdev_mode+0x28/0x160 [drm_kms_helper]
> [7.813223]  drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 
> [drm_kms_helper]
> [7.813331]  drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper]
> [7.813346]  fbcon_init+0x4e8/0x538
> [7.813357]  visual_init+0xb4/0x108
> [7.813366]  do_bind_con_driver+0x1b8/0x3a0
> [7.813373]  do_take_over_console+0x150/0x1d0
> [7.813380]  do_fbcon_takeover+0x6c/0xf0
> [7.813387]  fbcon_event_notify+0x8fc/0x928
> [7.813399]  notifier_call_chain+0x50/0x90
> [7.813406]  __blocking_notifier_call_chain+0x4c/0x90
> [7.813413]  blocking_notifier_call_chain+0x14/0x20
> [7.813420]  fb_notifier_call_chain+0x1c/0x28
> [7.813426]  register_framebuffer+0x1d0/0x2d8
> [7.813533]  __drm_fb_helper_initial_config_and_unlock+0x1e8/0x350 
> [drm_kms_helper]
> [7.813639]  drm_fb_helper_initial_config+0x40/0x58 [drm_kms_helper]
> [7.813747]  drm_fbdev_cma_init_with_funcs+0x88/0x158 [drm_kms_helper]
> [7.813855]  drm_fbdev_cma_init+0x14/0x28 [drm_kms_helper]
> [7.813943]  vc4_kms_load+0xa4/0xf0 [vc4]
> [7.814026]  vc4_drm_bind+0x100/0x168 [vc4]
> [7.814038]  try_to_bring_up_master+0x144/0x1a8
> [7.814044]  component_master_add_with_match+0x9c/0xe0
> [7.814128]  vc4_platform_drm_probe+0xb4/0xf0 [vc4]
> [7.814137]  platform_drv_probe+0x58/0xc0
> [7.814146]  driver_probe_device+0x224/0x308
> [7.814153]  __driver_attach+0xac/0xb0
> [7.814

Re: [PATCH] drm/amd/display: fix memory leaks on error exit return

[Harry Wentland]

On 2017-11-22 11:47 AM, Colin King wrote:
> From: Colin Ian King 
> 
> Currently in the case where some of the allocations fail for dce110_tgv,
> dce110_xfmv, dce110_miv or dce110_oppv then the exit return path ends
> up leaking allocated objects. Fix this by kfree'ing them before returning.
> Also re-work the comparison of the null pointers to use the !ptr idiom.
> 
> Detected by CoverityScan, CID#1460246, 1460325, 1460324, 1460392
> ("Resource Leak")
> 
> Fixes: c4562236b3bc ("drm/amd/dc: Add dc display driver (v2)")
> Signed-off-by: Colin Ian King 

Thanks. I got the same patch but was too slow to post.

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> index db96d2b47ff1..61adb8174ce0 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> @@ -1037,11 +1037,13 @@ static bool underlay_create(struct dc_context *ctx, 
> struct resource_pool *pool)
>   struct dce110_opp *dce110_oppv = kzalloc(sizeof(*dce110_oppv),
>GFP_KERNEL);
>  
> - if ((dce110_tgv == NULL) ||
> - (dce110_xfmv == NULL) ||
> - (dce110_miv == NULL) ||
> - (dce110_oppv == NULL))
> - return false;
> + if (!dce110_tgv || !dce110_xfmv || !dce110_miv || !dce110_oppv) {
> + kfree(dce110_tgv);
> + kfree(dce110_xfmv);
> + kfree(dce110_miv);
> + kfree(dce110_oppv);
> + return false;
> + }
>  
>   dce110_opp_v_construct(dce110_oppv, ctx);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Tobias Jakobi]

Marek Szyprowski wrote:
> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
> are contiguous, because of the underlying dma_alloc_attrs() function
> provides only such buffers. In such case it makes no sense to keep
> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
> failures for buffer contiguity checks in the subsequent operations on GEM
> objects.

Reviewed-by: Tobias Jakobi 

- Tobias

> Signed-off-by: Marek Szyprowski 
> CC: sta...@vger.kernel.org # v4.4+
> ---
> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
> support for exynos drm framework"), but this patch applies cleanly
> only to v4.4+ kernel releases due changes in the surrounding code.
> 
> Changelog:
> v2:
> - added warning message when buffer flags are updadated (requested by Inki)
> 
> v1: https://patchwork.kernel.org/patch/10034919/
> - initial version
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 077de014d610..4400efe3974a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
> drm_device *dev,
>   if (IS_ERR(exynos_gem))
>   return exynos_gem;
>  
> + if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) {
> + /*
> +  * when no IOMMU is available, all allocated buffers are
> +  * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag
> +  */
> + flags &= ~EXYNOS_BO_NONCONTIG;
> + DRM_WARN("Non-contiguous allocation is not supported without 
> IOMMU, falling back to contiguous buffer\n");
> + }
> +
>   /* set memory type and cache attribute from user side. */
>   exynos_gem->flags = flags;
>  
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103788] [DC] Screen goes blank after screen sleep and will not come back on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103788

Michel Dänzer  changed:

   What|Removed |Added

Summary|Screen goes blank after |[DC] Screen goes blank
   |screen sleep and will not   |after screen sleep and will
   |come back on|not come back on
 CC||harry.wentl...@amd.com,
   ||jordan.laz...@amd.com

--- Comment #5 from Michel Dänzer  ---
(In reply to Hin-Tak Leung from comment #4)
> For other reasons I am still using the fedora 26 kernel (4.12.x) - so the
> problem seems to be entirely due to changes in userland, or at least,
> outside the kernel, in libdrm or x driver.

Please file your own report, then. The dmesg attached here looks clearly like a
DC (or possibly ATOM BIOS) issue.

-- 
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 103788] Screen goes blank after screen sleep and will not come back on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103788

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #135571|text/x-log  |text/plain
  mime type||

-- 
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 103788] Screen goes blank after screen sleep and will not come back on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103788

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #135572|text/x-log  |text/plain
  mime type||

-- 
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 v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Christian König]

Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:

On 11/22/2017 05:09 AM, Christian König wrote:

Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:

On 11/21/2017 08:34 AM, Christian König wrote:

Hi Boris,

attached are two patches.

The first one is a trivial fix for the infinite loop issue, it now
correctly aborts the fixup when it can't find address space for the
root window.

The second is a workaround for your board. It simply checks if there
is exactly one Processor Function to apply this fix on.

Both are based on linus current master branch. Please test if they fix
your issue.

Yes, they do fix it but that's because the feature is disabled.

Do you know what the actual problem was (on Xen)?

I still haven't understood what you actually did with Xen.

When you used PCI pass through with those devices then you have made a
major configuration error.

When the problem happened on dom0 then the explanation is most likely
that some PCI device ended up in the configured space, but the routing
was only setup correctly on one CPU socket.

The problem is that dom0 can be (and was in my case() booted with less
than full physical memory and so the "rest" of the host memory is not
necessarily reflected in iomem. Your patch then tried to configure that
memory for MMIO and the system hang.

And so my guess is that this patch will break dom0 on a single-socket
system as well.


Oh, thanks!

I've thought about that possibility before, but wasn't able to find a 
system which actually does that.


May I ask why the rest of the memory isn't reported to the OS?

Sounds like I can't trust Linux resource management and probably need to 
read the DRAM config to figure things out after all.


Thanks a lot for this information,
Christian.



-boris


Regards,
Christian.


Thanks.
-boris


Thanks for the help,
Christian.

Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky:

On 11/20/2017 11:07 AM, Christian König wrote:

Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky:

(and then it breaks differently as a Xen guest --- we hung on the
last
pci_read_config_dword(), I haven't looked at this at all yet)

Hui? How does this fix applies to a Xen guest in the first place?

Please provide the output of "lspci -nn" and explain further what is
your config with Xen.



This is dom0.

-bash-4.1# lspci -nn
00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge
only
dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02)
00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device
[1002:5a23]
00:0d.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI
bridge
(external gfx1 port B) [1002:5a1e]
00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA
Controller [AHCI mode] [1002:4391]
00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
EHCI
Controller [1002:4396]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
EHCI
Controller [1002:4396]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller
[1002:4385] (rev 3d)
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host
controller [1002:439d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI
Bridge
[1002:4384]
00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI2 Controller [1002:4399]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1600]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1601]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1602]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1603]
00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1604]
00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1605]
00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1600]
00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1601]
00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1602]
00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1603]
00:19.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1604]
00:19.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1605]
01:04.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA
G200eW WPCM450 [102b:0532] (rev 0a)
02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
-bash-4.1#


-boris



___
dri-devel mailing list

[PATCH] drm/amd/display: fix memory leaks on error exit return

[Colin King]

From: Colin Ian King 

Currently in the case where some of the allocations fail for dce110_tgv,
dce110_xfmv, dce110_miv or dce110_oppv then the exit return path ends
up leaking allocated objects. Fix this by kfree'ing them before returning.
Also re-work the comparison of the null pointers to use the !ptr idiom.

Detected by CoverityScan, CID#1460246, 1460325, 1460324, 1460392
("Resource Leak")

Fixes: c4562236b3bc ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index db96d2b47ff1..61adb8174ce0 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -1037,11 +1037,13 @@ static bool underlay_create(struct dc_context *ctx, 
struct resource_pool *pool)
struct dce110_opp *dce110_oppv = kzalloc(sizeof(*dce110_oppv),
 GFP_KERNEL);
 
-   if ((dce110_tgv == NULL) ||
-   (dce110_xfmv == NULL) ||
-   (dce110_miv == NULL) ||
-   (dce110_oppv == NULL))
-   return false;
+   if (!dce110_tgv || !dce110_xfmv || !dce110_miv || !dce110_oppv) {
+   kfree(dce110_tgv);
+   kfree(dce110_xfmv);
+   kfree(dce110_miv);
+   kfree(dce110_oppv);
+   return false;
+   }
 
dce110_opp_v_construct(dce110_oppv, ctx);
 
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

On 22 November 2017 at 2:45PM, Ilia Mirkin wrote:


I thought I covered that...

"I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible."

   -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


OK, I am bisecting 

Thanks,
Christian

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm/tinydrm: add driver for ILI9225 panels

[Noralf Trønnes]

Den 19.11.2017 21.12, skrev David Lechner:

This adds a new driver for display panels based on the Ilitek ILI9225
controller.

This was developed for a no-name panel with a red PCB that is commonly
marketed for Arduino. See .

Signed-off-by: David Lechner 
---


Reviewed-by: Noralf Trønnes 


v2 changes:
* use exported mipi_dbi_* functions from patch 3/4
* new ili9225_command function

  MAINTAINERS   |   6 +
  drivers/gpu/drm/tinydrm/Kconfig   |  10 +
  drivers/gpu/drm/tinydrm/Makefile  |   1 +
  drivers/gpu/drm/tinydrm/ili9225.c | 468 ++
  4 files changed, 485 insertions(+)
  create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d77f22..72404f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4372,6 +4372,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
  S:Maintained
  F:drivers/gpu/drm/tve200/
  
+DRM DRIVER FOR ILITEK ILI9225 PANELS

+M: David Lechner 
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9225.c
+F: Documentation/devicetree/bindings/display/ili9225.txt
+
  DRM DRIVER FOR INTEL I810 VIDEO CARDS
  S:Orphan / Obsolete
  F:drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 2e790e7..90c5bd5 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,6 +12,16 @@ menuconfig DRM_TINYDRM
  config TINYDRM_MIPI_DBI
tristate
  
+config TINYDRM_ILI9225

+   tristate "DRM support for ILI9225 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9225 panels:
+ * No-name 2.2" color screen module
+
+ If M is selected the module will be called ili9225.
+
  config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 0c184bd..8aeee53 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_TINYDRM)   += core/
  obj-$(CONFIG_TINYDRM_MIPI_DBI)+= mipi-dbi.o
  
  # Displays

+obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
  obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
  obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
  obj-$(CONFIG_TINYDRM_ST7586)  += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
new file mode 100644
index 000..3b766a2
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -0,0 +1,468 @@
+/*
+ * DRM driver for Ilitek ILI9225 panels
+ *
+ * Copyright 2017 David Lechner 
+ *
+ * Some code copied from mipi-dbi.c
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ILI9225_DRIVER_READ_CODE   0x00
+#define ILI9225_DRIVER_OUTPUT_CONTROL  0x01
+#define ILI9225_LCD_AC_DRIVING_CONTROL 0x02
+#define ILI9225_ENTRY_MODE 0x03
+#define ILI9225_DISPLAY_CONTROL_1  0x07
+#define ILI9225_BLANK_PERIOD_CONTROL_1 0x08
+#define ILI9225_FRAME_CYCLE_CONTROL0x0b
+#define ILI9225_INTERFACE_CONTROL  0x0c
+#define ILI9225_OSCILLATION_CONTROL0x0f
+#define ILI9225_POWER_CONTROL_10x10
+#define ILI9225_POWER_CONTROL_20x11
+#define ILI9225_POWER_CONTROL_30x12
+#define ILI9225_POWER_CONTROL_40x13
+#define ILI9225_POWER_CONTROL_50x14
+#define ILI9225_VCI_RECYCLING  0x15
+#define ILI9225_RAM_ADDRESS_SET_1  0x20
+#define ILI9225_RAM_ADDRESS_SET_2  0x21
+#define ILI9225_WRITE_DATA_TO_GRAM 0x22
+#define ILI9225_SOFTWARE_RESET 0x28
+#define ILI9225_GATE_SCAN_CONTROL  0x30
+#define ILI9225_VERTICAL_SCROLL_1  0x31
+#define ILI9225_VERTICAL_SCROLL_2  0x32
+#define ILI9225_VERTICAL_SCROLL_3  0x33
+#define ILI9225_PARTIAL_DRIVING_POS_1  0x34
+#define ILI9225_PARTIAL_DRIVING_POS_2  0x35
+#define ILI9225_HORIZ_WINDOW_ADDR_10x36
+#define ILI9225_HORIZ_WINDOW_ADDR_20x37
+#define ILI9225_VERT_WINDOW_ADDR_1 0x38
+#define ILI9225_VERT_WINDOW_ADDR_2 0x39
+#define ILI9225_GAMMA_CONTROL_10x50
+#define ILI9225_GAMMA_CONTROL_20x51
+#define ILI9225_GAMMA_CONTROL_30x52
+#define ILI9225_GAMMA_CONTROL_40x53
+#define ILI9225_GAMMA_CONTROL_50x54
+#define 

Re: [PATCH v2 3/4] drm/tinydrm: export mipi_dbi_buf_copy and mipi_dbi_spi_cmd_max_speed

[Noralf Trønnes]

Den 19.11.2017 21.12, skrev David Lechner:

This exports the mipi_dbi_buf_copy() and mipi_dbi_spi_cmd_max_speed()
functions so that they can be shared with other drivers.

Signed-off-by: David Lechner 
---


Reviewed-by: Noralf Trønnes 


v2 changes:
* new patch in v2

  drivers/gpu/drm/tinydrm/mipi-dbi.c | 24 
  include/drm/tinydrm/mipi-dbi.h |  4 +++-
  2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 347f9b2..aa6b6ce 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -154,8 +154,18 @@ int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 
*data, size_t len)
  }
  EXPORT_SYMBOL(mipi_dbi_command_buf);
  
-static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,

-   struct drm_clip_rect *clip, bool swap)
+/**
+ * mipi_dbi_buf_copy - Copy a framebuffer, transforming it if necessary
+ * @dst: The destination buffer
+ * @fb: The source framebuffer
+ * @clip: Clipping rectangle of the area to be copied
+ * @swap: When true, swap MSB/LSB of 16-bit values
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap)
  {
struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
@@ -192,6 +202,7 @@ static int mipi_dbi_buf_copy(void *dst, struct 
drm_framebuffer *fb,
 DMA_FROM_DEVICE);
return ret;
  }
+EXPORT_SYMBOL(mipi_dbi_buf_copy);
  
  static int mipi_dbi_fb_dirty(struct drm_framebuffer *fb,

 struct drm_file *file_priv,
@@ -444,18 +455,23 @@ EXPORT_SYMBOL(mipi_dbi_display_is_on);
  
  #if IS_ENABLED(CONFIG_SPI)
  
-/*

+/**
+ * mipi_dbi_spi_cmd_max_speed - get the maximum SPI bus speed
+ * @spi: SPI device
+ * @len: The transfer buffer length.
+ *
   * Many controllers have a max speed of 10MHz, but can be pushed way beyond
   * that. Increase reliability by running pixel data at max speed and the rest
   * at 10MHz, preventing transfer glitches from messing up the init settings.
   */
-static u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len)
+u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len)
  {
if (len > 64)
return 0; /* use default */
  
  	return min_t(u32, 1000, spi->max_speed_hz);

  }
+EXPORT_SYMBOL(mipi_dbi_spi_cmd_max_speed);
  
  /*

   * MIPI DBI Type C Option 1
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index 83346dd..5d0e82b 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -72,10 +72,12 @@ void mipi_dbi_pipe_enable(struct drm_simple_display_pipe 
*pipe,
  void mipi_dbi_pipe_disable(struct drm_simple_display_pipe *pipe);
  void mipi_dbi_hw_reset(struct mipi_dbi *mipi);
  bool mipi_dbi_display_is_on(struct mipi_dbi *mipi);
+u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len);
  
  int mipi_dbi_command_read(struct mipi_dbi *mipi, u8 cmd, u8 *val);

  int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 *data, size_t len);
-
+int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap);
  /**
   * mipi_dbi_command - MIPI DCS command with optional parameter(s)
   * @mipi: MIPI structure


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Ilia Mirkin]

On Wed, Nov 22, 2017 at 8:40 AM, Christian Zigotzky
 wrote:
> On 22 November 2017 at 2:27PM, Ilia Mirkin wrote:
>>
>> On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
>>  wrote:
>>>
>>> Hi Alex,
>>>
>>> I reverted the following files in the first bad commit (first DRM
>>> updates)
>>
>> Is the merge commit really the first bad commit? i.e. both parents of
>> the merge are good, but the merge commit itself is bad? Or did you do
>> this manually and therefore didn't go into the merge parents? If so,
>> I'd recommend doing a proper bisect (search for "git bisect", there
>> are tons of guides). That will identify the commit that's actually
>> responsible.
>
> Hi ilia,
>
> I did it manually. If I revert the merge commit then the hardware 3D
> acceleration works. Is it possible to bisect in the merge commit directly?

I thought I covered that...

"I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible."

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

On 22 November 2017 at 2:27PM, Ilia Mirkin wrote:

On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
 wrote:

Hi Alex,

I reverted the following files in the first bad commit (first DRM updates)

Is the merge commit really the first bad commit? i.e. both parents of
the merge are good, but the merge commit itself is bad? Or did you do
this manually and therefore didn't go into the merge parents? If so,
I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible.

Cheers,

   -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Hi ilia,

I did it manually. If I revert the merge commit then the hardware 3D 
acceleration works. Is it possible to bisect in the merge commit directly?


Thanks,
Christian

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Ilia Mirkin]

On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
 wrote:
> Hi Alex,
>
> I reverted the following files in the first bad commit (first DRM updates)

Is the merge commit really the first bad commit? i.e. both parents of
the merge are good, but the merge commit itself is bad? Or did you do
this manually and therefore didn't go into the merge parents? If so,
I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

Hi Alex,

I reverted the following files in the first bad commit (first DRM 
updates) [1].


-rw-r--r--    drivers/gpu/drm/radeon/Makefile    5
-rw-r--r--    drivers/gpu/drm/radeon/atombios_dp.c    46
-rw-r--r--    drivers/gpu/drm/radeon/ci_dpm.c    22
-rw-r--r--    drivers/gpu/drm/radeon/ci_dpm.h    1
-rw-r--r--    drivers/gpu/drm/radeon/ci_smc.c    21
-rw-r--r--    drivers/gpu/drm/radeon/cik.c    14
-rw-r--r--    drivers/gpu/drm/radeon/cikd.h    2
-rw-r--r--    drivers/gpu/drm/radeon/r100.c    2
-rw-r--r--    drivers/gpu/drm/radeon/r600_cs.c    2
-rw-r--r--    drivers/gpu/drm/radeon/r600_hdmi.c    2
-rw-r--r--    drivers/gpu/drm/radeon/radeon.h    3
-rw-r--r--    drivers/gpu/drm/radeon/radeon_connectors.c    16
-rw-r--r--    drivers/gpu/drm/radeon/radeon_drv.c    10
-rw-r--r--    drivers/gpu/drm/radeon/radeon_fb.c    4
-rw-r--r--    drivers/gpu/drm/radeon/radeon_kfd.c    870
-rw-r--r--    drivers/gpu/drm/radeon/radeon_kms.c    7
-rw-r--r--    drivers/gpu/drm/radeon/radeon_mode.h    4
-rw-r--r--    drivers/gpu/drm/radeon/radeon_trace.h    2
-rw-r--r--    drivers/gpu/drm/radeon/radeon_ttm.c

After that I compiled the latest git kernel again. Unfortunately I don't 
have hardware 3D acceleration. That means the bug isn't in these files 
above but it is somewhere in the first DRM updates [1].


I need really your help because I don't have any experiences with this 
source code. I will try to revert more files.


Thanks,
Christian


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980



On 21 November 2017 at 05:38AM, Alex Deucher wrote:


If you look at the code, radeon_bo_create() is failing with -ENOMEM in
radeon_wb_init().  If you look at radeon_bo_create(), it can fail for
the following reasons:
1. kzalloc fails
2. drm_gem_object_init fails
3. ttm_bo_init fails

I'd start by looking into what's changed in those areas.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Marek Szyprowski]

When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
are contiguous, because of the underlying dma_alloc_attrs() function
provides only such buffers. In such case it makes no sense to keep
BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
failures for buffer contiguity checks in the subsequent operations on GEM
objects.

Signed-off-by: Marek Szyprowski 
CC: sta...@vger.kernel.org # v4.4+
---
This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
support for exynos drm framework"), but this patch applies cleanly
only to v4.4+ kernel releases due changes in the surrounding code.

Changelog:
v2:
- added warning message when buffer flags are updadated (requested by Inki)

v1: https://patchwork.kernel.org/patch/10034919/
- initial version
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 077de014d610..4400efe3974a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
drm_device *dev,
if (IS_ERR(exynos_gem))
return exynos_gem;
 
+   if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) {
+   /*
+* when no IOMMU is available, all allocated buffers are
+* contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag
+*/
+   flags &= ~EXYNOS_BO_NONCONTIG;
+   DRM_WARN("Non-contiguous allocation is not supported without 
IOMMU, falling back to contiguous buffer\n");
+   }
+
/* set memory type and cache attribute from user side. */
exynos_gem->flags = flags;
 
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] drm/tegra: Fixes for v4.15-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit fb83be8873909ba7c089d1c5cb72873cc2cce7d1:

  drm/tegra: hdmi: Add cec-notifier support (2017-10-20 14:19:54 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc1-fixes

for you to fetch changes up to e1335e2f0cfcd36ffa1b709ac58096134eb6e779:

  drm/tegra: sor: Reimplement pad clock (2017-11-20 13:23:54 +0100)

This is a single fix on top of the earlier pull request for Tegra. I
forgot to include this in the initial pull request, but it is required
in order to keep the SOR working with some of the changes that went in
via the clock tree.

Thanks,
Thierry


drm/tegra: Fixes for v4.15-rc1

This includes an update to the SOR pad clock programming needed because
of some changes that went in through the clock tree.


Thierry Reding (1):
  drm/tegra: sor: Reimplement pad clock

 drivers/gpu/drm/tegra/sor.c | 157 +++-
 1 file changed, 111 insertions(+), 46 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: ipu-v3: prg: switch to runtime PM

[Philipp Zabel]

On Fri, 2017-11-10 at 17:06 +0100, Lucas Stach wrote:
> Instead of open-coding the clk enable/disable in all of the callers
> move this to the RPM suspend/resume functions.
> 
> Signed-off-by: Lucas Stach 
> Signed-off-by: Philipp Zabel 

Applied to imx-drm/next, thanks.

regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm/imx: advertise supported plane format modifiers

[Philipp Zabel]

On Fri, 2017-11-10 at 17:10 +0100, Lucas Stach wrote:
> Let userspace know about the supported modifiers, to make automatic
> selection of a proper modifier possible.
> 
> Signed-off-by: Lucas Stach 

Applied all four to imx-drm/next, thanks!

regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

--- Comment #6 from Christian König  ---
(In reply to Michel Dänzer from comment #4)
> Christian, might it be possible to e.g. maintain a list of per-VM BOs which
> were evicted from VRAM, and try to move them back to VRAM as part of the
> existing mechanism for this (for "normal" BOs)?

That would certainly be possible, but I don't think it would help in any way.

The kernel simply doesn't know any more which BOs are currently used and which
aren't. So as soon as userspace allocates more VRAM than physical available we
are practically lost.

In other words we would just cycle over a list of BOs evicted from VRAM on
every submission and would rarely be able to move something back in.

What we could do is try to move buffers back into VRAM when memory is freed,
but that happens so rarely as well that it probably doesn't make much sense
either.

Can somebody analyze exactly why those games are now slower than they have been
before? E.g. which buffers are fighting for VRAM? Or are they maybe fighting
for GTT?

-- 
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: [GIT PULL] imx-drm: various cleanups

[Philipp Zabel]

Hi Dave,

On Wed, 2017-10-18 at 19:17 +0200, Philipp Zabel wrote:
> Hi Dave,
> 
> please consider merging these small cleanups for the imx-drm driver,
> including a switch from drm_property_unreference_blob to
> drm_property_blob_put, a change of the parallel-display connector enum
> from VGA to DPI, a documentation fix for the device tree binding
> example, and removal of an unused variable.

Any reason these haven't made it into drm-for-v4.15?

None of them are critical. If they were just forgotten, I can merge them
into the the next pull request.

regards
Philipp

> The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
> 
>   Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2017-10-18
> 
> for you to fetch changes up to e64b9189bfd58e215ee44159767b39b8cf6fa302:
> 
>   gpu: ipu-v3: ipu-dc: Remove unused 'di' variable (2017-10-04 12:18:56 +0200)
> 
> 
> drm/imx: various cleanups
> 
> - Switch to drm_*_get/put() helpers
> - Use correct parallel-display connector enum: DPI instead of VGA
> - Remove incorrect unit name from device tree binding documentation example
> - Remove an unused variable
> 
> 
> Cihangir Akturk (1):
>   drm/imx: switch to drm_*_get(), drm_*_put() helpers
> 
> Fabio Estevam (1):
>   gpu: ipu-v3: ipu-dc: Remove unused 'di' variable
> 
> Lucas Stach (1):
>   drm/imx: parallel-display: use correct connector enum
> 
> Marco Franchi (1):
>   dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage
> 
>  Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c  | 2 +-
>  drivers/gpu/drm/imx/parallel-display.c| 2 +-
>  drivers/gpu/ipu-v3/ipu-dc.c   | 3 ---
>  4 files changed, 3 insertions(+), 6 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/ttm: add set_pages_wb for handling page order more than zero

[Christian König]

Am 22.11.2017 um 12:50 schrieb Chris Wilson:

Quoting Roger He (2017-11-22 11:44:27)

Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a8b2bfa..cdbb731 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -223,6 +223,17 @@ static struct kobj_type ttm_pool_kobj_type = {
  static struct ttm_pool_manager *_manager;
  
  #ifndef CONFIG_X86

+static int set_pages_wb(struct page *page, int numpages)
+{
+#if IS_ENABLED(CONFIG_AGP)
+   int i;
+
+   for (i = 0; i < numpages; i++)
+   unmap_page_from_agp(page++);
+#endif
+   return 0;
+}
+
  static int set_pages_array_wb(struct page **pages, int addrinarray)

Both of these are shadowing exports from arch/x86, probably not the
wisest choice of names.


That is intended, please note the "#ifndef CONFIG_X86".

Basically TTM provides the same function for other architectures that we 
have for X86.


Christian.


-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/ttm: add set_pages_wb for handling page order more than zero

[Christian König]

Am 22.11.2017 um 12:44 schrieb Roger He:

Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He 


Reviewed-by: Christian König  for the whole 
series.



---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a8b2bfa..cdbb731 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -223,6 +223,17 @@ static struct kobj_type ttm_pool_kobj_type = {
  static struct ttm_pool_manager *_manager;
  
  #ifndef CONFIG_X86

+static int set_pages_wb(struct page *page, int numpages)
+{
+#if IS_ENABLED(CONFIG_AGP)
+   int i;
+
+   for (i = 0; i < numpages; i++)
+   unmap_page_from_agp(page++);
+#endif
+   return 0;
+}
+
  static int set_pages_array_wb(struct page **pages, int addrinarray)
  {
  #if IS_ENABLED(CONFIG_AGP)



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/ttm: roundup the shrink request to prevent skip huge pool

[Chris Wilson]

Quoting Roger He (2017-11-22 11:44:29)
> e.g. shrink reqeust is less than 512, the logic will skip huge pool

You should also tell the shrinker that you skipped objects so that it
knows to accumulate the request for the next pass. See
shrinkctl->nr_scanned.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/ttm: add set_pages_wb for handling page order more than zero

[Chris Wilson]

Quoting Roger He (2017-11-22 11:44:27)
> Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
> Signed-off-by: Roger He 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index a8b2bfa..cdbb731 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -223,6 +223,17 @@ static struct kobj_type ttm_pool_kobj_type = {
>  static struct ttm_pool_manager *_manager;
>  
>  #ifndef CONFIG_X86
> +static int set_pages_wb(struct page *page, int numpages)
> +{
> +#if IS_ENABLED(CONFIG_AGP)
> +   int i;
> +
> +   for (i = 0; i < numpages; i++)
> +   unmap_page_from_agp(page++);
> +#endif
> +   return 0;
> +}
> +
>  static int set_pages_array_wb(struct page **pages, int addrinarray)

Both of these are shadowing exports from arch/x86, probably not the
wisest choice of names.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/ttm: add set_pages_wb for handling page order more than zero

[Roger He]

Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a8b2bfa..cdbb731 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -223,6 +223,17 @@ static struct kobj_type ttm_pool_kobj_type = {
 static struct ttm_pool_manager *_manager;
 
 #ifndef CONFIG_X86
+static int set_pages_wb(struct page *page, int numpages)
+{
+#if IS_ENABLED(CONFIG_AGP)
+   int i;
+
+   for (i = 0; i < numpages; i++)
+   unmap_page_from_agp(page++);
+#endif
+   return 0;
+}
+
 static int set_pages_array_wb(struct page **pages, int addrinarray)
 {
 #if IS_ENABLED(CONFIG_AGP)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/ttm: add page order support in ttm_pages_put

[Roger He]

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index cdbb731..25b0fa5 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -296,13 +296,23 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
 }
 
 /* set memory back to wb and free the pages. */
-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
 {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   unsigned int i, pages_nr = (1 << order);
+
+   if (order == 0) {
+   if (set_pages_array_wb(pages, npages))
+   pr_err("Failed to set %d pages to wb!\n", npages);
+   }
+
+   for (i = 0; i < npages; ++i) {
+   if (order > 0) {
+   if (set_pages_wb(pages[i], pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", 
pages_nr);
+   }
+   __free_pages(pages[i], order);
+   }
 }
 
 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,
@@ -365,7 +375,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
 
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
 
@@ -400,7 +410,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
spin_unlock_irqrestore(>lock, irq_flags);
 
if (freed_pages)
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
 out:
if (pages_to_free != static_buf)
kfree(pages_to_free);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/ttm: roundup the shrink request to prevent skip huge pool

[Roger He]

e.g. shrink reqeust is less than 512, the logic will skip huge pool

Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 25b0fa5..1543532 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -442,17 +442,19 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
/* select start pool in round robin fashion */
for (i = 0; i < NUM_POOLS; ++i) {
unsigned nr_free = shrink_pages;
+   unsigned page_nr;
+
if (shrink_pages == 0)
break;
 
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
+   page_nr = (1 << pool->order);
/* OK to use static buffer since global mutex is held. */
-   nr_free_pool = (nr_free >> pool->order);
-   if (nr_free_pool == 0)
-   continue;
-
+   nr_free_pool = roundup(nr_free, page_nr) >> pool->order;
shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
-   freed += ((nr_free_pool - shrink_pages) << pool->order);
+   freed += (nr_free_pool - shrink_pages) << pool->order;
+   if (freed >= sc->nr_to_scan)
+   break;
}
mutex_unlock();
return freed;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103175

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #10 from Andy Furniss  ---
Testing from head of drm-next-4.15 I can change minor to 19 and 20 in
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
and am stable so can test.

19 gives good perf 20 bad, so setting as duplicate.

*** This bug has been marked as a duplicate of bug 103100 ***

-- 
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 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

Andy Furniss  changed:

   What|Removed |Added

 CC||adf.li...@gmail.com

--- Comment #5 from Andy Furniss  ---
*** Bug 103175 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

[PATCH v3] drm/printer: Add drm_vprintf()

[Chris Wilson]

Simple va_args equivalent to the existing drm_printf() for use with the
drm_printer.

v2: Fixup kerneldoc to match final parameter names.
v3: Turn it into a kerneldoc comment

Signed-off-by: Chris Wilson 
Cc: Rob Clark 
Reviewed-by: Daniel Vetter 
Cc: Dave Airlie 
---

Dave,
  could you ack this for merging via drm/i915?
Thanks,
-Chris

---
 drivers/gpu/drm/drm_print.c |  5 +
 include/drm/drm_print.h | 15 +++
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 82ff327eb2df..781518fd88e3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -55,13 +55,10 @@ EXPORT_SYMBOL(__drm_printfn_debug);
  */
 void drm_printf(struct drm_printer *p, const char *f, ...)
 {
-   struct va_format vaf;
va_list args;
 
va_start(args, f);
-   vaf.fmt = f;
-   vaf.va = 
-   p->printfn(p, );
+   drm_vprintf(p, f, );
va_end(args);
 }
 EXPORT_SYMBOL(drm_printf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 0968e411f562..5f9932e2246e 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -80,6 +80,21 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
va_format *vaf);
 __printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
 
+/**
+ * drm_vprintf - print to a _printer stream
+ * @p: the _printer
+ * @fmt: format string
+ * @va: the va_list
+ */
+__printf(2, 0)
+static inline void
+drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
+{
+   struct va_format vaf = { .fmt = fmt, .va = va };
+
+   p->printfn(p, );
+}
+
 /**
  * drm_printf_indent - Print to a _printer stream with indentation
  * @printer: DRM printer
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 3/5] drm/ttm: add page order support in ttm_pages_put

[He, Roger]

Hi Christian:

Maybe we can get back the logic for page order 0 in ttm_pages_put.

I mean: handle order 0 with set_pages_array_wb and handle order 9 with 
set_pages_wb.
If that, no performance concern.
How about that?

Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Wednesday, November 22, 2017 6:01 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/ttm: add page order support in ttm_pages_put

That completely negates the advantage of setting write back on multiple pages 
at once.

In other words this way we wouldn't need the array any more at all and could 
remove the whole complicated handling.

I'm pretty close to saying just go ahead with that and even clean up the whole 
stuff with the static array, but I'm not sure if that doesn't result in some 
performance problems.

A possible alternative is the (untested) patch attached, this way we move the 
__free_page()/_free_pages() call out of ttm_pages_put and just need to add the 
correct number of pages to the array in the loop.

Regards,
Christian.

Am 22.11.2017 um 10:17 schrieb Roger He:
> Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 +++
>   1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 9b48b93..2dc83c0 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -299,13 +299,16 @@ static struct ttm_page_pool *ttm_get_pool(int flags, 
> bool huge,
>   }
>   
>   /* set memory back to wb and free the pages. */ -static void 
> ttm_pages_put(struct page *pages[], unsigned npages)
> +static void ttm_pages_put(struct page *pages[], unsigned npages,
> + unsigned int order)
>   {
> - unsigned i;
> - if (set_pages_array_wb(pages, npages))
> - pr_err("Failed to set %d pages to wb!\n", npages);
> - for (i = 0; i < npages; ++i)
> - __free_page(pages[i]);
> + unsigned int i, pages_nr = (1 << order);
> +
> + for (i = 0; i < npages; ++i) {
> + if (set_pages_wb(pages[i], pages_nr))
> + pr_err("Failed to set %d pages to wb!\n", pages_nr);
> + __free_pages(pages[i], order);
> + }
>   }
>   
>   static void ttm_pool_update_free_locked(struct ttm_page_pool *pool, 
> @@ -368,7 +371,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
> unsigned nr_free,
>*/
>   spin_unlock_irqrestore(>lock, irq_flags);
>   
> - ttm_pages_put(pages_to_free, freed_pages);
> + ttm_pages_put(pages_to_free, freed_pages, pool->order);
>   if (likely(nr_free != FREE_ALL_PAGES))
>   nr_free -= freed_pages;
>   
> @@ -403,7 +406,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
> unsigned nr_free,
>   spin_unlock_irqrestore(>lock, irq_flags);
>   
>   if (freed_pages)
> - ttm_pages_put(pages_to_free, freed_pages);
> + ttm_pages_put(pages_to_free, freed_pages, pool->order);
>   out:
>   if (pages_to_free != static_buf)
>   kfree(pages_to_free);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

Michel Dänzer  changed:

   What|Removed |Added

 CC||ckoenig.leichtzumerken@gmai
   ||l.com

--- Comment #4 from Michel Dänzer  ---
One possible issue with per-VM BOs is that the kernel driver can no longer
migrate BOs to more optimal placement for a command stream, because it doesn't
know which BOs are used by the command stream. So if e.g. a per-VM BO is
evicted from VRAM, e.g. due to CPU access to it, it will normally never move
back to VRAM.

Christian, might it be possible to e.g. maintain a list of per-VM BOs which
were evicted from VRAM, and try to move them back to VRAM as part of the
existing mechanism for this (for "normal" BOs)?

-- 
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 103838] Random segfaults in applications from radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103838

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #135653|text/x-log  |text/plain
  mime type||

-- 
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 103838] Random segfaults in applications from radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103838

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #135654|text/x-log  |text/plain
  mime type||

-- 
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 v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Christian König]

Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:

On 11/21/2017 08:34 AM, Christian König wrote:

Hi Boris,

attached are two patches.

The first one is a trivial fix for the infinite loop issue, it now
correctly aborts the fixup when it can't find address space for the
root window.

The second is a workaround for your board. It simply checks if there
is exactly one Processor Function to apply this fix on.

Both are based on linus current master branch. Please test if they fix
your issue.


Yes, they do fix it but that's because the feature is disabled.

Do you know what the actual problem was (on Xen)?


I still haven't understood what you actually did with Xen.

When you used PCI pass through with those devices then you have made a 
major configuration error.


When the problem happened on dom0 then the explanation is most likely 
that some PCI device ended up in the configured space, but the routing 
was only setup correctly on one CPU socket.


Regards,
Christian.



Thanks.
-boris


Thanks for the help,
Christian.

Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky:

On 11/20/2017 11:07 AM, Christian König wrote:

Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky:

(and then it breaks differently as a Xen guest --- we hung on the last
pci_read_config_dword(), I haven't looked at this at all yet)

Hui? How does this fix applies to a Xen guest in the first place?

Please provide the output of "lspci -nn" and explain further what is
your config with Xen.



This is dom0.

-bash-4.1# lspci -nn
00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge only
dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02)
00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device
[1002:5a23]
00:0d.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge
(external gfx1 port B) [1002:5a1e]
00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA
Controller [AHCI mode] [1002:4391]
00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
Controller [1002:4396]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
Controller [1002:4396]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller
[1002:4385] (rev 3d)
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host
controller [1002:439d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge
[1002:4384]
00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI2 Controller [1002:4399]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1600]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1601]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1602]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1603]
00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1604]
00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1605]
00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1600]
00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1601]
00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1602]
00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1603]
00:19.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1604]
00:19.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
[1022:1605]
01:04.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA
G200eW WPCM450 [102b:0532] (rev 0a)
02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
-bash-4.1#


-boris




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] lib/rbtree,drm/mm: Add rbtree_replace_node_cached()

[Chris Wilson]

Add a variant of rbtree_replace_node() that maintains the leftmost
cache of struct rbtree_root_cached when replacing nodes within the
rbtree.

As drm_mm is the only rb_replace_node() being used on an interval tree,
the mistake looks fairly self-contained. Furthermore the only user of
drm_mm_replace_node() is its testsuite...

Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
Testcase: igt/drm_mm/replace
Signed-off-by: Chris Wilson 
Cc: Davidlohr Bueso 
Cc: Jérôme Glisse 
Cc: Andrew Morton 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171109212435.9265-1-ch...@chris-wilson.co.uk
Acked-by: Davidlohr Bueso 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/drm_mm.c |  8 +---
 include/linux/rbtree.h   |  2 ++
 lib/rbtree.c | 10 ++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 61a1c8ea74bc..c3c79ee6119e 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -575,21 +575,23 @@ EXPORT_SYMBOL(drm_mm_remove_node);
  */
 void drm_mm_replace_node(struct drm_mm_node *old, struct drm_mm_node *new)
 {
+   struct drm_mm *mm = old->mm;
+
DRM_MM_BUG_ON(!old->allocated);
 
*new = *old;
 
list_replace(>node_list, >node_list);
-   rb_replace_node(>rb, >rb, >mm->interval_tree.rb_root);
+   rb_replace_node_cached(>rb, >rb, >interval_tree);
 
if (drm_mm_hole_follows(old)) {
list_replace(>hole_stack, >hole_stack);
rb_replace_node(>rb_hole_size,
>rb_hole_size,
-   >mm->holes_size);
+   >holes_size);
rb_replace_node(>rb_hole_addr,
>rb_hole_addr,
-   >mm->holes_addr);
+   >holes_addr);
}
 
old->allocated = false;
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index d574361943ea..fcbeed4053ef 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -99,6 +99,8 @@ extern void rb_replace_node(struct rb_node *victim, struct 
rb_node *new,
struct rb_root *root);
 extern void rb_replace_node_rcu(struct rb_node *victim, struct rb_node *new,
struct rb_root *root);
+extern void rb_replace_node_cached(struct rb_node *victim, struct rb_node *new,
+  struct rb_root_cached *root);
 
 static inline void rb_link_node(struct rb_node *node, struct rb_node *parent,
struct rb_node **rb_link)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index ba4a9d165f1b..d3ff682fd4b8 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -603,6 +603,16 @@ void rb_replace_node(struct rb_node *victim, struct 
rb_node *new,
 }
 EXPORT_SYMBOL(rb_replace_node);
 
+void rb_replace_node_cached(struct rb_node *victim, struct rb_node *new,
+   struct rb_root_cached *root)
+{
+   rb_replace_node(victim, new, >rb_root);
+
+   if (root->rb_leftmost == victim)
+   root->rb_leftmost = new;
+}
+EXPORT_SYMBOL(rb_replace_node_cached);
+
 void rb_replace_node_rcu(struct rb_node *victim, struct rb_node *new,
 struct rb_root *root)
 {
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100591] [AMD APU A9-9410] Kernel hang when using graphics acceleration

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100591

--- Comment #8 from Hin-Tak Leung  ---
is this patch in the release kernel yet?

-- 
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 103788] Screen goes blank after screen sleep and will not come back on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103788

--- Comment #4 from Hin-Tak Leung  ---
I seem to have a similar problem. Laptop working fine under fedora 26; since
ungraded to fedora 27 a few days ago; when the screen sleeps, it won't wake.

For other reasons I am still using the fedora 26 kernel (4.12.x) - so the
problem seems to be entirely due to changes in userland, or at least, outside
the kernel, in libdrm or x driver.

Am running gnome classic in x11 if that matters.

-- 
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 3/5] drm/ttm: add page order support in ttm_pages_put

[Christian König]

That completely negates the advantage of setting write back on multiple 
pages at once.


In other words this way we wouldn't need the array any more at all and 
could remove the whole complicated handling.


I'm pretty close to saying just go ahead with that and even clean up the 
whole stuff with the static array, but I'm not sure if that doesn't 
result in some performance problems.


A possible alternative is the (untested) patch attached, this way we 
move the __free_page()/_free_pages() call out of ttm_pages_put and just 
need to add the correct number of pages to the array in the loop.


Regards,
Christian.

Am 22.11.2017 um 10:17 schrieb Roger He:

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 +++
  1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 9b48b93..2dc83c0 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -299,13 +299,16 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
  }
  
  /* set memory back to wb and free the pages. */

-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
  {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   unsigned int i, pages_nr = (1 << order);
+
+   for (i = 0; i < npages; ++i) {
+   if (set_pages_wb(pages[i], pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
  }
  
  static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,

@@ -368,7 +371,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
  
-			ttm_pages_put(pages_to_free, freed_pages);

+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
  
@@ -403,7 +406,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,

spin_unlock_irqrestore(>lock, irq_flags);
  
  	if (freed_pages)

-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
  out:
if (pages_to_free != static_buf)
kfree(pages_to_free);



>From 4fcc6c40e3596e12a9712b01a44d9c0265f04582 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= 
Date: Wed, 22 Nov 2017 10:54:58 +0100
Subject: [PATCH] drm/ttm: move __free_page out of ttm_pages_put
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This way we can easier free the pages with the right order.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 72ea037b7090..4deb9c8441b5 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -286,11 +286,8 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool huge,
 /* set memory back to wb and free the pages. */
 static void ttm_pages_put(struct page *pages[], unsigned npages)
 {
-	unsigned i;
 	if (set_pages_array_wb(pages, npages))
 		pr_err("Failed to set %d pages to wb!\n", npages);
-	for (i = 0; i < npages; ++i)
-		__free_page(pages[i]);
 }
 
 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,
@@ -315,7 +312,8 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
 {
 	static struct page *static_buf[NUM_PAGES_TO_ALLOC];
 	unsigned long irq_flags;
-	struct page *p;
+	struct list_head freed;
+	struct page *p, *tmp;
 	struct page **pages_to_free;
 	unsigned freed_pages = 0,
 		 npages_to_free = nr_free;
@@ -333,6 +331,8 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
 		return 0;
 	}
 
+	INIT_LIST_HEAD();
+
 restart:
 	spin_lock_irqsave(>lock, irq_flags);
 
@@ -345,6 +345,8 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
 		if (freed_pages >= NUM_PAGES_TO_ALLOC) {
 			/* remove range of pages from the pool */
 			__list_del(p->lru.prev, >list);
+			/* and add to freed list */
+			__list_add(>lru, , );
 
 			ttm_pool_update_free_locked(pool, freed_pages);
 			/**
@@ -380,6 +382,8 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
 	

[PATCH 3/5] drm/ttm: add page order support in ttm_pages_put

[Roger He]

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 9b48b93..2dc83c0 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -299,13 +299,16 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
 }
 
 /* set memory back to wb and free the pages. */
-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
 {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   unsigned int i, pages_nr = (1 << order);
+
+   for (i = 0; i < npages; ++i) {
+   if (set_pages_wb(pages[i], pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
 }
 
 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,
@@ -368,7 +371,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
 
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
 
@@ -403,7 +406,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
spin_unlock_irqrestore(>lock, irq_flags);
 
if (freed_pages)
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
 out:
if (pages_to_free != static_buf)
kfree(pages_to_free);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/4] drm/ttm: add page order support in ttm_pages_put

[He, Roger]

Hi Christian:

This is old patch, I already send new patches. And it is clean and simple.  
Please check that.

Thanks
Roger(Hongbo.He)

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Wednesday, November 22, 2017 5:29 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: Re: [PATCH 2/4] drm/ttm: add page order support in ttm_pages_put

I would rather completely nuke ttm_pages_put() instead of coming up with more 
workarounds here.

Going to provide a cleanup patch to show what I mean, just give me a minute.

Regards,
Christian.

Am 22.11.2017 um 06:36 schrieb Roger He:
> Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 
> +---
>   1 file changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 0a0c653..de64209 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -285,13 +285,39 @@ static struct ttm_page_pool *ttm_get_pool(int flags, 
> bool huge,
>   }
>   
>   /* set memory back to wb and free the pages. */ -static void 
> ttm_pages_put(struct page *pages[], unsigned npages)
> +static void ttm_pages_put(struct page *pages[], unsigned npages,
> + unsigned int order)
>   {
> - unsigned i;
> - if (set_pages_array_wb(pages, npages))
> - pr_err("Failed to set %d pages to wb!\n", npages);
> - for (i = 0; i < npages; ++i)
> - __free_page(pages[i]);
> + struct page **pages_to_free = NULL;
> + struct page **pages_array;
> + struct page *p;
> + unsigned int i, j, pages_nr = (1 << order);
> +
> + if (order > 0) {
> + pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),
> + GFP_KERNEL);
> + if (!pages_to_free) {
> + pr_err("Failed to allocate memory for ttm pages put 
> operation\n");
> + return;
> + }
> + }
> +
> + for (i = 0; i < npages; ++i) {
> + if (order > 0) {
> + p = pages[i];
> + for (j = 0; j < pages_nr; ++j)
> + pages_to_free[j] = p++;
> +
> + pages_array = pages_to_free;
> + } else
> + pages_array = pages;
> +
> + if (set_pages_array_wb(pages_array, pages_nr))
> + pr_err("Failed to set %d pages to wb!\n", pages_nr);
> + __free_pages(pages[i], order);
> + }
> +
> + kfree(pages_to_free);
>   }
>   
>   static void ttm_pool_update_free_locked(struct ttm_page_pool *pool, 
> @@ -354,7 +380,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
> unsigned nr_free,
>*/
>   spin_unlock_irqrestore(>lock, irq_flags);
>   
> - ttm_pages_put(pages_to_free, freed_pages);
> + ttm_pages_put(pages_to_free, freed_pages, pool->order);
>   if (likely(nr_free != FREE_ALL_PAGES))
>   nr_free -= freed_pages;
>   
> @@ -389,7 +415,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
> unsigned nr_free,
>   spin_unlock_irqrestore(>lock, irq_flags);
>   
>   if (freed_pages)
> - ttm_pages_put(pages_to_free, freed_pages);
> + ttm_pages_put(pages_to_free, freed_pages, pool->order);
>   out:
>   if (pages_to_free != static_buf)
>   kfree(pages_to_free);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/ttm: add page order in page pool

[Chunming Zhou]

the patch set looks ok to me, Reviewed-by: Chunming Zhou 




On 2017年11月22日 17:17, Roger He wrote:

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 38 +---
  1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 7385785..a02bd65 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -84,6 +84,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
  };
  
  /**

@@ -415,6 +416,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
  
  	if (!mutex_trylock())

return SHRINK_STOP;
@@ -424,10 +426,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -439,9 +446,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
  {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
  
-	for (i = 0; i < NUM_POOLS; ++i)

-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
  
  	return count;

  }
@@ -935,7 +945,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
  }
  
  static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,

-   char *name)
+   char *name, unsigned int order)
  {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -943,11 +953,17 @@ static void ttm_page_pool_init_locked(struct 
ttm_page_pool *pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
  }
  
  int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)

  {
int ret;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   unsigned order = HPAGE_PMD_ORDER;
+#else
+   unsigned order = 0;
+#endif
  
  	WARN_ON(_manager);
  
@@ -955,23 +971,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
  
-	ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");

+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  
-	ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");

+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_dma32,

- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_dma32,

- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", order);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+ , "uc huge", order);
  
  	_manager->options.max_size = max_pages;

_manager->options.small = SMALL_ALLOCATION;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/ttm: add page order in page pool

[Christian König]

Am 22.11.2017 um 10:17 schrieb Roger He:

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 


Reviewed-by: Christian König  for this one.

Feel free to commit it preliminary, but I think we still need to work on 
the rest.


Regards,
Christian.


---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 38 +---
  1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 7385785..a02bd65 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -84,6 +84,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
  };
  
  /**

@@ -415,6 +416,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
  
  	if (!mutex_trylock())

return SHRINK_STOP;
@@ -424,10 +426,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -439,9 +446,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
  {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
  
-	for (i = 0; i < NUM_POOLS; ++i)

-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
  
  	return count;

  }
@@ -935,7 +945,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
  }
  
  static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,

-   char *name)
+   char *name, unsigned int order)
  {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -943,11 +953,17 @@ static void ttm_page_pool_init_locked(struct 
ttm_page_pool *pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
  }
  
  int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)

  {
int ret;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   unsigned order = HPAGE_PMD_ORDER;
+#else
+   unsigned order = 0;
+#endif
  
  	WARN_ON(_manager);
  
@@ -955,23 +971,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
  
-	ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");

+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  
-	ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");

+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_dma32,

- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_dma32,

- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", order);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+ , "uc huge", order);
  
  	_manager->options.max_size = max_pages;

_manager->options.small = SMALL_ALLOCATION;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] drm/ttm: add page order support in ttm_pages_put

[Christian König]

I would rather completely nuke ttm_pages_put() instead of coming up with 
more workarounds here.


Going to provide a cleanup patch to show what I mean, just give me a minute.

Regards,
Christian.

Am 22.11.2017 um 06:36 schrieb Roger He:

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 +---
  1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0a0c653..de64209 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -285,13 +285,39 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
  }
  
  /* set memory back to wb and free the pages. */

-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
  {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   struct page **pages_to_free = NULL;
+   struct page **pages_array;
+   struct page *p;
+   unsigned int i, j, pages_nr = (1 << order);
+
+   if (order > 0) {
+   pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),
+   GFP_KERNEL);
+   if (!pages_to_free) {
+   pr_err("Failed to allocate memory for ttm pages put 
operation\n");
+   return;
+   }
+   }
+
+   for (i = 0; i < npages; ++i) {
+   if (order > 0) {
+   p = pages[i];
+   for (j = 0; j < pages_nr; ++j)
+   pages_to_free[j] = p++;
+
+   pages_array = pages_to_free;
+   } else
+   pages_array = pages;
+
+   if (set_pages_array_wb(pages_array, pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
+
+   kfree(pages_to_free);
  }
  
  static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,

@@ -354,7 +380,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
  
-			ttm_pages_put(pages_to_free, freed_pages);

+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
  
@@ -389,7 +415,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,

spin_unlock_irqrestore(>lock, irq_flags);
  
  	if (freed_pages)

-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
  out:
if (pages_to_free != static_buf)
kfree(pages_to_free);



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/ttm: delete set_pages_array_wb since no one use it anymore

[Roger He]

Change-Id: I9fa45af447c3c78d0b7b2b8958081e584c560120
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a710d9e..388c5b1 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -237,17 +237,6 @@ static int set_pages_wb(struct page *page, int numpages)
return 0;
 }
 
-static int set_pages_array_wb(struct page **pages, int addrinarray)
-{
-#if IS_ENABLED(CONFIG_AGP)
-   int i;
-
-   for (i = 0; i < addrinarray; i++)
-   unmap_page_from_agp(pages[i]);
-#endif
-   return 0;
-}
-
 static int set_pages_array_wc(struct page **pages, int addrinarray)
 {
 #if IS_ENABLED(CONFIG_AGP)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/ttm: roundup the shrink request to prevent skip huge pool

[Roger He]

e.g. shrink reqeust is less than 512, the logic will skip huge pool

Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2dc83c0..a710d9e 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -438,17 +438,19 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
/* select start pool in round robin fashion */
for (i = 0; i < NUM_POOLS; ++i) {
unsigned nr_free = shrink_pages;
+   unsigned page_nr;
+
if (shrink_pages == 0)
break;
 
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
+   page_nr = (1 << pool->order);
/* OK to use static buffer since global mutex is held. */
-   nr_free_pool = (nr_free >> pool->order);
-   if (nr_free_pool == 0)
-   continue;
-
+   nr_free_pool = roundup(nr_free, page_nr) >> pool->order;
shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
-   freed += ((nr_free_pool - shrink_pages) << pool->order);
+   freed += (nr_free_pool - shrink_pages) << pool->order;
+   if (freed >= sc->nr_to_scan)
+   break;
}
mutex_unlock();
return freed;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm/ttm: add set_pages_wb for handling page order more than zero

[Roger He]

Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a02bd65..9b48b93 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -226,6 +226,17 @@ static struct kobj_type ttm_pool_kobj_type = {
 static struct ttm_pool_manager *_manager;
 
 #ifndef CONFIG_X86
+static int set_pages_wb(struct page *page, int numpages)
+{
+#if IS_ENABLED(CONFIG_AGP)
+   int i;
+
+   for (i = 0; i < numpages; i++)
+   unmap_page_from_agp(page++);
+#endif
+   return 0;
+}
+
 static int set_pages_array_wb(struct page **pages, int addrinarray)
 {
 #if IS_ENABLED(CONFIG_AGP)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] drm/ttm: add page order in page pool

[Roger He]

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 38 +---
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 7385785..a02bd65 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -84,6 +84,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
 };
 
 /**
@@ -415,6 +416,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
 
if (!mutex_trylock())
return SHRINK_STOP;
@@ -424,10 +426,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -439,9 +446,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
 {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
 
-   for (i = 0; i < NUM_POOLS; ++i)
-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
 
return count;
 }
@@ -935,7 +945,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 }
 
 static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,
-   char *name)
+   char *name, unsigned int order)
 {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -943,11 +953,17 @@ static void ttm_page_pool_init_locked(struct 
ttm_page_pool *pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
 }
 
 int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 {
int ret;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   unsigned order = HPAGE_PMD_ORDER;
+#else
+   unsigned order = 0;
+#endif
 
WARN_ON(_manager);
 
@@ -955,23 +971,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
 
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
 
-   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
 
-   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");
+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_dma32,
- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
 
ttm_page_pool_init_locked(&_manager->uc_pool_dma32,
- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", order);
 
ttm_page_pool_init_locked(&_manager->uc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+ , "uc huge", order);
 
_manager->options.max_size = max_pages;
_manager->options.small = SMALL_ALLOCATION;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge/sii8620: fix potential buffer overflow

[Maciej Purski]

Buffer overflow error should not occur, as mode_fixup() callback
filters pixel clock value and it should never exceed 60. However,
current implementation is not obviously safe and relies on
implementation of mode_fixup().

Make 'i' variable never reach unsafe value in order to avoid buffer
overflow error.

Reported-by: Dan Carpenter 
Fixes: bf1722ca ("drm/bridge/sii8620: rewrite hdmi start sequence")
Signed-off-by: Maciej Purski 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index d58db13..25ae0e5 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1210,7 +1210,7 @@ static void sii8620_start_video(struct sii8620 *ctx)
int clk = ctx->pixel_clock * (ctx->use_packed_pixel ? 2 : 3);
int i;
 
-   for (i = 0; i < ARRAY_SIZE(clk_spec); ++i)
+   for (i = 0; i < ARRAY_SIZE(clk_spec) - 1; ++i)
if (clk < clk_spec[i].max_clk)
break;
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #40 from Shih-Yuan Lee  ---
Created attachment 135662
  --> https://bugs.freedesktop.org/attachment.cgi?id=135662=edit
dmesg

(In reply to Alex Deucher from comment #38)
> Created attachment 135647 [details] [review]
> workaround for radeon
> 
> workarounds for radeon and amdgpu to fix the issue.

I applied this patch on top of Ubuntu-4.4.0-101.124 Linux kernel and it seems
to fix the issue in the beginning.
But it has some problem later on.

$ seq 20 | while read i; do echo Loop $i; DRI_PRIME=1 glxgears -info|head -n 5;
done
Loop 1
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 65536 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 4
radeon:va: 0x0080
radeon: Failed to deallocate virtual address for buffer:
radeon:size  : 65536 bytes
radeon:va: 0x80
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 65536 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 4
radeon:va: 0x0080
radeon: Failed to deallocate virtual address for buffer:
radeon:size  : 65536 bytes
radeon:va: 0x80
radeonsi: Failed to create a context.
Loop 2
...

-- 
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

[PATCH 10/30] drm/nouveau: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.

Signed-off-by: Sinan Kaya 
---
 drivers/gpu/drm/nouveau/dispnv04/arb.c   | 3 ++-
 drivers/gpu/drm/nouveau/dispnv04/hw.c| 6 --
 drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 2 +-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c 
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..729d7d0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -214,7 +214,8 @@ struct nv_sim_state {
(dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
 
-   pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(0, 0, 1),
+ 0x7c, );
 
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c 
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..4b35093 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -221,7 +221,8 @@
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
 
-   pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(0, 0, 3),
+ 0x6c, );
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +233,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
 
-   pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(0, 0, 5),
+ 0x4c, );
return clock / 1000;
}
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 595630d..0b6c639 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
 
/* subfunction one is a hdmi audio device? */
-   drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+   drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+   (unsigned int)pdev->bus->number,

PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
 
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 3c6a871..3d2a203 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -29,7 +29,7 @@
struct pci_dev *bridge;
u32 mem, mib;
 
-   bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+   bridge = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(>subdev, "no bridge device\n");
return -ENODEV;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/30] drm/i915: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.

Signed-off-by: Sinan Kaya 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9f45cfe..2ca7603 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -419,7 +419,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 
 static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
 {
-   dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+   uint16_t devfn = PCI_DEVFN(0, 0)
+
+   dev_priv->bridge_dev = pci_get_domain_bus_and_slot(0, 0, devfn);
if (!dev_priv->bridge_dev) {
DRM_ERROR("bridge device not found\n");
return -1;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Josh Boyer]

On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> - Document the autoselect process
>>Information about about What, Why, and [ideally] How - analogous to
>>the normal stable nominations.
>>Insert reference to the process in the patch notification email.
>
> I agree with this one, and it'll definitely happen. The story behind
> this is that this is all based on Julia Lawall's work which is well
> documented in a published paper here:
>
> https://soarsmu.github.io/papers/icse12-patch.pdf
>
> I have modified inputs and process, but it essentially is very similar
> to what's described in that paper.
>
> While I have no problem with sharing what I have so far, this is
> still very much work in progress, and things keep constantly changing
> based on comments I receive from reviewers and Greg, so I want to
> reach a more stable point before trying to explain things and change
> my mind the day after :)
>
> If anyone is really interested in seeing the guts of this mess I
> currently have I can push it to github, but bear in mind that in it's
> current state it's very custom to the configuration I have, and is
> a borderline unreadable mix of bash scripts and LUA.
>
> Ideally it'll all get cleaned up and pushed anyways once I feel
> comfortable with the quality of the process.
>
>> - Make the autoselect nominations _more_ distinct than the normal stable 
>> ones.
>>Maintainers will want to put more cognitive effort into the patches.
>
> So this came up before, and the participants of that thread agreed
> that adding "AUTOSEL" in the patch prefix is sufficient. What else
> would you suggest adding?

The root of the concern seems to be around how the stable process
currently works and how auto-selection plays into that.  When Greg
sends out the RC, the default model of "if nobody objects, this patch
will get included in the next stable release" works because a human
already identified as that needing to be included.  So the review is
looking for a NAK, but that's overriding another human's explicit
decision with reasons.  For something that is auto-selected, people
seem concerned that the default should be flipped.  Perhaps they'd be
more comfortable if auto-selected packages required a human ACK before
they are included?

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 03/22] drm/arc: Use drm_fb_cma_fbdev_init/fini()

[Alexey Brodkin]

Hi Noralf,

On Wed, 2017-11-15 at 15:19 +0100, Noralf Trønnes wrote:
> Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
> the fact that drm_device holds a pointer to the drm_fb_helper structure.
> This means that the driver doesn't have to keep track of that.
> Also use the drm_fb_helper functions directly.
> Remove unused function prototype arcpgu_fbdev_cma_init().
> 
> Cc: Alexey Brodkin 
> Signed-off-by: Noralf Trønnes 

Acked-by: Alexey Brodkin 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 11/21/2017 08:34 AM, Christian König wrote:
> Hi Boris,
>
> attached are two patches.
>
> The first one is a trivial fix for the infinite loop issue, it now
> correctly aborts the fixup when it can't find address space for the
> root window.
>
> The second is a workaround for your board. It simply checks if there
> is exactly one Processor Function to apply this fix on.
>
> Both are based on linus current master branch. Please test if they fix
> your issue.


Yes, they do fix it but that's because the feature is disabled.

Do you know what the actual problem was (on Xen)?

Thanks.
-boris

>
> Thanks for the help,
> Christian.
>
> Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky:
>> On 11/20/2017 11:07 AM, Christian König wrote:
>>> Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky:
 (and then it breaks differently as a Xen guest --- we hung on the last
 pci_read_config_dword(), I haven't looked at this at all yet)
>>> Hui? How does this fix applies to a Xen guest in the first place?
>>>
>>> Please provide the output of "lspci -nn" and explain further what is
>>> your config with Xen.
>>>
>>>
>>
>> This is dom0.
>>
>> -bash-4.1# lspci -nn
>> 00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge only
>> dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02)
>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device
>> [1002:5a23]
>> 00:0d.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge
>> (external gfx1 port B) [1002:5a1e]
>> 00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA
>> Controller [AHCI mode] [1002:4391]
>> 00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
>> OHCI0 Controller [1002:4397]
>> 00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
>> Controller [1002:4398]
>> 00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
>> Controller [1002:4396]
>> 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
>> OHCI0 Controller [1002:4397]
>> 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
>> Controller [1002:4398]
>> 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
>> Controller [1002:4396]
>> 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller
>> [1002:4385] (rev 3d)
>> 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host
>> controller [1002:439d]
>> 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge
>> [1002:4384]
>> 00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
>> OHCI2 Controller [1002:4399]
>> 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1600]
>> 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1601]
>> 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1602]
>> 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1603]
>> 00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1604]
>> 00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1605]
>> 00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1600]
>> 00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1601]
>> 00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1602]
>> 00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1603]
>> 00:19.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1604]
>> 00:19.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
>> [1022:1605]
>> 01:04.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA
>> G200eW WPCM450 [102b:0532] (rev 0a)
>> 02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
>> Network Connection [8086:10c9] (rev 01)
>> 02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
>> Network Connection [8086:10c9] (rev 01)
>> -bash-4.1#
>>
>>
>> -boris
>
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/22] drm/cma-helper: Remove drm_fbdev_cma* functions

[Alexey Brodkin]

Hi Noralf,

On Tue, 2017-11-21 at 00:52 +0100, Noralf Trønnes wrote:
> Den 17.11.2017 10.10, skrev Alexey Brodkin:
> > 
> > Hi Noralf,
> > 
> > On Thu, 2017-11-16 at 21:11 +0100, Noralf Trønnes wrote:
> > > 
> > > Den 16.11.2017 09.14, skrev Shawn Guo:
> > > > 
> > > > On Wed, Nov 15, 2017 at 03:19:39PM +0100, Noralf Trønnes wrote:
> > > > > 
> > > > > This patchset adds drm_fb_cma_fbdev_init/fini() functions that 
> > > > > replaces
> > > > > drm_fbdev_cma_init/fini(). The reason for doing so is to get rid of
> > > > > struct drm_fbdev_cma and it's wrapper functions. The final piece will
> > > > > happen when tinydrm moves away from the cma helper and we can remove 
> > > > > the
> > > > > struct.
> > > > > 
> > > > > Note:
> > > > > Patches 19-22 depends on patchset:
> > > > > [v3] drm: Add simple modeset suspend/resume helpers
> > > > Is there a git branch somewhere we can test?
> > > > 
> > > Here you go: 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notro_linux_tree_drm-5Ffb-5Fcma-5Ffbdev-5Finit=DwIDaQ=DPL6_X_6J
> > > kXFx
> > > 7AXWqB0tg=OtZvQ4lNHIbjtyysXrNW8RbX6WFkigcev-xByzJ_fLk=McbBjcx46wmGkpM3GHmk9URB1xbd6ywS-
> > > Z5tpdWwDX8=BewulagwMNQa5xW19olMnlzV5DI5cZ_7eDSPyUpzMV8=
> > Thanks for that this really helps to test your patches.
> > And looks like something is broken for ARC PGU + ADV7511 with your tree:
> > -->8
> > adv7511: probe of 1-0039 failed with error -2
> 
> Maybe the problem is with the cec support added after 4.14:
> 
> drm: adv7511/33: add HDMI CEC support
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_drm_drm-2Dmisc_commit_drivers_gpu_drm_bridge_adv7511-3Fid-3D3b1b975003e4a3
> da4b93ab032487a3ae4afca7b5=DwIDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=H7HSEHrOweYdtYmtV7QQ7l6ndVPGq1aUigPo3Wq
> DlNg=67zDRPjQ2iyMOhroP6wat67ESWhYnGPAhKgbmgHwxQ0=
> 
> Apparently there's a problem with it:
> 
> [PATCHv2] drm: adv7511/33: Fix adv7511_cec_init() failure handling
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2017-2DNovember_158024.html=DwIDaQ=DPL6_X_6JkXFx
> 7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=H7HSEHrOweYdtYmtV7QQ7l6ndVPGq1aUigPo3WqDlNg=ecprlgbDaK04JzdFl4w5JR7J-
> HoHaHCMwB0BfgRxufY=

Thanks a lot for the pointer!

Indeed this patch fixes a problem:
>8
arcpgu e0017000.pgu: arc_pgu ID: 0x41440304
arcpgu e0017000.pgu: assigned reserved memory node frame_buffer@9e00
Console: switching to colour frame buffer device 160x45
arcpgu e0017000.pgu: fb0:  frame buffer device
[drm] Initialized arcpgu 1.0.0 20160219 for e0017000.pgu on minor 0
>8

So I'll reply with my ack for ARC PGU patch then as it works perfectly fine for 
me.

-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[alexander . levin]

On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote:
>The root of the concern seems to be around how the stable process
>currently works and how auto-selection plays into that.  When Greg
>sends out the RC, the default model of "if nobody objects, this patch
>will get included in the next stable release" works because a human
>already identified as that needing to be included.  So the review is
>looking for a NAK, but that's overriding another human's explicit
>decision with reasons.  For something that is auto-selected, people
>seem concerned that the default should be flipped.  Perhaps they'd be
>more comfortable if auto-selected packages required a human ACK before
>they are included?

Josh, I review the autogenerated list of commits, patch by patch,
myself, before sending it out. So there is a human involved in the
process.

Admittingly I'm not perfect and things do slip by once in a while. I
always look back and try to improve the process. Although the sample
size is small now (~600 commits proposed and merged using this method)
I don't belive the error rate is higher than the error rate for
"regular" stable tree commits.

I'd treat autoselection as a helper tool for the stable tree
maintainer rather than a magical way to produce stable commits (we're
not going to replace Greg with a robot any time soon).

-- 

Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/mediatek: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

[Vasyl Gomonovych]

Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).

drivers/gpu/drm/mediatek/mtk_drm_gem.c:223:9-16: WARNING: ERR_CAST can be used 
with mtk_gem
Generated by: scripts/coccinelle/api/err_cast.cocci

Signed-off-by: Vasyl Gomonovych 
---
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index f595ac816b55..5766b42fc174 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -220,7 +220,7 @@ struct drm_gem_object *mtk_gem_prime_import_sg_table(struct 
drm_device *dev,
mtk_gem = mtk_drm_gem_init(dev, attach->dmabuf->size);
 
if (IS_ERR(mtk_gem))
-   return ERR_PTR(PTR_ERR(mtk_gem));
+   return ERR_CAST(mtk_gem));
 
expected = sg_dma_address(sg->sgl);
for_each_sg(sg->sgl, s, sg->nents, i) {
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/4] drm/ttm: add page order in page pool

[He, Roger]

-Original Message-
From: Koenig, Christian 
Sent: Wednesday, November 22, 2017 3:48 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/ttm: add page order in page pool

Am 22.11.2017 um 06:36 schrieb Roger He:
> to indicate page order for each element in the pool
>
> Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 
> ++--
>   1 file changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 72ea037..0a0c653 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -81,6 +81,7 @@ struct ttm_page_pool {
>   char*name;
>   unsigned long   nfrees;
>   unsigned long   nrefills;
> + unsigned intorder;
>   };
>   
>   /**
> @@ -412,6 +413,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
> shrink_control *sc)
>   struct ttm_page_pool *pool;
>   int shrink_pages = sc->nr_to_scan;
>   unsigned long freed = 0;
> + unsigned int nr_free_pool;
>   
>   if (!mutex_trylock())
>   return SHRINK_STOP;
> @@ -421,10 +423,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
> shrink_control *sc)
>   unsigned nr_free = shrink_pages;
>   if (shrink_pages == 0)
>   break;
> +
>   pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
>   /* OK to use static buffer since global mutex is held. */
> - shrink_pages = ttm_page_pool_free(pool, nr_free, true);
> - freed += nr_free - shrink_pages;
> + nr_free_pool = (nr_free >> pool->order);
> + if (nr_free_pool == 0)
> + continue;
> +
> + shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
> + freed += ((nr_free_pool - shrink_pages) << pool->order);
>   }
>   mutex_unlock();
>   return freed;
> @@ -436,9 +443,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
> shrink_control *sc)
>   {
>   unsigned i;
>   unsigned long count = 0;
> + struct ttm_page_pool *pool;
>   
> - for (i = 0; i < NUM_POOLS; ++i)
> - count += _manager->pools[i].npages;
> + for (i = 0; i < NUM_POOLS; ++i) {
> + pool = &_manager->pools[i];
> + count += (pool->npages << pool->order);
> + }
>   
>   return count;
>   }
> @@ -932,7 +942,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
> npages, int flags,
>   }
>   
>   static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t 
> flags,
> - char *name)
> + char *name, unsigned int order)
>   {
>   spin_lock_init(>lock);
>   pool->fill_lock = false;
> @@ -940,8 +950,18 @@ static void ttm_page_pool_init_locked(struct 
> ttm_page_pool *pool, gfp_t flags,
>   pool->npages = pool->nfrees = 0;
>   pool->gfp_flags = flags;
>   pool->name = name;
> + pool->order = order;
>   }
>   
> +/**
> + * Actually if TRANSPARENT_HUGEPAGE not enabled, we will not use
> + * wc_pool_huge and uc_pool_huge, so no matter whatever the page
> + * order are for those two pools
> + */
> +#ifndef CONFIG_TRANSPARENT_HUGEPAGE
> +#define  HPAGE_PMD_ORDER 9
> +#endif
> +

That still won't work and sorry I wasn't 100% clear in the last mail.

When CONFIG_TRANSPARENT_HUGEPAGE isn't set HPAGE_PMD_ORDER is defined as 
BUILD_BUG().

So you will still run into problems when that config option isn't set.

>   int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
>   {
>   int ret;

I suggest to just handle it here like this

#ifdef CONFIG_TRANSPARENT_HUGEPAGE
     unsigned order = HPAGE_PMD_ORDER;
#else
     unsigned order = 0;
#endif

Apart from that the patch looks good to me, Christian.


Ok, going to modify it. Thanks!

Thanks
Roger(Hongbo.He)

> @@ -952,23 +972,23 @@ int ttm_page_alloc_init(struct ttm_mem_global 
> *glob, unsigned max_pages)
>   
>   _manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
>   
> - ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
> + ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 
> +0);
>   
> - ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");
> + ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 
> +0);
>   
>   ttm_page_pool_init_locked(&_manager->wc_pool_dma32,
> -   GFP_USER | GFP_DMA32, "wc dma");
> +   GFP_USER | GFP_DMA32, "wc dma", 0);
>   
>   ttm_page_pool_init_locked(&_manager->uc_pool_dma32,
> -   GFP_USER | GFP_DMA32, "uc dma");
> +   GFP_USER | 

[PATCH 5/5] drm/ttm: delete set_pages_array_wb since no one use it anymore

[Roger He]

Change-Id: I9fa45af447c3c78d0b7b2b8958081e584c560120
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 82d40c6..53fd8e9 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -237,17 +237,6 @@ static int set_pages_wb(struct page *page, int numpages)
return 0;
 }
 
-static int set_pages_array_wb(struct page **pages, int addrinarray)
-{
-#if IS_ENABLED(CONFIG_AGP)
-   int i;
-
-   for (i = 0; i < addrinarray; i++)
-   unmap_page_from_agp(pages[i]);
-#endif
-   return 0;
-}
-
 static int set_pages_array_wc(struct page **pages, int addrinarray)
 {
 #if IS_ENABLED(CONFIG_AGP)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/ttm: free one in huge pool even shrink request less than one element

[Roger He]

Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 343db0b..82d40c6 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -444,11 +444,13 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
nr_free_pool = (nr_free >> pool->order);
-   if (nr_free_pool == 0)
-   continue;
+   if (!nr_free_pool && pool->order)
+   nr_free_pool = 1;
 
shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
freed += ((nr_free_pool - shrink_pages) << pool->order);
+   if (freed >= sc->nr_to_scan)
+   break;
}
mutex_unlock();
return freed;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm/ttm: add set_pages_wb for handling page order more than zero

[Roger He]

Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2db551f..fabb082 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -226,6 +226,17 @@ static struct kobj_type ttm_pool_kobj_type = {
 static struct ttm_pool_manager *_manager;
 
 #ifndef CONFIG_X86
+static int set_pages_wb(struct page *page, int numpages)
+{
+#if IS_ENABLED(CONFIG_AGP)
+   int i;
+
+   for (i = 0; i < numpages; i++)
+   unmap_page_from_agp(page++);
+#endif
+   return 0;
+}
+
 static int set_pages_array_wb(struct page **pages, int addrinarray)
 {
 #if IS_ENABLED(CONFIG_AGP)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm/ttm: add page order support in ttm_pages_put

[Roger He]

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index fabb082..343db0b 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -299,13 +299,16 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
 }
 
 /* set memory back to wb and free the pages. */
-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
 {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   unsigned int i, pages_nr = (1 << order);
+
+   for (i = 0; i < npages; ++i) {
+   if (set_pages_wb(pages[i], pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
 }
 
 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,
@@ -368,7 +371,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
 
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
 
@@ -403,7 +406,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
spin_unlock_irqrestore(>lock, irq_flags);
 
if (freed_pages)
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
 out:
if (pages_to_free != static_buf)
kfree(pages_to_free);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] drm/ttm: add page order in page pool

[Roger He]

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 ++--
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 7385785..2db551f 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -84,6 +84,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
 };
 
 /**
@@ -415,6 +416,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
 
if (!mutex_trylock())
return SHRINK_STOP;
@@ -424,10 +426,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -439,9 +446,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
 {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
 
-   for (i = 0; i < NUM_POOLS; ++i)
-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
 
return count;
 }
@@ -935,7 +945,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 }
 
 static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,
-   char *name)
+   char *name, unsigned int order)
 {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -943,8 +953,18 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool 
*pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
 }
 
+/**
+ * Actually if TRANSPARENT_HUGEPAGE not enabled, we will not use
+ * wc_pool_huge and uc_pool_huge, so no matter whatever the page
+ * order are for those two pools
+ */
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
+#defineHPAGE_PMD_ORDER 9
+#endif
+
 int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 {
int ret;
@@ -955,23 +975,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
 
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
 
-   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
 
-   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");
+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_dma32,
- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
 
ttm_page_pool_init_locked(&_manager->uc_pool_dma32,
- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", HPAGE_PMD_ORDER);
 
ttm_page_pool_init_locked(&_manager->uc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+ , "uc huge", HPAGE_PMD_ORDER);
 
_manager->options.max_size = max_pages;
_manager->options.small = SMALL_ALLOCATION;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/ttm: add page order in page pool

[Christian König]

Am 22.11.2017 um 06:36 schrieb Roger He:

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 ++--
  1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 72ea037..0a0c653 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -81,6 +81,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
  };
  
  /**

@@ -412,6 +413,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
  
  	if (!mutex_trylock())

return SHRINK_STOP;
@@ -421,10 +423,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -436,9 +443,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
  {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
  
-	for (i = 0; i < NUM_POOLS; ++i)

-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
  
  	return count;

  }
@@ -932,7 +942,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
  }
  
  static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,

-   char *name)
+   char *name, unsigned int order)
  {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -940,8 +950,18 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool 
*pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
  }
  
+/**

+ * Actually if TRANSPARENT_HUGEPAGE not enabled, we will not use
+ * wc_pool_huge and uc_pool_huge, so no matter whatever the page
+ * order are for those two pools
+ */
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
+#defineHPAGE_PMD_ORDER 9
+#endif
+


That still won't work and sorry I wasn't 100% clear in the last mail.

When CONFIG_TRANSPARENT_HUGEPAGE isn't set HPAGE_PMD_ORDER is defined as 
BUILD_BUG().


So you will still run into problems when that config option isn't set.


  int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
  {
int ret;


I suggest to just handle it here like this

#ifdef CONFIG_TRANSPARENT_HUGEPAGE
    unsigned order = HPAGE_PMD_ORDER;
#else
    unsigned order = 0;
#endif

Apart from that the patch looks good to me,
Christian.


@@ -952,23 +972,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
  
-	ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");

+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  
-	ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");

+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_dma32,

- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_dma32,

- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", HPAGE_PMD_ORDER);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+