Re: [bug report] drm/prime: replace NULL with error value in drm_prime_pages_to_sg

[Oleksandr Andrushchenko]

On 06/15/2018 06:22 AM, YoungJun Cho wrote:

Dear Dan,

Your mail flashes back to my memory 5 years ago.
Back then, I had cleaned up the exynos driver.

And the replacement IS_ERR was one of items.

IMHO it is still better to modify those two functions, 
drm_gem_cma_prime_get_sg_table and xen_drm_front_gem_get_sg_table.


Thank you.
Best regards YJ


On Thu, 14 Jun 2018, 23:42 Dan Carpenter, > wrote:


Hello YoungJun Cho,

The patch 7e3d88f9cce3: "drm/prime: replace NULL with error value in
drm_prime_pages_to_sg" from Jun 24, 2013, leads to the following
static checker warning:

        drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
        warn: 'sgt' can also be NULL

drivers/gpu/drm/drm_prime.c
   307          /*
   308           * two mappings with different directions for the
same attachment are
   309           * not allowed
   310           */
   311          if (WARN_ON(prime_attach->dir != DMA_NONE))
   312                  return ERR_PTR(-EBUSY);
   313
   314          sgt = obj->dev->driver->gem_prime_get_sg_table(obj);

The problematic functions here are
drm_gem_cma_prime_get_sg_table() and
xen_drm_front_gem_get_sg_table().  My preference would be to update
those functions to return error pointers, but I'm not familiar
with the
code or able to test it.


I believe it is safe to change the return value to error pointer:
the code below (which is the only caller of .gem_prime_get_sg_table
callback) does not check for NULL anyways

Dan, do you want me to send the patch for Xen or you prefer to post both
Xen and CMA helpers fix yourself?


But this static checker test seems pretty good so I'm likely to
publish
it soon and then this sort of bug will normally be caught quickly.

   315
   316          if (!IS_ERR(sgt)) {
   317                  if (!dma_map_sg_attrs(attach->dev,
sgt->sgl, sgt->nents, dir,
   318 DMA_ATTR_SKIP_CPU_SYNC)) {
   319                          sg_free_table(sgt);
   320                          kfree(sgt);
   321                          sgt = ERR_PTR(-ENOMEM);
   322                  } else {
   323                          prime_attach->sgt = sgt;
   324                          prime_attach->dir = dir;
   325                  }
   326          }
   327
   328          return sgt;

regards,
dan carpenter
___
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


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

[radeon-alex:drm-next-4.19-wip 121/126] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1943:57: sparse: incorrect type in assignment (different base types)

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.19-wip
head:   0198cd6030f1f4bddc2fceb47971bfcbaa616db5
commit: 30e85debc13f1b8aaac16906441ee66645db10ed [121/126] drm/amd/pp: Remove 
SAMU support in powerplay
reproduce:
# apt-get install sparse
git checkout 30e85debc13f1b8aaac16906441ee66645db10ed
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1225:9:got 
restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1226:9: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] CcPwrDynRm @@got ed int [unsigned] 
[usertype] CcPwrDynRm @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1226:9:
expected unsigned int [unsigned] [usertype] CcPwrDynRm
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1226:9:got 
restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1227:9: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] CcPwrDynRm1 @@got ed int [unsigned] 
[usertype] CcPwrDynRm1 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1227:9:
expected unsigned int [unsigned] [usertype] CcPwrDynRm1
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1227:9:got 
restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1236:48: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] MinMvdd @@got ed int [unsigned] 
[usertype] MinMvdd @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1236:48:
expected unsigned int [unsigned] [usertype] MinMvdd
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1236:48:
got restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1259:51: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] DllCntl @@got ed int [unsigned] 
[usertype] DllCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1259:51:
expected unsigned int [unsigned] [usertype] DllCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1259:51:
got restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1261:51: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] MclkPwrmgtCntl @@got ed int [unsigned] 
[usertype] MclkPwrmgtCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1261:51:
expected unsigned int [unsigned] [usertype] MclkPwrmgtCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1261:51:
got restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1263:51: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] MpllAdFuncCntl @@got ed int [unsigned] 
[usertype] MpllAdFuncCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1263:51:
expected unsigned int [unsigned] [usertype] MpllAdFuncCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1263:51:
got restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1265:51: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] MpllDqFuncCntl @@got ed int [unsigned] 
[usertype] MpllDqFuncCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1265:51:
expected unsigned int [unsigned] [usertype] MpllDqFuncCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1265:51:
got restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1267:51: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] MpllFuncCntl @@got ed int [unsigned] 
[usertype] MpllFuncCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1267:51:
expected unsigned int [unsigned] [usertype] MpllFuncCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1267:51:
got restricted __be32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1269:51: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned int [unsigned] [usertype] MpllFuncCntl_1 @@got ed int [unsigned] 
[usertype] MpllFuncCntl_1 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1269:51:
expected unsigned int [unsigned] [usertype] MpllFuncCntl_1
   

[Bug 200045] black screen on 'radeon' module probing

[bugzilla-daemon]

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

--- Comment #11 from Wolfram Sang (w...@the-dreams.de) ---
I have sent another patch, let's hope it really is this issue:

http://patchwork.ozlabs.org/patch/929798/

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

[git pull] drm amd fixes for 4.18-rc1

[Dave Airlie]

Hi Linus,

Just a single set of AMD fixes for stuff in -next for -rc1.

Thanks,
Dave.

drm-next-2018-06-15:
amd fixes for 4.18-rc1
The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5:

  Merge tag 'drm-intel-next-fixes-2018-06-08-2' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-06-09
06:34:51 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-06-15

for you to fetch changes up to daf0678c2036c918f01e4aa6035629d2debc2f30:

  Merge branch 'drm-next-4.18' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2018-06-15
11:32:29 +1000)


amd fixes for 4.18-rc1


Alex Deucher (2):
  drm/amdgpu/display: check if ppfuncs exists before using it
  Revert "drm/amdgpu: Add an ATPX quirk for hybrid laptop"

Charlene Liu (1):
  drm/amd/display: add register offset != 0 check.

Chunming Zhou (1):
  drm/amdgpu: gds bo must not be per-vm-bo

Colin Ian King (2):
  drm/amdgpu/df: fix potential array out-of-bounds read
  drm/amd/pp: initialize result to before or'ing in data

Dave Airlie (1):
  Merge branch 'drm-next-4.18' of
git://people.freedesktop.org/~agd5f/linux into drm-next

Deepak Sharma (2):
  drm/amdgpu: Use GTT for dumb buffer if sg display enabled (v2)
  drm/amdgpu: Add helper function to get buffer domain

Dmytro Laktyushkin (1):
  drm/amd/display: fix dscl_manual_ratio_init

Emily Deng (1):
  drm/amdgpu: To get gds, gws and oa from adev->gds (v2)

Eric Bernstein (2):
  drm/amd/display: DP component depth 16 bpc
  drm/amd/display: Set TMZ and DCC for secondary surface

Evan Quan (6):
  drm/amdgpu: correct SMU11 SYSPLL0 clock id values
  drm/amd/powerplay: bug fixs for getsmuclockinfo
  drm/amdgpu: typo fix for vega20 cg flags
  drm/amd/powerplay: fix wrong clock adjust sequence
  drm/amdgpu: fix parsing indirect register list v2
  drm/amd/powerplay: remove uncessary extra gfxoff control call

Feifei Xu (1):
  drm/gfx9: Update gc goldensetting for vega20.

Harry Wentland (2):
  drm/amd/display: Implement dm_pp_get_clock_levels_by_type_with_latency
  drm/amd/display: Fix wrong latency assignment for VEGA clock levels

Huang Rui (4):
  drm/amdgpu: fix the missed vcn fw version report
  drm/amdgpu: add checking for sos version
  drm/amdgpu: fix CG enabling hang with gfxoff enabled
  drm/amd/powerplay: fix missed hwmgr check warning before call
gfx_off_control handler

Junwei Zhang (1):
  drm/amdgpu: fix clear_all and replace handling in the VM (v2)

Kenneth Feng (1):
  drm/amd/powerplay: Set higher SCLK frequency than dpm7 in OD (v2)

Leo (Sunpeng) Li (2):
  drm/amd/display: Destroy connector state on reset
  drm/amd/display: Fix BUG_ON during CRTC atomic check update

Leo Liu (1):
  drm/amdgpu: remove unnecessary scheduler entity for VCN

Lyude Paul (1):
  drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()

Mikita Lipski (5):
  drm/amd/pp: Add cases for getting phys and disp clks for SMU10
  drm/amd/display: Do not limit color depth to 8bpc
  drm/amd/display: Release fake sink
  drm/amd/display: Do not program interrupt status on disabled crtc
  drm/amd/pp: Connect display_clock_voltage_request to a function pointer

Nayan Deshmukh (1):
  drm/scheduler: fix a corner case in dependency optimization

Nikola Cornij (2):
  drm/amd/display: Read DPCD link caps up to and including DP_ADAPTER_CAP
  drm/amd/display: Read DP_SINK_COUNT_ESI range on HPD for DP 1.4

Pratik Vishwakarma (1):
  drm/amd/display: Fix stale buffer object (bo) use

Rex Zhu (2):
  drm/amd/pp: Allow underclocking when od table is empty in vbios
  drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cards

Roman Li (2):
  drm/amd/display: replace msleep with udelay in fbc path
  drm/amd/display: check if audio clk enable is applicable

Shaoyun Liu (2):
  drm/amdgpu: Fix NULL pointer when load kfd driver with PP block
is disabled
  drm/amd/include: Update df 3.6 mask and shift definition

kbuild test robot (1):
  drm/amdgpu: vcn_v1_0_is_idle() can be static

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 18 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 38 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 15 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 52 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  6 +-
 

[DPU PATCH] drm/msm/dsi: configure VCO rate for 10nm PLL driver

[Abhinav Kumar]

Currenty the VCO rate in the 10nm PLL driver relies
on the parent rate which is not configured.

Configure the VCO rate to 19.2 Mhz as required by
the 10nm PLL driver.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index c4c37a7..fb485cb 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -39,6 +39,8 @@
 #define DSI_PIXEL_PLL_CLK  1
 #define NUM_PROVIDED_CLKS  2
 
+#define VCO_REF_CLK_RATE   1920
+
 struct dsi_pll_regs {
u32 pll_prop_gain_rate;
u32 pll_lockdet_rate;
@@ -316,7 +318,7 @@ static int dsi_pll_10nm_vco_set_rate(struct clk_hw *hw, 
unsigned long rate,
parent_rate);
 
pll_10nm->vco_current_rate = rate;
-   pll_10nm->vco_ref_clk_rate = parent_rate;
+   pll_10nm->vco_ref_clk_rate = VCO_REF_CLK_RATE;
 
dsi_pll_setup_config(pll_10nm);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the 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

Re: [bug report] drm/prime: replace NULL with error value in drm_prime_pages_to_sg

[YoungJun Cho]

Dear Dan,

Your mail flashes back to my memory 5 years ago.
Back then, I had cleaned up the exynos driver.

And the replacement IS_ERR was one of items.

IMHO it is still better to modify those two functions,
drm_gem_cma_prime_get_sg_table and xen_drm_front_gem_get_sg_table.

Thank you.
Best regards YJ


On Thu, 14 Jun 2018, 23:42 Dan Carpenter,  wrote:

> Hello YoungJun Cho,
>
> The patch 7e3d88f9cce3: "drm/prime: replace NULL with error value in
> drm_prime_pages_to_sg" from Jun 24, 2013, leads to the following
> static checker warning:
>
> drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
> warn: 'sgt' can also be NULL
>
> drivers/gpu/drm/drm_prime.c
>307  /*
>308   * two mappings with different directions for the same
> attachment are
>309   * not allowed
>310   */
>311  if (WARN_ON(prime_attach->dir != DMA_NONE))
>312  return ERR_PTR(-EBUSY);
>313
>314  sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
>
> The problematic functions here are drm_gem_cma_prime_get_sg_table() and
> xen_drm_front_gem_get_sg_table().  My preference would be to update
> those functions to return error pointers, but I'm not familiar with the
> code or able to test it.
>
> But this static checker test seems pretty good so I'm likely to publish
> it soon and then this sort of bug will normally be caught quickly.
>
>315
>316  if (!IS_ERR(sgt)) {
>317  if (!dma_map_sg_attrs(attach->dev, sgt->sgl,
> sgt->nents, dir,
>318DMA_ATTR_SKIP_CPU_SYNC)) {
>319  sg_free_table(sgt);
>320  kfree(sgt);
>321  sgt = ERR_PTR(-ENOMEM);
>322  } else {
>323  prime_attach->sgt = sgt;
>324  prime_attach->dir = dir;
>325  }
>326  }
>327
>328  return sgt;
>
> regards,
> dan carpenter
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7] vulkan: Add VK_EXT_display_control and VK_EXT_display_surface_counter

[Keith Packard]

Here's a couple of reasonably straightforward extensions implemented
for both anv and radv drivers.

VK_EXT_display_surface_counter is a very simple extension which
adds an API, vkGetPhysicalSurfaceCapabilities2EXT, to extend the
existing vkGetPhysicalDeviceSurfaceCapabilitiesKHR and
vkGetPhysicalDeviceSurfaceCapablities2KHR interfaces.

The new interface uses a slightly different structure that includes a
new flags word, "supportedSurfaceCounters". This new field describes
the counters available from the underlying WSI layer. As this
extension doesn't provide any counters itself, each WSI layer
initializes this to zero for now.

VK_EXT_display_control is an extension specific to display surfaces
(those created via the KHR_display extension). This extension adds
DPMS support and fences which signal when vblank or monitor hotplug
events happen.

I've implemented the DPMS support and the vblank fence stuff; I
haven't bothered hooking up the monitor hotplug bits, although it
would be fairly simple.

To make the fences work on anv, I had to refactor the existing fence
waiting code to add the ability to spin waiting for any of a set of
heterogeneous fences (a mixture of syncobj and bo fences) to become
ready; this mirrors the same functionality in the radv driver,
although anv hadn't needed it before as it only supported homogenous
fence types (either all syncobj or all bo).

I've created a separate patch for this refactoring to try and reduce
the difficulty in reviewing that part.

-keith


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

[PATCH 6/7] anv: add VK_EXT_display_control to anv driver [v2]

[Keith Packard]

This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.

v2: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Add extension to list in alphabetical order

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_private.h |  4 ++
 src/intel/vulkan/anv_queue.c   | 22 +++
 src/intel/vulkan/anv_wsi_display.c | 97 ++
 4 files changed, 124 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 68e545a40f8..8c010e9280b 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -111,6 +111,7 @@ EXTENSIONS = [
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index fb91bc33046..c81885979ad 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2133,6 +2133,7 @@ enum anv_fence_type {
ANV_FENCE_TYPE_NONE = 0,
ANV_FENCE_TYPE_BO,
ANV_FENCE_TYPE_SYNCOBJ,
+   ANV_FENCE_TYPE_WSI,
 };
 
 enum anv_bo_fence_state {
@@ -2167,6 +2168,9 @@ struct anv_fence_impl {
 
   /** DRM syncobj handle for syncobj-based fences */
   uint32_t syncobj;
+
+  /** WSI fence */
+  struct wsi_fence *fence_wsi;
};
 };
 
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 8df99c84549..073e65acf5e 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -324,6 +324,10 @@ anv_fence_impl_cleanup(struct anv_device *device,
   anv_gem_syncobj_destroy(device, impl->syncobj);
   break;
 
+   case ANV_FENCE_TYPE_WSI:
+  impl->fence_wsi->destroy(impl->fence_wsi);
+  break;
+
default:
   unreachable("Invalid fence type");
}
@@ -672,6 +676,21 @@ done:
return result;
 }
 
