Re: [PATCH 5/8] drm/sun4i: Add a driver for the display frontend

[kbuild test robot]

Hi Maxime,

I love your patch! Yet something to improve:

[auto build test ERROR on ]

url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
base:
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: the 
linux-review/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
 HEAD c38c4ce4b14c4c68a9fde0cc35ead5b1c894776b builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_bind':
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:22: error: implicit declaration of 
>> function 'sun4i_backend_find_frontend'; did you mean 'sun4i_backend_bind'? 
>> [-Werror=implicit-function-declaration]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
 ^~~
 sun4i_backend_bind
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:20: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
   ^
   cc1: some warnings being treated as errors

vim +370 drivers/gpu/drm/sun4i/sun4i_backend.c

   346  
   347  static int sun4i_backend_bind(struct device *dev, struct device *master,
   348void *data)
   349  {
   350  struct platform_device *pdev = to_platform_device(dev);
   351  struct drm_device *drm = data;
   352  struct sun4i_drv *drv = drm->dev_private;
   353  struct sun4i_backend *backend;
   354  const struct sun4i_backend_quirks *quirks;
   355  struct resource *res;
   356  void __iomem *regs;
   357  int i, ret;
   358  
   359  backend = devm_kzalloc(dev, sizeof(*backend), GFP_KERNEL);
   360  if (!backend)
   361  return -ENOMEM;
   362  dev_set_drvdata(dev, backend);
   363  
   364  backend->engine.node = dev->of_node;
   365  backend->engine.ops = _backend_engine_ops;
   366  backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
   367  if (backend->engine.id < 0)
   368  return backend->engine.id;
   369  
 > 370  backend->frontend = sun4i_backend_find_frontend(drv, 
 > dev->of_node);
   371  if (IS_ERR(backend->frontend)) {
   372  dev_err(dev, "Couldn't find matching frontend, frontend 
features disabled\n");
   373  }
   374  
   375  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   376  regs = devm_ioremap_resource(dev, res);
   377  if (IS_ERR(regs))
   378  return PTR_ERR(regs);
   379  
   380  backend->reset = devm_reset_control_get(dev, NULL);
   381  if (IS_ERR(backend->reset)) {
   382  dev_err(dev, "Couldn't get our reset line\n");
   383  return PTR_ERR(backend->reset);
   384  }
   385  
   386  ret = reset_control_deassert(backend->reset);
   387  if (ret) {
   388  dev_err(dev, "Couldn't deassert our reset line\n");
   389  return ret;
   390  }
   391  
   392  backend->bus_clk = devm_clk_get(dev, "ahb");
   393  if (IS_ERR(backend->bus_clk)) {
   394  dev_err(dev, "Couldn't get the backend bus clock\n");
   395  ret = PTR_ERR(backend->bus_clk);
   396  goto err_assert_reset;
   397  }
   398  clk_prepare_enable(backend->bus_clk);
   399  
   400  backend->mod_clk = devm_clk_get(dev, "mod");
   401  if (IS_ERR(backend->mod_clk)) {
   402  dev_err(dev, "Couldn't get the backend module clock\n");
   403  ret = PTR_ERR(backend->mod_clk);
   404  goto err_disable_bus_clk;
   405  }
   406  clk_prepare_enable(backend->mod_clk);
   407  
   408  backend->ram_clk = devm_clk_get(dev, "ram");
   409  if (IS_ERR(backend->ram_clk)) {
   410  dev_err(dev, "Couldn't get the backend RAM clock\n");
   411  ret = PTR_ERR(backend->ram_clk);
   412  goto err_disable_mod_clk;
   413  }
   414  clk_prepare_enable(backend->ram_clk);
   415  
   416  if (of_device_is_compatible(dev->of_node,
   417  
"allwinner,sun8i-a33-display-backend")) {
   418  ret = sun4i_backend_init_sat(dev);
   419  if (ret) {
   420  

Re: [PATCH 1/3] drm/prime: forward begin_cpu_access callback to drivers

[kbuild test robot]

Hi Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.15-rc3 next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Samuel-Li/drm-prime-forward-begin_cpu_access-callback-to-drivers/20171216-125056
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-a0-201750 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/drm_drv.c:36:0:
>> include/drm/drm_drv.h:494:14: warning: 'enum dma_data_direction' declared 
>> inside parameter list
enum dma_data_direction direction);
 ^
>> include/drm/drm_drv.h:494:14: warning: its scope is only this definition or 
>> declaration, which is probably not what you want

vim +494 include/drm/drm_drv.h

59  
60  /**
61   * struct drm_driver - DRM driver structure
62   *
63   * This structure represent the common code for a family of cards. 
There will
64   * one drm_device for each card present in this family. It contains 
lots of
65   * vfunc entries, and a pile of those probably should be moved to more
66   * appropriate places like _mode_config_funcs or into a new 
operations
67   * structure for GEM drivers.
68   */
69  struct drm_driver {
70  /**
71   * @load:
72   *
73   * Backward-compatible driver callback to complete
74   * initialization steps after the driver is registered.  For
75   * this reason, may suffer from race conditions and its use is
76   * deprecated for new drivers.  It is therefore only supported
77   * for existing drivers not yet converted to the new scheme.
78   * See drm_dev_init() and drm_dev_register() for proper and
79   * race-free way to set up a  drm_device.
80   *
81   * This is deprecated, do not use!
82   *
83   * Returns:
84   *
85   * Zero on success, non-zero value on failure.
86   */
87  int (*load) (struct drm_device *, unsigned long flags);
88  
89  /**
90   * @open:
91   *
92   * Driver callback when a new  drm_file is opened. 
Useful for
93   * setting up driver-private data structures like buffer 
allocators,
94   * execution contexts or similar things. Such driver-private 
resources
95   * must be released again in @postclose.
96   *
97   * Since the display/modeset side of DRM can only be owned by 
exactly
98   * one  drm_file (see _file.is_master and 
_device.master)
99   * there should never be a need to set up any modeset related 
resources
   100   * in this callback. Doing so would be a driver design bug.
   101   *
   102   * Returns:
   103   *
   104   * 0 on success, a negative error code on failure, which will be
   105   * promoted to userspace as the result of the open() system 
call.
   106   */
   107  int (*open) (struct drm_device *, struct drm_file *);
   108  
   109  /**
   110   * @postclose:
   111   *
   112   * One of the driver callbacks when a new  drm_file is 
closed.
   113   * Useful for tearing down driver-private data structures 
allocated in
   114   * @open like buffer allocators, execution contexts or similar 
things.
   115   *
   116   * Since the display/modeset side of DRM can only be owned by 
exactly
   117   * one  drm_file (see _file.is_master and 
_device.master)
   118   * there should never be a need to tear down any modeset related
   119   * resources in this callback. Doing so would be a driver 
design bug.
   120   */
   121  void (*postclose) (struct drm_device *, struct drm_file *);
   122  
   123  /**
   124   * @lastclose:
   125   *
   126   * Called when the last  drm_file has been closed and 
there's
   127   * currently no userspace client for the  drm_device.
   128   *
   129   * Modern drivers should only use this to force-restore the 
fbdev
   130   * framebuffer using 
drm_fb_helper_restore_fbdev_mode_unlocked().
   131   * Anything else would indicate there's something seriously 
wrong.
   132   * Modern drivers can also use this to execute delayed power 
switching
   133   * state changes, e.g. in conjunction with the 
:ref:`vga_switcheroo`
   134 

Re: [PATCH 1/3] drm/prime: forward begin_cpu_access callback to drivers

[kbuild test robot]

Hi Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.15-rc3 next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Samuel-Li/drm-prime-forward-begin_cpu_access-callback-to-drivers/20171216-125056
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-x016-201750 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/drm_drv.c:36:0:
>> include/drm/drm_drv.h:494:14: warning: 'enum dma_data_direction' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
enum dma_data_direction direction);
 ^~

vim +494 include/drm/drm_drv.h

59  
60  /**
61   * struct drm_driver - DRM driver structure
62   *
63   * This structure represent the common code for a family of cards. 
There will
64   * one drm_device for each card present in this family. It contains 
lots of
65   * vfunc entries, and a pile of those probably should be moved to more
66   * appropriate places like _mode_config_funcs or into a new 
operations
67   * structure for GEM drivers.
68   */
69  struct drm_driver {
70  /**
71   * @load:
72   *
73   * Backward-compatible driver callback to complete
74   * initialization steps after the driver is registered.  For
75   * this reason, may suffer from race conditions and its use is
76   * deprecated for new drivers.  It is therefore only supported
77   * for existing drivers not yet converted to the new scheme.
78   * See drm_dev_init() and drm_dev_register() for proper and
79   * race-free way to set up a  drm_device.
80   *
81   * This is deprecated, do not use!
82   *
83   * Returns:
84   *
85   * Zero on success, non-zero value on failure.
86   */
87  int (*load) (struct drm_device *, unsigned long flags);
88  
89  /**
90   * @open:
91   *
92   * Driver callback when a new  drm_file is opened. 
Useful for
93   * setting up driver-private data structures like buffer 
allocators,
94   * execution contexts or similar things. Such driver-private 
resources
95   * must be released again in @postclose.
96   *
97   * Since the display/modeset side of DRM can only be owned by 
exactly
98   * one  drm_file (see _file.is_master and 
_device.master)
99   * there should never be a need to set up any modeset related 
resources
   100   * in this callback. Doing so would be a driver design bug.
   101   *
   102   * Returns:
   103   *
   104   * 0 on success, a negative error code on failure, which will be
   105   * promoted to userspace as the result of the open() system 
call.
   106   */
   107  int (*open) (struct drm_device *, struct drm_file *);
   108  
   109  /**
   110   * @postclose:
   111   *
   112   * One of the driver callbacks when a new  drm_file is 
closed.
   113   * Useful for tearing down driver-private data structures 
allocated in
   114   * @open like buffer allocators, execution contexts or similar 
things.
   115   *
   116   * Since the display/modeset side of DRM can only be owned by 
exactly
   117   * one  drm_file (see _file.is_master and 
_device.master)
   118   * there should never be a need to tear down any modeset related
   119   * resources in this callback. Doing so would be a driver 
design bug.
   120   */
   121  void (*postclose) (struct drm_device *, struct drm_file *);
   122  
   123  /**
   124   * @lastclose:
   125   *
   126   * Called when the last  drm_file has been closed and 
there's
   127   * currently no userspace client for the  drm_device.
   128   *
   129   * Modern drivers should only use this to force-restore the 
fbdev
   130   * framebuffer using 
drm_fb_helper_restore_fbdev_mode_unlocked().
   131   * Anything else would indicate there's something seriously 
wrong.
   132   * Modern drivers can also use this to execute delayed power 
switching
   133   * state changes, e.g. in conjunction with the 
:ref:`vga_switcheroo`
   134   * infrastructure.
   135   *
   136 

Re: [PATCH] drm: Fix possible deadlock in drm_mode_config_cleanup()

[kbuild test robot]

Hi Marek,

I love your patch! Perhaps something to improve:

[auto build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next 
drm-intel/for-linux-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/drm-Fix-possible-deadlock-in-drm_mode_config_cleanup/20171216-102239
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
   include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHE

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=197925

--- Comment #9 from kwka...@gmx.com ---
#3 is fixed in both my monitor configurations.

#2 the behavior is still identical to Comment 5.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198123

--- Comment #8 from Deposite Pirate (dpir...@metalpunks.info) ---
Ok, I went through all the git bisect process. Here are the results:

git bisect start
# bad: [a638349bf6c29433b938141f99225b160551ff48] Merge branch 'for-4.15-fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu
git bisect bad a638349bf6c29433b938141f99225b160551ff48
# good: [47b4a457e4cc816b3fdd2ee55c65fda8ea6de051] alarmtimer: Fix unavailable
wake-up source in sysfs
git bisect good 47b4a457e4cc816b3fdd2ee55c65fda8ea6de051
# bad: [2040c47361646d18b9832fd930d2a025da002a57] Merge branch 'drm-next-4.14'
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect bad 2040c47361646d18b9832fd930d2a025da002a57
# good: [5771a8c08880cdca3bfb4a3fc6d309d6bba20877] Linux v4.13-rc1
git bisect good 5771a8c08880cdca3bfb4a3fc6d309d6bba20877
# bad: [37899a5254917e17418bbb23086d55e38faaa659] drm/amdgpu/gfx7: fix function
name
git bisect bad 37899a5254917e17418bbb23086d55e38faaa659
# good: [520eccdfe187591a51ea9ab4c1a024ae4d0f68d9] Linux 4.13-rc2
git bisect good 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9
# bad: [9a61c54b9bff88e692ac7b1245546539ac5274a1] drm/rockchip: vop: group vop
registers
git bisect bad 9a61c54b9bff88e692ac7b1245546539ac5274a1
# bad: [8572636e45167adbdb997fe5c43122bf77fd2291] drm/nouveau: Handle
drm_atomic_helper_swap_state failure
git bisect bad 8572636e45167adbdb997fe5c43122bf77fd2291
# good: [05ccf211efbb6c8b5da2b5fda4f9399a7bc0db2e] drm: ttm: virtio-gpu:
dma-buf: Constify ttm_place structures.
git bisect good 05ccf211efbb6c8b5da2b5fda4f9399a7bc0db2e
# bad: [30ea752146e147c5a1f0367aa5303929f7bfd697] drm/imx: Use atomic iterator
macros
git bisect bad 30ea752146e147c5a1f0367aa5303929f7bfd697
# bad: [dd2adf743bc47ac14999bb375fed390af6524f29] drm/bridge: analogix-anx78xx:
clean up drm_bridge_add call
git bisect bad dd2adf743bc47ac14999bb375fed390af6524f29
# good: [bdac4a052a47920eeae22441ab608612dc0ef4e5] drm/fb-helper: Push locking
in fb_is_bound
git bisect good bdac4a052a47920eeae22441ab608612dc0ef4e5
# good: [6b7dc6e9f82615836b389cb5f806914048b132cd] drm/fb-helper: Split dpms
handling into legacy and atomic paths
git bisect good 6b7dc6e9f82615836b389cb5f806914048b132cd
# bad: [a3562a0e471df02234f74ab4e0625042f44a76e9] drm/fb-helper: keep the
.gamma_store updated in drm_fb_helper_setcmap
git bisect bad a3562a0e471df02234f74ab4e0625042f44a76e9
# bad: [b8e2b0199cc377617dc238f5106352c06dcd3fa2] drm/fb-helper: factor out
pseudo-palette
git bisect bad b8e2b0199cc377617dc238f5106352c06dcd3fa2
# first bad commit: [b8e2b0199cc377617dc238f5106352c06dcd3fa2] drm/fb-helper:
factor out pseudo-palette

b8e2b0199cc377617dc238f5106352c06dcd3fa2 is the first bad commit
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin 
Date:   Tue Jul 4 12:36:57 2017 +0200

drm/fb-helper: factor out pseudo-palette

The pseudo-palette has nothing to do with the crtc, so move it
out of the crtc loop and update the palette once, then break out
early.

Signed-off-by: Peter Rosin 
Signed-off-by: Daniel Vetter 
Link:
http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-p...@axentia.se

:04 04 a8c2650554e199fee994ac63c2700c73ba2ecffe
7f72ed414efadd77ef1d718e7477475c4ba1127d M  drivers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:drm-next-4.16-wip 105/117] drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:119:21: sparse: cast removes address space of expression

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.16-wip
head:   8f003334f9f06d5a4c03c3d966ba258d770b97f4
commit: b8e7f06f8cc17c9f978987c9b98886f6e338a506 [105/117] drm/amdgpu: move 
debugfs functions to their own file
reproduce:
# apt-get install sparse
git checkout b8e7f06f8cc17c9f978987c9b98886f6e338a506
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)


vim +119 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c

66  
67  static ssize_t amdgpu_debugfs_regs_read(struct file *f, char __user 
*buf,
68  size_t size, loff_t *pos)
69  {
70  struct amdgpu_device *adev = file_inode(f)->i_private;
71  ssize_t result = 0;
72  int r;
73  bool pm_pg_lock, use_bank;
74  unsigned instance_bank, sh_bank, se_bank;
75  
76  if (size & 0x3 || *pos & 0x3)
77  return -EINVAL;
78  
79  /* are we reading registers for which a PG lock is necessary? */
80  pm_pg_lock = (*pos >> 23) & 1;
81  
82  if (*pos & (1ULL << 62)) {
83  se_bank = (*pos & GENMASK_ULL(33, 24)) >> 24;
84  sh_bank = (*pos & GENMASK_ULL(43, 34)) >> 34;
85  instance_bank = (*pos & GENMASK_ULL(53, 44)) >> 44;
86  
87  if (se_bank == 0x3FF)
88  se_bank = 0x;
89  if (sh_bank == 0x3FF)
90  sh_bank = 0x;
91  if (instance_bank == 0x3FF)
92  instance_bank = 0x;
93  use_bank = 1;
94  } else {
95  use_bank = 0;
96  }
97  
98  *pos &= (1UL << 22) - 1;
99  
   100  if (use_bank) {
   101  if ((sh_bank != 0x && sh_bank >= 
adev->gfx.config.max_sh_per_se) ||
   102  (se_bank != 0x && se_bank >= 
adev->gfx.config.max_shader_engines))
   103  return -EINVAL;
   104  mutex_lock(>grbm_idx_mutex);
   105  amdgpu_gfx_select_se_sh(adev, se_bank,
   106  sh_bank, instance_bank);
   107  }
   108  
   109  if (pm_pg_lock)
   110  mutex_lock(>pm.mutex);
   111  
   112  while (size) {
   113  uint32_t value;
   114  
   115  if (*pos > adev->rmmio_size)
   116  goto end;
   117  
   118  value = RREG32(*pos >> 2);
 > 119  r = put_user(value, (uint32_t *)buf);
   120  if (r) {
   121  result = r;
   122  goto end;
   123  }
   124  
   125  result += 4;
   126  buf += 4;
   127  *pos += 4;
   128  size -= 4;
   129  }
   130  
   131  end:
   132  if (use_bank) {
   133  amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
   134  mutex_unlock(>grbm_idx_mutex);
   135  }
   136  
   137  if (pm_pg_lock)
   138  mutex_unlock(>pm.mutex);
   139  
   140  return result;
   141  }
   142  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/virtio: Add window server support

[kbuild test robot]

Hi Tomeu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tomeu-Vizoso/drm-virtio-Add-window-server-support/20171216-081939
config: i386-randconfig-x002-201750 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/uapi/linux/aio_abi.h:31,
from include/linux/syscalls.h:72,
from drivers/gpu/drm/virtio/virtgpu_ioctl.c:29:
   drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl_rx':
   drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
  if (copy_to_user((void *)cmd->data + read_count,
   ^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:3: note: in expansion of macro 
>> 'if'
  if (copy_to_user((void *)cmd->data + read_count,
  ^~
   drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
  if (copy_to_user((void *)cmd->data + read_count,
   ^
   include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:3: note: in expansion of macro 
>> 'if'
  if (copy_to_user((void *)cmd->data + read_count,
  ^~
   drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
  if (copy_to_user((void *)cmd->data + read_count,
   ^
   include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:3: note: in expansion of macro 
>> 'if'
  if (copy_to_user((void *)cmd->data + read_count,
  ^~
   drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl':
   drivers/gpu/drm/virtio/virtgpu_ioctl.c:615:5: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
(const char __user *) winsrv_cmd.data,
^

vim +/if +562 drivers/gpu/drm/virtio/virtgpu_ioctl.c

   547  
   548  static int winsrv_ioctl_rx(struct virtio_gpu_device *vgdev,
   549 struct virtio_gpu_winsrv_conn *conn,
   550 struct drm_virtgpu_winsrv *cmd)
   551  {
   552  struct virtio_gpu_winsrv_rx_qentry *qentry, *tmp;
   553  struct virtio_gpu_winsrv_rx *virtio_cmd;
   554  int available_len = cmd->len;
   555  int read_count = 0;
   556  
   557  list_for_each_entry_safe(qentry, tmp, >cmdq, next) {
   558  virtio_cmd = qentry->cmd;
   559  if (virtio_cmd->len > available_len)
   560  return 0;
   561  
 > 562  if (copy_to_user((void *)cmd->data + read_count,
   563   virtio_cmd->data,
   564   virtio_cmd->len)) {
   565  /* return error unless we have some data to 
return */
   566  if (read_count == 0)
   567  return -EFAULT;
   568  }
   569  
   570  /*
   571   * here we could export resource IDs to FDs, but no 
protocol
   572   * as of today requires it
   573   */
   574  
   575  available_len -= virtio_cmd->len;
   576  read_count += virtio_cmd->len;
   577  
   578  virtio_gpu_queue_winsrv_rx_in(vgdev, virtio_cmd);
   579  
   580  list_del(>next);
   581  kfree(qentry);
   582  }
   583  
   584  cmd->len = read_count;
   585  
   586  return 0;
   587  }
   588  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/

Re: [PATCH] drm/virtio: Add window server support

[kbuild test robot]

Hi Tomeu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tomeu-Vizoso/drm-virtio-Add-window-server-support/20171216-081939
config: i386-randconfig-x016-201750 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl_rx':
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from 
>> integer of different size [-Wint-to-pointer-cast]
  if (copy_to_user((void *)cmd->data + read_count,
   ^
   drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl':
   drivers/gpu/drm/virtio/virtgpu_ioctl.c:615:5: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
(const char __user *) winsrv_cmd.data,
^

vim +562 drivers/gpu/drm/virtio/virtgpu_ioctl.c

   547  
   548  static int winsrv_ioctl_rx(struct virtio_gpu_device *vgdev,
   549 struct virtio_gpu_winsrv_conn *conn,
   550 struct drm_virtgpu_winsrv *cmd)
   551  {
   552  struct virtio_gpu_winsrv_rx_qentry *qentry, *tmp;
   553  struct virtio_gpu_winsrv_rx *virtio_cmd;
   554  int available_len = cmd->len;
   555  int read_count = 0;
   556  
   557  list_for_each_entry_safe(qentry, tmp, >cmdq, next) {
   558  virtio_cmd = qentry->cmd;
   559  if (virtio_cmd->len > available_len)
   560  return 0;
   561  
 > 562  if (copy_to_user((void *)cmd->data + read_count,
   563   virtio_cmd->data,
   564   virtio_cmd->len)) {
   565  /* return error unless we have some data to 
return */
   566  if (read_count == 0)
   567  return -EFAULT;
   568  }
   569  
   570  /*
   571   * here we could export resource IDs to FDs, but no 
protocol
   572   * as of today requires it
   573   */
   574  
   575  available_len -= virtio_cmd->len;
   576  read_count += virtio_cmd->len;
   577  
   578  virtio_gpu_queue_winsrv_rx_in(vgdev, virtio_cmd);
   579  
   580  list_del(>next);
   581  kfree(qentry);
   582  }
   583  
   584  cmd->len = read_count;
   585  
   586  return 0;
   587  }
   588  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: Add support for AUO G104SN02 V2 panel

[Rob Herring]

On Wed, Dec 13, 2017 at 03:00:56PM +0100, Christoph Fritz wrote:
> This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM
> simple panel driver.
> 
> Signed-off-by: Christoph Fritz 
> Signed-off-by: Stefan Riedmueller 
> ---
>  .../bindings/display/panel/auo,g104sn02.txt|  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt 
> b/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt
> new file mode 100644
> index 000..050ac90
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt
> @@ -0,0 +1,7 @@
> +AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,g104sn02"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

Please be explicit as to which properties apply. power-supply?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-fixes-4.15

[Alex Deucher]

Hi Dave,

I forgot to include the DC fixes from Harry when I sent out
my fixes yesterday.  This just adds them on top.

The following changes since commit 0507f438ea19d4280006467ba02956f6a693deca:

  drm/amdgpu: fix MAP_QUEUES paramter (2017-12-12 15:40:11 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.15

for you to fetch changes up to becd0875f4393a992afbf57aa323f7bf1a71c3ff:

  drm/amd/display: Fix rehook MST display not light back on (2017-12-15 
17:32:42 -0500)


Bhawanpreet Lakha (1):
  drm/amd/display: add pipe locking before front end programing

Dmytro Laktyushkin (1):
  drm/amd/display: set chroma taps to 1 when not scaling

Eric Yang (1):
  drm/amd/display: fix missing pixel clock adjustment for dongle

Jerry (Fangzhi) Zuo (1):
  drm/amd/display: Fix rehook MST display not light back on

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 13 +++---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  2 +
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 51 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h|  1 +
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  9 
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  4 +-
 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 26 ---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c   |  9 ++--
 8 files changed, 99 insertions(+), 16 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=197925

--- Comment #8 from kwka...@gmx.com ---
As of 4.15.0-rc3-00086-g032b4cc8ff84:

#3 is fixed when in single internal monitor configuration. (Yes!)

I will, again, recheck #2 and #3 when I have an external monitor attached.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3] drm/sun4i: validate modes for HDMI

[Maxime Ripard]

Hi,

On Fri, Dec 15, 2017 at 04:21:50PM +0100, Hans Verkuil wrote:
> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no 
> picture. Some
> digging found that there is no check against the upper pixelclock limit of 
> the HDMI
> output, so X selects a 4kp60 format at 594 MHz, which obviously won't work.
> 
> The patch below adds a check for the upper bound of what this hardware can 
> do, and
> it checks if the requested tmds clock can be obtained.
> 
> It also allows for the +/- 0.5% pixel clock variation that the HDMI spec 
> permits.
> 
> That code is based on commit 22d0be2a557e53a22feb484e8fce255fe09e6ad5 from
> Jose Abreu for drm/arc.
> 
> Signed-off-by: Hans Verkuil 
> Thanks-to: Jose Abreu 

I've fixed the checkpatch warnings, and the compilation warning about
the type mismatch (between long and unsigned long), and
applied. Thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] x86/gpu: add CFL to early quirks

[Rodrigo Vivi]

On Fri, Dec 15, 2017 at 04:39:25PM +, Ingo Molnar wrote:
> 
> * Lucas De Marchi  wrote:
> 
> > CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
> > allow the memory region to be stolen, otherwise we could have RAM being
> > arbitrarily overwritten if for example we keep using the UEFI framebuffer,
> > depending on how BIOS has set up the e820 map.
> > 
> > Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
> > Signed-off-by: Lucas De Marchi 
> > Cc: Rodrigo Vivi 
> > Cc: Anusha Srivatsa 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: David Airlie 
> > Cc: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Ingo Molnar 
> > Cc: H. Peter Anvin 
> > Cc: Thomas Gleixner 
> > Cc: x...@kernel.org
> > Cc:  # v4.13+ 0890540e21cf drm/i915: add GT number 
> > to intel_device_info
> > Cc:  # v4.13+ 41693fd52373 drm/i915/kbl: Change a 
> > KBL pci id to GT2 from GT1.5
> > Cc:  # v4.13+
> > Reviewed-by: Rodrigo Vivi 
> > ---
> > 
> > v2: improve commit message, add Fixes tag and CC stable
> > 
> >  arch/x86/kernel/early-quirks.c | 1 +
> >  include/drm/i915_pciids.h  | 6 ++
> >  2 files changed, 7 insertions(+)
> 
> Acked-by: Ingo Molnar 

Merged to drm-intel-next-queued.
Thanks for the patches, suggestions and acks.

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

[PATCH 3/3] drm/amdgpu: Move to gtt before cpu accesses dma buf.

[Samuel Li]

To improve cpu read performance. This is implemented for APUs currently.

v2: Adapt to change 
https://lists.freedesktop.org/archives/amd-gfx/2017-October/015174.html
v3: Adapt to change "forward begin_cpu_access callback to drivers"

Change-Id: I7a583e23a9ee706e0edd2a46f4e4186a609368e3
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 26 ++
 3 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f8657c3..4204d87 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -420,6 +420,7 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
 int amdgpu_gem_prime_pin(struct drm_gem_object *obj);
 void amdgpu_gem_prime_unpin(struct drm_gem_object *obj);
 struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object *);
+int amdgpu_gem_prime_begin_cpu_access(struct drm_gem_object *obj, enum 
dma_data_direction direction);
 void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj);
 void amdgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int amdgpu_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct 
*vma);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 31383e0..87d05b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -874,6 +874,7 @@ static struct drm_driver kms_driver = {
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
.gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
+   .gem_prime_begin_cpu_access = amdgpu_gem_prime_begin_cpu_access,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index ae9c106..1f5063e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "amdgpu.h"
+#include "amdgpu_display.h"
 #include 
 #include 
 
@@ -164,6 +165,30 @@ struct reservation_object *amdgpu_gem_prime_res_obj(struct 
drm_gem_object *obj)
return bo->tbo.resv;
 }
 
+int amdgpu_gem_prime_begin_cpu_access(struct drm_gem_object *obj, enum 
dma_data_direction direction)
+{
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   struct ttm_operation_ctx ctx = { true, false };
+   u32 domain = amdgpu_framebuffer_domains(adev);
+   long ret = 0;
+   bool reads = (direction == DMA_BIDIRECTIONAL || direction == 
DMA_FROM_DEVICE);
+
+   if (!reads || !(domain & AMDGPU_GEM_DOMAIN_GTT) || bo->pin_count)
+   return 0;
+
+   /* move to gtt */
+   ret = amdgpu_bo_reserve(bo, false);
+   if (unlikely(ret != 0))
+   return ret;
+
+   amdgpu_ttm_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+   ret = ttm_bo_validate(>tbo, >placement, );
+
+   amdgpu_bo_unreserve(bo);
+   return ret;
+}
+
 struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gobj,
int flags)
@@ -178,5 +203,6 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
buf = drm_gem_prime_export(dev, gobj, flags);
if (!IS_ERR(buf))
buf->file->f_mapping = dev->anon_inode->i_mapping;
+
return buf;
 }
-- 
2.7.4

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

Re: [PATCH libdrm] tests/amdgpu: Restore return CUE_SUCCESS to suite_vcn_tests_clean.

[Emil Velikov]

On 15 December 2017 at 18:27, Andrey Grodzovsky
 wrote:
> fixes: 806d080360faecb4025d8e9c7490cb097c25 (amdgpu: Use new 
> suite/test disabling functionality.)
> bug: https://bugs.freedesktop.org/show_bug.cgi?id=104280
Nit: remove the leading space.

>
> Signed-off-by: Andrey Grodzovsky 
Thanks for the quick fixup.
Reviewed-by: Emil Velikov 

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

Re: [PATCH 19/27] drm/etnaviv: move ww_acquire_ctx out of submit object

[Philipp Zabel]

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote:
> The acquire_ctx is special in that it needs to be released from the same
> thread as has been used to initialize it. This collides with the intention to
> extend the submit lifetime beyond the gem_submit function with potentially
> other threads doing the final cleanup.
> 
> Move the ww_acquire_ctx to the function local stack as suggested in the
> documentation.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

regards
Philipp

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem.h|  1 -
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 22 +-
>  2 files changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> index 21cb3460046f..6b78d059ed2d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> @@ -102,7 +102,6 @@ struct etnaviv_gem_submit_bo {
>   */
>  struct etnaviv_gem_submit {
>   struct etnaviv_gpu *gpu;
> - struct ww_acquire_ctx ticket;
>   struct dma_fence *out_fence, *in_fence;
>   u32 flags;
>   unsigned int nr_bos;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 9b5541207d33..3090a46979af 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -44,8 +44,6 @@ static struct etnaviv_gem_submit *submit_create(struct 
> drm_device *dev,
>  
>   submit->gpu = gpu;
>  
> - ww_acquire_init(>ticket, _ww_class);
> -
>   return submit;
>  }
>  
> @@ -107,7 +105,8 @@ static void submit_unlock_object(struct 
> etnaviv_gem_submit *submit, int i)
>   }
>  }
>  
> -static int submit_lock_objects(struct etnaviv_gem_submit *submit)
> +static int submit_lock_objects(struct etnaviv_gem_submit *submit,
> + struct ww_acquire_ctx *ticket)
>  {
>   int contended, slow_locked = -1, i, ret = 0;
>  
> @@ -122,7 +121,7 @@ static int submit_lock_objects(struct etnaviv_gem_submit 
> *submit)
>  
>   if (!(submit->bos[i].flags & BO_LOCKED)) {
>   ret = 
> ww_mutex_lock_interruptible(_obj->resv->lock,
> - >ticket);
> +   ticket);
>   if (ret == -EALREADY)
>   DRM_ERROR("BO at index %u already on submit 
> list\n",
> i);
> @@ -132,7 +131,7 @@ static int submit_lock_objects(struct etnaviv_gem_submit 
> *submit)
>   }
>   }
>  
> - ww_acquire_done(>ticket);
> + ww_acquire_done(ticket);
>  
>   return 0;
>  
> @@ -150,7 +149,7 @@ static int submit_lock_objects(struct etnaviv_gem_submit 
> *submit)
>  
>   /* we lost out in a seqno race, lock and retry.. */
>   ret = ww_mutex_lock_slow_interruptible(_obj->resv->lock,
> - >ticket);
> +ticket);
>   if (!ret) {
>   submit->bos[contended].flags |= BO_LOCKED;
>   slow_locked = contended;
> @@ -361,7 +360,6 @@ static void submit_cleanup(struct etnaviv_gem_submit 
> *submit)
>   drm_gem_object_put_unlocked(_obj->base);
>   }
>  
> - ww_acquire_fini(>ticket);
>   if (submit->in_fence)
>   dma_fence_put(submit->in_fence);
>   if (submit->out_fence)
> @@ -381,6 +379,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>   struct etnaviv_cmdbuf *cmdbuf;
>   struct etnaviv_gpu *gpu;
>   struct sync_file *sync_file = NULL;
> + struct ww_acquire_ctx ticket;
>   int out_fence_fd = -1;
>   void *stream;
>   int ret;
> @@ -466,10 +465,12 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> void *data,
>   }
>   }
>  
> + ww_acquire_init(, _ww_class);
> +
>   submit = submit_create(dev, gpu, args->nr_bos);
>   if (!submit) {
>   ret = -ENOMEM;
> - goto err_submit_cmds;
> + goto err_submit_ww_acquire;
>   }
>  
>   submit->flags = args->flags;
> @@ -478,7 +479,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>   if (ret)
>   goto err_submit_objects;
>  
> - ret = submit_lock_objects(submit);
> + ret = submit_lock_objects(submit, );
>   if (ret)
>   goto err_submit_objects;
>  
> @@ -545,6 +546,9 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>  err_submit_objects:
>   submit_cleanup(submit);
>  
> +err_submit_ww_acquire:
> + ww_acquire_fini();
> +
>  err_submit_cmds:
>   if (ret && (out_fence_fd >= 0))
>   put_unused_fd(out_fence_fd);
___
dri-devel 

Re: [PATCH libdrm] etnaviv: fix BO cache to properly work with different flags

[Christian Gmeiner]

2017-12-15 11:30 GMT+01:00 Lucas Stach :
> Currently if the oldest BO in a bucket has different flags than what we
> look for we'll miss the cache.Fix this by iterating over the cached BOs
> until we find the oldest one with matching flags. This improves the hit
> ratio for some of the buckets.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  etnaviv/etnaviv_bo_cache.c | 26 +++---
>  1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/etnaviv/etnaviv_bo_cache.c b/etnaviv/etnaviv_bo_cache.c
> index 8924651f0cd8..6208230dc81a 100644
> --- a/etnaviv/etnaviv_bo_cache.c
> +++ b/etnaviv/etnaviv_bo_cache.c
> @@ -124,20 +124,32 @@ static int is_idle(struct etna_bo *bo)
>
>  static struct etna_bo *find_in_bucket(struct etna_bo_bucket *bucket, 
> uint32_t flags)
>  {
> -   struct etna_bo *bo = NULL;
> +   struct etna_bo *bo = NULL, *tmp;
>
> pthread_mutex_lock(_lock);
> -   while (!LIST_IS_EMPTY(>list)) {
> -   bo = LIST_ENTRY(struct etna_bo, bucket->list.next, list);
>
> -   if (bo->flags == flags && is_idle(bo)) {
> -   list_del(>list);
> -   break;
> +   if (LIST_IS_EMPTY(>list))
> +   goto out_unlock;
> +
> +   LIST_FOR_EACH_ENTRY_SAFE(bo, tmp, >list, list) {
> +   /* skip BOs with different flags */
> +   if (bo->flags != flags)
> +   continue;
> +
> +   /* check if the first BO with matching flags is idle */
> +   if (is_idle(bo)) {
> +   list_delinit(>list);
> +   goto out_unlock;
> }
>
> -   bo = NULL;
> +   /* If the oldest BO is still busy, don't try younger ones */
> break;
> }
> +
> +   /* There was no matching buffer found */
> +   bo = NULL;
> +
> +out_unlock:
> pthread_mutex_unlock(_lock);
>
> return bo;
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

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

[PATCH 2/3] drm/ttm: cleanup some more resv->lock uses

[Christian König]

Use the reservation wrapper for this.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c  | 14 +++---
 drivers/gpu/drm/ttm/ttm_bo_util.c |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 122a964cac40..5cc96b232c17 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -165,7 +165,7 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_mem_type_manager *man;
 
-   lockdep_assert_held(>resv->lock.base);
+   reservation_object_assert_held(bo->resv);
 
if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
 
@@ -216,7 +216,7 @@ EXPORT_SYMBOL(ttm_bo_del_sub_from_lru);
 
 void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
 {
-   lockdep_assert_held(>resv->lock.base);
+   reservation_object_assert_held(bo->resv);
 
ttm_bo_del_from_lru(bo);
ttm_bo_add_to_lru(bo);
@@ -665,7 +665,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
struct ttm_placement placement;
int ret = 0;
 
-   lockdep_assert_held(>resv->lock.base);
+   reservation_object_assert_held(bo->resv);
 
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
@@ -1022,7 +1022,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
*bo,
int ret = 0;
struct ttm_mem_reg mem;
 
-   lockdep_assert_held(>resv->lock.base);
+   reservation_object_assert_held(bo->resv);
 
mem.num_pages = bo->num_pages;
mem.size = mem.num_pages << PAGE_SHIFT;
@@ -1092,7 +1092,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
int ret;
uint32_t new_flags;
 
-   lockdep_assert_held(>resv->lock.base);
+   reservation_object_assert_held(bo->resv);
/*
 * Check whether we need to move buffer.
 */
@@ -1186,7 +1186,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->sg = sg;
if (resv) {
bo->resv = resv;
-   lockdep_assert_held(>resv->lock.base);
+   reservation_object_assert_held(bo->resv);
} else {
bo->resv = >ttm_resv;
}
@@ -1208,7 +1208,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
 * since otherwise lockdep will be angered in radeon.
 */
if (!resv) {
-   locked = ww_mutex_trylock(>resv->lock);
+   locked = reservation_object_trylock(bo->resv);
WARN_ON(!locked);
}
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 9237099a7c49..6e353df4e4bc 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -485,7 +485,7 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
fbo->acc_size = 0;
fbo->resv = >ttm_resv;
reservation_object_init(fbo->resv);
-   ret = ww_mutex_trylock(>resv->lock);
+   ret = reservation_object_trylock(fbo->resv);
WARN_ON(!ret);
 
*new_obj = fbo;
-- 
2.11.0

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

[PATCH 3/3] drm/ttm: cleanup some old defines

[Christian König]

Use pr_debug instead of TTM_DEBUG, fix the lockdep assert and remove the
unused constant.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 5cc96b232c17..60bb5c12b568 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -42,10 +42,6 @@
 #include 
 #include 
 
-#define TTM_ASSERT_LOCKED(param)
-#define TTM_DEBUG(fmt, arg...)
-#define TTM_BO_HASH_ORDER 13
-
 static int ttm_bo_swapout(struct ttm_mem_shrink *shrink);
 static void ttm_bo_global_kobj_release(struct kobject *kobj);
 
@@ -233,7 +229,7 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
int ret = 0;
uint32_t page_flags = 0;
 
-   TTM_ASSERT_LOCKED(>mutex);
+   reservation_object_assert_held(bo->resv);
bo->ttm = NULL;
 
if (bdev->need_dma32)
@@ -1544,12 +1540,12 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev)
cancel_delayed_work_sync(>wq);
 
if (ttm_bo_delayed_delete(bdev, true))
-   TTM_DEBUG("Delayed destroy list was clean\n");
+   pr_debug("Delayed destroy list was clean\n");
 
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
if (list_empty(>man[0].lru[0]))
-   TTM_DEBUG("Swap list %d was clean\n", i);
+   pr_debug("Swap list %d was clean\n", i);
spin_unlock(>lru_lock);
 
drm_vma_offset_manager_destroy(>vma_manager);
-- 
2.11.0

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

[PATCH 1/3] drm/ttm: use try_lock in ttm_bo_delayed_delete again

[Christian König]

We only need to wait for the contended lock when the reservation object is
shared or when we want to remove everything. A trylock should be sufficient
in all other cases.

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

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index ba5b48617bba..122a964cac40 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -586,12 +586,17 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
  ddestroy);
kref_get(>list_kref);
list_move_tail(>ddestroy, );
-   spin_unlock(>lru_lock);
 
-   reservation_object_lock(bo->resv, NULL);
+   if (remove_all || bo->resv != >ttm_resv) {
+   spin_unlock(>lru_lock);
+   reservation_object_lock(bo->resv, NULL);
 
-   spin_lock(>lru_lock);
-   ttm_bo_cleanup_refs(bo, false, !remove_all, true);
+   spin_lock(>lru_lock);
+   ttm_bo_cleanup_refs(bo, false, !remove_all, true);
+
+   } else if (reservation_object_trylock(bo->resv)) {
+   ttm_bo_cleanup_refs(bo, false, !remove_all, true);
+   }
 
kref_put(>list_kref, ttm_bo_release_list);
spin_lock(>lru_lock);
-- 
2.11.0

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

Re: [PATCH libdrm] tests/amdgpu: Restore return CUE_SUCCESS to suite_vcn_tests_clean.

[Christian König]

Am 15.12.2017 um 19:27 schrieb Andrey Grodzovsky:

 fixes: 806d080360faecb4025d8e9c7490cb097c25 (amdgpu: Use new 
suite/test disabling functionality.)
 bug: https://bugs.freedesktop.org/show_bug.cgi?id=104280

Signed-off-by: Andrey Grodzovsky 


Reviewed-by: Christian König 


---
  tests/amdgpu/vcn_tests.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/tests/amdgpu/vcn_tests.c b/tests/amdgpu/vcn_tests.c
index 53a2d08..9224bc3 100644
--- a/tests/amdgpu/vcn_tests.c
+++ b/tests/amdgpu/vcn_tests.c
@@ -144,6 +144,8 @@ int suite_vcn_tests_clean(void)
r = amdgpu_device_deinitialize(device_handle);
if (r)
return CUE_SCLEAN_FAILED;
+
+   return CUE_SUCCESS;
  }
  
  static int submit(unsigned ndw, unsigned ip)


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

[PATCH libdrm] tests/amdgpu: Restore return CUE_SUCCESS to suite_vcn_tests_clean.

[Andrey Grodzovsky]

fixes: 806d080360faecb4025d8e9c7490cb097c25 (amdgpu: Use new suite/test 
disabling functionality.)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=104280

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/vcn_tests.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/amdgpu/vcn_tests.c b/tests/amdgpu/vcn_tests.c
index 53a2d08..9224bc3 100644
--- a/tests/amdgpu/vcn_tests.c
+++ b/tests/amdgpu/vcn_tests.c
@@ -144,6 +144,8 @@ int suite_vcn_tests_clean(void)
r = amdgpu_device_deinitialize(device_handle);
if (r)
return CUE_SCLEAN_FAILED;
+
+   return CUE_SUCCESS;
 }
 
 static int submit(unsigned ndw, unsigned ip)
-- 
2.7.4

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

[Bug 104280] libdrm fails to build in open build service due to no-return function

[bugzilla-daemon]

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

Andrey Grodzovsky  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |andrey.grodzov...@amd.com
   |.org|

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 2/4] amdgpu: Use new suite/test disabling functionality.

[Emil Velikov]

On 10 November 2017 at 04:30, Andrey Grodzovsky
 wrote:
> Switch from disabling tests during run to using the new disable
> API.
>
> Signed-off-by: Andrey Grodzovsky 
> ---
>  tests/amdgpu/amdgpu_test.c| 14 ++--
>  tests/amdgpu/amdgpu_test.h| 15 
>  tests/amdgpu/deadlock_tests.c |  8 +
>  tests/amdgpu/uvd_enc_tests.c  | 81 
> +--
>  tests/amdgpu/vce_tests.c  | 65 +-
>  tests/amdgpu/vcn_tests.c  | 74 +--
>  6 files changed, 123 insertions(+), 134 deletions(-)
>
> diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
> index 68ec5d3..91010dc 100644
> --- a/tests/amdgpu/amdgpu_test.c
> +++ b/tests/amdgpu/amdgpu_test.c
> @@ -150,15 +150,15 @@ static Suites_Active_Status suites_active_stat[] = {
> },
> {
> .pName = VCE_TESTS_STR,
> -   .pActive = always_active,
> +   .pActive = suite_vce_tests_enable,
> },
> {
> .pName = VCN_TESTS_STR,
> -   .pActive = always_active,
> +   .pActive = suite_vcn_tests_enable,
> },
> {
> .pName = UVD_ENC_TESTS_STR,
> -   .pActive = always_active,
> +   .pActive = suite_uvd_enc_tests_enable,
> },
> {
> .pName = DEADLOCK_TESTS_STR,
> @@ -409,6 +409,14 @@ static void amdgpu_disable_suits()
> if (amdgpu_set_suite_active(suites_active_stat[i].pName,
> suites_active_stat[i].pActive()))
> fprintf(stderr, "suit deactivation failed - %s\n", 
> CU_get_error_msg());
> +
> +   /* Explicitly disable specific tests due to known bugs or preferences 
> */
> +   /*
> +   * BUG: Compute ring stalls and never recovers when the address is
> +   * written after the command already submitted
> +   */
> +   if (amdgpu_set_test_active(DEADLOCK_TESTS_STR, "compute ring block 
> test", CU_FALSE))
> +   fprintf(stderr, "test deactivation failed - %s\n", 
> CU_get_error_msg());
>  }
>
>  /* The main() function for setting up and running the tests.
> diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
> index 9ccc1ff..dd236ed 100644
> --- a/tests/amdgpu/amdgpu_test.h
> +++ b/tests/amdgpu/amdgpu_test.h
> @@ -100,6 +100,11 @@ int suite_vce_tests_init();
>  int suite_vce_tests_clean();
>
>  /**
> + * Decide if the suite is enabled by default or not.
> + */
> +CU_BOOL suite_vce_tests_enable(void);
> +
> +/**
>   * Tests in vce test suite
>   */
>  extern CU_TestInfo vce_tests[];
> @@ -115,6 +120,11 @@ int suite_vcn_tests_init();
>  int suite_vcn_tests_clean();
>
>  /**
> + * Decide if the suite is enabled by default or not.
> + */
> +CU_BOOL suite_vcn_tests_enable(void);
> +
> +/**
>  + * Tests in vcn test suite
>  + */
>  extern CU_TestInfo vcn_tests[];
> @@ -130,6 +140,11 @@ int suite_uvd_enc_tests_init();
>  int suite_uvd_enc_tests_clean();
>
>  /**
> + * Decide if the suite is enabled by default or not.
> + */
> +CU_BOOL suite_uvd_enc_tests_enable(void);
> +
> +/**
>   * Tests in uvd enc test suite
>   */
>  extern CU_TestInfo uvd_enc_tests[];
> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
> index e23d903..f5c4552 100644
> --- a/tests/amdgpu/deadlock_tests.c
> +++ b/tests/amdgpu/deadlock_tests.c
> @@ -119,13 +119,7 @@ int suite_deadlock_tests_clean(void)
>
>  CU_TestInfo deadlock_tests[] = {
> { "gfx ring block test",  amdgpu_deadlock_gfx },
> -
> -   /*
> -   * BUG: Compute ring stalls and never recovers when the address is
> -   * written after the command already submitted
> -   */
> -   /* { "compute ring block test",  amdgpu_deadlock_compute }, */
> -
> +   { "compute ring block test",  amdgpu_deadlock_compute },
> CU_TEST_INFO_NULL,
>  };
>
> diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
> index bbda131..bed8494 100644
> --- a/tests/amdgpu/uvd_enc_tests.c
> +++ b/tests/amdgpu/uvd_enc_tests.c
> @@ -79,7 +79,6 @@ static void amdgpu_cs_uvd_enc_session_init(void);
>  static void amdgpu_cs_uvd_enc_encode(void);
>  static void amdgpu_cs_uvd_enc_destroy(void);
>
> -static bool uvd_enc_support(void);
>
>  CU_TestInfo uvd_enc_tests[] = {
> { "UVD ENC create",  amdgpu_cs_uvd_enc_create },
> @@ -89,6 +88,27 @@ CU_TestInfo uvd_enc_tests[] = {
> CU_TEST_INFO_NULL,
>  };
>
> +CU_BOOL suite_uvd_enc_tests_enable(void)
> +{
> +   int r;
> +   struct drm_amdgpu_info_hw_ip info;
> +
> +   if (amdgpu_device_initialize(drm_amdgpu[0], _version,
> +_version, _handle))
> +   return 

[PATCH v2 5/7] drm/fb-helper: Add drm_fb_helper_defio_init()

[Noralf Trønnes]

Add helper for initializing fbdev deferred I/O.

The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo which lives in Greg's staging tree.
So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
but not that bad either.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 54 -
 include/drm/drm_fb_helper.h |  6 +
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e3eb3c9a98e3..4a61e1aef41b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -107,7 +107,8 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  * always run in process context since the fb_*() function could be running in
  * atomic context. If drm_fb_helper_deferred_io() is used as the deferred_io
  * callback it will also schedule dirty_work with the damage collected from the
- * mmap page writes.
+ * mmap page writes. Drivers can use drm_fb_helper_defio_init() to setup
+ * deferred I/O (coupled with drm_fb_helper_fbdev_teardown()).
  */
 
 #define drm_fb_helper_for_each_connector(fbh, i__) \
@@ -1028,6 +1029,49 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
 }
 EXPORT_SYMBOL(drm_fb_helper_deferred_io);
 
+/**
+ * drm_fb_helper_defio_init - fbdev deferred I/O initialization
+ * @fb_helper: driver-allocated fbdev helper
+ *
+ * This function allocates _deferred_io, sets callback to
+ * drm_fb_helper_deferred_io(), delay to 50ms and calls fb_deferred_io_init().
+ * It should be called from the _fb_helper_funcs->fb_probe callback.
+ * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
+ *
+ * NOTE: A copy of _ops is made and assigned to >fbops. This is done
+ * because fb_deferred_io_cleanup() clears >fb_mmap and would thereby
+ * affect other instances of that _ops.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper)
+{
+   struct fb_info *info = fb_helper->fbdev;
+   struct fb_deferred_io *fbdefio;
+   struct fb_ops *fbops;
+
+   fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
+   fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
+   if (!fbdefio || !fbops) {
+   kfree(fbdefio);
+   kfree(fbops);
+   return -ENOMEM;
+   }
+
+   info->fbdefio = fbdefio;
+   fbdefio->delay = msecs_to_jiffies(50);
+   fbdefio->deferred_io = drm_fb_helper_deferred_io;
+
+   *fbops = *info->fbops;
+   info->fbops = fbops;
+
+   fb_deferred_io_init(info);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_defio_init);
+
 /**
  * drm_fb_helper_sys_read - wrapper around fb_sys_read
  * @info: fb_info struct pointer
@@ -2824,6 +2868,7 @@ EXPORT_SYMBOL(drm_fb_helper_fbdev_setup);
 void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
 {
struct drm_fb_helper *fb_helper = dev->fb_helper;
+   struct fb_ops *fbops = NULL;
 
if (!fb_helper)
return;
@@ -2832,7 +2877,14 @@ void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
if (fb_helper->fbdev && fb_helper->fbdev->dev)
drm_fb_helper_unregister_fbi(fb_helper);
 
+   if (fb_helper->fbdev && fb_helper->fbdev->fbdefio) {
+   fb_deferred_io_cleanup(fb_helper->fbdev);
+   kfree(fb_helper->fbdev->fbdefio);
+   fbops = fb_helper->fbdev->fbops;
+   }
+
drm_fb_helper_fini(fb_helper);
+   kfree(fbops);
 
if (fb_helper->fb)
drm_framebuffer_remove(fb_helper->fb);
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index aa78ac3b8ad0..b069433e7fc1 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -276,6 +276,7 @@ void drm_fb_helper_unlink_fbi(struct drm_fb_helper 
*fb_helper);
 
 void drm_fb_helper_deferred_io(struct fb_info *info,
   struct list_head *pagelist);
+int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper);
 
 ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
   size_t count, loff_t *ppos);
@@ -423,6 +424,11 @@ static inline void drm_fb_helper_deferred_io(struct 
fb_info *info,
 {
 }
 
+static inline int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper)
+{
+   return -ENODEV;
+}
+
 static inline ssize_t drm_fb_helper_sys_read(struct fb_info *info,
 char __user *buf, size_t count,
 loff_t *ppos)
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v2 1/7] drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini

[Noralf Trønnes]

Set dev->fb_helper even when fbdev emulation is compiled out,
so drivers can use it to free the structure.
Clear it for consistency.

Fixes: 29ad20b22c8f ("drm: Add drm_device->fb_helper pointer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 include/drm/drm_fb_helper.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 1494b12a984a..1bd624579db7 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -33,6 +33,7 @@
 struct drm_fb_helper;
 
 #include 
+#include 
 #include 
 
 enum mode_set_atomic {
@@ -332,11 +333,17 @@ static inline int drm_fb_helper_init(struct drm_device 
*dev,
   struct drm_fb_helper *helper,
   int max_conn)
 {
+   /* So drivers can use it to free the struct */
+   helper->dev = dev;
+   dev->fb_helper = helper;
+
return 0;
 }
 
 static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
 {
+   if (helper && helper->dev)
+   helper->dev->fb_helper = NULL;
 }
 
 static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
-- 
2.14.2

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

[PATCH v2 4/7] drm/fb-helper: Update DOC with new helpers

[Noralf Trønnes]

Promote new helpers for dealing with fbdev emulation.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 823fc8f50d85..e3eb3c9a98e3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -66,19 +66,23 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  * helper functions used by many drivers to implement the kernel mode setting
  * interfaces.
  *
- * Initialization is done as a four-step process with drm_fb_helper_prepare(),
- * drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and
- * drm_fb_helper_initial_config(). Drivers with fancier requirements than the
- * default behaviour can override the third step with their own code.
- * Teardown is done with drm_fb_helper_fini() after the fbdev device is
- * unregisters using drm_fb_helper_unregister_fbi().
+ * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
+ * down by calling drm_fb_helper_fbdev_teardown().
  *
- * At runtime drivers should restore the fbdev console by calling
- * drm_fb_helper_restore_fbdev_mode_unlocked() from their _driver.lastclose
- * callback.  They should also notify the fb helper code from updates to the
- * output configuration by calling drm_fb_helper_hotplug_event(). For easier
- * integration with the output polling code in drm_crtc_helper.c the modeset
- * code provides a _mode_config_funcs.output_poll_changed callback.
+ * Drivers that need to handle connector hotplugging (e.g. dp mst) can't use
+ * the setup helper and will need to do the whole four-step setup process with
+ * drm_fb_helper_prepare(), drm_fb_helper_init(),
+ * drm_fb_helper_single_add_all_connectors(), enable hotplugging and
+ * drm_fb_helper_initial_config() to avoid a possible race window.
+ *
+ * At runtime drivers should restore the fbdev console by using
+ * drm_fb_helper_lastclose() as their _driver.lastclose callback.
+ * They should also notify the fb helper code from updates to the output
+ * configuration by using drm_fb_helper_output_poll_changed() as their
+ * _mode_config_funcs.output_poll_changed callback.
+ *
+ * For suspend/resume consider using drm_mode_config_helper_suspend() and
+ * drm_mode_config_helper_resume() which takes care of fbdev as well.
  *
  * All other functions exported by the fb helper library can be used to
  * implement the fbdev driver interface by the driver.
-- 
2.14.2

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

[PATCH v2 6/7] drm/fb-cma-helper: Use drm_fb_helper_fbdev_setup/teardown()

[Noralf Trønnes]

Use the new setup/teardown helpers as well as drm_fb_helper_defio_init().
Wrap fb_deferred_io_mmap() in ifdef so we can make fbdev optional.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---

I had to touch drm_fbdev_cma_fini() here, but that will be rebased away
when this patch is unblocked and applied:
[PATCH v3 11/11] drm/cma-helper: Remove drm_fbdev_cma* functions

 drivers/gpu/drm/drm_fb_cma_helper.c | 111 +---
 1 file changed, 15 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..9f8210130dc6 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -26,8 +26,6 @@
 #include 
 #include 
 
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
 struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
const struct drm_framebuffer_funcs *fb_funcs;
@@ -149,58 +147,14 @@ static struct fb_ops drm_fbdev_cma_ops = {
 static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
  struct vm_area_struct *vma)
 {
+#ifdef CONFIG_FB_DEFERRED_IO
fb_deferred_io_mmap(info, vma);
+#endif
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
 
return 0;
 }
 
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
-   struct drm_gem_cma_object *cma_obj)
-{
-   struct fb_deferred_io *fbdefio;
-   struct fb_ops *fbops;
-
-   /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
-   fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
-   fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
-   if (!fbdefio || !fbops) {
-   kfree(fbdefio);
-   kfree(fbops);
-   return -ENOMEM;
-   }
-
-   /* can't be offset from vaddr since dirty() uses cma_obj */
-   fbi->screen_buffer = cma_obj->vaddr;
-   /* fb_deferred_io_fault() needs a physical address */
-   fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
-   *fbops = *fbi->fbops;
-   fbi->fbops = fbops;
-
-   fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
-   fbdefio->deferred_io = drm_fb_helper_deferred_io;
-   fbi->fbdefio = fbdefio;
-   fb_deferred_io_init(fbi);
-   fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
-
-   return 0;
-}
-
-static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
-{
-   if (!fbi->fbdefio)
-   return;
-
-   fb_deferred_io_cleanup(fbi);
-   kfree(fbi->fbdefio);
-   kfree(fbi->fbops);
-}
-
 static int
 drm_fbdev_cma_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
@@ -258,9 +212,15 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
fbi->fix.smem_len = size;
 
if (fb->funcs->dirty) {
-   ret = drm_fbdev_cma_defio_init(fbi, obj);
+   ret = drm_fb_helper_defio_init(helper);
if (ret)
goto err_cma_destroy;
+
+   /* can't be offset from vaddr since dirty() uses cma obj */
+   fbi->screen_buffer = obj->vaddr;
+   /* fb_deferred_io_fault() needs a physical address */
+   fbi->fix.smem_start = page_to_phys(virt_to_page(obj->vaddr));
+   fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
}
 
return 0;
@@ -296,52 +256,23 @@ int drm_fb_cma_fbdev_init_with_funcs(struct drm_device 
*dev,
const struct drm_framebuffer_funcs *funcs)
 {
struct drm_fbdev_cma *fbdev_cma;
-   struct drm_fb_helper *fb_helper;
int ret;
 
-   if (!preferred_bpp)
-   preferred_bpp = dev->mode_config.preferred_depth;
-   if (!preferred_bpp)
-   preferred_bpp = 32;
-
-   if (!max_conn_count)
-   max_conn_count = dev->mode_config.num_connector;
-
fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
if (!fbdev_cma)
return -ENOMEM;
 
fbdev_cma->fb_funcs = funcs;
-   fb_helper = _cma->fb_helper;
 
-   drm_fb_helper_prepare(dev, fb_helper, _fb_cma_helper_funcs);
-
-   ret = drm_fb_helper_init(dev, fb_helper, max_conn_count);
+   ret = drm_fb_helper_fbdev_setup(dev, _cma->fb_helper,
+   _fb_cma_helper_funcs,
+   preferred_bpp, max_conn_count);
if (ret < 0) {
-   DRM_DEV_ERROR(dev->dev, "Failed to initialize fbdev helper.\n");
-   goto err_free;
-   }
-
-   ret = drm_fb_helper_single_add_all_connectors(fb_helper);
-   if (ret < 0) {
-   DRM_DEV_ERROR(dev->dev, "Failed to add connectors.\n");
- 

[PATCH v2 0/7] Add drm_fb_helper_fbdev_setup/teardown()

[Noralf Trønnes]

Hi,

This is a new attempt at simplifying fbdev setup/teardown in drivers.

Only doc changes in this version based on feedback from Daniel.

Noralf.

Changes since version 1:
- Document a case where drm_fb_helper_fbdev_setup() can't be used:
  connector hotplugging (e.g. dp mst).
- Document where drm_fb_helper_defio_init() should be called from.
- Move drm_fb_helper_defio_init() recommendation to DOC framebuffer
  flushing section.

Noralf Trønnes (7):
  drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini
  drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()
  drm/docs: Add todo entry for drm_fb_helper_fbdev_setup()
  drm/fb-helper: Update DOC with new helpers
  drm/fb-helper: Add drm_fb_helper_defio_init()
  drm/fb-cma-helper: Use drm_fb_helper_fbdev_setup/teardown()
  drm/fb-cma-helper: Honour DRM_FBDEV_EMULATION

 Documentation/gpu/todo.rst  |  18 
 drivers/gpu/drm/Kconfig |   5 +-
 drivers/gpu/drm/drm_fb_cma_helper.c | 111 +++--
 drivers/gpu/drm/drm_fb_helper.c | 188 +---
 include/drm/drm_fb_helper.h |  38 
 5 files changed, 247 insertions(+), 113 deletions(-)

-- 
2.14.2

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

[PATCH v2 7/7] drm/fb-cma-helper: Honour DRM_FBDEV_EMULATION

[Noralf Trønnes]

Make it possible to opt out of fbdev emulation.
DRM_FBDEV_EMULATION selects DRM_KMS_FB_HELPER and is default yes so
this doesn't change the default behaviour.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/Kconfig | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d853989848d6..fe1b6030d3c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -143,10 +143,7 @@ config DRM_KMS_CMA_HELPER
bool
depends on DRM
select DRM_GEM_CMA_HELPER
-   select DRM_KMS_FB_HELPER
-   select FB_SYS_FILLRECT
-   select FB_SYS_COPYAREA
-   select FB_SYS_IMAGEBLIT
+   select DRM_KMS_HELPER
help
  Choose this if you need the KMS CMA helper functions
 
-- 
2.14.2

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

[PATCH v2 2/7] drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()

[Noralf Trønnes]

Add helpers to setup and teardown fbdev emulation.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 106 
 include/drm/drm_fb_helper.h |  25 ++
 2 files changed, 131 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 04a3a5ce370a..823fc8f50d85 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2729,6 +2729,112 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
 
+/**
+ * drm_fb_helper_fbdev_setup() - Setup fbdev emulation
+ * @dev: DRM device
+ * @fb_helper: fbdev helper structure to set up
+ * @funcs: fbdev helper functions
+ * @preferred_bpp: Preferred bits per pixel for the device.
+ * @dev->mode_config.preferred_depth is used if this is zero.
+ * @max_conn_count: Maximum number of connectors.
+ *  @dev->mode_config.num_connector is used if this is zero.
+ *
+ * This function sets up fbdev emulation and registers fbdev for access by
+ * userspace. If all connectors are disconnected, setup is deferred to the next
+ * time drm_fb_helper_hotplug_event() is called.
+ * The caller must to provide a _fb_helper_funcs->fb_probe callback
+ * function.
+ *
+ * See also: drm_fb_helper_initial_config()
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fb_helper_fbdev_setup(struct drm_device *dev,
+ struct drm_fb_helper *fb_helper,
+ const struct drm_fb_helper_funcs *funcs,
+ unsigned int preferred_bpp,
+ unsigned int max_conn_count)
+{
+   int ret;
+
+   if (!preferred_bpp)
+   preferred_bpp = dev->mode_config.preferred_depth;
+   if (!preferred_bpp)
+   preferred_bpp = 32;
+
+   if (!max_conn_count)
+   max_conn_count = dev->mode_config.num_connector;
+   if (!max_conn_count) {
+   DRM_DEV_ERROR(dev->dev, "No connectors\n");
+   return -EINVAL;
+   }
+
+   drm_fb_helper_prepare(dev, fb_helper, funcs);
+
+   ret = drm_fb_helper_init(dev, fb_helper, max_conn_count);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to initialize fbdev helper\n");
+   return ret;
+   }
+
+   ret = drm_fb_helper_single_add_all_connectors(fb_helper);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to add connectors\n");
+   goto err_drm_fb_helper_fini;
+   }
+
+   if (!drm_drv_uses_atomic_modeset(dev))
+   drm_helper_disable_unused_functions(dev);
+
+   ret = drm_fb_helper_initial_config(fb_helper, preferred_bpp);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to set fbdev configuration\n");
+   goto err_drm_fb_helper_fini;
+   }
+
+   return 0;
+
+err_drm_fb_helper_fini:
+   drm_fb_helper_fini(fb_helper);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_fbdev_setup);
+
+/**
+ * drm_fb_helper_fbdev_teardown - Tear down fbdev emulation
+ * @dev: DRM device
+ *
+ * This function unregisters fbdev if not already done and cleans up the
+ * associated resources including the _framebuffer.
+ * The driver is responsible for freeing the _fb_helper structure which is
+ * stored in _device->fb_helper. Do note that this pointer has been cleared
+ * when this function returns.
+ *
+ * In order to support device removal/unplug while file handles are still open,
+ * drm_fb_helper_unregister_fbi() should be called on device removal and
+ * drm_fb_helper_fbdev_teardown() in the _driver->release callback when
+ * file handles are closed.
+ */
+void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
+{
+   struct drm_fb_helper *fb_helper = dev->fb_helper;
+
+   if (!fb_helper)
+   return;
+
+   /* Unregister if it hasn't been done already */
+   if (fb_helper->fbdev && fb_helper->fbdev->dev)
+   drm_fb_helper_unregister_fbi(fb_helper);
+
+   drm_fb_helper_fini(fb_helper);
+
+   if (fb_helper->fb)
+   drm_framebuffer_remove(fb_helper->fb);
+}
+EXPORT_SYMBOL(drm_fb_helper_fbdev_teardown);
+
 /**
  * drm_fb_helper_lastclose - DRM driver lastclose helper for fbdev emulation
  * @dev: DRM device
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 1bd624579db7..aa78ac3b8ad0 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -320,6 +320,13 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper, struct drm_
 int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
   struct drm_connector *connector);
 
+int drm_fb_helper_fbdev_setup(struct drm_device *dev,
+  

[PATCH v2 3/7] drm/docs: Add todo entry for drm_fb_helper_fbdev_setup()

[Noralf Trønnes]

Add entry for conversion of drivers to new helpers.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index f421a54527d2..1e593370f64f 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -194,6 +194,24 @@ drm_mode_config_helper_suspend/resume().
 
 Contact: Maintainer of the driver you plan to convert
 
+Convert drivers to use drm_fb_helper_fbdev_setup/teardown()
+---
+
+Most drivers can use drm_fb_helper_fbdev_setup() except maybe:
+
+- amdgpu which has special logic to decide whether to call
+  drm_helper_disable_unused_functions()
+
+- armada which isn't atomic and doesn't call
+  drm_helper_disable_unused_functions()
+
+- i915 which calls drm_fb_helper_initial_config() in a worker
+
+Drivers that use drm_framebuffer_remove() to clean up the fbdev framebuffer can
+probably use drm_fb_helper_fbdev_teardown().
+
+Contact: Maintainer of the driver you plan to convert
+
 Core refactorings
 =
 
-- 
2.14.2

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

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #6 from mikhail.v.gavri...@gmail.com ---
Created attachment 136200
  --> https://bugs.freedesktop.org/attachment.cgi?id=136200=edit
dmesg with 4.15.0-rc2 amd-staging-drm-next

-- 
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: [PATCHv4] drm/sun4i: validate modes for HDMI

[Daniel Vetter]

On Fri, Dec 15, 2017 at 05:46:19PM +0100, Hans Verkuil wrote:
> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no 
> picture. Some
> digging found that there is no check against the upper pixelclock limit of 
> the HDMI
> output, so X selects a 4kp60 format at 594 MHz, which obviously won't work.
> 
> The patch below adds a check for the upper bound of what this hardware can 
> do, and
> it checks if the requested tmds clock can be obtained.
> 
> It also allows for the ± 0.5% pixel clock variation that the HDMI spec 
> permits.
> 
> That code is based on commit 22d0be2a557e53a22feb484e8fce255fe09e6ad5 from
> Jose Abreu for drm/arc.
> 
> Signed-off-by: Hans Verkuil 
> ---
> Changes since v3:
> - Move the mode_valid callback to struct drm_encoder_helper_funcs.
>   I'm assuming this is the correct struct, since this check is specific to the
>   hdmi encoder.

Reviewed-by: Daniel Vetter 

I think sun4i is in drm-misc, so feel free to push.

Cheers, Daniel


> Changes since v2:
> - Allow for the 0.5% variation.
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index dda904ec0534..500b6fb3e028 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -175,11 +175,31 @@ static void sun4i_hdmi_mode_set(struct drm_encoder 
> *encoder,
>   writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
>  }
> 
> +static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder 
> *encoder,
> + const struct drm_display_mode *mode)
> +{
> + struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
> + unsigned long rate = mode->clock * 1000;
> + unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
> + long rounded_rate;
> +
> + /* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
> + if (rate > 16500)
> + return MODE_CLOCK_HIGH;
> + rounded_rate = clk_round_rate(hdmi->tmds_clk, rate);
> + if (rounded_rate > 0 &&
> + max_t(unsigned long, rounded_rate, rate) -
> + min_t(unsigned long, rounded_rate, rate) < diff)
> + return MODE_OK;
> + return MODE_NOCLOCK;
> +}
> +
>  static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
>   .atomic_check   = sun4i_hdmi_atomic_check,
>   .disable= sun4i_hdmi_disable,
>   .enable = sun4i_hdmi_enable,
>   .mode_set   = sun4i_hdmi_mode_set,
> + .mode_valid = sun4i_hdmi_mode_valid,
>  };
> 
>  static const struct drm_encoder_funcs sun4i_hdmi_funcs = {
> -- 
> 2.15.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/amdgpu: allow framebuffer in GART memory as well

[Samuel Li]

From: Christian König 

On CZ and newer APUs we can pin the fb into GART as well as VRAM.

v2: Don't enable gpu_vm_support for Raven yet since it leads to
a black screen. Need to debug this further before enabling.

Change-Id: Id0f8af3110e54a3aabf7a258871867bc121cc1a2
Signed-off-by: Christian König 
Reviewed-by: Andrey Grodzovsky 
Acked-by: Alex Deucher 
Signed-off-by: Samuel Li 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 ++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +--
 4 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index d704a45..d9fdc19 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -29,6 +29,7 @@
 #include "amdgpu_i2c.h"
 #include "atom.h"
 #include "amdgpu_connectors.h"
+#include "amdgpu_display.h"
 #include 
 
 #include 
@@ -188,7 +189,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
goto cleanup;
}
 
-   r = amdgpu_bo_pin(new_abo, AMDGPU_GEM_DOMAIN_VRAM, );
+   r = amdgpu_bo_pin(new_abo, amdgpu_framebuffer_domains(adev), );
if (unlikely(r != 0)) {
DRM_ERROR("failed to pin new abo buffer before flip\n");
goto unreserve;
@@ -501,6 +502,17 @@ static const struct drm_framebuffer_funcs amdgpu_fb_funcs 
= {
.create_handle = amdgpu_user_framebuffer_create_handle,
 };
 
+uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev)
+{
+   uint32_t domain = AMDGPU_GEM_DOMAIN_VRAM;
+
+   if (adev->asic_type >= CHIP_CARRIZO && adev->asic_type < CHIP_RAVEN &&
+   adev->flags & AMD_IS_APU)
+   domain |= AMDGPU_GEM_DOMAIN_GTT;
+
+   return domain;
+}
+
 int
 amdgpu_framebuffer_init(struct drm_device *dev,
struct amdgpu_framebuffer *rfb,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
index 11ae4ab..f241949 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
@@ -23,6 +23,7 @@
 #ifndef __AMDGPU_DISPLAY_H__
 #define __AMDGPU_DISPLAY_H__
 
+uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev);
 struct drm_framebuffer *
 amdgpu_user_framebuffer_create(struct drm_device *dev,
   struct drm_file *file_priv,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 90fa8e8..9be3228 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -38,6 +38,8 @@
 
 #include 
 
+#include "amdgpu_display.h"
+
 /* object hierarchy -
this contains a helper + a amdgpu fb
the helper contains a pointer to amdgpu framebuffer baseclass.
@@ -124,7 +126,7 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
struct drm_gem_object *gobj = NULL;
struct amdgpu_bo *abo = NULL;
bool fb_tiled = false; /* useful for testing */
-   u32 tiling_flags = 0;
+   u32 tiling_flags = 0, domain;
int ret;
int aligned_size, size;
int height = mode_cmd->height;
@@ -135,12 +137,12 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
/* need to align pitch with crtc limits */
mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
  fb_tiled);
+   domain = amdgpu_framebuffer_domains(adev);
 
height = ALIGN(mode_cmd->height, 8);
size = mode_cmd->pitches[0] * height;
aligned_size = ALIGN(size, PAGE_SIZE);
-   ret = amdgpu_gem_object_create(adev, aligned_size, 0,
-  AMDGPU_GEM_DOMAIN_VRAM,
+   ret = amdgpu_gem_object_create(adev, aligned_size, 0, domain,
   AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED |
   AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS |
   AMDGPU_GEM_CREATE_VRAM_CLEARED,
@@ -166,7 +168,7 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
}
 
 
-   ret = amdgpu_bo_pin(abo, AMDGPU_GEM_DOMAIN_VRAM, NULL);
+   ret = amdgpu_bo_pin(abo, domain, NULL);
if (ret) {
amdgpu_bo_unreserve(abo);
goto out_unref;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a3bf021..9b05abd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2982,11 +2982,13 @@ static int 

[PATCHv4] drm/sun4i: validate modes for HDMI

[Hans Verkuil]

When I connected my cubieboard running 4.15-rc1 to my 4k display I got no 
picture. Some
digging found that there is no check against the upper pixelclock limit of the 
HDMI
output, so X selects a 4kp60 format at 594 MHz, which obviously won't work.

The patch below adds a check for the upper bound of what this hardware can do, 
and
it checks if the requested tmds clock can be obtained.

It also allows for the ± 0.5% pixel clock variation that the HDMI spec permits.

That code is based on commit 22d0be2a557e53a22feb484e8fce255fe09e6ad5 from
Jose Abreu for drm/arc.

Signed-off-by: Hans Verkuil 
---
Changes since v3:
- Move the mode_valid callback to struct drm_encoder_helper_funcs.
  I'm assuming this is the correct struct, since this check is specific to the
  hdmi encoder.
Changes since v2:
- Allow for the 0.5% variation.
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index dda904ec0534..500b6fb3e028 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -175,11 +175,31 @@ static void sun4i_hdmi_mode_set(struct drm_encoder 
*encoder,
writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
 }

+static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+{
+   struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
+   unsigned long rate = mode->clock * 1000;
+   unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
+   long rounded_rate;
+
+   /* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
+   if (rate > 16500)
+   return MODE_CLOCK_HIGH;
+   rounded_rate = clk_round_rate(hdmi->tmds_clk, rate);
+   if (rounded_rate > 0 &&
+   max_t(unsigned long, rounded_rate, rate) -
+   min_t(unsigned long, rounded_rate, rate) < diff)
+   return MODE_OK;
+   return MODE_NOCLOCK;
+}
+
 static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
.atomic_check   = sun4i_hdmi_atomic_check,
.disable= sun4i_hdmi_disable,
.enable = sun4i_hdmi_enable,
.mode_set   = sun4i_hdmi_mode_set,
+   .mode_valid = sun4i_hdmi_mode_valid,
 };

 static const struct drm_encoder_funcs sun4i_hdmi_funcs = {
-- 
2.15.0

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

[PATCH 1/3] drm/prime: forward begin_cpu_access callback to drivers

[Samuel Li]

From: Christian König 

Allow drivers to implement their own begin_cpu_access callback.

Change-Id: I97709b42b9351a04ee7e01106107a87bc56ea258
Signed-off-by: Christian König 
---
 drivers/gpu/drm/drm_prime.c | 13 +
 include/drm/drm_drv.h   |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 8de93a2..b4b0e64 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -346,6 +346,18 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_release);
 
+static int drm_gem_dmabuf_begin_cpu_access(struct dma_buf *dma_buf,
+   enum dma_data_direction direction)
+{
+   struct drm_gem_object *obj = dma_buf->priv;
+   struct drm_device *dev = obj->dev;
+
+   if (!dev->driver->gem_prime_begin_cpu_access)
+   return 0;
+
+   return dev->driver->gem_prime_begin_cpu_access(obj, direction);
+}
+
 static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
 {
struct drm_gem_object *obj = dma_buf->priv;
@@ -403,6 +415,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
+   .begin_cpu_access = drm_gem_dmabuf_begin_cpu_access,
.map = drm_gem_dmabuf_kmap,
.map_atomic = drm_gem_dmabuf_kmap_atomic,
.unmap = drm_gem_dmabuf_kunmap,
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 412e83a..1fbf298 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -475,6 +475,8 @@ struct drm_driver {
struct drm_device *dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
+   int (*gem_prime_begin_cpu_access)(struct drm_gem_object *obj,
+  enum dma_data_direction direction);
void *(*gem_prime_vmap)(struct drm_gem_object *obj);
void (*gem_prime_vunmap)(struct drm_gem_object *obj, void *vaddr);
int (*gem_prime_mmap)(struct drm_gem_object *obj,
-- 
2.7.4

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

Re: [PATCH] drm/amd/display: remove redundant null check of array 'data'

[Harry Wentland]

On 2017-12-15 05:53 AM, Colin King wrote:
> From: Colin Ian King 
> 
> The null check on aconnector->base.edid_blob_ptr->data is redundant
> since data is an array and can never be null.  Remove it.
> 
> Detected by CoverityScan, CID#1460369 ("Array compared against 0")
> 
> Signed-off-by: Colin Ian King 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ccbf10e3bbb6..c388778dbba3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2725,8 +2725,7 @@ static void create_eml_sink(struct amdgpu_dm_connector 
> *aconnector)
>   };
>   struct edid *edid;
>  
> - if (!aconnector->base.edid_blob_ptr ||
> - !aconnector->base.edid_blob_ptr->data) {
> + if (!aconnector->base.edid_blob_ptr) {
>   DRM_ERROR("No EDID firmware found on connector: %s ,forcing to 
> OFF!\n",
>   aconnector->base.name);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/amdgpu: Move to gtt before cpu accesses dma buf.

[Christian König]

Am 15.12.2017 um 17:33 schrieb Samuel Li:

To improve cpu read performance. This is implemented for APUs currently.

v2: Adapt to change 
https://lists.freedesktop.org/archives/amd-gfx/2017-October/015174.html
v3: Adapt to change "forward begin_cpu_access callback to drivers"

Change-Id: I7a583e23a9ee706e0edd2a46f4e4186a609368e3
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 26 ++
  3 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f8657c3..4204d87 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -420,6 +420,7 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
  int amdgpu_gem_prime_pin(struct drm_gem_object *obj);
  void amdgpu_gem_prime_unpin(struct drm_gem_object *obj);
  struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object *);
+int amdgpu_gem_prime_begin_cpu_access(struct drm_gem_object *obj, enum 
dma_data_direction direction);
  void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj);
  void amdgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
  int amdgpu_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct 
*vma);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 31383e0..87d05b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -874,6 +874,7 @@ static struct drm_driver kms_driver = {
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
.gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
+   .gem_prime_begin_cpu_access = amdgpu_gem_prime_begin_cpu_access,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index ae9c106..1f5063e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -26,6 +26,7 @@
  #include 
  
  #include "amdgpu.h"

+#include "amdgpu_display.h"
  #include 
  #include 
  
@@ -164,6 +165,30 @@ struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object *obj)

return bo->tbo.resv;
  }
  
+int amdgpu_gem_prime_begin_cpu_access(struct drm_gem_object *obj, enum dma_data_direction direction)

+{
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   struct ttm_operation_ctx ctx = { true, false };
+   u32 domain = amdgpu_framebuffer_domains(adev);
+   long ret = 0;
+   bool reads = (direction == DMA_BIDIRECTIONAL || direction == 
DMA_FROM_DEVICE);


Reverse tree order please and ret should be an int in this case.


+
+   if (!reads || !(domain & AMDGPU_GEM_DOMAIN_GTT) || bo->pin_count)
+   return 0;


bo->pin_count is protected by the BO being reserved.


+
+   /* move to gtt */
+   ret = amdgpu_bo_reserve(bo, false);
+   if (unlikely(ret != 0))
+   return ret;
+
+   amdgpu_ttm_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+   ret = ttm_bo_validate(>tbo, >placement, );
+
+   amdgpu_bo_unreserve(bo);
+   return ret;
+}
+
  struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gobj,
int flags)
@@ -178,5 +203,6 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
buf = drm_gem_prime_export(dev, gobj, flags);
if (!IS_ERR(buf))
buf->file->f_mapping = dev->anon_inode->i_mapping;
+


Unrelated whitespace change.

Christian.


return buf;
  }


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

[Bug 104281] black / corrupted screen when resuming from S3 [AMDGPU]

[bugzilla-daemon]

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

--- Comment #1 from Carlo Caione  ---
The issue is not limited to this laptop model. We have at least 3 other ACER
models affected by this.

-- 
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 104281] black / corrupted screen when resuming from S3 [AMDGPU]

[bugzilla-daemon]

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

Bug ID: 104281
   Summary: black / corrupted screen when resuming from S3
[AMDGPU]
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ca...@caione.org

Created attachment 136199
  --> https://bugs.freedesktop.org/attachment.cgi?id=136199=edit
journal_suspend_resume_corrupted_screen

Hardware is AMD Bristol Ridge chipset with AMD A10-9620P RADEON R5 SoC.

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Carrizo (rev ca)
03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 699f
(rev ff)

Kernel is latest Linus master (4.15.0-rc3) compiled with
CONFIG_DRM_AMD_DC_PRE_VEGA=y

When resuming from suspend most of the times the screen is black / corrupted. I
can still SSH into the system.

In attachment the full log, including suspend + resume.

-- 
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: [PATCHv3] drm/sun4i: validate modes for HDMI

[Daniel Vetter]

On Fri, Dec 15, 2017 at 04:21:50PM +0100, Hans Verkuil wrote:
> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no 
> picture. Some
> digging found that there is no check against the upper pixelclock limit of 
> the HDMI
> output, so X selects a 4kp60 format at 594 MHz, which obviously won't work.
> 
> The patch below adds a check for the upper bound of what this hardware can 
> do, and
> it checks if the requested tmds clock can be obtained.
> 
> It also allows for the +/- 0.5% pixel clock variation that the HDMI spec 
> permits.
> 
> That code is based on commit 22d0be2a557e53a22feb484e8fce255fe09e6ad5 from
> Jose Abreu for drm/arc.
> 
> Signed-off-by: Hans Verkuil 
> Thanks-to: Jose Abreu 
> ---
> Changes since v2:
> - Allow for the 0.5% variation.
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index dda904ec0534..a7e9eb93c378 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -208,8 +208,27 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
> *connector)
>   return ret;
>  }
> 
> +static int sun4i_hdmi_mode_valid(struct drm_connector *connector,
> +  struct drm_display_mode *mode)
> +{

This only catches bad modes in the probe code, userspace can still request
bad modes directly through atomic or SETCRTC ioctls.

Please read the kerneldoc for drm_connector_helper_funcs->mode_valid and
put your shiny mode_valid callback into the right vtable.

Cheers, Daniel

> + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
> + unsigned long rate = mode->clock * 1000;
> + long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
> + long rounded_rate;
> +
> + /* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
> + if (rate > 16500)
> + return MODE_CLOCK_HIGH;
> + rounded_rate = clk_round_rate(hdmi->tmds_clk, rate);
> + if (max(rounded_rate, rate) - min(rounded_rate, rate) < diff &&
> + rounded_rate > 0)
> + return MODE_OK;
> + return MODE_NOCLOCK;
> +}
> +
>  static const struct drm_connector_helper_funcs 
> sun4i_hdmi_connector_helper_funcs = {
>   .get_modes  = sun4i_hdmi_get_modes,
> + .mode_valid = sun4i_hdmi_mode_valid,
>  };
> 
>  static enum drm_connector_status
> -- 
> 2.15.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

[bugzilla-daemon]

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

--- Comment #3 from Sverd Johnsen  ---
Thanks for pointing me to that. Seems like it should have gone to stable

Alright. Here is what I do now:

boot with intel gpu, amdgpu is blacklisted in modules so it doesn't get
autoloaded
then i load amdgpu with dc on or off by hand, this time i make sure display
that is attached via DisplayPort to amdgpu is on

i cannot unload until i use

echo 0 > /sys/devices/virtual/vtconsole/vtcon1/bind

here is with dc=1:

rmmod hangs


[   45.665237] LoadPin: kernel-module pinning-ignored
obj="/usr/lib/modules/4.15.0-1-rc/kernel/drivers/gpu/drm/ttm/ttm.ko" pid=1201
cmdline="modprobe amdgpu dc=1"
[   45.682434] LoadPin: kernel-module pinning-ignored
obj="/usr/lib/modules/4.15.0-1-rc/kernel/drivers/gpu/drm/amd/lib/chash.ko"
pid=1201 cmdline="modprobe amdgpu dc=1"
[   45.693068] LoadPin: kernel-module pinning-ignored
obj="/usr/lib/modules/4.15.0-1-rc/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko"
pid=1201 cmdline="modprobe amdgpu dc=1"
[   46.202469] [drm] amdgpu kernel modesetting enabled.
[   46.202519] amdgpu :01:00.0: enabling device (0006 -> 0007)
[   46.202669] [drm] initializing kernel modesetting (POLARIS11 0x1002:0x67EF
0x1462:0x809D 0xCF).
[   46.202681] [drm] register mmio base: 0xEFE0
[   46.202682] [drm] register mmio size: 262144
[   46.202694] [drm] probing gen 2 caps for device 8086:1901 = 261ad03/e
[   46.202694] [drm] probing mlw for device 8086:1901 = 261ad03
[   46.202700] [drm] UVD is enabled in VM mode
[   46.202700] [drm] UVD ENC is enabled in VM mode
[   46.202702] [drm] VCE enabled in VM mode
[   46.202715] ATOM BIOS: 113-C99401-S01
[   46.202721] [drm] GPU post is not needed
[   46.202730] [drm] vm size is 64 GB, block size is 13-bit, fragment size is
9-bit
[   46.203725] LoadPin: firmware pinning-ignored
obj="/usr/lib/firmware/amdgpu/polaris11_mc.bin" pid=1201 cmdline="modprobe
amdgpu dc=1"
[   46.204234] amdgpu :01:00.0: VRAM: 2048M 0x00F4 -
0x00F47FFF (2048M used)
[   46.204235] amdgpu :01:00.0: GTT: 256M 0x -
0x0FFF
[   46.204241] [drm] Detected VRAM RAM=2048M, BAR=256M
[   46.204242] [drm] RAM width 128bits GDDR5
[   46.204321] [TTM] Zone  kernel: Available graphics memory: 8082548 kiB
[   46.204321] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   46.204321] [TTM] Initializing pool allocator
[   46.204323] [TTM] Initializing DMA pool allocator
[   46.204333] [drm] amdgpu: 2048M of VRAM memory ready
[   46.204333] [drm] amdgpu: 3072M of GTT memory ready.
[   46.204366] [drm] GART: num cpu pages 65536, num gpu pages 65536
[   46.204414] [drm] PCIE GART of 256M enabled (table at 0x00F40004).
[   46.204447] amdgpu :01:00.0: amdgpu: using MSI.
[   46.204462] [drm] amdgpu: irq initialized.
[   46.204475] amdgpu: [powerplay] amdgpu: powerplay sw initialized
[   46.204487] LoadPin: firmware pinning-ignored
obj="/usr/lib/firmware/amdgpu/polaris11_pfp_2.bin" pid=1201 cmdline="modprobe
amdgpu dc=1"
[   46.205094] LoadPin: firmware pinning-ignored
obj="/usr/lib/firmware/amdgpu/polaris11_me_2.bin" pid=1201 cmdline="modprobe
amdgpu dc=1"
[   46.217397] LoadPin: firmware pinning-ignored
obj="/usr/lib/firmware/amdgpu/polaris11_ce_2.bin" pid=1201 cmdline="modprobe
amdgpu dc=1"
[   46.217550] [drm] Chained IB support enabled!
[   46.217556] LoadPin: firmware pinning-ignored
obj="/usr/lib/firmware/amdgpu/polaris11_rlc.bin" pid=1201 cmdline="modprobe
amdgpu dc=1"
[   46.217822] LoadPin: firmware pinning-ignored
obj="/usr/lib/firmware/amdgpu/polaris11_mec_2.bin" pid=1201 cmdline="modprobe
amdgpu dc=1"
[   46.218718] LoadPin: firmware pinning-ignored
obj="/usr/lib/firmware/amdgpu/polaris11_mec2_2.bin" pid=1201 cmdline="modprobe
amdgpu dc=1"
[   46.219694] amdgpu :01:00.0: fence driver on ring 0 use gpu addr
0x00400040, cpu addr 0x72e5becd
[   46.219847] amdgpu :01:00.0: fence driver on ring 1 use gpu addr
0x004000c0, cpu addr 0x7d1f8b28
[   46.219906] amdgpu :01:00.0: fence driver on ring 2 use gpu addr
0x00400140, cpu addr 0x1b657fe6
[   46.219946] amdgpu :01:00.0: fence driver on ring 3 use gpu addr
0x004001c0, cpu addr 0x9cd8ddd2
[   46.219993] amdgpu :01:00.0: fence driver on ring 4 use gpu addr
0x00400240, cpu addr 0x4495111b
[   46.220039] amdgpu :01:00.0: fence driver on ring 5 use gpu addr
0x004002c0, cpu addr 0x705ffa8e
[   46.220113] amdgpu :01:00.0: fence driver on ring 6 use gpu addr
0x00400340, cpu addr 0x9005afe9
[   46.220160] amdgpu :01:00.0: fence driver on ring 7 use gpu addr
0x004003c0, cpu addr 0xe3bdcb19
[   46.220203] amdgpu :01:00.0: fence driver on ring 8 use gpu addr
0x00400440, cpu addr 0xd3b3c22e
[   46.220214] amdgpu :01:00.0: fence driver on ring 9 use gpu addr
0x004004e0, cpu addr 

Re: [PATCH 5/7] drm/fb-helper: Add drm_fb_helper_defio_init()

[Noralf Trønnes]

Den 15.12.2017 16.43, skrev Daniel Vetter:

On Fri, Dec 15, 2017 at 02:18:55PM +0100, Noralf Trønnes wrote:

Den 14.12.2017 21.25, skrev Daniel Vetter:

On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:

Add helper for initializing fbdev deferred I/O.

The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo which lives in Greg's staging tree.
So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
but not that bad either.

Signed-off-by: Noralf Trønnes 
---
   drivers/gpu/drm/drm_fb_helper.c | 53 
+
   include/drm/drm_fb_helper.h |  6 +
   2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 14aa83579e76..d5eeed1c7749 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1022,6 +1022,48 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
   }
   EXPORT_SYMBOL(drm_fb_helper_deferred_io);
+/**
+ * drm_fb_helper_defio_init - fbdev deferred I/O initialization
+ * @fb_helper: driver-allocated fbdev helper
+ *
+ * This function allocates _deferred_io, sets callback to
+ * drm_fb_helper_deferred_io(), delay to 50ms and calls fb_deferred_io_init().
+ * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
+ *
+ * NOTE: A copy of _ops is made and assigned to >fbops. This is done
+ * because fb_deferred_io_cleanup() clears >fb_mmap and would thereby
+ * affect other instances of that _ops.

Do we need to call this before initial_config? Or after? Should be
documented imo.

Indeed it should be:

  * This function allocates _deferred_io, sets callback to
  * drm_fb_helper_deferred_io(), delay to 50ms and calls
fb_deferred_io_init().
  * It should be called from the _fb_helper_funcs->fb_probe callback.
  * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.

Forgot this part, lgtm, Reviewed-by: Daniel Vetter 

I think we got them all now?


Indeed, thanks Daniel.

Noralf.

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

Re: [PATCH 0/4 v5] Support bridge timings

[Daniel Vetter]

On Fri, Dec 15, 2017 at 01:30:24PM +0100, Linus Walleij wrote:
> On Fri, Dec 15, 2017 at 1:10 PM, Linus Walleij  
> wrote:
> 
> > - The connector is apparently not the right abstraction to carry
> >   the detailed timings specification between DRI drivers and bridge
> >   drivers.
> >
> > - Instead put detailed timing data into the bridge itself as an
> >   optional information pointer.
> 
> Notice that this is just my fumbling attempts to deal with the situation.
> 
> Laurent made me understand what the actual technical problem was,
> how come my pixels were flickering.
> 
> Both Laurent and DVetter mentioned that we may need to convey
> information between the bridge and the display engine in some
> way.
> 
> Alternatively I could go and hack on adding this to e.g. drm_display_info
> which was used in the previous patch sets by setting the negede flag
> in bus_formats.
> 
> I don't know. struct drm_display_info is getting a bit heavy as
> container of misc settings related to "some kind of display".
> The bridge isn't even a display itself, that is on the other side
> of it. So using the connector and treating a bridge as "some kind
> of display" seems wrong too.
> 
> Is there a third way?

If you don't plan to nest bridges too deeply, there is. Atm we have 2
modes in drm_crtc_state:

- mode, which is what userspace requested, and what it expects logically
  to be the actual real thing. I.e. timing, resolution and all that that
  userspace can observe (through plane positioning and vblank timestamps)
  should match this mode. For external screens this should also match
  what's physically going over the cable.

- adjusted_mode, which is something entirely undefined and to be used by
  drivers internally. Most drivers use it as the thing that's actually
  transported between the CRTC and the encoder.

There's a few common reasons for adjusted mode to be different:
- integrated panel, and your CRTC has a scaler. In that case the
  userspace-requested mode is what you feed into into the scaler, and the
  adjusted mode is what comes out of your scaler and then goes down the
  wire to the panel.

- your encoder is funky, and e.g. transcodes to the output mode itself,
  but expects that you program the input mode always the same. Usual
  reasons for this are transcoders that always want non-interlaced mode
  (and do the interlacing themselves), if the transcoder has some scaler
  itself (some TV-out transcoders had that), or if it has a strict
  expectation about signalling edges and stuff (and then transcodes the
  signal again). DACs are common doing that.
 
Anyway, sounds like your bridge is of the 2nd kind, so all you have to do
is
- in your bridge->mode_fixup function, adjust the adjusted_mode as needed
- in your pl111 driver, program the adjusted mode, not the originally
  requested mode

adjusted mode is set to be a copy of the requested mode by atomic helpers,
so this should keep working as-is on any other bridge driver.

No idea why I didn't tell you this right away, or maybe I'm missing
something this time around.

> I'm just a bit lost.

Once your un-lost, pls review the docs for drm_crtc_state and the various
mode_fixup functions, to make sure they're clear on how this is supposed
to work. Might need a new overview DOC: comment that ties it all together.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] drm/fb-helper: Add drm_fb_helper_defio_init()

[Daniel Vetter]

On Fri, Dec 15, 2017 at 02:18:55PM +0100, Noralf Trønnes wrote:
> 
> Den 14.12.2017 21.25, skrev Daniel Vetter:
> > On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
> > > Add helper for initializing fbdev deferred I/O.
> > > 
> > > The cleanup could have happened in drm_fb_helper_fini(), but that would
> > > have required me to set fb_info->fbdefio to NULL in a couple of drivers
> > > before they call _fini() to avoid double defio cleanup. The problem is
> > > that one of those is vboxvideo which lives in Greg's staging tree.
> > > So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
> > > but not that bad either.
> > > 
> > > Signed-off-by: Noralf Trønnes 
> > > ---
> > >   drivers/gpu/drm/drm_fb_helper.c | 53 
> > > +
> > >   include/drm/drm_fb_helper.h |  6 +
> > >   2 files changed, 59 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 14aa83579e76..d5eeed1c7749 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -1022,6 +1022,48 @@ void drm_fb_helper_deferred_io(struct fb_info 
> > > *info,
> > >   }
> > >   EXPORT_SYMBOL(drm_fb_helper_deferred_io);
> > > +/**
> > > + * drm_fb_helper_defio_init - fbdev deferred I/O initialization
> > > + * @fb_helper: driver-allocated fbdev helper
> > > + *
> > > + * This function allocates _deferred_io, sets callback to
> > > + * drm_fb_helper_deferred_io(), delay to 50ms and calls 
> > > fb_deferred_io_init().
> > > + * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
> > > + *
> > > + * NOTE: A copy of _ops is made and assigned to >fbops. This is 
> > > done
> > > + * because fb_deferred_io_cleanup() clears >fb_mmap and would 
> > > thereby
> > > + * affect other instances of that _ops.
> > Do we need to call this before initial_config? Or after? Should be
> > documented imo.
> 
> Indeed it should be:
> 
>  * This function allocates _deferred_io, sets callback to
>  * drm_fb_helper_deferred_io(), delay to 50ms and calls
> fb_deferred_io_init().
>  * It should be called from the _fb_helper_funcs->fb_probe callback.
>  * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.

Forgot this part, lgtm, Reviewed-by: Daniel Vetter 

I think we got them all now?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/fb-helper: Update DOC with new helpers

[Daniel Vetter]

On Fri, Dec 15, 2017 at 02:17:49PM +0100, Noralf Trønnes wrote:
> 
> Den 14.12.2017 20.10, skrev Noralf Trønnes:
> > Promote new helpers for dealing with fbdev emulation.
> > 
> > Signed-off-by: Noralf Trønnes 
> > ---
> >   drivers/gpu/drm/drm_fb_helper.c | 22 ++
> >   1 file changed, 10 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 823fc8f50d85..14aa83579e76 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -66,19 +66,17 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
> >* helper functions used by many drivers to implement the kernel mode 
> > setting
> >* interfaces.
> >*
> > - * Initialization is done as a four-step process with 
> > drm_fb_helper_prepare(),
> > - * drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and
> > - * drm_fb_helper_initial_config(). Drivers with fancier requirements than 
> > the
> > - * default behaviour can override the third step with their own code.
> > - * Teardown is done with drm_fb_helper_fini() after the fbdev device is
> > - * unregisters using drm_fb_helper_unregister_fbi().
> > + * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
> > + * down by calling drm_fb_helper_fbdev_teardown().
> >*
> 
> How about this for documenting when _setup() can't be used:
> 
>  * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
>  * down by calling drm_fb_helper_fbdev_teardown().
>  *
>  * Drivers that need to handle connector hotplugging (e.g. dp mst) can't use
>  * the setup helper and will need to do the whole four-step setup process
> with
>  * drm_fb_helper_prepare(), drm_fb_helper_init(),
>  * drm_fb_helper_single_add_all_connectors(), enable hotplugging and
>  * drm_fb_helper_initial_config() to avoid a possible race window.

lgtm, Reviewed-by: Daniel Vetter  on both this an
the other patch that inspired this update.
-Daniel

> 
> Noralf.
> 
> > - * At runtime drivers should restore the fbdev console by calling
> > - * drm_fb_helper_restore_fbdev_mode_unlocked() from their 
> > _driver.lastclose
> > - * callback.  They should also notify the fb helper code from updates to 
> > the
> > - * output configuration by calling drm_fb_helper_hotplug_event(). For 
> > easier
> > - * integration with the output polling code in drm_crtc_helper.c the 
> > modeset
> > - * code provides a _mode_config_funcs.output_poll_changed callback.
> > + * At runtime drivers should restore the fbdev console by using
> > + * drm_fb_helper_lastclose() as their _driver.lastclose callback.
> > + * They should also notify the fb helper code from updates to the output
> > + * configuration by using drm_fb_helper_output_poll_changed() as their
> > + * _mode_config_funcs.output_poll_changed callback.
> > + *
> > + * For suspend/resume consider using drm_mode_config_helper_suspend() and
> > + * drm_mode_config_helper_resume() which takes care of fbdev as well.
> >*
> >* All other functions exported by the fb helper library can be used to
> >* implement the fbdev driver interface by the driver.
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] drm/fb-helper: Add drm_fb_helper_defio_init()

[Daniel Vetter]

On Fri, Dec 15, 2017 at 2:18 PM, Noralf Trønnes  wrote:
>
> Den 14.12.2017 21.25, skrev Daniel Vetter:
>>
>> On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
>>>
>>> Add helper for initializing fbdev deferred I/O.
>>>
>>> The cleanup could have happened in drm_fb_helper_fini(), but that would
>>> have required me to set fb_info->fbdefio to NULL in a couple of drivers
>>> before they call _fini() to avoid double defio cleanup. The problem is
>>> that one of those is vboxvideo which lives in Greg's staging tree.
>>> So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
>>> but not that bad either.
>>>
>>> Signed-off-by: Noralf Trønnes 
>>> ---
>>>   drivers/gpu/drm/drm_fb_helper.c | 53
>>> +
>>>   include/drm/drm_fb_helper.h |  6 +
>>>   2 files changed, 59 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 14aa83579e76..d5eeed1c7749 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -1022,6 +1022,48 @@ void drm_fb_helper_deferred_io(struct fb_info
>>> *info,
>>>   }
>>>   EXPORT_SYMBOL(drm_fb_helper_deferred_io);
>>>   +/**
>>> + * drm_fb_helper_defio_init - fbdev deferred I/O initialization
>>> + * @fb_helper: driver-allocated fbdev helper
>>> + *
>>> + * This function allocates _deferred_io, sets callback to
>>> + * drm_fb_helper_deferred_io(), delay to 50ms and calls
>>> fb_deferred_io_init().
>>> + * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
>>> + *
>>> + * NOTE: A copy of _ops is made and assigned to >fbops. This is
>>> done
>>> + * because fb_deferred_io_cleanup() clears >fb_mmap and would
>>> thereby
>>> + * affect other instances of that _ops.
>>
>> Do we need to call this before initial_config? Or after? Should be
>> documented imo.
>
>
> Indeed it should be:
>
>  * This function allocates _deferred_io, sets callback to
>  * drm_fb_helper_deferred_io(), delay to 50ms and calls
> fb_deferred_io_init().
>  * It should be called from the _fb_helper_funcs->fb_probe callback.
>  * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
>
>> Also, did you look into just fixing fb_deferred_io_cleanup to no longer do
>> this? Changing function tables is definitely not cool (because that means
>> we can't put them into read-only memory and protect them from attackers -
>> function tables are a high-value target in the kernel, since usually easy
>> to trigger them).
>
>
> The fbdev operations isn't const:
>
> struct fb_info {
> struct fb_ops *fbops;
> };
>
> Fixing that is a project of it's own as a quick grep revealed:
>
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_fillrect =
> cfb_fillrect;
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_copyarea =
> cfb_copyarea;
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_imageblit =
> cfb_imageblit;
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_fillrect =
> mb86290fb_fillrect;
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_copyarea =
> mb86290fb_copyarea;
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_imageblit =
> mb86290fb_imageblit;
>
> drivers/video/fbdev/uvesafb.c:  info->fbops->fb_blank = NULL;
> drivers/video/fbdev/uvesafb.c: info->fbops->fb_pan_display = NULL;
>
> drivers/video/fbdev/aty/atyfb_base.c: info->fbops->fb_sync = atyfb_sync;
> drivers/video/fbdev/aty/atyfb_base.c: info->fbops->fb_sync = NULL;
>
> drivers/video/fbdev/aty/mach64_cursor.c: info->fbops->fb_cursor =
> atyfb_cursor;
>
> drivers/video/fbdev/core/fb_defio.c:info->fbops->fb_mmap =
> fb_deferred_io_mmap;
> drivers/video/fbdev/core/fb_defio.c:info->fbops->fb_mmap = NULL;

Ah, it frobs the mmap callback with it's own.

> drivers/video/fbdev/vesafb.c: info->fbops->fb_pan_display = NULL;
>
> drivers/video/fbdev/udlfb.c:info->fbops->fb_mmap =
> dlfb_ops_mmap;
>
> drivers/video/fbdev/smscufx.c:  info->fbops->fb_mmap = ufx_ops_mmap;
>
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_imageblit =
> nvidiafb_imageblit;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_fillrect =
> nvidiafb_fillrect;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_copyarea =
> nvidiafb_copyarea;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_sync = nvidiafb_sync;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_imageblit =
> cfb_imageblit;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_fillrect =
> cfb_fillrect;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_copyarea =
> cfb_copyarea;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_sync = NULL;
> drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_cursor = NULL;

^^ this one we can probably delete, use tegra or nouveau instead.

> drivers/gpu/drm/udl/udl_fb.c:   info->fbops->fb_mmap = udl_fb_mmap;

Ugh.

> 

Re: [PATCH] drm/msm: Fix NULL deref in adreno_load_gpu

[Jordan Crouse]

On Thu, Dec 14, 2017 at 11:11:50AM +0530, Archit Taneja wrote:
> The msm/kms driver should work even if there is no GPU device specified
> in DT. Currently, we get a NULL dereference crash in adreno_load_gpu
> since the driver assumes that priv->gpu_pdev is non-NULL.
> 
> Perform an additional check on priv->gpu_pdev before trying to retrieve
> the msm_gpu pointer from it.
> 
> Fixes: eec874ce5ff1 (drm/msm/adreno: load gpu at probe/bind time)
> 
> Signed-off-by: Archit Taneja 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 05022ea2a007..ac60cf3c794e 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -124,10 +124,17 @@ const struct adreno_info *adreno_info(struct adreno_rev 
> rev)
>  struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
>  {
>   struct msm_drm_private *priv = dev->dev_private;
> - struct platform_device *pdev = priv->gpu_pdev;
> - struct msm_gpu *gpu = platform_get_drvdata(priv->gpu_pdev);
> + struct platform_device *pdev;
> + struct msm_gpu *gpu;
>   int ret;
>  
> + pdev = priv->gpu_pdev;
> + if (!pdev) {
> + dev_dbg(dev->dev, "no adreno platform device found\n");
> + return NULL;
> + }
> +
> + gpu = platform_get_drvdata(pdev);
>   if (!gpu) {
>   dev_err(dev->dev, "no adreno device\n");
>   return NULL;

Obviously correct fix but I can't help but think that we should share the same
error message, so something like:

struct msm_gpu *gpu = NULL;

.. 

if (priv->gpu_pdev)
   gpu = platform_get_drvdata(priv->gpu_pdev);

if (!gpu) {
dev_err(dev->dev, "No GPU device was was found\n");
return NULL;
}

(also, I can't help but think maybe that dev_err should be a ONCE so you don't
get a nasty message every time you open the file descriptor).

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv3] drm/sun4i: validate modes for HDMI

[Hans Verkuil]

When I connected my cubieboard running 4.15-rc1 to my 4k display I got no 
picture. Some
digging found that there is no check against the upper pixelclock limit of the 
HDMI
output, so X selects a 4kp60 format at 594 MHz, which obviously won't work.

The patch below adds a check for the upper bound of what this hardware can do, 
and
it checks if the requested tmds clock can be obtained.

It also allows for the +/- 0.5% pixel clock variation that the HDMI spec 
permits.

That code is based on commit 22d0be2a557e53a22feb484e8fce255fe09e6ad5 from
Jose Abreu for drm/arc.

Signed-off-by: Hans Verkuil 
Thanks-to: Jose Abreu 
---
Changes since v2:
- Allow for the 0.5% variation.
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index dda904ec0534..a7e9eb93c378 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -208,8 +208,27 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
*connector)
return ret;
 }

+static int sun4i_hdmi_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+   struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
+   unsigned long rate = mode->clock * 1000;
+   long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
+   long rounded_rate;
+
+   /* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
+   if (rate > 16500)
+   return MODE_CLOCK_HIGH;
+   rounded_rate = clk_round_rate(hdmi->tmds_clk, rate);
+   if (max(rounded_rate, rate) - min(rounded_rate, rate) < diff &&
+   rounded_rate > 0)
+   return MODE_OK;
+   return MODE_NOCLOCK;
+}
+
 static const struct drm_connector_helper_funcs 
sun4i_hdmi_connector_helper_funcs = {
.get_modes  = sun4i_hdmi_get_modes,
+   .mode_valid = sun4i_hdmi_mode_valid,
 };

 static enum drm_connector_status
-- 
2.15.0

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

Re: [PATCHv2] drm/sun4i: validate modes for HDMI

[Maxime Ripard]

Hi Jose,

On Wed, Dec 13, 2017 at 12:07:05PM +, Jose Abreu wrote:
> On 13-12-2017 11:05, Hans Verkuil wrote:
> > On 13/12/17 11:30, Maxime Ripard wrote:
> >> Hi Hans,
> >>
> >> On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote:
> >>> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no 
> >>> picture. Some
> >>> digging found that there is no check against the upper pixelclock limit 
> >>> of the HDMI
> >>> output, so X selects a 4kp60 format at 594 MHz, which obviously won't 
> >>> work.
> >>>
> >>> The patch below adds a check for the upper bound of what this hardware 
> >>> can do, and
> >>> it checks if the requested tmds clock can be obtained.
> >>>
> >>> Signed-off-by: Hans Verkuil 
> >>> ---
> >>>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 19 +++
> >>>  1 file changed, 19 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> >>> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >>> index dda904ec0534..c10400a19b33 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >>> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >>> @@ -208,8 +208,27 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
> >>> *connector)
> >>>   return ret;
> >>>  }
> >>>
> >>> +static int sun4i_hdmi_mode_valid(struct drm_connector *connector,
> >>> +  struct drm_display_mode *mode)
> >>> +{
> >>> + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
> >>> + unsigned long rate = mode->clock * 1000;
> >>> + long rounded_rate;
> >>> +
> >>> + /* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
> >>> + if (rate > 16500)
> >>> + return MODE_CLOCK_HIGH;
> >>> + rounded_rate = clk_round_rate(hdmi->tmds_clk, rate);
> >>> + if (rounded_rate < rate)
> >>> + return MODE_CLOCK_LOW;
> >>> + if (rounded_rate > rate)
> >>> + return MODE_CLOCK_HIGH;
> >>> + return MODE_OK;
> >>> +}
> >> This looks much better, thanks!
> >>
> >> One thing that I was mentionning in my other mail is that our rate
> >> rounding might not provide the exact TMDS clock rate advertised by the
> >> EDID, while staying in the tolerancy.
> >>
> >> We've raised this issue before, without coming to a conclusion. Would
> >> you happen to know what that tolerancy would be on an HDMI link?
> > I can't actually find anything about that in the HDMI spec. However, the 
> > VESA DMT
> > spec specifies a tolerance of +/- 0.5% for the pixelclock.
> >
> > The HDMI 2.1 spec also suggests that this is the tolerance (caveat: I have 
> > not had
> > the time to study this in detail, but it does mention it when describing 
> > the new
> > variable refresh rate feature).
> >
> > That said, the problem with a 0.5% tolerance is that the slight slowdown 
> > for 59.94
> > vs 60 Hz framerate falls within that tolerance (it's a 0.1% slowdown).
> >
> > Generally clocks will be able to hit the standard frequencies (74.25, 
> > 148.5, etc)
> > exactly, but if you want to slow down for 59.94 framerate they tend to be 
> > off by
> > a bit.
> >
> > In the end I think keeping a margin of 0.4 or 0.5% is the best approach.
> 
> We had the same problem in arcpgu, please check if commit [1] can
> be used by you.
> 
> Best Regards,
> Jose Miguel Abreu
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22d0be2a557e53a22feb484e8fce255fe09e6ad5

Yeah, something like that would definitely work. I'm not entirely sure
whether we need to report whether the clock was too high or too low,
but I'm totally fine with something like that.

Hans, do you want to resend a new version of this patch?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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/tegra: mark t186 display hub PM functions __maybe_unused

[Dmitry Osipenko]

On 15.12.2017 15:51, Arnd Bergmann wrote:
> The newly introduced driver has optional suspend/resume functions,
> causing a warning when CONFIG_PM is disabled:
> 
> drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined 
> but not used [-Werror=unused-function]
> drivers/gpu/drm/tegra/hub.c:733:12: error: 'tegra_display_hub_suspend' 
> defined but not used [-Werror=unused-function]
> 
> This marks them __maybe_unused to shut up the warnings.
> 
> Fixes: c4755fb9064f ("drm/tegra: Add Tegra186 display hub support")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/tegra/hub.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
> index cccd44711d68..f4911feda9ff 100644
> --- a/drivers/gpu/drm/tegra/hub.c
> +++ b/drivers/gpu/drm/tegra/hub.c
> @@ -730,7 +730,7 @@ static int tegra_display_hub_remove(struct 
> platform_device *pdev)
>   return err;
>  }
>  
> -static int tegra_display_hub_suspend(struct device *dev)
> +static int __maybe_unused tegra_display_hub_suspend(struct device *dev)
>  {
>   struct tegra_display_hub *hub = dev_get_drvdata(dev);
>   int err;
> @@ -746,7 +746,7 @@ static int tegra_display_hub_suspend(struct device *dev)
>   return 0;
>  }
>  
> -static int tegra_display_hub_resume(struct device *dev)
> +static int __maybe_unused tegra_display_hub_resume(struct device *dev)
>  {
>   struct tegra_display_hub *hub = dev_get_drvdata(dev);
>   int err;
> 

Probably would be better to put '#ifdef CONFIG_PM' around these functions for
the consistency with the other drm/tegra files.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[Thomas Hellstrom]

On 12/15/2017 01:05 PM, Christian König wrote:


I'm in favour of that. But I don't think what I proposed is a step 
away from that direction. On the contrary.  I've attached a POC patch 
with the correctness checks stripped, not compile-tested. Much easier 
to follow if you ask me, but if you feel so strongly against it, 
never mind.


Exactly that's what I've meant with that this won't work. See you 
loose the extra check "!ctx->allow_reserved_eviction && 
list_empty(>ddestroy))" here and that one is really important for 
correct operation.


Um, yes. The list_empty(>ddestroy) can't be guaranteed to be 
preserved against a  lock - unlock sequence, that would indeed need an 
extra state variable bo->shared_reserved, but still allow for locking 
outside of TTM.


But apparently we have different opinions what's clean and what's not, 
and you're the maintainer now, so you decide :).


/Thomas




Regards,
Christian.



Thanks,
Thomas




Regards,
Christian. qq




I agree recursive locking is generally frowned upon, but you're 
already doing it, not by using recursive locks, but by passing 
locking state around which IMO is worse.


Collecting the state in a the operation_ctx will make that 
usage-pattern more obvious but will help make the code cleaner and 
less error prone.


/Thomas





Regards,
Christian.

Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom:

Roger and Chrisitian,

Correct me if I'm wrong, but It seems to me like a lot of the 
recent changes to ttm_bo.c are to allow recursive reservation 
object locking in the case of shared reservation objects, but 
only in certain functions and with special arguments so it 
doesn't look like recursive locking to the lockdep checker. 
Wouldn't it be a lot cleaner if we were to hide all this in a 
resurrected __ttm_bo_reserve something along the lines of


int __ttm_bo_reserve(struct ttm_bo *bo, struct ttm_operation_ctx 
*ctx) {

    if (ctx && ctx->resv == bo->resv) {
#ifdef CONFIG_LOCKDEP
    WARN_ON(bo->reserved);
lockdep_assert_held(>resv);
        ctx->reserve_count++;
bo->reserved = true;
#endif
        return0;
 } else {
    int ret = reservation_object_lock(bo->resv, NULL) ? 
0:-EBUSY;


    if (ret)
            return ret;
#ifdef CONFIG_LOCKDEP
        WARN_ON(bo->reserved);
        bo->reserved = true;
#endif
        return 0;
}

And similar for tryreserve and unreserve? Perhaps with a 
ww_acquire_ctx included somewhere as well...


/Thomas




On 12/14/2017 09:10 AM, Roger He wrote:

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
b/drivers/gpu/drm/ttm/ttm_bo.c

index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,

  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
    static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   struct reservation_object *resv,
 uint32_t mem_type,
 const struct ttm_place *place,
 struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct 
ttm_bo_device *bdev,

  spin_lock(>lru_lock);
  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  list_for_each_entry(bo, >lru[i], lru) {
-    if (bo->resv == resv) {
-    if (list_empty(>ddestroy))
+    if (bo->resv == ctx->resv) {
+    if (!ctx->allow_reserved_eviction &&
+    list_empty(>ddestroy))
  continue;
  } else {
  locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,

  return ret;
  if (mem->mm_node)
  break;
-    ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, 
place, ctx);

+    ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
  if (unlikely(ret != 0))
  return ret;
  } while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct 
ttm_bo_device *bdev,

  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  while (!list_empty(>lru[i])) {
  spin_unlock(>lru_lock);
-    ret = ttm_mem_evict_first(bdev, NULL, mem_type,
-  NULL, );
+    ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
  if (ret)
  return ret;
  spin_lock(>lru_lock);





___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx





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

Re: [PATCH] drm/tegra: mark t186 display hub PM functions __maybe_unused

[Arnd Bergmann]

On Fri, Dec 15, 2017 at 2:33 PM, Thierry Reding
 wrote:
> On Fri, Dec 15, 2017 at 01:51:52PM +0100, Arnd Bergmann wrote:
>> The newly introduced driver has optional suspend/resume functions,
>> causing a warning when CONFIG_PM is disabled:
>>
>> drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' 
>> defined but not used [-Werror=unused-function]
>> drivers/gpu/drm/tegra/hub.c:733:12: error: 'tegra_display_hub_suspend' 
>> defined but not used [-Werror=unused-function]
>>
>> This marks them __maybe_unused to shut up the warnings.
>>
>> Fixes: c4755fb9064f ("drm/tegra: Add Tegra186 display hub support")
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  drivers/gpu/drm/tegra/hub.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> We had touched on this topic in a different thread. The Tegra DRM driver
> currently relies on runtime PM to work properly. I don't see a reason to
> not make that official by adding a select PM to menuconfig ARCH_TEGRA on
> 32-bit ARM just like we already do on 64-bit ARM.
>
> I've gone and applied this patch as an interim solution. Once we've made
> the switch to select PM on all generations of Tegra we can remove all
> the #ifdef and __maybe_unused.

Sounds good, thanks!

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

Re: [PATCH] drm/tegra: mark t186 display hub PM functions __maybe_unused

[Thierry Reding]

On Fri, Dec 15, 2017 at 01:51:52PM +0100, Arnd Bergmann wrote:
> The newly introduced driver has optional suspend/resume functions,
> causing a warning when CONFIG_PM is disabled:
> 
> drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined 
> but not used [-Werror=unused-function]
> drivers/gpu/drm/tegra/hub.c:733:12: error: 'tegra_display_hub_suspend' 
> defined but not used [-Werror=unused-function]
> 
> This marks them __maybe_unused to shut up the warnings.
> 
> Fixes: c4755fb9064f ("drm/tegra: Add Tegra186 display hub support")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/tegra/hub.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

We had touched on this topic in a different thread. The Tegra DRM driver
currently relies on runtime PM to work properly. I don't see a reason to
not make that official by adding a select PM to menuconfig ARCH_TEGRA on
32-bit ARM just like we already do on 64-bit ARM.

I've gone and applied this patch as an interim solution. Once we've made
the switch to select PM on all generations of Tegra we can remove all
the #ifdef and __maybe_unused.

Thanks,
Thierry


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

Re: [PATCH libdrm] etnaviv: fix BO cache to properly work with different flags

[Philipp Zabel]

On Fri, 2017-12-15 at 11:30 +0100, Lucas Stach wrote:
> Currently if the oldest BO in a bucket has different flags than what we
> look for we'll miss the cache.Fix this by iterating over the cached BOs
> until we find the oldest one with matching flags. This improves the hit
> ratio for some of the buckets.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

regards
Philipp

> ---
>  etnaviv/etnaviv_bo_cache.c | 26 +++---
>  1 file changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/etnaviv/etnaviv_bo_cache.c b/etnaviv/etnaviv_bo_cache.c
> index 8924651f0cd8..6208230dc81a 100644
> --- a/etnaviv/etnaviv_bo_cache.c
> +++ b/etnaviv/etnaviv_bo_cache.c
> @@ -124,20 +124,32 @@ static int is_idle(struct etna_bo *bo)
>  
>  static struct etna_bo *find_in_bucket(struct etna_bo_bucket *bucket, 
> uint32_t flags)
>  {
> - struct etna_bo *bo = NULL;
> + struct etna_bo *bo = NULL, *tmp;
>  
>   pthread_mutex_lock(_lock);
> - while (!LIST_IS_EMPTY(>list)) {
> - bo = LIST_ENTRY(struct etna_bo, bucket->list.next, list);
>  
> - if (bo->flags == flags && is_idle(bo)) {
> - list_del(>list);
> - break;
> + if (LIST_IS_EMPTY(>list))
> + goto out_unlock;
> +
> + LIST_FOR_EACH_ENTRY_SAFE(bo, tmp, >list, list) {
> + /* skip BOs with different flags */
> + if (bo->flags != flags)
> + continue;
> +
> + /* check if the first BO with matching flags is idle */
> + if (is_idle(bo)) {
> + list_delinit(>list);
> + goto out_unlock;
>   }
>  
> - bo = NULL;
> + /* If the oldest BO is still busy, don't try younger ones */
>   break;
>   }
> +
> + /* There was no matching buffer found */
> + bo = NULL;
> +
> +out_unlock:
>   pthread_mutex_unlock(_lock);
>  
>   return bo;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/7] drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()

[Noralf Trønnes]

Den 14.12.2017 21.19, skrev Daniel Vetter:

On Thu, Dec 14, 2017 at 08:10:03PM +0100, Noralf Trønnes wrote:

Add helpers to setup and teardown fbdev emulation.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_helper.c | 106 
  include/drm/drm_fb_helper.h |  25 ++
  2 files changed, 131 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 04a3a5ce370a..823fc8f50d85 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2729,6 +2729,112 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
  }
  EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
  
+/**

+ * drm_fb_helper_fbdev_setup() - Setup fbdev emulation
+ * @dev: DRM device
+ * @fb_helper: fbdev helper structure to set up
+ * @funcs: fbdev helper functions
+ * @preferred_bpp: Preferred bits per pixel for the device.
+ * @dev->mode_config.preferred_depth is used if this is zero.
+ * @max_conn_count: Maximum number of connectors.
+ *  @dev->mode_config.num_connector is used if this is zero.
+ *
+ * This function sets up fbdev emulation and registers fbdev for access by
+ * userspace. If all connectors are disconnected, setup is deferred to the next
+ * time drm_fb_helper_hotplug_event() is called.
+ * The caller must to provide a _fb_helper_funcs->fb_probe callback
+ * function.

I think we should be a bit clearer when it's not advisable to use this
helper because there are issues:
- when connectors can be hotplugged (e.g. dp mst). For that case you need
   to init the fbdev before you enabling hotplugging, but call
   initial_config after you've enabled hotplugging. Otherwise there's a
   posssible race window.


I have made a propose DOC change in patch 4.


- when there's anything else that mus be done before we do the fbdev
   registration, e.g. defio_init.


This happens in .fb_probe callback. See my reply to patch 5.


So still not 100% sure this will help you all that much, but it's also not
an unreasonable idea.

Assuming we can agree on the ceveats and how do document them:

Reviewed-by: Daniel Vetter 


+ *
+ * See also: drm_fb_helper_initial_config()
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fb_helper_fbdev_setup(struct drm_device *dev,
+ struct drm_fb_helper *fb_helper,
+ const struct drm_fb_helper_funcs *funcs,
+ unsigned int preferred_bpp,
+ unsigned int max_conn_count)
+{
+   int ret;
+
+   if (!preferred_bpp)
+   preferred_bpp = dev->mode_config.preferred_depth;
+   if (!preferred_bpp)
+   preferred_bpp = 32;
+
+   if (!max_conn_count)
+   max_conn_count = dev->mode_config.num_connector;
+   if (!max_conn_count) {
+   DRM_DEV_ERROR(dev->dev, "No connectors\n");
+   return -EINVAL;
+   }
+
+   drm_fb_helper_prepare(dev, fb_helper, funcs);
+
+   ret = drm_fb_helper_init(dev, fb_helper, max_conn_count);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to initialize fbdev helper\n");
+   return ret;
+   }
+
+   ret = drm_fb_helper_single_add_all_connectors(fb_helper);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to add connectors\n");
+   goto err_drm_fb_helper_fini;
+   }
+
+   if (!drm_drv_uses_atomic_modeset(dev))
+   drm_helper_disable_unused_functions(dev);
+
+   ret = drm_fb_helper_initial_config(fb_helper, preferred_bpp);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to set fbdev configuration\n");
+   goto err_drm_fb_helper_fini;
+   }
+
+   return 0;
+
+err_drm_fb_helper_fini:
+   drm_fb_helper_fini(fb_helper);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_fbdev_setup);
+
+/**
+ * drm_fb_helper_fbdev_teardown - Tear down fbdev emulation
+ * @dev: DRM device
+ *
+ * This function unregisters fbdev if not already done and cleans up the
+ * associated resources including the _framebuffer.
+ * The driver is responsible for freeing the _fb_helper structure which is
+ * stored in _device->fb_helper. Do note that this pointer has been cleared
+ * when this function returns.
+ *
+ * In order to support device removal/unplug while file handles are still open,
+ * drm_fb_helper_unregister_fbi() should be called on device removal and
+ * drm_fb_helper_fbdev_teardown() in the _driver->release callback when
+ * file handles are closed.
+ */
+void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
+{
+   struct drm_fb_helper *fb_helper = dev->fb_helper;
+
+   if (!fb_helper)
+   return;
+
+   /* Unregister if it hasn't been done already */
+   if (fb_helper->fbdev && fb_helper->fbdev->dev)
+ 

[Bug 104043] TV out garbled with linux > 3.2 (RV516)

[bugzilla-daemon]

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

frodz...@gmail.com changed:

   What|Removed |Added

 Attachment #136193|0   |1
is obsolete||

--- Comment #6 from frodz...@gmail.com ---
Created attachment 136194
  --> https://bugs.freedesktop.org/attachment.cgi?id=136194=edit
Xorg log (with text/plain content 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 5/7] drm/fb-helper: Add drm_fb_helper_defio_init()

[Noralf Trønnes]

Den 14.12.2017 21.25, skrev Daniel Vetter:

On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:

Add helper for initializing fbdev deferred I/O.

The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo which lives in Greg's staging tree.
So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
but not that bad either.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_helper.c | 53 +
  include/drm/drm_fb_helper.h |  6 +
  2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 14aa83579e76..d5eeed1c7749 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1022,6 +1022,48 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
  }
  EXPORT_SYMBOL(drm_fb_helper_deferred_io);
  
+/**

+ * drm_fb_helper_defio_init - fbdev deferred I/O initialization
+ * @fb_helper: driver-allocated fbdev helper
+ *
+ * This function allocates _deferred_io, sets callback to
+ * drm_fb_helper_deferred_io(), delay to 50ms and calls fb_deferred_io_init().
+ * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
+ *
+ * NOTE: A copy of _ops is made and assigned to >fbops. This is done
+ * because fb_deferred_io_cleanup() clears >fb_mmap and would thereby
+ * affect other instances of that _ops.

Do we need to call this before initial_config? Or after? Should be
documented imo.


Indeed it should be:

 * This function allocates _deferred_io, sets callback to
 * drm_fb_helper_deferred_io(), delay to 50ms and calls 
fb_deferred_io_init().

 * It should be called from the _fb_helper_funcs->fb_probe callback.
 * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.


Also, did you look into just fixing fb_deferred_io_cleanup to no longer do
this? Changing function tables is definitely not cool (because that means
we can't put them into read-only memory and protect them from attackers -
function tables are a high-value target in the kernel, since usually easy
to trigger them).


The fbdev operations isn't const:

struct fb_info {
    struct fb_ops *fbops;
};

Fixing that is a project of it's own as a quick grep revealed:

drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_fillrect 
= cfb_fillrect;
drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_copyarea 
= cfb_copyarea;
drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_imageblit 
= cfb_imageblit;
drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_fillrect 
= mb86290fb_fillrect;
drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_copyarea 
= mb86290fb_copyarea;
drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: info->fbops->fb_imageblit 
= mb86290fb_imageblit;


drivers/video/fbdev/uvesafb.c:  info->fbops->fb_blank = NULL;
drivers/video/fbdev/uvesafb.c: info->fbops->fb_pan_display = NULL;

drivers/video/fbdev/aty/atyfb_base.c: info->fbops->fb_sync = atyfb_sync;
drivers/video/fbdev/aty/atyfb_base.c: info->fbops->fb_sync = NULL;

drivers/video/fbdev/aty/mach64_cursor.c: info->fbops->fb_cursor = 
atyfb_cursor;


drivers/video/fbdev/core/fb_defio.c:    info->fbops->fb_mmap = 
fb_deferred_io_mmap;

drivers/video/fbdev/core/fb_defio.c:    info->fbops->fb_mmap = NULL;

drivers/video/fbdev/vesafb.c: info->fbops->fb_pan_display = NULL;

drivers/video/fbdev/udlfb.c:    info->fbops->fb_mmap = 
dlfb_ops_mmap;


drivers/video/fbdev/smscufx.c:  info->fbops->fb_mmap = ufx_ops_mmap;

drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_imageblit = 
nvidiafb_imageblit;
drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_fillrect = 
nvidiafb_fillrect;
drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_copyarea = 
nvidiafb_copyarea;

drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_sync = nvidiafb_sync;
drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_imageblit = 
cfb_imageblit;
drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_fillrect = 
cfb_fillrect;
drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_copyarea = 
cfb_copyarea;

drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_sync = NULL;
drivers/video/fbdev/nvidia/nvidia.c: info->fbops->fb_cursor = NULL;

drivers/gpu/drm/udl/udl_fb.c:   info->fbops->fb_mmap = udl_fb_mmap;

drivers/gpu/drm/drm_fb_cma_helper.c: fbi->fbops->fb_mmap = 
drm_fbdev_cma_deferred_io_mmap;


Noralf.




+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper)
+{
+   struct fb_info *info = fb_helper->fbdev;
+   struct fb_deferred_io *fbdefio;
+   struct fb_ops *fbops;
+
+   fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
+   fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
+   if 

Re: [PATCH] drm/tegra: mark t186 display hub PM functions __maybe_unused

[Arnd Bergmann]

On Fri, Dec 15, 2017 at 2:10 PM, Dmitry Osipenko  wrote:
> On 15.12.2017 15:51, Arnd Bergmann wrote:
>> --- a/drivers/gpu/drm/tegra/hub.c
>> +++ b/drivers/gpu/drm/tegra/hub.c
>> @@ -730,7 +730,7 @@ static int tegra_display_hub_remove(struct 
>> platform_device *pdev)
>>   return err;
>>  }
>>
>> -static int tegra_display_hub_suspend(struct device *dev)
>> +static int __maybe_unused tegra_display_hub_suspend(struct device *dev)
>>  {
>>   struct tegra_display_hub *hub = dev_get_drvdata(dev);
>>   int err;
>> @@ -746,7 +746,7 @@ static int tegra_display_hub_suspend(struct device *dev)
>>   return 0;
>>  }
>>
>> -static int tegra_display_hub_resume(struct device *dev)
>> +static int __maybe_unused tegra_display_hub_resume(struct device *dev)
>>  {
>>   struct tegra_display_hub *hub = dev_get_drvdata(dev);
>>   int err;
>>
>
> Probably would be better to put '#ifdef CONFIG_PM' around these functions for
> the consistency with the other drm/tegra files.

I usually use __maybe_unused because it is less error-prone, the
#ifdefs are often
wrong, either they are around the wrong functions or they use CONFIG_PM
CONFIG_PM_SLEEP interchangeably, which they are not. If you want to
add a patch with the correct #ifdef instead of my patch, that's fine with me
(add a Reported-by tag then), but I won't send a patch to do that myself.

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

Re: [PATCH 4/7] drm/fb-helper: Update DOC with new helpers

[Noralf Trønnes]

Den 14.12.2017 20.10, skrev Noralf Trønnes:

Promote new helpers for dealing with fbdev emulation.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_helper.c | 22 ++
  1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 823fc8f50d85..14aa83579e76 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -66,19 +66,17 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
   * helper functions used by many drivers to implement the kernel mode setting
   * interfaces.
   *
- * Initialization is done as a four-step process with drm_fb_helper_prepare(),
- * drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and
- * drm_fb_helper_initial_config(). Drivers with fancier requirements than the
- * default behaviour can override the third step with their own code.
- * Teardown is done with drm_fb_helper_fini() after the fbdev device is
- * unregisters using drm_fb_helper_unregister_fbi().
+ * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
+ * down by calling drm_fb_helper_fbdev_teardown().
   *


How about this for documenting when _setup() can't be used:

 * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
 * down by calling drm_fb_helper_fbdev_teardown().
 *
 * Drivers that need to handle connector hotplugging (e.g. dp mst) 
can't use
 * the setup helper and will need to do the whole four-step setup 
process with

 * drm_fb_helper_prepare(), drm_fb_helper_init(),
 * drm_fb_helper_single_add_all_connectors(), enable hotplugging and
 * drm_fb_helper_initial_config() to avoid a possible race window.

Noralf.


- * At runtime drivers should restore the fbdev console by calling
- * drm_fb_helper_restore_fbdev_mode_unlocked() from their _driver.lastclose
- * callback.  They should also notify the fb helper code from updates to the
- * output configuration by calling drm_fb_helper_hotplug_event(). For easier
- * integration with the output polling code in drm_crtc_helper.c the modeset
- * code provides a _mode_config_funcs.output_poll_changed callback.
+ * At runtime drivers should restore the fbdev console by using
+ * drm_fb_helper_lastclose() as their _driver.lastclose callback.
+ * They should also notify the fb helper code from updates to the output
+ * configuration by using drm_fb_helper_output_poll_changed() as their
+ * _mode_config_funcs.output_poll_changed callback.
+ *
+ * For suspend/resume consider using drm_mode_config_helper_suspend() and
+ * drm_mode_config_helper_resume() which takes care of fbdev as well.
   *
   * All other functions exported by the fb helper library can be used to
   * implement the fbdev driver interface by the driver.


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

[Bug 104043] TV out garbled with linux > 3.2 (RV516)

[bugzilla-daemon]

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

--- Comment #5 from frodz...@gmail.com ---
Created attachment 136193
  --> https://bugs.freedesktop.org/attachment.cgi?id=136193=edit
Xorg log

-- 
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/tegra: mark t186 display hub PM functions __maybe_unused

[Arnd Bergmann]

The newly introduced driver has optional suspend/resume functions,
causing a warning when CONFIG_PM is disabled:

drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined 
but not used [-Werror=unused-function]
drivers/gpu/drm/tegra/hub.c:733:12: error: 'tegra_display_hub_suspend' defined 
but not used [-Werror=unused-function]

This marks them __maybe_unused to shut up the warnings.

Fixes: c4755fb9064f ("drm/tegra: Add Tegra186 display hub support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tegra/hub.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index cccd44711d68..f4911feda9ff 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -730,7 +730,7 @@ static int tegra_display_hub_remove(struct platform_device 
*pdev)
return err;
 }
 
-static int tegra_display_hub_suspend(struct device *dev)
+static int __maybe_unused tegra_display_hub_suspend(struct device *dev)
 {
struct tegra_display_hub *hub = dev_get_drvdata(dev);
int err;
@@ -746,7 +746,7 @@ static int tegra_display_hub_suspend(struct device *dev)
return 0;
 }
 
-static int tegra_display_hub_resume(struct device *dev)
+static int __maybe_unused tegra_display_hub_resume(struct device *dev)
 {
struct tegra_display_hub *hub = dev_get_drvdata(dev);
int err;
-- 
2.9.0

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

[Bug 104043] TV out garbled with linux > 3.2 (RV516)

[bugzilla-daemon]

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

--- Comment #4 from frodz...@gmail.com ---
Created attachment 136192
  --> https://bugs.freedesktop.org/attachment.cgi?id=136192=edit
dmesg log

-- 
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 104043] TV out garbled with linux > 3.2 (RV516)

[bugzilla-daemon]

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

--- Comment #3 from frodz...@gmail.com ---
Hi, thanks for the response and sorry for taking so long but the notification
went to spam folder. I will attach the Xorg log later today.

I actually tried to bisect already. The problem is that it doesn't happen all
the time (I found that out during the bisect). With a recent kernel it happens
all the time but with an older kernel (I'm at g8ff1f792dd68/3.6.0-rc7 right
now) it happens about 1 out of 4 boots (rough guess). Luckily the corruption
with recent kernels (where it happens all the time) looks different. With newer
kernels is just horizontal purple lines, with older ones it alsa has vertical
lines. So I may be able to bisect up to the point where it can be reproduced
all the time. Hopefully that will help.

When it boots correctly if I start my application (which uses DRM/EGL without
X) it starts correctly but when I quit it and return the to the VT console the
display gets corrupted most of the time. If I get lucky and quit the app once
without the display getting corrupted then I can restart it again and again
without getting corruption until I reboot.

Starting X is harder because most of the time the display gets corrupted when X
starts.

-- 
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 0/4 v5] Support bridge timings

[Linus Walleij]

On Fri, Dec 15, 2017 at 1:10 PM, Linus Walleij  wrote:

> - The connector is apparently not the right abstraction to carry
>   the detailed timings specification between DRI drivers and bridge
>   drivers.
>
> - Instead put detailed timing data into the bridge itself as an
>   optional information pointer.

Notice that this is just my fumbling attempts to deal with the situation.

Laurent made me understand what the actual technical problem was,
how come my pixels were flickering.

Both Laurent and DVetter mentioned that we may need to convey
information between the bridge and the display engine in some
way.

Alternatively I could go and hack on adding this to e.g. drm_display_info
which was used in the previous patch sets by setting the negede flag
in bus_formats.

I don't know. struct drm_display_info is getting a bit heavy as
container of misc settings related to "some kind of display".
The bridge isn't even a display itself, that is on the other side
of it. So using the connector and treating a bridge as "some kind
of display" seems wrong too.

Is there a third way?

I'm just a bit lost.

Suggestions welcome!

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

Re: [PATCH] drm/amd/display: remove redundant null check of array 'data'

[Christian König]

Am 15.12.2017 um 11:53 schrieb Colin King:

From: Colin Ian King 

The null check on aconnector->base.edid_blob_ptr->data is redundant
since data is an array and can never be null.  Remove it.

Detected by CoverityScan, CID#1460369 ("Array compared against 0")

Signed-off-by: Colin Ian King 


Acked-by: Christian König 


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ccbf10e3bbb6..c388778dbba3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2725,8 +2725,7 @@ static void create_eml_sink(struct amdgpu_dm_connector 
*aconnector)
};
struct edid *edid;
  
-	if (!aconnector->base.edid_blob_ptr ||

-   !aconnector->base.edid_blob_ptr->data) {
+   if (!aconnector->base.edid_blob_ptr) {
DRM_ERROR("No EDID firmware found on connector: %s ,forcing to 
OFF!\n",
aconnector->base.name);
  


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

[PATCH 2/4 v5] drm/bridge: Provide a way to embed timing info in bridges

[Linus Walleij]

After some discussion and failed patch sets trying to convey
the right timing information between the display engine and
a bridge using the connector, I try instead to use an optional
timing information container in the bridge itself, so that
display engines can retrieve it from any bridge and use it to
determine how to drive outputs.

Signed-off-by: Linus Walleij 
---
ChangeLog ->v5:
- New patch
---
 include/drm/drm_bridge.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..3bf34f7c90d4 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -30,6 +30,7 @@
 
 struct drm_bridge;
 struct drm_panel;
+struct drm_bridge_timings;
 
 /**
  * struct drm_bridge_funcs - drm_bridge control functions
@@ -222,6 +223,22 @@ struct drm_bridge_funcs {
void (*enable)(struct drm_bridge *bridge);
 };
 
+/**
+ * struct drm_bridge_timings - timing information for the bridge
+ * @sampling_edge: whether the bridge samples the digital input signal from the
+ * display engine on the positive or negative edge of the clock - false means
+ * negative edge, true means positive edge.
+ * @setup_time_ps: the time in picoseconds the input data lines must be stable
+ * before the clock edge
+ * @hold_time_ps: the time in picoseconds taken for the bridge to sample the
+ * input signal after the rising or falling edge
+ */
+struct drm_bridge_timings {
+   bool sampling_edge;
+   u32 setup_time_ps;
+   u32 hold_time_ps;
+};
+
 /**
  * struct drm_bridge - central DRM bridge control structure
  * @dev: DRM device this bridge belongs to
@@ -229,6 +246,8 @@ struct drm_bridge_funcs {
  * @next: the next bridge in the encoder chain
  * @of_node: device node pointer to the bridge
  * @list: to keep track of all added bridges
+ * @timings: the timing specification for the bridge, if any (may
+ * be NULL)
  * @funcs: control functions
  * @driver_private: pointer to the bridge driver's internal context
  */
@@ -240,6 +259,7 @@ struct drm_bridge {
struct device_node *of_node;
 #endif
struct list_head list;
+   const struct drm_bridge_timings *timings;
 
const struct drm_bridge_funcs *funcs;
void *driver_private;
-- 
2.14.3

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

[PATCH 0/4 v5] Support bridge timings

[Linus Walleij]

This patch set is in response to Laurent's mail:
https://www.spinics.net/lists/dri-devel/msg155618.html

So in summary:
- The connector is apparently not the right abstraction to carry
  the detailed timings specification between DRI drivers and bridge
  drivers.

- Instead put detailed timing data into the bridge itself as an
  optional information pointer.

- Add fields to specify triggering edge on the clock, setup
  and hold time for the bridge.

- Augment the dumb VGA driver with this data, supporting a few
  ADV and TI variants.

- Augment the PL111 driver to use this data to figure out if it
  needs to clock out display data on the negative edge rather
  than the positive edge because the current clocking out on the
  positive edge obviously partly misses the setup->hold window,
  as can be observed in annoying green flicker.

Linus Walleij (4):
  drm/bridge: Add bindings for TI THS8134
  drm/bridge: Provide a way to embed timing info in bridges
  drm/bridge: Add timing support to dumb VGA DAC
  drm/pl111: Support handling bridge timings

 .../bridge/{ti,ths8135.txt => ti,ths813x.txt}  | 13 +++--
 drivers/gpu/drm/bridge/dumb-vga-dac.c  | 61 --
 drivers/gpu/drm/pl111/Kconfig  |  1 +
 drivers/gpu/drm/pl111/pl111_display.c  | 35 +++--
 drivers/gpu/drm/pl111/pl111_drv.c  | 20 +++
 include/drm/drm_bridge.h   | 20 +++
 6 files changed, 130 insertions(+), 20 deletions(-)
 rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt => 
ti,ths813x.txt} (69%)

-- 
2.14.3

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

[PATCH 3/4 v5] drm/bridge: Add timing support to dumb VGA DAC

[Linus Walleij]

This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.

We assign the proper timing data to the pointer inside the
bridge struct so display controllers that need to align their
timings to the bridge can pick it up and work from there.

Cc: Laurent Pinchart 
Cc: Bartosz Golaszewski 
Cc: Maxime Ripard 
Signed-off-by: Linus Walleij 
---
ChangeLog v4->v5:
- Rewrite the support using the new concept of defining
  fine-granular sampling (setup+hold) timing definitions
  stored in the bridge timings struct.
ChangeLog v3->v4:
- Actually have the code syntactically correct and compiling :(
  (Kconfig mistake.)
  (...)
  AS  usr/initramfs_data.o
  AR  usr/built-in.o
  CC  drivers/gpu/drm/bridge/dumb-vga-dac.o
  AR  drivers/gpu/drm/bridge/built-in.o
  AR  drivers/gpu/drm/built-in.o
  AR  drivers/gpu/built-in.o
  AR  drivers/built-in.o
  (...)
ChangeLog v2->v3:
- Move const specifier.
- Cut one line of code assigning bus flags.
- Preserve the "ti,ths8135" compatible for elder device trees.
ChangeLog v1->v2:
- Alphabetize includes
- Use a u32 with the bus polarity flags and just encode the
  polarity using the DRM define directly.
- Rename vendor_data to vendor_info.
- Simplify assignment of the flag as it is just a simple
  u32 now.
- Probe all TI variants on the "ti,ths813x" wildcard for now,
  we only need to know that the device is in this family to
  set the clock edge flag right.
---
 drivers/gpu/drm/bridge/dumb-vga-dac.c | 61 +--
 1 file changed, 58 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index de5e7dee7ad6..34788783a90f 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -176,11 +177,13 @@ static struct i2c_adapter *dumb_vga_retrieve_ddc(struct 
device *dev)
 static int dumb_vga_probe(struct platform_device *pdev)
 {
struct dumb_vga *vga;
+   const struct drm_bridge_timings *timings;
 
vga = devm_kzalloc(>dev, sizeof(*vga), GFP_KERNEL);
if (!vga)
return -ENOMEM;
platform_set_drvdata(pdev, vga);
+   timings = of_device_get_match_data(>dev);
 
vga->vdd = devm_regulator_get_optional(>dev, "vdd");
if (IS_ERR(vga->vdd)) {
@@ -204,6 +207,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
 
vga->bridge.funcs = _vga_bridge_funcs;
vga->bridge.of_node = pdev->dev.of_node;
+   vga->bridge.timings = timings;
 
drm_bridge_add(>bridge);
 
@@ -222,10 +226,61 @@ static int dumb_vga_remove(struct platform_device *pdev)
return 0;
 }
 
+/*
+ * We assume the ADV7123 DAC is the "default" for historical reasons
+ * Information taken from the ADV7123 datasheet, revision D.
+ * NOTE: the ADV7123EP seems to have other timings and need a new timings
+ * set if used.
+ */
+static const struct drm_bridge_timings default_dac_timings = {
+   /* Timing specifications, datasheet page 7 */
+   .sampling_edge = true,
+   .setup_time_ps = 500,
+   .hold_time_ps = 1500,
+};
+
+/*
+ * Information taken from the THS8134, THS8134A, THS8134B datasheet named
+ * "SLVS205D", dated May 1990, revised March 2000.
+ */
+static const struct drm_bridge_timings ti_ths8134_dac_timings = {
+   /* From timing diagram, datasheet page 9 */
+   .sampling_edge = true,
+   /* From datasheet, page 12 */
+   .setup_time_ps = 3000,
+   /* I guess this means latched input */
+   .hold_time_ps = 0,
+};
+
+/*
+ * Information taken from the THS8135 datasheet named "SLAS343B", dated
+ * May 2001, revised April 2013.
+ */
+static const struct drm_bridge_timings ti_ths8135_dac_timings = {
+   /* From timing diagram, datasheet page 14 */
+   .sampling_edge = true,
+   /* From datasheet, page 16 */
+   .setup_time_ps = 2000,
+   .hold_time_ps = 500,
+};
+
 static const struct of_device_id dumb_vga_match[] = {
-   { .compatible = "dumb-vga-dac" },
-   { .compatible = "adi,adv7123" },
-   { .compatible = "ti,ths8135" },
+   {
+   .compatible = "dumb-vga-dac",
+   .data = _dac_timings,
+   },
+   {
+   .compatible = "adi,adv7123",
+   .data = _dac_timings,
+   },
+   {
+   .compatible = "ti,ths8135",
+   .data = _ths8135_dac_timings,
+   },
+   {
+   .compatible = "ti,ths8134",
+   .data = _ths8134_dac_timings,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, dumb_vga_match);
-- 
2.14.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH 4/4 v5] drm/pl111: Support handling bridge timings

[Linus Walleij]

If the bridge has a too strict setup time for the incoming
signals, we may not be fast enough and then we need to
compensate by outputting the signal on the inverse clock
edge so it is for sure stable when the bridge samples it.

Since bridges in difference to panels does not expose their
connectors, make the connector optional in the display
setup code.

Signed-off-by: Linus Walleij 
---
ChangeLog v4->v5:
- Use the new bridge timings setup method.
---
 drivers/gpu/drm/pl111/Kconfig |  1 +
 drivers/gpu/drm/pl111/pl111_display.c | 35 +++
 drivers/gpu/drm/pl111/pl111_drv.c | 20 +++-
 3 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index e5e2abd66491..82cb3e60ddc8 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -8,6 +8,7 @@ config DRM_PL111
select DRM_GEM_CMA_HELPER
select DRM_BRIDGE
select DRM_PANEL_BRIDGE
+   select DRM_DUMB_VGA_DAC
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
  Choose this option for DRM support for the PL111 CLCD controller.
diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 06c4bf756b69..7fe4040aea46 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -94,6 +94,7 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
const struct drm_display_mode *mode = >mode;
struct drm_framebuffer *fb = plane->state->fb;
struct drm_connector *connector = priv->connector;
+   struct drm_bridge *bridge = priv->bridge;
u32 cntl;
u32 ppl, hsw, hfp, hbp;
u32 lpp, vsw, vfp, vbp;
@@ -143,11 +144,37 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
tim2 |= TIM2_IVS;
 
-   if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
-   tim2 |= TIM2_IOE;
+   if (connector) {
+   if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
+   tim2 |= TIM2_IOE;
 
-   if (connector->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
-   tim2 |= TIM2_IPC;
+   if (connector->display_info.bus_flags &
+   DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+   tim2 |= TIM2_IPC;
+   }
+
+   if (bridge) {
+   const struct drm_bridge_timings *btimings = bridge->timings;
+
+   /*
+* Here is when things get really fun. Sometimes the bridge
+* timings are such that the signal out from PL11x is not
+* stable before the receiving bridge (such as a dumb VGA DAC
+* or similar) samples it. If that happens, we compensate by
+* the only method we have: output the data on the opposite
+* edge of the clock so it is for sure stable when it gets
+* sampled.
+*
+* The PL111 manual does not contain proper timining diagrams
+* or data for these details, but we know from experiments
+* that the setup time is more than 3000 picoseconds (3 ns).
+* If we have a bridge that requires the signal to be stable
+* earlier than 3000 ps before the clock pulse, we have to
+* output the data on the opposite edge to avoid flicker.
+*/
+   if (btimings && btimings->setup_time_ps >= 3000)
+   tim2 ^= TIM2_IPC;
+   }
 
tim2 |= cpl << 16;
writel(tim2, priv->regs + CLCD_TIM2);
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 201d57d5cb54..101a9c7db6ff 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -107,11 +107,17 @@ static int pl111_modeset_init(struct drm_device *dev)
ret = PTR_ERR(bridge);
goto out_config;
}
-   /*
-* TODO: when we are using a different bridge than a panel
-* (such as a dumb VGA connector) we need to devise a different
-* method to get the connector out of the bridge.
-*/
+   } else if (bridge) {
+   dev_info(dev->dev, "Using non-panel bridge\n");
+   } else {
+   dev_err(dev->dev, "No bridge, exiting\n");
+   return -ENODEV;
+   }
+
+   priv->bridge = bridge;
+   if (panel) {
+   priv->panel = panel;
+   priv->connector = panel->connector;
}
 
ret = pl111_display_init(dev);
@@ -125,10 +131,6 @@ static int pl111_modeset_init(struct drm_device *dev)
if (ret)
return ret;
 
-  

[PATCH 1/4 v5] drm/bridge: Add bindings for TI THS8134

[Linus Walleij]

This adds device tree bindings for the Texas Instruments
THS8134, THS8134A and THS8134B VGA DACs by extending and
renaming the existing bindings for THS8135.

These DACs are used for the VGA outputs on the ARM reference
designs such as Integrator, Versatile and RealView.

Cc: devicet...@vger.kernel.org
Cc: Bartosz Golaszewski 
Acked-by: Rob Herring 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v5:
- Dropped the "ti,ths813x" as it turns out we need precise info
  about the sub-variant anyways as they all very in timings.
- Refine the THS8134 variants, it turns out ths8134, ths8134a
  and ths8134b are three different variants of ths8134.
ChangeLog v1->v2:
- Introduce specific-to-general compatible string:
  compatible = "ti,ths8134a", "ti,ths813x";
  so drivers can handle the whole family the same way.
- Collected Rob's ACK.
---
 .../display/bridge/{ti,ths8135.txt => ti,ths813x.txt}   | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt => 
ti,ths813x.txt} (69%)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
similarity index 69%
rename from Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
rename to Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
index 6ec1a880ac18..49f155467f00 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
@@ -1,11 +1,16 @@
-THS8135 Video DAC
--
+THS8134 and THS8135 Video DAC
+-
 
-This is the binding for Texas Instruments THS8135 Video DAC bridge.
+This is the binding for Texas Instruments THS8134, THS8134A, THS8134B and
+THS8135 Video DAC bridge.
 
 Required properties:
 
-- compatible: Must be "ti,ths8135"
+- compatible: Must be one of
+  "ti,ths8134"
+  "ti,ths8134", "ti,ths8134a"
+  "ti,ths8134", "ti,ths8134b"
+  "ti,ths8135"
 
 Required nodes:
 
-- 
2.14.3

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

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[Christian König]

Am 15.12.2017 um 12:35 schrieb Thomas Hellstrom:

On 12/15/2017 10:53 AM, Christian König wrote:


Well this is more or less replicating what you are doing currently 
but instead of spreading the checks and locking state all over the 
code, both as local variables and parameters this is keeping it in a 
single place with correctness checks.


I don't see how that can be correct. 


In what sense? It should be doing *exactly* what you're doing now but 
use an abstraction. No more no less. But with correctness checks, and 
less of passing state around. Specifically what I'm referring to are 
things like the locking test this patch is proposing, the "locked" 
variable in ttm_mem_evict_first(), and the parameter special code in 
ttm_mem_cleanup_refs() that I think are hard to follow and error 
prone. Conditional locking like in ttm_mem_clenup_refs() also 
typically trip static lock balance checkers.


It looks like you just have a typo in your example code then 
"ctx->reserve_count++;" that should mean "bo->reserved++;", doesn't it? 
That makes the idea more clear.






As far as I can see it makes TTM responsible about locking again


No it doesn't. It's a helper. The only TTM state in my suggestion was 
the "bo::reserved"  debug variable, which could either be ommited or 
count the recursive reservation to aid making sure that all recursive 
reservations you do in TTM are undone in TTM.


Yes, but this bo->reserved counter is what makes me thing that this 
isn't a good idea at all.


We need to distinct between BOs which are reserved by the eviction code 
and which are already reserved anyway. Hiding that behind an extra layer 
makes things more error prone, not less.





and to be honest TTM is a bloody mess regarding this already.


Hmm. IMO strong unspecific wording like this in a design descussions 
should be avoided. It tends to take away focus from what's actually 
being dicussed by making either part feel bad.


I agree that this is strong wording, but unfortunately regarding locking 
TTM is one of the code bases where it really applies in my opinion.


Functions which are entered with locks held and then release and/or 
regrab them are really not fun to work with. Took us quite a while to 
get a grip on that and understand all the side effects a change could have.



And it's typically unproductive.


Yeah, agree on that trying to choose my wording more wisely in the future.

My intention in the long term is rather to remove logic from TTM and 
move it back into the drivers. The end result I have in mind is that 
TTM becomes a toolbox instead of the midlayer it is currently.


I'm in favour of that. But I don't think what I proposed is a step 
away from that direction. On the contrary.  I've attached a POC patch 
with the correctness checks stripped, not compile-tested. Much easier 
to follow if you ask me, but if you feel so strongly against it, never 
mind.


Exactly that's what I've meant with that this won't work. See you loose 
the extra check "!ctx->allow_reserved_eviction && 
list_empty(>ddestroy))" here and that one is really important for 
correct operation.


Regards,
Christian.



Thanks,
Thomas




Regards,
Christian. qq




I agree recursive locking is generally frowned upon, but you're 
already doing it, not by using recursive locks, but by passing 
locking state around which IMO is worse.


Collecting the state in a the operation_ctx will make that 
usage-pattern more obvious but will help make the code cleaner and 
less error prone.


/Thomas





Regards,
Christian.

Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom:

Roger and Chrisitian,

Correct me if I'm wrong, but It seems to me like a lot of the 
recent changes to ttm_bo.c are to allow recursive reservation 
object locking in the case of shared reservation objects, but only 
in certain functions and with special arguments so it doesn't look 
like recursive locking to the lockdep checker. Wouldn't it be a 
lot cleaner if we were to hide all this in a resurrected 
__ttm_bo_reserve something along the lines of


int __ttm_bo_reserve(struct ttm_bo *bo, struct ttm_operation_ctx 
*ctx) {

    if (ctx && ctx->resv == bo->resv) {
#ifdef CONFIG_LOCKDEP
    WARN_ON(bo->reserved);
lockdep_assert_held(>resv);
        ctx->reserve_count++;
bo->reserved = true;
#endif
        return0;
 } else {
    int ret = reservation_object_lock(bo->resv, NULL) ? 0:-EBUSY;

    if (ret)
            return ret;
#ifdef CONFIG_LOCKDEP
        WARN_ON(bo->reserved);
        bo->reserved = true;
#endif
        return 0;
}

And similar for tryreserve and unreserve? Perhaps with a 
ww_acquire_ctx included somewhere as well...


/Thomas




On 12/14/2017 09:10 AM, Roger He wrote:

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[Thomas Hellstrom]

On 12/15/2017 10:53 AM, Christian König wrote:


Well this is more or less replicating what you are doing currently 
but instead of spreading the checks and locking state all over the 
code, both as local variables and parameters this is keeping it in a 
single place with correctness checks.


I don't see how that can be correct. 


In what sense? It should be doing *exactly* what you're doing now but 
use an abstraction. No more no less. But with correctness checks, and 
less of passing state around. Specifically what I'm referring to are 
things like the locking test this patch is proposing, the "locked" 
variable in ttm_mem_evict_first(), and the parameter special code in 
ttm_mem_cleanup_refs() that I think are hard to follow and error prone. 
Conditional locking like in ttm_mem_clenup_refs() also typically trip 
static lock balance checkers.



As far as I can see it makes TTM responsible about locking again


No it doesn't. It's a helper. The only TTM state in my suggestion was 
the "bo::reserved"  debug variable, which could either be ommited or 
count the recursive reservation to aid making sure that all recursive 
reservations you do in TTM are undone in TTM.



and to be honest TTM is a bloody mess regarding this already.


Hmm. IMO strong unspecific wording like this in a design descussions 
should be avoided. It tends to take away focus from what's actually 
being dicussed by making either part feel bad. And it's typically 
unproductive.





My intention in the long term is rather to remove logic from TTM and 
move it back into the drivers. The end result I have in mind is that 
TTM becomes a toolbox instead of the midlayer it is currently.


I'm in favour of that. But I don't think what I proposed is a step away 
from that direction. On the contrary.  I've attached a POC patch with 
the correctness checks stripped, not compile-tested. Much easier to 
follow if you ask me, but if you feel so strongly against it, never mind.


Thanks,
Thomas




Regards,
Christian. qq




I agree recursive locking is generally frowned upon, but you're 
already doing it, not by using recursive locks, but by passing 
locking state around which IMO is worse.


Collecting the state in a the operation_ctx will make that 
usage-pattern more obvious but will help make the code cleaner and 
less error prone.


/Thomas





Regards,
Christian.

Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom:

Roger and Chrisitian,

Correct me if I'm wrong, but It seems to me like a lot of the 
recent changes to ttm_bo.c are to allow recursive reservation 
object locking in the case of shared reservation objects, but only 
in certain functions and with special arguments so it doesn't look 
like recursive locking to the lockdep checker. Wouldn't it be a lot 
cleaner if we were to hide all this in a resurrected 
__ttm_bo_reserve something along the lines of


int __ttm_bo_reserve(struct ttm_bo *bo, struct ttm_operation_ctx 
*ctx) {

    if (ctx && ctx->resv == bo->resv) {
#ifdef CONFIG_LOCKDEP
    WARN_ON(bo->reserved);
lockdep_assert_held(>resv);
        ctx->reserve_count++;
bo->reserved = true;
#endif
        return0;
 } else {
    int ret = reservation_object_lock(bo->resv, NULL) ? 0:-EBUSY;

    if (ret)
            return ret;
#ifdef CONFIG_LOCKDEP
        WARN_ON(bo->reserved);
        bo->reserved = true;
#endif
        return 0;
}

And similar for tryreserve and unreserve? Perhaps with a 
ww_acquire_ctx included somewhere as well...


/Thomas




On 12/14/2017 09:10 AM, Roger He wrote:

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
b/drivers/gpu/drm/ttm/ttm_bo.c

index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,

  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
    static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   struct reservation_object *resv,
 uint32_t mem_type,
 const struct ttm_place *place,
 struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct 
ttm_bo_device *bdev,

  spin_lock(>lru_lock);
  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  list_for_each_entry(bo, >lru[i], lru) {
-    if (bo->resv == resv) {
-    if (list_empty(>ddestroy))
+    if (bo->resv == ctx->resv) {
+    if (!ctx->allow_reserved_eviction &&
+    list_empty(>ddestroy))
  continue;
  } else {
  locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,

  return ret;
  if (mem->mm_node)

[PATCH] drm/amd/display: remove redundant null check of array 'data'

[Colin King]

From: Colin Ian King 

The null check on aconnector->base.edid_blob_ptr->data is redundant
since data is an array and can never be null.  Remove it.

Detected by CoverityScan, CID#1460369 ("Array compared against 0")

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ccbf10e3bbb6..c388778dbba3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2725,8 +2725,7 @@ static void create_eml_sink(struct amdgpu_dm_connector 
*aconnector)
};
struct edid *edid;
 
-   if (!aconnector->base.edid_blob_ptr ||
-   !aconnector->base.edid_blob_ptr->data) {
+   if (!aconnector->base.edid_blob_ptr) {
DRM_ERROR("No EDID firmware found on connector: %s ,forcing to 
OFF!\n",
aconnector->base.name);
 
-- 
2.14.1

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

[PATCH libdrm] etnaviv: fix BO cache to properly work with different flags

[Lucas Stach]

Currently if the oldest BO in a bucket has different flags than what we
look for we'll miss the cache.Fix this by iterating over the cached BOs
until we find the oldest one with matching flags. This improves the hit
ratio for some of the buckets.

Signed-off-by: Lucas Stach 
---
 etnaviv/etnaviv_bo_cache.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/etnaviv/etnaviv_bo_cache.c b/etnaviv/etnaviv_bo_cache.c
index 8924651f0cd8..6208230dc81a 100644
--- a/etnaviv/etnaviv_bo_cache.c
+++ b/etnaviv/etnaviv_bo_cache.c
@@ -124,20 +124,32 @@ static int is_idle(struct etna_bo *bo)
 
 static struct etna_bo *find_in_bucket(struct etna_bo_bucket *bucket, uint32_t 
flags)
 {
-   struct etna_bo *bo = NULL;
+   struct etna_bo *bo = NULL, *tmp;
 
pthread_mutex_lock(_lock);
-   while (!LIST_IS_EMPTY(>list)) {
-   bo = LIST_ENTRY(struct etna_bo, bucket->list.next, list);
 
-   if (bo->flags == flags && is_idle(bo)) {
-   list_del(>list);
-   break;
+   if (LIST_IS_EMPTY(>list))
+   goto out_unlock;
+
+   LIST_FOR_EACH_ENTRY_SAFE(bo, tmp, >list, list) {
+   /* skip BOs with different flags */
+   if (bo->flags != flags)
+   continue;
+
+   /* check if the first BO with matching flags is idle */
+   if (is_idle(bo)) {
+   list_delinit(>list);
+   goto out_unlock;
}
 
-   bo = NULL;
+   /* If the oldest BO is still busy, don't try younger ones */
break;
}
+
+   /* There was no matching buffer found */
+   bo = NULL;
+
+out_unlock:
pthread_mutex_unlock(_lock);
 
return bo;
-- 
2.11.0

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

[Bug 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #6 from Michel Dänzer  ---
Hmm, maybe a separate DC patch is needed as well. Christian?

-- 
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 5/5] drm/doc: Move legacy kms helpers to the very end

[Daniel Vetter]

On Thu, Dec 14, 2017 at 09:11:01PM -0500, Alex Deucher wrote:
> On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter  wrote:
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 420025bd6a9b..cbba93483aec 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -263,10 +263,10 @@ Taken all together there's two consequences for the 
> > atomic design:
> >
> >  - An atomic update is assembled and validated as an entirely free-standing 
> > pile
> >of structures within the :c:type:`drm_atomic_state `
> > -  container. Again drivers can subclass that container for their own state
> > -  structure tracking needs. Only when a state is committed is it applied 
> > to the
> > -  driver and modeset objects. This way rolling back an update boils down to
> > -  releasing memory and unreferencing objects like framebuffers.
> > +  container. Driver private state structures are also tracked in the same
> > +  structure, see the next chapter.  Only when a state is committed is it 
> > applied
> 
> I think it would be clearer as:
> structure (see the next chapter).
> or
> structure; see the next chapter.
> 
> Either way:
> Reviewed-by: Alex Deucher 

Thanks for all the review from you and DK, all taken into account and
merged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] etnaviv: support performance monitor requests

[Lucas Stach]

Am Freitag, den 15.12.2017, 10:33 +0100 schrieb Lucas Stach:
> Am Freitag, den 15.12.2017, 08:43 +0100 schrieb Christian Gmeiner:
> > Add etna_cmd_stream_perf(..) to submit perform requests.
> > Userspace can submit pmrs via submit ioctl to sample perfmon
> > signals.
> > 
> > v3:
> >  - mark perfmon bos as RW
> > 
> > Signed-off-by: Christian Gmeiner 
> > ---
> 
> [...]
> 
> >  #endif /* ETNAVIV_DRMIF_H_ */
> > diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
> > index 7b289b61..e45d364c 100644
> > --- a/etnaviv/etnaviv_priv.h
> > +++ b/etnaviv/etnaviv_priv.h
> > @@ -140,6 +140,10 @@ struct etna_cmd_stream_priv {
> >     /* reloc's table: */
> >     struct drm_etnaviv_gem_submit_reloc *relocs;
> >     uint32_t nr_relocs, max_relocs;
> > +
> > +   /* perf's table: */
> > +   struct drm_etnaviv_gem_submit_pmr *pmrs;
> > +   uint32_t nr_pmrs, max_pmrs;
> 
> On v2 I commented that I don't see max_pmrs used anywhere. If it's
> unused please remove before pushing the patch.

... And I just saw your reply to my v2 review explaining this stuff. So
please disregard this comment.

> Since this is a nitpick, you have my
> 
> Reviewed-by: Lucas Stach 
> 
> Regards,
> Lucas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/9] v4l: vsp1: Print the correct blending unit name in debug messages

[Kieran Bingham]

Hi Laurent,

On 03/12/17 10:57, Laurent Pinchart wrote:
> The DRM pipelines can use either the BRU or the BRS for blending. Make
> sure the right name is used in debugging messages to avoid confusion.

This could likely tag along with the preceding [PATCH 1/9] on it's short cut to
mainline before the rest of the CRC series is reviewed.

> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index ac85942162c1..0fe541084f5c 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -400,8 +400,11 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   struct v4l2_subdev_selection sel;
>   struct v4l2_subdev_format format;
>   const struct v4l2_rect *crop;
> + const char *bru_name;
>   int ret;
>  
> + bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
> +
>   /*
>* Configure the format on the RPF sink pad and propagate it up to the
>* BRU sink pad.
> @@ -473,9 +476,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, format.pad);
> + format.format.code, bru_name, format.pad);
>  
>   sel.pad = bru_input;
>   sel.target = V4L2_SEL_TGT_COMPOSE;
> @@ -486,10 +489,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev,
> - "%s: set selection (%u,%u)/%ux%u on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
>   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> - sel.pad);
> + bru_name, sel.pad);
>  
>   return 0;
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] v4l: vsp1: Fix display stalls when requesting too many inputs

[Kieran Bingham]

Hi Laurent,

As this is a prevents hardware hangs, and is a distinct patch on it's own - I
feel it should be on an accelerated path to integration, and should be merged
separately from the rest of the CRC feature series.

On 03/12/17 10:57, Laurent Pinchart wrote:
> Make sure we don't accept more inputs than the hardware can handle. This
> is a temporary fix to avoid display stall, we need to instead allocate
> the BRU or BRS to display pipelines dynamically based on the number of
> planes they each use.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 7ce69f23f50a..ac85942162c1 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -530,6 +530,15 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   struct vsp1_rwpf *rpf = vsp1->rpf[i];
>   unsigned int j;
>  
> + /*
> +  * Make sure we don't accept more inputs than the hardware can
> +  * handle. This is a temporary fix to avoid display stall, we
> +  * need to instead allocate the BRU or BRS to display pipelines
> +  * dynamically based on the number of planes they each use.
> +  */
> + if (pipe->num_inputs >= pipe->bru->source_pad)
> + pipe->inputs[i] = NULL;
> +
>   if (!pipe->inputs[i])
>   continue;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

--- Comment #5 from Kai-Heng Feng  ---
Created attachment 136191
  --> https://bugs.freedesktop.org/attachment.cgi?id=136191=edit
Garbled display.

-- 
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 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

--- Comment #4 from Kai-Heng Feng  ---
(In reply to Michel Dänzer from comment #3)
> The fundamental issue here is that only 32 MB of memory are reserved as VRAM
> for the GPU.
> 
> https://patchwork.freedesktop.org/patch/192451/ should fix it (with DC
> enabled).

I applied both [1] and [2], also enabled DC for it, now the Unity Desktop is
garbled.
Unity Greeter in LightDM is fine though.

[1] https://patchwork.freedesktop.org/patch/192451/
[2] https://patchwork.freedesktop.org/patch/192450/

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[Christian König]

Am 15.12.2017 um 10:38 schrieb Thomas Hellstrom:

On 12/15/2017 10:13 AM, Christian König wrote:

Hi Thomas,

actually I was very happy to get rid of that stuff.


Yes, wrappers that don't do anything don't make much sense, but this 
is a different story.


I was not talking about the wrappers, but rather about having the 
locking code in TTM.






In the long run I indeed wanted to replace ctx->resv with the 
ww_acquire_ctx to enable eviction of even more things, but that is a 
different story.


Recursive locking is usually something we should try to avoid.


Well this is more or less replicating what you are doing currently but 
instead of spreading the checks and locking state all over the code, 
both as local variables and parameters this is keeping it in a single 
place with correctness checks.


I don't see how that can be correct. As far as I can see it makes TTM 
responsible about locking again and to be honest TTM is a bloody mess 
regarding this already.


My intention in the long term is rather to remove logic from TTM and 
move it back into the drivers. The end result I have in mind is that TTM 
becomes a toolbox instead of the midlayer it is currently.


Regards,
Christian.




I agree recursive locking is generally frowned upon, but you're 
already doing it, not by using recursive locks, but by passing locking 
state around which IMO is worse.


Collecting the state in a the operation_ctx will make that 
usage-pattern more obvious but will help make the code cleaner and 
less error prone.


/Thomas





Regards,
Christian.

Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom:

Roger and Chrisitian,

Correct me if I'm wrong, but It seems to me like a lot of the recent 
changes to ttm_bo.c are to allow recursive reservation object 
locking in the case of shared reservation objects, but only in 
certain functions and with special arguments so it doesn't look like 
recursive locking to the lockdep checker. Wouldn't it be a lot 
cleaner if we were to hide all this in a resurrected 
__ttm_bo_reserve something along the lines of


int __ttm_bo_reserve(struct ttm_bo *bo, struct ttm_operation_ctx 
*ctx) {

    if (ctx && ctx->resv == bo->resv) {
#ifdef CONFIG_LOCKDEP
    WARN_ON(bo->reserved);
lockdep_assert_held(>resv);
        ctx->reserve_count++;
bo->reserved = true;
#endif
        return0;
 } else {
    int ret = reservation_object_lock(bo->resv, NULL) ? 0:-EBUSY;

    if (ret)
            return ret;
#ifdef CONFIG_LOCKDEP
        WARN_ON(bo->reserved);
        bo->reserved = true;
#endif
        return 0;
}

And similar for tryreserve and unreserve? Perhaps with a 
ww_acquire_ctx included somewhere as well...


/Thomas




On 12/14/2017 09:10 AM, Roger He wrote:

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
b/drivers/gpu/drm/ttm/ttm_bo.c

index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,

  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
    static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   struct reservation_object *resv,
 uint32_t mem_type,
 const struct ttm_place *place,
 struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct 
ttm_bo_device *bdev,

  spin_lock(>lru_lock);
  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  list_for_each_entry(bo, >lru[i], lru) {
-    if (bo->resv == resv) {
-    if (list_empty(>ddestroy))
+    if (bo->resv == ctx->resv) {
+    if (!ctx->allow_reserved_eviction &&
+    list_empty(>ddestroy))
  continue;
  } else {
  locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,

  return ret;
  if (mem->mm_node)
  break;
-    ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, 
ctx);

+    ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
  if (unlikely(ret != 0))
  return ret;
  } while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct 
ttm_bo_device *bdev,

  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  while (!list_empty(>lru[i])) {
  spin_unlock(>lru_lock);
-    ret = ttm_mem_evict_first(bdev, NULL, mem_type,
-  NULL, );
+    ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
  if (ret)
  return ret;
  spin_lock(>lru_lock);





___
amd-gfx mailing list
amd-...@lists.freedesktop.org

[PATCH 4.4 025/105] drm: extra printk() wrapper macros

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Gordon 

commit 30b0da8d556e65ff935a56cd82c05ba0516d3e4a upstream.

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon 
Reviewed-by: Eric Engestrom 
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie 
Signed-off-by: Tvrtko Ursulin 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 

---
 include/drm/drmP.h |   26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -158,6 +158,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -183,12 +203,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *


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

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[Thomas Hellstrom]

On 12/15/2017 10:13 AM, Christian König wrote:

Hi Thomas,

actually I was very happy to get rid of that stuff.


Yes, wrappers that don't do anything don't make much sense, but this is 
a different story.




In the long run I indeed wanted to replace ctx->resv with the 
ww_acquire_ctx to enable eviction of even more things, but that is a 
different story.


Recursive locking is usually something we should try to avoid.


Well this is more or less replicating what you are doing currently but 
instead of spreading the checks and locking state all over the code, 
both as local variables and parameters this is keeping it in a single 
place with correctness checks.


I agree recursive locking is generally frowned upon, but you're already 
doing it, not by using recursive locks, but by passing locking state 
around which IMO is worse.


Collecting the state in a the operation_ctx will make that usage-pattern 
more obvious but will help make the code cleaner and less error prone.


/Thomas





Regards,
Christian.

Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom:

Roger and Chrisitian,

Correct me if I'm wrong, but It seems to me like a lot of the recent 
changes to ttm_bo.c are to allow recursive reservation object locking 
in the case of shared reservation objects, but only in certain 
functions and with special arguments so it doesn't look like 
recursive locking to the lockdep checker. Wouldn't it be a lot 
cleaner if we were to hide all this in a resurrected __ttm_bo_reserve 
something along the lines of


int __ttm_bo_reserve(struct ttm_bo *bo, struct ttm_operation_ctx *ctx) {
    if (ctx && ctx->resv == bo->resv) {
#ifdef CONFIG_LOCKDEP
    WARN_ON(bo->reserved);
lockdep_assert_held(>resv);
        ctx->reserve_count++;
bo->reserved = true;
#endif
        return0;
 } else {
    int ret = reservation_object_lock(bo->resv, NULL) ? 0:-EBUSY;

    if (ret)
            return ret;
#ifdef CONFIG_LOCKDEP
        WARN_ON(bo->reserved);
        bo->reserved = true;
#endif
        return 0;
}

And similar for tryreserve and unreserve? Perhaps with a 
ww_acquire_ctx included somewhere as well...


/Thomas




On 12/14/2017 09:10 AM, Roger He wrote:

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
b/drivers/gpu/drm/ttm/ttm_bo.c

index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,

  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
    static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   struct reservation_object *resv,
 uint32_t mem_type,
 const struct ttm_place *place,
 struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct 
ttm_bo_device *bdev,

  spin_lock(>lru_lock);
  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  list_for_each_entry(bo, >lru[i], lru) {
-    if (bo->resv == resv) {
-    if (list_empty(>ddestroy))
+    if (bo->resv == ctx->resv) {
+    if (!ctx->allow_reserved_eviction &&
+    list_empty(>ddestroy))
  continue;
  } else {
  locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,

  return ret;
  if (mem->mm_node)
  break;
-    ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, 
ctx);

+    ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
  if (unlikely(ret != 0))
  return ret;
  } while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct 
ttm_bo_device *bdev,

  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  while (!list_empty(>lru[i])) {
  spin_unlock(>lru_lock);
-    ret = ttm_mem_evict_first(bdev, NULL, mem_type,
-  NULL, );
+    ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
  if (ret)
  return ret;
  spin_lock(>lru_lock);





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

Re: [PATCH v3 3/3] etnaviv: support performance monitor requests

[Lucas Stach]

Am Freitag, den 15.12.2017, 08:43 +0100 schrieb Christian Gmeiner:
> Add etna_cmd_stream_perf(..) to submit perform requests.
> Userspace can submit pmrs via submit ioctl to sample perfmon
> signals.
> 
> v3:
>  - mark perfmon bos as RW
> 
> Signed-off-by: Christian Gmeiner 
> ---

[...]

>  #endif /* ETNAVIV_DRMIF_H_ */
> diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
> index 7b289b61..e45d364c 100644
> --- a/etnaviv/etnaviv_priv.h
> +++ b/etnaviv/etnaviv_priv.h
> @@ -140,6 +140,10 @@ struct etna_cmd_stream_priv {
>   /* reloc's table: */
>   struct drm_etnaviv_gem_submit_reloc *relocs;
>   uint32_t nr_relocs, max_relocs;
> +
> + /* perf's table: */
> + struct drm_etnaviv_gem_submit_pmr *pmrs;
> + uint32_t nr_pmrs, max_pmrs;

On v2 I commented that I don't see max_pmrs used anywhere. If it's
unused please remove before pushing the patch.

Since this is a nitpick, you have my

Reviewed-by: Lucas Stach 

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

[Bug 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
The fundamental issue here is that only 32 MB of memory are reserved as VRAM
for the GPU.

https://patchwork.freedesktop.org/patch/192451/ should fix it (with DC
enabled).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[Christian König]

Am 15.12.2017 um 07:24 schrieb Thomas Hellstrom:

Hi.

On 12/14/2017 09:10 AM, Roger He wrote:

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,

  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
    static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   struct reservation_object *resv,
 uint32_t mem_type,
 const struct ttm_place *place,
 struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct 
ttm_bo_device *bdev,

  spin_lock(>lru_lock);
  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  list_for_each_entry(bo, >lru[i], lru) {
-    if (bo->resv == resv) {
-    if (list_empty(>ddestroy))
+    if (bo->resv == ctx->resv) {
+    if (!ctx->allow_reserved_eviction &&
+    list_empty(>ddestroy))
  continue;


It looks to me like a value of locked==true could leak through from a 
previous loop iteration here, so that locked ends up to be true if 
(bo->resv == resv  && ctx->allow_reserved_eviction), even if no 
locking was taking place. Perhaps-re-initialize locked to false on 
each loop iteration?


Yeah, that is correct. Roger had a patch for this as prerequisite for 
this one.


No idea why this change isn't obvious in this one.

Christian.



/Thomas


  } else {
  locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,

  return ret;
  if (mem->mm_node)
  break;
-    ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, 
ctx);

+    ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
  if (unlikely(ret != 0))
  return ret;
  } while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct 
ttm_bo_device *bdev,

  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  while (!list_empty(>lru[i])) {
  spin_unlock(>lru_lock);
-    ret = ttm_mem_evict_first(bdev, NULL, mem_type,
-  NULL, );
+    ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
  if (ret)
  return ret;
  spin_lock(>lru_lock);



___
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

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com,
   ||jordan.laz...@amd.com

--- Comment #2 from Michel Dänzer  ---
The problem in the original report was fixed by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a072c5f896beba806b4b867d478e1b90f94ba29b
.

Comment 1 looks like a new issue in DC. Looks like this might be related to the
core DRM code now only initializing fbdev compatibility when a display
connection is detected, like the change above.

Sverd, until the latter is fixed, maybe you can try if amdgpu.dc=0 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

RE: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[He, Roger]

-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org] 
Sent: Friday, December 15, 2017 2:25 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

Hi.

On 12/14/2017 09:10 AM, Roger He wrote:
> Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
>   1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> b/drivers/gpu/drm/ttm/ttm_bo.c index 098b22e..ba5b486 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
> *bo,
>   EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>   
>   static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> -struct reservation_object *resv,
>  uint32_t mem_type,
>  const struct ttm_place *place,
>  struct ttm_operation_ctx *ctx) @@ -722,8 +721,9 
> @@ static 
> int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>   spin_lock(>lru_lock);
>   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>   list_for_each_entry(bo, >lru[i], lru) {
> - if (bo->resv == resv) {
> - if (list_empty(>ddestroy))
> + if (bo->resv == ctx->resv) {
> + if (!ctx->allow_reserved_eviction &&
> + list_empty(>ddestroy))
>   continue;

It looks to me like a value of locked==true could leak through from a 
previous loop iteration here, so that locked ends up to betrue if 
(bo->resv == resv  && ctx->allow_reserved_eviction), even if no locking was 
taking place. Perhaps-re-initialize locked to   false on each loop 
iteration?

At  the beginning, I also have this concern about incorrect using of locked. 
So, add patch a few days ago.

init locked again to prevent incorrect unlock
is it help?


Thanks
Roger(Hongbo.He)

/Thomas

>   } else {
>   locked = reservation_object_trylock(bo->resv);
> @@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct 
> ttm_buffer_object *bo,
>   return ret;
>   if (mem->mm_node)
>   break;
> - ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, ctx);
> + ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
>   if (unlikely(ret != 0))
>   return ret;
>   } while (1);
> @@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
> *bdev,
>   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>   while (!list_empty(>lru[i])) {
>   spin_unlock(>lru_lock);
> - ret = ttm_mem_evict_first(bdev, NULL, mem_type,
> -   NULL, );
> + ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
>   if (ret)
>   return ret;
>   spin_lock(>lru_lock);


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

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

[Christian König]

Hi Thomas,

actually I was very happy to get rid of that stuff.

In the long run I indeed wanted to replace ctx->resv with the 
ww_acquire_ctx to enable eviction of even more things, but that is a 
different story.


Recursive locking is usually something we should try to avoid.

Regards,
Christian.

Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom:

Roger and Chrisitian,

Correct me if I'm wrong, but It seems to me like a lot of the recent 
changes to ttm_bo.c are to allow recursive reservation object locking 
in the case of shared reservation objects, but only in certain 
functions and with special arguments so it doesn't look like recursive 
locking to the lockdep checker.  Wouldn't it be a lot cleaner if we 
were to hide all this in a resurrected __ttm_bo_reserve something 
along the lines of


int __ttm_bo_reserve(struct ttm_bo *bo, struct ttm_operation_ctx *ctx) {
    if (ctx && ctx->resv == bo->resv) {
#ifdef CONFIG_LOCKDEP
    WARN_ON(bo->reserved);
lockdep_assert_held(>resv);
        ctx->reserve_count++;
bo->reserved = true;
#endif
        return0;
 } else {
    int ret = reservation_object_lock(bo->resv, NULL) ? 0:-EBUSY;

    if (ret)
            return ret;
#ifdef CONFIG_LOCKDEP
        WARN_ON(bo->reserved);
        bo->reserved = true;
#endif
        return 0;
}

And similar for tryreserve and unreserve? Perhaps with a 
ww_acquire_ctx included somewhere as well...


/Thomas




On 12/14/2017 09:10 AM, Roger He wrote:

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,

  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
    static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   struct reservation_object *resv,
 uint32_t mem_type,
 const struct ttm_place *place,
 struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct 
ttm_bo_device *bdev,

  spin_lock(>lru_lock);
  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  list_for_each_entry(bo, >lru[i], lru) {
-    if (bo->resv == resv) {
-    if (list_empty(>ddestroy))
+    if (bo->resv == ctx->resv) {
+    if (!ctx->allow_reserved_eviction &&
+    list_empty(>ddestroy))
  continue;
  } else {
  locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,

  return ret;
  if (mem->mm_node)
  break;
-    ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, 
ctx);

+    ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
  if (unlikely(ret != 0))
  return ret;
  } while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct 
ttm_bo_device *bdev,

  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
  while (!list_empty(>lru[i])) {
  spin_unlock(>lru_lock);
-    ret = ttm_mem_evict_first(bdev, NULL, mem_type,
-  NULL, );
+    ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
  if (ret)
  return ret;
  spin_lock(>lru_lock);





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

[Bug 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #15 from Charly  ---
Hi Andrew. X works all the time.

-- 
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 v3 2/2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Geert Uytterhoeven]

Hi Morimoto-san,

On Fri, Dec 15, 2017 at 9:12 AM, Kuninori Morimoto
 wrote:
>> > From: Kuninori Morimoto 
>> > In general, PLL has VCO (= Voltage controlled oscillator),
>> > one of the very important electronic feature called as "jitter"
>> > is related to this VCO.
>> > In academic generalism, VCO should be maximum to be more small jitter.
>> > In high frequency clock, jitter will be large impact.
>> > Thus, selecting Hi VCO is general theory.
>>
>> Thanks for your patch!
>>
>> > One note here is that it should be 2000 < fvco < 4096MHz
>>
>> 2000 Hz? (else it could be misinterpreted that MHz applies to both values).
>
> Laurent had asked same question ;)
> But, yes, it is 2000 Hz

I've seen his question, that's why I think you should make it unambiguous.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

Hi Laurent, David

These are v3 of DPLLCR patch for rcar-du.
[1/2] is added

Kuninori Morimoto (2):
  drm: rcar-du: use 1000 to avoid misunderstanding in rcar_du_dpll_divider()
  drm: rcar-du: calculate DPLLCR to be more small jitter

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 60 +++---
 1 file changed, 55 insertions(+), 5 deletions(-)

-- 
1.9.1

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

[PATCH v3 1/2] drm: rcar-du: use 1000 to avoid misunderstanding in rcar_du_dpll_divider()

[Kuninori Morimoto]

From: Kuninori Morimoto 

It is difficult to understand its scale if number has many 0s.
This patch uses "* 1000" to avoid it in rcar_du_dpll_divider().

Signed-off-by: Kuninori Morimoto 
---
v2 -> v3

 - new patch

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 5685d5a..6820461f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -132,7 +132,7 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc *rcrtc,
 
output = input * (n + 1) / (m + 1)
   / (fdpll + 1);
-   if (output >= 4)
+   if (output >= 400 * 1000 * 1000)
continue;
 
diff = abs((long)output - (long)target);
-- 
1.9.1

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

[PATCH v3 2/2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

From: Kuninori Morimoto 

In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be large impact.
Thus, selecting Hi VCO is general theory.

   fin fvcofout  fclkout
in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out
 +-> |  | |
 ||
 +-[1/N]<-+

fclkout = fvco / P / FDPLL -- (1)

In PD, it will loop until fin/M = fvco/P/N

fvco = fin * P *  N / M -- (2)

(1) + (2) indicates

fclkout = fin * N / M / FDPLL

In this device, N = (n + 1), M = (m + 1), P = 2, FDPLL = (fdpll + 1).

fclkout = fin * (n + 1) / (m + 1) / (fdpll + 1)

This is the datasheet formula.
One note here is that it should be 2000 < fvco < 4096MHz
To be smaller jitter, fvco should be maximum,
in other words, N as large as possible, M as small as possible driver
should select. Here, basically M=1.
This patch do it.

Reported-by: HIROSHI INOSE 
Signed-off-by: Kuninori Morimoto 
---
v2 -> v3

 - uses "* 1000" for number
 - uses "xx000U" for number
 - uses finnm to avoid duplicate calculation

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 58 +++---
 1 file changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 6820461f..bb5ead6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -125,13 +125,63 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc 
*rcrtc,
unsigned int m;
unsigned int n;
 
-   for (n = 39; n < 120; n++) {
-   for (m = 0; m < 4; m++) {
+   /*
+*   fin fvcofout   fclkout
+* in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> 
out
+*  +-> |  | |
+*  ||
+*  +-[1/N]<-+
+*
+*  fclkout = fvco / P / FDPLL -- (1)
+*
+* fin/M = fvco/P/N
+*
+*  fvco = fin * P *  N / M -- (2)
+*
+* (1) + (2) indicates
+*
+*  fclkout = fin * N / M / FDPLL
+*
+* NOTES
+*  N   : (n + 1)
+*  M   : (m + 1)
+*  FDPLL   : (fdpll + 1)
+*  P   : 2
+*  2000 < fvco < 4096Mhz
+*
+* To be small jitter,
+* N : as large as possible
+* M : as small as possible
+*/
+   for (m = 0; m < 4; m++) {
+   for (n = 119; n > 38; n--) {
+   /*
+* NOTE:
+*
+* This code is assuming "used" from 64bit CPU only,
+* not from 32bit CPU. But both can compile correctly
+*/
+
+   /*
+*  fvco= fin * P *  N / M
+*  fclkout = fin  * N / M / FDPLL
+*
+* To avoid duplicate calculation, let's use below
+*
+*  finnm   = fin * N / M
+*  fvco= finnm * P
+*  fclkout = finnm / FDPLL
+*/
+   unsigned long finnm = input * (n + 1) / (m + 1);
+   unsigned long fvco  = finnm * 2;
+
+   if (fvco < 2000 || fvco > 4096 * 1000 * 1000U)
+   continue;
+
for (fdpll = 1; fdpll < 32; fdpll++) {
unsigned long output;
 
-   output = input * (n + 1) / (m + 1)
-  / (fdpll + 1);
+   output = finnm / (fdpll + 1);
if (output >= 400 * 1000 * 1000)
continue;
 
-- 
1.9.1

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

Re: [PATCH v3 2/2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

Hi Geert

> > From: Kuninori Morimoto 
> > In general, PLL has VCO (= Voltage controlled oscillator),
> > one of the very important electronic feature called as "jitter"
> > is related to this VCO.
> > In academic generalism, VCO should be maximum to be more small jitter.
> > In high frequency clock, jitter will be large impact.
> > Thus, selecting Hi VCO is general theory.
> 
> Thanks for your patch!
> 
> > One note here is that it should be 2000 < fvco < 4096MHz
> 
> 2000 Hz? (else it could be misinterpreted that MHz applies to both values).

Laurent had asked same question ;)
But, yes, it is 2000 Hz

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

[PATCH v3 3/3] etnaviv: support performance monitor requests

[Christian Gmeiner]

Add etna_cmd_stream_perf(..) to submit perform requests.
Userspace can submit pmrs via submit ioctl to sample perfmon
signals.

v3:
 - mark perfmon bos as RW

Signed-off-by: Christian Gmeiner 
---
 etnaviv/etnaviv-symbol-check |  1 +
 etnaviv/etnaviv_cmd_stream.c | 20 
 etnaviv/etnaviv_drmif.h  | 12 
 etnaviv/etnaviv_priv.h   |  4 
 4 files changed, 37 insertions(+)

diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index bd95b459..bc509615 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -41,6 +41,7 @@ etna_cmd_stream_timestamp
 etna_cmd_stream_flush
 etna_cmd_stream_flush2
 etna_cmd_stream_finish
+etna_cmd_stream_perf
 etna_cmd_stream_reloc
 etna_perfmon_create
 etna_perfmon_del
diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
index 8d0e8135..e8c58cd5 100644
--- a/etnaviv/etnaviv_cmd_stream.c
+++ b/etnaviv/etnaviv_cmd_stream.c
@@ -105,6 +105,7 @@ void etna_cmd_stream_del(struct etna_cmd_stream *stream)
 
free(stream->buffer);
free(priv->submit.relocs);
+   free(priv->submit.pmrs);
free(priv);
 }
 
@@ -115,6 +116,7 @@ static void reset_buffer(struct etna_cmd_stream *stream)
stream->offset = 0;
priv->submit.nr_bos = 0;
priv->submit.nr_relocs = 0;
+   priv->submit.nr_pmrs = 0;
priv->nr_bos = 0;
 
if (priv->reset_notify)
@@ -191,6 +193,8 @@ static void flush(struct etna_cmd_stream *stream, int 
in_fence_fd,
.nr_bos = priv->submit.nr_bos,
.relocs = VOID2U64(priv->submit.relocs),
.nr_relocs = priv->submit.nr_relocs,
+   .pmrs = VOID2U64(priv->submit.pmrs),
+   .nr_pmrs = priv->submit.nr_pmrs,
.stream = VOID2U64(stream->buffer),
.stream_size = stream->offset * 4, /* in bytes */
};
@@ -260,3 +264,19 @@ void etna_cmd_stream_reloc(struct etna_cmd_stream *stream, 
const struct etna_rel
 
etna_cmd_stream_emit(stream, addr);
 }
+
+void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const struct 
etna_perf *p)
+{
+   struct etna_cmd_stream_priv *priv = etna_cmd_stream_priv(stream);
+   struct drm_etnaviv_gem_submit_pmr *pmr;
+   uint32_t idx = APPEND(>submit, pmrs);
+
+   pmr = >submit.pmrs[idx];
+
+   pmr->flags = p->flags;
+   pmr->sequence = p->sequence;
+   pmr->read_offset = p->offset;
+   pmr->read_idx = bo2idx(stream, p->bo, ETNA_SUBMIT_BO_READ | 
ETNA_SUBMIT_BO_WRITE);
+   pmr->domain = p->signal->domain->id;
+   pmr->signal = p->signal->signal;
+}
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 949b9b62..5a6bef8d 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -201,4 +201,16 @@ void etna_perfmon_del(struct etna_perfmon *perfmon);
 struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct etna_perfmon 
*pm, const char *name);
 struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct 
etna_perfmon_domain *dom, const char *name);
 
+struct etna_perf {
+#define ETNA_PM_PROCESS_PRE 0x0001
+#define ETNA_PM_PROCESS_POST0x0002
+   uint32_t flags;
+   uint32_t sequence;
+   struct etna_perfmon_signal *signal;
+   struct etna_bo *bo;
+   uint32_t offset;
+};
+
+void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const struct 
etna_perf *p);
+
 #endif /* ETNAVIV_DRMIF_H_ */
diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
index 7b289b61..e45d364c 100644
--- a/etnaviv/etnaviv_priv.h
+++ b/etnaviv/etnaviv_priv.h
@@ -140,6 +140,10 @@ struct etna_cmd_stream_priv {
/* reloc's table: */
struct drm_etnaviv_gem_submit_reloc *relocs;
uint32_t nr_relocs, max_relocs;
+
+   /* perf's table: */
+   struct drm_etnaviv_gem_submit_pmr *pmrs;
+   uint32_t nr_pmrs, max_pmrs;
} submit;
 
/* should have matching entries in submit.bos: */
-- 
2.14.3

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