[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.
v2: (Rodrigo)
- Move the check to intel_psr_match_conditions
v3: (Rodrigo)
- add return false
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/intel_psr.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 05efd4e..fc32b04 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -433,6 +433,15 @@ static bool intel_psr_match_conditions(struct intel_dp
*intel_dp)
return false;
}
+ /*
+* FIXME:enable psr2 only for y-cordinate psr2 panels
+* After gtc implementation , remove this restriction.
+*/
+ if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
+ DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
coordinate\n");
+ return false;
+ }
+
dev_priv->psr.source_ok = true;
return true;
}
--
1.9.1
[Bug 99303] [REGRESSION][BISECTED] DMs are crashing on start with "radeon"
https://bugs.freedesktop.org/show_bug.cgi?id=99303 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Marek Olšák --- Fixed by aead6a1e947af84b0af2853c204d5cad6d92bfff. Closing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/0bbee6f4/attachment-0001.html>
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #47 from Marek Olšák --- The freezes are not caused by shader compilation. I don't know what's causing them. They are too long (even 10 seconds). A CPU profiler shows the time is not spent in the driver. It's spent in RocketLeague. The game is doing something and I can't see what, because it doesn't come with debug info. Some time is spent in sched_yield, which suggests that the game is in a loop waiting for something. This issue might not be related to the GL driver even. -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/55aa150c/attachment.html>
[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.
v2: (Rodrigo)
- Move the check to intel_psr_match_conditions
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/intel_psr.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 05efd4e..1729128 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -433,6 +433,15 @@ static bool intel_psr_match_conditions(struct intel_dp
*intel_dp)
return false;
}
+ /*
+* FIXME:enable psr2 only for y-cordinate psr2 panels
+* After gtc implementation , remove this restriction.
+*/
+ if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
+ DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
coordinate\n");
+ return;
+ }
+
dev_priv->psr.source_ok = true;
return true;
}
--
1.9.1
[Bug 99303] [REGRESSION][BISECTED] DMs are crashing on start with "radeon"
https://bugs.freedesktop.org/show_bug.cgi?id=99303 --- Comment #4 from Hi-Angel --- Thank you, worked for me too! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/80be984c/attachment.html>
[PATCH 09/10] drm/i915/psr: report live PSR2 State
Reports live state of PSR2 form PSR2_STATUS register.
bit field 31:28 gives the live state of PSR2.
It can be used to check if system is in deep sleep,
selective update or selective update standby.
During video play back, we can use this to check
if system is entering SU mode or not.
when system is in idle state, DEEP_SLEEP(8) must be entered.
When video playback is happening, system must be in
SLEEP(3 / selective update) or SU_STANDBY( 6 / selective update standby)
v2: (Rodrigo)
- Remove EDP_PSR2_STATUS_TG_ON=a ,instead use ARRAY_SIZE
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_debugfs.c | 24
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9d7b5a8..ec9013e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2606,6 +2606,30 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
+ if (dev_priv->psr.psr2_support) {
+ static const char * const live_status[] = {
+ "IDLE",
+ "CAPTURE",
+ "CAPTURE_FS",
+ "SLEEP",
+ "BUFON_FW",
+ "ML_UP",
+ "SU_STANDBY",
+ "FAST_SLEEP",
+ "DEEP_SLEEP",
+ "BUF_ON",
+ "TG_ON" };
+ u8 pos = (I915_READ(EDP_PSR2_STATUS_CTL) &
+ EDP_PSR2_STATUS_STATE_MASK) >>
+ EDP_PSR2_STATUS_STATE_SHIFT;
+
+ seq_printf(m, "PSR2_STATUS_EDP: %x\n",
+ I915_READ(EDP_PSR2_STATUS_CTL));
+
+ if (pos < ARRAY_SIZE(live_status))
+ seq_printf(m, "PSR2 live state %s\n",
+ live_status[pos]);
+ }
mutex_unlock(_priv->psr.lock);
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 272a283..65fffc5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3621,6 +3621,7 @@ enum {
#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+#define EDP_PSR2_STATUS_STATE_SHIFT28
/* VGA port control */
#define ADPA _MMIO(0x61100)
--
1.9.1
[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.
v2: (Rodrigo)
- Move the check to intel_psr_match_conditions
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/intel_psr.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 05efd4e..1729128 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -433,6 +433,15 @@ static bool intel_psr_match_conditions(struct intel_dp
*intel_dp)
return false;
}
+ /*
+* FIXME:enable psr2 only for y-cordinate psr2 panels
+* After gtc implementation , remove this restriction.
+*/
+ if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
+ DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
coordinate\n");
+ return;
+ }
+
dev_priv->psr.source_ok = true;
return true;
}
--
1.9.1
[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep
Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
should report value 8 , if system enters deep sleep state.
Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
flickering is observed on psr2 panel.
v2: (Ilia Mirkin)
- Remove duplicate bit definition 25:27
v3: rebase
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i915/i915_reg.h | 10 +++---
drivers/gpu/drm/i915/intel_psr.c | 22 --
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5ca506a..272a283 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3597,9 +3597,12 @@ enum {
#define EDP_PSR_PERF_CNT_MASK0xff
#define EDP_PSR_DEBUG_CTL _MMIO(dev_priv->psr_mmio_base + 0x60)
-#define EDP_PSR_DEBUG_MASK_LPSP (1<<27)
-#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
-#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
+#define EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
+#define EDP_PSR_DEBUG_MASK_LPSP (1<<27)
+#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
+#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
+#define EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1<<16)
+#define EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1<<15)
#define EDP_PSR2_CTL _MMIO(0x6f900)
#define EDP_PSR2_ENABLE (1<<31)
@@ -3614,6 +3617,7 @@ enum {
#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
#define EDP_PSR2_IDLE_MASK 0xf
+#define EDP_FRAMES_BEFORE_SU_ENTRY (1<<4)
#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index bcfe0db..05efd4e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -338,8 +338,9 @@ static void intel_enable_source_psr2(struct intel_dp
*intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
- val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
-
+ val |= EDP_PSR2_ENABLE |
+ EDP_SU_TRACK_ENABLE |
+ EDP_FRAMES_BEFORE_SU_ENTRY;
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
@@ -512,9 +513,26 @@ void intel_psr_enable(struct intel_dp *intel_dp)
/* Set CHICKEN_TRANS_BIT12 for programable header */
chicken_trans = chicken_trans | CHICKEN_TRANS_BIT12;
I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken_trans);
+ I915_WRITE(EDP_PSR_DEBUG_CTL,
+ EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP |
+ EDP_PSR_DEBUG_MASK_MAX_SLEEP |
+ EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
+ /*
+* Per Spec: Avoid continuous PSR exit by masking MEMUP
+* and HPD. also mask LPSP to avoid dependency on other
+* drivers that might block runtime_pm besides
+* preventing other hw tracking issues now we can rely
+* on frontbuffer tracking.
+*/
+ I915_WRITE(EDP_PSR_DEBUG_CTL,
+ EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP);
}
/*
* Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD.
--
1.9.1
[PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2
As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
must be programmed.
Enable bit 12 for programmable header packet.
Enable bit 15 for Y cordinate support.
v2: (Rodrigo)
- move CHICKEN_TRANS_EDP bit set logic right
after setup_vsc
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: vathsala nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_psr.c | 9 -
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7830e6e..5ca506a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6449,6 +6449,13 @@ enum {
#define BDW_DPRS_MASK_VBLANK_SRD (1 << 0)
#define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A,
_CHICKEN_PIPESL_1_B)
+#define CHICKEN_TRANS_A 0x420c0
+#define CHICKEN_TRANS_B 0x420c4
+#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
CHICKEN_TRANS_B)
+#define TRANS_EDP 3
+#define CHICKEN_TRANS_BIT12(1<<12)
+#define CHICKEN_TRANS_BIT15(1<<15)
+
#define DISP_ARB_CTL _MMIO(0x45000)
#define DISP_FBC_MEMORY_WAKE (1<<31)
#define DISP_TILE_SURFACE_SWIZZLING (1<<13)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 7020f42..bcfe0db 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -348,7 +348,6 @@ static void intel_enable_source_psr2(struct intel_dp
*intel_dp)
val |= EDP_PSR2_TP2_TIME_100;
else
val |= EDP_PSR2_TP2_TIME_50;
-
I915_WRITE(EDP_PSR2_CTL, val);
}
@@ -475,6 +474,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
+ uint32_t chicken_trans = 0;
if (!HAS_PSR(dev_priv)) {
DRM_DEBUG_KMS("PSR not supported on this platform\n");
@@ -505,6 +505,13 @@ void intel_psr_enable(struct intel_dp *intel_dp)
dev_priv->psr.psr2_support = false;
else
skl_psr_setup_su_vsc(intel_dp);
+
+ /* Set CHICKEN_TRANS_BIT15 if Y coordinate is supported
*/
+ if (dev_priv->psr.y_cord_support)
+ chicken_trans = CHICKEN_TRANS_BIT15;
+ /* Set CHICKEN_TRANS_BIT12 for programable header */
+ chicken_trans = chicken_trans | CHICKEN_TRANS_BIT12;
+ I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken_trans);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
--
1.9.1
[drm-tip:drm-tip 500/507] warning: (DRM_RADEON && ..) selects DRM_TTM which has unmet direct dependencies (HAS_IOMEM && ..)
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 88c0b7de9157d1f7824dee04d4ad04dbd9c802fb commit: 62a0d98a188cc4ebd8ea54b37d274ec20465e464 [500/507] drm: allow to use mmuless SoC config: sh-allyesconfig (attached as .config) compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 62a0d98a188cc4ebd8ea54b37d274ec20465e464 # save the attached .config to linux build tree make.cross ARCH=sh All warnings (new ones prefixed by >>): warning: (DRM_RADEON && DRM_AMDGPU && DRM_NOUVEAU && DRM_VMWGFX && DRM_GMA500 && DRM_AST && DRM_AST && DRM_MGAG200 && DRM_CIRRUS_QEMU && DRM_QXL && DRM_BOCHS && DRM_VIRTIO_GPU && DRM_HISI_HIBMC) selects DRM_TTM which has unmet direct dependencies (HAS_IOMEM && DRM && MMU) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 42837 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/378adde6/attachment-0001.gz>
[Bug 99303] [REGRESSION][BISECTED] DMs are crashing on start with "radeon"
https://bugs.freedesktop.org/show_bug.cgi?id=99303 --- Comment #3 from MWATTT --- This patch works for me (tried on glxgears). Thanks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/2a2eec31/attachment.html>
[Bug 99303] [REGRESSION][BISECTED] DMs are crashing on start with "radeon"
https://bugs.freedesktop.org/show_bug.cgi?id=99303 --- Comment #2 from Marek Olšák --- Created attachment 128802 --> https://bugs.freedesktop.org/attachment.cgi?id=128802=edit possible fix Would you please try this patch? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/1b52ff59/attachment.html>
[Bug 99307] [r600g, bisected] Segmentation fault in every application
https://bugs.freedesktop.org/show_bug.cgi?id=99307 Alex Deucher changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 99303 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/808c9b2c/attachment-0001.html>
[Bug 99303] [REGRESSION][BISECTED] DMs are crashing on start with "radeon"
https://bugs.freedesktop.org/show_bug.cgi?id=99303 Alex Deucher changed: What|Removed |Added CC||megwattt at gmail.com --- Comment #1 from Alex Deucher --- *** Bug 99307 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/16e0262b/attachment.html>
[Bug 99307] [r600g, bisected] Segmentation fault in every application
https://bugs.freedesktop.org/show_bug.cgi?id=99307 Bug ID: 99307 Summary: [r600g, bisected] Segmentation fault in every application Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: megwattt at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 128801 --> https://bugs.freedesktop.org/attachment.cgi?id=128801=edit Glxgears gdb output On my JUNIPER XT GPU, every OpenGL application will crash at the beginning. The commit which cause this problem is 9a3296bf1cf8d45349b14b31eeb0d81f8b8774fc : radeonsi: use SDMA for initial clearing of DCC/CMASK/HTILE on CIK-VI. I have attached the output when glxgears is debugged with gdb. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/87804bfa/attachment.html>
nouveau: display freezing
Hei, 839ca903f12e (drm/nouveau/kms/nv50: transition to atomic interfaces internally, 2016-11-04) seems to introduce a regression on my machine. Attached dmesg output. Has anyone else seen this on a MacBookPro? Thanks. -- Mit freundlichen GrüÃen Alexander Alemayhu -- next part -- [0.00] microcode: microcode updated early to revision 0x16, date = 2016-04-01 [0.00] Linux version 4.10.0-rc2 (scanf at hafza) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Wed Jan 4 20:16:20 CET 2017 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.10.0-rc2 root=/dev/mapper/fedora_hafza-root ro rd.lvm.lv=fedora_hafza/root rd.lvm.lv=fedora_hafza/swap rhgb quiet intel_pstate=support_acpi_ppc [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0008efff] usable [0.00] BIOS-e820: [mem 0x0008f000-0x0008] reserved [0.00] BIOS-e820: [mem 0x0009-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000b] reserved [0.00] BIOS-e820: [mem 0x0010-0x7ad13fff] usable [0.00] BIOS-e820: [mem 0x7ad14000-0x7ad52fff] ACPI NVS [0.00] BIOS-e820: [mem 0x7ad53000-0x7ad5efff] usable [0.00] BIOS-e820: [mem 0x7ad5f000-0x7ad8efff] ACPI data [0.00] BIOS-e820: [mem 0x7ad8f000-0x7ae38fff] usable [0.00] BIOS-e820: [mem 0x7ae39000-0x7ae8efff] reserved [0.00] BIOS-e820: [mem 0x7ae8f000-0x7aec] usable [0.00] BIOS-e820: [mem 0x7aed-0x7aefefff] reserved [0.00] BIOS-e820: [mem 0x7aeff000-0x7af7afff] usable [0.00] BIOS-e820: [mem 0x7af7b000-0x7afe4fff] reserved [0.00] BIOS-e820: [mem 0x7afe5000-0x7aff] usable [0.00] BIOS-e820: [mem 0x7b00-0x7f9f] reserved [0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xffe1-0xffe3] reserved [0.00] BIOS-e820: [mem 0x0001-0x00047f5f] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x77d00190-0x77d167cf] usable ==> usable [0.00] e820: update [mem 0x77cfe190-0x77cff04e] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x00057fff] usable [0.00] reserve setup_data: [mem 0x00058000-0x00058fff] reserved [0.00] reserve setup_data: [mem 0x00059000-0x0008efff] usable [0.00] reserve setup_data: [mem 0x0008f000-0x0008] reserved [0.00] reserve setup_data: [mem 0x0009-0x0009] usable [0.00] reserve setup_data: [mem 0x000a-0x000b] reserved [0.00] reserve setup_data: [mem 0x0010-0x77cfe18f] usable [0.00] reserve setup_data: [mem 0x77cfe190-0x77cff04e] usable [0.00] reserve setup_data: [mem 0x77cff04f-0x77d0018f] usable [0.00] reserve setup_data: [mem 0x77d00190-0x77d167cf] usable [0.00] reserve setup_data: [mem 0x77d167d0-0x7ad13fff] usable [0.00] reserve setup_data: [mem 0x7ad14000-0x7ad52fff] ACPI NVS [0.00] reserve setup_data: [mem 0x7ad53000-0x7ad5efff] usable [0.00] reserve setup_data: [mem 0x7ad5f000-0x7ad8efff] ACPI data [0.00] reserve setup_data: [mem 0x7ad8f000-0x7ae38fff] usable [0.00] reserve setup_data: [mem 0x7ae39000-0x7ae8efff] reserved [0.00] reserve setup_data: [mem 0x7ae8f000-0x7aec] usable [0.00] reserve setup_data: [mem 0x7aed-0x7aefefff] reserved [0.00] reserve setup_data: [mem 0x7aeff000-0x7af7afff] usable [0.00] reserve setup_data: [mem 0x7af7b000-0x7afe4fff] reserved [0.00] reserve setup_data: [mem
[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
On Fri, 2017-01-06 at 17:55 +, Nagaraju, Vathsala wrote:
> 1) I am still not able to get psr1 working on y-cordinate panels. Only psr2
> works.
> 2) I haven't got a GTC panel to test this scenario. Once we test psr1 on psr2
> GTC panel, we could add dev_priv->psr.psr2_support = false; till GTC is
> implemented.
Agree!
Reviewed-by: Rodrigo Vivi
>
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Friday, January 6, 2017 11:08 PM
> To: Nagaraju, Vathsala
> Cc: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org;
> jim.bride at linux.intel.com; Patil, Deepti
> Subject: Re: [PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
>
> I was going to write the rv-b,
> but something came to my mind...
>
> In this case where y_cord_support but we don't have gtc yet, couldn't we
> enable PSR1 instead?
> in this case instead of return false we would do dev_priv->psr.psr2_support =
> false;
>
> what do you think/advise?
>
> On Fri, 2017-01-06 at 23:01 +0530, vathsala nagaraju wrote:
> > Psr2 is enabled only for y cordinate panels.Once GTC (global time
> > code) is implemented,this restriction is removed so that psr2 can work
> > on panels without y cordinate support.
> >
> > v2: (Rodrigo)
> > - Move the check to intel_psr_match_conditions
> >
> > v3: (Rodrigo)
> > - add return false
> >
> > Cc: Rodrigo Vivi
> > Cc: Jim Bride
> > Signed-off-by: Vathsala Nagaraju
> > Signed-off-by: Patil Deepti
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 05efd4e..fc32b04 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -433,6 +433,15 @@ static bool intel_psr_match_conditions(struct intel_dp
> > *intel_dp)
> > return false;
> > }
> >
> > + /*
> > +* FIXME:enable psr2 only for y-cordinate psr2 panels
> > +* After gtc implementation , remove this restriction.
> > +*/
> > + if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
> > + DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
> > coordinate\n");
> > + return false;
> > + }
> > +
> > dev_priv->psr.source_ok = true;
> > return true;
> > }
>
[PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2
On Sat, 2017-01-07 at 00:28 +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
> must be programmed.
> Enable bit 12 for programmable header packet.
> Enable bit 15 for Y cordinate support.
>
> v2: (Rodrigo)
> - move CHICKEN_TRANS_EDP bit set logic right after setup_vsc
>
> v3:(Rodrigo)
> - initialize chicken_trans to CHICKEN_TRANS_BIT12 instead of 0
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: vathsala nagaraju
> Signed-off-by: Patil Deepti
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> drivers/gpu/drm/i915/intel_psr.c | 6 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7830e6e..5ca506a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6449,6 +6449,13 @@ enum {
> #define BDW_DPRS_MASK_VBLANK_SRD(1 << 0)
> #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A,
> _CHICKEN_PIPESL_1_B)
>
> +#define CHICKEN_TRANS_A 0x420c0
> +#define CHICKEN_TRANS_B 0x420c4
> +#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
> CHICKEN_TRANS_B)
> +#define TRANS_EDP 3
> +#define CHICKEN_TRANS_BIT12(1<<12)
> +#define CHICKEN_TRANS_BIT15(1<<15)
> +
> #define DISP_ARB_CTL _MMIO(0x45000)
> #define DISP_FBC_MEMORY_WAKE(1<<31)
> #define DISP_TILE_SURFACE_SWIZZLING (1<<13)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 7020f42..7573c2f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -475,6 +475,8 @@ void intel_psr_enable(struct intel_dp *intel_dp)
> struct drm_device *dev = intel_dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
> + /* Set CHICKEN_TRANS_BIT12 for programable header */
> + uint32_t chicken_trans = CHICKEN_TRANS_BIT12;
+ uint32_t chicken_trans;
>
> if (!HAS_PSR(dev_priv)) {
> DRM_DEBUG_KMS("PSR not supported on this platform\n");
> @@ -505,6 +507,10 @@ void intel_psr_enable(struct intel_dp *intel_dp)
> dev_priv->psr.psr2_support = false;
> else
> skl_psr_setup_su_vsc(intel_dp);
+
+ /* Set CHICKEN_TRANS_BIT12 for programable header */
+ chicken_trans = CHICKEN_TRANS_BIT12;
> + /* Set CHICKEN_TRANS_BIT15 if Y coordinate is supported
> */
> + if (dev_priv->psr.y_cord_support)
> + chicken_trans |= CHICKEN_TRANS_BIT15;
> + I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken_trans);
> } else {
> /* set up vsc header for psr1 */
> hsw_psr_setup_vsc(intel_dp);
Enabling peer to peer device transactions for PCIe devices
> -Original Message- > From: Jason Gunthorpe [mailto:jgunthorpe at obsidianresearch.com] > Sent: Friday, January 06, 2017 1:26 PM > To: Jerome Glisse > Cc: Sagalovitch, Serguei; Jerome Glisse; Deucher, Alexander; 'linux- > kernel at vger.kernel.org'; 'linux-rdma at vger.kernel.org'; 'linux- > nvdimm at lists.01.org'; 'Linux-media at vger.kernel.org'; 'dri- > devel at lists.freedesktop.org'; 'linux-pci at vger.kernel.org'; Kuehling, > Felix; > Blinzer, Paul; Koenig, Christian; Suthikulpanit, Suravee; Sander, Ben; > hch at infradead.org; Zhou, David(ChunMing); Yu, Qiang > Subject: Re: Enabling peer to peer device transactions for PCIe devices > > On Fri, Jan 06, 2017 at 12:37:22PM -0500, Jerome Glisse wrote: > > On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote: > > > On 2017-01-05 08:58 PM, Jerome Glisse wrote: > > > > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote: > > > > > On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote: > > > > > > > > > > > > I still don't understand what you driving at - you've said in both > > > > > > > cases a user VMA exists. > > > > > > In the former case no, there is no VMA directly but if you want one > than > > > > > > a device can provide one. But such VMA is useless as CPU access is > not > > > > > > expected. > > > > > I disagree it is useless, the VMA is going to be necessary to support > > > > > upcoming things like CAPI, you need it to support O_DIRECT from the > > > > > filesystem, DPDK, etc. This is why I am opposed to any model that is > > > > > not VMA based for setting up RDMA - that is shorted sighted and > does > > > > > not seem to reflect where the industry is going. > > > > > > > > > > So focus on having VMA backed by actual physical memory that > covers > > > > > your GPU objects and ask how do we wire up the '__user *' to the > DMA > > > > > API in the best way so the DMA API still has enough information to > > > > > setup IOMMUs and whatnot. > > > > I am talking about 2 different thing. Existing hardware and API where > you > > > > _do not_ have a vma and you do not need one. This is just > > > > > existing stuff. > > > > I do not understand why you assume that existing API doesn't need one. > > > I would say that a lot of __existing__ user level API and their support in > > > kernel (especially outside of graphics domain) assumes that we have vma > and > > > deal with __user * pointers. > > +1 > > > Well i am thinking to GPUDirect here. Some of GPUDirect use case do not > have > > vma (struct vm_area_struct) associated with them they directly apply to > GPU > > object that aren't expose to CPU. Yes some use case have vma for share > buffer. > > Lets stop talkind about GPU direct. Today we can't even make VMA > pointing at a PCI bar work properly in the kernel - lets start there > please. People can argue over other options once that is done. > > > For HMM plan is to restrict to ODP and either to replace ODP with HMM or > change > > ODP to not use get_user_pages_remote() but directly fetch informations > from > > CPU page table. Everything else stay as it is. I posted patchset to replace > > ODP with HMM in the past. > > Make a generic API for all of this and you'd have my vote.. > > IMHO, you must support basic pinning semantics - that is necessary to > support generic short lived DMA (eg filesystem, etc). That hardware > can clearly do that if it can support ODP. We would definitely like to have support for hardware that can't handle page faults gracefully. Alex
[PATCH] drm: Change the return type of the unload hook to void
Am 06.01.2017 um 18:57 schrieb Gabriel Krisman Bertazi:
> The integer returned by the unload hook is ignored by the drm core, so
> let's make it void.
>
> This patch was created using the following Coccinelle semantic script
> (except for the declaration and comment in drm_drv.h):
>
> Compile-tested only.
>
> //
> @ get_name @
> struct drm_driver drv;
> identifier fn;
> @@
> drv.unload = fn;
>
> @ replace_type @
> identifier get_name.fn;
> @@
> - int
> + void
> fn (...)
> {
> ...
> }
>
> @ remove_return_param @
> identifier get_name.fn;
> @@
> void fn (...)
> {
> <...
> if (...)
> return
> - ...
> ;
> ...>
> }
>
> @ drop_final_return @
> identifier get_name.fn;
> @@
> void fn (...)
> {
> ...
>
> - return 0;
> }
> //
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Gabriel Krisman Bertazi
Acked-by: Christian König .
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 ++---
> drivers/gpu/drm/ast/ast_drv.h | 2 +-
> drivers/gpu/drm/ast/ast_main.c| 3 +--
> drivers/gpu/drm/bochs/bochs_drv.c | 3 +--
> drivers/gpu/drm/cirrus/cirrus_drv.h | 2 +-
> drivers/gpu/drm/cirrus/cirrus_main.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 +---
> drivers/gpu/drm/gma500/psb_drv.c | 3 +--
> drivers/gpu/drm/mga/mga_dma.c | 4 +---
> drivers/gpu/drm/mga/mga_drv.h | 2 +-
> drivers/gpu/drm/mgag200/mgag200_drv.h | 2 +-
> drivers/gpu/drm/mgag200/mgag200_main.c| 5 ++---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +--
> drivers/gpu/drm/omapdrm/omap_drv.c| 4 +---
> drivers/gpu/drm/qxl/qxl_drv.h | 2 +-
> drivers/gpu/drm/qxl/qxl_kms.c | 5 ++---
> drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
> drivers/gpu/drm/radeon/radeon_kms.c | 5 ++---
> drivers/gpu/drm/savage/savage_bci.c | 4 +---
> drivers/gpu/drm/savage/savage_drv.h | 2 +-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
> drivers/gpu/drm/sis/sis_drv.c | 4 +---
> drivers/gpu/drm/tegra/drm.c | 6 ++
> drivers/gpu/drm/udl/udl_drv.h | 2 +-
> drivers/gpu/drm/udl/udl_main.c| 3 +--
> drivers/gpu/drm/via/via_drv.h | 2 +-
> drivers/gpu/drm/via/via_map.c | 4 +---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
> drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +---
> include/drm/drm_drv.h | 5 +
> 33 files changed, 39 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 54ac8a845e9f..7077ed65d403 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1711,7 +1711,7 @@ extern const struct drm_ioctl_desc amdgpu_ioctls_kms[];
> extern const int amdgpu_max_kms_ioctl;
>
> int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags);
> -int amdgpu_driver_unload_kms(struct drm_device *dev);
> +void amdgpu_driver_unload_kms(struct drm_device *dev);
> void amdgpu_driver_lastclose_kms(struct drm_device *dev);
> int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file
> *file_priv);
> void amdgpu_driver_postclose_kms(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 9af87eaf8ee3..8aef2582 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -50,12 +50,12 @@ static inline bool amdgpu_has_atpx(void) { return false; }
>* This is the main unload function for KMS (all asics).
>* Returns 0 on success.
>*/
> -int amdgpu_driver_unload_kms(struct drm_device *dev)
> +void amdgpu_driver_unload_kms(struct drm_device *dev)
> {
> struct amdgpu_device *adev = dev->dev_private;
>
> if (adev == NULL)
> - return 0;
> + return;
>
> if (adev->rmmio == NULL)
> goto done_free;
> @@ -74,7 +74,6 @@ int amdgpu_driver_unload_kms(struct drm_device *dev)
> done_free:
> kfree(adev);
> dev->dev_private = NULL;
> - return 0;
> }
>
> /**
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 6f3b6f50cf52..1051181d8c0d 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -122,7 +122,7 @@ struct ast_private {
> };
>
> int ast_driver_load(struct drm_device *dev, unsigned long flags);
> -int ast_driver_unload(struct drm_device *dev);
> +void ast_driver_unload(struct drm_device *dev);
>
> struct ast_gem_object;
>
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index d85af0ff2653..5b59888426cf 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++
[Bug 191571] AMD APU R4 hangs during hibernation - regression
https://bugzilla.kernel.org/show_bug.cgi?id=191571 --- Comment #5 from Przemek --- I can confirm that this commit is makeing problems on A6 6310 APU. I have compiled kernel 4.9 with reversed patch [274ad65c9d02bdcbee9bae045517864c3521d530] and I can hibernate without problems. Moreover I have checked UVD hardware acceleration of h264 codec in mplayer's vdpau option and it is working correctly. I have an accelerated playback with ffmpeg12vdpau codec after resume from hibernate. So maby forcing A6 GPU - r4 Mullins/Beema to hard reset when wakeing up from hibernate state isn't necessarily mandatory. I am also wondering, (cause of the experimentary support of CIK GPU's in amdgpu driver as in the future GPU's from Sea Island and Southern Island families support would be implemented in amdgpu) if there is similar patch commited to amdgpu and if so I am aware that it could also affect the hibernate process on A6 6310 APU. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 99303] [REGRESSION][BISECTED] DMs are crashing on start with "radeon"
https://bugs.freedesktop.org/show_bug.cgi?id=99303 Bug ID: 99303 Summary: [REGRESSION][BISECTED] DMs are crashing on start with "radeon" Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: Hi-Angel at yandex.ru QA Contact: dri-devel at lists.freedesktop.org As of the commit 9a3296bf1cf8d45349b14b31eeb0d81f8b8774fc radeonsi: use SDMA for initial clearing of DCC/CMASK/HTILE on CIK-VI , SDDM crashes on start. The same with GDM, though I bisect-tested mostly with SDDM. The system log says: systemd[1]: Started User Manager for UID 996. sddm[513]: Greeter session started successfully sddm-greeter[584]: Reading from "/usr/share/xsessions/awesome.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/enlightenment.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/gnome-classic.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/gnome-xorg.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/gnome.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/i3-with-shmlog.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/i3.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/plasma-mediacenter.desktop" sddm-greeter[584]: Reading from "/usr/share/xsessions/plasma.desktop" sddm-greeter[584]: Reading from "/usr/share/wayland-sessions/gnome.desktop" sddm-greeter[584]: Reading from "/usr/share/wayland-sessions/sway.desktop" sddm-greeter[584]: Connected to the daemon. sddm[513]: Message received from greeter: Connect sddm-greeter[584]: Loading qrc:/theme/Main.qml... sddm-greeter[584]: Adding view for "HDMI-0" QRect(0,0 1920x1080) systemd[577]: Started D-Bus User Message Bus. sddm-greeter[584]: Message received from daemon: Capabilities sddm-greeter[584]: Message received from daemon: HostName kernel: sddm-greeter[584]: segfault at 0 ip (null) sp 7fffbb3c12e8 error 14 in sddm-greeter[40+8e000] systemd[1]: Created slice system-systemd\x2dcoredump.slice. systemd[1]: Started Process Core Dump (PID 593/UID 0). sddm-helper[575]: [PAM] Closing session sddm-helper[575]: pam_unix(sddm-greeter:session): session closed for user sddm sddm-helper[575]: [PAM] Ended. sddm[513]: Auth: sddm-helper exited with 11 sddm[513]: Greeter stopped. systemd-logind[481]: Removed session c1. systemd[1]: Stopping User Manager for UID 996... systemd[577]: Stopped target Default. systemd[577]: Stopping D-Bus User Message Bus... systemd[577]: Stopped D-Bus User Message Bus. systemd[577]: Stopped target Basic System. systemd[577]: Stopped target Paths. systemd[577]: Stopped target Timers. systemd[577]: Stopped target Sockets. systemd[577]: Closed Sound System. systemd[577]: Closed D-Bus User Message Bus Socket. systemd[577]: Reached target Shutdown. systemd[577]: Starting Exit the Session... systemd[577]: Received SIGRTMIN+24 from PID 597 (kill). systemd[578]: pam_unix(systemd-user:session): session closed for user sddm systemd[1]: Stopped User Manager for UID 996. systemd[1]: Removed slice User Slice of sddm. systemd-coredump[594]: Process 584 (sddm-greeter) of user 996 dumped core. Stack trace of thread 584: #0 0x n/a (n/a) GPU: Radeon HD5730 (note, its driver is rather radeon than radeonsi) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/999c9ab9/attachment-0001.html>
[pull] radeon and amdgpu drm-fixes-4.10
Hi Dave, Fixes for 4.10: - Polaris 12 support - Add new amd-gfx mailing list to MAINTAINERS file - UVD clockgating fix - SI dpm fixes The following changes since commit 4a401ceeef7bf3bc55f5e913cbf19d6038cf83c6: Merge tag 'drm-intel-next-fixes-2016-12-22' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2016-12-23 05:28:02 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.10 for you to fetch changes up to 7192c54a68013f6058b1bb505645fcd07015191c: drm/amdgpu: drop verde dpm quirks (2017-01-06 17:43:38 -0500) Alex Deucher (4): MAINTAINERS: Update mailing list for radeon and amdgpu drm/radeon: update smc firmware selection for SI drm/radeon: drop verde dpm quirks drm/amdgpu: drop verde dpm quirks Flora Cui (1): drm/amdgpu: update si kicker smc firmware Junwei Zhang (3): drm/amd/amdgpu: add Polaris12 support (v3) drm/amdgpu/powerplay: add Polaris12 support drm/amd/amdgpu: add Polaris12 PCI ID Rex Zhu (1): drm/amd/powerplay: extend smu's response timeout time. Yintian Tao (1): drm/amdgpu: remove static integer for uvd pp state MAINTAINERS| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 7 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 5 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 5 ++ drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 13 +++- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 31 -- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 5 ++ drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 6 ++ drivers/gpu/drm/amd/amdgpu/si_dpm.c| 70 +- drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c | 5 -- drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/vi.c| 10 drivers/gpu/drm/amd/include/amd_shared.h | 3 +- drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 3 +- .../gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c | 2 +- drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 1 + drivers/gpu/drm/radeon/si.c| 60 +-- drivers/gpu/drm/radeon/si_dpm.c| 13 21 files changed, 146 insertions(+), 106 deletions(-)
[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
1) I am still not able to get psr1 working on y-cordinate panels. Only psr2
works.
2) I haven't got a GTC panel to test this scenario. Once we test psr1 on psr2
GTC panel, we could add dev_priv->psr.psr2_support = false; till GTC is
implemented.
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, January 6, 2017 11:08 PM
To: Nagaraju, Vathsala
Cc: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org;
jim.bride at linux.intel.com; Patil, Deepti
Subject: Re: [PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
I was going to write the rv-b,
but something came to my mind...
In this case where y_cord_support but we don't have gtc yet, couldn't we enable
PSR1 instead?
in this case instead of return false we would do dev_priv->psr.psr2_support =
false;
what do you think/advise?
On Fri, 2017-01-06 at 23:01 +0530, vathsala nagaraju wrote:
> Psr2 is enabled only for y cordinate panels.Once GTC (global time
> code) is implemented,this restriction is removed so that psr2 can work
> on panels without y cordinate support.
>
> v2: (Rodrigo)
> - Move the check to intel_psr_match_conditions
>
> v3: (Rodrigo)
> - add return false
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: Vathsala Nagaraju
> Signed-off-by: Patil Deepti
> ---
> drivers/gpu/drm/i915/intel_psr.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 05efd4e..fc32b04 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -433,6 +433,15 @@ static bool intel_psr_match_conditions(struct intel_dp
> *intel_dp)
> return false;
> }
>
> + /*
> + * FIXME:enable psr2 only for y-cordinate psr2 panels
> + * After gtc implementation , remove this restriction.
> + */
> + if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
> + DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
> coordinate\n");
> + return false;
> + }
> +
> dev_priv->psr.source_ok = true;
> return true;
> }
[PATCH 2/2] drm: get fbdev size from cmdline if no connector found
In case no connector is found while creating the fbdev, gives the
possibility to specify the default fbdev size by firstly checking if the
command line is defining a preferred mode. Else go into fallback and set
1024x768 fbdev size as it was already done.
Cc: Tomi Valkeinen
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/drm_fb_helper.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 77d9ac6..115c265 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1522,6 +1522,7 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
}
crtc_count = 0;
+
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
struct drm_mode_set *mode_set;
@@ -1566,11 +1567,32 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
}
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
- /* hmm everyone went away - assume VGA cable just fell out
- and will come back later. */
- DRM_INFO("Cannot find any crtc or sizes - going 1024x768\n");
- sizes.fb_width = sizes.surface_width = 1024;
- sizes.fb_height = sizes.surface_height = 768;
+ struct drm_display_mode *mode = NULL;
+ /* hmm everyone went away - assume cable just fell out and will
+* come back later.
+* Get fb size from command line mode (if existing) else fb size
+* is set to 1024x768
+*/
+ for (i = 0; i < fb_helper->connector_count; i++) {
+ struct drm_fb_helper_connector *fb_helper_conn;
+
+ fb_helper_conn = fb_helper->connector_info[i];
+ mode = drm_pick_cmdline_mode(fb_helper_conn);
+ }
+
+ if (mode) {
+ sizes.fb_width = mode->hdisplay;
+ sizes.fb_height = mode->vdisplay;
+ DRM_INFO("Cannot find any crtc or sizes - use cmdline
%dx%d\n",
+sizes.fb_width, sizes.fb_height);
+ } else {
+ sizes.fb_width = 1024;
+ sizes.fb_height = 768;
+ DRM_INFO("Cannot find any crtc or sizes - going
1024x768\n");
+ }
+
+ sizes.surface_width = sizes.fb_width;
+ sizes.surface_height = sizes.fb_height;
}
/* push down into drivers */
--
2.7.4
[PATCH 1/2] drm: remove useless parameters from drm_pick_cmdline_mode function
drm_pick_cmdline_mode width and height parameters are useless.
Just remove them.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/drm_fb_helper.c| 7 +++
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
include/drm/drm_fb_helper.h| 3 +--
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e934b54..77d9ac6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1748,8 +1748,7 @@ static bool drm_has_cmdline_mode(struct
drm_fb_helper_connector *fb_connector)
return fb_connector->connector->cmdline_mode.specified;
}
-struct drm_display_mode *drm_pick_cmdline_mode(struct drm_fb_helper_connector
*fb_helper_conn,
- int width, int height)
+struct drm_display_mode *drm_pick_cmdline_mode(struct drm_fb_helper_connector
*fb_helper_conn)
{
struct drm_cmdline_mode *cmdline_mode;
struct drm_display_mode *mode;
@@ -1867,7 +1866,7 @@ static bool drm_target_cloned(struct drm_fb_helper
*fb_helper,
if (!enabled[i])
continue;
fb_helper_conn = fb_helper->connector_info[i];
- modes[i] = drm_pick_cmdline_mode(fb_helper_conn, width, height);
+ modes[i] = drm_pick_cmdline_mode(fb_helper_conn);
if (!modes[i]) {
can_clone = false;
break;
@@ -1989,7 +1988,7 @@ static bool drm_target_preferred(struct drm_fb_helper
*fb_helper,
fb_helper_conn->connector->base.id);
/* got for command line mode first */
- modes[i] = drm_pick_cmdline_mode(fb_helper_conn, width, height);
+ modes[i] = drm_pick_cmdline_mode(fb_helper_conn);
if (!modes[i]) {
DRM_DEBUG_KMS("looking for preferred mode on connector
%d %d\n",
fb_helper_conn->connector->base.id,
fb_helper_conn->connector->tile_group ?
fb_helper_conn->connector->tile_group->id : 0);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index beb0898..4b302f8 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -447,7 +447,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
connector->name);
/* go for command line mode first */
- modes[i] = drm_pick_cmdline_mode(fb_conn, width, height);
+ modes[i] = drm_pick_cmdline_mode(fb_conn);
/* try for preferred next */
if (!modes[i]) {
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 975deed..48e09e8 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -295,8 +295,7 @@ struct drm_display_mode *
drm_has_preferred_mode(struct drm_fb_helper_connector *fb_connector,
int width, int height);
struct drm_display_mode *
-drm_pick_cmdline_mode(struct drm_fb_helper_connector *fb_helper_conn,
- int width, int height);
+drm_pick_cmdline_mode(struct drm_fb_helper_connector *fb_helper_conn);
int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector);
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
--
2.7.4
[PATCH 0/2] get fbdev size from cmdline if no connector found
In case no connector is found while creating the fbdev, gives the possibility to specify the default fbdev size by firstly checking if the command line is defining a preferred mode. Else go into fallback and set 1024x768 fbdev size as it was already done. It is usefull in case you forgot to plug your connector cable but you want your fbdev to have the size you have defined in the command line. Then when you plug your connector cable, the fbdev will match your display size. In case no command line is specified, the 1024x768 fbdev resolution is keept as default fbdev resolution. Vincent Abriou (2): drm: remove useless parameters from drm_pick_cmdline_mode function drm: get fbdev size from cmdline mode if it exists. drivers/gpu/drm/drm_fb_helper.c| 39 +- drivers/gpu/drm/i915/intel_fbdev.c | 2 +- include/drm/drm_fb_helper.h| 3 +-- 3 files changed, 32 insertions(+), 12 deletions(-) -- 2.7.4
[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
I was going to write the rv-b,
but something came to my mind...
In this case where y_cord_support but we don't have gtc yet, couldn't we
enable PSR1 instead?
in this case instead of return false we would do
dev_priv->psr.psr2_support = false;
what do you think/advise?
On Fri, 2017-01-06 at 23:01 +0530, vathsala nagaraju wrote:
> Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
> is implemented,this restriction is removed so that psr2
> can work on panels without y cordinate support.
>
> v2: (Rodrigo)
> - Move the check to intel_psr_match_conditions
>
> v3: (Rodrigo)
> - add return false
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: Vathsala Nagaraju
> Signed-off-by: Patil Deepti
> ---
> drivers/gpu/drm/i915/intel_psr.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 05efd4e..fc32b04 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -433,6 +433,15 @@ static bool intel_psr_match_conditions(struct intel_dp
> *intel_dp)
> return false;
> }
>
> + /*
> + * FIXME:enable psr2 only for y-cordinate psr2 panels
> + * After gtc implementation , remove this restriction.
> + */
> + if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
> + DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
> coordinate\n");
> + return false;
> + }
> +
> dev_priv->psr.source_ok = true;
> return true;
> }
[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
2017ë
01ì 06ì¼ 17:18ì Andi Shyti ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> Thanks for the reply, but...
>
+static const struct drm_display_mode default_mode = {
+ .clock = 222372,
+ .hdisplay = 1440,
+ .hsync_start = 1440 + 1,
+ .hsync_end = 1440 + 1 + 1,
+ .htotal = 1440 + 1 + 1 + 1,
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 1,
+ .vsync_end = 2560 + 1 + 1,
+ .vtotal = 2560 + 1 + 1 + 15,
+ .vrefresh = 60,
+ .flags = 0,
+};
>>>
>>> how is this working with tm2e? Are these values valid for both
>>> the boards?
>>
>> We don't need to consider tm2e board with two reasones,
>> 1. there is no tm2e board support in mainline
>> 2. the panel on tm2 would be a little bit different from one on tm2e
>
> ... this display in the Tizen Kernel is supported by both:
> tm2 [1] and tm2e [2]. The only differences are:
Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :(
>
> TM2:
>clock-frequency = <1487>;
>hactive = <1440>;
>
> TM2E:
>clock-frequency = <16523724>;
>hactive = <1600>;
>
> I don't know much about the differences you mention in point 2,
> but it's a pity to drop support only because we don't want to put
> in the dts the 'hactive', and 'clock-frequency' properties.
Anyway, tm2e board is already in mainline so Panel driver may need to identify
what kinds of panel is probed to decide porch values. I think there are
relevant registers in MCU of the Panel device to check version or similar thing.
Thanks.
>
> Andi
>
> [1]
> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
> [2]
> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
[Bug 95306] Random Blank(black) screens on "Carrizo"
https://bugs.freedesktop.org/show_bug.cgi?id=95306 --- Comment #42 from cyrwyn --- I had already removed vga=788 from command line. It makes no difference. It was meant just to set the display resolution for grub before the kernel boots. However, grub2 now requires other instructions. New info to report. I reinstalled amdgpu and created the xorg.conf file. This was the first time that the installer (XFdrake) reported the resolution correctly and I didn't have to manually configure it. Now I get a randomly flashing screen and still no keyboard input. Before, it was a blank screen with the backlight on, now the light is on/off irregularly every few seconds. I'm not sure this is progress, but perhaps it is a clue for someone who knows the driver well. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/639dad3d/attachment.html>
[PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2
On Fri, 2017-01-06 at 21:59 +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
> must be programmed.
> Enable bit 12 for programmable header packet.
> Enable bit 15 for Y cordinate support.
>
> v2: (Rodrigo)
> - move CHICKEN_TRANS_EDP bit set logic right
> after setup_vsc
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: vathsala nagaraju
> Signed-off-by: Patil Deepti
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> drivers/gpu/drm/i915/intel_psr.c | 9 -
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7830e6e..5ca506a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6449,6 +6449,13 @@ enum {
> #define BDW_DPRS_MASK_VBLANK_SRD(1 << 0)
> #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A,
> _CHICKEN_PIPESL_1_B)
>
> +#define CHICKEN_TRANS_A 0x420c0
> +#define CHICKEN_TRANS_B 0x420c4
> +#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
> CHICKEN_TRANS_B)
> +#define TRANS_EDP 3
> +#define CHICKEN_TRANS_BIT12(1<<12)
> +#define CHICKEN_TRANS_BIT15(1<<15)
> +
> #define DISP_ARB_CTL _MMIO(0x45000)
> #define DISP_FBC_MEMORY_WAKE(1<<31)
> #define DISP_TILE_SURFACE_SWIZZLING (1<<13)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 7020f42..bcfe0db 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -348,7 +348,6 @@ static void intel_enable_source_psr2(struct intel_dp
> *intel_dp)
> val |= EDP_PSR2_TP2_TIME_100;
> else
> val |= EDP_PSR2_TP2_TIME_50;
> -
I'm afraid you missed this space here and removed one extra line.
> I915_WRITE(EDP_PSR2_CTL, val);
> }
>
> @@ -475,6 +474,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
> struct drm_device *dev = intel_dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
> + uint32_t chicken_trans = 0;
what about invert the order below so you don't need to initialize this
as 0 here.
chicken_trans = CHICKEN_TRANS_BIT12;
if (dev_priv->psr.y_cord_support)
chicken_trans |= CHICKEN_TRANS_BIT15;
>
> if (!HAS_PSR(dev_priv)) {
> DRM_DEBUG_KMS("PSR not supported on this platform\n");
> @@ -505,6 +505,13 @@ void intel_psr_enable(struct intel_dp *intel_dp)
> dev_priv->psr.psr2_support = false;
> else
> skl_psr_setup_su_vsc(intel_dp);
> +
> + /* Set CHICKEN_TRANS_BIT15 if Y coordinate is supported
> */
> + if (dev_priv->psr.y_cord_support)
> + chicken_trans = CHICKEN_TRANS_BIT15;
> + /* Set CHICKEN_TRANS_BIT12 for programable header */
> + chicken_trans = chicken_trans | CHICKEN_TRANS_BIT12;
or at least use |= here...
> + I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken_trans);
> } else {
> /* set up vsc header for psr1 */
> hsw_psr_setup_vsc(intel_dp);
[PATCH 09/10] drm/i915/psr: report live PSR2 State
Reviewed-by: Rodrigo Vivi
On Fri, 2017-01-06 at 22:02 +0530, vathsala nagaraju wrote:
> Reports live state of PSR2 form PSR2_STATUS register.
> bit field 31:28 gives the live state of PSR2.
> It can be used to check if system is in deep sleep,
> selective update or selective update standby.
> During video play back, we can use this to check
> if system is entering SU mode or not.
> when system is in idle state, DEEP_SLEEP(8) must be entered.
> When video playback is happening, system must be in
> SLEEP(3 / selective update) or SU_STANDBY( 6 / selective update standby)
>
> v2: (Rodrigo)
> - Remove EDP_PSR2_STATUS_TG_ON=a ,instead use ARRAY_SIZE
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: Vathsala Nagaraju
> Signed-off-by: Patil Deepti
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 24
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 9d7b5a8..ec9013e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2606,6 +2606,30 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
>
> seq_printf(m, "Performance_Counter: %u\n", psrperf);
> }
> + if (dev_priv->psr.psr2_support) {
> + static const char * const live_status[] = {
> + "IDLE",
> + "CAPTURE",
> + "CAPTURE_FS",
> + "SLEEP",
> + "BUFON_FW",
> + "ML_UP",
> + "SU_STANDBY",
> + "FAST_SLEEP",
> + "DEEP_SLEEP",
> + "BUF_ON",
> + "TG_ON" };
> + u8 pos = (I915_READ(EDP_PSR2_STATUS_CTL) &
> + EDP_PSR2_STATUS_STATE_MASK) >>
> + EDP_PSR2_STATUS_STATE_SHIFT;
> +
> + seq_printf(m, "PSR2_STATUS_EDP: %x\n",
> + I915_READ(EDP_PSR2_STATUS_CTL));
> +
> + if (pos < ARRAY_SIZE(live_status))
> + seq_printf(m, "PSR2 live state %s\n",
> + live_status[pos]);
> + }
> mutex_unlock(_priv->psr.lock);
>
> intel_runtime_pm_put(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 272a283..65fffc5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3621,6 +3621,7 @@ enum {
>
> #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +#define EDP_PSR2_STATUS_STATE_SHIFT28
>
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
On Fri, 2017-01-06 at 22:21 +0530, vathsala nagaraju wrote:
> Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
> is implemented,this restriction is removed so that psr2
> can work on panels without y cordinate support.
>
> v2: (Rodrigo)
> - Move the check to intel_psr_match_conditions
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: Vathsala Nagaraju
> Signed-off-by: Patil Deepti
> ---
> drivers/gpu/drm/i915/intel_psr.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 05efd4e..1729128 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -433,6 +433,15 @@ static bool intel_psr_match_conditions(struct intel_dp
> *intel_dp)
> return false;
> }
>
> + /*
> + * FIXME:enable psr2 only for y-cordinate psr2 panels
> + * After gtc implementation , remove this restriction.
> + */
> + if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
> + DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
> coordinate\n");
> + return;
return false;
> + }
> +
> dev_priv->psr.source_ok = true;
> return true;
> }
[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hi Inki,
Thanks for the reply, but...
> >> +static const struct drm_display_mode default_mode = {
> >> + .clock = 222372,
> >> + .hdisplay = 1440,
> >> + .hsync_start = 1440 + 1,
> >> + .hsync_end = 1440 + 1 + 1,
> >> + .htotal = 1440 + 1 + 1 + 1,
> >> + .vdisplay = 2560,
> >> + .vsync_start = 2560 + 1,
> >> + .vsync_end = 2560 + 1 + 1,
> >> + .vtotal = 2560 + 1 + 1 + 15,
> >> + .vrefresh = 60,
> >> + .flags = 0,
> >> +};
> >
> > how is this working with tm2e? Are these values valid for both
> > the boards?
>
> We don't need to consider tm2e board with two reasones,
> 1. there is no tm2e board support in mainline
> 2. the panel on tm2 would be a little bit different from one on tm2e
... this display in the Tizen Kernel is supported by both:
tm2 [1] and tm2e [2]. The only differences are:
TM2:
clock-frequency = <1487>;
hactive = <1440>;
TM2E:
clock-frequency = <16523724>;
hactive = <1600>;
I don't know much about the differences you mention in point 2,
but it's a pity to drop support only because we don't want to put
in the dts the 'hactive', and 'clock-frequency' properties.
Andi
[1]
https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
[2]
https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Hi Jose, On Friday 06 Jan 2017 10:07:03 Jose Abreu wrote: > Hi Laurent, > > Sorry for the delayed answer but I am quite busy at the moment. No worries, your help is really appreciated. > On 06-01-2017 01:48, Laurent Pinchart wrote: > > [snip] > > The TX_READY signal is documented in the i.MX6 datasheet as being a PHY > output signal, but there seems to be no HDMI TX register from which its > state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register > through I2C ? How long is the PHY expected to take to set TX_READY to 0 > ? > >>> > >>> TX_READY can be read from register 0x1A of phy, BIT(2) (through > >>> I2C). > >> > >> That's what I thought, I'll poll that then. Do you have any idea how long > >> it's supposed to take, to set an appropriate timeout ? > > For 3d tx phy and for 25 MHz input reference clock the power-up > time is ~1ms, there is no data in the docs to power-down time but > it should be similar. Reference clock value is board dependent > and the minimum value for HDMI shall be 13.5MHz. > > > On i.MX6 (3D TX PHY) register 0x1a reads as 0x0007 before powering down > > the PHY (by deasserting TXPWRON) and as 0x immediately after. On > > RK3288 (MHL PHY) the register reads as 0x0207 and as 0x immediately > > after deasserting TXPWRON. It seems that one I2C read is a sufficient > > delay for TX_READY to go low. > > > >>> Not sure if same offset for all phys though. > >> > >> Most probably not, it would be too easy :-) I'll investigate (which will > >> likely include lots of guesswork). If you can find any information about > >> that (and especially about the MHL and HDMI 2.0 PHYs) that would be very > >> appreciated, as I don't have access to any documentation that mentions a > >> TX_READY bit for those. > > > > I haven't tested the HDMI 2.0 PHY yet, but I'd be surprised if the > > TX_READY bit was in the same register at the same position. > > The info I got the register offset is from an HDMI 2.0 phy :) That's good news :-) > Notice that there are a lot of phy versions and some of them > (used in dw-hdmi) maybe customized, I don't think I have access > to that custom phys documentation. I think we will eventually have to implement PHY-specific power up and power down sequences, but for now a common sequence should work. > Please test the HDMI 2.0 phy and check if the register is the same, it > should be. I did, and it is \o/ I'll send patches. > In the meantime it would really be helpful if some of the developers > that used dw-hdmi supplied this info about the registers as they > should know exactly what phy was used. I will ask internally for the R-Car H3 SoC. -- Regards, Laurent Pinchart
[PATCH] drm: allow to use mmuless SoC
Some SoC without MMU have display driver where a drm/kms driver could be implemented. Before doing such kind of thing drm/kms must allow to use mmuless devices. This patch propose to remove MMU configuration flag and add a cma helper function to help implementing mmuless display driver version 4: - add documentation about drm_gem_cma_get_unmapped_area() - stub it MMU case version 5: - Make all driver that select DRM_TTM depends on MMU (issue reported by kbuild test robot) Signed-off-by: Benjamin Gaignard [danvet: Use recommended struct member references in kernel-doc.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483521177-21794-4-git-send-email-benjamin.gaignard at linaro.org --- Documentation/gpu/drm-mm.rst| 11 + drivers/gpu/drm/Kconfig | 8 ++-- drivers/gpu/drm/ast/Kconfig | 2 +- drivers/gpu/drm/bochs/Kconfig | 2 +- drivers/gpu/drm/cirrus/Kconfig | 2 +- drivers/gpu/drm/drm_gem_cma_helper.c| 71 + drivers/gpu/drm/gma500/Kconfig | 2 +- drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +- drivers/gpu/drm/mgag200/Kconfig | 2 +- drivers/gpu/drm/nouveau/Kconfig | 2 +- drivers/gpu/drm/qxl/Kconfig | 2 +- drivers/gpu/drm/virtio/Kconfig | 2 +- drivers/gpu/drm/vmwgfx/Kconfig | 2 +- include/drm/drm_gem_cma_helper.h| 17 14 files changed, 113 insertions(+), 14 deletions(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index d3c6d77..1ea94fc 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -310,6 +310,17 @@ created. Drivers that want to map the GEM object upfront instead of handling page faults can implement their own mmap file operation handler. +For platforms without MMU the GEM core provides a helper method +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call +this to get a proposed address for the mapping. + +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the +struct :c:type:`struct file_operations ` get_unmapped_area +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`. + +More detailed information about get_unmapped_area can be found in +Documentation/nommu-mmap.txt + Memory Coherency diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index d56b85c..6f3f9e6 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -6,7 +6,7 @@ # menuconfig DRM tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA select HDMI select FB_CMDLINE select I2C @@ -113,7 +113,7 @@ config DRM_LOAD_EDID_FIRMWARE config DRM_TTM tristate - depends on DRM + depends on DRM && MMU help GPU memory management subsystem for devices with multiple GPU memory types. Will be enabled automatically if a device driver @@ -146,7 +146,7 @@ source "drivers/gpu/drm/arm/Kconfig" config DRM_RADEON tristate "ATI Radeon" - depends on DRM && PCI + depends on DRM && PCI && MMU select FW_LOADER select DRM_KMS_HELPER select DRM_TTM @@ -166,7 +166,7 @@ source "drivers/gpu/drm/radeon/Kconfig" config DRM_AMDGPU tristate "AMD GPU" - depends on DRM && PCI + depends on DRM && PCI && MMU select FW_LOADER select DRM_KMS_HELPER select DRM_TTM diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig index 15f6ce7..9647e1f 100644 --- a/drivers/gpu/drm/ast/Kconfig +++ b/drivers/gpu/drm/ast/Kconfig @@ -1,6 +1,6 @@ config DRM_AST tristate "AST server chips" - depends on DRM && PCI + depends on DRM && PCI && MMU select DRM_TTM select DRM_KMS_HELPER select DRM_TTM diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig index f739763..bd27180 100644 --- a/drivers/gpu/drm/bochs/Kconfig +++ b/drivers/gpu/drm/bochs/Kconfig @@ -1,6 +1,6 @@ config DRM_BOCHS tristate "DRM Support for bochs dispi vga interface (qemu stdvga)" - depends on DRM && PCI + depends on DRM && PCI && MMU select DRM_KMS_HELPER select DRM_TTM help diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig index 04b3c16..ca38098 100644 --- a/drivers/gpu/drm/cirrus/Kconfig +++ b/drivers/gpu/drm/cirrus/Kconfig @@ -1,6 +1,6 @@ config DRM_CIRRUS_QEMU tristate "Cirrus driver for QEMU emulated device" - depends on DRM && PCI + depends on DRM && PCI && MMU select DRM_KMS_HELPER select DRM_TTM help diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index e0806a2a..5cf38a4 100644 ---
[PATCH] drm: Change the return type of the unload hook to void
The integer returned by the unload hook is ignored by the drm core, so
let's make it void.
This patch was created using the following Coccinelle semantic script
(except for the declaration and comment in drm_drv.h):
Compile-tested only.
//
@ get_name @
struct drm_driver drv;
identifier fn;
@@
drv.unload = fn;
@ replace_type @
identifier get_name.fn;
@@
- int
+ void
fn (...)
{
...
}
@ remove_return_param @
identifier get_name.fn;
@@
void fn (...)
{
<...
if (...)
return
- ...
;
...>
}
@ drop_final_return @
identifier get_name.fn;
@@
void fn (...)
{
...
- return 0;
}
//
Suggested-by: Daniel Vetter
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 ++---
drivers/gpu/drm/ast/ast_drv.h | 2 +-
drivers/gpu/drm/ast/ast_main.c| 3 +--
drivers/gpu/drm/bochs/bochs_drv.c | 3 +--
drivers/gpu/drm/cirrus/cirrus_drv.h | 2 +-
drivers/gpu/drm/cirrus/cirrus_main.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 +---
drivers/gpu/drm/gma500/psb_drv.c | 3 +--
drivers/gpu/drm/mga/mga_dma.c | 4 +---
drivers/gpu/drm/mga/mga_drv.h | 2 +-
drivers/gpu/drm/mgag200/mgag200_drv.h | 2 +-
drivers/gpu/drm/mgag200/mgag200_main.c| 5 ++---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +--
drivers/gpu/drm/omapdrm/omap_drv.c| 4 +---
drivers/gpu/drm/qxl/qxl_drv.h | 2 +-
drivers/gpu/drm/qxl/qxl_kms.c | 5 ++---
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 5 ++---
drivers/gpu/drm/savage/savage_bci.c | 4 +---
drivers/gpu/drm/savage/savage_drv.h | 2 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
drivers/gpu/drm/sis/sis_drv.c | 4 +---
drivers/gpu/drm/tegra/drm.c | 6 ++
drivers/gpu/drm/udl/udl_drv.h | 2 +-
drivers/gpu/drm/udl/udl_main.c| 3 +--
drivers/gpu/drm/via/via_drv.h | 2 +-
drivers/gpu/drm/via/via_map.c | 4 +---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +---
include/drm/drm_drv.h | 5 +
33 files changed, 39 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 54ac8a845e9f..7077ed65d403 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1711,7 +1711,7 @@ extern const struct drm_ioctl_desc amdgpu_ioctls_kms[];
extern const int amdgpu_max_kms_ioctl;
int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags);
-int amdgpu_driver_unload_kms(struct drm_device *dev);
+void amdgpu_driver_unload_kms(struct drm_device *dev);
void amdgpu_driver_lastclose_kms(struct drm_device *dev);
int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv);
void amdgpu_driver_postclose_kms(struct drm_device *dev,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 9af87eaf8ee3..8aef2582 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -50,12 +50,12 @@ static inline bool amdgpu_has_atpx(void) { return false; }
* This is the main unload function for KMS (all asics).
* Returns 0 on success.
*/
-int amdgpu_driver_unload_kms(struct drm_device *dev)
+void amdgpu_driver_unload_kms(struct drm_device *dev)
{
struct amdgpu_device *adev = dev->dev_private;
if (adev == NULL)
- return 0;
+ return;
if (adev->rmmio == NULL)
goto done_free;
@@ -74,7 +74,6 @@ int amdgpu_driver_unload_kms(struct drm_device *dev)
done_free:
kfree(adev);
dev->dev_private = NULL;
- return 0;
}
/**
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 6f3b6f50cf52..1051181d8c0d 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -122,7 +122,7 @@ struct ast_private {
};
int ast_driver_load(struct drm_device *dev, unsigned long flags);
-int ast_driver_unload(struct drm_device *dev);
+void ast_driver_unload(struct drm_device *dev);
struct ast_gem_object;
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index d85af0ff2653..5b59888426cf 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -476,7 +476,7 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
return ret;
}
-int ast_driver_unload(struct drm_device *dev)
+void ast_driver_unload(struct drm_device *dev)
{
struct ast_private *ast = dev->dev_private;
@@ -489,7 +489,6 @@ int ast_driver_unload(struct drm_device *dev)
pci_iounmap(dev->pdev, ast->ioregs);
[PULL] sti-drm-next-2017-01-06
Hi Dave, Here is an update of the STI drm driver. It contains file cleanup and various fixes. Regard, Vincent The following changes since commit 2cf026ae85c42f253feb9f420d1b4bc99bd5503d: Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next (2016-12-13 14:29:05 +1000) are available in the git repository at: https://github.com/vinceab/linux.git 1ae0d5af347df224a6e76334683f13a96d915a44 for you to fetch changes up to 1ae0d5af347df224a6e76334683f13a96d915a44: drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache (2017-01-06 15:12:03 +0100) Arnaud Pouliquen (1): drm/sti: allow audio playback on HDMI even if disabled. Arvind Yadav (1): drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache Fabien DESSENNE (2): drm/sti: load XP70 firmware only once drm/sti: do not post HQVDP command if no update Vincent Abriou (3): drm/sti: update fps debugfs entries drm/sti: create fbdev at binding drm/sti: remove deprecated sti_vtac.c file drivers/gpu/drm/sti/Makefile| 1 - drivers/gpu/drm/sti/sti_drv.c | 28 ++--- drivers/gpu/drm/sti/sti_drv.h | 1 - drivers/gpu/drm/sti/sti_hdmi.c | 205 ++-- drivers/gpu/drm/sti/sti_hqvdp.c | 23 - drivers/gpu/drm/sti/sti_plane.c | 17 ++- drivers/gpu/drm/sti/sti_plane.h | 2 +- drivers/gpu/drm/sti/sti_vtac.c | 223 drivers/gpu/drm/sti/sti_vtg.c | 4 + 9 files changed, 154 insertions(+), 350 deletions(-) delete mode 100644 drivers/gpu/drm/sti/sti_vtac.c
[PATCH 0/9] drm/i915: SKL+ render decompression support
On 17-01-04 20:42:23, Ville Syrjälä wrote: >From: Ville Syrjälä > >This series enables the SKL+ display engine render decompression >support. Some bits and pieces of the i915 code are based on work >from various people, but I just put my name on it since it >would be hard to figure out which parts came from where. > >Entire series available here: >git://github.com/vsyrjala/linux.git fb_format_dedup_4_ccs > >Cc: Vandana Kannan >Cc: Daniel Vetter >Cc: Ben Widawsky >Cc: Jason Ekstrand >Cc: Laurent Pinchart > In addition to review comments I've left, this series (patch 8 and 9 in particular) is: Tested-by: Ben Widawsky [snip] -- Ben Widawsky, Intel Open Source Technology Center
[PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)
Allows usage of the new page_flip_target hook for drivers implementing
the atomic path.
Provides default atomic helper for the new hook.
v2:
Update code sharing logic between exsiting and the new flip hooks.
Improve kerneldoc.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_atomic_helper.c | 133 ++--
include/drm/drm_atomic_helper.h | 6 ++
include/drm/drm_crtc.h | 9 +++
3 files changed, 127 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 583f47f..a4e5477 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2733,6 +2733,44 @@ int drm_atomic_helper_resume(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
+static int page_flip_common(
+ struct drm_atomic_state *state,
+ struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event)
+{
+ struct drm_plane *plane = crtc->primary;
+ struct drm_plane_state *plane_state;
+ struct drm_crtc_state *crtc_state;
+ int ret = 0;
+
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ crtc_state->event = event;
+
+ plane_state = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(plane_state))
+ return PTR_ERR(plane_state);
+
+
+ ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
+ if (ret != 0)
+ return ret;
+ drm_atomic_set_fb_for_plane(plane_state, fb);
+
+ /* Make sure we don't accidentally do a full modeset. */
+ state->allow_modeset = false;
+ if (!crtc_state->active) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
+crtc->base.id);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
/**
* drm_atomic_helper_page_flip - execute a legacy page flip
* @crtc: DRM crtc
@@ -2740,7 +2778,8 @@ int drm_atomic_helper_resume(struct drm_device *dev,
* @event: optional DRM event to signal upon completion
* @flags: flip flags for non-vblank sync'ed updates
*
- * Provides a default page flip implementation using the atomic driver
interface.
+ * Provides a default _crtc_funcs.page_flip implementation
+ * using the atomic driver interface.
*
* Note that for now so called async page flips (i.e. updates which are not
* synchronized to vblank) are not supported, since the atomic interfaces have
@@ -2748,6 +2787,9 @@ int drm_atomic_helper_resume(struct drm_device *dev,
*
* Returns:
* Returns 0 on success, negative errno numbers on failure.
+ *
+ * See also:
+ * drm_atomic_helper_page_flip_target()
*/
int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
@@ -2756,8 +2798,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
{
struct drm_plane *plane = crtc->primary;
struct drm_atomic_state *state;
- struct drm_plane_state *plane_state;
- struct drm_crtc_state *crtc_state;
int ret = 0;
if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
@@ -2768,35 +2808,86 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
return -ENOMEM;
state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+
retry:
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- if (IS_ERR(crtc_state)) {
- ret = PTR_ERR(crtc_state);
+ ret = page_flip_common(state, crtc, fb, event);
+ if (ret != 0)
goto fail;
- }
- crtc_state->event = event;
- plane_state = drm_atomic_get_plane_state(state, plane);
- if (IS_ERR(plane_state)) {
- ret = PTR_ERR(plane_state);
- goto fail;
- }
+ ret = drm_atomic_nonblocking_commit(state);
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
+fail:
+ if (ret == -EDEADLK)
+ goto backoff;
+
+ drm_atomic_state_put(state);
+ return ret;
+
+backoff:
+ drm_atomic_state_clear(state);
+ drm_atomic_legacy_backoff(state);
+
+ /*
+* Someone might have exchanged the framebuffer while we dropped locks
+* in the backoff code. We need to fix up the fb refcount tracking the
+* core does for us.
+*/
+ plane->old_fb = plane->fb;
+
+ goto retry;
+}
+EXPORT_SYMBOL(drm_atomic_helper_page_flip);
+
+/**
+ * drm_atomic_helper_page_flip_target - do page flip on target vblank period.
+ * @crtc: DRM crtc
+ * @fb: DRM framebuffer
+ * @event: optional DRM event to signal upon completion
+ * @flags: flip flags for non-vblank sync'ed updates
+ * @target: specifying the target vblank period when the
[PATCH v3 5/5] drm/rockchip: Implement CRC debugfs API
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001f51c3..5e19bef6d5b4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1105,6 +1106,52 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
}
+static struct drm_connector *vop_get_edp_connector(struct vop *vop)
+{
+ struct drm_crtc *crtc = >crtc;
+ struct drm_connector *connector;
+
+ mutex_lock(>dev->mode_config.mutex);
+ drm_for_each_connector(connector, crtc->dev)
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ mutex_unlock(>dev->mode_config.mutex);
+ return connector;
+ }
+ mutex_unlock(>dev->mode_config.mutex);
+
+ return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+ const char *source_name, size_t *values_cnt)
+{
+ struct vop *vop = to_vop(crtc);
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+ struct drm_connector *connector;
+ int ret;
+
+ connector = vop_get_edp_connector(vop);
+ if (!connector)
+ return -EINVAL;
+
+ *values_cnt = 3;
+
+ if (source_name &&
+ strcmp(source_name, "auto") == 0) {
+
+ if (s->output_type != DRM_MODE_CONNECTOR_eDP)
+ return -EINVAL;
+
+ ret = analogix_dp_start_crc(connector);
+ } else if (!source_name)
+
+ ret = analogix_dp_stop_crc(connector);
+ else
+ ret = -EINVAL;
+
+ return ret;
+}
+
static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1112,6 +1159,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
+ .set_crc_source = vop_crtc_set_crc_source,
};
static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
--
2.9.3
[PATCH v3 4/5] drm/bridge: analogix_dp: add helpers for capture of frame CRCs
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7d45d3e4600a..02f63eb1b887 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1483,6 +1483,22 @@ int analogix_dp_resume(struct device *dev)
EXPORT_SYMBOL_GPL(analogix_dp_resume);
#endif
+int analogix_dp_start_crc(struct drm_connector *connector)
+{
+ struct analogix_dp_device *dp = to_dp(connector);
+
+ return drm_dp_start_crc(>aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_start_crc);
+
+int analogix_dp_stop_crc(struct drm_connector *connector)
+{
+ struct analogix_dp_device *dp = to_dp(connector);
+
+ return drm_dp_stop_crc(>aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_stop_crc);
+
MODULE_AUTHOR("Jingoo Han ");
MODULE_DESCRIPTION("Analogix DP Core Driver");
MODULE_LICENSE("GPL v2");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index f6f0c062205c..c99d6eaef1ac 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -49,4 +49,7 @@ int analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
struct analogix_dp_plat_data *plat_data);
void analogix_dp_unbind(struct device *dev, struct device *master, void *data);
+int analogix_dp_start_crc(struct drm_connector *connector);
+int analogix_dp_stop_crc(struct drm_connector *connector);
+
#endif /* _ANALOGIX_DP_H_ */
--
2.9.3
[PATCH v3 3/5] drm/dp: add helpers for capture of frame CRCs
Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.
v2: Reuse drm_crtc_wait_one_vblank
Update locking, as drm_crtc_add_crc_entry now takes the lock
v3: Don't call wake_up_interruptible directly, that's now done in
drm_crtc_add_crc_entry.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_dp_helper.c | 118
include/drm/drm_dp_helper.h | 7 +++
2 files changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e6fe82c6d64..e531f1317268 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -981,6 +981,74 @@ static const struct i2c_lock_operations
drm_dp_i2c_lock_ops = {
.unlock_bus = unlock_bus,
};
+static int drm_dp_aux_get_crc(struct drm_dp_aux *aux, u8 *crc)
+{
+ u8 buf, count;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(!(buf & DP_TEST_SINK_START));
+
+ ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK_MISC, );
+ if (ret < 0)
+ return ret;
+
+ count = buf & DP_TEST_COUNT_MASK;
+ if (count == aux->crc_count)
+ return -EAGAIN; /* No CRC yet */
+
+ aux->crc_count = count;
+
+ /* At DP_TEST_CRC_R_CR, there's 6 bytes containing CRC data, 2 bytes
+* per component (RGB or CrYCb).
+*/
+ ret = drm_dp_dpcd_read(aux, DP_TEST_CRC_R_CR, crc, 6);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static void drm_dp_aux_crc_work(struct work_struct *work)
+{
+ struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
+ crc_work);
+ struct drm_crtc *crtc;
+ u8 crc_bytes[6];
+ uint32_t crcs[3];
+ int ret;
+
+ if (WARN_ON(!aux->connector))
+ return;
+
+ crtc = aux->connector->state->crtc;
+ while (crtc->crc.opened) {
+ drm_crtc_wait_one_vblank(crtc);
+ if (!crtc->crc.opened)
+ break;
+
+ ret = drm_dp_aux_get_crc(aux, crc_bytes);
+ if (ret == -EAGAIN) {
+ usleep_range(1000, 2000);
+ ret = drm_dp_aux_get_crc(aux, crc_bytes);
+ }
+
+ if (ret) {
+ DRM_DEBUG_KMS("Failed to get a CRC even after retrying:
%d\n",
+ ret);
+ continue;
+ }
+
+ crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
+ crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
+ crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
+ ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
+ }
+}
+
/**
* drm_dp_aux_init() - minimally initialise an aux channel
* @aux: DisplayPort AUX channel
@@ -993,6 +1061,7 @@ static const struct i2c_lock_operations
drm_dp_i2c_lock_ops = {
void drm_dp_aux_init(struct drm_dp_aux *aux)
{
mutex_init(>hw_mutex);
+ INIT_WORK(>crc_work, drm_dp_aux_crc_work);
aux->ddc.algo = _dp_i2c_algo;
aux->ddc.algo_data = aux;
@@ -1081,3 +1150,52 @@ int drm_dp_psr_setup_time(const u8
psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
EXPORT_SYMBOL(drm_dp_psr_setup_time);
#undef PSR_SETUP_TIME
+
+/**
+ * drm_dp_start_crc() - start capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_start_crc(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
+ if (ret < 0)
+ return ret;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_TEST_SINK, buf | DP_TEST_SINK_START);
+ if (ret < 0)
+ return ret;
+
+ aux->crc_count = 0;
+ schedule_work(>crc_work);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_start_crc);
+
+/**
+ * drm_dp_stop_crc() - stop capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_stop_crc(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
+ if (ret < 0)
+ return ret;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_TEST_SINK, buf & ~DP_TEST_SINK_START);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_stop_crc);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4fa77b434594..276e1ecd947b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -723,6 +723,8 @@ struct drm_dp_aux_msg {
* @dev: pointer to struct device that is the parent for this
[PATCH v3 2/5] drm/bridge: analogix_dp: set connector to drm_dp_aux
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 02b97bf64ee4..7d45d3e4600a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1402,23 +1402,25 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
dp->drm_dev = drm_dev;
dp->encoder = dp->plat_data->encoder;
+ ret = analogix_dp_create_bridge(drm_dev, dp);
+ if (ret) {
+ DRM_ERROR("failed to create bridge (%d)\n", ret);
+ goto err_encoder_cleanup;
+ }
+
dp->aux.name = "DP-AUX";
dp->aux.transfer = analogix_dpaux_transfer;
dp->aux.dev = >dev;
+ dp->aux.connector = >connector;
ret = drm_dp_aux_register(>aux);
if (ret)
- goto err_disable_pm_runtime;
-
- ret = analogix_dp_create_bridge(drm_dev, dp);
- if (ret) {
- DRM_ERROR("failed to create bridge (%d)\n", ret);
- drm_encoder_cleanup(dp->encoder);
- goto err_disable_pm_runtime;
- }
+ goto err_encoder_cleanup;
return 0;
+err_encoder_cleanup:
+ drm_encoder_cleanup(dp->encoder);
err_disable_pm_runtime:
pm_runtime_disable(dev);
--
2.9.3
[PATCH v3 1/5] drm/dp: add connector backpointer to drm_dp_aux
This backpointer allows DP helpers to access the connector it's being
used for.
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 55bbeb0ff594..4fa77b434594 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -721,6 +721,7 @@ struct drm_dp_aux_msg {
* @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
* @ddc: I2C adapter that can be used for I2C-over-AUX communication
* @dev: pointer to struct device that is the parent for this AUX channel
+ * @connector: backpointer to connector that uses this AUX channel
* @hw_mutex: internal mutex used for locking transfers
* @transfer: transfers a message representing a single AUX transaction
*
@@ -757,6 +758,7 @@ struct drm_dp_aux {
const char *name;
struct i2c_adapter ddc;
struct device *dev;
+ struct drm_connector *connector;
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
--
2.9.3
[PATCH v3 0/5] drm/dp: Implement CRC debugfs API
Hi, this series builds up on the API for exposing captured CRCs through debugfs. It adds new DP helpers for starting and stopping CRC capture and gets the Rockchip driver to use it. Also had to add a connector backpointer to the drm_dp_aux struct so we could wait for the right vblank and store the CRCs afterwards, I will be glad to hear about better alternatives. With these patches, tests in IGT such as kms_pipe_crc_basic and kms_plane do pass on RK3288. Thanks, Tomeu Tomeu Vizoso (5): drm/dp: add connector backpointer to drm_dp_aux drm/bridge: analogix_dp: set connector to drm_dp_aux drm/dp: add helpers for capture of frame CRCs drm/bridge: analogix_dp: add helpers for capture of frame CRCs drm/rockchip: Implement CRC debugfs API drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 34 -- drivers/gpu/drm/drm_dp_helper.c| 118 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 48 + include/drm/bridge/analogix_dp.h | 3 + include/drm/drm_dp_helper.h| 9 ++ 5 files changed, 204 insertions(+), 8 deletions(-) -- 2.9.3
[PATCH v2 1/2] drm: crc: Call wake_up_interruptible() each time there is a new CRC entry
On Fri, Jan 06, 2017 at 10:15:03AM +0100, Benjamin Gaignard wrote: > Each time new data has being added in CRC list inform reader by calling > wake_up_interruptible(). > This should avoid to do it in all drivers. > > Signed-off-by: Benjamin Gaignard > Cc: Tomeu Vizoso > Cc: Daniel Vetter Applied with Tomeu's irc r-b. Thanks, Daniel > --- > drivers/gpu/drm/drm_debugfs_crc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 8b0..96891c4 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -363,6 +363,8 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool > has_frame, > > spin_unlock(>lock); > > + wake_up_interruptible(>wq); > + > return 0; > } > EXPORT_SYMBOL_GPL(drm_crtc_add_crc_entry); > -- > 1.9.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Enabling peer to peer device transactions for PCIe devices
On 06/01/17 11:26 AM, Jason Gunthorpe wrote: > Make a generic API for all of this and you'd have my vote.. > > IMHO, you must support basic pinning semantics - that is necessary to > support generic short lived DMA (eg filesystem, etc). That hardware > can clearly do that if it can support ODP. I agree completely. What we want is for RDMA, O_DIRECT, etc to just work with special VMAs (ie. at least those backed with ZONE_DEVICE memory). Then GPU/NVME/DAX/whatever drivers can just hand these VMAs to userspace (using whatever interface is most appropriate) and userspace can do what it pleases with them. This makes _so_ much sense and actually largely already works today (as demonstrated by iopmem). Though, of course, there are many aspects that could still be improved like denying CPU access to special VMAs and having get_user_pages avoid pinning device memory, etc, etc. But all this would just be enhancements to how VMAs work and not be effected by the basic design described above. We experimented with GPU Direct and the peer memory patchset for IB and they were broken by design. They were just a very specific hack into the IB core and thus didn't help to support O_DIRECT or any other possible DMA user. And the invalidation thing was completely nuts. We had to pray an invalidation would never occur because, if it did, our application would just break. Logan
[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
2017ë
01ì 06ì¼ 14:22ì Andi Shyti ì´(ê°) ì´ ê¸:
> Hi Hoegeun,
>
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +.vdisplay = 2560,
>> +.vsync_start = 2560 + 1,
>> +.vsync_end = 2560 + 1 + 1,
>> +.vtotal = 2560 + 1 + 1 + 15,
>> +.vrefresh = 60,
>> +.flags = 0,
>> +};
>
> how is this working with tm2e? Are these values valid for both
> the boards?
We don't need to consider tm2e board with two reasones,
1. there is no tm2e board support in mainline
2. the panel on tm2 would be a little bit different from one on tm2e
Thanks,
Inki Dae
>
> Andi
>
>
[PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()
On Wed, Jan 04, 2017 at 09:23:34PM +0530, Sumit Semwal wrote: > Hi Chris, > > Thanks for your patches! > > On 4 January 2017 at 20:40, Daniel Vetter wrote: > > On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote: > >> As the fence->status is an optional field that may be set before > >> dma_fence_signal() is called to convey that the fence completed with an > >> error, we have to ensure that it is always set to zero on initialisation > >> so that the typical use (i.e. unset) always flags a successful completion. > >> > >> Signed-off-by: Chris Wilson > >> Reviewed-by: Tvrtko Ursulin > > > > Yeah, this looks all pretty. On the series: > > > > Reviewed-by: Daniel Vetter > > > FWIW, please feel free, for this series, to apply my > > Reviewed-by: Sumit Semwal > > > I'll defer to Gustavo for another pass over it and merging it to drm-misc. It would be nice to have this in the next round of backmerges. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hi Hoegeun,
> +static const struct drm_display_mode default_mode = {
> + .clock = 222372,
> + .hdisplay = 1440,
> + .hsync_start = 1440 + 1,
> + .hsync_end = 1440 + 1 + 1,
> + .htotal = 1440 + 1 + 1 + 1,
> + .vdisplay = 2560,
> + .vsync_start = 2560 + 1,
> + .vsync_end = 2560 + 1 + 1,
> + .vtotal = 2560 + 1 + 1 + 15,
> + .vrefresh = 60,
> + .flags = 0,
> +};
how is this working with tm2e? Are these values valid for both
the boards?
Andi
[Bug 98743] Incorrect colormapping in Verdun game
https://bugs.freedesktop.org/show_bug.cgi?id=98743 --- Comment #5 from Samuel Pitoiset --- I can't reproduce the bug. Which version of mesa/llvm are you using? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/efdae206/attachment.html>
[PATCH v7 4/4] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
Hi Hoegeun, On Thu, Jan 05, 2017 at 07:20:09PM +0900, Hoegeun Kwon wrote: > From: Hyungwon Hwang > > This patch add the panel device tree node for S6E3HA2 display > controller to TM2 dts. > > Signed-off-by: Hyungwon Hwang > Signed-off-by: Andrzej Hajda > Signed-off-by: Chanwoo Choi > Signed-off-by: Hoegeun Kwon > Tested-by: Chanwoo Choi > --- > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts > b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts Damn! this is getting complicated, you need to rebase this branch on top of the latest changes on exynos5433-tm2* (see Jaechul's patches https://lkml.org/lkml/2017/1/5/887). I will soon send you a link where you can get them. Andi
[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2
Rodrigo,
The code is
if (dev_priv->psr.psr2_support) {
/* PSR2 is restricted to work with panel resolutions
upto 3200x2000 */
if (crtc->config->pipe_src_w > 3200 ||
crtc->config->pipe_src_h > 2000)
dev_priv->psr.psr2_support = false;
else
skl_psr_setup_su_vsc(intel_dp);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
}
If psr2_support=0 , then it calls hsw_psr_setup_vsc(intel_dp); {psr1 vsc setup)
If psr2_support=1 then it calls skl_psr_setup_su_vsc(intel_dp); (psr2 vsc setup)
Regards,
vathsala
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, January 6, 2017 2:12 AM
To: Nagaraju, Vathsala
Cc: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org;
jim.bride at linux.intel.com; Patil, Deepti
Subject: Re: [PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2
On Fri, 2017-01-06 at 00:55 +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg PSR2_CTL
> must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting in
> blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance, as
> suggested by rodrigo and jim.
>
> v2: (Vivi Rodrigo)
> - Rename hsw_enable_source_psr* to intel_enable_source_psr*
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: Vathsala Nagaraju
> Signed-off-by: Patil Deepti
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +
> drivers/gpu/drm/i915/intel_psr.c | 124
> +--
> 2 files changed, 97 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
> #define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf<<4)
> #define EDP_PSR2_IDLE_MASK 0xf
>
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3aa649..d5e8bcc 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
> VLV_EDP_PSR_ACTIVE_ENTRY);
> }
>
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void intel_enable_source_psr1(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct drm_device *dev = dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> -
> uint32_t max_sleep_time = 0x1f;
> /*
>* Let's respect VBT in case VBT asks a higher idle_frame value.
> @@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp
> *intel_dp)
> val |= EDP_PSR_TP1_TP2_SEL;
>
> I915_WRITE(EDP_PSR_CTL, val);
> +}
>
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void intel_enable_source_psr2(struct intel_dp *intel_dp) {
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /*
> + * Let's respect VBT in case VBT asks a higher idle_frame value.
> + * Let's use 6 as the minimum to cover all known cases including
> + * the off-by-one issue that HW has in some cases. Also there are
> + * cases where sink should be able to train
> + * with the 5 or 6 idle patterns.
> + */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val = EDP_PSR_ENABLE;
> +
> + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>
> /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>
> if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp
> *intel_dp)
> I915_WRITE(EDP_PSR2_CTL, val);
> }
>
> +
>
Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?
+rantogno
Rafael, I finally discovered the source of the bug I was hitting.
On Fri 06 Jan 2017, Chad Versace wrote:
> Was this a mistake in the API? If so, can we fix this ABI mistake before
> kernel consumers rely on this?
>
> I naïvely expected that OUT_FENCE_PTR would be a pointer to, obviously, a
> fence
> fd (s32 __user *). But it's not. It's s64 __user *. Due to that surprise, I
> spent several hours chasing down weird corruption in Rob Clark's kmscube. The
> kernel unexpectedly cleared the 32 bits *above* an `int kms_fence_fd` in
> userspace.
>
> For reference, here's the relevant DRM code.
>
> // file: drivers/gpu/drm/drm_atomic.c
> struct drm_out_fence_state {
> s64 __user *out_fence_ptr;
> struct sync_file *sync_file;
> int fd;
> };
>
> static int setup_out_fence(struct drm_out_fence_state *fence_state,
>struct dma_fence *fence)
> {
> fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
> if (fence_state->fd < 0)
> return fence_state->fd;
>
> if (put_user(fence_state->fd, fence_state->out_fence_ptr))
> return -EFAULT;
>
> fence_state->sync_file = sync_file_create(fence);
> if (!fence_state->sync_file)
> return -ENOMEM;
>
> return 0;
> }
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: sti: implement CRC capture API
On 01/06/2017 11:21 AM, Benjamin Gaignard wrote:
> 2017-01-06 10:58 GMT+01:00 Daniel Vetter :
>> On Fri, Jan 06, 2017 at 10:06:50AM +0100, Benjamin Gaignard wrote:
>>> 2017-01-06 9:22 GMT+01:00 Tomeu Vizoso :
On 5 January 2017 at 12:12, Benjamin Gaignard
wrote:
> Use CRC API to retrieve the 3 crc values from hardware.
>
> Signed-off-by: Benjamin Gaignard
> ---
> This patch should be applied on top of drm-misc branch where Tomeu
> has change crc.lock.
>
> I think that wake_up_interruptible() could also be call at the end
> of drm_crtc_add_crc_entry() to avoid putting it in all drivers.
Agreed, I can send such a patch if you don't have time.
>>>
>>> I just finish to test the patches I will send them asap
>>>
Btw, do any tests from iGT that make use of CRCs pass with this? If
so, would be good to note it in the commit message.
>>>
>>> I don't run IGT just modetest and cat on crtc-0/crc/data
>>
>> Would be really good if you can give igt a spin on this ...
>
> What is the status of IGT on ARM platforms ?
> Last time (~6 months ago) I tested it, I had to include intel drm lib
> and it just allow me
> to check drm version. Does that have change ?
Yup, this and other issues have been fixed. Have been running
tests/kms_pipe_crc_basic on a RK3288 Chromebook recently without any
problems.
Make sure though to rebase onto a recent drm-misc because of
e3d19d55676b ("drm: crc: Wait for a frame before returning from open()").
Regards,
Tomeu
Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?
Was this a mistake in the API? If so, can we fix this ABI mistake before
kernel consumers rely on this?
I naïvely expected that OUT_FENCE_PTR would be a pointer to, obviously, a fence
fd (s32 __user *). But it's not. It's s64 __user *. Due to that surprise, I
spent several hours chasing down weird corruption in Rob Clark's kmscube. The
kernel unexpectedly cleared the 32 bits *above* an `int kms_fence_fd` in
userspace.
For reference, here's the relevant DRM code.
// file: drivers/gpu/drm/drm_atomic.c
struct drm_out_fence_state {
s64 __user *out_fence_ptr;
struct sync_file *sync_file;
int fd;
};
static int setup_out_fence(struct drm_out_fence_state *fence_state,
struct dma_fence *fence)
{
fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
if (fence_state->fd < 0)
return fence_state->fd;
if (put_user(fence_state->fd, fence_state->out_fence_ptr))
return -EFAULT;
fence_state->sync_file = sync_file_create(fence);
if (!fence_state->sync_file)
return -ENOMEM;
return 0;
}
Enabling peer to peer device transactions for PCIe devices
On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote: > On 2017-01-05 08:58 PM, Jerome Glisse wrote: > > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote: > > > On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote: > > > > > > > > I still don't understand what you driving at - you've said in both > > > > > cases a user VMA exists. > > > > In the former case no, there is no VMA directly but if you want one than > > > > a device can provide one. But such VMA is useless as CPU access is not > > > > expected. > > > I disagree it is useless, the VMA is going to be necessary to support > > > upcoming things like CAPI, you need it to support O_DIRECT from the > > > filesystem, DPDK, etc. This is why I am opposed to any model that is > > > not VMA based for setting up RDMA - that is shorted sighted and does > > > not seem to reflect where the industry is going. > > > > > > So focus on having VMA backed by actual physical memory that covers > > > your GPU objects and ask how do we wire up the '__user *' to the DMA > > > API in the best way so the DMA API still has enough information to > > > setup IOMMUs and whatnot. > > I am talking about 2 different thing. Existing hardware and API where you > > _do not_ have a vma and you do not need one. This is just existing stuff. > I do not understand why you assume that existing API doesn't need one. > I would say that a lot of __existing__ user level API and their support in > kernel (especially outside of graphics domain) assumes that we have vma and > deal with __user * pointers. Well i am thinking to GPUDirect here. Some of GPUDirect use case do not have vma (struct vm_area_struct) associated with them they directly apply to GPU object that aren't expose to CPU. Yes some use case have vma for share buffer. In the open source driver it is true that we have vma most often than not. > > Some close driver provide a functionality on top of this design. Question > > is do we want to do the same ? If yes and you insist on having a vma we > > could provide one but this is does not apply and is useless for where we > > are going with new hardware. > > > > With new hardware you just use malloc or mmap to allocate memory and then > > you use it directly with the device. Device driver can migrate any part of > > the process address space to device memory. In this scheme you have your > > usual VMAs but there is nothing special about them. > > Assuming that the whole device memory is CPU accessible and it looks > like the direction where we are going: > - You forgot about use case when we want or need to allocate memory > directly on device (why we need to migrate anything if not needed?). > - We may want to use CPU to access such memory on device to avoid > any unnecessary migration back. > - We may have more device memory than the system one. > E.g. if you have 12 GPUs w/64GB each it will already give us ~0.7 TB > not mentioning NVDIMM cards which could also be used as memory > storage for other device access. > - We also may want/need to share GPU memory between different > processes. Here i am talking about platform where GPU memory is not accessible at all by the CPU (because of PCIe restriction, think CPU atomic operation on IO memory). So i really distinguish between CAPI/CCIX and PCIe. Some platform will have CAPI/CCIX other wont. HMM apply mostly to the latter. Some of HMM functionalities are still usefull with CAPI/CCIX. Note that HMM do support allocation on GPU first. In current design this can happen when GPU is the first to access an unpopulated virtual address. For platform where GPU memory is accessible plan is either something like CDM (Coherent Device Memory) or rely on ZONE_DEVICE. So all GPU memory have struct page and those are like ordinary pages. CDM still wants some restrictions like avoiding CPU allocation to happen on GPU when there is memory pressure ... For all intent and purposes this will work transparently in respect to RDMA because we assume on those system that the RDMA is CAPI/CCIX and that it can peer to other device. > > Now when you try to do get_user_page() on any page that is inside the > > device it will fails because we do not allow any device memory to be pin. > > There is various reasons for that and they are not going away in any hw > > in the planing (so for next few years). > > > > Still we do want to support peer to peer mapping. Plan is to only do so > > with ODP capable hardware. Still we need to solve the IOMMU issue and > > it needs special handling inside the RDMA device. The way it works is > > that RDMA ask for a GPU page, GPU check if it has place inside its PCI > > bar to map this page for the device, this can fail. If it succeed then > > you need the IOMMU to let the RDMA device access the GPU PCI bar. > > > > So here we have 2 orthogonal problem. First one is how to make 2 drivers > > talks to each other to setup mapping to allow peer to peer But I would > > assume and
Enabling peer to peer device transactions for PCIe devices
Hello, I've been watching this thread not as a kernel developer, but as an user interested in doing peer-to-peer access between network card and GPU. I believe that merging raw direct access with vma overcomplicates things for our use case. We'll have a very large camera streaming data at high throughput (up to 100 Gbps) to the GPU, which will operate in soft real time mode and write back the results to a RDMA enabled network storage. The CPU will only arrange the connection between GPU and network card. Having things like paging or memory overcommit is possible, but they are not required and they might consistently decrease the quality of the data acquisition. I see my use case something likely to exist for others and a strong reason to split the implementation in two. 2017-01-05 16:01 GMT-03:00 Jason Gunthorpe : > On Thu, Jan 05, 2017 at 01:39:29PM -0500, Jerome Glisse wrote: > >> 1) peer-to-peer because of userspace specific API like NVidia GPU >> direct (AMD is pushing its own similar API i just can't remember >> marketing name). This does not happen through a vma, this happens >> through specific device driver call going through device specific >> ioctl on both side (GPU and RDMA). So both kernel driver are aware >> of each others. > > Today you can only do user-initiated RDMA operations in conjection > with a VMA. > > We'd need a really big and strong reason to create an entirely new > non-VMA based memory handle scheme for RDMA. > > So my inclination is to just completely push back on this idea. You > need a VMA to do RMA. > > GPUs need to create VMAs for the memory they want to RDMA from, even > if the VMA handle just causes SIGBUS for any CPU access. > > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Enabling peer to peer device transactions for PCIe devices
On 2017-01-05 08:58 PM, Jerome Glisse wrote: > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote: >> On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote: >> I still don't understand what you driving at - you've said in both cases a user VMA exists. >>> In the former case no, there is no VMA directly but if you want one than >>> a device can provide one. But such VMA is useless as CPU access is not >>> expected. >> I disagree it is useless, the VMA is going to be necessary to support >> upcoming things like CAPI, you need it to support O_DIRECT from the >> filesystem, DPDK, etc. This is why I am opposed to any model that is >> not VMA based for setting up RDMA - that is shorted sighted and does >> not seem to reflect where the industry is going. >> >> So focus on having VMA backed by actual physical memory that covers >> your GPU objects and ask how do we wire up the '__user *' to the DMA >> API in the best way so the DMA API still has enough information to >> setup IOMMUs and whatnot. > I am talking about 2 different thing. Existing hardware and API where you > _do not_ have a vma and you do not need one. This is just existing stuff. I do not understand why you assume that existing API doesn't need one. I would say that a lot of __existing__ user level API and their support in kernel (especially outside of graphics domain) assumes that we have vma and deal with __user * pointers. > Some close driver provide a functionality on top of this design. Question > is do we want to do the same ? If yes and you insist on having a vma we > could provide one but this is does not apply and is useless for where we > are going with new hardware. > > With new hardware you just use malloc or mmap to allocate memory and then > you use it directly with the device. Device driver can migrate any part of > the process address space to device memory. In this scheme you have your > usual VMAs but there is nothing special about them. Assuming that the whole device memory is CPU accessible and it looks like the direction where we are going: - You forgot about use case when we want or need to allocate memory directly on device (why we need to migrate anything if not needed?). - We may want to use CPU to access such memory on device to avoid any unnecessary migration back. - We may have more device memory than the system one. E.g. if you have 12 GPUs w/64GB each it will already give us ~0.7 TB not mentioning NVDIMM cards which could also be used as memory storage for other device access. - We also may want/need to share GPU memory between different processes. > Now when you try to do get_user_page() on any page that is inside the > device it will fails because we do not allow any device memory to be pin. > There is various reasons for that and they are not going away in any hw > in the planing (so for next few years). > > Still we do want to support peer to peer mapping. Plan is to only do so > with ODP capable hardware. Still we need to solve the IOMMU issue and > it needs special handling inside the RDMA device. The way it works is > that RDMA ask for a GPU page, GPU check if it has place inside its PCI > bar to map this page for the device, this can fail. If it succeed then > you need the IOMMU to let the RDMA device access the GPU PCI bar. > > So here we have 2 orthogonal problem. First one is how to make 2 drivers > talks to each other to setup mapping to allow peer to peer But I would assume > and second is > about IOMMU. > I think that there is the third problem: A lot of existing user level API (MPI, IB Verbs, file i/o, etc.) deal with pointers to the buffers. Potentially it would be ideally to support use cases when those buffers are located in device memory avoiding any unnecessary migration / double-buffering. Currently a lot of infrastructure in kernel assumes that this is the user pointer and call "get_user_pages" to get s/g. What is your opinion how it should be changed to deal with cases when "buffer" is in device memory?
Enabling peer to peer device transactions for PCIe devices
On Fri, Jan 06, 2017 at 12:37:22PM -0500, Jerome Glisse wrote: > On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote: > > On 2017-01-05 08:58 PM, Jerome Glisse wrote: > > > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote: > > > > On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote: > > > > > > > > > > I still don't understand what you driving at - you've said in both > > > > > > cases a user VMA exists. > > > > > In the former case no, there is no VMA directly but if you want one > > > > > than > > > > > a device can provide one. But such VMA is useless as CPU access is not > > > > > expected. > > > > I disagree it is useless, the VMA is going to be necessary to support > > > > upcoming things like CAPI, you need it to support O_DIRECT from the > > > > filesystem, DPDK, etc. This is why I am opposed to any model that is > > > > not VMA based for setting up RDMA - that is shorted sighted and does > > > > not seem to reflect where the industry is going. > > > > > > > > So focus on having VMA backed by actual physical memory that covers > > > > your GPU objects and ask how do we wire up the '__user *' to the DMA > > > > API in the best way so the DMA API still has enough information to > > > > setup IOMMUs and whatnot. > > > I am talking about 2 different thing. Existing hardware and API where you > > > _do not_ have a vma and you do not need one. This is just > > > > existing stuff. > > I do not understand why you assume that existing API doesn't need one. > > I would say that a lot of __existing__ user level API and their support in > > kernel (especially outside of graphics domain) assumes that we have vma and > > deal with __user * pointers. +1 > Well i am thinking to GPUDirect here. Some of GPUDirect use case do not have > vma (struct vm_area_struct) associated with them they directly apply to GPU > object that aren't expose to CPU. Yes some use case have vma for share buffer. Lets stop talkind about GPU direct. Today we can't even make VMA pointing at a PCI bar work properly in the kernel - lets start there please. People can argue over other options once that is done. > For HMM plan is to restrict to ODP and either to replace ODP with HMM or > change > ODP to not use get_user_pages_remote() but directly fetch informations from > CPU page table. Everything else stay as it is. I posted patchset to replace > ODP with HMM in the past. Make a generic API for all of this and you'd have my vote.. IMHO, you must support basic pinning semantics - that is necessary to support generic short lived DMA (eg filesystem, etc). That hardware can clearly do that if it can support ODP. Jason
[PATCH] drm: sti: implement CRC capture API
2017-01-06 10:58 GMT+01:00 Daniel Vetter : > On Fri, Jan 06, 2017 at 10:06:50AM +0100, Benjamin Gaignard wrote: >> 2017-01-06 9:22 GMT+01:00 Tomeu Vizoso : >> > On 5 January 2017 at 12:12, Benjamin Gaignard >> > wrote: >> >> Use CRC API to retrieve the 3 crc values from hardware. >> >> >> >> Signed-off-by: Benjamin Gaignard >> >> --- >> >> This patch should be applied on top of drm-misc branch where Tomeu >> >> has change crc.lock. >> >> >> >> I think that wake_up_interruptible() could also be call at the end >> >> of drm_crtc_add_crc_entry() to avoid putting it in all drivers. >> > >> > Agreed, I can send such a patch if you don't have time. >> >> I just finish to test the patches I will send them asap >> >> > >> > Btw, do any tests from iGT that make use of CRCs pass with this? If >> > so, would be good to note it in the commit message. >> >> I don't run IGT just modetest and cat on crtc-0/crc/data > > Would be really good if you can give igt a spin on this ... What is the status of IGT on ARM platforms ? Last time (~6 months ago) I tested it, I had to include intel drm lib and it just allow me to check drm version. Does that have change ? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Benjamin Gaignard Graphic Study Group Linaro.org â Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] drm: Schedule the output_poll_work with 1s delay if we have delayed event
On Thu, Jan 05, 2017 at 12:40:29PM +0200, Peter Ujfalusi wrote:
> On 01/05/2017 10:43 AM, Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 02:00:53PM +0200, Peter Ujfalusi wrote:
> >> Instead of scheduling the work to handle the initial delayed event, use 1s
> >> delay.
> >>
> >> When the delayed event is handled w/o delay - in a similar matter when the
> >> poll had been initialized before drm_helper_probe_single_connector_modes()
> >> is called - it triggers a race in Optimus setups.
> >>
> >> Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work
> >> scheduling")
> >> Cc: stable at vger.kernel.org # v4.9
> >> Signed-off-by: Peter Ujfalusi
> >> ---
> >> Hi,
> >>
> >> related bug report: https://bugs.freedesktop.org/show_bug.cgi?id=98690
> >>
> >> Regards,
> >> Peter
> >>
> >> drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> index 98ed110e28ed..f30c14b0a72f 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> @@ -146,8 +146,9 @@ void drm_kms_helper_poll_enable_locked(struct
> >> drm_device *dev)
> >>drm_connector_list_iter_put(_iter);
> >>
> >>if (dev->mode_config.delayed_event) {
> >> + /* Use short (1s) delay to handle the initial delayed event */
> >>poll = true;
> >> - delay = 0;
> >> + delay = HZ;
> >
> > This smells a bit like duct-tape papering over some other race.
>
> Yes, I agree. We could revert 339fd36238dd also to put back the duct-tape.
Since the revert and this patch are the same kind of duct-tape (massive
delay) I prefer something like this patch ...
>
> > Lack of
> > locking or something else. Most likely some drivers enable polling a bit
> > too early in their load sequence.
>
> All is pointing to Optimus. Intel and nouveau alone works, but we have
> failure on Optimus laptops.
> I have tried to narrow it down with another patch attached to the
> bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=128742
>
> I expected it to fix the problem. But it did not. So I'm puzzled.
>
> >And if we can't figure this out, then we
> > need some really big FIXME: here that this papers over driver races.
>
> Yeah, now we know that there is something wrong in some driver(s). We
> can hide it with delaying the poll_work. It would be great if
> nouveau/optimus guys would be able to take a look at this.
... but with all the above information (optimus only, what blows up)
condensed into both the commit message and a big WARNING comment in the
code. Then I think this is reasonable to merge (but still a decent wtf),
since it addresses a rather serious regression.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v5 3/3] drm: allow to use mmuless SoC
On Wed, Jan 04, 2017 at 10:12:57AM +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add a cma helper
> function to help implementing mmuless display driver
>
> version 4:
> - add documentation about drm_gem_cma_get_unmapped_area()
> - stub it MMU case
>
> Signed-off-by: Benjamin Gaignard
> ---
> Documentation/gpu/drm-mm.rst | 11 ++
> drivers/gpu/drm/Kconfig | 4 +-
> drivers/gpu/drm/drm_gem_cma_helper.c | 71
>
> include/drm/drm_gem_cma_helper.h | 17 +
> 4 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index bca8085..9d4aa11 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -303,6 +303,17 @@ created.
> Drivers that want to map the GEM object upfront instead of handling page
> faults can implement their own mmap file operation handler.
>
> +For platforms without MMU the GEM core provides a helper method
> +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call
> +this to get a proposed address for the mapping.
> +
> +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the
> +struct :c:type:`struct file_operations ` get_unmapped_area
> +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
I've switched this to the recommened struct member reference format, which
is _operations.get_unmapped_area and merged all 3 patches.
Thanks, Daniel
> +
> +More detailed information about get_unmapped_area can be found in
> +Documentation/nommu-mmap.txt
> +
> Memory Coherency
>
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f799696..c5b6f33 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -6,7 +6,7 @@
> #
> menuconfig DRM
> tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
> support)"
> - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
> + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> select HDMI
> select FB_CMDLINE
> select I2C
> @@ -98,7 +98,7 @@ config DRM_LOAD_EDID_FIRMWARE
>
> config DRM_TTM
> tristate
> - depends on DRM
> + depends on DRM && MMU
> help
> GPU memory management subsystem for devices with multiple
> GPU memory types. Will be enabled automatically if a device driver
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 1d6c335..19908bb 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -358,6 +358,77 @@ int drm_gem_cma_mmap(struct file *filp, struct
> vm_area_struct *vma)
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
>
> +#ifndef CONFIG_MMU
> +/**
> + * drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU cases
> + * @filp: file object
> + * @addr: memory address
> + * @len: buffer size
> + * @pgoff: page offset
> + * @flags: memory flags
> + *
> + * This function is used in noMMU platforms to propose address mapping
> + * for a given buffer.
> + * It's intended to be used as a direct handler for the struct
> _operations
> + * .get_unmapped_area() operation.
> + *
> + * Returns:
> + * mapping address on success or a negative error code on failure.
> + */
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags)
> +{
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *obj = NULL;
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> + struct drm_vma_offset_node *node;
> +
> + if (drm_device_is_unplugged(dev))
> + return -ENODEV;
> +
> + drm_vma_offset_lock_lookup(dev->vma_offset_manager);
> + node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
> + pgoff,
> + len >> PAGE_SHIFT);
> + if (likely(node)) {
> + obj = container_of(node, struct drm_gem_object, vma_node);
> + /*
> + * When the object is being freed, after it hits 0-refcnt it
> + * proceeds to tear down the object. In the process it will
> + * attempt to remove the VMA offset and so acquire this
> + * mgr->vm_lock. Therefore if we find an object with a 0-refcnt
> + * that matches our range, we know it is in the process of being
> +
[PATCH] drm: sti: implement CRC capture API
On Fri, Jan 06, 2017 at 10:06:50AM +0100, Benjamin Gaignard wrote: > 2017-01-06 9:22 GMT+01:00 Tomeu Vizoso : > > On 5 January 2017 at 12:12, Benjamin Gaignard > > wrote: > >> Use CRC API to retrieve the 3 crc values from hardware. > >> > >> Signed-off-by: Benjamin Gaignard > >> --- > >> This patch should be applied on top of drm-misc branch where Tomeu > >> has change crc.lock. > >> > >> I think that wake_up_interruptible() could also be call at the end > >> of drm_crtc_add_crc_entry() to avoid putting it in all drivers. > > > > Agreed, I can send such a patch if you don't have time. > > I just finish to test the patches I will send them asap > > > > > Btw, do any tests from iGT that make use of CRCs pass with this? If > > so, would be good to note it in the commit message. > > I don't run IGT just modetest and cat on crtc-0/crc/data Would be really good if you can give igt a spin on this ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v3 5/5] drm/rockchip: Implement CRC debugfs API
On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
wrote:
> Implement the .set_crc_source() callback and call the DP helpers
> accordingly to start and stop CRC capture.
>
> This is only done if this CRTC is currently using the eDP connector.
>
> v3: Remove superfluous check on rockchip_crtc_state->output_type
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48
> +
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb5f001f51c3..5e19bef6d5b4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1105,6 +1106,52 @@ static void vop_crtc_destroy_state(struct drm_crtc
> *crtc,
> kfree(s);
> }
>
> +static struct drm_connector *vop_get_edp_connector(struct vop *vop)
> +{
> + struct drm_crtc *crtc = >crtc;
> + struct drm_connector *connector;
> +
> + mutex_lock(>dev->mode_config.mutex);
> + drm_for_each_connector(connector, crtc->dev)
> + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + mutex_unlock(>dev->mode_config.mutex);
> + return connector;
> + }
> + mutex_unlock(>dev->mode_config.mutex);
> +
> + return NULL;
> +}
> +
> +static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
> + const char *source_name, size_t
> *values_cnt)
> +{
> + struct vop *vop = to_vop(crtc);
> + struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
> + struct drm_connector *connector;
> + int ret;
> +
> + connector = vop_get_edp_connector(vop);
> + if (!connector)
> + return -EINVAL;
> +
> + *values_cnt = 3;
> +
> + if (source_name &&
> + strcmp(source_name, "auto") == 0) {
> +
> + if (s->output_type != DRM_MODE_CONNECTOR_eDP)
> + return -EINVAL;
> +
> + ret = analogix_dp_start_crc(connector);
To pick up my thoughts from 1/5, you could do the following instead:
analogix_dp_start_crc(drm_crtc_index(crtc));
> + } else if (!source_name)
> +
> + ret = analogix_dp_stop_crc(connector);
> + else
> + ret = -EINVAL;
> +
> + return ret;
> +}
> +
> static const struct drm_crtc_funcs vop_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .page_flip = drm_atomic_helper_page_flip,
> @@ -1112,6 +1159,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
> .reset = vop_crtc_reset,
> .atomic_duplicate_state = vop_crtc_duplicate_state,
> .atomic_destroy_state = vop_crtc_destroy_state,
> + .set_crc_source = vop_crtc_set_crc_source,
> };
>
> static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
> --
> 2.9.3
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Sean Paul, Software Engineer, Google / Chromium OS
[PATCH v3 3/5] drm/dp: add helpers for capture of frame CRCs
On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
wrote:
> Adds helpers for starting and stopping capture of frame CRCs through the
> DPCD. When capture is on, a worker waits for vblanks and retrieves the
> frame CRC to put it in the queue on the CRTC that is using the
> eDP connector, so it's passed to userspace.
>
> v2: Reuse drm_crtc_wait_one_vblank
> Update locking, as drm_crtc_add_crc_entry now takes the lock
>
> v3: Don't call wake_up_interruptible directly, that's now done in
> drm_crtc_add_crc_entry.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> drivers/gpu/drm/drm_dp_helper.c | 118
>
> include/drm/drm_dp_helper.h | 7 +++
> 2 files changed, 125 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 3e6fe82c6d64..e531f1317268 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -981,6 +981,74 @@ static const struct i2c_lock_operations
> drm_dp_i2c_lock_ops = {
> .unlock_bus = unlock_bus,
> };
>
> +static int drm_dp_aux_get_crc(struct drm_dp_aux *aux, u8 *crc)
> +{
> + u8 buf, count;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
> + if (ret < 0)
> + return ret;
> +
> + WARN_ON(!(buf & DP_TEST_SINK_START));
> +
> + ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK_MISC, );
> + if (ret < 0)
> + return ret;
> +
> + count = buf & DP_TEST_COUNT_MASK;
> + if (count == aux->crc_count)
> + return -EAGAIN; /* No CRC yet */
> +
> + aux->crc_count = count;
> +
> + /* At DP_TEST_CRC_R_CR, there's 6 bytes containing CRC data, 2 bytes
> +* per component (RGB or CrYCb).
nit: doesn't conform to CodingStyle
> +*/
> + ret = drm_dp_dpcd_read(aux, DP_TEST_CRC_R_CR, crc, 6);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void drm_dp_aux_crc_work(struct work_struct *work)
> +{
> + struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
> + crc_work);
> + struct drm_crtc *crtc;
> + u8 crc_bytes[6];
> + uint32_t crcs[3];
> + int ret;
> +
> + if (WARN_ON(!aux->connector))
> + return;
> +
> + crtc = aux->connector->state->crtc;
> + while (crtc->crc.opened) {
> + drm_crtc_wait_one_vblank(crtc);
> + if (!crtc->crc.opened)
> + break;
> +
> + ret = drm_dp_aux_get_crc(aux, crc_bytes);
> + if (ret == -EAGAIN) {
> + usleep_range(1000, 2000);
> + ret = drm_dp_aux_get_crc(aux, crc_bytes);
> + }
> +
> + if (ret) {
> + DRM_DEBUG_KMS("Failed to get a CRC even after
> retrying: %d\n",
> + ret);
> + continue;
> + }
I think it'd be better to restructure this to only call
drm_dp_aux_get_crc in one place (and differentiate between EAGAIN and
other failures):
bool retry = false;
while (...) {
...
ret = drm_dp_aux_get_crc(aux, crc_bytes);
if (ret == -EAGAIN) {
if (retry)
DRM_DEBUG_KMS("Get CRC failed after retrying: %d\n",
ret);
retry = !retry;
usleep_range(1000, 2000);
continue;
}
retry = false;
if (!ret) {
crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
if (ret)
DRM_DEBUG_KMS("Failed to add crc entry %d\n", ret);
} else {
DRM_DEBUG_KMS("Get CRC failed: %d\n", ret);
}
}
> +
> + crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
> + crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
> + crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
> + ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
> + }
> +}
> +
> /**
> * drm_dp_aux_init() - minimally initialise an aux channel
> * @aux: DisplayPort AUX channel
> @@ -993,6 +1061,7 @@ static const struct i2c_lock_operations
> drm_dp_i2c_lock_ops = {
> void drm_dp_aux_init(struct drm_dp_aux *aux)
> {
> mutex_init(>hw_mutex);
> + INIT_WORK(>crc_work, drm_dp_aux_crc_work);
>
> aux->ddc.algo = _dp_i2c_algo;
> aux->ddc.algo_data = aux;
> @@ -1081,3 +1150,52 @@ int drm_dp_psr_setup_time(const u8
> psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
> EXPORT_SYMBOL(drm_dp_psr_setup_time);
>
> #undef PSR_SETUP_TIME
> +
> +/**
> + * drm_dp_start_crc() - start capture of frame CRCs
> + * @aux: DisplayPort AUX
[PATCH v3 1/5] drm/dp: add connector backpointer to drm_dp_aux
On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
wrote:
> This backpointer allows DP helpers to access the connector it's being
> used for.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> include/drm/drm_dp_helper.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 55bbeb0ff594..4fa77b434594 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -721,6 +721,7 @@ struct drm_dp_aux_msg {
> * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
> * @ddc: I2C adapter that can be used for I2C-over-AUX communication
> * @dev: pointer to struct device that is the parent for this AUX channel
> + * @connector: backpointer to connector that uses this AUX channel
> * @hw_mutex: internal mutex used for locking transfers
> * @transfer: transfers a message representing a single AUX transaction
> *
> @@ -757,6 +758,7 @@ struct drm_dp_aux {
> const char *name;
> struct i2c_adapter ddc;
> struct device *dev;
> + struct drm_connector *connector;
Perhaps I'm misreading the series, but it seems like you could instead
add int crc_pipe along with the other crc fields. Then when you start
the crc, set the pipe number. If you have the pipe in the crc worker,
you can wait vblank on that pipe (no pointers needed).
Reasonable?
Sean
> struct mutex hw_mutex;
> ssize_t (*transfer)(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg);
> --
> 2.9.3
>
--
Sean Paul, Software Engineer, Google / Chromium OS
[PATCH v2 2/2] drm: sti: implement CRC capture API
Use CRC API to retrieve the 3 crc values from hardware.
Signed-off-by: Benjamin Gaignard
---
This patch should be applied on top of drm-misc branch where Tomeu
has change crc.lock.
Cc: Tomeu Vizoso
Cc: Daniel Vetter
---
drivers/gpu/drm/sti/sti_crtc.c | 23 ++
drivers/gpu/drm/sti/sti_mixer.c | 52 +
drivers/gpu/drm/sti/sti_mixer.h | 4
3 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index e992bed..caf5d61 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -20,6 +20,8 @@
#include "sti_vid.h"
#include "sti_vtg.h"
+#define CRC_SAMPLES 3
+
static void sti_crtc_enable(struct drm_crtc *crtc)
{
struct sti_mixer *mixer = to_sti_mixer(crtc);
@@ -253,6 +255,7 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
unsigned long flags;
struct sti_private *priv;
unsigned int pipe;
+ u32 crcs[CRC_SAMPLES];
priv = crtc->dev->dev_private;
pipe = drm_crtc_index(crtc);
@@ -275,6 +278,9 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
}
spin_unlock_irqrestore(>dev->event_lock, flags);
+ if (!sti_mixer_read_crcs(mixer, [0], [1], [2]))
+ drm_crtc_add_crc_entry(crtc, false, 0, crcs);
+
if (mixer->status == STI_MIXER_DISABLING) {
struct drm_plane *p;
@@ -343,6 +349,22 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
return 0;
}
+int sti_set_crc_source(struct drm_crtc *crtc, const char *source,
+ size_t *values_cnt)
+{
+ struct sti_mixer *mixer = to_sti_mixer(crtc);
+
+ *values_cnt = CRC_SAMPLES;
+
+ if (!source)
+ return sti_mixer_set_crc_status(mixer, false);
+
+ if (source && strcmp(source, "auto") == 0)
+ return sti_mixer_set_crc_status(mixer, true);
+
+ return -EINVAL;
+}
+
static const struct drm_crtc_funcs sti_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -352,6 +374,7 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.late_register = sti_crtc_late_register,
+ .set_crc_source = sti_set_crc_source,
};
bool sti_crtc_is_main(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index 4ddc58f..e245ef7 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -27,6 +27,13 @@
#define GAM_MIXER_ACT 0x38
#define GAM_MIXER_MBP 0x3C
#define GAM_MIXER_MX0 0x80
+#define GAM_MIXER_MISR_CTL 0xA0
+#define GAM_MIXER_MISR_STA 0xA4
+#define GAM_MIXER_SIGN10xA8
+#define GAM_MIXER_SIGN20xAC
+#define GAM_MIXER_SIGN30xB0
+#define GAM_MIXER_MISR_AVO 0xB4
+#define GAM_MIXER_MISR_AVS 0xB8
/* id for depth of CRB reg */
#define GAM_DEPTH_VID0_ID 1
@@ -47,6 +54,10 @@
#define GAM_CTL_GDP3_MASK BIT(6)
#define GAM_CTL_CURSOR_MASK BIT(9)
+#define GAM_MISR_EN (BIT(1) | BIT(2) | BIT(3))
+#define GAM_MISR_RST_STA BIT(0)
+#define GAM_MISR_TEST_RSLT_VALID BIT(0)
+
const char *sti_mixer_to_str(struct sti_mixer *mixer)
{
switch (mixer->id) {
@@ -162,6 +173,13 @@ static int mixer_dbg_show(struct seq_file *s, void *arg)
DBGFS_DUMP(GAM_MIXER_MBP);
DBGFS_DUMP(GAM_MIXER_MX0);
mixer_dbg_mxn(s, mixer->regs + GAM_MIXER_MX0);
+ DBGFS_DUMP(GAM_MIXER_MISR_CTL);
+ DBGFS_DUMP(GAM_MIXER_MISR_STA);
+ DBGFS_DUMP(GAM_MIXER_SIGN1);
+ DBGFS_DUMP(GAM_MIXER_SIGN2);
+ DBGFS_DUMP(GAM_MIXER_SIGN3);
+ DBGFS_DUMP(GAM_MIXER_MISR_AVO);
+ DBGFS_DUMP(GAM_MIXER_MISR_AVS);
seq_puts(s, "\n");
return 0;
@@ -202,6 +220,37 @@ int sti_mixer_debugfs_init(struct sti_mixer *mixer, struct
drm_minor *minor)
minor->debugfs_root, minor);
}
+int sti_mixer_set_crc_status(struct sti_mixer *mixer, bool enable)
+{
+ if (enable) {
+ sti_mixer_reg_read(mixer, GAM_MIXER_MISR_STA);
+ sti_mixer_reg_read(mixer, GAM_MIXER_SIGN1);
+ sti_mixer_reg_read(mixer, GAM_MIXER_SIGN2);
+ sti_mixer_reg_read(mixer, GAM_MIXER_SIGN3);
+ sti_mixer_reg_write(mixer, GAM_MIXER_MISR_CTL,
+ GAM_MISR_EN | GAM_MISR_RST_STA);
+ } else {
+ sti_mixer_reg_write(mixer, GAM_MIXER_MISR_CTL, 0x00);
+ }
+
+ return 0;
+}
+
+int sti_mixer_read_crcs(struct sti_mixer *mixer,
+ u32 *sign1, u32 *sign2, u32 *sign3)
+{
+ u32 status = sti_mixer_reg_read(mixer, GAM_MIXER_MISR_STA);
+
+ if (!(status & GAM_MISR_TEST_RSLT_VALID))
+ return -EAGAIN;
+
+ *sign1 = sti_mixer_reg_read(mixer,
[PATCH v2 1/2] drm: crc: Call wake_up_interruptible() each time there is a new CRC entry
Each time new data has being added in CRC list inform reader by calling wake_up_interruptible(). This should avoid to do it in all drivers. Signed-off-by: Benjamin Gaignard Cc: Tomeu Vizoso Cc: Daniel Vetter --- drivers/gpu/drm/drm_debugfs_crc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index 8b0..96891c4 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -363,6 +363,8 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, spin_unlock(>lock); + wake_up_interruptible(>wq); + return 0; } EXPORT_SYMBOL_GPL(drm_crtc_add_crc_entry); -- 1.9.1
[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Hi Laurent, Sorry for the delayed answer but I am quite busy at the moment. On 06-01-2017 01:48, Laurent Pinchart wrote: [snip] The TX_READY signal is documented in the i.MX6 datasheet as being a PHY output signal, but there seems to be no HDMI TX register from which its state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register through I2C ? How long is the PHY expected to take to set TX_READY to 0 ? >>> TX_READY can be read from register 0x1A of phy, BIT(2) (through >>> I2C). >> That's what I thought, I'll poll that then. Do you have any idea how long >> it's supposed to take, to set an appropriate timeout ? For 3d tx phy and for 25 MHz input reference clock the power-up time is ~1ms, there is no data in the docs to power-down time but it should be similar. Reference clock value is board dependent and the minimum value for HDMI shall be 13.5MHz. > On i.MX6 (3D TX PHY) register 0x1a reads as 0x0007 before powering down the > PHY (by deasserting TXPWRON) and as 0x immediately after. On RK3288 (MHL > PHY) the register reads as 0x0207 and as 0x immediately after deasserting > TXPWRON. It seems that one I2C read is a sufficient delay for TX_READY to go > low. >>> Not sure if same offset for all phys though. >> Most probably not, it would be too easy :-) I'll investigate (which will >> likely include lots of guesswork). If you can find any information about >> that (and especially about the MHL and HDMI 2.0 PHYs) that would be very >> appreciated, as I don't have access to any documentation that mentions a >> TX_READY bit for those. > I haven't tested the HDMI 2.0 PHY yet, but I'd be surprised if the TX_READY > bit was in the same register at the same position. > The info I got the register offset is from an HDMI 2.0 phy :) Notice that there are a lot of phy versions and some of them (used in dw-hdmi) maybe customized, I don't think I have access to that custom phys documentation. Please test the HDMI 2.0 phy and check if the register is the same, it should be. In the meantime it would really be helpful if some of the developers that used dw-hdmi supplied this info about the registers as they should know exactly what phy was used. Best regards, Jose Miguel Abreu
[PATCH] drm: sti: implement CRC capture API
2017-01-06 9:22 GMT+01:00 Tomeu Vizoso :
> On 5 January 2017 at 12:12, Benjamin Gaignard
> wrote:
>> Use CRC API to retrieve the 3 crc values from hardware.
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> This patch should be applied on top of drm-misc branch where Tomeu
>> has change crc.lock.
>>
>> I think that wake_up_interruptible() could also be call at the end
>> of drm_crtc_add_crc_entry() to avoid putting it in all drivers.
>
> Agreed, I can send such a patch if you don't have time.
I just finish to test the patches I will send them asap
>
> Btw, do any tests from iGT that make use of CRCs pass with this? If
> so, would be good to note it in the commit message.
I don't run IGT just modetest and cat on crtc-0/crc/data
>
>> Cc: Tomeu Vizoso
>> Cc: Daniel Vetter
>> ---
>> drivers/gpu/drm/sti/sti_crtc.c | 27 +++
>> drivers/gpu/drm/sti/sti_mixer.c | 47
>> +
>> drivers/gpu/drm/sti/sti_mixer.h | 4
>> 3 files changed, 78 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
>> index e992bed..47022b4 100644
>> --- a/drivers/gpu/drm/sti/sti_crtc.c
>> +++ b/drivers/gpu/drm/sti/sti_crtc.c
>> @@ -20,6 +20,8 @@
>> #include "sti_vid.h"
>> #include "sti_vtg.h"
>>
>> +#define CRC_SAMPLES 3
>> +
>> static void sti_crtc_enable(struct drm_crtc *crtc)
>> {
>> struct sti_mixer *mixer = to_sti_mixer(crtc);
>> @@ -253,6 +255,8 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
>> unsigned long flags;
>> struct sti_private *priv;
>> unsigned int pipe;
>> + u32 crcs[CRC_SAMPLES];
>> + int ret;
>>
>> priv = crtc->dev->dev_private;
>> pipe = drm_crtc_index(crtc);
>> @@ -275,6 +279,12 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
>> }
>> spin_unlock_irqrestore(>dev->event_lock, flags);
>>
>> + if (!sti_mixer_read_crcs(mixer, [0], [1], [2])) {
>
> nit: I would place the return value of that function into ret, so it's
> easier to read and easier to instrument when debugging (and maybe log
> a debug message if it fails?).
sti_mixer_read_crcs() is called even if crc isn't enabled so status
bit could be set
at 0 without being an error...
>> + ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
>
> Doesn't the frame number returned by drm_accurate_vblank_count()
> correspond to the fb contents characterized by these crcs?
My driver doesn't implement get_vblank_timestamp() so
drm_accurate_vblank_count()
won't work.
> When the CRCs come from a sink, we don't have a good way of knowing to
> which frame count they correspond, but in this case I would expect
> that the mixer was programmed with the new fb contents for this vblank
> count.
>
> Tests can be more extensive if there are frame numbers.
>
>> + if (!ret)
>> + wake_up_interruptible(>crc.wq);
>> + }
>> +
>> if (mixer->status == STI_MIXER_DISABLING) {
>> struct drm_plane *p;
>>
>> @@ -343,6 +353,22 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
>> return 0;
>> }
>>
>> +int sti_set_crc_source(struct drm_crtc *crtc, const char *source,
>> + size_t *values_cnt)
>> +{
>> + struct sti_mixer *mixer = to_sti_mixer(crtc);
>> +
>> + *values_cnt = CRC_SAMPLES;
>> +
>> + if (!source)
>> + return sti_mixer_set_crc_status(mixer, false);
>> +
>> + if (source && strcmp(source, "auto") == 0)
>> + return sti_mixer_set_crc_status(mixer, true);
>> +
>> + return -EINVAL;
>> +}
>> +
>> static const struct drm_crtc_funcs sti_crtc_funcs = {
>> .set_config = drm_atomic_helper_set_config,
>> .page_flip = drm_atomic_helper_page_flip,
>> @@ -352,6 +378,7 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
>> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>> .late_register = sti_crtc_late_register,
>> + .set_crc_source = sti_set_crc_source,
>> };
>>
>> bool sti_crtc_is_main(struct drm_crtc *crtc)
>> diff --git a/drivers/gpu/drm/sti/sti_mixer.c
>> b/drivers/gpu/drm/sti/sti_mixer.c
>> index 4ddc58f..4eb5cc5 100644
>> --- a/drivers/gpu/drm/sti/sti_mixer.c
>> +++ b/drivers/gpu/drm/sti/sti_mixer.c
>> @@ -27,6 +27,13 @@
>> #define GAM_MIXER_ACT 0x38
>> #define GAM_MIXER_MBP 0x3C
>> #define GAM_MIXER_MX0 0x80
>> +#define GAM_MIXER_MISR_CTL 0xA0
>> +#define GAM_MIXER_MISR_STA 0xA4
>> +#define GAM_MIXER_SIGN10xA8
>> +#define GAM_MIXER_SIGN20xAC
>> +#define GAM_MIXER_SIGN30xB0
>> +#define GAM_MIXER_MISR_AVO 0xB4
>> +#define GAM_MIXER_MISR_AVS 0xB8
>>
>> /* id for depth of CRB reg */
>> #define GAM_DEPTH_VID0_ID 1
>> @@ -162,6 +169,13 @@ static int mixer_dbg_show(struct seq_file *s, void *arg)
>> DBGFS_DUMP(GAM_MIXER_MBP);
>>
[PATCH] drm: sti: implement CRC capture API
On 5 January 2017 at 12:12, Benjamin Gaignard
wrote:
> Use CRC API to retrieve the 3 crc values from hardware.
>
> Signed-off-by: Benjamin Gaignard
> ---
> This patch should be applied on top of drm-misc branch where Tomeu
> has change crc.lock.
>
> I think that wake_up_interruptible() could also be call at the end
> of drm_crtc_add_crc_entry() to avoid putting it in all drivers.
Agreed, I can send such a patch if you don't have time.
Btw, do any tests from iGT that make use of CRCs pass with this? If
so, would be good to note it in the commit message.
> Cc: Tomeu Vizoso
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/sti/sti_crtc.c | 27 +++
> drivers/gpu/drm/sti/sti_mixer.c | 47
> +
> drivers/gpu/drm/sti/sti_mixer.h | 4
> 3 files changed, 78 insertions(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index e992bed..47022b4 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -20,6 +20,8 @@
> #include "sti_vid.h"
> #include "sti_vtg.h"
>
> +#define CRC_SAMPLES 3
> +
> static void sti_crtc_enable(struct drm_crtc *crtc)
> {
> struct sti_mixer *mixer = to_sti_mixer(crtc);
> @@ -253,6 +255,8 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
> unsigned long flags;
> struct sti_private *priv;
> unsigned int pipe;
> + u32 crcs[CRC_SAMPLES];
> + int ret;
>
> priv = crtc->dev->dev_private;
> pipe = drm_crtc_index(crtc);
> @@ -275,6 +279,12 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
> }
> spin_unlock_irqrestore(>dev->event_lock, flags);
>
> + if (!sti_mixer_read_crcs(mixer, [0], [1], [2])) {
nit: I would place the return value of that function into ret, so it's
easier to read and easier to instrument when debugging (and maybe log
a debug message if it fails?).
> + ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
Doesn't the frame number returned by drm_accurate_vblank_count()
correspond to the fb contents characterized by these crcs?
When the CRCs come from a sink, we don't have a good way of knowing to
which frame count they correspond, but in this case I would expect
that the mixer was programmed with the new fb contents for this vblank
count.
Tests can be more extensive if there are frame numbers.
> + if (!ret)
> + wake_up_interruptible(>crc.wq);
> + }
> +
> if (mixer->status == STI_MIXER_DISABLING) {
> struct drm_plane *p;
>
> @@ -343,6 +353,22 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
> return 0;
> }
>
> +int sti_set_crc_source(struct drm_crtc *crtc, const char *source,
> + size_t *values_cnt)
> +{
> + struct sti_mixer *mixer = to_sti_mixer(crtc);
> +
> + *values_cnt = CRC_SAMPLES;
> +
> + if (!source)
> + return sti_mixer_set_crc_status(mixer, false);
> +
> + if (source && strcmp(source, "auto") == 0)
> + return sti_mixer_set_crc_status(mixer, true);
> +
> + return -EINVAL;
> +}
> +
> static const struct drm_crtc_funcs sti_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .page_flip = drm_atomic_helper_page_flip,
> @@ -352,6 +378,7 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> .late_register = sti_crtc_late_register,
> + .set_crc_source = sti_set_crc_source,
> };
>
> bool sti_crtc_is_main(struct drm_crtc *crtc)
> diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
> index 4ddc58f..4eb5cc5 100644
> --- a/drivers/gpu/drm/sti/sti_mixer.c
> +++ b/drivers/gpu/drm/sti/sti_mixer.c
> @@ -27,6 +27,13 @@
> #define GAM_MIXER_ACT 0x38
> #define GAM_MIXER_MBP 0x3C
> #define GAM_MIXER_MX0 0x80
> +#define GAM_MIXER_MISR_CTL 0xA0
> +#define GAM_MIXER_MISR_STA 0xA4
> +#define GAM_MIXER_SIGN10xA8
> +#define GAM_MIXER_SIGN20xAC
> +#define GAM_MIXER_SIGN30xB0
> +#define GAM_MIXER_MISR_AVO 0xB4
> +#define GAM_MIXER_MISR_AVS 0xB8
>
> /* id for depth of CRB reg */
> #define GAM_DEPTH_VID0_ID 1
> @@ -162,6 +169,13 @@ static int mixer_dbg_show(struct seq_file *s, void *arg)
> DBGFS_DUMP(GAM_MIXER_MBP);
> DBGFS_DUMP(GAM_MIXER_MX0);
> mixer_dbg_mxn(s, mixer->regs + GAM_MIXER_MX0);
> + DBGFS_DUMP(GAM_MIXER_MISR_CTL);
> + DBGFS_DUMP(GAM_MIXER_MISR_STA);
> + DBGFS_DUMP(GAM_MIXER_SIGN1);
> + DBGFS_DUMP(GAM_MIXER_SIGN2);
> + DBGFS_DUMP(GAM_MIXER_SIGN3);
> + DBGFS_DUMP(GAM_MIXER_MISR_AVO);
> + DBGFS_DUMP(GAM_MIXER_MISR_AVS);
> seq_puts(s, "\n");
>
> return 0;
> @@ -202,6 +216,36 @@ int sti_mixer_debugfs_init(struct sti_mixer *mixer,
> struct drm_minor *minor)
>
[GIT PULL] VFIO fixes for v4.10-rc3
Hi Linus, This pull request has a merge conflict and requires a build fix with kvmgt (merged in ed40875), which is a consumer of the new vfio-mdev work. Stephen Rothwell has fixed both of these correctly for linux-next as documented here: merge conflict: http://marc.info/?l=linux-next=148340046329214 build fix: https://lkml.org/lkml/2017/1/2/521 Please make the corresponding changes in your merge. Thanks! Alex The following changes since commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1: mm/filemap: fix parameters to test_bit() (2016-12-29 14:46:39 -0800) are available in the git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-v4.10-rc3 for you to fetch changes up to c6ef7fd40eddad38a8825cbd6bb2ce8bdbba88f5: vfio-mdev: fix non-standard ioctl return val causing i386 build fail (2017-01-04 13:22:38 -0700) VFIO fixes for v4.10-rc3 - Add mtty sample driver properly into build system (Alex Williamson) - Restore type1 mapping performance after mdev (Alex Williamson) - Fix mdev device race (Alex Williamson) - Cleanups to the mdev ABI used by vendor drivers (Alex Williamson) - Build fix for old compilers (Arnd Bergmann) - Fix sample driver error path (Dan Carpenter) - Handle pci_iomap() error (Arvind Yadav) - Fix mdev ioctl return type (Paul Gortmaker) Alex Williamson (6): vfio-mdev: Fix mtty sample driver building vfio/type1: Restore mapping performance with mdev support vfio-mdev: Fix remove race vfio-mdev: de-polute the namespace, rename parent_device & parent_ops vfio-mdev: Make mdev_parent private vfio-mdev: Make mdev_device private and abstract interfaces Arnd Bergmann (1): vfio-pci: use 32-bit comparisons for register address for gcc-4.5 Arvind Yadav (1): vfio-pci: Handle error from pci_iomap Dan Carpenter (1): vfio-mdev: fix some error codes in the sample code Paul Gortmaker (1): vfio-mdev: fix non-standard ioctl return val causing i386 build fail Documentation/vfio-mediated-device.txt | 27 + drivers/gpu/drm/i915/gvt/kvmgt.c | 22 drivers/vfio/mdev/mdev_core.c | 100 +++-- drivers/vfio/mdev/mdev_private.h | 29 +- drivers/vfio/mdev/mdev_sysfs.c | 8 +-- drivers/vfio/mdev/vfio_mdev.c | 12 ++-- drivers/vfio/pci/vfio_pci.c| 4 ++ drivers/vfio/pci/vfio_pci_rdwr.c | 5 +- drivers/vfio/vfio_iommu_type1.c| 98 include/linux/mdev.h | 56 +- samples/Kconfig| 7 +++ samples/Makefile | 3 +- samples/vfio-mdev/Makefile | 14 + samples/vfio-mdev/mtty.c | 32 ++- 14 files changed, 246 insertions(+), 171 deletions(-)
[Bug 99292] GPU hang in High Fidelity
https://bugs.freedesktop.org/show_bug.cgi?id=99292 --- Comment #2 from Christoph Haag --- Oops, it has the same name, so I overwrote the other one. It really should be a new trace though. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/a8054767/attachment.html>
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #26 from Michel Dänzer --- (In reply to Eugenij Shkrigunov from comment #23) > I have no symptoms from #99078 The bug results in incorrect shader code generation, which could cause other symptoms. If reverting that commit doesn't help, you could try bisecting between LLVM 3.9.0 and 3.9.1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/4c999e4f/attachment.html>
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #25 from Eugenij Shkrigunov --- Sorry for the noise, this information may be helpful. I have installed mesa-13.0.3, latest Steam beta (with fix libxcb, libX) and llvm-3.9.1: "Star Conflict" randomly hang whole computer (only SysRq helps). After downgrade to llvm-3.9.0 "Star Conflict" does not hang computer anymore. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/9a8f81f4/attachment.html>
Please add fbdev-for-next to linux-next
Hi Bartlomiej, On Thu, 05 Jan 2017 12:45:32 +0100 Bartlomiej Zolnierkiewicz wrote: > > Could you please add: > > git://github.com/bzolnier/linux.git fbdev-for-next > > To the linux-next tree? > > Linus has recently accepted u pull request from the fbdev-v4.10-rc2 > tag that added fbdev subsystem back into Maintained mode (with me as > Maintainer). Added from today. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au
[Bug 99191] Weird blocky green stuff rendered in High Fidelity
https://bugs.freedesktop.org/show_bug.cgi?id=99191 --- Comment #3 from Samuel Pitoiset --- I think the correct status should be NOTOURBUG but whatever. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/b33d6e73/attachment.html>
[PATCH] drm/via: use get_user_pages_unlocked()
On 3 January 2017 at 20:23, Lorenzo Stoakes wrote:
> Hi All,
>
> Just a gentle ping on this one :)
>
> Cheers, Lorenzo
>
> On 1 November 2016 at 19:43, Lorenzo Stoakes wrote:
>> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
>> and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
>>
>> Signed-off-by: Lorenzo Stoakes
>> ---
>> drivers/gpu/drm/via/via_dmablit.c | 10 +++---
>> 1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/via/via_dmablit.c
>> b/drivers/gpu/drm/via/via_dmablit.c
>> index 1a3ad76..98aae98 100644
>> --- a/drivers/gpu/drm/via/via_dmablit.c
>> +++ b/drivers/gpu/drm/via/via_dmablit.c
>> @@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,
>> drm_via_dmablit_t *xfer)
>> vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
>> if (NULL == vsg->pages)
>> return -ENOMEM;
>> - down_read(>mm->mmap_sem);
>> - ret = get_user_pages((unsigned long)xfer->mem_addr,
>> -vsg->num_pages,
>> -(vsg->direction == DMA_FROM_DEVICE) ?
>> FOLL_WRITE : 0,
>> -vsg->pages, NULL);
>> -
>> - up_read(>mm->mmap_sem);
>> + ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
>> + vsg->num_pages, vsg->pages,
>> + (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE :
>> 0);
>> if (ret != vsg->num_pages) {
>> if (ret < 0)
>> return ret;
>> --
>> 2.10.2
>>
Adding Andrew, as this may be another less active corner of the corner, thanks!
--
Lorenzo Stoakes
https://ljs.io
[PULL] drm-intel-fixes
On 6 January 2017 at 04:29, Linus Torvalds wrote: > On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula wrote: >> >> Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure, > > I'm going to ignore this on the assumption that Dave is around. But if > nothing happens for a few days, ping me again and I'll pull it > directly. Ok? Ack from me for direct pull, I'm only on email/irc until Monday/Tuesday next week, then off again until LCA, then LCA. Dave.
[Bug 99292] GPU hang in High Fidelity
https://bugs.freedesktop.org/show_bug.cgi?id=99292 --- Comment #1 from smoki --- This is same trace like in closed bug 99191 that no driver could run normaly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/8a25b22c/attachment-0001.html>
[Bug 99191] Weird blocky green stuff rendered in High Fidelity
https://bugs.freedesktop.org/show_bug.cgi?id=99191 smoki changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from smoki --- Yup, trace does not even run with AMD blob also... likely does not work anywhere. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/e80558d9/attachment.html>
[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Hi Jose,
On Thursday 05 Jan 2017 17:33:58 Laurent Pinchart wrote:
> On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> > On 05-01-2017 12:29, Laurent Pinchart wrote:
> >> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >>> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> > Instead of spreading version-dependent PHY power handling code
> > around, group it in two functions to power the PHY on and off and use
> > them through the driver.
> >
> > Powering off the PHY at the beginning of the setup phase is currently
> > split in two locations for first and second generation PHYs, group
> > all the operations in the dw_hdmi_phy_init() function.
>
> This changes the behaviour of the driver.
>
> > +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > +{
> > + if (hdmi->phy->gen == 1) {
> > + dw_hdmi_phy_enable_tmds(hdmi, 0);
> > + dw_hdmi_phy_enable_powerdown(hdmi, true);
> > + } else {
> > + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> > + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> > + }
> > +}
> > @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi)
> > if (!hdmi->phy_enabled)
> > return;
> >
> > - dw_hdmi_phy_enable_tmds(hdmi, 0);
> > - dw_hdmi_phy_enable_powerdown(hdmi, true);
> > -
> > + dw_hdmi_phy_power_off(hdmi);
>
> This makes dw_hdmi_phy_disable() power down a gen2 phy.
>
> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> gen2 phy. I've been carrying this change for a while, which I've had
> to revert (and finally expunge), as it causes problems on iMX6:
>
> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> *hdmi)
> if (!hdmi->phy_enabled)
> return;
>
> + /* Actually set the phy into low power mode */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> +
> + /* FIXME: We should wait for TX_READY to be deasserted */
> +
> + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> +
> + /* This appears to have no effect on iMX6 */
> dw_hdmi_phy_enable_tmds(hdmi, 0);
> dw_hdmi_phy_enable_powerdown(hdmi, true);
>
> So, I think your change here will cause problems for iMX6.
>
> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> bouncing when the PHY is powered down. I can't promise when I'll be
> able to check for that again.
> >>>
> >>> Indeed TX_READY must be low before asserting pddq.
> >>
> >> The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
> >> output signal, but there seems to be no HDMI TX register from which its
> >> state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
> >> through I2C ? How long is the PHY expected to take to set TX_READY to 0
> >> ?
> >
> > TX_READY can be read from register 0x1A of phy, BIT(2) (through
> > I2C).
>
> That's what I thought, I'll poll that then. Do you have any idea how long
> it's supposed to take, to set an appropriate timeout ?
On i.MX6 (3D TX PHY) register 0x1a reads as 0x0007 before powering down the
PHY (by deasserting TXPWRON) and as 0x immediately after. On RK3288 (MHL
PHY) the register reads as 0x0207 and as 0x immediately after deasserting
TXPWRON. It seems that one I2C read is a sufficient delay for TX_READY to go
low.
> > Not sure if same offset for all phys though.
>
> Most probably not, it would be too easy :-) I'll investigate (which will
> likely include lots of guesswork). If you can find any information about
> that (and especially about the MHL and HDMI 2.0 PHYs) that would be very
> appreciated, as I don't have access to any documentation that mentions a
> TX_READY bit for those.
I haven't tested the HDMI 2.0 PHY yet, but I'd be surprised if the TX_READY
bit was in the same register at the same position.
--
Regards,
Laurent Pinchart
[Bug 98743] Incorrect colormapping in Verdun game
https://bugs.freedesktop.org/show_bug.cgi?id=98743 --- Comment #4 from piejacker875 at gmail.com --- Here's an apitrace https://transfer.sh/tzF87/verdun.x86-64.trace.xz -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/723b7ec0/attachment.html>
[Bug 98743] Incorrect colormapping in Verdun game
https://bugs.freedesktop.org/show_bug.cgi?id=98743 piejacker875 at gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #3 from piejacker875 at gmail.com --- So this same issue just started happening again today. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/9ec9d3c4/attachment.html>
[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2
Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of PSR2_STATUS register, which has wrong data, resulting
in blankscreen.
hsw_enable_source is split into hsw_enable_source_psr1 and
hsw_enable_source_psr2 for easier code review and maintenance,
as suggested by rodrigo and jim.
v2: (Vivi Rodrigo)
- Rename hsw_enable_source_psr* to intel_enable_source_psr*
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_psr.c | 124 +--
2 files changed, 97 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa..7830e6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3615,6 +3615,9 @@ enum {
#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
#define EDP_PSR2_IDLE_MASK 0xf
+#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
+#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+
/* VGA port control */
#define ADPA _MMIO(0x61100)
#define PCH_ADPA_MMIO(0xe1100)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3aa649..d5e8bcc 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
VLV_EDP_PSR_ACTIVE_ENTRY);
}
-static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+static void intel_enable_source_psr1(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-
uint32_t max_sleep_time = 0x1f;
/*
* Let's respect VBT in case VBT asks a higher idle_frame value.
@@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp
*intel_dp)
val |= EDP_PSR_TP1_TP2_SEL;
I915_WRITE(EDP_PSR_CTL, val);
+}
- if (!dev_priv->psr.psr2_support)
- return;
+static void intel_enable_source_psr2(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ /*
+* Let's respect VBT in case VBT asks a higher idle_frame value.
+* Let's use 6 as the minimum to cover all known cases including
+* the off-by-one issue that HW has in some cases. Also there are
+* cases where sink should be able to train
+* with the 5 or 6 idle patterns.
+*/
+ uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
+ uint32_t val = EDP_PSR_ENABLE;
+
+ val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
/* FIXME: selective update is probably totally broken because it doesn't
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
- val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+ val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp
*intel_dp)
I915_WRITE(EDP_PSR2_CTL, val);
}
+
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ /* psr1 and psr2 are mutually exclusive.*/
+ if (dev_priv->psr.psr2_support)
+ intel_enable_source_psr2(intel_dp);
+ else
+ intel_enable_source_psr1(intel_dp);
+}
+
static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
+ if (dev_priv->psr.psr2_support)
+ WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
+ else
+ WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
WARN_ON(dev_priv->psr.active);
lockdep_assert_held(_priv->psr.lock);
@@ -462,8 +494,6 @@ void intel_psr_enable(struct intel_dp *intel_dp)
dev_priv->psr.busy_frontbuffer_bits = 0;
if (HAS_DDI(dev_priv)) {
-
[Bug 98238] witcher 2: objects are black when changing lod
https://bugs.freedesktop.org/show_bug.cgi?id=98238 --- Comment #17 from Marek Olšák --- The remaining bug can be an instruction scheduling issue: v_interp is moved outside of the WQM or moved after the KILL opcode (which can break the WQM) or moved into a branch (same issue). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/372a2b30/attachment.html>