+static VkResult
+anv_wait_for_wsi_fence(struct anv_device *device,
+   const VkFence _fence,
+   uint64_t abs_timeout)
+{
+   ANV_FROM_HANDLE(anv_fence, fence, _fence);
+
+   struct anv_fence_impl *impl = >permanent;
+   bool expired = impl->fence_wsi->wait(impl->fence_wsi, true, abs_timeout);
+
+   if (!expired)
+  return VK_TIMEOUT;
+   return VK_SUCCESS;
+}
+
 static VkResult
 anv_wait_for_fences(struct anv_device *device,
 uint32_t fenceCount,
@@ -694,6 +713,9 @@ anv_wait_for_fences(struct anv_device *device,
 result = anv_wait_for_syncobj_fences(device, 1, [i],
  true, abs_timeout);
 break;
+ case ANV_FENCE_TYPE_WSI:
+result = anv_wait_for_wsi_fence(device, pFences[i], abs_timeout);
+break;
  case ANV_FENCE_TYPE_NONE:
 result = VK_SUCCESS;
 break;
diff --git a/src/intel/vulkan/anv_wsi_display.c 
b/src/intel/vulkan/anv_wsi_display.c
index f749a8d98f7..cd736bcdd74 100644
--- a/src/intel/vulkan/anv_wsi_display.c
+++ b/src/intel/vulkan/anv_wsi_display.c
@@ -168,3 +168,100 @@ anv_GetRandROutputDisplayEXT(VkPhysicalDevice  
physical_device,
display);
 }
 #endif /* VK_USE_PLATFORM_XLIB_XRANDR_EXT */
+
+/* VK_EXT_display_control */
+
+VkResult
+anv_DisplayPowerControlEXT(VkDevice_device,
+VkDisplayKHRdisplay,
+const VkDisplayPowerInfoEXT *display_power_info)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+
+   return wsi_display_power_control(
+  _device, >instance->physicalDevice.wsi_device,
+  display, display_power_info);
+}
+
+VkResult
+anv_RegisterDeviceEventEXT(VkDevice _device,
+const VkDeviceEventInfoEXT *device_event_info,
+const VkAllocationCallbacks *allocator,
+VkFence *_fence)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+   const VkAllocationCallbacks *alloc;
+   struct anv_fence *fence;
+   VkResult ret;
+
+   if (allocator)
+ alloc = allocator;
+   else
+ alloc = >instance->alloc;
+
+   fence = vk_alloc(alloc, sizeof (*fence), 8,
+ 

[PATCH 7/7] radv: add VK_EXT_display_control to radv driver [v3]

[Keith Packard]

This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.

v2:
Rework fence integration into the driver so that waiting for
any of a mixture of fence types (wsi, driver or syncobjs)
causes the driver to poll, while a list of just syncobjs or
just driver fences will block. When we get syncobjs for wsi
fences, we'll adapt to use them.

v3: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c  |  68 +-
 src/amd/vulkan/radv_extensions.py |   1 +
 src/amd/vulkan/radv_private.h |   1 +
 src/amd/vulkan/radv_wsi_display.c | 113 ++
 4 files changed, 167 insertions(+), 16 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 59ee503c8c2..fd80db1c9b4 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -3240,6 +3240,7 @@ VkResult radv_CreateFence(
if (!fence)
return vk_error(device->instance, VK_ERROR_OUT_OF_HOST_MEMORY);
 
+   fence->fence_wsi = NULL;
fence->submitted = false;
fence->signalled = !!(pCreateInfo->flags & 
VK_FENCE_CREATE_SIGNALED_BIT);
fence->temp_syncobj = 0;
@@ -3284,6 +3285,8 @@ void radv_DestroyFence(
device->ws->destroy_syncobj(device->ws, fence->syncobj);
if (fence->fence)
device->ws->destroy_fence(fence->fence);
+   if (fence->fence_wsi)
+   fence->fence_wsi->destroy(fence->fence_wsi);
vk_free2(>alloc, pAllocator, fence);
 }
 
@@ -3309,7 +3312,19 @@ static bool radv_all_fences_plain_and_submitted(uint32_t 
fenceCount, const VkFen
 {
for (uint32_t i = 0; i < fenceCount; ++i) {
RADV_FROM_HANDLE(radv_fence, fence, pFences[i]);
-   if (fence->syncobj || fence->temp_syncobj || (!fence->signalled 
&& !fence->submitted))
+   if (fence->fence == NULL || fence->syncobj ||
+   fence->temp_syncobj ||
+   (!fence->signalled && !fence->submitted))
+   return false;
+   }
+   return true;
+}
+
+static bool radv_all_fences_syncobj(uint32_t fenceCount, const VkFence 
*pFences)
+{
+   for (uint32_t i = 0; i < fenceCount; ++i) {
+   RADV_FROM_HANDLE(radv_fence, fence, pFences[i]);
+   if (fence->syncobj == 0 && fence->temp_syncobj == 0)
return false;
}
return true;
@@ -3325,7 +3340,9 @@ VkResult radv_WaitForFences(
RADV_FROM_HANDLE(radv_device, device, _device);
timeout = radv_get_absolute_timeout(timeout);
 
-   if (device->always_use_syncobj) {
+   if (device->always_use_syncobj &&
+   radv_all_fences_syncobj(fenceCount, pFences))
+   {
uint32_t *handles = malloc(sizeof(uint32_t) * fenceCount);
if (!handles)
return vk_error(device->instance, 
VK_ERROR_OUT_OF_HOST_MEMORY);
@@ -3395,21 +3412,35 @@ VkResult radv_WaitForFences(
if (fence->signalled)
continue;
 
-   if (!fence->submitted) {
-   while(radv_get_current_time() <= timeout && 
!fence->submitted)
-   /* Do nothing */;
+   if (fence->fence) {
+   if (!fence->submitted) {
+   while(radv_get_current_time() <= timeout &&
+ !fence->submitted)
+   /* Do nothing */;
 
-   if (!fence->submitted)
-   return VK_TIMEOUT;
+   if (!fence->submitted)
+   return VK_TIMEOUT;
 
-   /* Recheck as it may have been set by submitting 
operations. */
-   if (fence->signalled)
-   continue;
+   /* Recheck as it may have been set by
+* submitting operations. */
+
+   if (fence->signalled)
+   continue;
+   }
+
+   expired = device->ws->fence_wait(device->ws,
+fence->fence,
+true, timeout);
+   if (!expired)
+   return VK_TIMEOUT;
}
 
-   expired = device->ws->fence_wait(device->ws, fence->fence, 
true, timeout);
-   if (!expired)
- 

[PATCH 2/7] anv: Add VK_EXT_display_surface_counter to anv driver [v2]

[Keith Packard]

This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

v2:
Add extension to list in alphabetical order

Suggested-by:  Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_wsi.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 4bffbcb5a2a..68e545a40f8 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -111,6 +111,7 @@ EXTENSIONS = [
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1,
   'device->has_context_priority'),
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index a7efb1416fa..1403601e9c0 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -120,6 +120,18 @@ VkResult anv_GetPhysicalDeviceSurfaceCapabilities2KHR(
pSurfaceCapabilities);
 }
 
+VkResult anv_GetPhysicalDeviceSurfaceCapabilities2EXT(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   VkSurfaceCapabilities2EXT*  pSurfaceCapabilities)
+{
+   ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_surface_capabilities2ext(>wsi_device,
+  surface,
+  pSurfaceCapabilities);
+}
+
 VkResult anv_GetPhysicalDeviceSurfaceFormatsKHR(
 VkPhysicalDevicephysicalDevice,
 VkSurfaceKHRsurface,
-- 
2.17.1

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

[PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]

[Keith Packard]

Handle the case where the set of fences to wait for is not all of the
same type by either waiting for them sequentially (waitAll), or
polling them until the timer has expired (!waitAll). We hope the
latter case is not common.

While the current code makes sure that it always has fences of only
one type, that will not be true when we add WSI fences. Split out this
refactoring to make merging that clearer.

v2: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/intel/vulkan/anv_queue.c | 105 +--
 1 file changed, 88 insertions(+), 17 deletions(-)

diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 6fe04a0a19d..8df99c84549 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -459,12 +459,32 @@ gettime_ns(void)
return (uint64_t)current.tv_sec * NSEC_PER_SEC + current.tv_nsec;
 }
 
+static uint64_t anv_get_absolute_timeout(uint64_t timeout)
+{
+   if (timeout == 0)
+  return 0;
+   uint64_t current_time = gettime_ns();
+
+   timeout = MIN2(INT64_MAX - current_time, timeout);
+
+   return (current_time + timeout);
+}
+
+static int64_t anv_get_relative_timeout(uint64_t abs_timeout)
+{
+   uint64_t now = gettime_ns();
+
+   if (abs_timeout < now)
+  return 0;
+   return abs_timeout - now;
+}
+
 static VkResult
 anv_wait_for_syncobj_fences(struct anv_device *device,
 uint32_t fenceCount,
 const VkFence *pFences,
 bool waitAll,
-uint64_t _timeout)
+uint64_t abs_timeout_ns)
 {
uint32_t *syncobjs = vk_zalloc(>alloc,
   sizeof(*syncobjs) * fenceCount, 8,
@@ -484,19 +504,6 @@ anv_wait_for_syncobj_fences(struct anv_device *device,
   syncobjs[i] = impl->syncobj;
}
 
-   int64_t abs_timeout_ns = 0;
-   if (_timeout > 0) {
-  uint64_t current_ns = gettime_ns();
-
-  /* Add but saturate to INT32_MAX */
-  if (current_ns + _timeout < current_ns)
- abs_timeout_ns = INT64_MAX;
-  else if (current_ns + _timeout > INT64_MAX)
- abs_timeout_ns = INT64_MAX;
-  else
- abs_timeout_ns = current_ns + _timeout;
-   }
-
/* The gem_syncobj_wait ioctl may return early due to an inherent
 * limitation in the way it computes timeouts.  Loop until we've actually
 * passed the timeout.
@@ -665,6 +672,67 @@ done:
return result;
 }
 
+static VkResult
+anv_wait_for_fences(struct anv_device *device,
+uint32_t fenceCount,
+const VkFence *pFences,
+bool waitAll,
+uint64_t abs_timeout)
+{
+   VkResult result = VK_SUCCESS;
+
+   if (fenceCount <= 1 || waitAll) {
+  for (uint32_t i = 0; i < fenceCount; i++) {
+ ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
+ switch (fence->permanent.type) {
+ case ANV_FENCE_TYPE_BO:
+result = anv_wait_for_bo_fences(
+   device, 1, [i], true,
+   anv_get_relative_timeout(abs_timeout));
+break;
+ case ANV_FENCE_TYPE_SYNCOBJ:
+result = anv_wait_for_syncobj_fences(device, 1, [i],
+ true, abs_timeout);
+break;
+ case ANV_FENCE_TYPE_NONE:
+result = VK_SUCCESS;
+break;
+ }
+ if (result != VK_SUCCESS)
+return result;
+  }
+   } else {
+  while (gettime_ns() < abs_timeout) {
+ for (uint32_t i = 0; i < fenceCount; i++) {
+if (anv_wait_for_fences(device, 1, [i], true, 0) == 
VK_SUCCESS)
+   return VK_SUCCESS;
+ }
+  }
+  result = VK_TIMEOUT;
+   }
+   return result;
+}
+
+static bool anv_all_fences_syncobj(uint32_t fenceCount, const VkFence *pFences)
+{
+   for (uint32_t i = 0; i < fenceCount; ++i) {
+  ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
+  if (fence->permanent.type != ANV_FENCE_TYPE_SYNCOBJ)
+ return false;
+   }
+   return true;
+}
+
+static bool anv_all_fences_bo(uint32_t fenceCount, const VkFence *pFences)
+{
+   for (uint32_t i = 0; i < fenceCount; ++i) {
+  ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
+  if (fence->permanent.type != ANV_FENCE_TYPE_BO)
+ return false;
+   }
+   return true;
+}
+
 VkResult anv_WaitForFences(
 VkDevice_device,
 uint32_tfenceCount,
@@ -677,12 +745,15 @@ VkResult anv_WaitForFences(
if (unlikely(device->lost))
   return VK_ERROR_DEVICE_LOST;
 
-   if (device->instance->physicalDevice.has_syncobj_wait) {
+   if (anv_all_fences_syncobj(fenceCount, pFences)) {
   return 

[PATCH 1/7] vulkan: Add VK_EXT_display_surface_counter [v4]

[Keith Packard]

This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

v2: Thanks to kisak

Fix spelling of VkSurfaceCapabilities2EXT in wsi_common_wayland.c,
it was using ext instead of EXT.

Fix spelling of VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT

v3: Fix wayland WSI, regularize spelling

Misspelled 'surface' in get_capabilities2ext
Remove extra _ from get_capabilities_2ext in a couple of places

v4: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace
between types and names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/vulkan/wsi/wsi_common.c | 12 
 src/vulkan/wsi/wsi_common.h |  6 ++
 src/vulkan/wsi/wsi_common_display.c | 27 +++
 src/vulkan/wsi/wsi_common_private.h |  3 +++
 src/vulkan/wsi/wsi_common_wayland.c | 27 +++
 src/vulkan/wsi/wsi_common_x11.c | 27 +++
 6 files changed, 102 insertions(+)

diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 142c5d8fe58..91d0b72e1ba 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -710,6 +710,18 @@ wsi_common_get_surface_capabilities2(struct wsi_device 
*wsi_device,
pSurfaceCapabilities);
 }
 
+VkResult
+wsi_common_get_surface_capabilities2ext(
+   struct wsi_device *wsi_device,
+   VkSurfaceKHR _surface,
+   VkSurfaceCapabilities2EXT *pSurfaceCapabilities)
+{
+   ICD_FROM_HANDLE(VkIcdSurfaceBase, surface, _surface);
+   struct wsi_interface *iface = wsi_device->wsi[surface->platform];
+
+   return iface->get_capabilities2ext(surface, pSurfaceCapabilities);
+}
+
 VkResult
 wsi_common_get_surface_formats(struct wsi_device *wsi_device,
VkSurfaceKHR _surface,
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 61b1de59d7f..054aad23c1c 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -178,6 +178,12 @@ wsi_common_get_surface_present_modes(struct wsi_device 
*wsi_device,
  uint32_t *pPresentModeCount,
  VkPresentModeKHR *pPresentModes);
 
+VkResult
+wsi_common_get_surface_capabilities2ext(
+   struct wsi_device *wsi_device,
+   VkSurfaceKHR surface,
+   VkSurfaceCapabilities2EXT *pSurfaceCapabilities);
+
 VkResult
 wsi_common_get_images(VkSwapchainKHR _swapchain,
   uint32_t *pSwapchainImageCount,
diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index e140e71c518..504f7741d73 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -641,6 +641,32 @@ wsi_display_surface_get_capabilities2(VkIcdSurfaceBase 
*icd_surface,
>surfaceCapabilities);
 }
 
+static VkResult
+wsi_display_surface_get_capabilities2ext(VkIcdSurfaceBase *icd_surface,
+  VkSurfaceCapabilities2EXT *caps)
+{
+   VkSurfaceCapabilitiesKHR khr_caps;
+   VkResult ret;
+
+   assert(caps->sType == VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT);
+   ret = wsi_display_surface_get_capabilities(icd_surface, _caps);
+   if (ret)
+  return ret;
+
+   caps->minImageCount = khr_caps.minImageCount;
+   caps->maxImageCount = khr_caps.maxImageCount;
+   caps->currentExtent = khr_caps.currentExtent;
+   caps->minImageExtent = khr_caps.minImageExtent;
+   caps->maxImageExtent = khr_caps.maxImageExtent;
+   caps->maxImageArrayLayers = khr_caps.maxImageArrayLayers;
+   caps->supportedTransforms = khr_caps.supportedTransforms;
+   caps->currentTransform = khr_caps.currentTransform;
+   caps->supportedCompositeAlpha = khr_caps.supportedCompositeAlpha;
+   caps->supportedUsageFlags = khr_caps.supportedUsageFlags;
+   caps->supportedSurfaceCounters = 0;
+   return ret;
+}
+
 static const struct {
VkFormat format;
uint32_t drm_format;
@@ -1393,6 +1419,7 @@ wsi_display_init_wsi(struct wsi_device *wsi_device,
wsi->base.get_support = wsi_display_surface_get_support;
wsi->base.get_capabilities = wsi_display_surface_get_capabilities;
wsi->base.get_capabilities2 = wsi_display_surface_get_capabilities2;
+   wsi->base.get_capabilities2ext = wsi_display_surface_get_capabilities2ext;
wsi->base.get_formats = wsi_display_surface_get_formats;
wsi->base.get_formats2 = wsi_display_surface_get_formats2;
wsi->base.get_present_modes = wsi_display_surface_get_present_modes;
diff --git a/src/vulkan/wsi/wsi_common_private.h 
b/src/vulkan/wsi/wsi_common_private.h
index 3d502b9fc9d..b97d2d8ba06 100644
--- a/src/vulkan/wsi/wsi_common_private.h
+++ b/src/vulkan/wsi/wsi_common_private.h
@@ -109,6 +109,9 @@ struct wsi_interface {
VkResult 

[PATCH 5/7] vulkan: add VK_EXT_display_control [v5]

[Keith Packard]

This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.

v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
been removed from the proposed kernel API.

Add NULL parameter to drmCrtcQueueSequence ioctl as we
don't care what sequence the event was actually queued to.

v3: Adapt to pthread clock switch to MONOTONIC

v4: Fix scope for wsi_display_mode andwsi_display_connector allocs

Suggested-by: Jason Ekstrand 

v5: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Use wsi_rel_to_abs_time helper function to convert relative
timeouts to absolute timeouts without causing overflow.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/vulkan/wsi/wsi_common.h |  10 +
 src/vulkan/wsi/wsi_common_display.c | 307 +++-
 src/vulkan/wsi/wsi_common_display.h |  29 +++
 3 files changed, 345 insertions(+), 1 deletion(-)

diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 054aad23c1c..081fe1dcf8d 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -66,6 +66,16 @@ struct wsi_format_modifier_properties_list {
struct wsi_format_modifier_properties *modifier_properties;
 };
 
+struct wsi_fence {
+   VkDevice device;
+   const struct wsi_device  *wsi_device;
+   VkDisplayKHR display;
+   const VkAllocationCallbacks  *alloc;
+   bool (*wait)(struct wsi_fence *fence,
+bool absolute, uint64_t timeout);
+   void (*destroy)(struct wsi_fence *fence);
+};
+
 struct wsi_interface;
 
 #define VK_ICD_WSI_PLATFORM_MAX (VK_ICD_WSI_PLATFORM_DISPLAY + 1)
diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index 504f7741d73..40eaa6a322e 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -79,6 +79,7 @@ typedef struct wsi_display_connector {
struct list_head display_modes;
wsi_display_mode *current_mode;
drmModeModeInfo  current_drm_mode;
+   uint32_t dpms_property;
 #ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
xcb_randr_output_t   output;
 #endif
@@ -132,6 +133,15 @@ struct wsi_display_swapchain {
struct wsi_display_image images[0];
 };
 
+struct wsi_display_fence {
+   struct wsi_fence base;
+   bool event_received;
+   bool destroyed;
+   uint64_t sequence;
+};
+
+static uint64_t fence_sequence;
+
 ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_mode, VkDisplayModeKHR)
 ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_connector, VkDisplayKHR)
 
@@ -307,6 +317,19 @@ wsi_display_get_connector(struct wsi_device *wsi_device,
 
connector->connected = drm_connector->connection != DRM_MODE_DISCONNECTED;
 
+   /* Look for a DPMS property */
+   for (int p = 0; p < drm_connector->count_props; p++) {
+  drmModePropertyPtr prop = drmModeGetProperty(wsi->fd,
+   drm_connector->props[p]);
+  if (!prop)
+ continue;
+  if (prop->flags & DRM_MODE_PROP_ENUM) {
+ if (!strcmp(prop->name, "DPMS"))
+connector->dpms_property = drm_connector->props[p];
+  }
+  drmModeFreeProperty(prop);
+   }
+
/* Mark all connector modes as invalid */
wsi_display_invalidate_connector_modes(wsi_device, connector);
 
@@ -663,7 +686,7 @@ wsi_display_surface_get_capabilities2ext(VkIcdSurfaceBase 
*icd_surface,
caps->currentTransform = khr_caps.currentTransform;
caps->supportedCompositeAlpha = khr_caps.supportedCompositeAlpha;
caps->supportedUsageFlags = khr_caps.supportedUsageFlags;
-   caps->supportedSurfaceCounters = 0;
+   caps->supportedSurfaceCounters = VK_SURFACE_COUNTER_VBLANK_EXT;
return ret;
 }
 
@@ -896,12 +919,21 @@ static void wsi_display_page_flip_handler(int fd,
wsi_display_page_flip_handler2(fd, frame, sec, usec, 0, data);
 }
 
+static void wsi_display_vblank_handler(int fd, unsigned int frame,
+   unsigned int sec, unsigned int usec,
+   void *data);
+
+static void wsi_display_sequence_handler(int fd, uint64_t frame,
+ uint64_t ns, uint64_t user_data);
+
 static drmEventContext event_context = {
.version = DRM_EVENT_CONTEXT_VERSION,
.page_flip_handler = wsi_display_page_flip_handler,
 #if DRM_EVENT_CONTEXT_VERSION >= 3
.page_flip_handler2 = wsi_display_page_flip_handler2,
 #endif
+   .vblank_handler = wsi_display_vblank_handler,
+   .sequence_handler = wsi_display_sequence_handler,
 };
 
 static 

[PATCH 3/7] radv: Add VK_EXT_display_surface_counter to radv driver

[Keith Packard]

This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py |  1 +
 src/amd/vulkan/radv_wsi.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 65ce7349016..601a345b114 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -89,6 +89,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',  23, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
+Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_depth_range_unrestricted',  1, True),
 Extension('VK_EXT_descriptor_indexing',   2, True),
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 2840b666727..20484177135 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -103,6 +103,18 @@ VkResult radv_GetPhysicalDeviceSurfaceCapabilities2KHR(
pSurfaceCapabilities);
 }
 
+VkResult radv_GetPhysicalDeviceSurfaceCapabilities2EXT(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   VkSurfaceCapabilities2EXT*  pSurfaceCapabilities)
+{
+   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_surface_capabilities2ext(>wsi_device,
+  surface,
+  pSurfaceCapabilities);
+}
+
 VkResult radv_GetPhysicalDeviceSurfaceFormatsKHR(
VkPhysicalDevicephysicalDevice,
VkSurfaceKHRsurface,
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values

[Keith Packard]

Jason Ekstrand  writes:

> Looks good to me.  With this properly sprinkled on the appropriate patches,
> the entire series is
>
> Reviewed-by: Jason Ekstrand 

Thanks so much! I've rebased the series onto current master and pushed
it back to my gitlab repo here

https://gitlab.freedesktop.org/keithp/mesa/tree/drm-lease

I'll be doing testing tomorrow morning, and if it all looks good on both
anv and radv, I'll get it merged and pushed to master.

Now to get the next series ready for review :-)


-- 
-keith


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

Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values

[Jason Ekstrand]

Looks good to me.  With this properly sprinkled on the appropriate patches,
the entire series is

Reviewed-by: Jason Ekstrand 

On Thu, Jun 14, 2018 at 5:57 PM, Keith Packard  wrote:

> We sorted out what 'vscan' means and are trying to use it correctly.
>
> vscan = 0 is the same as vscan = 1, which is slightly annoying; we use
> MAX2(vscan, 1) everywhere.
>
> randr doesn't pass vscan at all, so we set wsi mode vscan = 0.
>
> The doublescan flag doubles the vscan value, so we don't need to deal
> with that separately, we can just compare flags normally.
>
> Signed-off-by: Keith Packard 
> ---
>  src/vulkan/wsi/wsi_common_display.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_display.c
> b/src/vulkan/wsi/wsi_common_display.c
> index c7f794a0eff..de1c1826bd2 100644
> --- a/src/vulkan/wsi/wsi_common_display.c
> +++ b/src/vulkan/wsi/wsi_common_display.c
> @@ -149,7 +149,7 @@ wsi_display_mode_matches_drm(wsi_display_mode *wsi,
>wsi->vsync_start == drm->vsync_start &&
>wsi->vsync_end == drm->vsync_end &&
>wsi->vtotal == drm->vtotal &&
> -  wsi->vscan == drm->vscan &&
> +  MAX2(wsi->vscan, 1) == MAX2(drm->vscan, 1) &&
>wsi->flags == drm->flags;
>  }
>
> @@ -158,7 +158,7 @@ wsi_display_mode_refresh(struct wsi_display_mode *wsi)
>  {
> return (double) wsi->clock * 1000.0 / ((double) wsi->htotal *
>(double) wsi->vtotal *
> -  (double) (wsi->vscan + 1));
> +  (double) MAX2(wsi->vscan, 1));
>  }
>
>  static uint64_t wsi_get_current_monotonic(void)
> @@ -1657,6 +1657,7 @@ wsi_display_mode_matches_x(struct wsi_display_mode
> *wsi,
>wsi->vsync_start == xcb->vsync_start &&
>wsi->vsync_end == xcb->vsync_end &&
>wsi->vtotal == xcb->vtotal &&
> +  wsi->vscan <= 1 &&
>wsi->flags == xcb->mode_flags;
>  }
>
> @@ -1707,8 +1708,6 @@ wsi_display_register_x_mode(struct wsi_device
> *wsi_device,
> display_mode->vsync_end = x_mode->vsync_end;
> display_mode->vtotal = x_mode->vtotal;
> display_mode->vscan = 0;
> -   if (x_mode->mode_flags & XCB_RANDR_MODE_FLAG_DOUBLE_SCAN)
> -  display_mode->vscan = 1;
> display_mode->flags = x_mode->mode_flags;
>
> list_addtail(_mode->list, >display_modes);
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] wsi_common_display: Deal with vscan values

[Keith Packard]

We sorted out what 'vscan' means and are trying to use it correctly.

vscan = 0 is the same as vscan = 1, which is slightly annoying; we use
MAX2(vscan, 1) everywhere.

randr doesn't pass vscan at all, so we set wsi mode vscan = 0.

The doublescan flag doubles the vscan value, so we don't need to deal
with that separately, we can just compare flags normally.

Signed-off-by: Keith Packard 
---
 src/vulkan/wsi/wsi_common_display.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index c7f794a0eff..de1c1826bd2 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -149,7 +149,7 @@ wsi_display_mode_matches_drm(wsi_display_mode *wsi,
   wsi->vsync_start == drm->vsync_start &&
   wsi->vsync_end == drm->vsync_end &&
   wsi->vtotal == drm->vtotal &&
-  wsi->vscan == drm->vscan &&
+  MAX2(wsi->vscan, 1) == MAX2(drm->vscan, 1) &&
   wsi->flags == drm->flags;
 }
 
@@ -158,7 +158,7 @@ wsi_display_mode_refresh(struct wsi_display_mode *wsi)
 {
return (double) wsi->clock * 1000.0 / ((double) wsi->htotal *
   (double) wsi->vtotal *
-  (double) (wsi->vscan + 1));
+  (double) MAX2(wsi->vscan, 1));
 }
 
 static uint64_t wsi_get_current_monotonic(void)
@@ -1657,6 +1657,7 @@ wsi_display_mode_matches_x(struct wsi_display_mode *wsi,
   wsi->vsync_start == xcb->vsync_start &&
   wsi->vsync_end == xcb->vsync_end &&
   wsi->vtotal == xcb->vtotal &&
+  wsi->vscan <= 1 && 
   wsi->flags == xcb->mode_flags;
 }
 
@@ -1707,8 +1708,6 @@ wsi_display_register_x_mode(struct wsi_device *wsi_device,
display_mode->vsync_end = x_mode->vsync_end;
display_mode->vtotal = x_mode->vtotal;
display_mode->vscan = 0;
-   if (x_mode->mode_flags & XCB_RANDR_MODE_FLAG_DOUBLE_SCAN)
-  display_mode->vscan = 1;
display_mode->flags = x_mode->mode_flags;
 
list_addtail(_mode->list, >display_modes);
-- 
2.17.1

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

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

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

--- Comment #38 from Samuel Sieb (samuel-kb...@sieb.net) ---
https://bugzilla.redhat.com/show_bug.cgi?id=1558023

-- 
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 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

--- Comment #7 from Ricardo Ribalda  ---
BTW: Are you aware of anyway that I can validate that a video is properly
encoded, besides playing it?

Thanks!

-- 
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 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

--- Comment #6 from Ricardo Ribalda  ---
I tried this combinations with gstreamer:

sw encoding + sw decoding (libva): works

sw encoding + omx decoding: works

omx encoding + sw decoding (libva): works

omx encoding + omx decoding : fails


I havent tried vaapi yet. I can try to give it a try tomorrow and report
results

-- 
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 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

--- Comment #5 from Julien Isorce  ---
Can you try gstreamer-vaapi ? to compare with another hw decoder. And with sw
decoders in gstreamer it works ? And other players ?
I am trying to determine if the issue is only in the omx decoder.

-- 
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 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Peter Zijlstra]

On Thu, Jun 14, 2018 at 06:43:40PM +0200, Thomas Hellstrom wrote:
> Overall, I think this looks fine. I'll just fix up the FLAG_WAITERS setting
> and affected comments and do some torture testing on it.

Thanks!

> Are you OK with adding the new feature and the cleanup in the same patch?

I suppose so, trying to untangle that will be a bit of a pain. But if
you feel so inclined I'm not going to stop you :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)

[bugzilla-daemon]

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

--- Comment #24 from djip.per...@free.fr ---
look like LVDS is not see as attached...

-- 
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 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)

[bugzilla-daemon]

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

--- Comment #23 from djip.per...@free.fr ---
Created attachment 140167
  --> https://bugs.freedesktop.org/attachment.cgi?id=140167=edit
dmesg from kernel 4.17.1 with attachment 138831 applied

recompile 4.17.1 kernel with patch an debug mod...
hope it can help.

-- 
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 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

--- Comment #4 from Ricardo Ribalda  ---
I do not know. It is the first time that I use this configuration: omx for
encoding and decoding.

The only thing that I know for sure is that the effect gets worse and worse if
I increase the frequency of key frames.

-- 
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 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

Julien Isorce  changed:

   What|Removed |Added

 CC||boyuan.zh...@amd.com,
   ||leoxs...@gmail.com

--- Comment #3 from Julien Isorce  ---
Is it a regression ? Was it working for you before on the same or other config
?

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

RE: [PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap

[Chris Wilson]

Quoting Bloomfield, Jon (2018-06-14 17:36:29)
> > -Original Message-
> > From: Chris Wilson 
> > Sent: Thursday, June 14, 2018 9:07 AM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Chris Wilson 
> > ;
> > Bloomfield, Jon ; Joonas Lahtinen
> > ; Matthew Auld
> > ; David Herrmann
> > 
> > Subject: [PATCH v2] drm/i915: Prevent writing into a read-only object via a
> > GGTT mmap
> > 
> > If the user has created a read-only object, they should not be allowed
> > to circumvent the write protection by using a GGTT mmapping. Deny it.
> > 
> > Also most machines do not support read-only GGTT PTEs, so again we have
> > to reject attempted writes. Fortunately, this is known a priori, so we
> > can at least reject in the call to create the mmap (with a sanity check
> > in the fault handler).
> > 
> > v2: Check the vma->vm_flags during mmap() to allow readonly access.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Jon Bloomfield 
> > Cc: Joonas Lahtinen 
> > Cc: Matthew Auld 
> > Cc: David Herrmann 
> 
> Shame about the BUG_ON, but probably overkill to add code to suppress
> the RO flag just for mmap.
> 
> Reviewed-by: Jon Bloomfield 

Maybe one day with a PIN_RO, we can put it back in again.
Just a feeling of unease for shadowing cache_level on the vma. If only
we could just erase the history of doing cache_domain tracking.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106921] System lockup with Vega10 amdgpu: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout

[bugzilla-daemon]

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

--- Comment #2 from sam.ps...@gmail.com ---
Created attachment 140166
  --> https://bugs.freedesktop.org/attachment.cgi?id=140166=edit
another dmesg w/mesa 18.0.2-1.fc28

-- 
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 106921] System lockup with Vega10 amdgpu: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout

[bugzilla-daemon]

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

--- Comment #1 from sam.ps...@gmail.com ---
Created attachment 140165
  --> https://bugs.freedesktop.org/attachment.cgi?id=140165=edit
dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28

-- 
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 106921] System lockup with Vega10 amdgpu: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout

[bugzilla-daemon]

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

Bug ID: 106921
   Summary: System lockup with Vega10 amdgpu:
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sam.ps...@gmail.com

Created attachment 140164
  --> https://bugs.freedesktop.org/attachment.cgi?id=140164=edit
dmesg w/mesa 18.0.2-1.fc28

Using Vega10 hardware (in my case, RX Vega 64), the whole system experiences
regular full lockups, requiring me to force reboot either with the power switch
on the PC or using SysRq. The system is still running, since I am able to ssh
in from a separate machine and retrieve logs/run commands/etc, but all keyboard
and mouse input ceases.

I've had this occur when doing a multitude of things, some of which are as
follows:
- Playing games through Steam (Half-Life 2, Portal 2, Terraria tested)
- Playing non-Steam games (SuperTuxKart, GNOME Mines)
- Idle GNOME 3 desktop (no applications running)
- Browsing the web with Firefox 60.0.1

I have had this occur with:
Kernel: 4.16.14-300.fc28.x86_64 (from Fedora repos), 4.17.0 & 4.18.0-git5.1
(from kernel-vanilla repositories linked on Fedora wiki)
Mesa: 18.0.2-1.fc28 (from Fedora repos), 18.2.0-0.11.git41dabdc.fc28 (from
che/mesa copr repo)
linux-firmware: 20180525-85.git7518922b.fc28 (from Fedora repos), with
amdgpu/vega10_vce.bin replaced with newest version from git master.
OS: Fedora 28 Workstation

I am attaching a few dmesgs, each of which going from boot to the bug
occurring.

-- 
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 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

On 06/14/2018 04:42 PM, Peter Zijlstra wrote:

On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:

The literature makes a distinction between "killed" and "wounded". In our
context, "Killed" is when a transaction actually receives an -EDEADLK and
needs to back off. "Wounded" is when someone (typically another transaction)
requests a transaction to kill itself. A wound will often, but not always,
lead to a kill. If the wounded transaction has finished its locking
sequence, or has the opportunity to grab uncontended ww mutexes or steal
contended (non-handoff) ww mutexes to finish its transaction it will do so
and never kill itself.

Hopefully I got it all right this time; I folded your patch in and
mucked around with it a bit, but haven't done anything except compile
it.

I left the context/transaction thing because well, that's what we called
the thing.


Overall, I think this looks fine. I'll just fix up the FLAG_WAITERS 
setting and affected comments and do some torture testing on it.


Are you OK with adding the new feature and the cleanup in the same patch?

Thomas






diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 39fda195bf78..50ef5a10cfa0 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -8,6 +8,8 @@
   *
   * Wound/wait implementation:
   *  Copyright (C) 2013 Canonical Ltd.
+ * Choice of algorithm:
+ *  Copyright (C) 2018 WMWare Inc.
   *
   * This file contains the main data structure and API definitions.
   */
@@ -23,14 +25,17 @@ struct ww_class {
struct lock_class_key mutex_key;
const char *acquire_name;
const char *mutex_name;
+   unsigned int is_wait_die;
  };
  
  struct ww_acquire_ctx {

struct task_struct *task;
unsigned long stamp;
-   unsigned acquired;
+   unsigned int acquired;
+   unsigned short wounded;
+   unsigned short is_wait_die;
  #ifdef CONFIG_DEBUG_MUTEXES
-   unsigned done_acquire;
+   unsigned int done_acquire;
struct ww_class *ww_class;
struct ww_mutex *contending_lock;
  #endif
@@ -38,8 +43,8 @@ struct ww_acquire_ctx {
struct lockdep_map dep_map;
  #endif
  #ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
-   unsigned deadlock_inject_interval;
-   unsigned deadlock_inject_countdown;
+   unsigned int deadlock_inject_interval;
+   unsigned int deadlock_inject_countdown;
  #endif
  };
  
@@ -58,17 +63,21 @@ struct ww_mutex {

  # define __WW_CLASS_MUTEX_INITIALIZER(lockname, class)
  #endif
  
-#define __WW_CLASS_INITIALIZER(ww_class) \

+#define __WW_CLASS_INITIALIZER(ww_class, _is_wait_die) \
{ .stamp = ATOMIC_LONG_INIT(0) \
, .acquire_name = #ww_class "_acquire" \
-   , .mutex_name = #ww_class "_mutex" }
+   , .mutex_name = #ww_class "_mutex" \
+   , .is_wait_die = _is_wait_die }
  
  #define __WW_MUTEX_INITIALIZER(lockname, class) \

{ .base =  __MUTEX_INITIALIZER(lockname.base) \
__WW_CLASS_MUTEX_INITIALIZER(lockname, class) }
  
+#define DEFINE_WD_CLASS(classname) \

+   struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 1)
+
  #define DEFINE_WW_CLASS(classname) \
-   struct ww_class classname = __WW_CLASS_INITIALIZER(classname)
+   struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 0)
  
  #define DEFINE_WW_MUTEX(mutexname, ww_class) \

struct ww_mutex mutexname = __WW_MUTEX_INITIALIZER(mutexname, ww_class)
@@ -123,6 +132,8 @@ static inline void ww_acquire_init(struct ww_acquire_ctx 
*ctx,
ctx->task = current;
ctx->stamp = atomic_long_inc_return_relaxed(_class->stamp);
ctx->acquired = 0;
+   ctx->wounded = false;
+   ctx->is_wait_die = ww_class->is_wait_die;
  #ifdef CONFIG_DEBUG_MUTEXES
ctx->ww_class = ww_class;
ctx->done_acquire = 0;
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index f44f658ae629..9e244af4647d 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -244,6 +244,22 @@ void __sched mutex_lock(struct mutex *lock)
  EXPORT_SYMBOL(mutex_lock);
  #endif
  
+/*

+ * Wait-Die:
+ *   The newer transactions are killed when:
+ * It (the new transaction) makes a request for a lock being held
+ * by an older transaction.
+ *
+ * Wound-Wait:
+ *   The newer transactions are wounded when:
+ * An older transaction makes a request for a lock being held by
+ * the newer transaction.
+ */
+
+/*
+ * Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
+ * it.
+ */
  static __always_inline void
  ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
  {
@@ -282,26 +298,96 @@ ww_mutex_lock_acquired(struct ww_mutex *ww, struct 
ww_acquire_ctx *ww_ctx)
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
  #endif
ww_ctx->acquired++;
+   ww->ctx = ww_ctx;
  }
  
+/*

+ * Determine if context @a is 'after' context @b. 

RE: [PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap

[Bloomfield, Jon]

> -Original Message-
> From: Chris Wilson 
> Sent: Thursday, June 14, 2018 9:07 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Chris Wilson ;
> Bloomfield, Jon ; Joonas Lahtinen
> ; Matthew Auld
> ; David Herrmann
> 
> Subject: [PATCH v2] drm/i915: Prevent writing into a read-only object via a
> GGTT mmap
> 
> If the user has created a read-only object, they should not be allowed
> to circumvent the write protection by using a GGTT mmapping. Deny it.
> 
> Also most machines do not support read-only GGTT PTEs, so again we have
> to reject attempted writes. Fortunately, this is known a priori, so we
> can at least reject in the call to create the mmap (with a sanity check
> in the fault handler).
> 
> v2: Check the vma->vm_flags during mmap() to allow readonly access.
> 
> Signed-off-by: Chris Wilson 
> Cc: Jon Bloomfield 
> Cc: Joonas Lahtinen 
> Cc: Matthew Auld 
> Cc: David Herrmann 

Shame about the BUG_ON, but probably overkill to add code to suppress
the RO flag just for mmap.

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

Re: [alsa-devel] [PATCH v3 16/27] docs: Fix more broken references

[Takashi Iwai]

On Thu, 14 Jun 2018 18:09:01 +0200,
Mauro Carvalho Chehab wrote:
> 
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
>   ./scripts/documentation-file-ref-check --fix
> 
> Manually checked that produced results are valid.
> 
> Signed-off-by: Mauro Carvalho Chehab 

For the sound bits:
  Acked-by: Takashi Iwai 


thanks,

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

[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32

[bugzilla-daemon]

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

--- Comment #23 from sam.ps...@gmail.com ---
(In reply to Michel Dänzer from comment #22)
> (In reply to sam.psylo from comment #20)
> > I am still suffering from this issue, even with latest firmware from comment
> > 15.
> 
> Please file your own report. This report is resolved.

Will do. Sorry about that.

> > Firmware: 20180525-85.git7518922b.fc28 (current Fedora release), but with
> > vega10_vce.bin from comment 15 replacing the one installed by the package.
> 
> Did you double-check that's the only file which differs from the ones you
> have?

Not directly, but I did take a look at the linux-firmware git history and that
was the only firmware changed after May 25 (the date that the fedora package
was based on).

I'll make a new report for the bug, and continue there.

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

Re: [PATCH v3 04/27] docs: fix broken references with multiple hints

[Steven Rostedt]

On Thu, 14 Jun 2018 13:08:49 -0300
Mauro Carvalho Chehab  wrote:

> +++ b/Documentation/trace/events.rst
> @@ -8,7 +8,7 @@ Event Tracing
>  1. Introduction
>  ===
>  
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used
> +Tracepoints (see Documentation/trace/tracepoints.rst) can be used
>  without creating custom kernel modules to register probe functions
>  using the event tracing infrastructure.
>  
> diff --git a/Documentation/trace/tracepoint-analysis.rst 
> b/Documentation/trace/tracepoint-analysis.rst
> index a4d3ff2e5efb..bef37abf4ad3 100644
> --- a/Documentation/trace/tracepoint-analysis.rst
> +++ b/Documentation/trace/tracepoint-analysis.rst
> @@ -6,7 +6,7 @@ Notes on Analysing Behaviour Using Events and Tracepoints
>  1. Introduction
>  ===
>  
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used without
> +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without
>  creating custom kernel modules to register probe functions using the event
>  tracing infrastructure.
>  

Acked-by: Steven Rostedt (VMware) 

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

Re: [Intel-wired-lan] [PATCH v3 16/27] docs: Fix more broken references

[Jeff Kirsher]

On Thu, 2018-06-14 at 13:09 -0300, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
> 
> Manually checked that produced results are valid.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Jeff Kirsher 

For the Intel networking Kconfig changes.

> ---
>  .../devicetree/bindings/clock/st/st,clkgen.txt |  8 
>  .../devicetree/bindings/clock/ti/gate.txt  |  2 +-
>  .../devicetree/bindings/clock/ti/interface.txt |  2 +-
>  .../bindings/cpufreq/cpufreq-mediatek.txt  |  2 +-
>  .../devicetree/bindings/devfreq/rk3399_dmc.txt |  2 +-
>  .../bindings/gpu/arm,mali-midgard.txt  |  2 +-
>  .../bindings/gpu/arm,mali-utgard.txt   |  2 +-
>  .../devicetree/bindings/mfd/mt6397.txt |  2 +-
>  .../devicetree/bindings/mfd/sun6i-prcm.txt |  2 +-
>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |  2 +-
>  .../devicetree/bindings/net/dsa/ksz.txt|  2 +-
>  .../devicetree/bindings/net/dsa/mt7530.txt |  2 +-
>  .../devicetree/bindings/power/fsl,imx-gpc.txt  |  2 +-
>  .../bindings/power/wakeup-source.txt   |  2 +-
>  .../devicetree/bindings/usb/rockchip,dwc3.txt  |  2 +-
>  Documentation/hwmon/ina2xx |  2 +-
>  Documentation/maintainer/pull-requests.rst |  2 +-
>  Documentation/translations/ko_KR/howto.rst |  2 +-
>  MAINTAINERS| 18 +---
> --
>  drivers/net/ethernet/intel/Kconfig |  8 
>  drivers/soundwire/stream.c |  8 
>  fs/Kconfig.binfmt  |  2 +-
>  fs/binfmt_misc.c   |  2 +-
>  23 files changed, 40 insertions(+), 40 deletions(-)


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC v3 0/8] Add Plane Color Properties

[Shankar, Uma]

>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Thursday, June 14, 2018 6:21 PM
>To: Shankar, Uma 
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville
>; n...@arm.com; Lankhorst, Maarten
>
>Subject: Re: [RFC v3 0/8] Add Plane Color Properties
>
>On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>> >Behalf Of Alexandru-Cosmin Gheorghe
>> >Sent: Monday, June 11, 2018 3:47 PM
>> >To: Shankar, Uma 
>> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>> >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala,
>> >Ville ; n...@arm.com; Lankhorst, Maarten
>> >
>> >Subject: Re: [RFC v3 0/8] Add Plane Color Properties
>> >
>> >Hi Uma,
>> >
>> >Any progress on userspace for this?
>> >I was thinking on working on using this in drm_hwcomposer.
>> >
>>
>> Hi Alex,
>> Not much work has been done till now on user space side. You can go
>> ahead and try to enable it in drm_hwcomposer.
>>
>
>Hi,
>
>I'm missing the hardware/driver that can do all three operations DEGAMMA, CSC,
>GAMMA for now, any chance you have a setup env with drm_hwcomposer and
>you would have time to help me with some testing after I would be writing the
>code ?
>

I can help with testing this out in some of our intel platforms. Will implement
the platform hooks for the same.

Let me know once you have the hwc changes ready.

Regards,
Uma Shankar

>Thank you,
>Alex Gheorghe
>
>> >
>> >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote:
>> >> This patch series adds properties for plane color features. It adds
>> >> properties for degamma used to linearize data, CSC used for gamut
>> >> conversion, and gamma used to again non-linearize data as per panel
>> >> supported color space. These can be utilize by user space to
>> >> convert planes from one format to another, one color space to another etc.
>> >>
>> >> Usersapce can take smart blending decisions and utilize these
>> >> hardware supported plane color features to get accurate color
>> >> profile. The same can help in consistent color quality from source
>> >> to panel taking advantage of advanced color features in hardware.
>> >>
>> >> These patches just add the property interfaces and enable helper
>> >> functions.
>> >>
>> >> This series adds Intel Gen9 specific plane gamma feature. We can
>> >> build up and add other platform/hardware specific implementation on
>> >> top of this series
>> >>
>> >> Note: This is just to get a design feedback whether these
>> >> interfaces look ok. Based on community feedback on interfaces, we
>> >> will implement IGT tests to validate plane color features. This is 
>> >> un-tested
>currently.
>> >> Also, userspace implementation to use these properties is currently
>> >> not available.
>> >>
>> >> v2: Dropped legacy gamma table for plane as suggested by Maarten.
>> >> Added Gen9/BDW plane gamma feature and rebase on tot.
>> >>
>> >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit
>> >> precision entries, pointed to by Brian, Starkey for HDR usecases.
>> >> Addressed Sean,Paul comments and moved plane color properties to
>> >> drm_plane instead of mode_config. Added property documentation as
>> >suggested by Daniel, Vetter.
>> >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov.
>> >>
>> >> Uma Shankar (8):
>> >>   drm: Add Enhanced Gamma LUT precision structure
>> >>   drm: Add Plane Degamma properties
>> >>   drm: Add Plane CTM property
>> >>   drm: Add Plane Gamma properties
>> >>   drm: Define helper function for plane color enabling
>> >>   drm/i915: Enable plane color features
>> >>   drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
>> >>   drm/i915: Load plane color luts from atomic flip
>> >>
>> >>  Documentation/gpu/drm-kms.rst |  18 
>> >>  drivers/gpu/drm/drm_atomic.c  |  30 +++
>> >>  drivers/gpu/drm/drm_atomic_helper.c   |  12 +++
>> >>  drivers/gpu/drm/drm_plane.c   | 131
>> >++
>> >>  drivers/gpu/drm/i915/i915_drv.h   |   5 ++
>> >>  drivers/gpu/drm/i915/i915_pci.c   |   5 +-
>> >>  drivers/gpu/drm/i915/i915_reg.h   |  24 ++
>> >>  drivers/gpu/drm/i915/intel_atomic_plane.c |   4 +
>> >>  drivers/gpu/drm/i915/intel_color.c|  80 ++
>> >>  drivers/gpu/drm/i915/intel_device_info.h  |   5 ++
>> >>  drivers/gpu/drm/i915/intel_display.c  |   4 +
>> >>  drivers/gpu/drm/i915/intel_drv.h  |  10 +++
>> >>  drivers/gpu/drm/i915/intel_sprite.c   |   4 +
>> >>  include/drm/drm_color_mgmt.h  |   5 ++
>> >>  include/drm/drm_plane.h   |  66 +++
>> >>  include/uapi/drm/drm_mode.h   |  15 
>> >>  16 files changed, 417 

[PATCH v3 05/27] docs: Fix some broken references

[Mauro Carvalho Chehab]

As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix

Manually checked if the produced result is valid, removing a few
false-positives.

Acked-by: Takashi Iwai 
Acked-by: Masami Hiramatsu 
Acked-by: Stephen Boyd 
Acked-by: Charles Keepax 
Acked-by: Mathieu Poirier 
Signed-off-by: Mauro Carvalho Chehab 
---
 .../admin-guide/kernel-parameters.txt |  4 ++--
 .../bindings/input/rotary-encoder.txt |  2 +-
 Documentation/driver-api/gpio/consumer.rst|  2 +-
 Documentation/kprobes.txt |  4 ++--
 Documentation/trace/coresight.txt |  2 +-
 Documentation/trace/ftrace-uses.rst   |  2 +-
 Documentation/trace/histogram.txt |  2 +-
 Documentation/trace/intel_th.rst  |  2 +-
 Documentation/trace/tracepoint-analysis.rst   |  6 +++---
 Documentation/translations/ja_JP/howto.rst|  4 ++--
 .../translations/zh_CN/magic-number.txt   |  4 ++--
 .../zh_CN/video4linux/omap3isp.txt|  4 ++--
 MAINTAINERS   | 20 +--
 arch/Kconfig  |  2 +-
 arch/arm/include/asm/cacheflush.h |  2 +-
 arch/arm64/include/asm/cacheflush.h   |  2 +-
 arch/microblaze/include/asm/cacheflush.h  |  2 +-
 arch/um/Kconfig.um|  2 +-
 arch/unicore32/include/asm/cacheflush.h   |  2 +-
 arch/x86/entry/vsyscall/vsyscall_64.c |  2 +-
 arch/xtensa/include/asm/cacheflush.h  |  4 ++--
 block/Kconfig |  2 +-
 certs/Kconfig |  2 +-
 crypto/asymmetric_keys/asymmetric_type.c  |  2 +-
 crypto/asymmetric_keys/signature.c|  2 +-
 drivers/char/Kconfig  |  2 +-
 drivers/clk/clk.c |  4 ++--
 drivers/clk/ingenic/cgu.h |  2 +-
 drivers/gpu/vga/Kconfig   |  2 +-
 drivers/gpu/vga/vgaarb.c  |  2 +-
 drivers/input/joystick/Kconfig| 10 +-
 drivers/input/joystick/walkera0701.c  |  2 +-
 drivers/input/misc/Kconfig|  4 ++--
 drivers/input/misc/rotary_encoder.c   |  2 +-
 drivers/input/mouse/Kconfig   |  6 +++---
 drivers/input/mouse/alps.c|  2 +-
 drivers/input/touchscreen/wm97xx-core.c   |  2 +-
 drivers/lightnvm/pblk-rb.c|  2 +-
 drivers/md/bcache/Kconfig |  2 +-
 drivers/md/bcache/btree.c |  2 +-
 drivers/md/bcache/extents.c   |  2 +-
 drivers/media/dvb-core/dvb_ringbuffer.c   |  2 +-
 drivers/media/pci/meye/Kconfig|  2 +-
 drivers/media/platform/pxa_camera.c   |  4 ++--
 .../soc_camera/sh_mobile_ceu_camera.c |  2 +-
 drivers/media/radio/Kconfig   |  2 +-
 drivers/media/radio/si470x/Kconfig|  2 +-
 drivers/media/usb/dvb-usb-v2/lmedm04.c|  2 +-
 drivers/media/usb/zr364xx/Kconfig |  2 +-
 drivers/parport/Kconfig   |  6 +++---
 drivers/staging/media/bcm2048/TODO|  2 +-
 include/keys/asymmetric-subtype.h |  2 +-
 include/keys/asymmetric-type.h|  2 +-
 include/linux/assoc_array.h   |  2 +-
 include/linux/assoc_array_priv.h  |  2 +-
 include/linux/circ_buf.h  |  2 +-
 include/linux/ftrace.h|  2 +-
 include/linux/rculist_nulls.h |  2 +-
 include/uapi/linux/prctl.h|  2 +-
 include/xen/interface/io/kbdif.h  |  2 +-
 kernel/cgroup/cpuset.c|  2 +-
 kernel/trace/Kconfig  | 16 +++
 lib/Kconfig   |  2 +-
 security/selinux/hooks.c  |  2 +-
 sound/core/Kconfig|  4 ++--
 sound/drivers/Kconfig |  4 ++--
 sound/pci/Kconfig | 10 +-
 tools/include/uapi/linux/prctl.h  |  2 +-
 tools/lib/api/fs/fs.c |  2 +-
 tools/perf/util/bpf-prologue.c|  2 +-
 .../config/custom-timeline-functions.cfg  |  4 ++--
 71 files changed, 113 insertions(+), 113 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 638342d0a095..6fa3f31ed2a5 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4335,7 +4335,7 @@
[FTRACE] Set and start specified trace events in order
to facilitate early boot debugging. The event-list is a
comma separated list of trace events to enable. See
-   also 

[PATCH v3 16/27] docs: Fix more broken references

[Mauro Carvalho Chehab]

As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix

Manually checked that produced results are valid.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../devicetree/bindings/clock/st/st,clkgen.txt |  8 
 .../devicetree/bindings/clock/ti/gate.txt  |  2 +-
 .../devicetree/bindings/clock/ti/interface.txt |  2 +-
 .../bindings/cpufreq/cpufreq-mediatek.txt  |  2 +-
 .../devicetree/bindings/devfreq/rk3399_dmc.txt |  2 +-
 .../bindings/gpu/arm,mali-midgard.txt  |  2 +-
 .../bindings/gpu/arm,mali-utgard.txt   |  2 +-
 .../devicetree/bindings/mfd/mt6397.txt |  2 +-
 .../devicetree/bindings/mfd/sun6i-prcm.txt |  2 +-
 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |  2 +-
 .../devicetree/bindings/net/dsa/ksz.txt|  2 +-
 .../devicetree/bindings/net/dsa/mt7530.txt |  2 +-
 .../devicetree/bindings/power/fsl,imx-gpc.txt  |  2 +-
 .../bindings/power/wakeup-source.txt   |  2 +-
 .../devicetree/bindings/usb/rockchip,dwc3.txt  |  2 +-
 Documentation/hwmon/ina2xx |  2 +-
 Documentation/maintainer/pull-requests.rst |  2 +-
 Documentation/translations/ko_KR/howto.rst |  2 +-
 MAINTAINERS| 18 +-
 drivers/net/ethernet/intel/Kconfig |  8 
 drivers/soundwire/stream.c |  8 
 fs/Kconfig.binfmt  |  2 +-
 fs/binfmt_misc.c   |  2 +-
 23 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt 
b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
index 7364953d0d0b..45ac19bfa0a9 100644
--- a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
@@ -31,10 +31,10 @@ This binding uses the common clock binding[1].
 Each subnode should use the binding described in [2]..[7]
 
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt
-[4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt
-[7] Documentation/devicetree/bindings/clock/st,quadfs.txt
-[8] Documentation/devicetree/bindings/clock/st,flexgen.txt
+[3] Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
+[4] Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
+[7] Documentation/devicetree/bindings/clock/st/st,quadfs.txt
+[8] Documentation/devicetree/bindings/clock/st/st,flexgen.txt
 
 
 Required properties:
diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt 
b/Documentation/devicetree/bindings/clock/ti/gate.txt
index 03f8fdee62a7..56d603c1f716 100644
--- a/Documentation/devicetree/bindings/clock/ti/gate.txt
+++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
@@ -10,7 +10,7 @@ will be controlled instead and the corresponding hw-ops for
 that is used.
 
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
 [3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
 
 Required properties:
diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt 
b/Documentation/devicetree/bindings/clock/ti/interface.txt
index 3111a409fea6..3f4704040140 100644
--- a/Documentation/devicetree/bindings/clock/ti/interface.txt
+++ b/Documentation/devicetree/bindings/clock/ti/interface.txt
@@ -9,7 +9,7 @@ companion clock finding (match corresponding functional gate
 clock) and hardware autoidle enable / disable.
 
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
 
 Required properties:
 - compatible : shall be one of:
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
index d36f07e0a2bb..0551c78619de 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
@@ -8,7 +8,7 @@ Required properties:
"intermediate"  - A parent of "cpu" clock which is used as 
"intermediate" clock
  source (usually MAINPLL) when the original CPU PLL is 
under
  transition and not stable yet.
-   Please refer to 
Documentation/devicetree/bindings/clk/clock-bindings.txt for
+   Please refer to 
Documentation/devicetree/bindings/clock/clock-bindings.txt for
generic clock consumer properties.
 - operating-points-v2: Please refer to 
Documentation/devicetree/bindings/opp/opp.txt
for detail.
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
index 

[PATCH v3 04/27] docs: fix broken references with multiple hints

[Mauro Carvalho Chehab]

The script:
./scripts/documentation-file-ref-check --fix-rst

Gives multiple hints for broken references on some files.
Manually use the one that applies for some files.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/ABI/obsolete/sysfs-gpio | 2 +-
 .../devicetree/bindings/display/bridge/tda998x.txt| 2 +-
 Documentation/trace/events.rst| 2 +-
 Documentation/trace/tracepoint-analysis.rst   | 2 +-
 Documentation/translations/zh_CN/SubmittingDrivers| 2 +-
 Documentation/translations/zh_CN/gpio.txt | 4 ++--
 MAINTAINERS   | 2 +-
 drivers/hid/usbhid/Kconfig| 2 +-
 drivers/input/Kconfig | 4 ++--
 drivers/input/joystick/Kconfig| 4 ++--
 drivers/input/joystick/iforce/Kconfig | 4 ++--
 drivers/input/serio/Kconfig   | 4 ++--
 drivers/staging/fsl-mc/bus/dpio/dpio-driver.txt   | 2 +-
 drivers/video/fbdev/skeletonfb.c  | 8 
 include/linux/tracepoint.h| 2 +-
 security/device_cgroup.c  | 2 +-
 16 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/Documentation/ABI/obsolete/sysfs-gpio 
b/Documentation/ABI/obsolete/sysfs-gpio
index 32513dc2eec9..40d41ea1a3f5 100644
--- a/Documentation/ABI/obsolete/sysfs-gpio
+++ b/Documentation/ABI/obsolete/sysfs-gpio
@@ -11,7 +11,7 @@ Description:
   Kernel code may export it for complete or partial access.
 
   GPIOs are identified as they are inside the kernel, using integers in
-  the range 0..INT_MAX.  See Documentation/gpio/gpio.txt for more information.
+  the range 0..INT_MAX.  See Documentation/gpio for more information.
 
 /sys/class/gpio
/export ... asks the kernel to export a GPIO to userspace
diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt 
b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
index 1a4eaca40d94..f5a02f61dd36 100644
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
@@ -30,7 +30,7 @@ Optional properties:
   - nxp,calib-gpios: calibration GPIO, which must correspond with the
gpio used for the TDA998x interrupt pin.
 
-[1] Documentation/sound/alsa/soc/DAI.txt
+[1] Documentation/sound/soc/dai.rst
 [2] include/dt-bindings/display/tda998x.h
 
 Example:
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index 1afae55dc55c..696dc69b8158 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -8,7 +8,7 @@ Event Tracing
 1. Introduction
 ===
 
-Tracepoints (see Documentation/trace/tracepoints.txt) can be used
+Tracepoints (see Documentation/trace/tracepoints.rst) can be used
 without creating custom kernel modules to register probe functions
 using the event tracing infrastructure.
 
diff --git a/Documentation/trace/tracepoint-analysis.rst 
b/Documentation/trace/tracepoint-analysis.rst
index a4d3ff2e5efb..bef37abf4ad3 100644
--- a/Documentation/trace/tracepoint-analysis.rst
+++ b/Documentation/trace/tracepoint-analysis.rst
@@ -6,7 +6,7 @@ Notes on Analysing Behaviour Using Events and Tracepoints
 1. Introduction
 ===
 
-Tracepoints (see Documentation/trace/tracepoints.txt) can be used without
+Tracepoints (see Documentation/trace/tracepoints.rst) can be used without
 creating custom kernel modules to register probe functions using the event
 tracing infrastructure.
 
diff --git a/Documentation/translations/zh_CN/SubmittingDrivers 
b/Documentation/translations/zh_CN/SubmittingDrivers
index 929385e4b194..15e73562f710 100644
--- a/Documentation/translations/zh_CN/SubmittingDrivers
+++ b/Documentation/translations/zh_CN/SubmittingDrivers
@@ -107,7 +107,7 @@ Linux 2.6:
程序测试的指导，请参阅
Documentation/power/drivers-testing.txt。有关驱动程序电
源管理问题相对全面的概述，请参阅
-   Documentation/power/admin-guide/devices.rst。
+   Documentation/driver-api/pm/devices.rst。
 
 管理：如果一个驱动程序的作者还在进行有效的维护，那么通常除了那
些明显正确且不需要任何检查的补丁以外，其他所有的补丁都会
diff --git a/Documentation/translations/zh_CN/gpio.txt 
b/Documentation/translations/zh_CN/gpio.txt
index 4f8bf30a41dc..4cb1ba8b8fed 100644
--- a/Documentation/translations/zh_CN/gpio.txt
+++ b/Documentation/translations/zh_CN/gpio.txt
@@ -1,4 +1,4 @@
-Chinese translated version of Documentation/gpio.txt
+Chinese translated version of Documentation/gpio
 
 If you have any comment or update to the content, please contact the
 original document maintainer directly.  However, if you have a problem
@@ -10,7 +10,7 @@ Maintainer: Grant Likely 
Linus Walleij 
 Chinese maintainer: Fu Wei 
 

Re: [PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu

[Jordan Crouse]

On Thu, Jun 14, 2018 at 12:30:35PM +0530, Vivek Gautam wrote:
> Hi Jordan,
> 
> On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse  
> wrote:
> > Now that the IOMMU is the master of it's own power we don't need to bring
> > up the GPU to do IOMMU operations. This is good because bringing up a6xx
> > requires the GMU so calling pm_runtime_get_sync() too early in the process
> > gets us into some nasty circular dependency situations.
> 
> Thanks for the patch.
> While you are removing these calls, we should add pm_runtime calls
> to qcom_iommu_map(). That should make qcom_iommu too master of
> its power control.
> Then we should be good to go with this patch.

Right - I told Rob about that in IRC but I should have mentioned it here as
well. In order to do this we need to be sure that all of of the possible MMU
combinations are covered.

> >
> > Signed-off-by: Jordan Crouse 
> > ---
> >  drivers/gpu/drm/msm/msm_iommu.c | 8 
> >  1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
> > b/drivers/gpu/drm/msm/msm_iommu.c
> > index b23d33622f37..ccd93ac6a4d8 100644
> > --- a/drivers/gpu/drm/msm/msm_iommu.c
> > +++ b/drivers/gpu/drm/msm/msm_iommu.c
> > @@ -40,9 +40,7 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const 
> > char * const *names,
> > struct msm_iommu *iommu = to_msm_iommu(mmu);
> > int ret;
> >
> > -   pm_runtime_get_sync(mmu->dev);
> > ret = iommu_attach_device(iommu->domain, mmu->dev);
> > -   pm_runtime_put_sync(mmu->dev);
> 
> may be just do the following here.
>return iommu_attach_device(iommu->domain, mmu->dev);

I'll do that. Thanks.

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

[PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap

[Chris Wilson]

If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.

Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least reject in the call to create the mmap (with a sanity check
in the fault handler).

v2: Check the vma->vm_flags during mmap() to allow readonly access.

Signed-off-by: Chris Wilson 
Cc: Jon Bloomfield 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Cc: David Herrmann 
---
 drivers/gpu/drm/drm_gem.c |  5 +
 drivers/gpu/drm/i915/i915_gem.c   |  4 
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 12 +++-
 drivers/gpu/drm/i915/i915_gem_object.h|  7 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_context.c |  5 +++--
 include/drm/drm_vma_manager.h |  1 +
 7 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4a16d7b26c89..230863813905 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1036,6 +1036,11 @@ int drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return -EACCES;
}
 
+   if (vma->vm_flags & VM_WRITE && node->readonly) {
+   drm_gem_object_put_unlocked(obj);
+   return -EINVAL;
+   }
+
ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT,
   vma);
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8dd4d35655af..2bfb16e83af2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2009,6 +2009,10 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
unsigned int flags;
int ret;
 
+   /* Sanity check that we allow writing into this object */
+   if (i915_gem_object_is_readonly(obj) && write)
+   return VM_FAULT_SIGBUS;
+
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ca84616fbe24..d57f0154b6cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -198,7 +198,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
 
/* Applicable to VLV, and gen8+ */
pte_flags = 0;
-   if (vma->obj->gt_ro)
+   if (i915_gem_object_is_readonly(vma->obj))
pte_flags |= PTE_READ_ONLY;
 
vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
@@ -2416,8 +2416,10 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
 
-   /* The GTT does not support read-only mappings */
-   GEM_BUG_ON(flags & PTE_READ_ONLY);
+   /*
+* Note that we ignore PTE_READ_ONLY here. The caller must be careful
+* not to allow the user to override access to a read only page.
+*/
 
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
gtt_entries += vma->node.start >> PAGE_SHIFT;
@@ -2656,7 +2658,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
 
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
-   if (obj->gt_ro)
+   if (i915_gem_object_is_readonly(obj))
pte_flags |= PTE_READ_ONLY;
 
intel_runtime_pm_get(i915);
@@ -2694,7 +2696,7 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
 
/* Currently applicable only to VLV */
pte_flags = 0;
-   if (vma->obj->gt_ro)
+   if (i915_gem_object_is_readonly(vma->obj))
pte_flags |= PTE_READ_ONLY;
 
if (flags & I915_VMA_LOCAL_BIND) {
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index 54f00b350779..66e30aa4b7da 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -141,7 +141,6 @@ struct drm_i915_gem_object {
 * Is the object to be mapped as read-only to the GPU
 * Only honoured if hardware has relevant pte bit
 */
-   unsigned long gt_ro:1;
unsigned int cache_level:3;
unsigned int cache_coherent:2;
 #define I915_BO_CACHE_COHERENT_FOR_READ BIT(0)
@@ -367,6 +366,12 @@ static inline void i915_gem_object_unlock(struct 
drm_i915_gem_object *obj)
reservation_object_unlock(obj->resv);
 }
 
+static inline bool
+i915_gem_object_is_readonly(const struct drm_i915_gem_object *obj)
+{
+   return obj->base.vma_node.readonly;
+}
+
 static inline bool
 i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 

Re: [DPU PATCH 4/4] drm/msm/dpu: use private obj to track hw resources

[Sean Paul]

On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> Switch to state based resource management. This patch
> overhauls the resource manager and HW allocation methods by
> maintaining the global resource pool and allocated hw
> blocks in respective drm component states.
> 
> Global resource manager(RM) is tracked in private object.
> Allocation strategy is switched from single point allocation
> of HW resources for the display pipeline to per component
> based allocation, where each drm component allocates HW
> blocks mapped to it's domain and tracks them in their respective
> state objects.
> 
> Fixes resource contention due to race conditions between
> user space and display thread by reserving resources
> only in atomic check.
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 210 +++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |  59 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   4 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   9 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  32 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  86 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  19 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   8 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805 
> ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++--
>  11 files changed, 534 insertions(+), 1070 deletions(-)

Ok, there's a lot going on here. It's pretty easy to review megapatches where
the diffstat is mostly negative. However, this patch has a lot of code deleted
and moving around, along with the new private obj. It's really hard to review
changes like this.

Could you please split this up into a bunch of simple patches which do one
thing? ie: Moving topology is a patch, using cstate instead of crtc is a patch,
using private obj is a patch, etc, etc.

Basically, cut things down into small enough pieces such that each patch can
be easily explained without using "and" in the commit message :-)

/snip

> +
>   dpu_crtc = to_dpu_crtc(crtc);
>   cstate = to_dpu_crtc_state(crtc->state);
>   mode = >base.adjusted_mode;
>   priv = crtc->dev->dev_private;
> + dpu_kms = to_dpu_kms(priv->kms);
> +
> + /* accessing after swap state. piv_obj.state is the current state */

s/piv_obj/priv_obj/

> + dpu_priv_state = to_dpu_private_state(dpu_kms->priv_obj.state);
>  
>   DPU_DEBUG("crtc%d\n", crtc->base.id);
>  

/snip

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200045] black screen on 'radeon' module probing

[bugzilla-daemon]

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

--- Comment #10 from cerg2010cerg2...@mail.ru ---
Here is the output:

[   23.056329]  (null): initial SCL state 1
[   23.056330]  (null): initial SDA state 1
[   23.056532]  (null): initial SCL state 1
[   23.056534]  (null): initial SDA state 1
[   23.056578]  (null): initial SCL state 0
[   23.056580]  (null): initial SDA state 0
[   23.056617]  (null): initial SCL state 0
[   23.056618]  (null): initial SDA state 0
[   23.056656]  (null): initial SCL state 0
[   23.056657]  (null): initial SDA state 0

-- 
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 106872] vram sizes reported by the kernel totally off

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|dri-devel@lists.freedesktop |mic...@daenzer.net
   |.org|

--- Comment #3 from Michel Dänzer  ---
Created attachment 140160
  --> https://bugs.freedesktop.org/attachment.cgi?id=140160=edit
drm/amdgpu: Refactor amdgpu_vram_mgr_bo_sizes helper

-- 
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 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32

[bugzilla-daemon]

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

--- Comment #22 from Michel Dänzer  ---
(In reply to sam.psylo from comment #20)
> I am still suffering from this issue, even with latest firmware from comment
> 15.

Please file your own report. This report is resolved.


> Firmware: 20180525-85.git7518922b.fc28 (current Fedora release), but with
> vega10_vce.bin from comment 15 replacing the one installed by the package.

Did you double-check that's the only file which differs from the ones you have?

-- 
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: [DPU PATCH 0/4] Atomic resource management

[Sean Paul]

On Tue, Jun 12, 2018 at 06:17:43PM -0700, Jeykumar Sankaran wrote:
> This patchset introduces drm private object in KMS to manage HW
> resource management. It modifies the resource manager by
> introducing API's to do per DRM object resource allocation/cleanups.
> 
> The patchset is based on: https://patchwork.kernel.org/patch/10461375/
> 
> Jeykumar Sankaran (4):
>   drm/msm/dpu: add atomic private object to dpu kms
>   drm/msm/dpu: remove scalar config definitions
>   drm/msm/dpu: remove resource pool manager
>   drm/msm/dpu: use private obj to track hw resources

Kind of an odd arrangement of patches. Since you're respinning anyways, can you
please reorder to:

   drm/msm/dpu: remove scalar config definitions
   drm/msm/dpu: remove resource pool manager
   drm/msm/dpu: add atomic private object to dpu kms
   drm/msm/dpu: use private obj to track hw resources

Sean

> 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 704 +++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   | 144 ++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   4 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   9 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  32 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  86 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h|  10 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  85 ++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|  23 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805 
> ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++--
>  12 files changed, 615 insertions(+), 1659 deletions(-)
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH 4/4] drm/msm/dpu: use private obj to track hw resources

[Sean Paul]

On Wed, Jun 13, 2018 at 12:01:21PM -0700, Jeykumar Sankaran wrote:
> On 2018-06-13 09:44, Jordan Crouse wrote:
> > On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> > > Switch to state based resource management. This patch
> > > overhauls the resource manager and HW allocation methods by
> > > maintaining the global resource pool and allocated hw
> > > blocks in respective drm component states.
> > > 
> > > Global resource manager(RM) is tracked in private object.
> > > Allocation strategy is switched from single point allocation
> > > of HW resources for the display pipeline to per component
> > > based allocation, where each drm component allocates HW
> > > blocks mapped to it's domain and tracks them in their respective
> > > state objects.
> > > 
> > > Fixes resource contention due to race conditions between
> > > user space and display thread by reserving resources
> > > only in atomic check.
> > > 
> > > Signed-off-by: Jeykumar Sankaran 
> > > ---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 210 +++---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |  59 +-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   4 -
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   9 +-
> > >  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  32 +-
> > >  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  86 +--
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  19 +-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   8 +-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805
> > ++---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++--
> > >  11 files changed, 534 insertions(+), 1070 deletions(-)

/snip

> > cstate->num_mixers);
> > 
> > Nit - this could be worded a bit better - "too many mixers" would be
> > better, but
> > I have to ask - under what circumstances would the number of mixers be
> > larger
> > than CRTC_DUAL_MIXERS and/or why don't we support a dynamic number of
> > mixers?
> > 
> Comes from downstream driver implementation where CRTC iterates through
> RM free pool to identify mixers tagged with the current crtc id. If the
> previous clean up was screwed up this may have more than 2 mixers. With
> the new state based RM, its very unlikely we hit this condition.
> 

In this case, add a comment with "/* This should never happen */"

I'm just kidding, that would virtually guarantee that it does happen and we
certainly don't need that bad juju around!

Sean

> We do support dynamic mixer counts. Based on the connector (panel)
> resolution,
> CRTC allocates 1 or 2 (panel_width > hw mixer width) mixer block(s) on the
> first
> atomic check. DPU limits max no. of hw mixers that can be ganged up for a
> display to 2.
> 
> > >   return;
> > >   }
> > 

