date:20190509

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

qmaster...@gmail.com changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #8 from qmaster...@gmail.com ---
Our problem was caused by the opensource coreboot BIOS incorrectly initializing
the discrete GPU. These unofficial patches are solving our problem -
https://review.coreboot.org/c/coreboot/+/31929/ . And here is our latest
board-status report, containing a new kernel log and other useful info -
https://coreboot.org/status/board-status.html#lenovo/g505s . So this issue
could be closed - and if someone has a similar problem he could reopen,
although maybe it's better to do a fresh start by creating a new issue.

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

RE: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v7

2019-05-09 Thread Liang, Prike

Thanks Christian proposal and David draft the solution implement .

The pinned Bos failed not observed from prepare_fb ,but Abaqus job can't  
finished through the whole night .
Regards the NULL fist BO EBUSY error case , which  comes from 
amdgpu_cs_bo_validate perform period as the below call stack show . Now the 
NULL first BO debug error message popup out endlessly during Abaqus running 
,that's seems the function @amdgpu_cs_validate run into invoked 
amdgpu_cs_bo_validate dead loop.

lxj ttm_mem_evict_first first_bo=  
(null),request_resv=929d47b33218,request_resv->lock.ctx=929b8d6bfbd8
[ 2703.091731] CPU: 3 PID: 10739 Comm: standard Kdump: loaded Tainted: G
   OE     3.10.0-957.el7.x86_64 #1
[ 2703.103046] Hardware name: MSI MS-7984/Z170 KRAIT GAMING (MS-7984), BIOS 
B.80 05/11/2016
[ 2703.81] Call Trace:
[ 2703.113745]  [] dump_stack+0x19/0x1b
[ 2703.118979]  [] ttm_mem_evict_first+0x3a9/0x400 [amdttm]
[ 2703.125974]  [] amdttm_bo_mem_space+0x2eb/0x4a0 [amdttm]
[ 2703.132967]  [] amdttm_bo_validate+0xc4/0x140 [amdttm]
[ 2703.139827]  [] amdgpu_cs_bo_validate+0xa5/0x220 [amdgpu]
[ 2703.146879]  [] amdgpu_cs_validate+0x47/0x2e0 [amdgpu]
[ 2703.153776]  [] ? amdgpu_vm_del_from_lru_notify+0x12/0x80 
[amdgpu]
[ 2703.161707]  [] ? amdgpu_cs_bo_validate+0x220/0x220 
[amdgpu]
[ 2703.169018]  [] amdgpu_vm_validate_pt_bos+0x92/0x140 
[amdgpu]
[ 2703.176512]  [] amdgpu_cs_ioctl+0x18a5/0x1d40 [amdgpu]
[ 2703.183372]  [] ? amdgpu_cs_find_mapping+0x120/0x120 
[amdgpu]
[ 2703.190815]  [] drm_ioctl_kernel+0x6c/0xb0 [drm]
[ 2703.197109]  [] drm_ioctl+0x1e7/0x420 [drm]
[ 2703.202995]  [] ? amdgpu_cs_find_mapping+0x120/0x120 
[amdgpu]
[ 2703.210471]  [] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu]
[ 2703.217019]  [] do_vfs_ioctl+0x3a0/0x5a0
[ 2703.222596]  [] ? __schedule+0x13a/0x890
[ 2703.228172]  [] SyS_ioctl+0xa1/0xc0
[ 2703.233308]  [] system_call_fastpath+0x22/0x27

Thanks,
Prike
From: Christian König 
Sent: Thursday, May 09, 2019 10:59 PM
To: Zhou, David(ChunMing) ; Koenig, Christian 
; Liang, Prike ; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v7

[CAUTION: External Email]
Oh, I know where this is coming from.

The problem is that we remove the BOs from the LRU during CS and so we can't 
wait for the CS to finish up.

Already working on this problem for Marek's similar issue,
Christian.

Am 09.05.19 um 16:46 schrieb Zhou, David(ChunMing):
I know that before, it will issue warning only when debug option is enabled. 
Removing that is ok to me.
I only help Prike draft your idea, and Prike is trying this patch on his side. 
The latest feedback he gave me is first_bo is always null, code doesn't run 
into busy path, which is very confusing me, and he said  he is debugging  that.

-David


 Original Message 
Subject: Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v7
From: "Koenig, Christian"
To: "Zhou, David(ChunMing)" ,"Liang, Prike" 
,dri-devel@lists.freedesktop.org
CC:
I've foudn one more problem with this.

With lockdep enabled I get a warning because ttm_eu_reserve_buffers()
has called ww_acquire_done() on the ticket (which essentially means we
are done, no more locking with that ticket).

The simplest solution is probably to just remove the call to
ww_acquire_done() from ttm_eu_reserve_buffers().

Christian.

Am 07.05.19 um 13:45 schrieb Chunming Zhou:
> heavy gpu job could occupy memory long time, which lead other user fail to 
> get memory.
>
> basically pick up Christian idea:
>
> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
> 2. If we then run into this EBUSY condition in TTM check if the BO we need 
> memory for (or rather the ww_mutex of its reservation object) has a ticket 
> assigned.
> 3. If we have a ticket we grab a reference to the first BO on the LRU, drop 
> the LRU lock and try to grab the reservation lock with the ticket.
> 4. If getting the reservation lock with the ticket succeeded we check if the 
> BO is still the first one on the LRU in question (the BO could have moved).
> 5. If the BO is still the first one on the LRU in question we try to evict it 
> as we would evict any other BO.
> 6. If any of the "If's" above fail we just back off and return -EBUSY.
>
> v2: fix some minor check
> v3: address Christian v2 comments.
> v4: fix some missing
> v5: handle first_bo unlock and bo_get/put
> v6: abstract unified iterate function, and handle all possible usecase not 
> only pinned bo.
> v7: pass request bo->resv to ttm_bo_evict_first
>
> Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 111 +--
>   1 file changed, 94 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8502b3ed2d88..f5e6328e4a57 100644
> --- a/drivers/gpu/drm/ttm

[Bug 110637] Any OpenCL application causes "ERROR ring gfx timeout" on Vega 64

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

--- Comment #8 from Alexander Mezin  ---
(In reply to Jan Vesely from comment #6)
> if yes can you confirm if the games hang when running with
> OCL_ICD_VENDORS=/var/empty/ ?
> (alternatively, you can just move libMesaOpenCL.* out of library path)

No, setting OCL_ICD_VENDORS didn't change anything (though I'm not completely
sure that Steam and then Proton don't discard environment variables somewhere).

However, upgrading Mesa to 19.0.4 fixed game hangs. OpenCL issues are still
here.

-- 
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 108824] Invalid handling when GL buffer is bound on one context and invalidated on another

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

--- Comment #4 from Marek Olšák  ---
This is fixed by these patches:
https://patchwork.freedesktop.org/series/60491/

-- 
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 110658] MXGP3 (Steam, native Linux port, UE4): graphical glitches

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

Bug ID: 110658
   Summary: MXGP3 (Steam, native Linux port, UE4): graphical
glitches
   Product: Mesa
   Version: 19.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mezin.alexan...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

In game the screen is sometimes too dark, when it shouldn't, sparks everywhere.
In menus everything is OK.

Screen capture: https://youtu.be/rr9DdFfII5E (glitches begin at 0:16)

Also reported the issue to game developers, got no response so far.

gpu: RX Vega 64
mesa: 19.0.3, also tested with 19.1 rc1, no changes
linux 5.0

-- 
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 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 05:40:48PM -0600, Logan Gunthorpe wrote:
> 
> Based on some of the other commenters, I was under the impression that
> kselftests had in-kernel tests but I'm not sure where or if they exist. If
> they do exists, it seems like it would make sense to convert those to kunit
> and have Kunit tests run-able in a VM or baremetal instance.

There are kselftests tests which are shell scripts which load a
module, and the module runs the in-kernel code.  However, I didn't see
much infrastructure for the in-kernel test code; the one or two test
modules called from kselftests looked pretty ad hoc to me.

That's why I used the "vise grips" analogy.  You can use a pair of
vise grips like a monkey wrench; but it's not really a monkey wrench,
and might not be the best tool to loosen or tighten nuts and bolts.

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

[Bug 110637] Any OpenCL application causes "ERROR ring gfx timeout" on Vega 64

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

--- Comment #7 from Alexander Mezin  ---
(In reply to Jan Vesely from comment #6)
> Can you post the output of 'clinfo'?

Sure

Number of platforms   1
  Platform Name   Clover
  Platform Vendor Mesa
  Platform VersionOpenCL 1.1 Mesa 19.0.4
  Platform ProfileFULL_PROFILE
  Platform Extensions cl_khr_icd
  Platform Extensions function suffix MESA

  Platform Name   Clover
Number of devices 1
  Device Name Radeon RX Vega (VEGA10, DRM
3.30.0, 5.1.0-arch1-1-ARCH, LLVM 8.0.0)
  Device Vendor   AMD
  Device Vendor ID0x1002
  Device Version  OpenCL 1.1 Mesa 19.0.4
  Driver Version  19.0.4
  Device OpenCL C Version OpenCL C 1.1 
  Device Type GPU
  Device Profile  FULL_PROFILE
  Device AvailableYes
  Compiler Available  Yes
  Max compute units   64
  Max clock frequency 1630MHz
  Max work item dimensions3
  Max work item sizes 256x256x256
  Max work group size 256
  Preferred work group size multiple  64
  Preferred / native vector sizes 
char16 / 16  
short8 / 8   
int  4 / 4   
long 2 / 2   
half 8 / 8   
(cl_khr_fp16)
float4 / 4   
double   2 / 2   
(cl_khr_fp64)
  Half-precision Floating-point support   (cl_khr_fp16)
Denormals No
Infinity and NANs Yes
Round to nearest  Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add   No
Support is emulated in software   No
  Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest  Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add   No
Support is emulated in software   No
Correctly-rounded divide and sqrt operations  No
  Double-precision Floating-point support (cl_khr_fp64)
Denormals Yes
Infinity and NANs Yes
Round to nearest  Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add   Yes
Support is emulated in software   No
  Address bits64, Little-Endian
  Global memory size  8573157376 (7.984GiB)
  Error Correction supportNo
  Max memory allocation   6858525900 (6.387GiB)
  Unified memory for Host and Device  No
  Minimum alignment for any data type 128 bytes
  Alignment of base address   32768 bits (4096 bytes)
  Global Memory cache typeNone
  Image support   No
  Local memory type   Local
  Local memory size   32768 (32KiB)
  Max number of constant args 16
  Max constant buffer size2147483647 (2GiB)
  Max size of kernel argument 1024
  Queue properties
Out-of-order executionNo
Profiling Yes
  Profiling timer resolution  0ns
  Execution capabilities  
Run OpenCL kernelsYes
Run native kernelsNo
  Device Extensions   cl_khr_byte_addressable_store
cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics
cl_khr

[Bug] program become uninterrupt(STAT D) when run 64 graphics program in sub window

2019-05-09 Thread wormwang



Linux kernel 5.0 , amd rx580 gpu card


1 or many graphics program become uninterrupted(STAT D) when run 64 
graphics program of sub-window concurrently.


We have to reboot machine to release the uninterrupted(STAT D) program.

We have such kernel log:


 kernel: RenderThread D 0 393786 337242 0x0048
 kernel: Call trace:
 kernel: __switch_to+0xbc/0x1c0
 kernel: __schedule+0x3fc/0xca0
 kernel: 0x801fd32a
 kernel: TP-IoBound-2 D 0 400200 337242 0x0040002d
 kernel: Call trace:
 kernel: __switch_to+0xbc/0x1c0
 kernel: __schedule+0x3fc/0xca0
 kernel: schedule+0x40/0x98
 kernel: schedule_preempt_disabled+0x28/0x40
 kernel: __mutex_lock+0x264/0x850
 kernel: mutex_lock_nested+0x3c/0x50
 kernel: drm_release+0x3c/0xd8 [drm]
 kernel: __fput+0xc0/0x230
 kernel: fput+0x20/0x30
 kernel: task_work_run+0xa0/0xd0
 kernel: do_exit+0x364/0xb50
 kernel: do_group_exit+0x40/0xa8
 kernel: get_signal+0xf0/0x970
 kernel: do_notify_resume+0x2ac/0x390
 kernel: work_pending+0x8/0x14
 kernel: BootAnimation D 0 400905 393737 0x
 kernel: Call trace:
 kernel: __switch_to+0xbc/0x1c0
 kernel: __schedule+0x3fc/0xca0
 kernel: schedule+0x40/0x98
 kernel: schedule_preempt_disabled+0x28/0x40
 kernel: __mutex_lock+0x264/0x850
 kernel: mutex_lock_nested+0x3c/0x50
 kernel: drm_stub_open+0x44/0x118 [drm]
 kernel: chrdev_open+0xac/0x1c0
 kernel: do_dentry_open+0x1c4/0x370
 kernel: vfs_open+0x38/0x48


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

[Bug 109345] drm-next-2018-12-14 -Linux PPC

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

--- Comment #40 from Christian Zigotzky  ---
Hi All,

Great news! :-) Allan successfully tested the latest patched Git kernel with
his two graphics cards today. 

OK, we know the bad commit and we have a patch. What’s next?

Cheers,
Christian

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

[PATCH v7 4/6] drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA

When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.

As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for the Pixel
Encoding/Colorimetry Format.

v2: Block comment style fix.

v6:
  Fix an wrong setting of MSA MISC1 fields for Pixel Encoding/Colorimetry
  Format indication. As per DP 1.4a spec Table 2-96 [MSA MISC1 and MISC0
  Fields for Pixel Encoding/Colorimetry Format Indication]
  When MISC1, bit 6, is Set to 1, a Source device uses a VSC SDP to
  indicate the Pixel Encoding/Colorimetry Format. On the wrong version
  it set a bit 5 of MISC1, now it set a bit 6 of MISC1.

Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_reg.h  | 1 +
 drivers/gpu/drm/i915/intel_ddi.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47fca645..2ad98e62034f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9524,6 +9524,7 @@ enum skl_power_gate {
 #define  TRANS_MSA_12_BPC  (3 << 5)
 #define  TRANS_MSA_16_BPC  (4 << 5)
 #define  TRANS_MSA_CEA_RANGE   (1 << 3)
+#define  TRANS_MSA_USE_VSC_SDP (1 << 14)
 
 /* LCPLL Control */
 #define LCPLL_CTL  _MMIO(0x130040)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2f1688ea5a2c..4441c5ba71fb 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1717,6 +1717,14 @@ void intel_ddi_set_pipe_settings(const struct 
intel_crtc_state *crtc_state)
 */
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
+   /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut] while sending
+* YCBCR 420 signals we should program MSA MISC1 fields which
+* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+*/
+   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   temp |= TRANS_MSA_USE_VSC_SDP;
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
 }
 
-- 
2.21.0

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

[PATCH v7 0/6] drm/i915/dp: Support for DP YCbCr4:2:0 outputs

On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr420.
The Bit per Pixel needs to be adjusted for YUV420 mode as it requires only
half of the RGB case.
 - Link M/N values are calculated and applied based on the Full Clock
 - Data M/N values needs to be calculated considering the data is half
   due to subsampling

These patches add a VSC structure for handling Pixel Encoding/Colorimetry
Formats and program YCBCR 4:2:0 to MSA and VSC SDP. And it changes a link
bandwidth computation for DP.

These patches tested on below test environment.
Test Environment: 
 - Tested System: Gen11 platform
 - Monitor: Wasabi Mango UHD430 REAL4K HDMI 2.0 Slim HDR DUAL DP i20
(This monitor supports HDMI YCbCr 4:2:0)
 - DP to HDMI Adaptor (Dongle) : Club3D CAC-1080 (This dongle supports
 DP YCbCr 4:2:0 pass through feature.)
 - To enable DP YCbCr 4:2:0 forcely, test enviromnent uses work arounds
   patches. You can find these on
   https://gitlab.freedesktop.org/elongbug/drm-tip/tree/dp_ycbcr420_work

The idea of a scaling (RGB -> YCbCr4:4:4 -> YCbCr 4:2:0) is to follow the
same approach used in YCbCr 4:2:0 on HDMI.

v2: Addressed Maarten's review comments, fixed minor coding and block comment
style. And reordered a first patch  ("drm/i915/dp: Support DP ports
YUV 4:2:0 output to GEN11") as a last patch.

v3: Addressed Ville's review comments.
Style fixed with few naming.
If lscon is active, it makes not to call intel_dp_ycbcr420_config() to avoid
to clobber of lspcon_ycbcr420_config() routine.
And it move the 420_only check into the intel_dp_ycbcr420_config().
Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
Because the pipe is running at the full bpp, keep pipe_bpp as RGB even though
YCbCr 4:2:0 output format is used.
Add a link bandwidth computation for YCbCr4:2:0 output format.

v4: Fix uninitialized return value which is reported by Dan Carpenter.

v5: Addressed reivew comments from Ville.
In order to make codes simple, it adds and uses intel_dp_output_bpp() function.
In order to avoid the extra indentation, it inverts if-clause on
intel_dp_ycbcr420_config().
Remove the error print where no errors print are allowed.

v6:
Link M/N values are calculated and applied based on the Full Clock for
YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode as it
requires only half of the RGB case.
 - Link M/N values are calculated and applied based on the Full Clock
 - Data M/N values needs to be calculated considering the data is half due
   to subsampling
Remove a doubling of pixel clock on a dot clock calculator for DP YCbCr 4:2:0.
Rebase and remove a duplicate setting of vsc_sdp.DB17.
Add a setting of dynamic range bit to  vsc_sdp.DB17.
Change Content Type bit to "Graphics" from "Not defined".
Change a dividing of pipe_bpp to muliplying to constant values on a switch-case
statement.
Fix an wrong setting of MSA MISC1 fields for Pixel Encoding/Colorimetry
Format indication. As per DP 1.4a spec Table 2-96 [MSA MISC1 and MISC0
Fields for Pixel Encoding/Colorimetry Format Indication] When MISC1, bit 6,
is Set to 1, a Source device uses a VSC SDP to indicate the Pixel
Encoding/Colorimetry Format. On the wrong version it set a bit 5 of MISC1,
now it set a bit 6 of MISC1.

v7:
Addressed review comments from Ville.
Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr.
Move a setting of dynamic range bit and a setting of bpc which is based
on pipe_bpp to a "drm/i915/dp: Program VSC Header and DB for Pixel
Encoding/Colorimetry Format" commit.
Change Content Type bit to "Not defined" from "Graphics".
Fix non-standard comment format.
Remove a referring to specific commit.
Remove duplicated checking of connector's ycbcr_420_allowed from
intel_pixel_encoding_setup_vsc().

References: https://patchwork.freedesktop.org/series/56059/

Gwan-gyeong Mun (6):
  drm/i915/dp: Add a config function for YCBCR420 outputs
  drm: Rename struct edp_vsc_psr to struct dp_sdp
  drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry
Format
  drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
  drm/i915/dp: Change a link bandwidth computation for DP
  drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11

 .../drm/bridge/analogix/analogix_dp_core.c|  12 +-
 .../drm/bridge/analogix/analogix_dp_core.h|   2 +-
 .../gpu/drm/bridge/analogix/analogix_dp_reg.c |  10 +-
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 drivers/gpu/drm/i915/intel_ddi.c  |  12 +-
 drivers/gpu/drm/i915/intel_dp.c   | 156 +-
 drivers/gpu/drm/i915/intel_dp.h   |   1 +
 drivers/gpu/drm/i915/intel_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_psr.c  |  12 +-
 includ

[PATCH v7 6/6] drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11

Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.

v2: Minor style fix.

Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_dp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 86dc5e23ea73..6583c656612b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7385,6 +7385,9 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
connector->interlace_allowed = true;
connector->doublescan_allowed = 0;
 
+   if (INTEL_GEN(dev_priv) >= 11)
+   connector->ycbcr_420_allowed = true;
+
intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
 
intel_dp_aux_init(intel_dp);
-- 
2.21.0

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

[PATCH v7 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format

Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.

Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120:VSC SDP Payload for DB16 through DB18.

v2:
  Minor style fix. [Maarten]
  Refer to commit ids instead of patchwork. [Maarten]

v6: Rebase

v7:
  Rebase and addressed review comments from Ville.
  Use a structure initializer instead of memset().
  Fix non-standard comment format.
  Remove a referring to specific commit.
  Add a setting of dynamic range bit to  vsc_sdp.DB17.
  Add a setting of bpc which is based on pipe_bpp.
  Remove duplicated checking of connector's ycbcr_420_allowed from
  intel_pixel_encoding_setup_vsc(). It is already checked from
  intel_dp_ycbcr420_config().
  Remove comments for VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED. It is
  already implemented on intel_dp_get_colorimetry_status().

Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/intel_ddi.c |  1 +
 drivers/gpu/drm/i915/intel_dp.c  | 90 
 drivers/gpu/drm/i915/intel_drv.h |  2 +
 3 files changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd5277d98b03..2f1688ea5a2c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3391,6 +3391,7 @@ static void intel_enable_ddi_dp(struct intel_encoder 
*encoder,
 
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
+   intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
 
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9f219f8f0c71..a3fd279a5c52 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4407,6 +4407,96 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp 
*intel_dp,
return 0;
 }
 
+static void
+intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
+  const struct intel_crtc_state *crtc_state)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct dp_sdp vsc_sdp = {};
+
+   /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
+   vsc_sdp.sdp_header.HB0 = 0;
+   vsc_sdp.sdp_header.HB1 = 0x7;
+
+   /*
+* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication.
+*/
+   vsc_sdp.sdp_header.HB2 = 0x5;
+
+   /*
+* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
+* Colorimetry Format indication (HB2 = 05h).
+*/
+   vsc_sdp.sdp_header.HB3 = 0x13;
+
+   /*
+* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
+* DB16[3:0] DP 1.4a spec, Table 2-120
+*/
+   vsc_sdp.DB[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
+   /* RGB->YCBCR color conversion uses the BT.709 color space. */
+   vsc_sdp.DB[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+
+   /*
+* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
+* the following Component Bit Depth values are defined:
+* 001b = 8bpc.
+* 010b = 10bpc.
+* 011b = 12bpc.
+* 100b = 16bpc.
+*/
+   switch (crtc_state->pipe_bpp) {
+   case 24: /* 8bpc */
+   vsc_sdp.DB[17] = 0x1;
+   break;
+   case 30: /* 10bpc */
+   vsc_sdp.DB[17] = 0x2;
+   break;
+   case 36: /* 12bpc */
+   vsc_sdp.DB[17] = 0x3;
+   break;
+   case 48: /* 16bpc */
+   vsc_sdp.DB[17] = 0x4;
+   break;
+   default:
+   DRM_DEBUG_KMS("Invalid bpp value '%d'\n", crtc_state->pipe_bpp);
+   break;
+   }
+
+   /*
+* Dynamic Range (Bit 7)
+* 0 = VESA range, 1 = CTA range.
+* all YCbCr are always limited range
+*/
+   vsc_sdp.DB[17] |= 0x80;
+
+   /*
+* Content Type (Bits 2:0)
+* 000b = Not defined.
+* 001b = Graphics.
+* 010b = Photo.
+* 011b = Video.
+* 100b = Game
+* All other values are RESERVED.
+* Note: See CTA-861-G for the definition and expected
+* processing by a stream sink for the above contect types.
+*/
+   vsc_sdp.DB[18] = 0;
+
+   intel_dig_port->write_infoframe(&intel_dig_port->base,
+   crtc_state, DP_SDP_VSC, &vsc_sdp, sizeof(vsc_sdp));
+}
+
+void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
+  const struct intel_crtc_state *crtc_state)
+{
+   if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+

[PATCH v7 5/6] drm/i915/dp: Change a link bandwidth computation for DP

Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
Therefore we need to divide pipe_bpp to 2 while DP output uses YCbCr4:2:0
format.
 - RGB format bpp = bpc x 3
 - YCbCr 4:2:0 format bpp = bpc x 1.5

But Link M/N values are calculated and applied based on the Full Clock for
YCbCr 4:2:0. And DP YCbCr 4:2:0 does not need to pixel clock double for
a dotclock caluation. Only for HDMI YCbCr 4:2:0 needs to pixel clock double
for a dot clock calculation.

It only affects dp and edp port which use YCbCr 4:2:0 output format.
And for now, it does not consider a use case of DSC + YCbCr 4:2:0.

v2:
  Addressed review comments from Ville.
  Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
  Because the pipe is running at the full bpp, keep pipe_bpp as RGB
  even though YCbCr 4:2:0 output format is used.
  Add a link bandwidth computation for YCbCr4:2:0 output format.

v3:
  Addressed reivew comments from Ville.
  In order to make codes simple, it adds and uses intel_dp_output_bpp()
  function.

v6:
  Link M/N values are calculated and applied based on the Full Clock for
  YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode as it
  requires only half of the RGB case.
- Link M/N values are calculated and applied based on the Full Clock
- Data M/N values needs to be calculated considering the data is half
  due to subsampling
  Remove a doubling of pixel clock on a dot clock calculator for
  DP YCbCr 4:2:0.
  Rebase and remove a duplicate setting of vsc_sdp.DB17.
  Add a setting of dynamic range bit to  vsc_sdp.DB17.
  Change Content Type bit to "Graphics" from "Not defined".
  Change a dividing of pipe_bpp to muliplying to constant values on a
  switch-case statement.

v7:
  Addressed review comments from Ville.
  Move a setting of dynamic range bit and a setting of bpc which is based
  on pipe_bpp to a "drm/i915/dp: Program VSC Header and DB for Pixel
  Encoding/Colorimetry Format" commit.
  Change Content Type bit to "Not defined" from "Graphics".

Cc: Ville Syrjälä 
Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/intel_ddi.c |  3 ++-
 drivers/gpu/drm/i915/intel_dp.c  | 15 ++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4441c5ba71fb..e22a0898b957 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1457,7 +1457,8 @@ static void ddi_dotclock_get(struct intel_crtc_state 
*pipe_config)
else
dotclock = pipe_config->port_clock;
 
-   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 &&
+   !intel_crtc_has_dp_encoder(pipe_config))
dotclock *= 2;
 
if (pipe_config->pixel_multiplier)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a3fd279a5c52..86dc5e23ea73 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1842,6 +1842,19 @@ intel_dp_adjust_compliance_config(struct intel_dp 
*intel_dp,
}
 }
 