/snip

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: mali-dp: Add debugfs file for reporting internal errors

[Liviu Dudau]

On Tue, May 15, 2018 at 11:18:50AM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the errors,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA models which have a lot of constraints, so we could easily
> end up in AXI or underrun errors.
> 
> Add a new file called debug that contains an aggregate of the
> errors reported by the Mali DP hardware.

Hi Alex,

Sorry, I thought I had Acked this one already, but I cannot find the
proof, so:

Acked-by: Liviu Dudau 

Best regards,
Liviu

> 
> E.g:
> [root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
> [DE] num_errors : 167
> [DE] last_error_status  : 0x0001
> [DE] last_error_vblank : 385
> [SE] num_errors : 3
> [SE] last_error_status  : 0x00e23001
> [SE] last_error_vblank : 201
> 
> Changes since v2:
> - Add lock to protect the errors stats.
> - Add possibility to reset the error stats by writing anything to the
>   debug file.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drivers/gpu/drm/arm/malidp_drv.c  | 104 
> ++
>  drivers/gpu/drm/arm/malidp_drv.h  |  19 +++
>  drivers/gpu/drm/arm/malidp_hw.c   |  46 ++---
>  drivers/gpu/drm/arm/malidp_hw.h   |   1 +
>  drivers/gpu/drm/arm/malidp_regs.h |   6 +++
>  5 files changed, 169 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 8d20faa..8bfeb46 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -327,6 +328,106 @@ static int malidp_dumb_create(struct drm_file 
> *file_priv,
>   return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
>  }
>  
> +#ifdef CONFIG_DEBUG_FS
> +
> +static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
> +{
> + error_stats->num_errors = 0;
> + error_stats->last_error_status = 0;
> + error_stats->last_error_vblank = -1;
> +}
> +
> +void malidp_error(struct malidp_drm *malidp,
> +   struct malidp_error_stats *error_stats, u32 status,
> +   u64 vblank)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>errors_lock, irqflags);
> + error_stats->last_error_status = status;
> + error_stats->last_error_vblank = vblank;
> + error_stats->num_errors++;
> + spin_unlock_irqrestore(>errors_lock, irqflags);
> +}
> +
> +void malidp_error_stats_dump(const char *prefix,
> +  struct malidp_error_stats error_stats,
> +  struct seq_file *m)
> +{
> + seq_printf(m, "[%s] num_errors : %d\n", prefix,
> +error_stats.num_errors);
> + seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
> +error_stats.last_error_status);
> + seq_printf(m, "[%s] last_error_vblank : %lld\n", prefix,
> +error_stats.last_error_vblank);
> +}
> +
> +static int malidp_show_stats(struct seq_file *m, void *arg)
> +{
> + struct drm_device *drm = m->private;
> + struct malidp_drm *malidp = drm->dev_private;
> + unsigned long irqflags;
> + struct malidp_error_stats de_errors, se_errors;
> +
> + spin_lock_irqsave(>errors_lock, irqflags);
> + de_errors = malidp->de_errors;
> + se_errors = malidp->se_errors;
> + spin_unlock_irqrestore(>errors_lock, irqflags);
> + malidp_error_stats_dump("DE", de_errors, m);
> + malidp_error_stats_dump("SE", se_errors, m);
> + return 0;
> +}
> +
> +static int malidp_debugfs_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, malidp_show_stats, inode->i_private);
> +}
> +
> +static ssize_t malidp_debugfs_write(struct file *file, const char __user 
> *ubuf,
> + size_t len, loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct drm_device *drm = m->private;
> + struct malidp_drm *malidp = drm->dev_private;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>errors_lock, irqflags);
> + malidp_error_stats_init(>de_errors);
> + malidp_error_stats_init(>se_errors);
> + spin_unlock_irqrestore(>errors_lock, irqflags);
> + return len;
> +}
> +
> +static const struct file_operations malidp_debugfs_fops = {
> + .owner = THIS_MODULE,
> + .open = malidp_debugfs_open,
> + .read = seq_read,
> + .write = malidp_debugfs_write,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> +static int malidp_debugfs_init(struct drm_minor *minor)
> +{
> + struct malidp_drm *malidp = minor->dev->dev_private;
> + struct dentry *dentry = NULL;
> +
> + malidp_error_stats_init(>de_errors);
> + malidp_error_stats_init(>se_errors);
> + spin_lock_init(>errors_lock);
> + dentry = 

[Bug 200045] black screen on 'radeon' module probing

[bugzilla-daemon]

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

--- Comment #9 from Wolfram Sang (w...@the-dreams.de) ---
Created attachment 276551
  --> https://bugzilla.kernel.org/attachment.cgi?id=276551=edit
print initial states to allow further debug

Thanks for testing the patches, pity it didn't help.

Would you mind testing with the attached patch? It should give some output
about the initial states. Let's hope that will lead to something...

-- 
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: [DPU PATCH] drm/msm: remove support for seamless modes

[Sean Paul]

On Tue, Jun 12, 2018 at 05:49:03PM -0700, Abhinav Kumar wrote:
> Seamless modes are ones which do not require a display
> to be turned OFF/ON between mode switches.
> 
> Remove support for seamless modes from DPU for now.
> 
> This will be added later based on additional requirements.
> 
> This change depends on the DPU custom property removal series:
>  - https://patchwork.freedesktop.org/series/44592/

Pushed to dpu-staging/for-next, thanks

Sean

> 
> Signed-off-by: Abhinav Kumar 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  31 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 106 
> +---
>  drivers/gpu/drm/msm/msm_kms.h   |  44 
>  include/uapi/drm/drm_mode.h |   1 -
>  4 files changed, 3 insertions(+), 179 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 4616a62..9ca8325 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -591,22 +591,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
>   kfree(dpu_crtc);
>  }
>  
> -static bool dpu_crtc_mode_fixup(struct drm_crtc *crtc,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - DPU_DEBUG("\n");
> -
> - if ((msm_is_mode_seamless(adjusted_mode) ||
> - msm_is_mode_seamless_vrr(adjusted_mode)) &&
> - (!crtc->enabled)) {
> - DPU_ERROR("crtc state prevents seamless transition\n");
> - return false;
> - }
> -
> - return true;
> -}
> -
>  static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
>   struct dpu_plane_state *pstate)
>  {
> @@ -1728,12 +1712,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
>   mode = >base.adjusted_mode;
>   priv = crtc->dev->dev_private;
>  
> - if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode) ||
> - msm_is_mode_seamless_dms(mode)) {
> - DPU_DEBUG("Seamless mode is being applied, skip disable\n");
> - return;
> - }
> -
>   DPU_DEBUG("crtc%d\n", crtc->base.id);
>  
>   if (dpu_kms_is_suspend_state(crtc->dev))
> @@ -1817,12 +1795,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
>   DPU_EVT32_VERBOSE(DRMID(crtc));
>   dpu_crtc = to_dpu_crtc(crtc);
>  
> - if (msm_is_mode_seamless(>state->adjusted_mode) ||
> - msm_is_mode_seamless_vrr(>state->adjusted_mode)) {
> - DPU_DEBUG("Skipping crtc enable, seamless mode\n");
> - return;
> - }
> -
>   drm_for_each_encoder(encoder, crtc->dev) {
>   if (encoder->crtc != crtc)
>   continue;
> @@ -1857,8 +1829,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
>   DPU_POWER_EVENT_PRE_DISABLE,
>   dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
>  
> - if (msm_needs_vblank_pre_modeset(>state->adjusted_mode))
> - drm_crtc_wait_one_vblank(crtc);
>  }
>  
>  struct plane_state {
> @@ -2497,7 +2467,6 @@ static void dpu_crtc_early_unregister(struct drm_crtc 
> *crtc)
>  };
>  
>  static const struct drm_crtc_helper_funcs dpu_crtc_helper_funcs = {
> - .mode_fixup = dpu_crtc_mode_fixup,
>   .disable = dpu_crtc_disable,
>   .atomic_enable = dpu_crtc_enable,
>   .atomic_check = dpu_crtc_atomic_check,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 7dd609c..11a1045 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -96,15 +96,6 @@
>   *   IDLE is expected when IDLE_PC has run, and PRE_OFF did nothing.
>   *   PRE_OFF is expected when PRE_STOP was executed during the ON state.
>   *   Resource state should be in OFF at the end of the event.
> - * @DPU_ENC_RC_EVENT_PRE_MODESET:
> - *   This event happens at NORMAL priority from a work item.
> - *   Event signals that there is a seamless mode switch is in prgoress. A
> - *   client needs to turn of only irq - leave clocks ON to reduce the mode
> - *   switch latency.
> - * @DPU_ENC_RC_EVENT_POST_MODESET:
> - *   This event happens at NORMAL priority from a work item.
> - *   Event signals that seamless mode switch is complete and resources are
> - *   acquired. Clients wants to turn on the irq again.
>   * @DPU_ENC_RC_EVENT_ENTER_IDLE:
>   *   This event happens at NORMAL priority from a work item.
>   *   Event signals that there were no frame updates for IDLE_TIMEOUT time.
> @@ -116,8 +107,6 @@ enum dpu_enc_rc_events {
>   DPU_ENC_RC_EVENT_FRAME_DONE,
>   DPU_ENC_RC_EVENT_PRE_STOP,
>   DPU_ENC_RC_EVENT_STOP,
> - DPU_ENC_RC_EVENT_PRE_MODESET,
> - DPU_ENC_RC_EVENT_POST_MODESET,
>   DPU_ENC_RC_EVENT_ENTER_IDLE
>  };
>  
> @@ -133,7 +122,6 @@ enum dpu_enc_rc_states {
>   DPU_ENC_RC_STATE_OFF,
>

Re: [DPU PATCH v3 0/7] clean up DPU custom properties

[Sean Paul]

On Mon, Jun 11, 2018 at 02:13:17PM -0700, Jeykumar Sankaran wrote:
> Submitting a series of patches to further clean up DPU driver by stripping
> down a list of custom properties supporting proprietary features. It 
> removes the property installers/handlers and cleans up relevant files of
> of some of the advanced features. This series is based on the patch[1] 
> available on the drm-next tip.
> 
> [1]https://patchwork.kernel.org/patch/10202847/

Pushed the set + cherry-pick of this patch to dpu-staging/for-next

Thanks,

Sean

> 
> Thanks.
> 
> changes in v2:
> - remove stale code in blend config
> - move unrelated code while updating zpos property
> - Makefile changes
> changes in v3:
> - rebase on https://gitlab.freedesktop.org/seanpaul/
>   dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
> 
> Thanks.
> 
> Jeykumar Sankaran (7):
>   drm/msm: remove connector custom properties
>   drm/msm/dpu: clean up dpu plane custom properties
>   drm/msm: enable zpos normalization
>   drm/msm/dpu: switch to drm zpos property
>   Remove dpu crtc custom properties and its handlers.
>   drm/msm: remove msm_prop files
>   drm/msm: remove dpu specific uapi header
> 
>  drivers/gpu/drm/msm/Makefile   |9 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h|   99 --
>  .../gpu/drm/msm/disp/dpu1/dpu_color_processing.c   | 1521 
> 
>  .../gpu/drm/msm/disp/dpu1/dpu_color_processing.h   |  120 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |   30 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 1328 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |   45 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|   14 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|2 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c | 1443 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   72 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   89 --
>  .../msm/disp/dpu1/dpu_hw_color_proc_common_v4.h|   69 -
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c   |  242 
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h   |   40 -
>  .../drm/msm/disp/dpu1/dpu_hw_color_processing.h|   20 -
>  .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.c   |  565 
>  .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.h   |   92 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c |   44 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |   15 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c  |  149 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h  |  111 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c|  209 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h|  220 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c  |   67 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h  |   14 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   58 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   68 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|6 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.c  |  757 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.h  |   27 -
>  .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.c   |  943 
>  .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.h   |   75 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c|  220 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h|   73 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c|1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h|  156 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|   11 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 1404 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h  |   43 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.c|  139 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.h|  310 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  149 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |2 -
>  drivers/gpu/drm/msm/msm_drv.c  |3 +
>  drivers/gpu/drm/msm/msm_drv.h  |   86 +-
>  drivers/gpu/drm/msm/msm_prop.c |  688 -
>  drivers/gpu/drm/msm/msm_prop.h |  438 --
>  include/uapi/drm/dpu_drm.h |  407 --
>  include/uapi/drm/msm_drm.h |1 -
>  include/uapi/drm/msm_drm_pp.h  |  345 -
>  51 files changed, 297 insertions(+), 12742 deletions(-)
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.c
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.h
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c
>  delete mode 100644 
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_common_v4.h
>  delete mode 

[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32

[bugzilla-daemon]

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

--- Comment #21 from sam.ps...@gmail.com ---
Created attachment 140159
  --> https://bugs.freedesktop.org/attachment.cgi?id=140159=edit
dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28

-- 
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 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32

[bugzilla-daemon]

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

--- Comment #20 from sam.ps...@gmail.com ---
Created attachment 140158
  --> https://bugs.freedesktop.org/attachment.cgi?id=140158=edit
dmesg w/mesa 18.0.2-1.fc28

I am still suffering from this issue, even with latest firmware from comment
15.
Kernel: 4.16.14-300.fc28.x86_64
Mesa: tested both 18.0.2-1.fc28 (current Fedora release) and
18.2.0-0.11.git41dabdc.fc28 (from che/mesa copr repo). Bug occurred on both.
Firmware: 20180525-85.git7518922b.fc28 (current Fedora release), but with
vega10_vce.bin from comment 15 replacing the one installed by the package.

My graphics card is a PowerColor RX Vega 64.

I am attaching two dmesgs: one with each mentioned tested Mesa version.

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

[PULL][drm-misc-next] drm_writeback patches

[Liviu Dudau]

Hello,

Please pull the generic drm_writeback patches into drm-misc-next. They
have been reviewed on the mailing lists for a while, and we have the
userspace and individual kernel driver's implementations using it.

The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5:

  Merge tag 'drm-intel-next-fixes-2018-06-08-2' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-06-09 06:34:51 
+1000)

are available in the Git repository at:

  git://linux-arm.org/linux-ld.git f989333aea5729639e522830af8d74dd6a4bd3cf

for you to fetch changes up to f989333aea5729639e522830af8d74dd6a4bd3cf:

  drm: writeback: Add client capability for exposing writeback connectors 
(2018-06-14 13:42:26 +0100)


Brian Starkey (2):
  drm: Add writeback connector type
  drm: writeback: Add out-fences for writeback connectors

Liviu Dudau (1):
  drm: writeback: Add client capability for exposing writeback connectors

 Documentation/gpu/drm-kms.rst|   9 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c | 223 +++-
 drivers/gpu/drm/drm_atomic_helper.c  |  25 +++
 drivers/gpu/drm/drm_connector.c  |   4 +-
 drivers/gpu/drm/drm_ioctl.c  |   7 +
 drivers/gpu/drm/drm_mode_config.c|   5 +
 drivers/gpu/drm/drm_writeback.c  | 350 +++
 include/drm/drm_atomic.h |  11 +
 include/drm/drm_connector.h  |  13 ++
 include/drm/drm_file.h   |   7 +
 include/drm/drm_mode_config.h|  23 ++
 include/drm/drm_modeset_helper_vtables.h |  11 +
 include/drm/drm_writeback.h  | 130 
 include/uapi/drm/drm.h   |   9 +
 include/uapi/drm/drm_mode.h  |   1 +
 16 files changed, 819 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_writeback.c
 create mode 100644 include/drm/drm_writeback.h
-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Peter Zijlstra]

On Thu, Jun 14, 2018 at 03:43:04PM +0200, Thomas Hellstrom wrote:
> It's intended to be enforced by storing the algorithm choice in the
> WW_MUTEX_CLASS which must be common for an acquire context and the
> ww_mutexes it acquires. However, I don't think there is a check that that
> holds. I guess we could add it as a DEBUG_MUTEX test in ww_mutex_lock().

There is ww_mutex_lock_acquired():

DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class)

which should trigger if you try and be clever.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Peter Zijlstra]

On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:
> The literature makes a distinction between "killed" and "wounded". In our
> context, "Killed" is when a transaction actually receives an -EDEADLK and
> needs to back off. "Wounded" is when someone (typically another transaction)
> requests a transaction to kill itself. A wound will often, but not always,
> lead to a kill. If the wounded transaction has finished its locking
> sequence, or has the opportunity to grab uncontended ww mutexes or steal
> contended (non-handoff) ww mutexes to finish its transaction it will do so
> and never kill itself.

Hopefully I got it all right this time; I folded your patch in and
mucked around with it a bit, but haven't done anything except compile
it.

I left the context/transaction thing because well, that's what we called
the thing.


diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 39fda195bf78..50ef5a10cfa0 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -8,6 +8,8 @@
  *
  * Wound/wait implementation:
  *  Copyright (C) 2013 Canonical Ltd.
+ * Choice of algorithm:
+ *  Copyright (C) 2018 WMWare Inc.
  *
  * This file contains the main data structure and API definitions.
  */
@@ -23,14 +25,17 @@ struct ww_class {
struct lock_class_key mutex_key;
const char *acquire_name;
const char *mutex_name;
+   unsigned int is_wait_die;
 };
 
 struct ww_acquire_ctx {
struct task_struct *task;
unsigned long stamp;
-   unsigned acquired;
+   unsigned int acquired;
+   unsigned short wounded;
+   unsigned short is_wait_die;
 #ifdef CONFIG_DEBUG_MUTEXES
-   unsigned done_acquire;
+   unsigned int done_acquire;
struct ww_class *ww_class;
struct ww_mutex *contending_lock;
 #endif
@@ -38,8 +43,8 @@ struct ww_acquire_ctx {
struct lockdep_map dep_map;
 #endif
 #ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
-   unsigned deadlock_inject_interval;
-   unsigned deadlock_inject_countdown;
+   unsigned int deadlock_inject_interval;
+   unsigned int deadlock_inject_countdown;
 #endif
 };
 
@@ -58,17 +63,21 @@ struct ww_mutex {
 # define __WW_CLASS_MUTEX_INITIALIZER(lockname, class)
 #endif
 
-#define __WW_CLASS_INITIALIZER(ww_class) \
+#define __WW_CLASS_INITIALIZER(ww_class, _is_wait_die) \
{ .stamp = ATOMIC_LONG_INIT(0) \
, .acquire_name = #ww_class "_acquire" \
-   , .mutex_name = #ww_class "_mutex" }
+   , .mutex_name = #ww_class "_mutex" \
+   , .is_wait_die = _is_wait_die }
 
 #define __WW_MUTEX_INITIALIZER(lockname, class) \
{ .base =  __MUTEX_INITIALIZER(lockname.base) \
__WW_CLASS_MUTEX_INITIALIZER(lockname, class) }
 
+#define DEFINE_WD_CLASS(classname) \
+   struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 1)
+
 #define DEFINE_WW_CLASS(classname) \
-   struct ww_class classname = __WW_CLASS_INITIALIZER(classname)
+   struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 0)
 
 #define DEFINE_WW_MUTEX(mutexname, ww_class) \