+static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int 
bpp)
+{
+   /*
+* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
+* format of the number of bytes per pixel will be half the number
+* of bytes of RGB pixel.
+*/
+   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   bpp /= 2;
+
+   return bpp;
+}
+
 /* Optimize link config in order: max bpp, min clock, min lanes */
 static int
 intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
@@ -2215,7 +2228,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (pipe_config->dsc_params.compression_enable)
output_bpp = pipe_config->dsc_params.compressed_bpp;
else
-   output_bpp = pipe_config->pipe_bpp;
+   output_bpp = intel_dp_output_bpp(pipe_config, 
pipe_config->pipe_bpp);
 
intel_link_compute_m_n(output_bpp,
   pipe_config->lane_count,
-- 
2.21.0

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

[PATCH v7 2/6] drm: Rename struct edp_vsc_psr to struct dp_sdp

VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
Video_Stream_Configuration Extension VESA SDP might use all of Data Blocks
as Extended INFORFRAME Data Byte. so it makes Data Block variables as
array type. And it adds comments of details of DB of VSC SDP Payload
for Pixel Encoding/Colorimetry Format. This comments follows DP 1.4a spec,
section 2.2.5.7.5, chapter "VSC SDP Payload for Pixel Encoding/Colorimetry
Format".

v7: Addressed review comments from Ville.

Cc: Ville Syrjälä 
Signed-off-by: Gwan-gyeong Mun 
---
 .../drm/bridge/analogix/analogix_dp_core.c| 12 +++
 .../drm/bridge/analogix/analogix_dp_core.h|  2 +-
 .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 +++---
 drivers/gpu/drm/i915/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 33 +--
 5 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 225f5e5dd69b..d1c2659d0cce 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
 
 int analogix_dp_enable_psr(struct analogix_dp_device *dp)
 {
-   struct edp_vsc_psr psr_vsc;
+   struct dp_sdp psr_vsc;
 
if (!dp->psr_enable)
return 0;
@@ -127,8 +127,8 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
 
-   psr_vsc.DB0 = 0;
-   psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
+   psr_vsc.DB[0] = 0;
+   psr_vsc.DB[1] = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
 
return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
 }
@@ -136,7 +136,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
 
 int analogix_dp_disable_psr(struct analogix_dp_device *dp)
 {
-   struct edp_vsc_psr psr_vsc;
+   struct dp_sdp psr_vsc;
int ret;
 
if (!dp->psr_enable)
@@ -149,8 +149,8 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
 
-   psr_vsc.DB0 = 0;
-   psr_vsc.DB1 = 0;
+   psr_vsc.DB[0] = 0;
+   psr_vsc.DB[1] = 0;
 
ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
if (ret != 1) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 769255dc6e99..3e5fe90edf71 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -254,7 +254,7 @@ void analogix_dp_enable_scrambling(struct 
analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
 int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc, bool blocking);
+struct dp_sdp *vsc, bool blocking);
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a5f2763d72e4..f591810ef1be 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1041,7 +1041,7 @@ static ssize_t analogix_dp_get_psr_status(struct 
analogix_dp_device *dp)
 }
 
 int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc, bool blocking)