struct ww_mutex mutexname = __WW_MUTEX_INITIALIZER(mutexname, ww_class)
@@ -123,6 +132,8 @@ static inline void ww_acquire_init(struct ww_acquire_ctx 
*ctx,
ctx->task = current;
ctx->stamp = atomic_long_inc_return_relaxed(_class->stamp);
ctx->acquired = 0;
+   ctx->wounded = false;
+   ctx->is_wait_die = ww_class->is_wait_die;
 #ifdef CONFIG_DEBUG_MUTEXES
ctx->ww_class = ww_class;
ctx->done_acquire = 0;
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index f44f658ae629..9e244af4647d 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -244,6 +244,22 @@ void __sched mutex_lock(struct mutex *lock)
 EXPORT_SYMBOL(mutex_lock);
 #endif
 
+/*
+ * Wait-Die:
+ *   The newer transactions are killed when:
+ * It (the new transaction) makes a request for a lock being held
+ * by an older transaction.
+ *
+ * Wound-Wait:
+ *   The newer transactions are wounded when:
+ * An older transaction makes a request for a lock being held by
+ * the newer transaction.
+ */
+
+/*
+ * Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
+ * it.
+ */
 static __always_inline void
 ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
 {
@@ -282,26 +298,96 @@ ww_mutex_lock_acquired(struct ww_mutex *ww, struct 
ww_acquire_ctx *ww_ctx)
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
 #endif
ww_ctx->acquired++;
+   ww->ctx = ww_ctx;
 }
 
+/*
+ * Determine if context @a is 'after' context @b. IOW, @a should be wounded in
+ * favour of @b.
+ */
 static inline bool __sched
 __ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
 {
-   return a->stamp - b->stamp <= LONG_MAX &&
-  (a->stamp != b->stamp || a > b);
+
+   return (signed long)(a->stamp - 

[Bug 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

--- Comment #2 from Ricardo Ribalda  ---
Created attachment 140156
  --> https://bugs.freedesktop.org/attachment.cgi?id=140156=edit
Sluttering (how do I see the video with omx decode)

-- 
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 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

--- Comment #1 from Ricardo Ribalda  ---
Created attachment 140154
  --> https://bugs.freedesktop.org/attachment.cgi?id=140154=edit
Original file encoded with omx (one keyframe per second)

-- 
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 report] drm/prime: replace NULL with error value in drm_prime_pages_to_sg

[Dan Carpenter]

Hello YoungJun Cho,

The patch 7e3d88f9cce3: "drm/prime: replace NULL with error value in
drm_prime_pages_to_sg" from Jun 24, 2013, leads to the following
static checker warning:

drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL

drivers/gpu/drm/drm_prime.c
   307  /*
   308   * two mappings with different directions for the same 
attachment are
   309   * not allowed
   310   */
   311  if (WARN_ON(prime_attach->dir != DMA_NONE))
   312  return ERR_PTR(-EBUSY);
   313  
   314  sgt = obj->dev->driver->gem_prime_get_sg_table(obj);

The problematic functions here are drm_gem_cma_prime_get_sg_table() and
xen_drm_front_gem_get_sg_table().  My preference would be to update
those functions to return error pointers, but I'm not familiar with the
code or able to test it.

But this static checker test seems pretty good so I'm likely to publish
it soon and then this sort of bug will normally be caught quickly.

   315  
   316  if (!IS_ERR(sgt)) {
   317  if (!dma_map_sg_attrs(attach->dev, sgt->sgl, 
sgt->nents, dir,
   318DMA_ATTR_SKIP_CPU_SYNC)) {
   319  sg_free_table(sgt);
   320  kfree(sgt);
   321  sgt = ERR_PTR(-ENOMEM);
   322  } else {
   323  prime_attach->sgt = sgt;
   324  prime_attach->dir = dir;
   325  }
   326  }
   327  
   328  return sgt;

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

[Bug 106919] Stuttering when trying to decode stream encoded with omx

[bugzilla-daemon]

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

Bug ID: 106919
   Summary: Stuttering when trying to decode stream encoded with
omx
   Product: Mesa
   Version: 18.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ricardo.riba...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

We have the following configuration:

With this configuration:
Mesa 18.1.1 AMD Radeon R7 Graphics (CARRIZO, DRM 3.25.0, 4.17.0, LLVM 6.0.1)

When we decode with OMX a video that was previously encoded with OMX, the video
seems to roll back a second once in a while (Please take a look to the videos,
it is hard to explain what is happening).

We are accessing libmesa-omx with libomx-bellagio 0.9.3 and gstreamer 1.12.4

-- 
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 100687] KWin won't draw Aurorae themes under EGL

[bugzilla-daemon]

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

MirceaKitsune  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from MirceaKitsune  ---
Closing this for now. I understand it was a deliberate decision of the KDE
developers as EGL support has been disabled on X11. If the driver developers
believe this can and should be fixed by the drivers, feel free to reopen.

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

[pull] amdgpu drm-next-4.18

[Alex Deucher]

Hi Dave,

Fixes for 4.18. Highlights:
- Fixes for gfxoff on Raven
- Remove an ATPX quirk now that the root cause is fixed
- Runtime PM fixes
- Vega20 register header update
- Wattman fixes
- Misc bug fixes

The following changes since commit 7ba01f9e12bb3f088f617cf69b589ea37bd5d6ed:

  drm/amdgpu: Fix NULL pointer when load kfd driver with PP block is disabled 
(2018-05-31 14:08:54 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.18

for you to fetch changes up to 5c16f36f6f003b4415237acca59384a074cd8030:

  drm/amd/powerplay: Set higher SCLK frequency than dpm7 in OD (v2) 
(2018-06-14 07:42:39 -0500)


Alex Deucher (1):
  Revert "drm/amdgpu: Add an ATPX quirk for hybrid laptop"

Colin Ian King (2):
  drm/amdgpu/df: fix potential array out-of-bounds read
  drm/amd/pp: initialize result to before or'ing in data

Evan Quan (3):
  drm/amd/powerplay: fix wrong clock adjust sequence
  drm/amdgpu: fix parsing indirect register list v2
  drm/amd/powerplay: remove uncessary extra gfxoff control call

Huang Rui (4):
  drm/amdgpu: fix the missed vcn fw version report
  drm/amdgpu: add checking for sos version
  drm/amdgpu: fix CG enabling hang with gfxoff enabled
  drm/amd/powerplay: fix missed hwmgr check warning before call 
gfx_off_control handler

Junwei Zhang (1):
  drm/amdgpu: fix clear_all and replace handling in the VM (v2)

Kenneth Feng (1):
  drm/amd/powerplay: Set higher SCLK frequency than dpm7 in OD (v2)

Lyude Paul (1):
  drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()

Pratik Vishwakarma (1):
  drm/amd/display: Fix stale buffer object (bo) use

Rex Zhu (1):
  drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cards

Shaoyun Liu (1):
  drm/amd/include: Update df 3.6 mask and shift definition

 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  6 +++--
 drivers/gpu/drm/amd/amdgpu/df_v3_6.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 20 
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c  | 27 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 24 ++-
 .../drm/amd/include/asic_reg/df/df_3_6_sh_mask.h   |  8 +++
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 10 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c   | 13 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c  |  4 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  7 --
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  9 ++--
 .../gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c |  2 +-
 15 files changed, 92 insertions(+), 54 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106418] kernel BUG at drivers/dma-buf/reservation.c:234!

[bugzilla-daemon]

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

davep  changed:

   What|Removed |Added

 CC||david.panar...@amd.com

--- Comment #5 from davep  ---
Hi Mikhail,

My name's Dave Panariti (david.and I'm going to be taking a look at this.
You mention a script that grabs what's needed.  If it doesn't build it, could
you send instructions on how to do so?

thanks,
davep

-- 
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 200045] black screen on 'radeon' module probing

[bugzilla-daemon]

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

--- Comment #8 from cerg2010cerg2...@mail.ru ---
Ok, I tested the patches, but they did not fix the problem. Nothing changed,
and the log is empty. I tried to apply them separately and both at the same
time. Note that second one seems to depend on the first, so I had to apply it
manually.

Thanks for trying to fix the issue!

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

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

On 06/14/2018 03:29 PM, Matthew Wilcox wrote:

On Thu, Jun 14, 2018 at 01:54:15PM +0200, Thomas Hellstrom wrote:

On 06/14/2018 01:36 PM, Peter Zijlstra wrote:

Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard relies on
that. Are there sensible use cases for mixing them? IOW will your
current restriction stand without hassle?

Contexts _must_ agree on the algorithm used to resolve deadlocks. With
Wait-Die, for example, older transactions will wait if a lock is held by a
younger transaction and with Wound-Wait, younger transactions will wait if a
lock is held by an older transaction so there is no way of mixing them.

Maybe the compiler should be enforcing that; ie make it a different type?


It's intended to be enforced by storing the algorithm choice in the 
WW_MUTEX_CLASS which must be common for an acquire context and the 
ww_mutexes it acquires. However, I don't think there is a check that 
that holds. I guess we could add it as a DEBUG_MUTEX test in 
ww_mutex_lock().


Thanks,

Thomas


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

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

On 06/14/2018 02:48 PM, Thomas Hellstrom wrote:

Hi, Peter,

On 06/14/2018 02:41 PM, Peter Zijlstra wrote:

On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:

+static bool __ww_mutex_wound(struct mutex *lock,
+ struct ww_acquire_ctx *ww_ctx,
+ struct ww_acquire_ctx *hold_ctx)
+{
+    struct task_struct *owner = __mutex_owner(lock);
+
+    lockdep_assert_held(>wait_lock);
+
+    if (owner && hold_ctx && __ww_ctx_stamp_after(hold_ctx, ww_ctx) &&
+    ww_ctx->acquired > 0) {
+    hold_ctx->wounded = 1;
+
+    /*
+ * wake_up_process() paired with set_current_state() inserts
+ * sufficient barriers to make sure @owner either sees it's
+ * wounded or has a wakeup pending to re-read the wounded
+ * state.
+ *
+ * The value of hold_ctx->wounded in
+ * __ww_mutex_lock_check_stamp();
+ */
+    if (owner != current)
+    wake_up_process(owner);
+
+    return true;
+    }
+
+    return false;
+}
@@ -338,12 +377,18 @@ ww_mutex_set_context_fastpath(struct ww_mutex 
*lock, struct ww_acquire_ctx *ctx)

   * and keep spinning, or it will acquire wait_lock, add itself
   * to waiter list and sleep.
   */
-    smp_mb(); /* ^^^ */
+    smp_mb(); /* See comments above and below. */
    /*
- * Check if lock is contended, if not there is nobody to wake up
+ * Check if lock is contended, if not there is nobody to wake up.
+ * We can use list_empty() unlocked here since it only compares a
+ * list_head field pointer to the address of the list head
+ * itself, similarly to how list_empty() can be considered 
RCU-safe.

+ * The memory barrier above pairs with the memory barrier in
+ * __ww_mutex_add_waiter and makes sure lock->ctx is visible 
before

+ * we check for waiters.
   */
-    if (likely(!(atomic_long_read(>base.owner) & 
MUTEX_FLAG_WAITERS)))

+    if (likely(list_empty(>base.wait_list)))
  return;

OK, so what happens is that if we see !empty list, we take wait_lock,
if we end up in __ww_mutex_wound() we must really have !empty wait-list.

It can however still see !owner because __mutex_unlock_slowpath() can
clear the owner field. But if owner is set, it must stay valid because
FLAG_WAITERS and we're holding wait_lock.


If __ww_mutex_wound() is called from ww_mutex_set_context_fastpath() 
owner is the current process so we can never see !owner. However if 
__ww_mutex_wound() is called from __ww_mutex_add_waiter() then the 
above is true.


Or actually it was intended to be true, but FLAG_WAITERS is set too 
late. It needs to be moved to just after we actually add the waiter to 
the list.


Then the hunk that replaces a FLAG_WAITERS read with a lockless 
list_empty() can also be ditched.


/Thomas






So the wake_up_process() is in fact safe.

Let me put that in a comment.



Thanks,

Thomas




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

[Bug 200045] black screen on 'radeon' module probing

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Wolfram Sang from comment #5)
> Sure. But reading the original description above, I think the default use
> case is to not use hw_i2c. It was just added to try to work around the
> regression. And that led to another bug. Or am I wrong here?

Correct.  I was just clarifying that that option does.

-- 
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: [RFC v3 0/8] Add Plane Color Properties

[Alexandru-Cosmin Gheorghe]

On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Alexandru-Cosmin Gheorghe
> >Sent: Monday, June 11, 2018 3:47 PM
> >To: Shankar, Uma 
> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
> >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville
> >; n...@arm.com; Lankhorst, Maarten
> >
> >Subject: Re: [RFC v3 0/8] Add Plane Color Properties
> >
> >Hi Uma,
> >
> >Any progress on userspace for this?
> >I was thinking on working on using this in drm_hwcomposer.
> >
> 
> Hi Alex,
> Not much work has been done till now on user space side. You can go ahead
> and try to enable it in drm_hwcomposer.
>

Hi, 

I'm missing the hardware/driver that can do all three operations DEGAMMA, CSC,
GAMMA for now, any chance you have a setup env with drm_hwcomposer and
you would have time to help me with some testing after I would be
writing the code ? 

Thank you,
Alex Gheorghe
 
> Regards,
> Uma Shankar
> 
> >Thank you,
> >Alex Gheorghe
> >
> >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote:
> >> This patch series adds properties for plane color features. It adds
> >> properties for degamma used to linearize data, CSC used for gamut
> >> conversion, and gamma used to again non-linearize data as per panel
> >> supported color space. These can be utilize by user space to convert
> >> planes from one format to another, one color space to another etc.
> >>
> >> Usersapce can take smart blending decisions and utilize these hardware
> >> supported plane color features to get accurate color profile. The same
> >> can help in consistent color quality from source to panel taking
> >> advantage of advanced color features in hardware.
> >>
> >> These patches just add the property interfaces and enable helper
> >> functions.
> >>
> >> This series adds Intel Gen9 specific plane gamma feature. We can build
> >> up and add other platform/hardware specific implementation on top of
> >> this series
> >>
> >> Note: This is just to get a design feedback whether these interfaces
> >> look ok. Based on community feedback on interfaces, we will implement
> >> IGT tests to validate plane color features. This is un-tested currently.
> >> Also, userspace implementation to use these properties is currently
> >> not available.
> >>
> >> v2: Dropped legacy gamma table for plane as suggested by Maarten.
> >> Added Gen9/BDW plane gamma feature and rebase on tot.
> >>
> >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit
> >> precision entries, pointed to by Brian, Starkey for HDR usecases.
> >> Addressed Sean,Paul comments and moved plane color properties to
> >> drm_plane instead of mode_config. Added property documentation as
> >suggested by Daniel, Vetter.
> >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov.
> >>
> >> Uma Shankar (8):
> >>   drm: Add Enhanced Gamma LUT precision structure
> >>   drm: Add Plane Degamma properties
> >>   drm: Add Plane CTM property
> >>   drm: Add Plane Gamma properties
> >>   drm: Define helper function for plane color enabling
> >>   drm/i915: Enable plane color features
> >>   drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
> >>   drm/i915: Load plane color luts from atomic flip
> >>
> >>  Documentation/gpu/drm-kms.rst |  18 
> >>  drivers/gpu/drm/drm_atomic.c  |  30 +++
> >>  drivers/gpu/drm/drm_atomic_helper.c   |  12 +++
> >>  drivers/gpu/drm/drm_plane.c   | 131
> >++
> >>  drivers/gpu/drm/i915/i915_drv.h   |   5 ++
> >>  drivers/gpu/drm/i915/i915_pci.c   |   5 +-
> >>  drivers/gpu/drm/i915/i915_reg.h   |  24 ++
> >>  drivers/gpu/drm/i915/intel_atomic_plane.c |   4 +
> >>  drivers/gpu/drm/i915/intel_color.c|  80 ++
> >>  drivers/gpu/drm/i915/intel_device_info.h  |   5 ++
> >>  drivers/gpu/drm/i915/intel_display.c  |   4 +
> >>  drivers/gpu/drm/i915/intel_drv.h  |  10 +++
> >>  drivers/gpu/drm/i915/intel_sprite.c   |   4 +
> >>  include/drm/drm_color_mgmt.h  |   5 ++
> >>  include/drm/drm_plane.h   |  66 +++
> >>  include/uapi/drm/drm_mode.h   |  15 
> >>  16 files changed, 417 insertions(+), 1 deletion(-)
> >>
> >> --
> >> 1.9.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >--
> >Cheers,
> >Alex G
> >___
> >dri-devel mailing list
> >dri-devel@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[Heiko Stuebner]

Am Mittwoch, 14. März 2018, 13:02:13 CEST schrieb Emil Velikov:
> Hi Lin,
> 
> On 14 March 2018 at 09:12, Lin Huang  wrote:
> > From: huang lin 
> >
> > Refactor Innolux P079ZCA panel driver, let it support
> > multi panel.
> >
> > Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
> > Signed-off-by: Lin Huang 

[...]

> > @@ -207,19 +248,28 @@ static const struct drm_panel_funcs 
> > innolux_panel_funcs = {
> 
> >
> > -   innolux->supply = devm_regulator_get(dev, "power");
> > -   if (IS_ERR(innolux->supply))
> > -   return PTR_ERR(innolux->supply);
> > +   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
> > +   if (!innolux)
> > +   return -ENOMEM;
> > +
> > +   innolux->desc = desc;
> > +   innolux->vddi = devm_regulator_get(dev, "power");
> > +   innolux->avdd = devm_regulator_get(dev, "avdd");
> > +   innolux->avee = devm_regulator_get(dev, "avee");
> >
> AFAICT devm_regulator_get returns a pointer which is unsuitable to be
> passed into regulator_{enable,disable}.
> Hence, the IS_ERR check should stay. If any of the regulators are
> optional, you want to call regulator_{enable,disable} only as
> applicable.

using the regulator_bulk APIs should help to make this far easier,
as you can just define the per-panel supplies in in the panel_desc
and then get + enable the correct ones per bound panel.


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

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

Hi, Peter,

On 06/14/2018 02:41 PM, Peter Zijlstra wrote:

On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:

+static bool __ww_mutex_wound(struct mutex *lock,
+struct ww_acquire_ctx *ww_ctx,
+struct ww_acquire_ctx *hold_ctx)
+{
+   struct task_struct *owner = __mutex_owner(lock);
+
+   lockdep_assert_held(>wait_lock);
+
+   if (owner && hold_ctx && __ww_ctx_stamp_after(hold_ctx, ww_ctx) &&
+   ww_ctx->acquired > 0) {
+   hold_ctx->wounded = 1;
+
+   /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the wounded
+* state.
+*
+* The value of hold_ctx->wounded in
+* __ww_mutex_lock_check_stamp();
+*/
+   if (owner != current)
+   wake_up_process(owner);
+
+   return true;
+   }
+
+   return false;
+}
@@ -338,12 +377,18 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock, 
struct ww_acquire_ctx *ctx)
 * and keep spinning, or it will acquire wait_lock, add itself
 * to waiter list and sleep.
 */
-   smp_mb(); /* ^^^ */
+   smp_mb(); /* See comments above and below. */
  
  	/*

-* Check if lock is contended, if not there is nobody to wake up
+* Check if lock is contended, if not there is nobody to wake up.
+* We can use list_empty() unlocked here since it only compares a
+* list_head field pointer to the address of the list head
+* itself, similarly to how list_empty() can be considered RCU-safe.
+* The memory barrier above pairs with the memory barrier in
+* __ww_mutex_add_waiter and makes sure lock->ctx is visible before
+* we check for waiters.
 */
-   if (likely(!(atomic_long_read(>base.owner) & MUTEX_FLAG_WAITERS)))
+   if (likely(list_empty(>base.wait_list)))
return;
  

OK, so what happens is that if we see !empty list, we take wait_lock,
if we end up in __ww_mutex_wound() we must really have !empty wait-list.

It can however still see !owner because __mutex_unlock_slowpath() can
clear the owner field. But if owner is set, it must stay valid because
FLAG_WAITERS and we're holding wait_lock.


If __ww_mutex_wound() is called from ww_mutex_set_context_fastpath() 
owner is the current process so we can never see !owner. However if 
__ww_mutex_wound() is called from __ww_mutex_add_waiter() then the above 
is true.




So the wake_up_process() is in fact safe.

Let me put that in a comment.



Thanks,

Thomas


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

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

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

--- Comment #37 from Alex Tucker (a...@floop.org.uk) ---
Thanks Samuel, updating to kernel-4.16.14-300.fc28.x86_64 and moving back to
Nouveau rather than the workaround with the NVIDIA driver, suspend and resume
now works again for me too.

Would you be able to provide a link to the Fedora bug you mentioned?

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

Re: [PATCH v2] drm/bridge: sil_sii8620: do not have a dependency of RC_CORE

[Andrzej Hajda]

On 24.05.2018 11:32, Inki Dae wrote:
> This patch makes RC_CORE to be selected with this driver.
>
> sil_sii8620 driver calls remote controller interfaces directly
> so RC_CORE should be enabled mandatorily.
>
> And some boards not using remote controller device don't really
> need to know that RC_CORE config should be enabled to use sil_sii8620
> driver only for HDMI.
>
> Changelog v2:
> - select INPUT because compiling will fail without INPUT.
>
> Signed-off-by: Inki Dae 

Queued to drm-misc-next.

Regards
Andrzej

> ---
>  drivers/gpu/drm/bridge/Kconfig | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3aa65bd..3c558ee 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -72,8 +72,10 @@ config DRM_PARADE_PS8622
>  
>  config DRM_SIL_SII8620
>   tristate "Silicon Image SII8620 HDMI/MHL bridge"
> - depends on OF && RC_CORE
> + depends on OF
>   select DRM_KMS_HELPER
> + select INPUT
> + select RC_CORE
>   help
> Silicon Image SII8620 HDMI/MHL bridge chip driver.
>  


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

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Peter Zijlstra]

On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> +static bool __ww_mutex_wound(struct mutex *lock,
> +  struct ww_acquire_ctx *ww_ctx,
> +  struct ww_acquire_ctx *hold_ctx)
> +{
> + struct task_struct *owner = __mutex_owner(lock);
> +
> + lockdep_assert_held(>wait_lock);
> +
> + if (owner && hold_ctx && __ww_ctx_stamp_after(hold_ctx, ww_ctx) &&
> + ww_ctx->acquired > 0) {
> + hold_ctx->wounded = 1;
> +
> + /*
> +  * wake_up_process() paired with set_current_state() inserts
> +  * sufficient barriers to make sure @owner either sees it's
> +  * wounded or has a wakeup pending to re-read the wounded
> +  * state.
> +  *
> +  * The value of hold_ctx->wounded in
> +  * __ww_mutex_lock_check_stamp();
> +  */
> + if (owner != current)
> + wake_up_process(owner);
> +
> + return true;
> + }
> +
> + return false;
> +}

> @@ -338,12 +377,18 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock, 
> struct ww_acquire_ctx *ctx)
>* and keep spinning, or it will acquire wait_lock, add itself
>* to waiter list and sleep.
>*/
> - smp_mb(); /* ^^^ */
> + smp_mb(); /* See comments above and below. */
>  
>   /*
> -  * Check if lock is contended, if not there is nobody to wake up
> +  * Check if lock is contended, if not there is nobody to wake up.
> +  * We can use list_empty() unlocked here since it only compares a
> +  * list_head field pointer to the address of the list head
> +  * itself, similarly to how list_empty() can be considered RCU-safe.
> +  * The memory barrier above pairs with the memory barrier in
> +  * __ww_mutex_add_waiter and makes sure lock->ctx is visible before
> +  * we check for waiters.
>*/
> - if (likely(!(atomic_long_read(>base.owner) & MUTEX_FLAG_WAITERS)))
> + if (likely(list_empty(>base.wait_list)))
>   return;
>  

OK, so what happens is that if we see !empty list, we take wait_lock,
if we end up in __ww_mutex_wound() we must really have !empty wait-list.

It can however still see !owner because __mutex_unlock_slowpath() can
clear the owner field. But if owner is set, it must stay valid because
FLAG_WAITERS and we're holding wait_lock.

So the wake_up_process() is in fact safe.

Let me put that in a comment.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

Resending hopefully better formatted..


On 06/14/2018 01:49 PM, Andrea Parri wrote:

[...]


+   /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the wounded
+* state.

IIUC, "sufficient barriers" = full memory barriers (here).  (You may
want to be more specific.)

Thanks for reviewing!
OK. What about if someone relaxes that in the future?

This is actually one of my main concerns ;-)  as, IIUC, those barriers are
not only sufficient but also necessary: anything "less than a full barrier"
(in either wake_up_process() or set_current_state()) would _not_ guarantee
the "condition" above unless I'm misunderstanding it.

But am I misunderstanding it?  Which barriers/guarantee do you _need_ from
the above mentioned pairing? (hence my comment...)

   Andrea


No you are probably not misunderstanding me at all. My comment 
originated from the reading of the kerneldoc of set_current_state()


/*
* set_current_state() includes a barrier so that the write of current->state
* is correctly serialised wrt the caller's subsequent test of whether to
* actually sleep:
*
* for (;;) {
* set_current_state(TASK_UNINTERRUPTIBLE);
* if (!need_sleep)
* break;
*
* schedule();
* }
* __set_current_state(TASK_RUNNING);
*
* If the caller does not need such serialisation (because, for instance, the
* condition test and condition change and wakeup are under the same 
lock) then

* use __set_current_state().
*
* The above is typically ordered against the wakeup, which does:
*
* need_sleep = false;
* wake_up_state(p, TASK_UNINTERRUPTIBLE);
*
* Where wake_up_state() (and all other wakeup primitives) imply enough
* barriers to order the store of the variable against wakeup.
---
*/

And with ctx->wounded := !need_sleep this exactly matches what's 
happening in my code. So what I was trying to say in the comment was 
that this above contract is sufficient to guarantee the "condition" 
above, whitout me actually knowing exactly what barriers are required. 
Thanks, Thomas


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

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

On 06/14/2018 01:49 PM, Andrea Parri wrote:

[...]


+   /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the wounded
+* state.

IIUC, "sufficient barriers" = full memory barriers (here).  (You may
want to be more specific.)

Thanks for reviewing!
OK. What about if someone relaxes that in the future?

This is actually one of my main concerns ;-)  as, IIUC, those barriers are
not only sufficient but also necessary: anything "less than a full barrier"
(in either wake_up_process() or set_current_state()) would _not_ guarantee
the "condition" above unless I'm misunderstanding it.

But am I misunderstanding it?  Which barriers/guarantee do you _need_ from
the above mentioned pairing? (hence my comment...)

   Andrea


No you are probably not misunderstanding me at all. My comment 
originated from the reading of the kerneldoc of set_current_state()


* set_current_state() includes a barrier so that the write of current->state
* is correctly serialised wrt the caller's subsequent test of whether to
* actually sleep:
*
* for (;;) {
* set_current_state(TASK_UNINTERRUPTIBLE);
* if (!need_sleep)
* break;
*
* schedule();
* }
* __set_current_state(TASK_RUNNING);
*
* If the caller does not need such serialisation (because, for instance, the
* condition test and condition change and wakeup are under the same 
lock) then

* use __set_current_state().
*
* The above is typically ordered against the wakeup, which does:
*
* need_sleep = false;
* wake_up_state(p, TASK_UNINTERRUPTIBLE);
*
* Where wake_up_state() (and all other wakeup primitives) imply enough
* barriers to order the store of the variable against wakeup. And with 
ctx->wounded := !need_sleep this exactly matches what's happening in my 
code. So what I was trying to say in the comment was that this above 
contract is sufficient to guarantee the "condition" above, whitout me 
actually knowing exactly what barriers are required. Thanks, Thomas


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

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

On 06/14/2018 01:36 PM, Peter Zijlstra wrote:

On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:


  __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx 
*ww_ctx)
  {
struct mutex_waiter *cur;
+   unsigned int is_wait_die = ww_ctx->ww_class->is_wait_die;
  
  	lockdep_assert_held(>wait_lock);
  
@@ -310,13 +348,14 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)

if (!cur->ww_ctx)
continue;
  
-		if (cur->ww_ctx->acquired > 0 &&

+   if (is_wait_die && cur->ww_ctx->acquired > 0 &&
__ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
debug_mutex_wake_waiter(lock, cur);
wake_up_process(cur->task);
}
  
-		break;

+   if (is_wait_die || __ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
+   break;
}
  }

I ended up with:


static void __sched
__ww_mutex_check_waiters(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
{
bool is_wait_die = ww_ctx->ww_class->is_wait_die;
struct mutex_waiter *cur;

lockdep_assert_held(>wait_lock);

list_for_each_entry(cur, >wait_list, list) {
if (!cur->ww_ctx)
continue;

if (is_wait_die) {
/*
 * Because __ww_mutex_add_waiter() and
 * __ww_mutex_check_stamp() wake any but the earliest
 * context, this can only affect the first waiter (with
 * a context).
 */
if (cur->ww_ctx->acquired > 0 &&
__ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
debug_mutex_wake_waiter(lock, cur);
wake_up_process(cur->task);
}

break;
}

if (__ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
break;
}
}


Looks OK to me.



Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard relies on
that. Are there sensible use cases for mixing them? IOW will your
current restriction stand without hassle?


Contexts _must_ agree on the algorithm used to resolve deadlocks. With 
Wait-Die, for example, older transactions will wait if a lock is held by 
a younger transaction and with Wound-Wait, younger transactions will 
wait if a lock is held by an older transaction so there is no way of 
mixing them.


Thanks,

/Thomas


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

Re: [PATCH 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

On 06/14/2018 12:51 PM, Peter Zijlstra wrote:

On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:

In short, with Wait-Die (before the patch) it's the process _taking_ the
contended lock that backs off if necessary. No preemption required. With
Wound-Wait, it's the process _holding_ the contended lock that gets wounded
(preempted), and it needs to back off at its own discretion but no later
than when it's going to sleep on another ww mutex. That point is where we
intercept the preemption request. We're preempting the transaction rather
than the process.

This:

   Wait-die:
 The newer transactions are killed when:
   It (= the newer transaction) makes a reqeust for a lock being held
   by an older transactions

   Wound-wait:
 The newer transactions are killed when:
   An older transaction makes a request for a lock being held by the
   newer transactions

Would make for an excellent comment somewhere. No talking about
preemption, although I think I know what you mean with it, that is not
how preemption is normally used.


Ok. I'll incorporate something along this line. Unfortunately that last 
statement is not fully true. It should read

"The newer transactions are wounded when:", not "killed" when.

The literature makes a distinction between "killed" and "wounded". In 
our context, "Killed" is when a transaction actually receives an 
-EDEADLK and needs to back off. "Wounded" is when someone (typically 
another transaction) requests a transaction to kill itself. A wound will 
often, but not always, lead to a kill. If the wounded transaction has 
finished its locking sequence, or has the opportunity to grab 
uncontended ww mutexes or steal contended (non-handoff) ww mutexes to 
finish its transaction it will do so and never kill itself.






In scheduling speak preemption is when we pick a runnable (but !running)
task to run instead of the current running task.  In this case however,
our T2 is blocked on a lock acquisition (one owned by our T1) and T1 is
the only runnable task. Only when T1's progress is inhibited by T2 (T1
wants a lock held by T2) do we wound/wake T2.


Indeed. The preemption spoken about in the Wound-Wait litterature means 
that a transaction preempts another transaction when it wounds it. In 
distributed computing my understanding is that the preempted transaction 
is aborted instantly and restarted after a random delay. Of course, we 
have no means of mapping wounding to process preemption in the linux 
kernel, so that's why I referred to it as "lazy preemption". In process 
analogy "wounded" wound roughly correspond to (need_resched() == true), 
and returning -EDEADLK would correspond to voluntary preemption.






In any case, I had a little look at the current ww_mutex code and ended
up with the below patch that hopefully clarifies things a little.

---
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index f44f658ae629..a20c04619b2a 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -244,6 +244,10 @@ void __sched mutex_lock(struct mutex *lock)
  EXPORT_SYMBOL(mutex_lock);
  #endif
  
+/*

+ * Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
+ * it.
+ */


IMO use of "acquire_context" or "context" is a little unfortunate when 
the literature uses "transaction",

but otherwise fine.



  static __always_inline void
  ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
  {
@@ -282,26 +286,36 @@ ww_mutex_lock_acquired(struct ww_mutex *ww, struct 
ww_acquire_ctx *ww_ctx)
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
  #endif
ww_ctx->acquired++;
+   lock->ctx = ctx;
  }
  
+/*

+ * Determine if context @a is 'after' context @b. IOW, @a should be wounded in
+ * favour of @b.
+ */


So "wounded" should never really be used with Wait-Die
"Determine whether context @a represents a younger transaction than 
context @b"?



  static inline bool __sched
  __ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
  {
-   return a->stamp - b->stamp <= LONG_MAX &&
-  (a->stamp != b->stamp || a > b);
+
+   return (signed long)(a->stamp - b->stamp) > 0;
  }
  
  /*

- * Wake up any waiters that may have to back off when the lock is held by the
- * given context.
+ * We just acquired @lock under @ww_ctx, if there are later contexts waiting
+ * behind us on the wait-list, wake them up so they can wound themselves.


Actually for Wait-Die, Back off or "Die" is the correct terminology.


   *
- * Due to the invariants on the wait list, this can only affect the first
- * waiter with a context.
+ * See __ww_mutex_add_waiter() for the list-order construction; basically the
+ * list is ordered by stamp smallest (oldest) first, so if there is a later
+ * (younger) stamp on the list behind us, wake it so it can wound itself.
+ *
+ * Because __ww_mutex_add_waiter() and __ww_mutex_check_stamp() wake any
+ * but the earliest 

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Peter Zijlstra]

On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:

>  __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx 
> *ww_ctx)
>  {
>   struct mutex_waiter *cur;
> + unsigned int is_wait_die = ww_ctx->ww_class->is_wait_die;
>  
>   lockdep_assert_held(>wait_lock);
>  
> @@ -310,13 +348,14 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, 
> struct ww_acquire_ctx *ww_ctx)
>   if (!cur->ww_ctx)
>   continue;
>  
> - if (cur->ww_ctx->acquired > 0 &&
> + if (is_wait_die && cur->ww_ctx->acquired > 0 &&
>   __ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
>   debug_mutex_wake_waiter(lock, cur);
>   wake_up_process(cur->task);
>   }
>  
> - break;
> + if (is_wait_die || __ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
> + break;
>   }
>  }

I ended up with:


static void __sched
__ww_mutex_check_waiters(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
{
bool is_wait_die = ww_ctx->ww_class->is_wait_die;
struct mutex_waiter *cur;

lockdep_assert_held(>wait_lock);

list_for_each_entry(cur, >wait_list, list) {
if (!cur->ww_ctx)
continue;

if (is_wait_die) {
/*
 * Because __ww_mutex_add_waiter() and
 * __ww_mutex_check_stamp() wake any but the earliest
 * context, this can only affect the first waiter (with
 * a context).
 */
if (cur->ww_ctx->acquired > 0 &&
__ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
debug_mutex_wake_waiter(lock, cur);
wake_up_process(cur->task);
}

break;
}

if (__ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
break;
}
}


Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard relies on
that. Are there sensible use cases for mixing them? IOW will your
current restriction stand without hassle?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