+struct dp_sdp *vsc, bool blocking)
 {
unsigned int val;
int ret;
@@ -1069,8 +1069,8 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
writel(0x5D, dp->reg_base + ANALOGIX_DP_SPD_PB3);
 
/* configure DB0 / DB1 values */
-   writel(vsc->DB0, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
-   writel(vsc->DB1, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
+   writel(vsc->DB[0], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
+   writel(vsc->DB[1], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
 
/* set reuse spd inforframe */
val = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
@@ -1092,8 +1092,8 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
 
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
-   ((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
-   (!vsc->DB1 && psr_status == DP_PSR_SINK_INACTIVE)), 1500,

[PATCH v7 1/6] drm/i915/dp: Add a config function for YCBCR420 outputs

This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.

v2:
  Addressed review comments from Ville.
  Style fixed with few naming.
  %s/config/crtc_state/
  %s/intel_crtc/crtc/
  If lscon is active, it makes not to call intel_dp_ycbcr420_config()
  to avoid to clobber of lspcon_ycbcr420_config() routine.
  And it move the 420_only check into the intel_dp_ycbcr420_config().

v3: Fix uninitialized return value and it is reported by Dan Carpenter.

v4:
  Addressed review comments from Ville.
  In order to avoid the extra indentation, it inverts if-clause on
  intel_dp_ycbcr420_config().
  Remove the error print where no errors print are allowed.

v6: Rebase

v7:
  Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr.
  intel_dp_get_colorimetry_status() checks
  VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the
  DPRX_FEATURE_ENUMERATION_LIST register.
  And intel_dp_ycbcr420_config() uses intel_dp_get_colorimetry_status().

Cc: Ville Syrjälä 
Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_dp.c  | 48 +++-
 drivers/gpu/drm/i915/intel_dp.h  |  1 +
 drivers/gpu/drm/i915/intel_psr.c | 10 ---
 3 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 53cc4afea256..9f219f8f0c71 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2085,6 +2085,36 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
return 0;
 }
 
+static int
+intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
+struct drm_connector *connector,
+struct intel_crtc_state *crtc_state)
+{
+   const struct drm_display_info *info = &connector->display_info;
+   const struct drm_display_mode *adjusted_mode =
+   &crtc_state->base.adjusted_mode;
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   int ret;
+
+   if (!drm_mode_is_420_only(info, adjusted_mode) ||
+   !intel_dp_get_colorimetry_status(intel_dp) ||
+   !connector->ycbcr_420_allowed)
+   return 0;
+
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
+   /* YCBCR 420 output conversion needs a scaler */
+   ret = skl_update_scaler_crtc(crtc_state);
+   if (ret) {
+   DRM_DEBUG_KMS("Scaler allocation for output failed\n");
+   return ret;
+   }
+
+   intel_pch_panel_fitting(crtc, crtc_state, DRM_MODE_SCALE_FULLSCREEN);
+
+   return 0;
+}
+
 bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
  const struct drm_connector_state *conn_state)
 {
@@ -2124,7 +2154,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
to_intel_digital_connector_state(conn_state);
bool constant_n = drm_dp_has_quirk(&intel_dp->desc,
   DP_DPCD_QUIRK_CONSTANT_N);
-   int ret, output_bpp;
+   int ret = 0, output_bpp;
 
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
pipe_config->has_pch_encoder = true;
@@ -2132,6 +2162,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
if (lspcon->active)
lspcon_ycbcr420_config(&intel_connector->base, pipe_config);
+   else
+   ret = intel_dp_ycbcr420_config(intel_dp, &intel_connector->base,
+  pipe_config);
+
+   if (ret)
+   return ret;
 
pipe_config->has_drrs = false;
if (IS_G4X(dev_priv) || port == PORT_A)
@@ -4051,6 +4087,16 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
return intel_dp->dpcd[DP_DPCD_REV] != 0;
 }
 
+bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
+{
+   u8 dprx = 0;
+
+   if (drm_dp_dpcd_readb(&intel_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
+ &dprx) != 1)
+   return false;
+   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
+}
+
 static void intel_dp_get_dsc_sink_cap(struct intel_dp *intel_dp)
 {
/*
diff --git a/drivers/gpu/drm/i915/intel_dp.h b/drivers/gpu/drm/i915/intel_dp.h
index 5e9e8d13de6e..da70b1a41c83 100644
--- a/drivers/gpu/drm/i915/intel_dp.h
+++ b/drivers/gpu/drm/i915/intel_dp.h
@@ -108,6 +108,7 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, 
int mode_clock,
int mode_hdisplay);
 
 bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
 int int

Re: [PATCH v6 5/6] drm/i915/dp: Change a link bandwidth computation for DP

2019-05-09 Thread Mun, Gwan-gyeong

On Wed, 2019-05-08 at 20:58 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:56AM +0300, Gwan-gyeong Mun wrote:
> > Data M/N calculations were assumed a bpp as RGB format. But when we
> > are
> > using YCbCr 4:2:0 output format on DP, we should change bpp
> > calculations
> > as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
> > therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a
> > multiplier
> > value to 1.5.
> > Therefore we need to divide pipe_bpp to 2 while DP output uses
> > YCbCr4:2:0
> > format.
> >  - RGB format bpp = bpc x 3
> >  - YCbCr 4:2:0 format bpp = bpc x 1.5
> > 
> > But Link M/N values are calculated and applied based on the Full
> > Clock for
> > YCbCr 4:2:0. And DP YCbCr 4:2:0 does not need to pixel clock double
> > for
> > a dotclock caluation. Only for HDMI YCbCr 4:2:0 needs to pixel
> > clock double
> > for a dot clock calculation.
> > 
> > And it adds missed bpc values for a programming of VSC Header.
> > It only affects dp and edp port which use YCbCr 4:2:0 output
> > format.
> > And for now, it does not consider a use case of DSC + YCbCr 4:2:0.
> > 
> > v2:
> >   Addressed review comments from Ville.
> >   Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
> >   Because the pipe is running at the full bpp, keep pipe_bpp as RGB
> >   even though YCbCr 4:2:0 output format is used.
> >   Add a link bandwidth computation for YCbCr4:2:0 output format.
> > 
> > v3:
> >   Addressed reivew comments from Ville.
> >   In order to make codes simple, it adds and uses
> > intel_dp_output_bpp()
> >   function.
> > 
> > v6:
> >   Link M/N values are calculated and applied based on the Full
> > Clock for
> >   YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode
> > as it
> >   requires only half of the RGB case.
> > - Link M/N values are calculated and applied based on the Full
> > Clock
> > - Data M/N values needs to be calculated considering the data
> > is half
> >   due to subsampling
> >   Remove a doubling of pixel clock on a dot clock calculator for
> >   DP YCbCr 4:2:0.
> >   Rebase and remove a duplicate setting of vsc_sdp.DB17.
> >   Add a setting of dynamic range bit to  vsc_sdp.DB17.
> >   Change Content Type bit to "Graphics" from "Not defined".
> >   Change a dividing of pipe_bpp to muliplying to constant values on
> > a
> >   switch-case statement.
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Gwan-gyeong Mun 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |  3 ++-
> >  drivers/gpu/drm/i915/intel_dp.c  | 42
> > +---
> >  2 files changed, 41 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 4441c5ba71fb..e22a0898b957 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1457,7 +1457,8 @@ static void ddi_dotclock_get(struct
> > intel_crtc_state *pipe_config)
> > else
> > dotclock = pipe_config->port_clock;
> >  
> > -   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > +   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420
> > &&
> > +   !intel_crtc_has_dp_encoder(pipe_config))
> > dotclock *= 2;
> >  
> > if (pipe_config->pixel_multiplier)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 74aad8830a80..c75e2bbe612a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1842,6 +1842,19 @@ intel_dp_adjust_compliance_config(struct
> > intel_dp *intel_dp,
> > }
> >  }
> >  
> > +static int intel_dp_output_bpp(const struct intel_crtc_state
> > *crtc_state, int bpp)
> > +{
> > +   /*
> > +* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> > +* format of the number of bytes per pixel will be half the
> > number
> > +* of bytes of RGB pixel.
> > +*/
> > +   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > +   bpp /= 2;
> > +
> > +   return bpp;
> > +}
> > +
> >  /* Optimize link config in order: max bpp, min clock, min lanes */
> >  static int
> >  intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
> > @@ -2212,7 +2225,7 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> > if (pipe_config->dsc_params.compression_enable)
> > output_bpp = pipe_config->dsc_params.compressed_bpp;
> > else
> > -   output_bpp = pipe_config->pipe_bpp;
> > +   output_bpp = intel_dp_output_bpp(pipe_config,
> > pipe_config->pipe_bpp);
> >  
> > intel_link_compute_m_n(output_bpp,
> >pipe_config->lane_count,
> > @@ -4439,7 +4452,30 @@ intel_pixel_encoding_setup_vsc(struct
> > intel_dp *intel_dp,
> >  * 011b = 12bpc.
> >  * 100b = 16bpc.
> >  */
> > -   vsc_sdp.DB17 = 0x1;
> > +   switch (crtc_state->pipe_bpp) {
> > +   case 24: /* 8bpc */
> > +   vsc_sdp.DB17 = 0x1

Re: [PATCH v6 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format

2019-05-09 Thread Mun, Gwan-gyeong

On Wed, 2019-05-08 at 20:56 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:54AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> > 
> > Setup VSC header and data block in function
> > intel_pixel_encoding_setup_vsc
> > for pixel encoding / colorimetry format as per dp 1.4a spec,
> > section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section
> > 2.2.5.7.5,
> > table 2-120:VSC SDP Payload for DB16 through DB18.
> > 
> > v2:
> >   Minor style fix. [Maarten]
> >   Refer to commit ids instead of patchwork. [Maarten]
> > 
> > v6: Rebase
> > 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Gwan-gyeong Mun 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |  1 +
> >  drivers/gpu/drm/i915/intel_dp.c  | 73
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  2 +
> >  3 files changed, 76 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index cd5277d98b03..2f1688ea5a2c 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3391,6 +3391,7 @@ static void intel_enable_ddi_dp(struct
> > intel_encoder *encoder,
> >  
> > intel_edp_backlight_on(crtc_state, conn_state);
> > intel_psr_enable(intel_dp, crtc_state);
> > +   intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
> 
> I wonder if this is a bit too late. But we do it for PSR here, so I
> guess we should think about this for both cases. We should actually
> add full readout + state checker for the VSC SDP for both cases as
> well. But that can be done later.
> 
I'll check it again.
> > intel_edp_drrs_enable(intel_dp, crtc_state);
> >  
> > if (crtc_state->has_audio)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 06a3417a88d1..74aad8830a80 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4394,6 +4394,79 @@ u8 intel_dp_dsc_get_slice_count(struct
> > intel_dp *intel_dp,
> > return 0;
> >  }
> >  
> > +static void
> > +intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
> > +  const struct intel_crtc_state
> > *crtc_state)
> > +{
> > +   struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > +   struct dp_vsc_sdp vsc_sdp;
> > +
> > +   if (!intel_dp->attached_connector->base.ycbcr_420_allowed)
> > +   return;
> > +
> > +   /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> > */
> > +   memset(&vsc_sdp, 0, sizeof(vsc_sdp));
> 
> Can be replaced with '= {}' in the declaration.
> 
Yes, I'll use a structure initializer instead of memset().
> > +   vsc_sdp.sdp_header.HB0 = 0;
> > +   vsc_sdp.sdp_header.HB1 = 0x7;
> > +
> > +   /* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> > +* Colorimetry Format indication. A DP Source device is allowed
> > +* to indicate the pixel encoding/colorimetry format to the DP
> > Sink
> > +* device with VSC SDP only when the DP Sink device supports it
> > +* (i.e., VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in
> > the register
> > +* DPRX_FEATURE_ENUMERATION_LIST (DPCD Address 02210h, bit 3)
> > is set to 1)
> > +*/
> 
> Are we checking that bit somewhere? I suppose the sink might a bit
> nuts
> if it declares 420_only modes without that set, but maybe it should
> be
> checked anyway.
> 
> Also non-standard comment format all over. Should be
> /*
>  * blah
>  */
> 
I'll add a checking of VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit
with intel_dp_get_colorimetry_status() on intel_dp_ycbcr420_config().
And I will fix non-standard comment format.
> > +   vsc_sdp.sdp_header.HB2 = 0x5;
> > +
> > +   /* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
> > +* Colorimetry Format indication (HB2 = 05h).
> > +*/
> > +   vsc_sdp.sdp_header.HB3 = 0x13;
> > +   /* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 =
> > 1h
> > +* DB16[3:0] DP 1.4a spec, Table 2-120
> > +*/
> > +
> > +   /* Commit id (25edf91501b8 "drm/i915: prepare csc unit for
> > YCBCR420 output")
> > +* uses the BT.709 color space to perform RGB->YCBCR
> > conversion.
> > +*/
> 
> I don't think referring to specific commit here is particularly
> helpful.
> The situation will change anyway at some point.
> 
Yes, I'll remove a referring to specific commit.
> > +   vsc_sdp.DB16 = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
> > +   vsc_sdp.DB16 |= 0x1; /* 0x1, ITU-R BT.709 */
> > +
> > +   /* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and
> > Y Only,
> > +* the following Component Bit Depth values are defined:
> > +* 001b = 8bpc.
> > +* 010b = 10bpc.
> > +* 011b = 12bpc.
> > +* 100b = 16bpc.
> > +*/
> > +   vsc_sdp.DB17 = 0x1;
> 
> Don't we need to base this on pipe_bpp? 
> 
> And I'm thinking we want the CEA bit set here as well.
> 
I'll mov

Re: [PATCH v6 2/6] drm: Add a VSC structure for handling Pixel Encoding/Colorimetry Formats

2019-05-09 Thread Mun, Gwan-gyeong

On Wed, 2019-05-08 at 20:32 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:53AM +0300, Gwan-gyeong Mun wrote:
> > SDP VSC Header and Data Block follow DP 1.4a spec, section
> > 2.2.5.7.5,
> > chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
> > 
> > Signed-off-by: Gwan-gyeong Mun 
> > Reviewed-by: Maarten Lankhorst 
> > ---
> >  include/drm/drm_dp_helper.h | 17 +
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index 97ce790a5b5a..3793bea7b7fe 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1096,6 +1096,23 @@ struct edp_vsc_psr {
> > u8 DB8_31[24]; /* Reserved */
> >  } __packed;
> >  
> > +struct dp_vsc_sdp {
> > +   struct dp_sdp_header sdp_header;
> > +   u8 DB0; /* Stereo Interface */
> > +   u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
> > +   u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
> > +   u8 DB3; /* CRC value bits 15:8 of the R or Cr component */
> > +   u8 DB4; /* CRC value bits 7:0 of the G or Y component */
> > +   u8 DB5; /* CRC value bits 15:8 of the G or Y component */
> > +   u8 DB6; /* CRC value bits 7:0 of the B or Cb component */
> > +   u8 DB7; /* CRC value bits 15:8 of the B or Cb component */
> > +   u8 DB8_15[8];  /* Reserved */
> > +   u8 DB16; /* Pixel Encoding and Colorimetry Formats */
> > +   u8 DB17; /* Dynamic Range and Component Bit Depth */
> > +   u8 DB18; /* Content Type */
> > +   u8 DB19_31[13]; /* Reserved */
> > +} __packed;
> 
> Isn't this the same thing we have for edp already? Just rename the
> edp
> struct and add the missing stuff?
> 
Okay, I'll rename struct edp_vsc_psr to general name of dp_sdp and will
add missing stuff.
> > +
> >  #define EDP_VSC_PSR_STATE_ACTIVE   (1<<0)
> >  #define EDP_VSC_PSR_UPDATE_RFB (1<<1)
> >  #define EDP_VSC_PSR_CRC_VALUES_VALID   (1<<2)
> > -- 
> > 2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/msm: Fix improper uses of smp_mb__{before,after}_atomic()

2019-05-09 Thread Andrea Parri

On Mon, Apr 29, 2019 at 10:14:57PM +0200, Andrea Parri wrote:
> These barriers only apply to the read-modify-write operations; in
> particular, they do not apply to the atomic_set() primitive.
> 
> Replace the barriers with smp_mb()s.
> 
> Fixes: b1fc2839d2f92 ("drm/msm: Implement preemption for A5XX targets")
> Cc: sta...@vger.kernel.org
> Reported-by: "Paul E. McKenney" 
> Reported-by: Peter Zijlstra 
> Signed-off-by: Andrea Parri 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Jordan Crouse 
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org

Rob, Sean, Jordan: any suggestions to move this patch forward?

Thanx,
  Andrea


> ---
>  drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> index 3d62310a535fb..ee0820ee0c664 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> @@ -39,10 +39,10 @@ static inline void set_preempt_state(struct a5xx_gpu *gpu,
>* preemption or in the interrupt handler so barriers are needed
>* before...
>*/
> - smp_mb__before_atomic();
> + smp_mb();
>   atomic_set(&gpu->preempt_state, new);
>   /* ... and after*/
> - smp_mb__after_atomic();
> + smp_mb();
>  }
>  
>  /* Write the most recent wptr for the given ring into the hardware */
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panfrost: Only put sync_out if non-NULL

2019-05-09 Thread Steven Price

On 09/05/2019 09:21, Tomeu Vizoso wrote:
> Dan Carpenter's static analysis tool reported:
> 
> drivers/gpu/drm/panfrost/panfrost_drv.c:222 panfrost_ioctl_submit()
> error: we previously assumed 'sync_out' could be null (see line 216)
> 
> Indeed, sync_out could be NULL if userspace doesn't send a sync object
> ID for the out fence.
> 
> Signed-off-by: Tomeu Vizoso 
> Reported-by: Dan Carpenter 
> Link: https://lists.freedesktop.org/archives/dri-devel/2019-May/217014.html

Reviewed-by: Steven Price 

> ---
>  drivers/gpu/drm/panfrost/panfrost_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 94b0819ad50b..d11e2281dde6 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -219,7 +219,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev, 
> void *data,
>  fail_job:
>   panfrost_job_put(job);
>  fail_out_sync:
> - drm_syncobj_put(sync_out);
> + if (sync_out)
> + drm_syncobj_put(sync_out);
>  
>   return ret;
>  }
> 

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

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

2019-05-09 Thread Bjorn Andersson

On Thu 09 May 00:12 PDT 2019, Brian Masney wrote:

> On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote:
> > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> > 
> > > On Wed, May 8, 2019 at 7:16 PM Brian Masney  wrote:
> > > >
> > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> > > > > > b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > > [..]
> > > > > > +   clocks = <&mmcc MDSS_MDP_CLK>,
> > > > > > +<&mmcc MDSS_AHB_CLK>,
> > > > > > +<&mmcc MDSS_AXI_CLK>,
> > > > > > +<&mmcc MDSS_BYTE0_CLK>,
> > > > > > +<&mmcc MDSS_PCLK0_CLK>,
> > > > > > +<&mmcc MDSS_ESC0_CLK>,
> > > > > > +<&mmcc MMSS_MISC_AHB_CLK>;
> > > > > > +   clock-names = "mdp_core",
> > > > > > + "iface",
> > > > > > + "bus",
> > > > > > + "byte",
> > > > > > + "pixel",
> > > > > > + "core",
> > > > > > + "core_mmss";
> > > > >
> > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > > > > underrun error from DSI. You don't see anything like this?
> > > > >
> > > > > (These clocks are controlled by msm_bus downstream and should be 
> > > > > driven
> > > > > by interconnect upstream)
> > > > >
> > > > >
> > > > > Apart from this, I think this looks nice. Happy to see the progress.
> > > >
> > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks
> > > > are fine since I'm able to get this working with 4.17 using these same
> > > > clocks. I just sent out v2 and the cover letter has some details, along
> > > > with the full dmesg.
> > > 
> > > since we don't have interconnect driver for 8974, I guess there is
> > > some chance that things work or not based on how lk leaves things?
> > > 
> > 
> > Right, I guess the bootloader on my device does not leave the busses
> > ticking - perhaps there's a boot splash involved on Brian's device?
> > 
> > Regardless, this works on Nexus 5 and allows Brian to make further
> > progress so I'm all for merging it.
> 
> There is a boot splash on the Nexus 5 and that may explain a behavior
> that I observed. I attempted to add reset GPIO support to the simple
> panel driver and the screen will clear but nothing will come on the
> screen after a hard reset, even on 4.17. To be sure, I got the timing
> information for how long to leave the GPIO high and low from the
> downstream MSM 3.4 sources. That's when I had a script port all of the
> ~400 panel on commands in the downstream device tree to a new panel
> driver.
> 
> With the latest kernel kernel having a delay showing the console text,
> I observe a brief second where the boot splash is shown along with the
> startup text from Linux. A full refresh is performed and the boot
> splash goes away. I don't see this with the 4.17 kernel; perhaps maybe
> the full refresh occurs quick enough that its not noticeable.
> 
> Can you point me to where the interconnect API is in the downstream
> MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead
> It looks like its in drivers/interconnect/ in the upstream sources.
> 

The data will be 8974 specific, but the plumbing should be reusable from
8916 or 404. Hopefully we can get those landed shortly.

You can find the latest incarnation here:
https://lore.kernel.org/lkml/20190415104357.5305-1-georgi.dja...@linaro.org/

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

Re: [PATCH] RFC: console: hack up console_lock more v3

2019-05-09 Thread Petr Mladek

On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then lockdep jumps in and spams the logs,
> potentially obscuring the real backtrace we're really interested in.
> One case I've seen (slightly simplified backtrace):
> 
>  Call Trace:
>   
>   console_trylock+0xe/0x60
>   vprintk_emit+0xf1/0x320
>   printk+0x4d/0x69
>   __warn_printk+0x46/0x90
>   native_smp_send_reschedule+0x2f/0x40
>   check_preempt_curr+0x81/0xa0
>   ttwu_do_wakeup+0x14/0x220
>   try_to_wake_up+0x218/0x5f0
>   pollwake+0x6f/0x90
>   credit_entropy_bits+0x204/0x310
>   add_interrupt_randomness+0x18f/0x210
>   handle_irq+0x67/0x160
>   do_IRQ+0x5e/0x130
>   common_interrupt+0xf/0xf
>   
> 
> This alone isn't a problem, but the spinlock in the semaphore is also
> still held while waking up waiters (up() -> __up() -> try_to_wake_up()
> callchain), which then closes the runqueue vs. semaphore.lock loop,
> and upsets lockdep, which issues a circular locking splat to dmesg.
> Worse it upsets developers, since we don't want to spam dmesg with
> clutter when the machine is dying already.
> 
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
> 
> - console_lock doesn't use interruptible or killable or timeout down()
>   calls, hence an up() is the only thing that can wake up a process.
>   Hence the process can't get woken and killed and reaped while we try
>   to wake it up too.
> 
> - semaphore.c always updates the waiter list while under the spinlock,
>   so there's no other races. Specifically another process that races
>   with a quick console_lock/unlock while we've dropped the spinlock
>   already won't see our own waiter.
> 
> Note that we only have to break the recursion for the semaphore.lock
> spinlock of the console_lock. Recursion within various scheduler
> related locks is already prevented by the printk_safe_enter/exit pair
> in __up_console_sem().

This is not fully true. printk_safe() helps only when
the first try_to_wake_up() is called from printk_safe() context.

> --- a/kernel/locking/semaphore.c
> +++ b/kernel/locking/semaphore.c
> @@ -197,6 +197,37 @@ struct semaphore_waiter {
>   bool up;
>  };
>  
> +/**
> + * printk_safe_up - release the semaphore in console_unlock
> + * @sem: the semaphore to release
> + *
> + * Release the semaphore.  Unlike mutexes, up() may be called from any
> + * context and even by tasks which have never called down().
> + *
> + * NOTE: This is a special version of up() for console_unlock only. It is 
> only
> + * safe if there are no killable, interruptible or timing out down() calls.
> + */
> +void printk_safe_up(struct semaphore *sem)
> +{
> + unsigned long flags;
> + struct semaphore_waiter *waiter = NULL;
> +
> + raw_spin_lock_irqsave(&sem->lock, flags);
> + if (likely(list_empty(&sem->wait_list))) {
> + sem->count++;
> + } else {
> + waiter = list_first_entry(&sem->wait_list,
> +   struct semaphore_waiter, list);
> + list_del(&waiter->list);
> + waiter->up = true;
> + }
> + raw_spin_unlock_irqrestore(&sem->lock, flags);
> +
> + if (waiter) /* protected by being sole wake source */
> + wake_up_process(waiter->task);

I still do not see how this could help. Let's take the above
backtrace as example:

   
   console_trylock+0xe/0x60
   vprintk_emit+0xf1/0x320
   printk+0x4d/0x69
   __warn_printk+0x46/0x90
   native_smp_send_reschedule +0x2f/0x40
   check_preempt_curr+0x81/0xa0
   ttwu_do_wakeup+0x14/0x220
   try_to_wake_up+0x218/0x5f0
   pollwake+0x6f/0x90
   credit_entropy_bits+0x204/0x310
   add_interrupt_randomness+0x18f/0x210
   handle_irq+0x67/0x160
   do_IRQ+0x5e/0x130
   common_interrupt+0xf/0xf
   

We have the following chain of calls:

  + do_IRQ()
...
  + try_to_wake_up()# takes p->pi_lock
+ ttwu_remote() # takes rq lock
  + ttwu_do_wakeup()
+ check_preempt_curr()
  + native_smp_send_reschedule()
+ __warn_printk()
  + printk()
+ vprintk_emit()
  + console_trylock() # success
  + console_unlock()
+ up_console_sem()
  + up() # wait list in not empty
+ __up()
  + wake_up_process()
+ try_to_wake_up()

!BANG! Deadlock on p->pi_lock.

It does not matter if the nested try_to_wake_up() was called
under sem->lock or outside.

By other words. The patch removed one lockdep warning. But it just
just delayed the deadlock. It will not

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
> 
> The second item, arguably, does have significant overlap with kselftest.
> Whether you are running short tests in a light weight UML environment or
> higher level tests in an heavier VM the two could be using the same
> framework for writing or defining in-kernel tests. It *may* also be valuable
> for some people to be able to run all the UML tests in the heavy VM
> environment along side other higher level tests.
> 
> Looking at the selftests tree in the repo, we already have similar items to
> what Kunit is adding as I described in point (2) above. kselftest_harness.h
> contains macros like EXPECT_* and ASSERT_* with very similar intentions to
> the new KUNIT_EXECPT_* and KUNIT_ASSERT_* macros.
> 
> However, the number of users of this harness appears to be quite small. Most
> of the code in the selftests tree seems to be a random mismash of scripts
> and userspace code so it's not hard to see it as something completely
> different from the new Kunit:
> 
> $ git grep --files-with-matches kselftest_harness.h *

To the extent that we can unify how tests are written, I agree that
this would be a good thing.  However, you should note that
kselftest_harness.h is currently assums that it will be included in
userspace programs.  This is most obviously seen if you look closely
at the functions defined in the header files which makes calls to
fork(), abort() and fprintf().

So Kunit can't reuse kselftest_harness.h unmodified.  And whether or
not the actual implementation of the header file can be reused or
refactored, making the unit tests use the same or similar syntax would
be a good thing.

Cheers,

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

[pull] amdgpu, radeon drm-next-5.2

2019-05-09 Thread Alex Deucher

Hi Dave, Daniel,

Fixes for 5.2:
- Fix a crash on gpu reset at driver load time
- ATPX hotplug fix for when the dGPU is powered off
- PLL fix for r5xx asics
- SR-IOV fixes

The following changes since commit 422449238e9853458283beffed77562d4b40a2fa:

  Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2019-05-03 10:31:07 +1000)

are available in the Git repository at:

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

for you to fetch changes up to 9d6fea5744d6798353f37ac42a8a653a2607ca69:

  drm/amdgpu/psp: move psp version specific function pointers to early_init 
(2019-05-09 17:47:04 -0500)


Aaron Liu (1):
  drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-in

Alex Deucher (1):
  drm/amdgpu/psp: move psp version specific function pointers to early_init

Christian König (1):
  drm/radeon: prefer lower reference dividers

Evan Quan (1):
  drm/amd/powerplay: check for invalid profile_exit setting

Nicholas Kazlauskas (1):
  drm/amd/display: Use long for signed error code checks in commit planes

Trigger Huang (4):
  drm/amdgpu: Rearm IRQ in Vega10 SR-IOV if IRQ lost
  drm/amdgpu: Fix VM clean check method
  drm/amdgpu: Add IDH_QUERY_ALIVE event for SR-IOV
  drm/amdgpu: Use FW addr returned by PSP for VF MM

 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 10 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   | 19 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 36 --
 drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c |  3 ++
 drivers/gpu/drm/amd/amdgpu/mxgpu_ai.h |  1 +
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 16 ++
 drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 17 +++
 drivers/gpu/drm/amd/amdgpu/vega10_ih.c| 37 ++-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +-
 drivers/gpu/drm/radeon/radeon_display.c   |  4 +--
 11 files changed, 119 insertions(+), 30 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 11:12:12AM -0700, Frank Rowand wrote:
> 
>"My understanding is that the intent of KUnit is to avoid booting a kernel 
> on
>real hardware or in a virtual machine.  That seems to be a matter of 
> semantics
>to me because isn't invoking a UML Linux just running the Linux kernel in
>a different form of virtualization?
> 
>So I do not understand why KUnit is an improvement over kselftest.
> 
>...
> 
>What am I missing?"

One major difference: kselftest requires a userspace environment; it
starts systemd, requires a root file system from which you can load
modules, etc.  Kunit doesn't require a root file system; doesn't
require that you start systemd; doesn't allow you to run arbitrary
perl, python, bash, etc. scripts.  As such, it's much lighter weight
than kselftest, and will have much less overhead before you can start
running tests.  So it's not really the same kind of virtualization.

Does this help?

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

[RFC PATCH v2 3/5] drm/amdgpu: Register AMD devices for DRM cgroup

Change-Id: I3750fc657b956b52750a36cb303c54fa6a265b44
Signed-off-by: Kenny Ho 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index da7b4fe8ade3..2568fd730161 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -28,6 +28,7 @@
 #include 
 #include "amdgpu.h"
 #include 
+#include 
 #include "amdgpu_sched.h"
 #include "amdgpu_uvd.h"
 #include "amdgpu_vce.h"
@@ -97,6 +98,7 @@ void amdgpu_driver_unload_kms(struct drm_device *dev)
 
amdgpu_device_fini(adev);
 
+   drmcgrp_unregister_device(dev);
 done_free:
kfree(adev);
dev->dev_private = NULL;
@@ -141,6 +143,8 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
struct amdgpu_device *adev;
int r, acpi_status;
 
+   drmcgrp_register_device(dev);
+
 #ifdef CONFIG_DRM_AMDGPU_SI
if (!amdgpu_si_support) {
switch (flags & AMD_ASIC_MASK) {
-- 
2.21.0

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

[RFC PATCH v2 5/5] drm, cgroup: Add peak GEM buffer allocation limit

This new drmcgrp resource limits the largest GEM buffer that can be
allocated in a cgroup.

Change-Id: I0830d56775568e1cf215b56cc892d5e7945e9f25
Signed-off-by: Kenny Ho 
---
 include/linux/cgroup_drm.h |  2 ++
 kernel/cgroup/drm.c| 59 ++
 2 files changed, 61 insertions(+)

diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index fe14ba7bb1cf..57c07a148975 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -16,8 +16,10 @@
 struct drmcgrp_device_resource {
/* for per device stats */
s64 bo_stats_total_allocated;
+   size_t  bo_stats_peak_allocated;
 
s64 bo_limits_total_allocated;
+   size_t  bo_limits_peak_allocated;
 };
 
 struct drmcgrp {
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index bc3abff09113..5c7e1b8059ce 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -17,6 +17,7 @@ struct drmcgrp_device {
struct mutexmutex;
 
s64 bo_limits_total_allocated_default;
+   size_t  bo_limits_peak_allocated_default;
 };
 
 #define DRMCG_CTF_PRIV_SIZE 3
@@ -24,6 +25,7 @@ struct drmcgrp_device {
 
 enum drmcgrp_res_type {
DRMCGRP_TYPE_BO_TOTAL,
+   DRMCGRP_TYPE_BO_PEAK,
 };
 
 enum drmcgrp_file_type {
@@ -72,6 +74,9 @@ static inline int init_drmcgrp_single(struct drmcgrp 
*drmcgrp, int i)
if (known_drmcgrp_devs[i] != NULL) {
ddr->bo_limits_total_allocated =
  known_drmcgrp_devs[i]->bo_limits_total_allocated_default;
+
+   ddr->bo_limits_peak_allocated =
+ known_drmcgrp_devs[i]->bo_limits_peak_allocated_default;
}
 
return 0;
@@ -131,6 +136,9 @@ static inline void drmcgrp_print_stats(struct 
drmcgrp_device_resource *ddr,
case DRMCGRP_TYPE_BO_TOTAL:
seq_printf(sf, "%lld\n", ddr->bo_stats_total_allocated);
break;
+   case DRMCGRP_TYPE_BO_PEAK:
+   seq_printf(sf, "%zu\n", ddr->bo_stats_peak_allocated);
+   break;
default:
seq_puts(sf, "\n");
break;
@@ -149,6 +157,9 @@ static inline void drmcgrp_print_limits(struct 
drmcgrp_device_resource *ddr,
case DRMCGRP_TYPE_BO_TOTAL:
seq_printf(sf, "%lld\n", ddr->bo_limits_total_allocated);
break;
+   case DRMCGRP_TYPE_BO_PEAK:
+   seq_printf(sf, "%zu\n", ddr->bo_limits_peak_allocated);
+   break;
default:
seq_puts(sf, "\n");
break;
@@ -167,6 +178,9 @@ static inline void drmcgrp_print_default(struct 
drmcgrp_device *ddev,
case DRMCGRP_TYPE_BO_TOTAL:
seq_printf(sf, "%lld\n", 
ddev->bo_limits_total_allocated_default);
break;
+   case DRMCGRP_TYPE_BO_PEAK:
+   seq_printf(sf, "%zu\n", ddev->bo_limits_peak_allocated_default);
+   break;
default:
seq_puts(sf, "\n");
break;
@@ -182,6 +196,11 @@ static inline void drmcgrp_print_help(int cardNum, struct 
seq_file *sf,
"Total amount of buffer allocation in bytes for card%d\n",
cardNum);
break;
+   case DRMCGRP_TYPE_BO_PEAK:
+   seq_printf(sf,
+   "Largest buffer allocation in bytes for card%d\n",
+   cardNum);
+   break;
default:
seq_puts(sf, "\n");
break;
@@ -254,6 +273,10 @@ ssize_t drmcgrp_bo_limit_write(struct kernfs_open_file 
*of, char *buf,
 if (val < 0) continue;
ddr->bo_limits_total_allocated = val;
break;
+   case DRMCGRP_TYPE_BO_PEAK:
+if (val < 0) continue;
+   ddr->bo_limits_peak_allocated = val;
+   break;
default:
break;
}
@@ -300,6 +323,33 @@ struct cftype files[] = {
.private = (DRMCGRP_TYPE_BO_TOTAL << DRMCG_CTF_PRIV_SIZE) |
DRMCGRP_FTYPE_MAX,
},
+   {
+   .name = "buffer.peak.stats",
+   .seq_show = drmcgrp_bo_show,
+   .private = (DRMCGRP_TYPE_BO_PEAK << DRMCG_CTF_PRIV_SIZE) |
+   DRMCGRP_FTYPE_STATS,
+   },
+   {
+   .name = "buffer.peak.default",
+   .seq_show = drmcgrp_bo_show,
+   .flags = CFTYPE_ONLY_ON_ROOT,
+   .private = (DRMCGRP_TYPE_BO_PEAK << DRMCG_CTF_PRIV_SIZE) |
+   DRMCGRP_FTYPE_DEFAULT,
+   },
+   {
+   .name = "buffer.peak.help",
+   .seq_show = drmcgrp_bo_show,
+   .flags = CFTY

[RFC PATCH v2 1/5] cgroup: Introduce cgroup for drm subsystem

Change-Id: I6830d3990f63f0c13abeba29b1d330cf28882831
Signed-off-by: Kenny Ho 
---
 include/linux/cgroup_drm.h| 32 ++
 include/linux/cgroup_subsys.h |  4 
 init/Kconfig  |  5 +
 kernel/cgroup/Makefile|  1 +
 kernel/cgroup/drm.c   | 42 +++
 5 files changed, 84 insertions(+)
 create mode 100644 include/linux/cgroup_drm.h
 create mode 100644 kernel/cgroup/drm.c

diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
new file mode 100644
index ..121001be1230
--- /dev/null
+++ b/include/linux/cgroup_drm.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ */
+#ifndef _CGROUP_DRM_H
+#define _CGROUP_DRM_H
+
+#ifdef CONFIG_CGROUP_DRM
+
+#include 
+
+struct drmcgrp {
+   struct cgroup_subsys_state  css;
+};
+
+static inline struct drmcgrp *css_drmcgrp(struct cgroup_subsys_state *css)
+{
+   return css ? container_of(css, struct drmcgrp, css) : NULL;
+}
+
+static inline struct drmcgrp *get_drmcgrp(struct task_struct *task)
+{
+   return css_drmcgrp(task_get_css(task, drm_cgrp_id));
+}
+
+
+static inline struct drmcgrp *parent_drmcgrp(struct drmcgrp *cg)
+{
+   return css_drmcgrp(cg->css.parent);
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+#endif /* _CGROUP_DRM_H */
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index acb77dcff3b4..ddedad809e8b 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -61,6 +61,10 @@ SUBSYS(pids)
 SUBSYS(rdma)
 #endif
 
+#if IS_ENABLED(CONFIG_CGROUP_DRM)
+SUBSYS(drm)
+#endif
+
 /*
  * The following subsystems are not supported on the default hierarchy.
  */
diff --git a/init/Kconfig b/init/Kconfig
index d47cb77a220e..0b0f112eb23b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -839,6 +839,11 @@ config CGROUP_RDMA
  Attaching processes with active RDMA resources to the cgroup
  hierarchy is allowed even if can cross the hierarchy's limit.
 
+config CGROUP_DRM
+   bool "DRM controller (EXPERIMENTAL)"
+   help
+ Provides accounting and enforcement of resources in the DRM subsystem.
+
 config CGROUP_FREEZER
bool "Freezer controller"
help
diff --git a/kernel/cgroup/Makefile b/kernel/cgroup/Makefile
index bfcdae896122..6af14bd93050 100644
--- a/kernel/cgroup/Makefile
+++ b/kernel/cgroup/Makefile
@@ -4,5 +4,6 @@ obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o
 obj-$(CONFIG_CGROUP_FREEZER) += freezer.o
 obj-$(CONFIG_CGROUP_PIDS) += pids.o
 obj-$(CONFIG_CGROUP_RDMA) += rdma.o
+obj-$(CONFIG_CGROUP_DRM) += drm.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_CGROUP_DEBUG) += debug.o
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
new file mode 100644
index ..620c887d6d24
--- /dev/null
+++ b/kernel/cgroup/drm.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: MIT
+// Copyright 2019 Advanced Micro Devices, Inc.
+#include 
+#include 
+#include 
+
+static struct drmcgrp *root_drmcgrp __read_mostly;
+
+static void drmcgrp_css_free(struct cgroup_subsys_state *css)
+{
+   struct drmcgrp *drmcgrp = css_drmcgrp(css);
+
+   kfree(css_drmcgrp(css));
+}
+
+static struct cgroup_subsys_state *
+drmcgrp_css_alloc(struct cgroup_subsys_state *parent_css)
+{
+   struct drmcgrp *parent = css_drmcgrp(parent_css);
+   struct drmcgrp *drmcgrp;
+
+   drmcgrp = kzalloc(sizeof(struct drmcgrp), GFP_KERNEL);
+   if (!drmcgrp)
+   return ERR_PTR(-ENOMEM);
+
+   if (!parent)
+   root_drmcgrp = drmcgrp;
+
+   return &drmcgrp->css;
+}
+
+struct cftype files[] = {
+   { } /* terminate */
+};
+
+struct cgroup_subsys drm_cgrp_subsys = {
+   .css_alloc  = drmcgrp_css_alloc,
+   .css_free   = drmcgrp_css_free,
+   .early_init = false,
+   .legacy_cftypes = files,
+   .dfl_cftypes= files,
+};
-- 
2.21.0

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

[RFC PATCH v2 2/5] cgroup: Add mechanism to register DRM devices

Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho 
---
 include/drm/drm_cgroup.h   |  24 
 include/linux/cgroup_drm.h |  10 
 kernel/cgroup/drm.c| 118 -
 3 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 include/drm/drm_cgroup.h

diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
new file mode 100644
index ..ddb9eab64360
--- /dev/null
+++ b/include/drm/drm_cgroup.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ */
+#ifndef __DRM_CGROUP_H__
+#define __DRM_CGROUP_H__
+
+#ifdef CONFIG_CGROUP_DRM
+
+int drmcgrp_register_device(struct drm_device *device);
+
+int drmcgrp_unregister_device(struct drm_device *device);
+
+#else
+static inline int drmcgrp_register_device(struct drm_device *device)
+{
+   return 0;
+}
+
+static inline int drmcgrp_unregister_device(struct drm_device *device)
+{
+   return 0;
+}
+#endif /* CONFIG_CGROUP_DRM */
+#endif /* __DRM_CGROUP_H__ */
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 121001be1230..d7ccf434ca6b 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -6,10 +6,20 @@
 
 #ifdef CONFIG_CGROUP_DRM
 
+#include 
 #include 
+#include 
+
+/* limit defined per the way drm_minor_alloc operates */
+#define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
+
+struct drmcgrp_device_resource {
+   /* for per device stats */
+};
 
 struct drmcgrp {
struct cgroup_subsys_state  css;
+   struct drmcgrp_device_resource  *dev_resources[MAX_DRM_DEV];
 };
 
 static inline struct drmcgrp *css_drmcgrp(struct cgroup_subsys_state *css)
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 620c887d6d24..f9ef4bf042d8 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -1,16 +1,79 @@
 // SPDX-License-Identifier: MIT
 // Copyright 2019 Advanced Micro Devices, Inc.
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+
+static DEFINE_MUTEX(drmcgrp_mutex);
+
+struct drmcgrp_device {
+   struct drm_device   *dev;
+   struct mutexmutex;
+};
+
+/* indexed by drm_minor for access speed */
+static struct drmcgrp_device   *known_drmcgrp_devs[MAX_DRM_DEV];
+
+static int max_minor;
+
 
 static struct drmcgrp *root_drmcgrp __read_mostly;
 
 static void drmcgrp_css_free(struct cgroup_subsys_state *css)
 {
struct drmcgrp *drmcgrp = css_drmcgrp(css);
+   int i;
+
+   for (i = 0; i <= max_minor; i++) {
+   if (drmcgrp->dev_resources[i] != NULL)
+   kfree(drmcgrp->dev_resources[i]);
+   }
+
+   kfree(drmcgrp);
+}
+
+static inline int init_drmcgrp_single(struct drmcgrp *drmcgrp, int i)
+{
+   struct drmcgrp_device_resource *ddr = drmcgrp->dev_resources[i];
+
+   if (ddr == NULL) {
+   ddr = kzalloc(sizeof(struct drmcgrp_device_resource),
+   GFP_KERNEL);
+
+   if (!ddr)
+   return -ENOMEM;
+
+   drmcgrp->dev_resources[i] = ddr;
+   }
+
+   /* set defaults here */
+
+   return 0;
+}
+
+static inline int init_drmcgrp(struct drmcgrp *drmcgrp, struct drm_device *dev)
+{
+   int rc = 0;
+   int i;
+
+   if (dev != NULL) {
+   rc = init_drmcgrp_single(drmcgrp, dev->primary->index);
+   return rc;
+   }
+
+   for (i = 0; i <= max_minor; i++) {
+   rc = init_drmcgrp_single(drmcgrp, i);
+   if (rc)
+   return rc;
+   }
 
-   kfree(css_drmcgrp(css));
+   return 0;
 }
 
 static struct cgroup_subsys_state *
@@ -18,11 +81,18 @@ drmcgrp_css_alloc(struct cgroup_subsys_state *parent_css)
 {
struct drmcgrp *parent = css_drmcgrp(parent_css);
struct drmcgrp *drmcgrp;
+   int rc;
 
drmcgrp = kzalloc(sizeof(struct drmcgrp), GFP_KERNEL);
if (!drmcgrp)
return ERR_PTR(-ENOMEM);
 
+   rc = init_drmcgrp(drmcgrp, NULL);
+   if (rc) {
+   drmcgrp_css_free(&drmcgrp->css);
+   return ERR_PTR(rc);
+   }
+
if (!parent)
root_drmcgrp = drmcgrp;
 
@@ -40,3 +110,49 @@ struct cgroup_subsys drm_cgrp_subsys = {
.legacy_cftypes = files,
.dfl_cftypes= files,
 };
+
+int drmcgrp_register_device(struct drm_device *dev)
+{
+   struct drmcgrp_device *ddev;
+   struct cgroup_subsys_state *pos;
+   struct drmcgrp *child;
+
+   ddev = kzalloc(sizeof(struct drmcgrp_device), GFP_KERNEL);
+   if (!ddev)
+   return -ENOMEM;
+
+   ddev->dev = dev;
+   mutex_init(&ddev->mutex);
+
+   mutex_lock(&drmcgrp_mutex);
+   known_drmcgrp_devs[dev->primary->index] = ddev;
+   max_minor = max(max_minor, dev->primary->index);
+   mutex_unlock(&drmcgrp_mutex);
+
+   /* init cgroups created before registration (i.e. root c

[RFC PATCH v2 4/5] drm, cgroup: Add total GEM buffer allocation limit

The drm resource being measured and limited here is the GEM buffer
objects.  User applications allocate and free these buffers.  In
addition, a process can allocate a buffer and share it with another
process.  The consumer of a shared buffer can also outlive the
allocator of the buffer.

For the purpose of cgroup accounting and limiting, ownership of the
buffer is deemed to be the cgroup for which the allocating process
belongs to.  There is one limit per drm device.

In order to prevent the buffer outliving the cgroup that owns it, a
process is prevented from importing buffers that are not own by the
process' cgroup or the ancestors of the process' cgroup.

For this resource, the control files are prefixed with drm.buffer.total.

There are four control file types,
stats (ro) - display current measured values for a resource
max (rw) - limits for a resource
default (ro, root cgroup only) - default values for a resource
help (ro, root cgroup only) - help string for a resource

Each file is multi-lined with one entry/line per drm device.

Usage examples:
// set limit for card1 to 1GB
sed -i '2s/.*/1073741824/' /sys/fs/cgroup//drm.buffer.total.max

// set limit for card0 to 512MB
sed -i '1s/.*/536870912/' /sys/fs/cgroup//drm.buffer.total.max

Change-Id: I4c249d06d45ec709d6481d4cbe87c5168545c5d0
Signed-off-by: Kenny Ho 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |   4 +
 drivers/gpu/drm/drm_gem.c  |   7 +
 drivers/gpu/drm/drm_prime.c|   9 +
 include/drm/drm_cgroup.h   |  34 ++-
 include/drm/drm_gem.h  |  11 +
 include/linux/cgroup_drm.h |   3 +
 kernel/cgroup/drm.c| 280 +
 7 files changed, 346 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 93b2c5a48a71..b4c078b7ad63 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 #include "amdgpu_amdkfd.h"
@@ -446,6 +447,9 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
if (!amdgpu_bo_validate_size(adev, size, bp->domain))
return -ENOMEM;
 
+   if (!drmcgrp_bo_can_allocate(current, adev->ddev, size))
+   return -ENOMEM;
+
*bo_ptr = NULL;
 
acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6a80db077dc6..cbd49bf34dcf 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -37,10 +37,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include "drm_internal.h"
 
 /** @file drm_gem.c
@@ -154,6 +156,9 @@ void drm_gem_private_object_init(struct drm_device *dev,
obj->handle_count = 0;
obj->size = size;
drm_vma_node_reset(&obj->vma_node);
+
+   obj->drmcgrp = get_drmcgrp(current);
+   drmcgrp_chg_bo_alloc(obj->drmcgrp, dev, size);
 }
 EXPORT_SYMBOL(drm_gem_private_object_init);
 
@@ -804,6 +809,8 @@ drm_gem_object_release(struct drm_gem_object *obj)
if (obj->filp)
fput(obj->filp);
 
+   drmcgrp_unchg_bo_alloc(obj->drmcgrp, obj->dev, obj->size);
+
drm_gem_free_mmap_offset(obj);
 }
 EXPORT_SYMBOL(drm_gem_object_release);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 231e3f6d5f41..faed5611a1c6 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_internal.h"
 
@@ -794,6 +795,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
 {
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
+   struct drmcgrp *drmcgrp = get_drmcgrp(current);
int ret;
 
dma_buf = dma_buf_get(prime_fd);
@@ -818,6 +820,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto out_unlock;
}
 
+   /* only allow bo from the same cgroup or its ancestor to be imported */
+   if (drmcgrp != NULL &&
+   !drmcgrp_is_self_or_ancestor(drmcgrp, obj->drmcgrp)) {
+   ret = -EACCES;
+   goto out_unlock;
+   }
+
if (obj->dma_buf) {
WARN_ON(obj->dma_buf != dma_buf);
} else {
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index ddb9eab64360..8711b7c5f7bf 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -4,12 +4,20 @@
 #ifndef __DRM_CGROUP_H__
 #define __DRM_CGROUP_H__
 
+#include 
+
 #ifdef CONFIG_CGROUP_DRM
 
 int drmcgrp_register_device(struct drm_device *device);
-
 int drmcgrp_unregister_device(struct drm_device *device);
-
+bool drmcgrp_is_self_or_ancestor(struct drmcgrp *self,
+   struct drmcgrp *relative);
+void drmcgr

[RFC PATCH v2 0/5] new cgroup controller for gpu/drm subsystem

This is a follow up to the RFC I made last november to introduce a cgroup
controller for the GPU/DRM subsystem [a]. The goal is to be able to provide
resource management to GPU resources using things like container. The cover
letter from v1 is copied below for reference.

Usage examples:
// set limit for card1 to 1GB
sed -i '2s/.*/1073741824/' /sys/fs/cgroup//drm.buffer.total.max

// set limit for card0 to 512MB
sed -i '1s/.*/536870912/' /sys/fs/cgroup//drm.buffer.total.max

v2:
* Removed the vendoring concepts
* Add limit to total buffer allocation
* Add limit to the maximum size of a buffer allocation

TODO: process migration
TODO: documentations

[a]: https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html

v1: cover letter

The purpose of this patch series is to start a discussion for a generic cgroup
controller for the drm subsystem. The design proposed here is a very early one.
We are hoping to engage the community as we develop the idea.

Backgrounds
==
Control Groups/cgroup provide a mechanism for aggregating/partitioning sets of
tasks, and all their future children, into hierarchical groups with specialized
behaviour, such as accounting/limiting the resources which processes in a cgroup
can access[1]. Weights, limits, protections, allocations are the main resource
distribution models. Existing cgroup controllers includes cpu, memory, io,
rdma, and more. cgroup is one of the foundational technologies that enables the
popular container application deployment and management method.

Direct Rendering Manager/drm contains code intended to support the needs of
complex graphics devices. Graphics drivers in the kernel may make use of DRM
functions to make tasks like memory management, interrupt handling and DMA
easier, and provide a uniform interface to applications. The DRM has also
developed beyond traditional graphics applications to support compute/GPGPU
applications.

Motivations
=
As GPU grow beyond the realm of desktop/workstation graphics into areas like
data center clusters and IoT, there are increasing needs to monitor and regulate
GPU as a resource like cpu, memory and io.

Matt Roper from Intel began working on similar idea in early 2018 [2] for the
purpose of managing GPU priority using the cgroup hierarchy. While that
particular use case may not warrant a standalone drm cgroup controller, there
are other use cases where having one can be useful [3]. Monitoring GPU
resources such as VRAM and buffers, CU (compute unit [AMD's nomenclature])/EU
(execution unit [Intel's nomenclature]), GPU job scheduling [4] can help
sysadmins get a better understanding of the applications usage profile. Further
usage regulations of the aforementioned resources can also help sysadmins
optimize workload deployment on limited GPU resources.

With the increased importance of machine learning, data science and other
cloud-based applications, GPUs are already in production use in data centers
today [5,6,7]. Existing GPU resource management is very course grain, however,
as sysadmins are only able to distribute workload on a per-GPU basis [8]. An
alternative is to use GPU virtualization (with or without SRIOV) but it
generally acts on the entire GPU instead of the specific resources in a GPU.
With a drm cgroup controller, we can enable alternate, fine-grain, sub-GPU
resource management (in addition to what may be available via GPU
virtualization.)

In addition to production use, the DRM cgroup can also help with testing
graphics application robustness by providing a mean to artificially limit DRM
resources availble to the applications.

Challenges

While there are common infrastructure in DRM that is shared across many vendors
(the scheduler [4] for example), there are also aspects of DRM that are vendor
specific. To accommodate this, we borrowed the mechanism used by the cgroup to
handle different kinds of cgroup controller.

Resources for DRM are also often device (GPU) specific instead of system
specific and a system may contain more than one GPU. For this, we borrowed some
of the ideas from RDMA cgroup controller.

Approach
===
To experiment with the idea of a DRM cgroup, we would like to start with basic
accounting and statistics, then continue to iterate and add regulating
mechanisms into the driver.

[1] https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
[2] https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
[3] https://www.spinics.net/lists/cgroups/msg20720.html
[4] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/scheduler
[5] https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/
[6]
https://blog.openshift.com/gpu-accelerated-sql-queries-with-postgresql-pg-strom-in-openshift-3-10/
[7] https://github.com/RadeonOpenCompute/k8s-device-plugin
[8] https://github.com/kubernetes/kubernetes/issues/52757

Kenny Ho (5):
cgroup: Introduce cgroup for drm subsystem
cgroup: Add mechanism to regist

[PATCH] kernel/locking/semaphore: use wake_q in up()

console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):

 Call Trace:
  
  console_trylock+0xe/0x60
  vprintk_emit+0xf1/0x320
  printk+0x4d/0x69
  __warn_printk+0x46/0x90
  native_smp_send_reschedule+0x2f/0x40
  check_preempt_curr+0x81/0xa0
  ttwu_do_wakeup+0x14/0x220
  try_to_wake_up+0x218/0x5f0
  pollwake+0x6f/0x90
  credit_entropy_bits+0x204/0x310
  add_interrupt_randomness+0x18f/0x210
  handle_irq+0x67/0x160
  do_IRQ+0x5e/0x130
  common_interrupt+0xf/0xf
  

This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.

Fix this specific locking recursion by moving the wake_up_process out
from under the semaphore.lock spinlock, using wake_q as recommended by
Peter Zijlstra.

As Petr Mladek points out this doesn't fix all the locking recursions
in this area. If we actually recursive in the above callchain:

  + try_to_wake_up()# takes p->pi_lock
+ ttwu_remote() # takes rq lock
  + ttwu_do_wakeup()
+ check_preempt_curr()
  + native_smp_send_reschedule()
+ __warn_printk()
  + printk()
+ vprintk_emit()
  + console_trylock() # success
  + console_unlock()
+ up_console_sem()
  + up() # wait list in not empty
+ __up()
  + wake_up_process()
+ try_to_wake_up()

Then there's any number of scheduler related locks will deadlock.
Given that the kernel is dying already (the printk() in
native_smp_send_reschedule() happens because we run on an offlined
CPU) I think there's limited value in trying to fix this:

- We haven't seen the actual deadlock in our CI, only lockdep
  complaining about the possibility.

- The real issue is that the lockdep splat hides useful dmesg
  information we capture in e.g. pstore or on screen about the real
  cause of why the kernel is dying.

- The console_unlock in the above callchain should have managed to get
  all the dmesg up to that point out already. Dying later on is
  somewhat ok - I've only seen this lockdep splat in pstore when the
  machine died anyway.

Also cc'ing John Ogness since perhaps his printk rework fixes this all
properly.

v2: Ditch attempt to fix console_trylock.

v3: Add a comment explaining why the taks we're waking won't
disappear (Chris), and improve commit message to address review
questions.

v4: Use wake_q (Peter Z).

Signed-off-by: Daniel Vetter 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Will Deacon 
Cc: Petr Mladek 
Cc: Sergey Senozhatsky 
Cc: Steven Rostedt 
Cc: Daniel Vetter 
Cc: John Ogness 
Cc: Chris Wilson 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 kernel/locking/semaphore.c | 42 +++---
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..7a6f33715688 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -33,12 +33,12 @@
 #include 
 #include 
 #include 
+#include 
 
 static noinline void __down(struct semaphore *sem);
 static noinline int __down_interruptible(struct semaphore *sem);
 static noinline int __down_killable(struct semaphore *sem);
 static noinline int __down_timeout(struct semaphore *sem, long timeout);
-static noinline void __up(struct semaphore *sem);
 
 /**
  * down - acquire the semaphore
@@ -169,6 +169,14 @@ int down_timeout(struct semaphore *sem, long timeout)
 }
 EXPORT_SYMBOL(down_timeout);
 
+/* Functions for the contended case */
+
+struct semaphore_waiter {
+   struct list_head list;
+   struct task_struct *task;
+   bool up;
+};
+
 /**
  * up - release the semaphore
  * @sem: the semaphore to release
@@ -179,24 +187,25 @@ EXPORT_SYMBOL(down_timeout);
 void up(struct semaphore *sem)
 {
unsigned long flags;
+   struct semaphore_waiter *waiter;
+   DEFINE_WAKE_Q(wake_q);
 
raw_spin_lock_irqsave(&sem->lock, flags);
-   if (likely(list_empty(&sem->wait_list)))
+   if (likely(list_empty(&sem->wait_list))) {
sem->count++;
-   else
-   __up(sem);
+   } else {
+   waiter =  list_first_entry(&sem->wait_list,
+  str

[Bug 110457] System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] ERROR ring gfx timeout on Acer Aspire A315-21G

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

--- Comment #7 from Cameron Banfield  ---
I am having very similar issues and see similar errors in logs. The most recent
error was:

kernel: amdgpu :06:00.0: [gfxhub] no-retry page fault (src_id:0 ring:24
vmid:1 pasid:32768, for process Xorg pid 1301 thread Xorg:cs0 pid 1362)
kernel: amdgpu :06:00.0:   in page starting at address 0x800108a18000
from 27
kernel: amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031

The laptop is then unusable and requires a hard reboot.

Linux Mint 19.1
Kernel 5.1.0
AMD Ryzen PRO 2700U with Vega 10 graphics

Trying to load cities skylines is a guaranteed crash.

-- 
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 5.0 55/95] drm/mediatek: fix possible object reference leak

[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]

The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.
drivers/gpu/drm/mediatek/mtk_hdmi.c:1524:1-7: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.

Signed-off-by: Wen Yang 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: CK Hu 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index c910850d20770..a687fe3e1d6c5 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1514,6 +1514,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
of_node_put(remote);
 
hdmi->ddc_adpt = of_find_i2c_adapter_by_node(i2c_np);
+   of_node_put(i2c_np);
if (!hdmi->ddc_adpt) {
dev_err(dev, "Failed to get ddc i2c adapter by node\n");
return -EINVAL;
-- 
2.20.1



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

[PATCH 4.19 43/66] drm/mediatek: fix possible object reference leak

[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]

The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.
drivers/gpu/drm/mediatek/mtk_hdmi.c:1524:1-7: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.

Signed-off-by: Wen Yang 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: CK Hu 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index c7a77d6f612b2..62444a3a5742a 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1508,6 +1508,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
of_node_put(remote);
 
hdmi->ddc_adpt = of_find_i2c_adapter_by_node(i2c_np);
+   of_node_put(i2c_np);
if (!hdmi->ddc_adpt) {
dev_err(dev, "Failed to get ddc i2c adapter by node\n");
return -EINVAL;
-- 
2.20.1



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

[PATCH 4.14 25/42] drm/mediatek: fix possible object reference leak

[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]

The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.
drivers/gpu/drm/mediatek/mtk_hdmi.c:1524:1-7: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.

Signed-off-by: Wen Yang 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: CK Hu 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index a33a1918463de..3c69c73fbd473 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1508,6 +1508,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
of_node_put(remote);
 
hdmi->ddc_adpt = of_find_i2c_adapter_by_node(i2c_np);
+   of_node_put(i2c_np);
if (!hdmi->ddc_adpt) {
dev_err(dev, "Failed to get ddc i2c adapter by node\n");
return -EINVAL;
-- 
2.20.1



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

[PATCH 4.9 14/28] drm/mediatek: fix possible object reference leak

[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]

The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.
drivers/gpu/drm/mediatek/mtk_hdmi.c:1524:1-7: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 1509, but without a 
corresponding object release within this function.

Signed-off-by: Wen Yang 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: CK Hu 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 200f75e1d6198..e7a6651ceeab1 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1528,6 +1528,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
of_node_put(remote);
 
hdmi->ddc_adpt = of_find_i2c_adapter_by_node(i2c_np);
+   of_node_put(i2c_np);
if (!hdmi->ddc_adpt) {
dev_err(dev, "Failed to get ddc i2c adapter by node\n");
return -EINVAL;
-- 
2.20.1



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

Re: [PATCH v8 4/4] drm/vc4: Allocate binner bo when starting to use the V3D

2019-05-09 Thread Eric Anholt

Paul Kocialkowski  writes:

> The binner BO is not required until the V3D is in use, so avoid
> allocating it at probe and do it on the first non-dumb BO allocation.
>
> Keep track of which clients are using the V3D and liberate the buffer
> when there is none left, using a kref. Protect the logic with a
> mutex to avoid race conditions.
>
> The binner BO is created at the time of the first render ioctl and is
> destroyed when there is no client and no exec job using it left.
>
> The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid
> enabling it before having allocated a binner bo.
>
> We also want to keep the BO alive during runtime suspend/resume to avoid
> failing to allocate it at resume. This happens when the CMA pool is
> full at that point and results in a hard crash.
>
> Signed-off-by: Paul Kocialkowski 

> @@ -313,6 +321,49 @@ static int bin_bo_alloc(struct vc4_dev *vc4)
>   return ret;
>  }
>  
> +int vc4_v3d_bin_bo_get(struct vc4_dev *vc4, bool *used)
> +{
> + int ret = 0;
> +
> + mutex_lock(&vc4->bin_bo_lock);
> +
> + if (used && *used)
> + goto complete;



> +
> + if (used)
> + *used = true;
> +
> + if (vc4->bin_bo) {
> + kref_get(&vc4->bin_bo_kref);
> + goto complete;
> + }
> +
> + ret = bin_bo_alloc(vc4);

I think this block wants to be:

if (vc4->bin_bo)
kref_get(&vc4->bin_bo_kref);
else
ret = bin_bo_alloc(vc4);

if (ret == 0 && used)
*used = true;

(so we don't flag used if bin_bo_alloc fails)

If you agree, then the series is:

Reviewed-by: Eric Anholt 

> +
> +complete:
> + mutex_unlock(&vc4->bin_bo_lock);
> +
> + return ret;
> +}



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

Re: [PATCH] drm: Fix drm.h uapi header for GNU/kFreeBSD

2019-05-09 Thread Eric Anholt

James Clarke  writes:

> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
> types, which differs from the BSDs' headers. Thus we should include
> stdint.h to ensure we have all the required integer types.
>
> Signed-off-by: James Clarke 

Reviewed-by: Eric Anholt 


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

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 9, 2019 at 7:00 PM  wrote:
> > -Original Message-
> > From: Theodore Ts'o
> >
> > On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote:
> > > 1) Tests that exercises typically algorithmic or intricate, complex
> > >code with relatively few outside dependencies, or where the
> > dependencies
> > >are considered worth mocking, such as the basics of container data
> > >structures or page table code. If I get you right, Ted, the tests
> > >you refer to in this thread are such tests. I believe covering this 
> > > space
> > >is the goal Brendan has in mind for KUnit.
> >
> > Yes, that's correct.  I'd also add that one of the key differences is
> > that it sounds like Frank and you are coming from the perspective of
> > testing *device drivers* where in general there aren't a lot of
> > complex code which is hardware independent.
>
> Ummm.  Not to speak for Frank, but he's representing the device tree
> layer, which I'd argue sits exactly at the intersection of testing device 
> drivers
> AND lots of complex code which is hardware independent.  So maybe his
> case is special.

Jumping in with a pure device driver hat: We already have add-hoc unit
tests in drivers/gpu, which somewhat shoddily integrate into
kselftests and our own gpu test suite from userspace. We'd like to do
a lot more in this area (there's enormous amounts of code in a gpu
driver that's worth testing on its own, or against a mocked model of a
part of the real hw), and I think a unit test framework for the entire
kernel would be great. Plus gpu/drm isn't the only subsystem by far
that already has a home-grown solution. So it's actually worse than
what Ted said: We don't just have a multitude of test frameworks
already, we have a multitude of ad-hoc unit test frameworks, each with
their own way to run tests, write tests and mock parts of the system.
Kunit hopefully helps us to standardize more in this area. I do plan
to look into converting all the drm selftest we have already as soon
as this lands (and as soon as I find some time ...).

Cheers, Daniel

>
> > After all, the vast
> > majority of device drivers are primarily interface code to hardware,
> > with as much as possible abstracted away to common code.  (Take, for
> > example, the model of the SCSI layer; or all of the kobject code.)
> >
> > > 2) Tests that exercises interaction between a module under test and other
> > >parts of the kernel, such as testing intricacies of the interaction of
> > >a driver or file system with the rest of the kernel, and with hardware,
> > >whether that is real hardware or a model/emulation.
> > >Using your testing needs as example again, Ted, from my shallow
> > understanding,
> > >you have such needs within the context of xfstests
> > (https://github.com/tytso/xfstests)
> >
> > Well, upstream is for xfstests is 
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-
> > dev.git
> >
> > The test framework where I can run 20 hours worth of xfstests
> > (multiple file system features enabled, multiple mount options, etc.)
> > in 3 hours of wall clock time using multiple cloud VM is something
> > called gce-xfstests.
> >
> > I also have kvm-xfstests, which optimizes low test latency, where I
> > want to run a one or a small number of tests with a minimum of
> > overhead --- gce startup and shutdown is around 2 minutes, where as
> > kvm startup and shutdown is about 7 seconds.  As far as I'm concerned,
> > 7 seconds is still too slow, but that's the best I've been able to do
> > given all of the other things I want a test framework to do, including
> > archiving test results, parsing the test results so it's easy to
> > interpret, etc.  Both kvm-xfstests and gce-xfstests are located at:
> >
> >   git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > So if Frank's primary argument is "too many frameworks", it's already
> > too late.  The block layer has blktests has a seprate framework,
> > called blktests --- and yeah, it's a bit painful to launch or learn
> > how to set things up.
> >
> > That's why I added support to run blktests using gce-xfstests and
> > kvm-xfstests, so that "gce-xfstests --blktests" or "kvm-xfstests
> > --xfstests" will pluck a kernel from your build tree, and launch at
> > test appliance VM using that kernel and run the block layer tests.
> >
> > The point is we *already* have multiple test frameworks, which are
> > optimized for testing different parts of the kernel.  And if you plan
> > to do a lot of work in these parts of the kernel, you're going to have
> > to learn how to use some other test framework other than kselftest.
> > Sorry, that's just the way it goes.
> >
> > Of course, I'll accept trivial patches that haven't been tested using
> > xfstests --- but that's because I can trivially run the smoke test for
> > you.  Of course, if I get a lot of patches from a contributor which
> > cause test regressions, I'll treat them much like someone who
> > contribut

Re: [PATCH v2 14/17] Documentation: kunit: add documentation for KUnit

2019-05-09 Thread Brendan Higgins

> Hi,
>
> On 5/1/19 4:01 PM, Brendan Higgins wrote:
> > Add documentation for KUnit, the Linux kernel unit testing framework.
> > - Add intro and usage guide for KUnit
> > - Add API reference
> >
> > Signed-off-by: Felix Guo 
> > Signed-off-by: Brendan Higgins 
> > ---
> >  Documentation/index.rst   |   1 +
> >  Documentation/kunit/api/index.rst |  16 ++
> >  Documentation/kunit/api/test.rst  |  15 +
> >  Documentation/kunit/faq.rst   |  46 +++
> >  Documentation/kunit/index.rst |  80 ++
> >  Documentation/kunit/start.rst | 180 
> >  Documentation/kunit/usage.rst | 447 ++
> >  7 files changed, 785 insertions(+)
> >  create mode 100644 Documentation/kunit/api/index.rst
> >  create mode 100644 Documentation/kunit/api/test.rst
> >  create mode 100644 Documentation/kunit/faq.rst
> >  create mode 100644 Documentation/kunit/index.rst
> >  create mode 100644 Documentation/kunit/start.rst
> >  create mode 100644 Documentation/kunit/usage.rst
> >
>
> > diff --git a/Documentation/kunit/api/index.rst 
> > b/Documentation/kunit/api/index.rst
> > new file mode 100644
> > index 0..c31c530088153
> > --- /dev/null
> > +++ b/Documentation/kunit/api/index.rst
> > @@ -0,0 +1,16 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +=
> > +API Reference
> > +=
> > +.. toctree::
> > +
> > + test
> > +
> > +This section documents the KUnit kernel testing API. It is divided into 3
> > +sections:
> > +
> > += 
> > ==
> > +:doc:`test`   documents all of the standard testing API
> > +  excluding mocking or mocking related 
> > features.
> > += 
> > ==
>
> What 3 sections does the above refer to?  seems to be missing.

Whoops, that references documentation added in a later patch (not
included in this patchset). Thanks for pointing this out, will fix in
next revision.

> > diff --git a/Documentation/kunit/start.rst b/Documentation/kunit/start.rst
> > new file mode 100644
> > index 0..5cdba5091905e
> > --- /dev/null
> > +++ b/Documentation/kunit/start.rst
> > @@ -0,0 +1,180 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +===
> > +Getting Started
> > +===
> > +
> > +Installing dependencies
> > +===
> > +KUnit has the same dependencies as the Linux kernel. As long as you can 
> > build
> > +the kernel, you can run KUnit.
> > +
> > +KUnit Wrapper
> > +=
> > +Included with KUnit is a simple Python wrapper that helps format the 
> > output to
> > +easily use and read KUnit output. It handles building and running the 
> > kernel, as
> > +well as formatting the output.
> > +
> > +The wrapper can be run with:
> > +
> > +.. code-block:: bash
> > +
> > +   ./tools/testing/kunit/kunit.py
> > +
> > +Creating a kunitconfig
> > +==
> > +The Python script is a thin wrapper around Kbuild as such, it needs to be
>
>around Kbuild. As such,
>
> > +configured with a ``kunitconfig`` file. This file essentially contains the
> > +regular Kernel config, with the specific test targets as well.
> > +
> > +.. code-block:: bash
> > +
> > + git clone -b master https://kunit.googlesource.com/kunitconfig 
> > $PATH_TO_KUNITCONFIG_REPO
> > + cd $PATH_TO_LINUX_REPO
> > + ln -s $PATH_TO_KUNIT_CONFIG_REPO/kunitconfig kunitconfig
> > +
> > +You may want to add kunitconfig to your local gitignore.
> > +
> > +Verifying KUnit Works
> > +-
>
> I would expect Sphinx to complain about the underline length not being the
> same as the header/title above it.

Hmmm...I am pretty sure it wasn't complaining to me, but that might
just be because I didn't build with the right verbosity options or
something.

My experience mostly comes from Markdown which doesn't care about this.

In any case, after some random spot checks it looks like everyone else
uniformly keeps the line under sections to be the same length. So it
looks like I need to fix this regardless.

Will fix in the next revision. Thanks for pointing this out!

> > +
> > +To make sure that everything is set up correctly, simply invoke the Python
> > +wrapper from your kernel repo:
> > +
> > +.. code-block:: bash
> > +
> > + ./tools/testing/kunit/kunit.py
> > +
> > +.. note::
> > +   You may want to run ``make mrproper`` first.
> > +
> > +If everything worked correctly, you should see the following:
> > +
> > +.. code-block:: bash
> > +
> > + Generating .config ...
> > + Building KUnit Kernel ...
> > + Starting KUnit Kernel ...
> > +
> > +followed by a list of tests that are run. All of them should be passing.
> > +
> > +.. note::
> > +   Because it is building a lot of sources for the first time, the 
> > ``Building
> > +   kunit kerne

Re: [RFC PATCH 0/5] cgroup support for GPU devices

2019-05-09 Thread Tejun Heo

Hello,

On Tue, May 07, 2019 at 12:50:50PM -0700, Welty, Brian wrote:
> There might still be merit in having a 'device mem' cgroup controller.
> The resource model at least is then no longer mixed up with host memory.
> RDMA community seemed to have some interest in a common controller at
> least for device memory aspects.
> Thoughts on this?   I believe could still reuse the 'struct mem_cgroup' data
> structure.  There should be some opportunity to reuse charging APIs and
> have some nice integration with HMM for charging to device memory, depending
> on backing store.

Library-ish sharing is fine but in terms of interface, I think it'd be
better to keep them separate at least for now.  Down the line maybe
these resources will interact with each other in a more integrated way
but I don't think it's a good idea to try to design and implement
resource models for something like that preemptively.

Thanks.

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

Re: [PATCH] RFC: console: hack up console_lock more v3

On Thu, May 9, 2019 at 4:56 PM Petr Mladek  wrote:
>
> On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> > console_trylock, called from within printk, can be called from pretty
> > much anywhere. Including try_to_wake_up. Note that this isn't common,
> > usually the box is in pretty bad shape at that point already. But it
> > really doesn't help when then lockdep jumps in and spams the logs,
> > potentially obscuring the real backtrace we're really interested in.
> > One case I've seen (slightly simplified backtrace):
> >
> >  Call Trace:
> >   
> >   console_trylock+0xe/0x60
> >   vprintk_emit+0xf1/0x320
> >   printk+0x4d/0x69
> >   __warn_printk+0x46/0x90
> >   native_smp_send_reschedule+0x2f/0x40
> >   check_preempt_curr+0x81/0xa0
> >   ttwu_do_wakeup+0x14/0x220
> >   try_to_wake_up+0x218/0x5f0
> >   pollwake+0x6f/0x90
> >   credit_entropy_bits+0x204/0x310
> >   add_interrupt_randomness+0x18f/0x210
> >   handle_irq+0x67/0x160
> >   do_IRQ+0x5e/0x130
> >   common_interrupt+0xf/0xf
> >   
> >
> > This alone isn't a problem, but the spinlock in the semaphore is also
> > still held while waking up waiters (up() -> __up() -> try_to_wake_up()
> > callchain), which then closes the runqueue vs. semaphore.lock loop,
> > and upsets lockdep, which issues a circular locking splat to dmesg.
> > Worse it upsets developers, since we don't want to spam dmesg with
> > clutter when the machine is dying already.
> >
> > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > outside of the spinlock. This isn't correct in full generality, but
> > good enough for console_lock:
> >
> > - console_lock doesn't use interruptible or killable or timeout down()
> >   calls, hence an up() is the only thing that can wake up a process.
> >   Hence the process can't get woken and killed and reaped while we try
> >   to wake it up too.
> >
> > - semaphore.c always updates the waiter list while under the spinlock,
> >   so there's no other races. Specifically another process that races
> >   with a quick console_lock/unlock while we've dropped the spinlock
> >   already won't see our own waiter.
> >
> > Note that we only have to break the recursion for the semaphore.lock
> > spinlock of the console_lock. Recursion within various scheduler
> > related locks is already prevented by the printk_safe_enter/exit pair
> > in __up_console_sem().
>
> This is not fully true. printk_safe() helps only when
> the first try_to_wake_up() is called from printk_safe() context.
>
> > --- a/kernel/locking/semaphore.c
> > +++ b/kernel/locking/semaphore.c
> > @@ -197,6 +197,37 @@ struct semaphore_waiter {
> >   bool up;
> >  };
> >
> > +/**
> > + * printk_safe_up - release the semaphore in console_unlock
> > + * @sem: the semaphore to release
> > + *
> > + * Release the semaphore.  Unlike mutexes, up() may be called from any
> > + * context and even by tasks which have never called down().
> > + *
> > + * NOTE: This is a special version of up() for console_unlock only. It is 
> > only
> > + * safe if there are no killable, interruptible or timing out down() calls.
> > + */
> > +void printk_safe_up(struct semaphore *sem)
> > +{
> > + unsigned long flags;
> > + struct semaphore_waiter *waiter = NULL;
> > +
> > + raw_spin_lock_irqsave(&sem->lock, flags);
> > + if (likely(list_empty(&sem->wait_list))) {
> > + sem->count++;
> > + } else {
> > + waiter = list_first_entry(&sem->wait_list,
> > +   struct semaphore_waiter, list);
> > + list_del(&waiter->list);
> > + waiter->up = true;
> > + }
> > + raw_spin_unlock_irqrestore(&sem->lock, flags);
> > +
> > + if (waiter) /* protected by being sole wake source */
> > + wake_up_process(waiter->task);
>
> I still do not see how this could help. Let's take the above
> backtrace as example:
>
>
>console_trylock+0xe/0x60
>vprintk_emit+0xf1/0x320
>printk+0x4d/0x69
>__warn_printk+0x46/0x90
>native_smp_send_reschedule +0x2f/0x40
>check_preempt_curr+0x81/0xa0
>ttwu_do_wakeup+0x14/0x220
>try_to_wake_up+0x218/0x5f0
>pollwake+0x6f/0x90
>credit_entropy_bits+0x204/0x310
>add_interrupt_randomness+0x18f/0x210
>handle_irq+0x67/0x160
>do_IRQ+0x5e/0x130
>common_interrupt+0xf/0xf
>
>
> We have the following chain of calls:
>
>   + do_IRQ()
> ...
>   + try_to_wake_up()# takes p->pi_lock
> + ttwu_remote() # takes rq lock
>   + ttwu_do_wakeup()
> + check_preempt_curr()
>   + native_smp_send_reschedule()
> + __warn_printk()
>   + printk()
> + vprintk_emit()
>   + console_trylock() # success
>   + console_unlock()
> + up_console_sem()
>   + up() # wait list in not empty
> + __up()
>   + w

[Bug 110637] Any OpenCL application causes "ERROR ring gfx timeout" on Vega 64

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

--- Comment #6 from Jan Vesely  ---
Can you post the output of 'clinfo'?
GPU hangs in clover are usually signs of old LLVM, or old mesa (that does not
catch function calls).

Do you use ocl-icd?
if yes can you confirm if the games hang when running with
OCL_ICD_VENDORS=/var/empty/ ?
(alternatively, you can just move libMesaOpenCL.* out of library path)



(In reply to Alex Deucher from comment #3)
> More likely a bug in the mesa OpenCL code.  If you want functional OpenCL,
> you should use the ROCm OpenCL packages.

I doubt that. clover uses the same LLVM code generation paths.
also note: "the same problem with multiple games", I doubt those use OpenCL.
the above steps should confirm that.
My guess is that compute shaders are busted (irrespective of the API).
GPU reset has never worked correctly on any AMD GPU that I've ever used.

-- 
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: [Freedreno] [PATCH 2/3] drm/msm/dpu: Avoid a null de-ref while recovering from kms init fail

2019-05-09 Thread Kristian Høgsberg

On Tue, May 7, 2019 at 12:18 PM Jordan Crouse  wrote:
>
> In the failure path for dpu_kms_init() it is possible to get to the MMU
> destroy function with uninitialized MMU structs. Check for NULl and skip

s/NULl/NULL

> if needed.
>
> Signed-off-by: Jordan Crouse 

Reviewed-by: Kristian H. Kristensen 

> ---
>
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 885bf88..1beaf29 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -56,7 +56,7 @@ static const char * const iommu_ports[] = {
>  #define DPU_DEBUGFS_HWMASKNAME "hw_log_mask"
>
>  static int dpu_kms_hw_init(struct msm_kms *kms);
> -static int _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
> +static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
>
>  static unsigned long dpu_iomap_size(struct platform_device *pdev,
> const char *name)
> @@ -725,17 +725,20 @@ static const struct msm_kms_funcs kms_funcs = {
>  #endif
>  };
>
> -static int _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
> +static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
>  {
> struct msm_mmu *mmu;
>
> +   if (!dpu_kms->base.aspace)
> +   return;
> +
> mmu = dpu_kms->base.aspace->mmu;
>
> mmu->funcs->detach(mmu, (const char **)iommu_ports,
> ARRAY_SIZE(iommu_ports));
> msm_gem_address_space_put(dpu_kms->base.aspace);
>
> -   return 0;
> +   dpu_kms->base.aspace = NULL;
>  }
>
>  static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
> --
> 2.7.4
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Applied "spi: Add spi_is_bpw_supported()" to the spi tree

2019-05-09 Thread Noralf Trønnes

Hi Mark,

Den 15.04.2019 10.53, skrev Mark Brown:
> The patch
> 
>spi: Add spi_is_bpw_supported()
> 
> has been applied to the spi tree at
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.2
> 

I can't see this in for-5.2 or linux-next. You also gave me a topic
branch for this, but I wasn't able to get an r-b on the drm patch in the
few days left before the -rc5 cutoff in the drm subsystem. This means
that the patch didn't go in through drm for 5.2.

How do we proceed from here?

Noralf.

> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
> From e6f3f7e4dc76eb8d8a546dc66621a02c5c84f4ac Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= 
> Date: Fri, 12 Apr 2019 11:41:30 +0200
> Subject: [PATCH] spi: Add spi_is_bpw_supported()
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> This let SPI clients check if the controller supports a particular word
> width. drivers/gpu/drm/tinydrm/mipi-dbi.c will use this to determine if
> the controller supports 16-bit for RGB565 pixels. If it doesn't it will
> swap the bytes before transfer on little endian machines.
> 
> Signed-off-by: Noralf TrÃ¸nnes 
> Signed-off-by: Mark Brown 
> ---
>  include/linux/spi/spi.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index 662b336aa2e4..b30e3d13a5ac 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -983,6 +983,26 @@ spi_max_transfer_size(struct spi_device *spi)
>   return min(tr_max, msg_max);
>  }
>  
> +/**
> + * spi_is_bpw_supported - Check if bits per word is supported
> + * @spi: SPI device
> + * @bpw: Bits per word
> + *
> + * This function checks to see if the SPI controller supports @bpw.
> + *
> + * Returns:
> + * True if @bpw is supported, false otherwise.
> + */
> +static inline bool spi_is_bpw_supported(struct spi_device *spi, u32 bpw)
> +{
> + u32 bpw_mask = spi->master->bits_per_word_mask;
> +
> + if (bpw == 8 || (bpw <= 32 && bpw_mask & SPI_BPW_MASK(bpw)))
> + return true;
> +
> + return false;
> +}
> +
>  
> /*---*/
>  
>  /* SPI transfer replacement methods which make use of spi_res */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH v1 2/3] drm/msm: Print all 64 bits of the faulting IOMMU address

2019-05-09 Thread Kristian Høgsberg

On Tue, May 7, 2019 at 11:02 AM Jordan Crouse  wrote:
>
> When we move to 64 bit addressing for a5xx and a6xx targets we will start
> seeing pagefaults at larger addresses so format them appropriately in the
> log message for easier debugging.

Yes please, this has confused me more than once.

Reviewed-by: Kristian H. Kristensen 

> Signed-off-by: Jordan Crouse 
> ---
>
>  drivers/gpu/drm/msm/msm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 12bb54c..1926329 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -30,7 +30,7 @@ static int msm_fault_handler(struct iommu_domain *domain, 
> struct device *dev,
> struct msm_iommu *iommu = arg;
> if (iommu->base.handler)
> return iommu->base.handler(iommu->base.arg, iova, flags);
> -   pr_warn_ratelimited("*** fault: iova=%08lx, flags=%d\n", iova, flags);
> +   pr_warn_ratelimited("*** fault: iova=%16lx, flags=%d\n", iova, flags);
> return 0;
>  }
>
> --
> 2.7.4
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v1] drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

2019-05-09 Thread liviu.du...@arm.com

On Wed, May 08, 2019 at 10:58:18AM +, Wen He wrote:
> This patch trying to fix monitor freeze issue caused by drm error
> 'flip_done timed out' on LS1028A platform. this set try is make a loop
> around the second setting CVAL and try like 5 times before giveing up.
> 
> Signed-off-by: Liviu 
> Signed-off-by: Wen He 

Acked-by: Liviu Dudau 

I will pull this into my mali-dp tree and send it as fixes after v5.2-rc1.

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 21725c9b9f5e..18cb7f134f4e 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -192,6 +192,7 @@ static void malidp_atomic_commit_hw_done(struct 
> drm_atomic_state *state)
>  {
>   struct drm_device *drm = state->dev;
>   struct malidp_drm *malidp = drm->dev_private;
> + int loop = 5;
>  
>   malidp->event = malidp->crtc.state->event;
>   malidp->crtc.state->event = NULL;
> @@ -206,8 +207,18 @@ static void malidp_atomic_commit_hw_done(struct 
> drm_atomic_state *state)
>   drm_crtc_vblank_get(&malidp->crtc);
>  
>   /* only set config_valid if the CRTC is enabled */
> - if (malidp_set_and_wait_config_valid(drm) < 0)
> + if (malidp_set_and_wait_config_valid(drm) < 0) {
> + /*
> +  * make a loop around the second CVAL setting and
> +  * try 5 times before giving up.
> +  */
> + while (loop--) {
> + if (!malidp_set_and_wait_config_valid(drm))
> + break;
> + }
>   DRM_DEBUG_DRIVER("timed out waiting for updated 
> configuration\n");
> + }
> +
>   } else if (malidp->event) {
>   /* CRTC inactive means vblank IRQ is disabled, send event 
> directly */
>   spin_lock_irq(&drm->event_lock);
> -- 
> 2.17.1
> 

-- 

| 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 1/2] drm/ttm: fix busy memory to fail other user v7

2019-05-09 Thread Christian König


Oh, I know where this is coming from.

The problem is that we remove the BOs from the LRU during CS and so we 
can't wait for the CS to finish up.


Already working on this problem for Marek's similar issue,
Christian.

Am 09.05.19 um 16:46 schrieb Zhou, David(ChunMing):
I know that before, it will issue warning only when debug option is 
enabled. Removing that is ok to me.
I only help Prike draft your idea, and Prike is trying this patch on 
his side. The latest feedback he gave me is first_bo is always null, 
code doesn't run into busy path, which is very confusing me, and he 
said  he is debugging  that.


-David


 Original Message 
Subject: Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v7
From: "Koenig, Christian"
To: "Zhou, David(ChunMing)" ,"Liang, Prike" 
,dri-devel@lists.freedesktop.org

CC:

I've foudn one more problem with this.

With lockdep enabled I get a warning because ttm_eu_reserve_buffers()
has called ww_acquire_done() on the ticket (which essentially means we
are done, no more locking with that ticket).

The simplest solution is probably to just remove the call to
ww_acquire_done() from ttm_eu_reserve_buffers().

Christian.

Am 07.05.19 um 13:45 schrieb Chunming Zhou:
> heavy gpu job could occupy memory long time, which lead other user 
fail to get memory.

>
> basically pick up Christian idea:
>
> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
> 2. If we then run into this EBUSY condition in TTM check if the BO 
we need memory for (or rather the ww_mutex of its reservation object) 
has a ticket assigned.
> 3. If we have a ticket we grab a reference to the first BO on the 
LRU, drop the LRU lock and try to grab the reservation lock with the 
ticket.
> 4. If getting the reservation lock with the ticket succeeded we 
check if the BO is still the first one on the LRU in question (the BO 
could have moved).
> 5. If the BO is still the first one on the LRU in question we try to 
evict it as we would evict any other BO.

> 6. If any of the "If's" above fail we just back off and return -EBUSY.
>
> v2: fix some minor check
> v3: address Christian v2 comments.
> v4: fix some missing
> v5: handle first_bo unlock and bo_get/put
> v6: abstract unified iterate function, and handle all possible 
usecase not only pinned bo.

> v7: pass request bo->resv to ttm_bo_evict_first
>
> Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 111 +--
>   1 file changed, 94 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8502b3ed2d88..f5e6328e4a57 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>    * b. Otherwise, trylock it.
>    */
>   static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,

> - struct ttm_operation_ctx *ctx, bool *locked)
> + struct ttm_operation_ctx *ctx, bool *locked, 
bool *busy)

>   {
>    bool ret = false;
>
>    *locked = false;
> + if (busy)
> + *busy = false;
>    if (bo->resv == ctx->resv) {
> reservation_object_assert_held(bo->resv);
>    if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
> @@ -779,35 +781,46 @@ static bool 
ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,

>    } else {
>    *locked = reservation_object_trylock(bo->resv);
>    ret = *locked;
> + if (!ret && busy)
> + *busy = true;
>    }
>
>    return ret;
>   }
>
> -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> -    uint32_t mem_type,
> -    const struct ttm_place *place,
> -    struct ttm_operation_ctx *ctx)
> +static struct ttm_buffer_object*
> +ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
> +  struct ttm_mem_type_manager *man,
> +  const struct ttm_place *place,
> +  struct ttm_operation_ctx *ctx,
> +  struct ttm_buffer_object **first_bo,
> +  bool *locked)
>   {
> - struct ttm_bo_global *glob = bdev->glob;
> - struct ttm_mem_type_manager *man = &bdev->man[mem_type];
>    struct ttm_buffer_object *bo = NULL;
> - bool locked = false;
> - unsigned i;
> - int ret;
> + int i;
>
> - spin_lock(&glob->lru_lock);
> + if (first_bo)
> + *first_bo = NULL;
>    for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>    list_for_each_entry(bo, &man->lru[i], lru) {
> - if (!ttm_bo_evict_swapout_allowable(bo, ctx, 
&locked))

> + bool busy = false;
> +
> + if (!ttm_bo_evict_swapout_allowable(bo, ctx, 
locked,

> + &busy)) {
> +

Re: [PATCH] drm/amd/display: Make some functions static

2019-05-09 Thread Alex Deucher

On Wed, May 8, 2019 at 10:47 AM Wang Hai  wrote:
>
> Fix the following sparse warnings:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce120/dce120_resource.c:483:21: 
> warning: symbol 'dce120_clock_source_create' was not declared. Should it be 
> static?
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce120/dce120_resource.c:506:6: 
> warning: symbol 'dce120_clock_source_destroy' was not declared. Should it be 
> static?
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce120/dce120_resource.c:513:6: 
> warning: symbol 'dce120_hw_sequencer_create' was not declared. Should it be 
> static?
>
> Fixes: b8fdfcc6a92c ("drm/amd/display: Add DCE12 core support")
> Reported-by: Hulk Robot 
> Signed-off-by: Wang Hai 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> index 312a0aebf91f..0948421219ef 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> @@ -458,7 +458,7 @@ static const struct dc_debug_options debug_defaults = {
> .disable_clock_gate = true,
>  };
>
> -struct clock_source *dce120_clock_source_create(
> +static struct clock_source *dce120_clock_source_create(
> struct dc_context *ctx,
> struct dc_bios *bios,
> enum clock_source_id id,
> @@ -481,14 +481,14 @@ struct clock_source *dce120_clock_source_create(
> return NULL;
>  }
>
> -void dce120_clock_source_destroy(struct clock_source **clk_src)
> +static void dce120_clock_source_destroy(struct clock_source **clk_src)
>  {
> kfree(TO_DCE110_CLK_SRC(*clk_src));
> *clk_src = NULL;
>  }
>
>
> -bool dce120_hw_sequencer_create(struct dc *dc)
> +static bool dce120_hw_sequencer_create(struct dc *dc)
>  {
> /* All registers used by dce11.2 match those in dce11 in offset and
>  * structure
> --
> 2.17.1
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re:[PATCH 1/2] drm/ttm: fix busy memory to fail other user v7

2019-05-09 Thread Zhou, David(ChunMing)

I know that before, it will issue warning only when debug option is enabled. 
Removing that is ok to me.
I only help Prike draft your idea, and Prike is trying this patch on his side. 
The latest feedback he gave me is first_bo is always null, code doesn't run 
into busy path, which is very confusing me, and he said  he is debugging  that.

-David


 Original Message 
Subject: Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v7
From: "Koenig, Christian"
To: "Zhou, David(ChunMing)" ,"Liang, Prike" ,dri-devel@lists.freedesktop.org
CC:

I've foudn one more problem with this.

With lockdep enabled I get a warning because ttm_eu_reserve_buffers()
has called ww_acquire_done() on the ticket (which essentially means we
are done, no more locking with that ticket).

The simplest solution is probably to just remove the call to
ww_acquire_done() from ttm_eu_reserve_buffers().

Christian.

Am 07.05.19 um 13:45 schrieb Chunming Zhou:
> heavy gpu job could occupy memory long time, which lead other user fail to 
> get memory.
>
> basically pick up Christian idea:
>
> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
> 2. If we then run into this EBUSY condition in TTM check if the BO we need 
> memory for (or rather the ww_mutex of its reservation object) has a ticket 
> assigned.
> 3. If we have a ticket we grab a reference to the first BO on the LRU, drop 
> the LRU lock and try to grab the reservation lock with the ticket.
> 4. If getting the reservation lock with the ticket succeeded we check if the 
> BO is still the first one on the LRU in question (the BO could have moved).
> 5. If the BO is still the first one on the LRU in question we try to evict it 
> as we would evict any other BO.
> 6. If any of the "If's" above fail we just back off and return -EBUSY.
>
> v2: fix some minor check
> v3: address Christian v2 comments.
> v4: fix some missing
> v5: handle first_bo unlock and bo_get/put
> v6: abstract unified iterate function, and handle all possible usecase not 
> only pinned bo.
> v7: pass request bo->resv to ttm_bo_evict_first
>
> Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 111 +--
>   1 file changed, 94 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8502b3ed2d88..f5e6328e4a57 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>* b. Otherwise, trylock it.
>*/
>   static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
> - struct ttm_operation_ctx *ctx, bool *locked)
> + struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
>   {
>bool ret = false;
>
>*locked = false;
> + if (busy)
> + *busy = false;
>if (bo->resv == ctx->resv) {
>reservation_object_assert_held(bo->resv);
>if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
> @@ -779,35 +781,46 @@ static bool ttm_bo_evict_swapout_allowable(struct 
> ttm_buffer_object *bo,
>} else {
>*locked = reservation_object_trylock(bo->resv);
>ret = *locked;
> + if (!ret && busy)
> + *busy = true;
>}
>
>return ret;
>   }
>
> -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> -uint32_t mem_type,
> -const struct ttm_place *place,
> -struct ttm_operation_ctx *ctx)
> +static struct ttm_buffer_object*
> +ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
> +  struct ttm_mem_type_manager *man,
> +  const struct ttm_place *place,
> +  struct ttm_operation_ctx *ctx,
> +  struct ttm_buffer_object **first_bo,
> +  bool *locked)
>   {
> - struct ttm_bo_global *glob = bdev->glob;
> - struct ttm_mem_type_manager *man = &bdev->man[mem_type];
>struct ttm_buffer_object *bo = NULL;
> - bool locked = false;
> - unsigned i;
> - int ret;
> + int i;
>
> - spin_lock(&glob->lru_lock);
> + if (first_bo)
> + *first_bo = NULL;
>for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>list_for_each_entry(bo, &man->lru[i], lru) {
> - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked))
> + bool busy = false;
> +
> + if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
> + &busy)) {
> + if (first_bo && !(*first_bo) && busy) {
> + ttm_bo_get(bo);
> + *first_bo = bo;
> + }
>

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

2019-05-09 Thread Rob Clark

On Thu, May 9, 2019 at 12:12 AM Brian Masney  wrote:
>
> On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote:
> > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> >
> > > On Wed, May 8, 2019 at 7:16 PM Brian Masney  wrote:
> > > >
> > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> > > > > > b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > > [..]
> > > > > > +   clocks = <&mmcc MDSS_MDP_CLK>,
> > > > > > +<&mmcc MDSS_AHB_CLK>,
> > > > > > +<&mmcc MDSS_AXI_CLK>,
> > > > > > +<&mmcc MDSS_BYTE0_CLK>,
> > > > > > +<&mmcc MDSS_PCLK0_CLK>,
> > > > > > +<&mmcc MDSS_ESC0_CLK>,
> > > > > > +<&mmcc MMSS_MISC_AHB_CLK>;
> > > > > > +   clock-names = "mdp_core",
> > > > > > + "iface",
> > > > > > + "bus",
> > > > > > + "byte",
> > > > > > + "pixel",
> > > > > > + "core",
> > > > > > + "core_mmss";
> > > > >
> > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > > > > underrun error from DSI. You don't see anything like this?
> > > > >
> > > > > (These clocks are controlled by msm_bus downstream and should be 
> > > > > driven
> > > > > by interconnect upstream)
> > > > >
> > > > >
> > > > > Apart from this, I think this looks nice. Happy to see the progress.
> > > >
> > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks
> > > > are fine since I'm able to get this working with 4.17 using these same
> > > > clocks. I just sent out v2 and the cover letter has some details, along
> > > > with the full dmesg.
> > >
> > > since we don't have interconnect driver for 8974, I guess there is
> > > some chance that things work or not based on how lk leaves things?
> > >
> >
> > Right, I guess the bootloader on my device does not leave the busses
> > ticking - perhaps there's a boot splash involved on Brian's device?
> >
> > Regardless, this works on Nexus 5 and allows Brian to make further
> > progress so I'm all for merging it.
>
> There is a boot splash on the Nexus 5 and that may explain a behavior
> that I observed. I attempted to add reset GPIO support to the simple
> panel driver and the screen will clear but nothing will come on the
> screen after a hard reset, even on 4.17. To be sure, I got the timing
> information for how long to leave the GPIO high and low from the
> downstream MSM 3.4 sources. That's when I had a script port all of the
> ~400 panel on commands in the downstream device tree to a new panel
> driver.
>
> With the latest kernel kernel having a delay showing the console text,
> I observe a brief second where the boot splash is shown along with the
> startup text from Linux. A full refresh is performed and the boot
> splash goes away. I don't see this with the 4.17 kernel; perhaps maybe
> the full refresh occurs quick enough that its not noticeable.
>
> Can you point me to where the interconnect API is in the downstream
> MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead
> It looks like its in drivers/interconnect/ in the upstream sources.
>

Looks like this is the thing:

https://github.com/AICP/kernel_lge_hammerhead/tree/n7.1/arch/arm/mach-msm/msm_bus

(ahh, mach-msm... blast from the past..)

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

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v7

2019-05-09 Thread Koenig, Christian

I've foudn one more problem with this.

With lockdep enabled I get a warning because ttm_eu_reserve_buffers() 
has called ww_acquire_done() on the ticket (which essentially means we 
are done, no more locking with that ticket).

The simplest solution is probably to just remove the call to 
ww_acquire_done() from ttm_eu_reserve_buffers().

Christian.

Am 07.05.19 um 13:45 schrieb Chunming Zhou:
> heavy gpu job could occupy memory long time, which lead other user fail to 
> get memory.
>
> basically pick up Christian idea:
>
> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
> 2. If we then run into this EBUSY condition in TTM check if the BO we need 
> memory for (or rather the ww_mutex of its reservation object) has a ticket 
> assigned.
> 3. If we have a ticket we grab a reference to the first BO on the LRU, drop 
> the LRU lock and try to grab the reservation lock with the ticket.
> 4. If getting the reservation lock with the ticket succeeded we check if the 
> BO is still the first one on the LRU in question (the BO could have moved).
> 5. If the BO is still the first one on the LRU in question we try to evict it 
> as we would evict any other BO.
> 6. If any of the "If's" above fail we just back off and return -EBUSY.
>
> v2: fix some minor check
> v3: address Christian v2 comments.
> v4: fix some missing
> v5: handle first_bo unlock and bo_get/put
> v6: abstract unified iterate function, and handle all possible usecase not 
> only pinned bo.
> v7: pass request bo->resv to ttm_bo_evict_first
>
> Change-Id: I21423fb922f885465f13833c41df1e134364a8e7
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 111 +--
>   1 file changed, 94 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8502b3ed2d88..f5e6328e4a57 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -766,11 +766,13 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>* b. Otherwise, trylock it.
>*/
>   static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
> - struct ttm_operation_ctx *ctx, bool *locked)
> + struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
>   {
>   bool ret = false;
>   
>   *locked = false;
> + if (busy)
> + *busy = false;
>   if (bo->resv == ctx->resv) {
>   reservation_object_assert_held(bo->resv);
>   if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
> @@ -779,35 +781,46 @@ static bool ttm_bo_evict_swapout_allowable(struct 
> ttm_buffer_object *bo,
>   } else {
>   *locked = reservation_object_trylock(bo->resv);
>   ret = *locked;
> + if (!ret && busy)
> + *busy = true;
>   }
>   
>   return ret;
>   }
>   
> -static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> -uint32_t mem_type,
> -const struct ttm_place *place,
> -struct ttm_operation_ctx *ctx)
> +static struct ttm_buffer_object*
> +ttm_mem_find_evitable_bo(struct ttm_bo_device *bdev,
> +  struct ttm_mem_type_manager *man,
> +  const struct ttm_place *place,
> +  struct ttm_operation_ctx *ctx,
> +  struct ttm_buffer_object **first_bo,
> +  bool *locked)
>   {
> - struct ttm_bo_global *glob = bdev->glob;
> - struct ttm_mem_type_manager *man = &bdev->man[mem_type];
>   struct ttm_buffer_object *bo = NULL;
> - bool locked = false;
> - unsigned i;
> - int ret;
> + int i;
>   
> - spin_lock(&glob->lru_lock);
> + if (first_bo)
> + *first_bo = NULL;
>   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>   list_for_each_entry(bo, &man->lru[i], lru) {
> - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked))
> + bool busy = false;
> +
> + if (!ttm_bo_evict_swapout_allowable(bo, ctx, locked,
> + &busy)) {
> + if (first_bo && !(*first_bo) && busy) {
> + ttm_bo_get(bo);
> + *first_bo = bo;
> + }
>   continue;
> + }
>   
>   if (place && !bdev->driver->eviction_valuable(bo,
> place)) {
> - if (locked)
> + if (*locked)
>   reservation_object_unlock(bo->resv);
>   continue;
>   }
> +
>   break;
>   }
>   
> @@ -818,9 +831,67 @@ static int ttm_mem_evict_first(

[Bug 108898] (Recoverable) GPU hangs with GfxBench Manhattan GL tests

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

--- Comment #4 from Eero Tamminen  ---
Any updates on this (VegaM) bug?  These recoverable hangs are still happening
with git versions of kernel, Mesa and linux-firmware. Unlike with the hard hang
bug 108900, this test-case is freely available.

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

Re: [PATCH] RFC: console: hack up console_lock more v3

2019-05-09 Thread Peter Zijlstra

On Thu, May 09, 2019 at 03:06:09PM +0200, Daniel Vetter wrote:
> On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra  wrote:
> > On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > > outside of the spinlock. This isn't correct in full generality, but
> > > good enough for console_lock:
> > >
> > > - console_lock doesn't use interruptible or killable or timeout down()
> > >   calls, hence an up() is the only thing that can wake up a process.
> >
> > Wrong :/ Any task can be woken at any random time. We must, at all
> > times, assume spurious wakeups will happen.
> 
> Out of curiosity, where do these come from? I know about the races
> where you need to recheck on the waiter side to avoid getting stuck,
> but didn't know about this. Are these earlier (possibly spurious)
> wakeups that got held up and delayed for a while, then hit the task
> much later when it's already continued doing something else?

Yes, this. So they all more or less have the form:

CPU0CPU1

enqueue_waiter()
done = true;
if (waiters)
for (;;) {
  if (done)
break;

  ...
}

dequeue_waiter()

do something else again

  wake_up_task



The wake_q thing made the above much more common, but we've had it
forever.

> Or even
> more random, and even if I never put a task on a wait list or anything
> else, ever, it can get woken spuriously?

I had patches that did that on purpose, but no.

> > Something like the below might work.
> 
> Yeah that looks like the proper fix. I guess semaphores are uncritical
> enough that we can roll this out for everyone. Thanks for the hint.

It's actually an optimization that we never did because semaphores are
so uncritical :-)

The thing is, by delaying the wakup until after we've released the
spinlock, the waiter will not contend on the spinlock the moment it
wakes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote:
> 1) Tests that exercises typically algorithmic or intricate, complex
>code with relatively few outside dependencies, or where the dependencies 
>are considered worth mocking, such as the basics of container data 
>structures or page table code. If I get you right, Ted, the tests 
>you refer to in this thread are such tests. I believe covering this space 
>is the goal Brendan has in mind for KUnit.

Yes, that's correct.  I'd also add that one of the key differences is
that it sounds like Frank and you are coming from the perspective of
testing *device drivers* where in general there aren't a lot of
complex code which is hardware independent.  After all, the vast
majority of device drivers are primarily interface code to hardware,
with as much as possible abstracted away to common code.  (Take, for
example, the model of the SCSI layer; or all of the kobject code.)

> 2) Tests that exercises interaction between a module under test and other 
>parts of the kernel, such as testing intricacies of the interaction of 
>a driver or file system with the rest of the kernel, and with hardware, 
>whether that is real hardware or a model/emulation. 
>Using your testing needs as example again, Ted, from my shallow 
> understanding,
>you have such needs within the context of xfstests 
> (https://github.com/tytso/xfstests)

Well, upstream is for xfstests is 
git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git

The test framework where I can run 20 hours worth of xfstests
(multiple file system features enabled, multiple mount options, etc.)
in 3 hours of wall clock time using multiple cloud VM is something
called gce-xfstests.

I also have kvm-xfstests, which optimizes low test latency, where I
want to run a one or a small number of tests with a minimum of
overhead --- gce startup and shutdown is around 2 minutes, where as
kvm startup and shutdown is about 7 seconds.  As far as I'm concerned,
7 seconds is still too slow, but that's the best I've been able to do
given all of the other things I want a test framework to do, including
archiving test results, parsing the test results so it's easy to
interpret, etc.  Both kvm-xfstests and gce-xfstests are located at:

git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git

So if Frank's primary argument is "too many frameworks", it's already
too late.  The block layer has blktests has a seprate framework,
called blktests --- and yeah, it's a bit painful to launch or learn
how to set things up.

That's why I added support to run blktests using gce-xfstests and
kvm-xfstests, so that "gce-xfstests --blktests" or "kvm-xfstests
--xfstests" will pluck a kernel from your build tree, and launch at
test appliance VM using that kernel and run the block layer tests.

The point is we *already* have multiple test frameworks, which are
optimized for testing different parts of the kernel.  And if you plan
to do a lot of work in these parts of the kernel, you're going to have
to learn how to use some other test framework other than kselftest.
Sorry, that's just the way it goes.

Of course, I'll accept trivial patches that haven't been tested using
xfstests --- but that's because I can trivially run the smoke test for
you.  Of course, if I get a lot of patches from a contributor which
cause test regressions, I'll treat them much like someone who
contribute patches which fail to build.  I'll apply pressure to the
contributor to actually build test, or run a ten minute kvm-xfstests
smoke test.  Part of the reason why I feel comfortable to do this is
it's really easy to run the smoke test.  There are pre-compiled test
appliances, and a lot of documentation:

https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md

This is why I have close to zero sympathy to Frank's complaint that
extra test frameworks are a bad thing.  To me, that's whining.  I've
done a huge amount of work to meet contributors more than half-way.
The insistence that "There Must Be One", ala the Highlander movie, is
IMHO so wrong that it's not even close.  Is it really that hard to do
a "git pull", download a test appliance, set up a config file to tell
kvm-xfstests where to find your build tree, and then run "kvm-xfstests
--smoke" or "gce-xfstests --smoke"?  Cry me a river.

There are already multiple test frameworks, and if you expect to do a
lot of work in a particular subsystem, you'll be expected to use the
Maintainer's choice of tests.  Deal with it.  We do this so we can
scale to the number of contributors we have in our subsystem.

> To 1) I agree with Frank in that the problem with using UML is that you still 
> have to
> relate to the complexity of a kernel run time system, while what you really 
> want for these
> types of tests is just to compile a couple of kernel source files in a normal 
> user land
> context, to allow the use of Valgrind and other user space tools on the code.

"Just

[drm-intel:drm-intel-next-queued 4/6] drivers/gpu/drm/drm_hdcp.c:27:3: sparse: sparse: symbol 'srm_data' was not declared. Should it be static?

2019-05-09 Thread kbuild test robot

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   c16fd9be70faf3c49a61700efd16018dd910e390
commit: 6498bf5800a302ef69e7f4914e727893f278bb2f [4/6] drm: revocation check at 
drm subsystem
reproduce:
# apt-get install sparse
git checkout 6498bf5800a302ef69e7f4914e727893f278bb2f
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/drm_hdcp.c:27:3: sparse: sparse: symbol 'srm_data' was not 
>> declared. Should it be static?
>> drivers/gpu/drm/drm_hdcp.c:235:6: sparse: sparse: symbol 
>> 'drm_hdcp_request_srm' was not declared. Should it be static?

Please review and possibly fold the followup patch.

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

[RFC PATCH drm-intel] drm: drm_hdcp_request_srm() can be static

2019-05-09 Thread kbuild test robot


Fixes: 6498bf5800a3 ("drm: revocation check at drm subsystem")
Signed-off-by: kbuild test robot 
---
 drm_hdcp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 5e54095..dc0beb3 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -232,7 +232,7 @@ static void drm_hdcp_srm_update(const u8 *buf, size_t count)
drm_hdcp_parse_hdcp2_srm(buf, count);
 }
 
-void drm_hdcp_request_srm(struct drm_device *drm_dev)
+static void drm_hdcp_request_srm(struct drm_device *drm_dev)
 {
char fw_name[36] = "display_hdcp_srm.bin";
const struct firmware *fw;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110381] Failed to updateMST allocation table forpipe idx:0

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

--- Comment #5 from Nicholas Kazlauskas  ---
(In reply to Paul Menzel from comment #4)
> (In reply to Nicholas Kazlauskas from comment #3)
> > We're able to reproduce the problem.
> > 
> > I believe that we found the issue was caused by the new common helper DRM
> > for DP MST hotplug. A fix is in the works for this issue.
> 
> Great news! Thank you for the update.
> 
> Is there another bug report this should be merged with?

Not that I'm aware of at least - I think this was the first user report for the
issue.

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

Re: [PATCH] RFC: console: hack up console_lock more v3

On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra  wrote:
> On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > outside of the spinlock. This isn't correct in full generality, but
> > good enough for console_lock:
> >
> > - console_lock doesn't use interruptible or killable or timeout down()
> >   calls, hence an up() is the only thing that can wake up a process.
>
> Wrong :/ Any task can be woken at any random time. We must, at all
> times, assume spurious wakeups will happen.

Out of curiosity, where do these come from? I know about the races
where you need to recheck on the waiter side to avoid getting stuck,
but didn't know about this. Are these earlier (possibly spurious)
wakeups that got held up and delayed for a while, then hit the task
much later when it's already continued doing something else? Or even
more random, and even if I never put a task on a wait list or anything
else, ever, it can get woken spuriously?

> > +void printk_safe_up(struct semaphore *sem)
> > +{
> > + unsigned long flags;
> > + struct semaphore_waiter *waiter = NULL;
> > +
> > + raw_spin_lock_irqsave(&sem->lock, flags);
> > + if (likely(list_empty(&sem->wait_list))) {
> > + sem->count++;
> > + } else {
> > + waiter = list_first_entry(&sem->wait_list,
> > +   struct semaphore_waiter, list);
> > + list_del(&waiter->list);
> > + waiter->up = true;
> > + }
> > + raw_spin_unlock_irqrestore(&sem->lock, flags);
> > +
> > + if (waiter) /* protected by being sole wake source */
> > + wake_up_process(waiter->task);
> > +}
> > +EXPORT_SYMBOL(printk_safe_up);
>
> Since its only used from printk, that EXPORT really isn't needed.
>
> Something like the below might work.

Yeah that looks like the proper fix. I guess semaphores are uncritical
enough that we can roll this out for everyone. Thanks for the hint.
-Daniel

>
> ---
>  kernel/locking/semaphore.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
> index 561acdd39960..ac0a67e95aac 100644
> --- a/kernel/locking/semaphore.c
> +++ b/kernel/locking/semaphore.c
> @@ -38,7 +38,6 @@ static noinline void __down(struct semaphore *sem);
>  static noinline int __down_interruptible(struct semaphore *sem);
>  static noinline int __down_killable(struct semaphore *sem);
>  static noinline int __down_timeout(struct semaphore *sem, long timeout);
> -static noinline void __up(struct semaphore *sem);
>
>  /**
>   * down - acquire the semaphore
> @@ -178,14 +177,24 @@ EXPORT_SYMBOL(down_timeout);
>   */
>  void up(struct semaphore *sem)
>  {
> +   struct semaphore_waiter *waiter;
> +   DEFINE_WAKE_Q(wake_q);
> unsigned long flags;
>
> raw_spin_lock_irqsave(&sem->lock, flags);
> -   if (likely(list_empty(&sem->wait_list)))
> +   if (likely(list_empty(&sem->wait_list))) {
> sem->count++;
> -   else
> -   __up(sem);
> +   goto unlock;
> +   }
> +
> +   waiter = list_first_entry(&sem->wait_list, struct semaphore_waiter, 
> list);
> +   list_del(&waiter->list);
> +   waiter->up = true;
> +   wake_q_add(&wake_q, waiter->task);
> +unlock:
> raw_spin_unlock_irqrestore(&sem->lock, flags);
> +
> +   wake_up_q(&wake_q);
>  }
>  EXPORT_SYMBOL(up);
>
> @@ -252,12 +261,3 @@ static noinline int __sched __down_timeout(struct 
> semaphore *sem, long timeout)
>  {
> return __down_common(sem, TASK_UNINTERRUPTIBLE, timeout);
>  }
> -
> -static noinline void __sched __up(struct semaphore *sem)
> -{
> -   struct semaphore_waiter *waiter = list_first_entry(&sem->wait_list,
> -   struct semaphore_waiter, 
> list);
> -   list_del(&waiter->list);
> -   waiter->up = true;
> -   wake_up_process(waiter->task);
> -}



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110381] Failed to updateMST allocation table forpipe idx:0

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

--- Comment #4 from Paul Menzel  ---
(In reply to Nicholas Kazlauskas from comment #3)
> We're able to reproduce the problem.
> 
> I believe that we found the issue was caused by the new common helper DRM
> for DP MST hotplug. A fix is in the works for this issue.

Great news! Thank you for the update.

Is there another bug report this should be merged with?

-- 
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 110381] Failed to updateMST allocation table forpipe idx:0

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

--- Comment #3 from Nicholas Kazlauskas  ---
We're able to reproduce the problem.

I believe that we found the issue was caused by the new common helper DRM for
DP MST hotplug. A fix is in the works for this issue.

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

[Bug 107607] Problems with MST display (REG_WAIT takes a while or times out)

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

--- Comment #8 from Paul Menzel  ---
(In reply to Nicholas Kazlauskas from comment #7)
> Can you clarify the problem you're observing?
> 
> Do all the displays go blank after switching inputs?

There is exactly one monitor/display.

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

[Bug 110381] Failed to updateMST allocation table forpipe idx:0

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

--- Comment #2 from Paul Menzel  ---
This still happens with Linux 5.1. I had to give the system away, so won’t have
access to it.

I had hoped for more help of the AMD developers to track down regressions.

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

Re: [PATCH] RFC: console: hack up console_lock more v3

2019-05-09 Thread Chris Wilson

Quoting Daniel Vetter (2019-05-09 13:09:03)
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then lockdep jumps in and spams the logs,
> potentially obscuring the real backtrace we're really interested in.
> One case I've seen (slightly simplified backtrace):
> 
>  Call Trace:
>   
>   console_trylock+0xe/0x60
>   vprintk_emit+0xf1/0x320
>   printk+0x4d/0x69
>   __warn_printk+0x46/0x90
>   native_smp_send_reschedule+0x2f/0x40
>   check_preempt_curr+0x81/0xa0
>   ttwu_do_wakeup+0x14/0x220
>   try_to_wake_up+0x218/0x5f0
>   pollwake+0x6f/0x90
>   credit_entropy_bits+0x204/0x310
>   add_interrupt_randomness+0x18f/0x210
>   handle_irq+0x67/0x160
>   do_IRQ+0x5e/0x130
>   common_interrupt+0xf/0xf
>   
> 
> This alone isn't a problem, but the spinlock in the semaphore is also
> still held while waking up waiters (up() -> __up() -> try_to_wake_up()
> callchain), which then closes the runqueue vs. semaphore.lock loop,
> and upsets lockdep, which issues a circular locking splat to dmesg.
> Worse it upsets developers, since we don't want to spam dmesg with
> clutter when the machine is dying already.
> 
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
> 
> - console_lock doesn't use interruptible or killable or timeout down()
>   calls, hence an up() is the only thing that can wake up a process.
>   Hence the process can't get woken and killed and reaped while we try
>   to wake it up too.
> 
> - semaphore.c always updates the waiter list while under the spinlock,
>   so there's no other races. Specifically another process that races
>   with a quick console_lock/unlock while we've dropped the spinlock
>   already won't see our own waiter.
> 
> Note that we only have to break the recursion for the semaphore.lock
> spinlock of the console_lock. Recursion within various scheduler
> related locks is already prevented by the printk_safe_enter/exit pair
> in __up_console_sem().
> 
> Also cc'ing John Ogness since perhaps his printk rework fixes this all
> properly.
> 
> v2: Ditch attempt to fix console_trylock.
> 
> v3: Add a comment explaining why the taks we're waking won't
> disappear (Chris), and improve commit message to address review
> questions.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Will Deacon 
> Cc: Petr Mladek 
> Cc: Sergey Senozhatsky 
> Cc: Steven Rostedt 
> Cc: Daniel Vetter 
> Cc: John Ogness 
> Cc: Chris Wilson 
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Daniel Vetter 

I'm a bit nervous about that this is only safe for the precisely
controlled conditions, but then again that it is called printk_safe
should deter any other users.

The logic checks out, and you convinced me that the dereference is
protected, so
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] RFC: console: hack up console_lock more v3

2019-05-09 Thread Peter Zijlstra

On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
> 
> - console_lock doesn't use interruptible or killable or timeout down()
>   calls, hence an up() is the only thing that can wake up a process.

Wrong :/ Any task can be woken at any random time. We must, at all
times, assume spurious wakeups will happen.

> +void printk_safe_up(struct semaphore *sem)
> +{
> + unsigned long flags;
> + struct semaphore_waiter *waiter = NULL;
> +
> + raw_spin_lock_irqsave(&sem->lock, flags);
> + if (likely(list_empty(&sem->wait_list))) {
> + sem->count++;
> + } else {
> + waiter = list_first_entry(&sem->wait_list,
> +   struct semaphore_waiter, list);
> + list_del(&waiter->list);
> + waiter->up = true;
> + }
> + raw_spin_unlock_irqrestore(&sem->lock, flags);
> +
> + if (waiter) /* protected by being sole wake source */
> + wake_up_process(waiter->task);
> +}
> +EXPORT_SYMBOL(printk_safe_up);

Since its only used from printk, that EXPORT really isn't needed.

Something like the below might work.

---
 kernel/locking/semaphore.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..ac0a67e95aac 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -38,7 +38,6 @@ static noinline void __down(struct semaphore *sem);
 static noinline int __down_interruptible(struct semaphore *sem);
 static noinline int __down_killable(struct semaphore *sem);
 static noinline int __down_timeout(struct semaphore *sem, long timeout);
-static noinline void __up(struct semaphore *sem);
 
 /**
  * down - acquire the semaphore
@@ -178,14 +177,24 @@ EXPORT_SYMBOL(down_timeout);
  */
 void up(struct semaphore *sem)
 {
+   struct semaphore_waiter *waiter;
+   DEFINE_WAKE_Q(wake_q);
unsigned long flags;
 
raw_spin_lock_irqsave(&sem->lock, flags);
-   if (likely(list_empty(&sem->wait_list)))
+   if (likely(list_empty(&sem->wait_list))) {
sem->count++;
-   else
-   __up(sem);
+   goto unlock;
+   }
+
+   waiter = list_first_entry(&sem->wait_list, struct semaphore_waiter, 
list);
+   list_del(&waiter->list);
+   waiter->up = true;
+   wake_q_add(&wake_q, waiter->task);
+unlock:
raw_spin_unlock_irqrestore(&sem->lock, flags);
+
+   wake_up_q(&wake_q);
 }
 EXPORT_SYMBOL(up);
 
@@ -252,12 +261,3 @@ static noinline int __sched __down_timeout(struct 
semaphore *sem, long timeout)
 {
return __down_common(sem, TASK_UNINTERRUPTIBLE, timeout);
 }
-
-static noinline void __sched __up(struct semaphore *sem)
-{
-   struct semaphore_waiter *waiter = list_first_entry(&sem->wait_list,
-   struct semaphore_waiter, list);
-   list_del(&waiter->list);
-   waiter->up = true;
-   wake_up_process(waiter->task);
-}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: disable framebuffer compression on GeminiLake

2019-05-09 Thread Jani Nikula

On Thu, 09 May 2019, Daniel Drake  wrote:
> Hi,
>
>
> On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni  wrote:
>>
>> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
>> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
>> > > From: Daniel Drake 
>> > >
>> > > On many (all?) the Gemini Lake systems we work with, there is frequent
>> > > momentary graphical corruption at the top of the screen, and it seems
>> > > that disabling framebuffer compression can avoid this.
>> > >
>> > > The ticket was reported 6 months ago and has already affected a
>> > > multitude of users, without any real progress being made. So, lets
>> > > disable framebuffer compression on GeminiLake until a solution is found.
>> > >
>> > > Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085
>> > > Signed-off-by: Daniel Drake 
>> > > Signed-off-by: Jian-Hong Pan 
>> >
>> > Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") ?
>> > Cc: Paulo Zanoni 
>> > Cc: Daniel Vetter 
>> > Cc: Jani Nikula 
>> > Cc:  # v4.11+
>> >
>> > glk landed 1 month before, so that seems the earliest broken point.
>> >
>>
>> The bug is well reported, the bug author is helpful and it even has a
>> description of "steps to reproduce" that looks very easy (although I
>> didn't try it). Everything suggests this is a bug the display team
>> could actually solve with not-so-many hours of debugging.
>>
>> In the meantime, unbreak the systems:
>> Reviewed-by: Paulo Zanoni 
>
> Quick ping here. Any further comments on this patch? Can it be applied?

Pushed now, thanks. Needed to get a clean CI result, and I dropped the
ball a bit there, sorry.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109294] [CI][SHARDS] igt@prime_vgem@basic-fence-flip - skip - Test requirement: (crtc_id = set_fb_on_crtc(i915, 0, &bo[0], fb_id[0])), SKIP

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

Tvrtko Ursulin  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Tvrtko Ursulin  ---
Pushed a test fix to probe the native display resolution.

-- 
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] RFC: console: hack up console_lock more v3

console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):

 Call Trace:
  
  console_trylock+0xe/0x60
  vprintk_emit+0xf1/0x320
  printk+0x4d/0x69
  __warn_printk+0x46/0x90
  native_smp_send_reschedule+0x2f/0x40
  check_preempt_curr+0x81/0xa0
  ttwu_do_wakeup+0x14/0x220
  try_to_wake_up+0x218/0x5f0
  pollwake+0x6f/0x90
  credit_entropy_bits+0x204/0x310
  add_interrupt_randomness+0x18f/0x210
  handle_irq+0x67/0x160
  do_IRQ+0x5e/0x130
  common_interrupt+0xf/0xf
  

This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.

Fix this by creating a prinkt_safe_up() which calls wake_up_process
outside of the spinlock. This isn't correct in full generality, but
good enough for console_lock:

- console_lock doesn't use interruptible or killable or timeout down()
  calls, hence an up() is the only thing that can wake up a process.
  Hence the process can't get woken and killed and reaped while we try
  to wake it up too.

- semaphore.c always updates the waiter list while under the spinlock,
  so there's no other races. Specifically another process that races
  with a quick console_lock/unlock while we've dropped the spinlock
  already won't see our own waiter.

Note that we only have to break the recursion for the semaphore.lock
spinlock of the console_lock. Recursion within various scheduler
related locks is already prevented by the printk_safe_enter/exit pair
in __up_console_sem().

Also cc'ing John Ogness since perhaps his printk rework fixes this all
properly.

v2: Ditch attempt to fix console_trylock.

v3: Add a comment explaining why the taks we're waking won't
disappear (Chris), and improve commit message to address review
questions.

Signed-off-by: Daniel Vetter 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Will Deacon 
Cc: Petr Mladek 
Cc: Sergey Senozhatsky 
Cc: Steven Rostedt 
Cc: Daniel Vetter 
Cc: John Ogness 
Cc: Chris Wilson 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 include/linux/semaphore.h  |  1 +
 kernel/locking/semaphore.c | 31 +++
 kernel/printk/printk.c |  2 +-
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h
index 11c86fbfeb98..7e839c72809d 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -41,6 +41,7 @@ extern int __must_check down_interruptible(struct semaphore 
*sem);
 extern int __must_check down_killable(struct semaphore *sem);
 extern int __must_check down_trylock(struct semaphore *sem);
 extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
+extern void printk_safe_up(struct semaphore *sem);
 extern void up(struct semaphore *sem);
 
 #endif /* __LINUX_SEMAPHORE_H */
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..55a896f18d91 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -197,6 +197,37 @@ struct semaphore_waiter {
bool up;
 };
 
+/**
+ * printk_safe_up - release the semaphore in console_unlock
+ * @sem: the semaphore to release
+ *
+ * Release the semaphore.  Unlike mutexes, up() may be called from any
+ * context and even by tasks which have never called down().
+ *
+ * NOTE: This is a special version of up() for console_unlock only. It is only
+ * safe if there are no killable, interruptible or timing out down() calls.
+ */
+void printk_safe_up(struct semaphore *sem)
+{
+   unsigned long flags;
+   struct semaphore_waiter *waiter = NULL;
+
+   raw_spin_lock_irqsave(&sem->lock, flags);
+   if (likely(list_empty(&sem->wait_list))) {
+   sem->count++;
+   } else {
+   waiter = list_first_entry(&sem->wait_list,
+ struct semaphore_waiter, list);
+   list_del(&waiter->list);
+   waiter->up = true;
+   }
+   raw_spin_unlock_irqrestore(&sem->lock, flags);
+
+   if (waiter) /* protected by being sole wake source */
+   wake_up_process(waiter->task);
+}
+EXPORT_SYMBOL(printk_safe_up);
+
 /*
  * Because this function is inlined, the 'state' parameter will be
  * constant, and thus optimised away by the compiler.  Likewise the
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02ca827b8fac..62303929afda 100644
--- a/kernel/printk/printk.c
+++ b/kernel

[Bug 109345] drm-next-2018-12-14 -Linux PPC

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

--- Comment #39 from Christian Zigotzky  ---
Hi All,

Allan has successfully tested the eleventh test kernel.

He wrote:

Christian
DRM11 boots to Firepro.

ace

--

We have a result!

git bisect good

The following commit is responsible for the issue:

3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa is the first bad commit
commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa
Author: Aaron Ma 
Date:   Sat Sep 1 02:20:00 2018 +0800

vgaarb: Keep adding VGA device in queue

If failed to find the deivice owning the boot framebuffer,
try to use the first VGA device instead of the last one.

Usually the 1st device is integrated GPU who owns the boot framebuffer.

Signed-off-by: Aaron Ma 
Acked-by: Alex Deucher 
Signed-off-by: Daniel Vetter 
Link:
https://patchwork.freedesktop.org/patch/msgid/1535739600-8842-2-git-send-email-aaron...@canonical.com

:04 04 2d69570b87946ba42095609c945f04de9ad24ef7
3d86752f71500726f20d7d503128119f9b249175 M   drivers

--

I undid these changes in the file 'drivers/gpu/vga/vgaarb.c' and created
another test kernel today.

Download: http://www.xenosoft.de/linux-image-5.2-alpha2-X1000_X5000.tar.gz

You can undo the commit with the following patch:

diff -rupN a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
--- a/drivers/gpu/vga/vgaarb.c2019-05-09 07:56:27.595746473 +0200
+++ b/drivers/gpu/vga/vgaarb.c2019-05-09 08:00:06.352660688 +0200
@@ -725,7 +725,7 @@ static bool vga_arbiter_add_pci_device(s
 vga_arbiter_check_bridge_sharing(vgadev);

 /* Add to the list */
-list_add_tail(&vgadev->list, &vga_list);
+list_add(&vgadev->list, &vga_list);
 vga_count++;
 vgaarb_info(&pdev->dev, "VGA device added: decodes=%s,owns=%s,locks=%s\n",
 vga_iostate_to_str(vgadev->decodes),

--

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian

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

Re: [PATCH] sync_file: Return reasonable timestamp when merging signaled fences

2019-05-09 Thread Chris Wilson

Quoting Michael Yang (2019-05-09 05:34:11)
> If all the sync points were signaled in both fences a and b,
> there was only one sync point in merged fence which is a_fence[0].
> The Fence structure in android framework might be confused about
> timestamp if there were any sync points which were signaled after
> a_fence[0]. It might be more reasonable to use timestamp of last signaled
> sync point to represent the merged fence.
> The issue can be found from EGL extension ANDROID_get_frame_timestamps.
> Sometimes the return value of EGL_READS_DONE_TIME_ANDROID is head of
> the return value of EGL_RENDERING_COMPLETE_TIME_ANDROID.
> That means display/composition had been completed before rendering
> was completed that is incorrect.
> 
> Some discussion can be found at:
> https://android-review.googlesource.com/c/kernel/common/+/907009
> 
> Signed-off-by: Michael Yang 
> ---
> Hi,
> I didn't get response since I previously sent this a month ago.
> Could someone have a chance to look at it please?
> Thanks.
>  drivers/dma-buf/sync_file.c | 25 +++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 4f6305c..d46bfe1 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -274,8 +274,29 @@ static struct sync_file *sync_file_merge(const char 
> *name, struct sync_file *a,
> for (; i_b < b_num_fences; i_b++)
> add_fence(fences, &i, b_fences[i_b]);
>  
> -   if (i == 0)
> -   fences[i++] = dma_fence_get(a_fences[0]);
> +   /* If all the sync pts were signaled, then adding the sync_pt who
> +* was the last signaled to the fence.
> +*/
> +   if (i == 0) {
> +   struct dma_fence *last_signaled_sync_pt = a_fences[0];
> +   int iter;
> +
> +   for (iter = 1; iter < a_num_fences; iter++) {

If there is more than one fence, sync_file->fence is a fence_array and
its timestamp is what you want. If there is one fence, sync_file->fence
is a pointer to that fence, and naturally has the right timestamp.

In short, this should be handled by dma_fence_array_create() when given
a complete set of signaled fences, it too should inherit the signaled
status with the timestamp being taken from the last fence. It should
also be careful to inherit the error status.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: disable framebuffer compression on GeminiLake

2019-05-09 Thread Daniel Drake

Hi,


On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni  wrote:
>
> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > > From: Daniel Drake 
> > >
> > > On many (all?) the Gemini Lake systems we work with, there is frequent
> > > momentary graphical corruption at the top of the screen, and it seems
> > > that disabling framebuffer compression can avoid this.
> > >
> > > The ticket was reported 6 months ago and has already affected a
> > > multitude of users, without any real progress being made. So, lets
> > > disable framebuffer compression on GeminiLake until a solution is found.
> > >
> > > Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085
> > > Signed-off-by: Daniel Drake 
> > > Signed-off-by: Jian-Hong Pan 
> >
> > Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") ?
> > Cc: Paulo Zanoni 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc:  # v4.11+
> >
> > glk landed 1 month before, so that seems the earliest broken point.
> >
>
> The bug is well reported, the bug author is helpful and it even has a
> description of "steps to reproduce" that looks very easy (although I
> didn't try it). Everything suggests this is a bug the display team
> could actually solve with not-so-many hours of debugging.
>
> In the meantime, unbreak the systems:
> Reviewed-by: Paulo Zanoni 

Quick ping here. Any further comments on this patch? Can it be applied?

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

[Bug 109345] drm-next-2018-12-14 -Linux PPC

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

--- Comment #38 from Christian Zigotzky  ---
Hi All,

Allan tested the tenth test kernel today.

He wrote:

Christian
DRM10 also boots to SI card.

ace

--

Link to the test thread:
http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4256&start=50#p47877

This step has been marked as bad because the tenth test kernel doesn't boot to
the FirePro.

Next step:

git bisect bad

Output:

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a81c9ab678802075b7942c41cf640d9d9866d2db] vgaarb: Add support for 64-bit frame
buffer address

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm11

Additionally I undid the changes in the file 'drivers/gpu/vga/vgaarb.c' [1] and
created a test kernel today.

Download: http://www.xenosoft.de/linux-image-5.2-alpha2-X1000_X5000.tar.gz

@Allan (acefnq/ace)
Please test both kernels.

Thanks,
Christian

[1] https://patchwork.freedesktop.org/patch/246810/

-- 
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-intel-next-fixes

2019-05-09 Thread Joonas Lahtinen

Hi Dave & Daniel,

Still rather quiet, most issues seem to have been fixed during CI testing.

For i915, just two fixes to the request semaphore ordering code.

For GVT a couple regression and static checker fixes.

Best Regards,
Joonas

***

drm-intel-next-fixes-2019-05-09:

- Two fixes for the freshly enabled semaphore ordering code
- Includes gvt-next-fixes-2019-05-07

The following changes since commit 9628e15ca9d5f7595ba886173e98a139d0a56cd1:

  drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 
+0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2019-05-09

for you to fetch changes up to 23372cce8fe7ee98a6458fd3d035a55b87f0c6fe:

  Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux 
into drm-intel-next-fixes (2019-05-07 15:29:15 +0300)


- Two fixes for the freshly enabled semaphore ordering code
- Includes gvt-next-fixes-2019-05-07


Aleksei Gimbitskii (4):
  drm/i915/gvt: Remove typedef and let the enumeration starts from zero
  drm/i915/gvt: Do not copy the uninitialized pointer from fb_info
  drm/i915/gvt: Use snprintf() to prevent possible buffer overflow.
  drm/i915/gvt: Check if get_next_pt_type() always returns a valid value

Chris Wilson (2):
  drm/i915: Delay semaphore submission until the start of the signaler
  drm/i915: Disable semaphore busywaits on saturated systems

Colin Xu (1):
  drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list

Joonas Lahtinen (1):
  Merge tag 'gvt-next-fixes-2019-05-07' of 
https://github.com/intel/gvt-linux into drm-intel-next-fixes

Xiong Zhang (1):
  drm/i915/gvt: Change fb_info->size from pages to bytes

Zhao Yakui (1):
  drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 
MCHBAR to optimize gvt-g boot time"

 drivers/gpu/drm/i915/gvt/debugfs.c |  4 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c  | 19 --
 drivers/gpu/drm/i915/gvt/gtt.c | 15 +---
 drivers/gpu/drm/i915/gvt/gtt.h | 16 
 drivers/gpu/drm/i915/gvt/handlers.c|  4 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c|  1 +
 drivers/gpu/drm/i915/gvt/reg.h |  3 --
 drivers/gpu/drm/i915/gvt/scheduler.c   |  2 +-
 drivers/gpu/drm/i915/i915_request.c| 59 +-
 drivers/gpu/drm/i915/intel_context.c   |  1 +
 drivers/gpu/drm/i915/intel_context_types.h |  3 ++
 11 files changed, 93 insertions(+), 34 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6Q

2019-05-09 Thread Philipp Zabel

The current buffer check halves the frame rate on non-plus i.MX6Q,
as the IDMAC current buffer pointer is not yet updated when
ipu_plane_atomic_update_pending is called from the EOF irq handler.

Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic update 
status")
Tested-by: Marco Felsch 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 13 -
 drivers/gpu/drm/imx/ipuv3-plane.h |  1 -
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index d7a727a6e3d7..91edfe2498a6 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -605,7 +605,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
-   ipu_plane->next_buf = !active;
if (ipu_plane_separate_alpha(ipu_plane)) {
active = 
ipu_idmac_get_current_buffer(ipu_plane->alpha_ch);
ipu_cpmem_set_buffer(ipu_plane->alpha_ch, !active,
@@ -710,7 +709,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba);
ipu_idmac_lock_enable(ipu_plane->ipu_ch, num_bursts);
ipu_plane_enable(ipu_plane);
-   ipu_plane->next_buf = -1;
 }
 
 static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = {
@@ -732,10 +730,15 @@ bool ipu_plane_atomic_update_pending(struct drm_plane 
*plane)
 
if (ipu_state->use_pre)
return ipu_prg_channel_configure_pending(ipu_plane->ipu_ch);
-   else if (ipu_plane->next_buf >= 0)
-   return ipu_idmac_get_current_buffer(ipu_plane->ipu_ch) !=
-  ipu_plane->next_buf;
 
+   /*
+* Pretend no update is pending in the non-PRE/PRG case. For this to
+* happen, an atomic update would have to be deferred until after the
+* start of the next frame and simultaneously interrupt latency would
+* have to be high enough to let the atomic update finish and issue an
+* event before the previous end of frame interrupt handler can be
+* executed.
+*/
return false;
 }
 int ipu_planes_assign_pre(struct drm_device *dev,
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.h 
b/drivers/gpu/drm/imx/ipuv3-plane.h
index 15e85e15d35c..ffacbcdd2f98 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.h
+++ b/drivers/gpu/drm/imx/ipuv3-plane.h
@@ -27,7 +27,6 @@ struct ipu_plane {
int dp_flow;
 
booldisabling;
-   int next_buf;
 };
 
 struct ipu_plane *ipu_plane_init(struct drm_device *dev, struct ipu_soc *ipu,
-- 
2.20.1

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

Re: [PATCH] drm: Some ocd in drm_file.c

On Thu, May 02, 2019 at 03:07:20PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-02 14:56:03)
> > Move the open helper around to avoid the forward decl, and give
> > drm_setup a drm_legacy_ prefix since it's all legacy stuff in there.
> > 
> > v2: Move drm_legacy_setup into drm_legacy_misc.c (Chris). The
> > counterpart in the form of drm_legacy_dev_reinit is there already too,
> > plus it fits perfectly into Dave's work of making DRIVER_LEGACY code
> > compile-time optional.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Daniel Vetter 
> Reviewed-by: Chris Wilson 

Finally gotten around to ask for the backmerge so I can apply this. Thanks
a lot for your review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 201273] Fatal error during GPU init amdgpu RX560

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

--- Comment #54 from Marco (rodomar...@protonmail.com) ---
It seems that I've managed to "fix" it by putting the amdgpu module load early
at boot with mkinitcpio.conf; after 30/40 reboots I still haven't seen a crash
since; but since the problem appears so randomly, I'm not sure if it just luck
or something specific that triggers it that I'm not doing it.

I'll post this here in the hope that it will help someone else.

-- 
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 110635] briefly flashing corruption when playing various OGL games

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

--- Comment #2 from tempel.jul...@gmail.com ---
The mesa-git build of mine was from after that commit, and a profile already
applies it to Dying Light as well. :)

-- 
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: Support for 2D engines/blitters in V4L2 and DRM

2019-05-09 Thread Paul Kocialkowski

Hi Pekka,

Le lundi 06 mai 2019 à 11:28 +0300, Pekka Paalanen a écrit :
> On Wed, 17 Apr 2019 20:10:15 +0200
> Paul Kocialkowski  wrote:
> 
> > There's also the possibility of writing up a drm-render DDX to handle
> > these 2D blitters that can make things a lot faster when running a
> > desktop environment. As for wayland, well, I don't really know what to
> > think. I was under the impression that it relies on GL for 2D
> > operations, but am really not sure how true that actually is.
> 
> Hi Paul,
> 
> Wayland does not rely on anything really, it does not even have any
> rendering commands, and is completely agnostic to how applications or
> display servers might be drawing things. Wayland (protocol) does care
> about buffer types and fences though, since those are the things passed
> between applications and servers.
> 
> In a Wayland architecture, each display server (called a Wayland
> compositor, corresponding to Xorg + window manager + compositing
> manager) uses whatever they want to use for putting the screen contents
> together. OpenGL is a popular choice, yes, but they may also use Vulkan,
> Pixman, Cairo, Skia, DRM KMS planes, and whatnot or a mix of any.
> Sometimes it may so happen that the display server does not need to
> render at all, the display hardware can realize the screen contents
> through e.g. KMS planes.

Right, I looked some more at wayland and had some discussions over IRC
(come to think of it, I'm pretty sure you were in the discussions too)
to get a clearer understanding of the architecture. The fact that the
wayland protocol is render-agnostic and does not alloc buffers on its
own feels very sane to me.

> Writing a hardware specific driver (like a DDX for Xorg) for one
> display server (or a display server library like wlroots or libweston)
> is no longer reasonable. You would have to do it on so many display
> server projects. What really makes it infeasible is the
> hardware-specific aspect. People would have to write a driver for every
> display server project for every hardware model. That's just not
> feasible today.

Yes, this is why I am suggesting implementing a DRM helper library for
that, which would handle common drivers. Basically what mesa does for
3D, but which a DRM-specific-but-device-agnostic userspace interface.
So the overhead for integration in display servers would be minimal.

> Some display server projects even refuse to take hardware-specific code
> upstream, because keeping it working has a high cost and only very few
> people can test it.

Right, maintainance aspects are quite importance and I think it's
definitely best to centralize per-device support in a common library.

> The only way as I see that you could have Wayland compositors at large
> take advantage of 2D hardware units is to come up with the common
> userspace API in the sense similar to Vulkan or OpenGL, so that each
> display server would only need to support the API, and the API
> implementation would handle the hardware-specific parts. OpenWF by
> Khronos may have been the most serious effort in that, good luck
> finding any users or implementations today. Although maybe Android's
> hwcomposer could be the next one.

I would be very cautious regarding the approach of designing a
"standardized" API across systems. Most of the time, this does not work
well and ends up involving a glue layer of crap that is not always a
good fit for the system. Things more or less worked out with GL (with
significant effort put into it), but there are countless other examples
where it didn't (things like OpenMAX, OpenVG, etc).

In addition, this would mostly only be used in compositors, not in
final applications, so the need to have a common API across systems is
much reduced. There's also the fact that 2D is much less complicated
than 3D.

So I am not very interested in this form of standardization and I think
a DRM-specific userspace API for this is not only sufficient, but
probably also the best fit for the job. Maybe the library implementing
this API and device support could later be extended to support a
standardized API across systems too if one shows up (a bit like mesa
supports different state trackers). That's definitely not a personal
priority though and I firmly believe it should not be a blocker to get
2D blitters support with DRM.

> However, if someone is doing a special Wayland compositor to be used on
> specific hardware, they can of course use whatever to put the screen
> contents together in a downstream fork. Wayland does not restrict that
> in any way, not even by buffer or fence types because you can extend
> Wayland to deal with anything you need, as long as you also modify the
> apps or toolkits to do it too. The limitations are really more
> political and practical if you aim for upstream and wide-spread use of
> 2D hardware blocks.

Yes I understand that the issue is not so much on the technical side,
but rather on governance and politics.

Cheers,

Paul

-- 
Paul Kocialkows

Re: [git pull] drm for 5.2-rc1

2019-05-09 Thread Dave Airlie

On Thu, 9 May 2019 at 14:45, Linus Torvalds
 wrote:
>
> Dave,
>
> On Wed, May 8, 2019 at 8:28 PM Dave Airlie  wrote:
> >
> > This is the main drm pull request for 5.2.
>
> Thanks. I've merged it, but I got a couple of conflicts with fixes
> (reverts) to mainline in the meantime.
>
> The one to the i915 driver you seem to have applied again (after the
> function was moved and renamed).
>
> The one to the virtgpu driver, I really don't know if is needed any
> more. I suspect I completely unnecessarily merged that
> virtgpu_gem_prime_import_sg_table() function that came in because I
> decided to do the merge of the revert.
>
> It's a trivial function that just returns an error, and your tree just
> leaves it as NULL, and I suspect my merge doesn't hurt, but it also
> probably doesn't matter.
>
> So you should check my merge.

Thanks,

That explains the "I know I had something else to say" feeling. I did
a test merge yesterday and then forgot to write the details down.

I had a look and it seems fine, and it's Gerd's code so if he's happy
with the result.

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

[PATCH] drm/panfrost: Only put sync_out if non-NULL

2019-05-09 Thread Tomeu Vizoso

Dan Carpenter's static analysis tool reported:

drivers/gpu/drm/panfrost/panfrost_drv.c:222 panfrost_ioctl_submit()
error: we previously assumed 'sync_out' could be null (see line 216)

Indeed, sync_out could be NULL if userspace doesn't send a sync object
ID for the out fence.

Signed-off-by: Tomeu Vizoso 
Reported-by: Dan Carpenter 
Link: https://lists.freedesktop.org/archives/dri-devel/2019-May/217014.html
---
 drivers/gpu/drm/panfrost/panfrost_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 94b0819ad50b..d11e2281dde6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -219,7 +219,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev, 
void *data,
 fail_job:
panfrost_job_put(job);
 fail_out_sync:
-   drm_syncobj_put(sync_out);
+   if (sync_out)
+   drm_syncobj_put(sync_out);
 
return ret;
 }
-- 
2.20.1

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

Re: [PATCH 1/2] drm/i915: Seal races between async GPU cancellation, retirement and signaling

On Wed, May 08, 2019 at 09:30:42PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-08 13:53:30)
> > On Wed, May 8, 2019 at 2:06 PM Chris Wilson  
> > wrote:
> > >
> > > Currently there is an underlying assumption that i915_request_unsubmit()
> > > is synchronous wrt the GPU -- that is the request is no longer in flight
> > > as we remove it. In the near future that may change, and this may upset
> > > our signaling as we can process an interrupt for that request while it
> > > is no longer in flight.
> > >
> > > CPU0CPU1
> > > intel_engine_breadcrumbs_irq
> > > (queue request completion)
> > > i915_request_cancel_signaling
> > > ... ...
> > > i915_request_enable_signaling
> > > dma_fence_signal
> > >
> > > Hence in the time it took us to drop the lock to signal the request, a
> > > preemption event may have occurred and re-queued the request. In the
> > > process, that request would have seen I915_FENCE_FLAG_SIGNAL clear and
> > > so reused the rq->signal_link that was in use on CPU0, leading to bad
> > > pointer chasing in intel_engine_breadcrumbs_irq.
> > >
> > > A related issue was that if someone started listening for a signal on a
> > > completed but no longer in-flight request, we missed the opportunity to
> > > immediately signal that request.
> > >
> > > Furthermore, as intel_contexts may be immediately released during
> > > request retirement, in order to be entirely sure that
> > > intel_engine_breadcrumbs_irq may no longer dereference the intel_context
> > > (ce->signals and ce->signal_link), we must wait for irq spinlock.
> > >
> > > In order to prevent the race, we use a bit in the fence.flags to signal
> > > the transfer onto the signal list inside intel_engine_breadcrumbs_irq.
> > > For simplicity, we use the DMA_FENCE_FLAG_SIGNALED_BIT as it then
> > > quickly signals to any outside observer that the fence is indeed signaled.
> > >
> > > v2: Sketch out potential dma-fence API for manual signaling
> > > v3: And the test_and_set_bit()
> > >
> > > Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with 
> > > per-context interrupt tracking")
> > > Signed-off-by: Chris Wilson 
> > > Cc: Tvrtko Ursulin 
> > > Reviewed-by: Tvrtko Ursulin 
> > 
> > Ok chatted a bit with Chris on irc, and we already allow drivers to
> > pass whatever spinlock is suitable for their request/fence
> > handling/retiring, so allowing to split up this all makes sense I
> > think. Has my ack on the approach.
> > 
> > I think it'd be good to spell out the optimization this allows
> > (synchronous cleanup instead of refcounting all. the. things.) plus
> > showcase the link between the fence->lock pointer and the split-up
> > __dma_signal functions in the kerneldoc. Definitely for the core
> > patch.
> > 
> > Also not sure why __notify and __timestamp has a double underscore in
> > the middle. That color choice confuses me a bit :-)
> 
> I like it for subphases. The overall action here is still the dma-fence
> 'signal', but now we are doing the 'set timestamp', 'notify callbacks'
> etc. Otherwise we gain a subject to the verb, 'signal_notify' which says
> to go and signal the notify, rather than do the notifications; for me
> the '__' breaks the association. Maybe dma_fence_signal_do_notifies.

at the cost of 2 more letters in already long function names, I think
_do_step1, _do_step2 are clearer ...

Aside: Could we merge the timestampe and do_notify steps together, maybe
with the spinlock in there? I think materially it doesn't matter whether
we set the timestampe before or in the spinlock protected section, as long
as we don't set it afterwards. And would simplify the interface a bit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110637] Any OpenCL application causes "ERROR ring gfx timeout" on Vega 64

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

--- Comment #5 from Alexander Mezin  ---
And BTW with kernel 4.19.40 and latest git firmware
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=2579167548be33afb1fe2a9a5c141561ee5a8bbe)
monitors switch off on boot as soon as amdgpu driver loads and never turn on
again

-- 
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 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

2019-05-09 Thread Frank Rowand

On 5/8/19 6:44 PM, Theodore Ts'o wrote:
> On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote:
>>
>> If KUnit is added to the kernel, and a subsystem that I am submitting
>> code for has chosen to use KUnit instead of kselftest, then yes, I do
>> *have* to use KUnit if my submission needs to contain a test for the
>> code unless I want to convince the maintainer that somehow my case
>> is special and I prefer to use kselftest instead of KUnittest.
> 
> That's going to be between you and the maintainer.  Today, if you want
> to submit a substantive change to xfs or ext4, you're going to be
> asked to create test for that new feature using xfstests.  It doesn't
> matter that xfstests isn't in the kernel --- if that's what is
> required by the maintainer.

Yes, that is exactly what I was saying.

Please do not cut the pertinent parts of context that I am replying to.


>>> supposed to be a simple way to run a large number of small tests that
>>> for specific small components in a system.
>>
>> kselftest also supports running a subset of tests.  That subset of tests
>> can also be a large number of small tests.  There is nothing inherent
>> in KUnit vs kselftest in this regard, as far as I am aware.


> The big difference is that kselftests are driven by a C program that
> runs in userspace.  Take a look at 
> tools/testing/selftests/filesystem/dnotify_test.c
> it has a main(int argc, char *argv) function.
> 
> In contrast, KUnit are fragments of C code which run in the kernel;
> not in userspace.  This allows us to test internal functions inside
> complex file system (such as the block allocator in ext4) directly.
> This makes it *fundamentally* different from kselftest.

No, totally incorrect.  kselftests also supports in kernel modules as
I mention in another reply to this patch.

This is talking past each other a little bit, because your next reply
is a reply to my email about modules.

-Frank

> 
> Cheers,
> 
>   - Ted
> 

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

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

2019-05-09 Thread Frank Rowand

On 5/8/19 6:58 PM, Theodore Ts'o wrote:
> On Wed, May 08, 2019 at 05:43:35PM -0700, Frank Rowand wrote:
>> kselftest provides a mechanism for in-kernel tests via modules.  For
>> example, see:
>>
>>   tools/testing/selftests/vm/run_vmtests invokes:
>> tools/testing/selftests/vm/test_vmalloc.sh
>>   loads module:
>> test_vmalloc
>> (which is built from lib/test_vmalloc.c if CONFIG_TEST_VMALLOC)
> 
> The majority of the kselftests are implemented as userspace programs.

Non-argument.


> You *can* run in-kernel test using modules; but there is no framework
> for the in-kernel code found in the test modules, which means each of
> the in-kernel code has to create their own in-kernel test
> infrastructure.

Why create an entire new subsystem (KUnit) when you can add a header
file (and .c code as appropriate) that outputs the proper TAP formatted
results from kselftest kernel test modules?

There are already a multitude of in kernel test modules used by
kselftest.  It would be good if they all used a common TAP compliant
mechanism to report results.

 
> That's much like saying you can use vice grips to turn a nut or
> bolt-head.  You *can*, but it might be that using a monkey wrench
> would be a much better tool that is much easier.
> 
> What would you say to a wood worker objecting that a toolbox should
> contain a monkey wrench because he already knows how to use vise
> grips, and his tiny brain shouldn't be forced to learn how to use a
> wrench when he knows how to use a vise grip, which is a perfectly good
> tool?
> 
> If you want to use vice grips as a hammer, screwdriver, monkey wrench,
> etc.  there's nothing stopping you from doing that.  But it's not fair
> to object to other people who might want to use better tools.
> 
> The reality is that we have a lot of testing tools.  It's not just
> kselftests.  There is xfstests for file system code, blktests for
> block layer tests, etc.   We use the right tool for the right job.

More specious arguments.

-Frank

> 
>   - Ted
> 

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

[PATCH 01/16] lib: fix match_string() helper on -1 array size

The documentation the `_match_string()` helper mentions that `n`
should be:
 * @n: number of strings in the array or -1 for NULL terminated arrays

The behavior of the function is different, in the sense that it exits on
the first NULL element in the array, regardless of whether `n` is -1 or a
positive number.

This patch changes the behavior, to exit the loop when a NULL element is
found and n == -1. Essentially, this aligns the behavior with the
doc-string.

There are currently many users of `match_string()`, and so, in order to go
through them, the next patches in the series will focus on doing some
cosmetic changes, which are aimed at grouping the users of
`match_string()`.

Signed-off-by: Alexandru Ardelean 
---
 lib/string.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/string.c b/lib/string.c
index 3ab861c1a857..76edb7bf76cb 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -648,8 +648,11 @@ int match_string(const char * const *array, size_t n, 
const char *string)
 
for (index = 0; index < n; index++) {
item = array[index];
-   if (!item)
+   if (!item) {
+   if (n != (size_t)-1)
+   continue;
break;
+   }
if (!strcmp(item, string))
return index;
}
-- 
2.17.1

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

[v1] drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

2019-05-09 Thread Wen He

This patch trying to fix monitor freeze issue caused by drm error
'flip_done timed out' on LS1028A platform. this set try is make a loop
around the second setting CVAL and try like 5 times before giveing up.

Signed-off-by: Liviu 
Signed-off-by: Wen He 
---
 drivers/gpu/drm/arm/malidp_drv.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 21725c9b9f5e..18cb7f134f4e 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -192,6 +192,7 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
 {
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
+   int loop = 5;
 
malidp->event = malidp->crtc.state->event;
malidp->crtc.state->event = NULL;
@@ -206,8 +207,18 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
drm_crtc_vblank_get(&malidp->crtc);
 
/* only set config_valid if the CRTC is enabled */
-   if (malidp_set_and_wait_config_valid(drm) < 0)
+   if (malidp_set_and_wait_config_valid(drm) < 0) {
+   /*
+* make a loop around the second CVAL setting and
+* try 5 times before giving up.
+*/
+   while (loop--) {
+   if (!malidp_set_and_wait_config_valid(drm))
+   break;
+   }
DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   }
+
} else if (malidp->event) {
/* CRTC inactive means vblank IRQ is disabled, send event 
directly */
spin_lock_irq(&drm->event_lock);
-- 
2.17.1

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

[PATCH v2 4/6] ARM: dts: msm8974: add display support

2019-05-09 Thread Brian Masney

Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.

Signed-off-by: Brian Masney 
Reviewed-by: Linus Walleij 
---
Changes since v1:
- None

 arch/arm/boot/dts/qcom-msm8974.dtsi | 132 
 1 file changed, 132 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..3f613c5b95a1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1085,6 +1086,137 @@
};
};
};
+
+   mdss: mdss@fd90 {
+   status = "disabled";
+
+   compatible = "qcom,mdss";
+   reg = <0xfd90 0x100>,
+ <0xfd924000 0x1000>;
+   reg-names = "mdss_phys",
+   "vbif_phys";
+
+   power-domains = <&mmcc MDSS_GDSC>;
+
+   clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+   clock-names = "iface",
+ "bus",
+ "vsync";
+
+   interrupts = ;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mdp: mdp@fd90 {
+   status = "disabled";
+
+   compatible = "qcom,mdp5";
+   reg = <0xfd900100 0x22000>;
+   reg-names = "mdp_phys";
+
+   interrupt-parent = <&mdss>;
+   interrupts = <0 0>;
+
+   clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+   clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdp5_intf1_out: endpoint {
+   remote-endpoint = 
<&dsi0_in>;
+   };
+   };
+   };
+   };
+
+   dsi0: dsi@fd922800 {
+   status = "disabled";
+
+   compatible = "qcom,mdss-dsi-ctrl";
+   reg = <0xfd922800 0x1f8>;
+   reg-names = "dsi_ctrl";
+
+   interrupt-parent = <&mdss>;
+   interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+   assigned-clocks = <&mmcc BYTE0_CLK_SRC>,
+ <&mmcc PCLK0_CLK_SRC>;
+   assigned-clock-parents = <&dsi_phy0 0>,
+<&dsi_phy0 1>;
+
+   clocks = <&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_BYTE0_CLK>,
+<&mmcc MDSS_PCLK0_CLK>,
+<&mmcc MDSS_ESC0_CLK>,
+<&mmcc MMSS_MISC_AHB_CLK>;
+   clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+   phys = <&dsi_phy0>;
+   phy-names = "dsi-phy";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+

[PATCH v2 1/6] drm: msm: remove resv fields from msm_gem_object struct

2019-05-09 Thread Brian Masney

The msm_gem_object structure contains resv and _resv fields that are
no longer needed since the reservation object is now stored on
drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb()
both referenced the wrong reservation object, and would lead to an
attempt to dereference a NULL pointer. Correct those two cases to
point to the correct reservation object.

Signed-off-by: Brian Masney 
Fixes: dd55cf6929e6 ("drm: msm: Switch to use drm_gem_object 
reservation_object")
---
Patch introduced in v2

 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 +---
 drivers/gpu/drm/msm/msm_atomic.c  | 4 +---
 drivers/gpu/drm/msm/msm_gem.c | 3 ---
 drivers/gpu/drm/msm/msm_gem.h | 4 
 4 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index da1f727d7495..ce1a555e1f31 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -780,7 +780,6 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
struct dpu_plane_state *pstate = to_dpu_plane_state(new_state);
struct dpu_hw_fmt_layout layout;
struct drm_gem_object *obj;
-   struct msm_gem_object *msm_obj;
struct dma_fence *fence;
struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
int ret;
@@ -799,8 +798,7 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
 *   implicit fence and fb prepare by hand here.
 */
obj = msm_framebuffer_bo(new_state->fb, 0);
-   msm_obj = to_msm_bo(obj);
-   fence = reservation_object_get_excl_rcu(msm_obj->resv);
+   fence = reservation_object_get_excl_rcu(obj->resv);
if (fence)
drm_atomic_set_fence_for_plane(new_state, fence);
 
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index f5b1256e32b6..131c23a267ee 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -49,15 +49,13 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
struct msm_drm_private *priv = plane->dev->dev_private;
struct msm_kms *kms = priv->kms;
struct drm_gem_object *obj;
-   struct msm_gem_object *msm_obj;
struct dma_fence *fence;
 
if (!new_state->fb)
return 0;
 
obj = msm_framebuffer_bo(new_state->fb, 0);
-   msm_obj = to_msm_bo(obj);
-   fence = reservation_object_get_excl_rcu(msm_obj->resv);
+   fence = reservation_object_get_excl_rcu(obj->resv);
 
drm_atomic_set_fence_for_plane(new_state, fence);
 
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 31d5a744d84f..947508e8269d 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -973,9 +973,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
msm_obj->flags = flags;
msm_obj->madv = MSM_MADV_WILLNEED;
 
-   if (resv)
-   msm_obj->base.resv = resv;
-
INIT_LIST_HEAD(&msm_obj->submit_entry);
INIT_LIST_HEAD(&msm_obj->vmas);
 
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c5ac781dffee..812d1b1369a5 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -86,10 +86,6 @@ struct msm_gem_object {
 
struct llist_node freed;
 
-   /* normally (resv == &_resv) except for imported bo's */
-   struct reservation_object *resv;
-   struct reservation_object _resv;
-
/* For physically contiguous buffers.  Used when we don't have
 * an IOMMU.  Also used for stolen/splashscreen buffer.
 */
-- 
2.20.1

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

[PATCH 15/16] video: fbdev: pxafb: use new match_string() helper/macro

The `lcd_types` array is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.

This reduces the array by 1 element, since the NULL (at the end of the
array) is no longer needed.

Signed-off-by: Alexandru Ardelean 
---
 drivers/video/fbdev/pxafb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 0025781e6e1e..e657a04f5b1d 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2114,7 +2114,7 @@ static void pxafb_check_options(struct device *dev, 
struct pxafb_mach_info *inf)
 #if defined(CONFIG_OF)
 static const char * const lcd_types[] = {
"unknown", "mono-stn", "mono-dstn", "color-stn", "color-dstn",
-   "color-tft", "smart-panel", NULL
+   "color-tft", "smart-panel"
 };
 
 static int of_get_pxafb_display(struct device *dev, struct device_node *disp,
@@ -2129,7 +2129,7 @@ static int of_get_pxafb_display(struct device *dev, 
struct device_node *disp,
if (ret)
s = "color-tft";
 
-   i = __match_string(lcd_types, -1, s);
+   i = match_string(lcd_types, s);
if (i < 0) {
dev_err(dev, "lcd-type %s is unknown\n", s);
return i;
-- 
2.17.1

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

[PATCH 10/16] pinctrl: armada-37xx: use new match_string() helper/macro

The change is mostly cosmetic.

The `armada_37xx_pin_group` struct is defined as.
struct armada_37xx_pin_group {
const char  *name;
unsigned intstart_pin;
unsigned intnpins;
u32 reg_mask;
u32 val[NB_FUNCS];
unsigned intextra_pin;
unsigned intextra_npins;
const char  *funcs[NB_FUNCS];
unsigned int*pins;
};

The `funcs` field is a static array of strings, so using the
new `match_string()` helper (which does an implicit ARRAY_SIZE(gp->funcs))
should be fine.

Signed-off-by: Alexandru Ardelean 
---
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 07a5bcaa0067..68b0db5ef5e9 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -348,7 +348,7 @@ static int armada_37xx_pmx_set_by_name(struct pinctrl_dev 
*pctldev,
dev_dbg(info->dev, "enable function %s group %s\n",
name, grp->name);
 
-   func = __match_string(grp->funcs, NB_FUNCS, name);
+   func = match_string(grp->funcs, name);
if (func < 0)
return -ENOTSUPP;
 
@@ -938,7 +938,7 @@ static int armada_37xx_fill_func(struct armada_37xx_pinctrl 
*info)
struct armada_37xx_pin_group *gp = &info->groups[g];
int f;
 
-   f = __match_string(gp->funcs, NB_FUNCS, name);
+   f = match_string(gp->funcs, name);
if (f < 0)
continue;
 
-- 
2.17.1

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

[PATCH 2/3] drm/bridge: add it6505 driver

2019-05-09 Thread allen

From: Allen Chen 

This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.

Signed-off-by: Jitao Shi 
Signed-off-by: Yilun Lin 
Signed-off-by: Allen Chen 
---
 drivers/gpu/drm/bridge/Kconfig  |   22 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ite-it6505.c | 2637 +++
 3 files changed, 2660 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 9c9c4df..d12e48c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -43,6 +43,28 @@ config DRM_DUMB_VGA_DAC
  Support for non-programmable RGB to VGA DAC bridges, such as ADI
  ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
 
+config DRM_ITE_IT6505
+   tristate "ITE IT6505 DP bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ ITE IT6505 DP bridge chip driver.
+
+config DRM_ITE_IT6505_ENHDCP
+   tristate "Enable IT6505 HDCP function"
+   depends on DRM_ITE_IT6505
+   default y
+
+config DRM_ITE_IT6505_ENAUD
+tristate "Enable IT6505 audio function"
+depends on DRM_ITE_IT6505
+default y
+
+config DRM_ITE_IT6505_ENPWRONOFF
+tristate "Enable IT6505 power on/off function"
+depends on DRM_ITE_IT6505
+default y
+
 config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..f5abca5 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index 000..13079a8
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1,2637 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AX 0
+#define BX 1
+#define AUDSEL I2S
+#define AUDTYPE LPCM
+#define AUDFS AUD48K
+#define AUDCH 2
+/* 0: Standard I2S;1: 32bit I2S */
+#define I2SINPUTFMT 1
+/* 0: Left-justified;1: Right-justified */
+#define I2SJUSTIFIED 0
+/* 0: Data delay 1T correspond to WS;1: No data delay correspond to WS */
+#define I2SDATADELAY 0
+/* 0: is left channel;1: is right channel */
+#define I2SWSCHANNEL 0
+/* 0: MSB shift first;1: LSB shift first */
+#define I2SDATASEQ 0
+
+#define LANESWAP 0
+#define LANE 4
+#define _HBR 1
+#define ENHFRAME 1
+#define ENSSC 1
+
+#define FLAGTRAINDOWN 100
+#define TRAINFAILCNT 5
+#define AUX_WAIT_TIMEOUT_MS 15
+#define PCLK_DELAY 1
+#define PCLK_INV 0
+#define EDIDRETRYTIME 5
+#define SHOWVIDEOTIMING 2
+#define PWROFFRETRYTIME 5
+
+/* AX or BX */
+#define CHIP_VERSION BX
+
+/* if use this define will power on in probe */
+/* #define TEST_MODE */
+
+/* if use this define will enable AUX debug option */
+/* #define ENAUX_TRANSFER_DEBUG */
+
+/* if use this define will enable SHA debug */
+/* #define SHA_DEBUG */
+
+enum sys_status {
+   SYS_UNPLUG = 0,
+   SYS_HPD,
+   SYS_AUTOTRAIN,
+   SYS_WAIT,
+   SYS_TRAINFAIL,
+   SYS_ReHDCP,
+   SYS_PWRDN,
+   SYS_NOROP,
+   SYS_Unknown,
+};
+
+enum it6505_aud_sel {
+   I2S = 0,
+   SPDIF,
+};
+
+enum it6505_aud_fs {
+   AUD24K = 0x6,
+   AUD32K = 0x3,
+   AUD48K = 0x2,
+   AUD96K = 0xA,
+   AUD192K = 0xE,
+   AUD44P1K = 0x0,
+   AUD88P2K = 0x8,
+   AUD176P4K = 0xC,
+};
+
+enum it6505_aud_type {
+   LPCM = 0,
+   NLPCM,
+   DSS,
+   HBR,
+};
+
+enum aud_word_length {
+   AUD16BIT = 0,
+   AUD18BIT,
+   AUD20BIT,
+   AUD24BIT,
+};
+
+/* Audio Sample Word Length: AUD16BIT, AUD18BIT, AUD20BIT, AUD24BIT */
+#define AUDWORDLENGTH AUD24BIT
+
+struct it6505_platform_data {
+   struct regulator *pwr18;
+   struct regulator *ovdd;
+   struct gpio_desc *gpiod_hpd;
+   struct gpio_desc *gpiod_pd;
+   struct gpio_desc *gpiod_reset;
+
+   int hpd_irq;
+   int intp_irq;
+};
+
+struct it6505_dp_port {
+   struct it6505 *it6505_dp;
+   struct notifier_block event_nb;
+   struct extcon_dev *extcon;
+   struct work_struct extcon_wq;
+   u8 id;
+};
+
+struct it6505 {
+

RE: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE

2019-05-09 Thread Wen He



> -Original Message-
> From: Wen He
> Sent: 2019年5月8日 17:42
> To: dri-devel@lists.freedesktop.org; p.za...@pengutronix.de
> Cc: Leo Li ; Wen He 
> Subject: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE
> 
> The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
> but platform is ARCH_LAYERSCAPE:
> 
> drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
> drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
> drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to
> `ipu_dc_enable_channel'
> drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable'
> drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb
> 
> Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable.
> 
> Signed-off-by: Wen He 
> ---
>  drivers/gpu/ipu-v3/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig index
> fe6f8c5b4445..51ea88c440df 100644
> --- a/drivers/gpu/ipu-v3/Kconfig
> +++ b/drivers/gpu/ipu-v3/Kconfig
> @@ -1,6 +1,6 @@
>  config IMX_IPUV3_CORE
>   tristate "IPUv3 core support"
> - depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM ||
> COMPILE_TEST
> + depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM ||
> COMPILE_TEST
> +|| ARCH_LAYERSCAPE
>   depends on DRM || !DRM # if DRM=m, this can't be 'y'
>   select BITREVERSE
>   select GENERIC_ALLOCATOR if DRM
> --
> 2.17.1

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

[PATCH 08/16] cpufreq/intel_pstate: remove NULL entry + use match_string()

The change is mostly cosmetic.

The `energy_perf_strings` array is static, so match_string() can be used
(which will implicitly do a ARRAY_SIZE(energy_perf_strings)).

The only small benefit here, is the reduction of the array size by 1
element.

Signed-off-by: Alexandru Ardelean 
---
 drivers/cpufreq/intel_pstate.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 6ed1e705bc05..ab9a0b34b900 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -593,8 +593,7 @@ static const char * const energy_perf_strings[] = {
"performance",
"balance_performance",
"balance_power",
-   "power",
-   NULL
+   "power"
 };
 static const unsigned int epp_values[] = {
HWP_EPP_PERFORMANCE,
@@ -680,8 +679,8 @@ static ssize_t 
show_energy_performance_available_preferences(
int i = 0;
int ret = 0;
 
-   while (energy_perf_strings[i] != NULL)
-   ret += sprintf(&buf[ret], "%s ", energy_perf_strings[i++]);
+   for (; i < ARRAY_SIZE(energy_perf_strings); i++)
+   ret += sprintf(&buf[ret], "%s ", energy_perf_strings[i]);
 
ret += sprintf(&buf[ret], "\n");
 
@@ -701,7 +700,7 @@ static ssize_t store_energy_performance_preference(
if (ret != 1)
return -EINVAL;
 
-   ret = __match_string(energy_perf_strings, -1, str_preference);
+   ret = match_string(energy_perf_strings, str_preference);
if (ret < 0)
return ret;
 
-- 
2.17.1

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

[v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE

2019-05-09 Thread Wen He

The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
but platform is ARCH_LAYERSCAPE:

drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to 
`ipu_dc_enable_channel'
drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable'
drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb

Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable.

Signed-off-by: Wen He 
---
 drivers/gpu/ipu-v3/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index fe6f8c5b4445..51ea88c440df 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,6 +1,6 @@
 config IMX_IPUV3_CORE
tristate "IPUv3 core support"
-   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST
+   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST 
|| ARCH_LAYERSCAPE
depends on DRM || !DRM # if DRM=m, this can't be 'y'
select BITREVERSE
select GENERIC_ALLOCATOR if DRM
-- 
2.17.1

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

Re: [PATCH 03/16] lib,treewide: add new match_string() helper/macro

2019-05-09 Thread Andy Shevchenko

On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean wrote:
> This change re-introduces `match_string()` as a macro that uses
> ARRAY_SIZE() to compute the size of the array.
> The macro is added in all the places that do
> `match_string(_a, ARRAY_SIZE(_a), s)`, since the change is pretty
> straightforward.

Can you split include/linux/ change from the rest?

> 
> Signed-off-by: Alexandru Ardelean 
> ---
>  drivers/clk/bcm/clk-bcm2835.c| 4 +---
>  drivers/gpio/gpiolib-of.c| 2 +-
>  drivers/gpu/drm/i915/intel_pipe_crc.c| 2 +-
>  drivers/mfd/omap-usb-host.c  | 2 +-
>  drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 2 +-
>  drivers/pci/pcie/aer.c   | 2 +-
>  drivers/usb/common/common.c  | 4 ++--
>  drivers/usb/typec/class.c| 8 +++-
>  drivers/usb/typec/tps6598x.c | 2 +-
>  drivers/vfio/vfio.c  | 4 +---
>  include/linux/string.h   | 9 +
>  sound/firewire/oxfw/oxfw.c   | 2 +-
>  sound/soc/codecs/max98088.c  | 2 +-
>  sound/soc/codecs/max98095.c  | 2 +-
>  14 files changed, 25 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index a775f6a1f717..1ab388590ead 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -1390,9 +1390,7 @@ static struct clk_hw *bcm2835_register_clock(struct 
> bcm2835_cprman *cprman,
>   for (i = 0; i < data->num_mux_parents; i++) {
>   parents[i] = data->parents[i];
>  
> - ret = __match_string(cprman_parent_names,
> -  ARRAY_SIZE(cprman_parent_names),
> -  parents[i]);
> + ret = match_string(cprman_parent_names, parents[i]);
>   if (ret >= 0)
>   parents[i] = cprman->real_parent_names[ret];
>   }
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 27d6f04ab58e..71e886869d78 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -279,7 +279,7 @@ static struct gpio_desc *of_find_regulator_gpio(struct 
> device *dev, const char *
>   if (!con_id)
>   return ERR_PTR(-ENOENT);
>  
> - i = __match_string(whitelist, ARRAY_SIZE(whitelist), con_id);
> + i = match_string(whitelist, con_id);
>   if (i < 0)
>   return ERR_PTR(-ENOENT);
>  
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index 286fad1f0e08..6fc4f3d3d1f6 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -449,7 +449,7 @@ display_crc_ctl_parse_source(const char *buf, enum 
> intel_pipe_crc_source *s)
>   return 0;
>   }
>  
> - i = __match_string(pipe_crc_sources, ARRAY_SIZE(pipe_crc_sources), buf);
> + i = match_string(pipe_crc_sources, buf);
>   if (i < 0)
>   return i;
>  
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 9aaacb5bdb26..53dff34c0afc 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -509,7 +509,7 @@ static int usbhs_omap_get_dt_pdata(struct device *dev,
>   continue;
>  
>   /* get 'enum usbhs_omap_port_mode' from port mode string */
> - ret = __match_string(port_modes, ARRAY_SIZE(port_modes), mode);
> + ret = match_string(port_modes, mode);
>   if (ret < 0) {
>   dev_warn(dev, "Invalid port%d-mode \"%s\" in device 
> tree\n",
>   i, mode);
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c 
> b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
> index 59ce3ff35553..778b4dfd8b75 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
> @@ -667,7 +667,7 @@ iwl_dbgfs_bt_force_ant_write(struct iwl_mvm *mvm, char 
> *buf,
>   };
>   int ret, bt_force_ant_mode;
>  
> - ret = __match_string(modes_str, ARRAY_SIZE(modes_str), buf);
> + ret = match_string(modes_str, buf);
>   if (ret < 0)
>   return ret;
>  
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 41a0773a1cbc..2278caba109c 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -203,7 +203,7 @@ void pcie_ecrc_get_policy(char *str)
>  {
>   int i;
>  
> - i = __match_string(ecrc_policy_str, ARRAY_SIZE(ecrc_policy_str), str);
> + i = match_string(ecrc_policy_str, str);
>   if (i < 0)
>   return;
>  
> diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> index bca0c404c6ca..5a651d311d38 100644
> --- a/drivers/usb/common/common.c
> +++ b

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

2019-05-09 Thread Bjorn Andersson

On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:

> On Wed, May 8, 2019 at 7:16 PM Brian Masney  wrote:
> >
> > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> > > > b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > [..]
> > > > +   clocks = <&mmcc MDSS_MDP_CLK>,
> > > > +<&mmcc MDSS_AHB_CLK>,
> > > > +<&mmcc MDSS_AXI_CLK>,
> > > > +<&mmcc MDSS_BYTE0_CLK>,
> > > > +<&mmcc MDSS_PCLK0_CLK>,
> > > > +<&mmcc MDSS_ESC0_CLK>,
> > > > +<&mmcc MMSS_MISC_AHB_CLK>;
> > > > +   clock-names = "mdp_core",
> > > > + "iface",
> > > > + "bus",
> > > > + "byte",
> > > > + "pixel",
> > > > + "core",
> > > > + "core_mmss";
> > >
> > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > > underrun error from DSI. You don't see anything like this?
> > >
> > > (These clocks are controlled by msm_bus downstream and should be driven
> > > by interconnect upstream)
> > >
> > >
> > > Apart from this, I think this looks nice. Happy to see the progress.
> >
> > No, I'm not seeing an underrun errors from the DSI. I think the clocks
> > are fine since I'm able to get this working with 4.17 using these same
> > clocks. I just sent out v2 and the cover letter has some details, along
> > with the full dmesg.
> 
> since we don't have interconnect driver for 8974, I guess there is
> some chance that things work or not based on how lk leaves things?
> 

Right, I guess the bootloader on my device does not leave the busses
ticking - perhaps there's a boot splash involved on Brian's device?

Regardless, this works on Nexus 5 and allows Brian to make further
progress so I'm all for merging it.

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

Re: [PATCH 09/16] mmc: sdhci-xenon: use new match_string() helper/macro

2019-05-09 Thread Ardelean, Alexandru

On Wed, 2019-05-08 at 15:20 +0300, Dan Carpenter wrote:
> 
> 
> On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
> > -static const char * const phy_types[] = {
> > - "emmc 5.0 phy",
> > - "emmc 5.1 phy"
> > -};
> > -
> >  enum xenon_phy_type_enum {
> >   EMMC_5_0_PHY,
> >   EMMC_5_1_PHY,
> >   NR_PHY_TYPES
> 
> There is no need for NR_PHY_TYPES now so you could remove that as well.
> 

I thought the same.
The only reason to keep NR_PHY_TYPES, is for potential future patches,
where it would be just 1 addition

 enum xenon_phy_type_enum {
  EMMC_5_0_PHY,
  EMMC_5_1_PHY,
+  EMMC_5_2_PHY,
  NR_PHY_TYPES
  }

Depending on style/preference of how to do enums (allow comma on last enum
or not allow comma on last enum value), adding new enum values woudl be 2
additions + 1 deletion lines.

 enum xenon_phy_type_enum {
  EMMC_5_0_PHY,
-  EMMC_5_1_PHY
+  EMM
C_5_1_PHY,
+  EMMC_5_2_PHY
 }

Either way (leave NR_PHY_TYPES or remove NR_PHY_TYPES) is fine from my
side.

Thanks
Alex

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

[PATCH 12/16] rdmacg: use new match_string() helper/macro