On 06/14/2018 12:38 PM, Andrea Parri wrote:

Hi Thomas,

On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:

The current Wound-Wait mutex algorithm is actually not Wound-Wait but
Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
is, contrary to Wait-Die a preemptive algorithm and is known to generate
fewer backoffs. Testing reveals that this is true if the
number of simultaneous contending transactions is small.
As the number of simultaneous contending threads increases, Wait-Wound
becomes inferior to Wait-Die in terms of elapsed time.
Possibly due to the larger number of held locks of sleeping transactions.

Update documentation and callers.

Timings using git://people.freedesktop.org/~thomash/ww_mutex_test
tag patch-18-06-14

Each thread runs 10 batches of lock / unlock 800 ww mutexes randomly
chosen out of 10. Four core Intel x86_64:

Algorithm#threads   Rollbacks  time
Wound-Wait   4  ~100   ~17s.
Wait-Die 4  ~15~19s.
Wound-Wait   16 ~36~109s.
Wait-Die 16 ~45~82s.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Jonathan Corbet 
Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Davidlohr Bueso 
Cc: "Paul E. McKenney" 
Cc: Josh Triplett 
Cc: Thomas Gleixner 
Cc: Kate Stewart 
Cc: Philippe Ombredanne 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Thomas Hellstrom 

---
v2:
* Update API according to review comment by Greg Kroah-Hartman.
* Address review comments by Peter Zijlstra:
   - Avoid _Bool in composites
   - Fix typo
   - Use __mutex_owner() where applicable
   - Rely on built-in barriers for the main loop exit condition,
 struct ww_acquire_ctx::wounded. Update code comments.
   - Explain unlocked use of list_empty().
---
  Documentation/locking/ww-mutex-design.txt |  54 
  drivers/dma-buf/reservation.c |   2 +-
  drivers/gpu/drm/drm_modeset_lock.c|   2 +-
  include/linux/ww_mutex.h  |  19 --
  kernel/locking/locktorture.c  |   2 +-
  kernel/locking/mutex.c| 103 +++---
  kernel/locking/test-ww_mutex.c|   2 +-
  lib/locking-selftest.c|   2 +-
  8 files changed, 156 insertions(+), 30 deletions(-)

diff --git a/Documentation/locking/ww-mutex-design.txt 
b/Documentation/locking/ww-mutex-design.txt
index 34c3a1b50b9a..b9597def9581 100644
--- a/Documentation/locking/ww-mutex-design.txt
+++ b/Documentation/locking/ww-mutex-design.txt
@@ -1,4 +1,4 @@
-Wait/Wound Deadlock-Proof Mutex Design
+Wound/Wait Deadlock-Proof Mutex Design
  ==
  
  Please read mutex-design.txt first, as it applies to wait/wound mutexes too.

@@ -32,10 +32,23 @@ the oldest task) wins, and the one with the higher 
reservation id (i.e. the
  younger task) unlocks all of the buffers that it has already locked, and then
  tries again.
  
-In the RDBMS literature this deadlock handling approach is called wait/wound:

-The older tasks waits until it can acquire the contended lock. The younger 
tasks
-needs to back off and drop all the locks it is currently holding, i.e. the
-younger task is wounded.
+In the RDBMS literature, a reservation ticket is associated with a transaction.
+and the deadlock handling approach is called Wait-Die. The name is based on
+the actions of a locking thread when it encounters an already locked mutex.
+If the transaction holding the lock is younger, the locking transaction waits.
+If the transaction holding the lock is older, the locking transaction backs off
+and dies. Hence Wait-Die.
+There is also another algorithm called Wound-Wait:
+If the transaction holding the lock is younger, the locking transaction
+preempts the transaction holding the lock, requiring it to back off. It
+Wounds the other transaction.
+If the transaction holding the lock is older, it waits for the other
+transaction. Hence Wound-Wait.
+The two algorithms are both fair in that a transaction will eventually succeed.
+However, the Wound-Wait algorithm is typically stated to generate fewer 
backoffs
+compared to Wait-Die, but is, on the other hand, associated with more work than
+Wait-Die when recovering from a backoff. Wound-Wait is also a preemptive
+algorithm which requires a reliable way to preempt another transaction.
  
  Concepts

  
@@ -47,10 +60,12 @@ Acquire context: To ensure eventual forward progress it is 
important the a task
  trying to acquire locks doesn't grab a new reservation id, but keeps the one 
it
  acquired when starting the lock acquisition. This ticket is stored in the
  acquire context. Furthermore the acquire context keeps track of debugging 
state
-to catch w/w mutex interface abuse.
+to catch w/w mutex interface abuse. An acquire context is representing a
+transaction.
  

[GIT PULL] fbdev changes for v4.18

[Bartlomiej Zolnierkiewicz]

Hi Linus,

Please pull fbdev changes for v4.18. There is nothing really major
here, few small fixes, some cleanups and dead drivers removal (please
see the signed tag description for details).

Test merge revealed a small merge conflict, the resolution is trivial:

diff --cc drivers/video/fbdev/mmp/fb/mmpfb.c
index f27697e,292b3e4..ee212be
--- a/drivers/video/fbdev/mmp/fb/mmpfb.c
+++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
@@@ -493,12 -493,11 +493,11 @@@ static int modes_setup(struct mmpfb_inf
return 0;
}
/* put videomode list to info structure */
 -  videomodes = kzalloc(sizeof(struct fb_videomode) * videomode_num,
 -  GFP_KERNEL);
 +  videomodes = kcalloc(videomode_num, sizeof(struct fb_videomode),
 +   GFP_KERNEL);
-   if (!videomodes) {
-   dev_err(fbi->dev, "can't malloc video modes\n");
+   if (!videomodes)
return -ENOMEM;
-   }
+ 
for (i = 0; i < videomode_num; i++)
mmpmode_to_fbmode([i], _modes[i]);
fb_videomode_to_modelist(videomodes, videomode_num, >modelist);


Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:

  Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.18

for you to fetch changes up to 85ebd164de56c5146e0f65cebee7fcc4babe52e3:

  fb_omap2: add gpiolib dependency (2018-06-08 18:08:12 +0200)


fbdev changes for v4.18:

- mark omapfb drivers as orphans in MAINTAINERS file (Tomi Valkeinen)

- add missing module license tags to omap/omapfb driver (Arnd Bergmann)

- add missing GPIOLIB dependendy to omap2/omapfb driver (Arnd Bergmann)

- convert savagefb, aty128fb & radeonfb drivers to use msleep & co.
  (Jia-Ju Bai)

- allow COMPILE_TEST build for viafb driver (media part was reviewed by
  media subsystem Maintainer)

- remove unused MERAM support from sh_mobile_lcdcfb and shmob-drm drivers
  (drm parts were acked by shmob-drm driver Maintainer)

- remove unused auo_k190xfb drivers

- misc cleanups (Souptick Joarder, Wolfram Sang, Markus Elfring, Andy
  Shevchenko, Colin Ian King)


Andy Shevchenko (1):
  video: fbdev: pxafb: Convert to use match_string() helper

Arnd Bergmann (2):
  video/omap: add module license tags
  fb_omap2: add gpiolib dependency

Bartlomiej Zolnierkiewicz (7):
  Merge tag 'v4.17-rc2' of git://git.kernel.org/.../torvalds/linux into 
fbdev-for-next
  video: fbdev: remove unused auo_k190xfb drivers
  video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support
  drm: shmobile: remove unused MERAM support
  video: fbdev: remove unused sh_mobile_meram driver
  video: fbdev: via: allow COMPILE_TEST build
  video: fbdev: pxafb: match_string() conversion fixup

Colin Ian King (2):
  video: fbdev: fix spelling mistake: "frambuffer" -> "framebuffer"
  video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling"

Geert Uytterhoeven (1):
  video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency

Jia-Ju Bai (3):
  video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw
  video: fbdev: aty: aty128fb: Replace mdelay with msleep in 
aty128_set_suspend
  video: fbdev: aty: radeon_pm: Replace mdelay with msleep in 
radeonfb_pci_suspend

Markus Elfring (7):
  video: sh_mobile_meram: Delete an error message for a failed memory 
allocation in sh_mobile_meram_probe()
  video: sh_mobile_lcdcfb: Delete an error message for a failed memory 
allocation in two functions
  video: auo_k190x: Delete an error message for a failed memory allocation 
in auok190x_common_probe()
  video: fbdev-MMP: Delete an error message for a failed memory allocation 
in two functions
  video: fbdev-MMP: Improve a size determination in path_init()
  video: sm501fb: Improve a size determination in sm501fb_probe()
  video: omap: Improve a size determination in omapfb_do_probe()

Souptick Joarder (1):
  video: fbdev: core: Change return type to vm_fault_t

Tomi Valkeinen (1):
  MAINTAINERS: make omapfb orphan

Wolfram Sang (2):
  video: fbdev: simplify getting .drvdata
  video: fbdev: omap2: omapfb: displays: simplify getting .drvdata

 MAINTAINERS|6 +-
 drivers/gpu/drm/shmobile/Kconfig   |1 -
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |   42 -
 drivers/gpu/drm/shmobile/shmob_drm_crtc.h  |1 -
 drivers/gpu/drm/shmobile/shmob_drm_drv.h   |2 -
 drivers/gpu/drm/shmobile/shmob_drm_kms.c   |   11 -
 drivers/gpu/drm/shmobile/shmob_drm_kms.h   |1 -
 drivers/gpu/drm/shmobile/shmob_drm_plane.c   

Re: [PATCH 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Peter Zijlstra]

On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:
> In short, with Wait-Die (before the patch) it's the process _taking_ the
> contended lock that backs off if necessary. No preemption required. With
> Wound-Wait, it's the process _holding_ the contended lock that gets wounded
> (preempted), and it needs to back off at its own discretion but no later
> than when it's going to sleep on another ww mutex. That point is where we
> intercept the preemption request. We're preempting the transaction rather
> than the process.

This:

  Wait-die:
The newer transactions are killed when:
  It (= the newer transaction) makes a reqeust for a lock being held
  by an older transactions

  Wound-wait:
The newer transactions are killed when:
  An older transaction makes a request for a lock being held by the
  newer transactions

Would make for an excellent comment somewhere. No talking about
preemption, although I think I know what you mean with it, that is not
how preemption is normally used.

In scheduling speak preemption is when we pick a runnable (but !running)
task to run instead of the current running task.  In this case however,
our T2 is blocked on a lock acquisition (one owned by our T1) and T1 is
the only runnable task. Only when T1's progress is inhibited by T2 (T1
wants a lock held by T2) do we wound/wake T2.

In any case, I had a little look at the current ww_mutex code and ended
up with the below patch that hopefully clarifies things a little.

---
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index f44f658ae629..a20c04619b2a 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -244,6 +244,10 @@ void __sched mutex_lock(struct mutex *lock)
 EXPORT_SYMBOL(mutex_lock);
 #endif
 
+/*
+ * Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
+ * it.
+ */
 static __always_inline void
 ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
 {
@@ -282,26 +286,36 @@ ww_mutex_lock_acquired(struct ww_mutex *ww, struct 
ww_acquire_ctx *ww_ctx)
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
 #endif
ww_ctx->acquired++;
+   lock->ctx = ctx;
 }
 
+/*
+ * Determine if context @a is 'after' context @b. IOW, @a should be wounded in
+ * favour of @b.
+ */
 static inline bool __sched
 __ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
 {
-   return a->stamp - b->stamp <= LONG_MAX &&
-  (a->stamp != b->stamp || a > b);
+
+   return (signed long)(a->stamp - b->stamp) > 0;
 }
 
 /*
- * Wake up any waiters that may have to back off when the lock is held by the
- * given context.
+ * We just acquired @lock under @ww_ctx, if there are later contexts waiting
+ * behind us on the wait-list, wake them up so they can wound themselves.
  *
- * Due to the invariants on the wait list, this can only affect the first
- * waiter with a context.
+ * See __ww_mutex_add_waiter() for the list-order construction; basically the
+ * list is ordered by stamp smallest (oldest) first, so if there is a later
+ * (younger) stamp on the list behind us, wake it so it can wound itself.
+ *
+ * Because __ww_mutex_add_waiter() and __ww_mutex_check_stamp() wake any
+ * but the earliest context, this can only affect the first waiter (with a
+ * context).
  *
  * The current task must not be on the wait list.
  */
 static void __sched
-__ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx 
*ww_ctx)
+__ww_mutex_wakeup_for_wound(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
 {
struct mutex_waiter *cur;
 
@@ -322,16 +336,14 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct 
ww_acquire_ctx *ww_ctx)
 }
 
 /*
- * After acquiring lock with fastpath or when we lost out in contested
- * slowpath, set ctx and wake up any waiters so they can recheck.
+ * After acquiring lock with fastpath, where we do not hold wait_lock, set ctx
+ * and wake up any waiters so they can recheck.
  */
 static __always_inline void
 ww_mutex_set_context_fastpath(struct ww_mutex *lock, struct ww_acquire_ctx 
*ctx)
 {
ww_mutex_lock_acquired(lock, ctx);
 
-   lock->ctx = ctx;
-
/*
 * The lock->ctx update should be visible on all cores before
 * the atomic read is done, otherwise contended waiters might be
@@ -352,25 +364,10 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock, 
struct ww_acquire_ctx *ctx)
 * so they can see the new lock->ctx.
 */
spin_lock(>base.wait_lock);
-   __ww_mutex_wakeup_for_backoff(>base, ctx);
+   __ww_mutex_wakeup_for_wound(>base, ctx);
spin_unlock(>base.wait_lock);
 }
 
-/*
- * After acquiring lock in the slowpath set ctx.
- *
- * Unlike for the fast path, the caller ensures that waiters are woken up where
- * necessary.
- *
- * Callers must hold the mutex wait_lock.
- */
-static __always_inline void
-ww_mutex_set_context_slowpath(struct ww_mutex *lock, struct 

[Bug 199959] amdgpu, regression?: system freezes after resume

[bugzilla-daemon]

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

--- Comment #25 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Yes, it works

dmesg:
[   34.330683] amdgpu :65:00.0: Test 0 from 8 to 13

-- 
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 199959] amdgpu, regression?: system freezes after resume

[bugzilla-daemon]

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

--- Comment #24 from Christian König (christian.koe...@amd.com) ---
Created attachment 276547
  --> https://bugzilla.kernel.org/attachment.cgi?id=276547=edit
Possible fix

In this case please try the attached patch and see if it helps.

-- 
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 199959] amdgpu, regression?: system freezes after resume

[bugzilla-daemon]

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

--- Comment #23 from Alexander Mezin (mezin.alexan...@gmail.com) ---
(In reply to Christian König from comment #22)
> Your debugging efforts are better than mine.
> 
> Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l
> ECAP15+8.l" once before suspend and once after suspend without any changes
> (e.g. when the problem happens).

before suspend:
27010015
0003f000
0d20

after resume:
27010015
0003f000
0820

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

Re: [PATCH 2/4] ARM: dts: Modernize the Vexpress PL111 integration

[Liviu Dudau]

On Wed, Jun 13, 2018 at 11:57:25AM +0100, Sudeep Holla wrote:
> Hi Linus,
> 
> I was planning to apply this and observed few things.
> 
> On 28/05/18 13:26, Linus Walleij wrote:
> > The Versatile Express was submitted with the actual display
> > bridges unconnected (but defined in the device tree) and
> > mock "panels" encoded in the device tree node of the PL111
> > controller.
> > 
> > This doesn't even remotely describe the actual Versatile
> > Express hardware. Exploit the SiI9022 bridge by connecting
> > the PL111 pads to it, making it use EDID or fallback values
> > to drive the monitor.
> > 
> > The  also has to use the reserved memory through the
> > CMA pool rather than by open coding a memory region and
> > remapping it explicitly in the driver. To achieve this,
> > a reserved-memory node must exist in the root of the
> > device tree, so we need to pull that out of the
> > motherboard .dtsi include files, and push it into each
> > top-level device tree instead.
> > 
> > We do the same manouver for all the Versatile Express
> > boards, taking into account the different location of the
> > video RAM depending on which chip select is used on
> > each platform.
> > 
> > This plays nicely with the new PL111 DRM driver and
> > follows the standard ways of assigning bridges and
> > memory pools for graphics.
> > 
> > Cc: Sudeep Holla 
> > Cc: Lorenzo Pieralisi 
> > Cc: Liviu Dudau 
> > Cc: Mali DP Maintainers 
> > Cc: Robin Murphy 
> > Signed-off-by: Linus Walleij 
> > ---
> > ChangeLog v1->v2:
> > - Fix up the memory address for the -rs1 tiles to 0x1800
> > - Drop a bunch of extraneous reg props from the DVI adapter
> > ---
> >  arch/arm/boot/dts/vexpress-v2m-rs1.dtsi   | 44 ++
> >  arch/arm/boot/dts/vexpress-v2m.dtsi   | 45 ++-
> >  arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts   | 14 ++
> >  arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 14 ++
> >  arch/arm/boot/dts/vexpress-v2p-ca5s.dts   | 14 ++
> >  arch/arm/boot/dts/vexpress-v2p-ca9.dts| 41 +++--
> >  arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 14 ++
> >  .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++
> >  8 files changed, 105 insertions(+), 118 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi 
> > b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > index 7b8ff5b3b912..69f6a9436325 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >  
> > -   v2m_video_ram: vram@2, {
> > -   compatible = "arm,vexpress-vram";
> > -   reg = <2 0x 0x0080>;
> > -   };
> > -
> > ethernet@2,0200 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <2 0x0200 0x1>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter@39 {
> > compatible = "sil,sii9022-tpi", 
> > "sil,sii9022";
> > reg = <0x39>;
> > +
> > +   ports {
> > +   port@0 {
> 
> 
> May need reg=<0> here, otherwise DTC might complain ?
> [...]
> 
> > diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi 
> > b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > index 9cd5e146abd5..067d84bc61c0 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >  
> > -   v2m_video_ram: vram@3, {
> > -   compatible = "arm,vexpress-vram";
> > -   reg = <3 0x 0x0080>;
> > -   };
> > -
> > ethernet@3,0200 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <3 0x0200 0x1>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter@39 {
> > compatible = "sil,sii9022-tpi", 
> > "sil,sii9022";
> > reg = <0x39>;
> > +
> > +   ports {
> > +   port@0 {
> 
> Ditto
> 
> > +   dvi_bridge_in: 
> > endpoint {
> > +   
> > remote-endpoint = <_pads>;
> > +   };
> > +   };
> > +   };
> >   

[Bug 199959] amdgpu, regression?: system freezes after resume

[bugzilla-daemon]

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

--- Comment #22 from Christian König (christian.koe...@amd.com) ---
Your debugging efforts are better than mine.

Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l
ECAP15+8.l" once before suspend and once after suspend without any changes
(e.g. when the problem happens).

-- 
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 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #19 from Christian König  ---
Ok then let's mark this as resolved for now.

-- 
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 v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes

[Thomas Hellstrom]

The current Wound-Wait mutex algorithm is actually not Wound-Wait but
Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
is, contrary to Wait-Die a preemptive algorithm and is known to generate
fewer backoffs. Testing reveals that this is true if the
number of simultaneous contending transactions is small.
As the number of simultaneous contending threads increases, Wait-Wound
becomes inferior to Wait-Die in terms of elapsed time.
Possibly due to the larger number of held locks of sleeping transactions.

Update documentation and callers.

Timings using git://people.freedesktop.org/~thomash/ww_mutex_test
tag patch-18-06-14

Each thread runs 10 batches of lock / unlock 800 ww mutexes randomly
chosen out of 10. Four core Intel x86_64:

Algorithm#threads   Rollbacks  time
Wound-Wait   4  ~100   ~17s.
Wait-Die 4  ~15~19s.
Wound-Wait   16 ~36~109s.
Wait-Die 16 ~45~82s.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Jonathan Corbet 
Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Davidlohr Bueso 
Cc: "Paul E. McKenney" 
Cc: Josh Triplett 
Cc: Thomas Gleixner 
Cc: Kate Stewart 
Cc: Philippe Ombredanne 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Thomas Hellstrom 

---
v2:
* Update API according to review comment by Greg Kroah-Hartman.
* Address review comments by Peter Zijlstra:
  - Avoid _Bool in composites
  - Fix typo
  - Use __mutex_owner() where applicable
  - Rely on built-in barriers for the main loop exit condition,
struct ww_acquire_ctx::wounded. Update code comments.
  - Explain unlocked use of list_empty().
---
 Documentation/locking/ww-mutex-design.txt |  54 
 drivers/dma-buf/reservation.c |   2 +-
 drivers/gpu/drm/drm_modeset_lock.c|   2 +-
 include/linux/ww_mutex.h  |  19 --
 kernel/locking/locktorture.c  |   2 +-
 kernel/locking/mutex.c| 103 +++---
 kernel/locking/test-ww_mutex.c|   2 +-
 lib/locking-selftest.c|   2 +-
 8 files changed, 156 insertions(+), 30 deletions(-)

diff --git a/Documentation/locking/ww-mutex-design.txt 
b/Documentation/locking/ww-mutex-design.txt
index 34c3a1b50b9a..b9597def9581 100644
--- a/Documentation/locking/ww-mutex-design.txt
+++ b/Documentation/locking/ww-mutex-design.txt
@@ -1,4 +1,4 @@
-Wait/Wound Deadlock-Proof Mutex Design
+Wound/Wait Deadlock-Proof Mutex Design
 ==
 
 Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
@@ -32,10 +32,23 @@ the oldest task) wins, and the one with the higher 
reservation id (i.e. the
 younger task) unlocks all of the buffers that it has already locked, and then
 tries again.
 
-In the RDBMS literature this deadlock handling approach is called wait/wound:
-The older tasks waits until it can acquire the contended lock. The younger 
tasks
-needs to back off and drop all the locks it is currently holding, i.e. the
-younger task is wounded.
+In the RDBMS literature, a reservation ticket is associated with a transaction.
+and the deadlock handling approach is called Wait-Die. The name is based on
+the actions of a locking thread when it encounters an already locked mutex.
+If the transaction holding the lock is younger, the locking transaction waits.
+If the transaction holding the lock is older, the locking transaction backs off
+and dies. Hence Wait-Die.
+There is also another algorithm called Wound-Wait:
+If the transaction holding the lock is younger, the locking transaction
+preempts the transaction holding the lock, requiring it to back off. It
+Wounds the other transaction.
+If the transaction holding the lock is older, it waits for the other
+transaction. Hence Wound-Wait.
+The two algorithms are both fair in that a transaction will eventually succeed.
+However, the Wound-Wait algorithm is typically stated to generate fewer 
backoffs
+compared to Wait-Die, but is, on the other hand, associated with more work than
+Wait-Die when recovering from a backoff. Wound-Wait is also a preemptive
+algorithm which requires a reliable way to preempt another transaction.
 
 Concepts
 
@@ -47,10 +60,12 @@ Acquire context: To ensure eventual forward progress it is 
important the a task
 trying to acquire locks doesn't grab a new reservation id, but keeps the one it
 acquired when starting the lock acquisition. This ticket is stored in the
 acquire context. Furthermore the acquire context keeps track of debugging state
-to catch w/w mutex interface abuse.
+to catch w/w mutex interface abuse. An acquire context is representing a
+transaction.
 
 W/w class: In contrast to normal mutexes the lock class needs to be explicit 
for
-w/w mutexes, since it is required to initialize the acquire context.

[PATCH v2 2/2] drm: Change deadlock-avoidance algorithm for the modeset locks.

[Thomas Hellstrom]

For modeset locks we don't expect a high number of contending
transactions so change algorithm from Wait-Die to Wound-Wait.

Signed-off-by: Thomas Hellstrom 

---
v2: Update to API change.
---
 drivers/gpu/drm/drm_modeset_lock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index ff00a814f617..8a5100685875 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -70,7 +70,7 @@
  * lists and lookup data structures.
  */
 
-static DEFINE_WW_CLASS_WDIE(crtc_ww_class);
+static DEFINE_WW_CLASS(crtc_ww_class);
 
 /**
  * drm_modeset_lock_all - take all modeset locks
-- 
2.14.3

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

[PATCH v2 0/2] locking, drm: Fix ww mutex naming / algorithm inconsistency

[Thomas Hellstrom]

This is a small fallout from a work to allow batching WW mutex locks and
unlocks.

Our Wound-Wait mutexes actually don't use the Wound-Wait algorithm but
the Wait-Die algorithm. One could perhaps rename those mutexes tree-wide to
"Wait-Die mutexes" or "Deadlock Avoidance mutexes". Another approach suggested
here is to implement also the "Wound-Wait" algorithm as a per-WW-class
choice, as it has advantages in some cases. See for example

http://www.mathcs.emory.edu/~cheung/Courses/554/Syllabus/8-recv+serial/deadlock-compare.html

Now Wound-Wait is a preemptive algorithm, and the preemption is implemented
using a lazy scheme: If a wounded transaction is about to go to sleep on
a contended WW mutex, we return -EDEADLK. That is sufficient for deadlock
prevention. Since with WW mutexes we also require the aborted transaction to
sleep waiting to lock the WW mutex it was aborted on, this choice also provides
a suitable WW mutex to sleep on. If we were to return -EDEADLK on the first
WW mutex lock after the transaction was wounded whether the WW mutex was
contended or not, the transaction might frequently be restarted without a wait,
which is far from optimal. Note also that with the lazy preemption scheme,
contrary to Wait-Die there will be no rollbacks on lock contention of locks
held by a transaction that has completed its locking sequence.

The modeset locks are then changed from Wait-Die to Wound-Wait since the
typical locking pattern of those locks very well matches the criterion for
a substantial reduction in the number of rollbacks. For reservation objects,
the benefit is more unclear at this point and they remain using Wait-Die.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Jonathan Corbet 
Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Davidlohr Bueso 
Cc: "Paul E. McKenney" 
Cc: Josh Triplett 
Cc: Thomas Gleixner 
Cc: Kate Stewart 
Cc: Philippe Ombredanne 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org

v2:
  Updated DEFINE_WW_CLASS() API, minor code- and comment fixes as
  detailed in each patch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"

[Paul Kocialkowski]

Hi,

On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote:
> Hello,
> 
> sorry for my ignorance.
> I don't know the right patch workflow in the case of "revert commit".
> When I fix this bug, should I have to re-submit the previous patch 
> entire plus bug-fix?
>
> Or do I have to submit patch with bug-fix only?

Yes, that is usually how it works! The revert patch will be picked up by
the maintainer (Maxime), integrated in his tree and eventually merged
into Linus' tree (along with stable trees).

Fixup patches for this will need to take into account the revert patch,
so it becomes equivalent to submitting the same patch with that issue
resolved.

> Thanks in advance to everybody

Cheers !

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 81678] X crashes on start (integrated 7640G + discrete 7500M/7600M)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Product|DRI |xorg
 QA Contact||xorg-t...@lists.x.org
  Component|DRM/Radeon  |Lib/pciaccess
   Assignee|dri-devel@lists.freedesktop |xorg-t...@lists.x.org
   |.org|

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

Re: [PATCH 3/3] drm/bridge/sii8620: fix loops in EDID fetch logic

[Maciej Purski]

Hi Andrzej,

On 01/15/2018 06:33 PM, Andrzej Hajda wrote:
> Function should constantly check if cable is connected and finish
> in finite time.
> 
> Signed-off-by: Andrzej Hajda 

Looks fine to me.

Reviewed-by: Maciej Purski 

> ---
>   drivers/gpu/drm/bridge/sil-sii8620.c | 31 ---
>   1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 7c46847fef18..f65e14836c0e 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -801,6 +801,7 @@ static void sii8620_burst_rx_all(struct sii8620 *ctx)
>   static void sii8620_fetch_edid(struct sii8620 *ctx)
>   {
>   u8 lm_ddc, ddc_cmd, int3, cbus;
> + unsigned long timeout;
>   int fetched, i;
>   int edid_len = EDID_LENGTH;
>   u8 *edid;
> @@ -850,23 +851,31 @@ static void sii8620_fetch_edid(struct sii8620 *ctx)
>   REG_DDC_CMD, ddc_cmd | VAL_DDC_CMD_ENH_DDC_READ_NO_ACK
>   );
>   
> - do {
> - int3 = sii8620_readb(ctx, REG_INTR3);
> + int3 = 0;
> + timeout = jiffies + msecs_to_jiffies(200);
> + for (;;) {
>   cbus = sii8620_readb(ctx, REG_CBUS_STATUS);
> -
> - if (int3 & BIT_DDC_CMD_DONE)
> - break;
> -
> - if (!(cbus & BIT_CBUS_STATUS_CBUS_CONNECTED)) {
> + if (~cbus & BIT_CBUS_STATUS_CBUS_CONNECTED) {
> + kfree(edid);
> + edid = NULL;
> + goto end;
> + }
> + if (int3 & BIT_DDC_CMD_DONE) {
> + if (sii8620_readb(ctx, REG_DDC_DOUT_CNT)
> + >= FETCH_SIZE)
> + break;
> + } else {
> + int3 = sii8620_readb(ctx, REG_INTR3);
> + }
> + if (time_is_before_jiffies(timeout)) {
> + ctx->error = -ETIMEDOUT;
> + dev_err(ctx->dev, "timeout during EDID read\n");
>   kfree(edid);
>   edid = NULL;
>   goto end;
>   }
> - } while (1);
> -
> - sii8620_readb(ctx, REG_DDC_STATUS);
> - while (sii8620_readb(ctx, REG_DDC_DOUT_CNT) < FETCH_SIZE)
>   usleep_range(10, 20);
> + }
>   
>   sii8620_read_buf(ctx, REG_DDC_DATA, edid + fetched, FETCH_SIZE);
>   if (fetched + FETCH_SIZE == EDID_LENGTH) {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality

[Boris Ostrovsky]

On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:
> On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
>>
>>
>> On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
>>
>>>   int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
>>> fd)
>>>   {
>>> -    return -EINVAL;
>>> +    struct gntdev_dmabuf *gntdev_dmabuf;
>>> +    struct dma_buf_attachment *attach;
>>> +    struct dma_buf *dma_buf;
>>> +
>>> +    gntdev_dmabuf = dmabuf_imp_find_unlink(priv, fd);
>>> +    if (IS_ERR(gntdev_dmabuf))
>>> +    return PTR_ERR(gntdev_dmabuf);
>>> +
>>> +    pr_debug("Releasing DMA buffer with fd %d\n", fd);
>>> +
>>> +    attach = gntdev_dmabuf->u.imp.attach;
>>> +
>>> +    if (gntdev_dmabuf->u.imp.sgt)
>>> +    dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
>>> + DMA_BIDIRECTIONAL);
>>> +    dma_buf = attach->dmabuf;
>>> +    dma_buf_detach(attach->dmabuf, attach);
>>> +    dma_buf_put(dma_buf);
>>> +
>>> +    dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs,
>>> +  gntdev_dmabuf->nr_pages);
>>
>>
>>
>> Should you first end foreign access, before doing anything?
>>
> I am rolling back in reverse order here, so I think we first need
> to finish local activities with the buffer and then end foreign
> access.

Looking at gntdev_dmabuf_imp_to_refs(), the order is
    dmabuf_imp_alloc_storage()
    dma_buf_attach()
    dma_buf_map_attachment()
    dmabuf_imp_grant_foreign_access()

Or was I looking at wrong place?

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

Re: [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality

[Oleksandr Andrushchenko]

On 06/14/2018 01:03 AM, Boris Ostrovsky wrote:

On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:

On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:


On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:


   int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
fd)
   {
-    return -EINVAL;
+    struct gntdev_dmabuf *gntdev_dmabuf;
+    struct dma_buf_attachment *attach;
+    struct dma_buf *dma_buf;
+
+    gntdev_dmabuf = dmabuf_imp_find_unlink(priv, fd);
+    if (IS_ERR(gntdev_dmabuf))
+    return PTR_ERR(gntdev_dmabuf);
+
+    pr_debug("Releasing DMA buffer with fd %d\n", fd);
+
+    attach = gntdev_dmabuf->u.imp.attach;
+
+    if (gntdev_dmabuf->u.imp.sgt)
+    dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
+ DMA_BIDIRECTIONAL);
+    dma_buf = attach->dmabuf;
+    dma_buf_detach(attach->dmabuf, attach);
+    dma_buf_put(dma_buf);
+
+    dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs,
+  gntdev_dmabuf->nr_pages);



Should you first end foreign access, before doing anything?


I am rolling back in reverse order here, so I think we first need
to finish local activities with the buffer and then end foreign
access.

Looking at gntdev_dmabuf_imp_to_refs(), the order is
     dmabuf_imp_alloc_storage()
     dma_buf_attach()
     dma_buf_map_attachment()
     dmabuf_imp_grant_foreign_access()

Or was I looking at wrong place?

Agree, will move as you suggest

-boris


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

[PATCH v9 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[Sandeep Panda]

Document the bindings used for the sn65dsi86 DSI to eDP bridge.

Changes in v1:
 - Rephrase the dt-binding descriptions to be more inline with existing
   bindings (Andrzej Hajda).
 - Add missing dt-binding that are parsed by corresponding driver
   (Andrzej Hajda).

Changes in v2:
 - Remove edp panel specific dt-binding entries. Only keep bridge
   specific entries (Sean Paul).
 - Remove custom-modes dt entry since its usage is removed from driver also 
(Sean Paul).
 - Remove is-pluggable dt entry since this will not be needed anymore (Sean 
Paul).

Changes in v3:
 - Remove irq-gpio dt entry and instead populate is an interrupt
   property (Rob Herring).

Changes in v4:
 - Add link to bridge chip datasheet (Stephen Boyd)
 - Add vpll and vcc regulator supply bindings (Stephen Boyd)
 - Add ref clk optional dt binding (Stephen Boyd)
 - Add gpio-controller optional dt binding (Stephen Boyd)

Changes in v5:
 - Use clock property to specify the input refclk (Stephen Boyd).
 - Update gpio cell and pwm cell numbers (Stephen Boyd).

Changes in v6:
 - Add property to mention the lane mapping scheme and polarity inversion
   (Stephen Boyd).

Changes in v7:
 - Detail description of lane mapping scheme dt property (Andrzej
   Hajda/ Rob Herring).
 - Removed HDP gpio binding, since the bridge uses IRQ signal to
   determine HPD, and IRQ property is already documented in binding.

Changes in v8:
 - Removed unnecessary explanation of lane mapping and polarity dt
   property, since these are already explained in media/video-interface
   dt binidng (Rob Herring).

Signed-off-by: Sandeep Panda 
---
 .../bindings/display/bridge/ti,sn65dsi86.txt   | 90 ++
 1 file changed, 90 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 000..601454c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,90 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specification for bridge_en pin (active 
high)
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vpll-supply: A 1.8V supply that powers up the displayport PLL.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+- vcc-supply: A 1.2V supply that powers up the digital core.
+
+Optional properties:
+- interrupts: Specifier for the SN65DSI86 interrupt line.
+
+- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
+
+- gpio-controller: Marks the device has a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../../gpio/gpio.txt for more information.
+- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
+   the cell formats.
+
+- clock-names: should be "refclk"
+- clocks: Specification for input reference clock. The reference
+ clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
+
+- data-lanes: Specification to describe the logical to physical lane
+ mapping scheme. See ../../media/video-interface.txt for more
+ information.
+- lane-polarities: Specification to describe the polarity of physical lanes.
+  See ../../media/video-interface.txt for more information.
+
+Required nodes:
+This device has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+   compatible = "ti,sn65dsi86";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x2d>;
+
+   enable-gpios = < 33 GPIO_ACTIVE_HIGH>;
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+
+   vccio-supply = <_l17>;
+   vcca-supply = <_l6>;
+   vpll-supply = <_l17>;
+   vcc-supply = <_l6>;
+
+   clock-names = "refclk";
+   clocks = <_refclk>;
+
+   data-lanes = <2 1 3 0>;
+   lane-polarities = <0 1 0 1>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   edp_bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   edp_bridge_out: 

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Ard Biesheuvel]

On 13 June 2018 at 16:22, Sinan Kaya  wrote:
> Hi Ard,
>
> On 5/18/2018 10:17 AM, Sinan Kaya wrote:
>> A host bridge is allowed to remap BAR addresses using _TRA attribute in
>> _CRS windows.
>>
>> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] 
>> (bus address [0x0010-0x1fff])
>> pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
>>
>> When a VGA device is behind such a host bridge and the resource is
>> translated efifb driver is trying to do ioremap against bus address
>> rather than the resource address and is failing to probe.
>>
>> efifb: probing for efifb
>> efifb: cannot reserve video memory at 0x1e00
>> efifb: framebuffer at 0x1e00, using 1920k, total 1875k
>> efifb: mode is 800x600x32, linelength=3200, pages=1
>> efifb: scrolling: redraw
>> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>>
>> Use the host bridge offset information to convert bus address to
>> resource address in the fixup.
>>
>> Signed-off-by: Sinan Kaya 
>> ---
>
> I didn't see any messages about these getting picked up for 4.18.
>
> Are they queued on your own branch?
>

No, you never cc'ed me on them until now.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[spanda]

On 2018-06-06 04:29, Sean Paul wrote:

On Tue, Jun 05, 2018 at 11:10:15AM +0530, Sandeep Panda wrote:

Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.

This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c interface only.
Also as of now HPD support has not been added to bridge
chip driver.

Changes in v1:
 - Split the dt-bindings and the driver support into separate patches
   (Andrzej Hajda).
 - Use of gpiod APIs to parse and configure gpios instead of obsolete 
ones

   (Andrzej Hajda).
 - Use macros to define the register offsets (Andrzej Hajda).

Changes in v2:
 - Separate out edp panel specific HW resource handling from bridge
   driver and create a separate edp panel drivers to handle panel
   specific mode information and HW resources (Sean Paul).
 - Replace pr_* APIs to DRM_* APIs to log error or debug information
   (Sean Paul).
 - Remove some of the unnecessary structure/variable from driver (Sean
   Paul).
 - Rename the function and structure prefix "sn65dsi86" to 
"ti_sn_bridge"

   (Sean Paul / Rob Herring).
 - Remove most of the hard-coding and modified the bridge init 
sequence

   based on current mode (Sean Paul).
 - Remove the existing function to retrieve the EDID data and
   implemented this as an i2c_adapter and use drm_get_edid() (Sean 
Paul).

 - Remove the dummy irq handler implementation, will add back the
   proper irq handling later (Sean Paul).
 - Capture the required enable gpios in a single array based on dt 
entry

   instead of having individual descriptor for each gpio (Sean Paul).

Changes in v3:
 - Remove usage of irq_gpio and replace it as "interrupts" property 
(Rob

   Herring).
 - Remove the unnecessary header file inclusions (Sean Paul).
 - Rearrange the header files in alphabetical order (Sean Paul).
 - Use regmap interface to perform i2c transactions.
 - Update Copyright/License field and address other review comments
   (Jordan Crouse).

Changes in v4:
 - Update License/Copyright (Sean Paul).
 - Add Kconfig and Makefile changes (Sean Paul).
 - Drop i2c gpio handling from this bridge driver, since i2c sda/scl 
gpios

   will be handled by i2c master.
 - Update required supplies names.
 - Remove unnecessary goto statements (Sean Paul).
 - Add mutex lock to power_ctrl API to avoid race conditions (Sean
   Paul).
 - Add support to parse reference clk frequency from dt(optional).
 - Update the bridge chip enable/disable sequence.

Changes in v5:
 - Fixed Kbuild test service reported warnings.

Changes in v6:
 - Use PM runtime based ref-counting instead of local ref_count 
mechanism

   (Stephen Boyd).
 - Clean up some debug logs and indentations (Sean Paul).
 - Simplify dp rate calculation (Sean Paul).
 - Add support to configure refclk based on input REFCLK pin or DACP/N
   pin (Stephen Boyd).

Changes in v7:
 - Use static supply entries instead of dynamic allocation (Andrzej
   Hajda).
 - Defer bridge driver probe if panel is not probed (Andrzej Hajda).
 - Update of_graph APIs for correct node reference management. 
(Andrzej

   Hajda).
 - Remove local display_mode object (Andrzej Hajda).
 - Remove version id check function from driver.

Changes in v8:
 - Move dsi register/attach function to bridge driver probe (Andrzej
   Hajda).
 - Introduce a new helper function to write 16bit words into 
consecutive

   registers (Andrzej Hajda).
 - Remove unnecessary macros (Andrzej Hajda).

Signed-off-by: Sandeep Panda 
---
 drivers/gpu/drm/bridge/Kconfig|   9 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 666 
++

 3 files changed, 676 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c

diff --git a/drivers/gpu/drm/bridge/Kconfig 
b/drivers/gpu/drm/bridge/Kconfig

index 3b99d5a..8153150 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -108,6 +108,15 @@ config DRM_TI_TFP410
---help---
  Texas Instruments TFP410 DVI/HDMI Transmitter driver

+config DRM_TI_SN65DSI86
+   tristate "TI SN65DSI86 DSI to eDP bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   ---help---
+ Texas Instruments SN65DSI86 DSI to eDP Bridge driver
+
 source "drivers/gpu/drm/bridge/analogix/Kconfig"

 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile 
b/drivers/gpu/drm/bridge/Makefile

index 373eb28..3711be8 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o


SN65DSI86 

Re: [PATCH v2] drm/bridge/sii8620: simplify hardware reset procedure

[Maciej Purski]

Hi Andrzej,

On 06/08/2018 08:04 AM, Andrzej Hajda wrote:
> There is no need to flip reset pin twice. Also delays can be changed to
> values present in vendor's code.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Maciej Purski 

> ---
> Hi,
> 
> This is v2 of forgotten patch, awaiting reviewers, any volunteers.
> Also "drm/bridge/sii8620: fix loops in EDID fetch logic" waits for reviewers.
> 
> In this version I have completely removed reset function, and moved its body
> to sii8620_hw_on.
> 
> Regards
> Andrzej
> ---
>   drivers/gpu/drm/bridge/sil-sii8620.c | 23 ++-
>   1 file changed, 10 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 7ab36042a822..d1e780fba4b6 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -971,8 +971,17 @@ static int sii8620_hw_on(struct sii8620 *ctx)
>   ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
>   if (ret)
>   return ret;
> +
>   usleep_range(1, 2);
> - return clk_prepare_enable(ctx->clk_xtal);
> + ret = clk_prepare_enable(ctx->clk_xtal);
> + if (ret)
> + return ret;
> +
> + msleep(100);
> + gpiod_set_value(ctx->gpio_reset, 0);
> + msleep(100);
> +
> + return 0;
>   }
>   
>   static int sii8620_hw_off(struct sii8620 *ctx)
> @@ -982,17 +991,6 @@ static int sii8620_hw_off(struct sii8620 *ctx)
>   return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
>   }
>   
> -static void sii8620_hw_reset(struct sii8620 *ctx)
> -{
> - usleep_range(1, 2);
> - gpiod_set_value(ctx->gpio_reset, 0);
> - usleep_range(5000, 2);
> - gpiod_set_value(ctx->gpio_reset, 1);
> - usleep_range(1, 2);
> - gpiod_set_value(ctx->gpio_reset, 0);
> - msleep(300);
> -}
> -
>   static void sii8620_cbus_reset(struct sii8620 *ctx)
>   {
>   sii8620_write(ctx, REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST
> @@ -2112,7 +2110,6 @@ static void sii8620_cable_in(struct sii8620 *ctx)
>   dev_err(dev, "Error powering on, %d.\n", ret);
>   return;
>   }
> - sii8620_hw_reset(ctx);
>   
>   sii8620_read_buf(ctx, REG_VND_IDL, ver, ARRAY_SIZE(ver));
>   ret = sii8620_clear_error(ctx);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel