[Bug 90889] Radeon driver with radeon.dpm=1 causes lockout
https://bugs.freedesktop.org/show_bug.cgi?id=90889 --- Comment #3 from lolwoot1234 at gmail.com --- Issue still not fixed... Early KMS doesn't really change anything anything. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/f40eed0d/attachment.html>
[Bug 91871] link retraining for DP not possible with current design of Atomic modeset framework
https://bugs.freedesktop.org/show_bug.cgi?id=91871 rtshiva changed: What|Removed |Added Version|XOrg git|unspecified -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/6e019011/attachment.html>
[Bug 91871] link retraining for DP not possible with current design of Atomic modeset framework
https://bugs.freedesktop.org/show_bug.cgi?id=91871 Bug ID: 91871 Summary: link retraining for DP not possible with current design of Atomic modeset framework Product: DRI Version: XOrg git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel at lists.freedesktop.org Reporter: sivakumar.thulasimani at intel.com DP spec requires Link training from highest link rate supported by panel to lowest link rate supported by panel. It is not possible to implement this in the current atomic modeset logic since it splits modeset into two half atomic_check and atomic_commit, where it is expected all values to be calculated in atomic_check and programmed in atomic_commit. link training being a negotiation phase of DP modeset it is not possible to predict if a training at certain link rate will succeed or not. if it does fail it will require us to disable, calculate new values and enable pll. this is not possible in current DRM Atomic modeset framework. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/c71a9713/attachment.html>
[PATCH] drm/exynos: add cursor plane support
From: Gustavo Padovan
Set one of the planes for each crtc driver as a cursor plane enabled
window managers to fully work on exynos.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 9 ++---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 ++--
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 ++--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 ++---
drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
8 files changed, 31 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index b3c7307..79b2b22 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -33,7 +33,6 @@ struct decon_context {
struct exynos_drm_plane planes[WINDOWS_NR];
void __iomem*addr;
struct clk *clks[6];
- unsigned intdefault_win;
unsigned long irq_flags;
int pipe;
boolsuspended;
@@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
unsigned int zpos;
int ret;
@@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->pipe = priv->pipe++;
for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
- type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
- 1 << ctx->pipe, type, decon_formats,
+ 1 << ctx->pipe, decon_formats,
ARRAY_SIZE(decon_formats), zpos);
if (ret)
return ret;
}
- exynos_plane = &ctx->planes[ctx->default_win];
+ exynos_plane = &ctx->planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
&decon_crtc_ops, ctx);
@@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct platform_device
*pdev)
if (!ctx)
return -ENOMEM;
- ctx->default_win = 0;
ctx->suspended = true;
ctx->dev = dev;
if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index cbdb78e..f3826dc 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -52,7 +52,6 @@ struct decon_context {
struct clk *eclk;
struct clk *vclk;
void __iomem*regs;
- unsigned intdefault_win;
unsigned long irq_flags;
booli80_if;
boolsuspended;
@@ -691,7 +690,6 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
unsigned int zpos;
int ret;
@@ -702,16 +700,14 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
}
for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
- type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
- 1 << ctx->pipe, type, decon_formats,
+ 1 << ctx->pipe, decon_formats,
ARRAY_SIZE(decon_formats), zpos);
if (ret)
return ret;
}
- exynos_plane = &ctx->planes[ctx->default_win];
+ exynos_plane = &ctx->planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
&decon_crtc_ops, ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exyno
[PATCH v4 05/16] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & colorimetry
On 01.09.2015 14:55, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code, same to color space and color depth can be
> parsed from EDID.
>
> But presumably Exynos still relaies on the DT properties, so take
s/relaies/relies/
> good use of mode_fixup() in to achieve the compatibility hacks.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4:
> - Take Krzysztof suggest, provide backword compatibility with samsung.
> - Take Thierry suggest, add "color-depth" and "color-space" dynamic parsed.
>
> Changes in v3:
> - Take Thierry Reding suggest, dynamic parse video timing info from
> struct drm_display_mode and struct drm_display_info.
>
> Changes in v2: None
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 141
> +
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 58 -
> 4 files changed, 151 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 7196097..f0db92e 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -897,8 +897,8 @@ static void analogix_dp_commit(struct analogix_dp_device
> *dp)
> return;
> }
>
> - ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
> - dp->video_info->link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> + dp->video_info.link_rate);
> if (ret) {
> dev_err(dp->dev, "unable to do link train\n");
> return;
> @@ -1081,6 +1081,82 @@ static void analogix_dp_bridge_disable(struct
> drm_bridge *bridge)
> dp->dpms_mode = DRM_MODE_DPMS_OFF;
> }
>
> +static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *orig_mode,
> + struct drm_display_mode *mode)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + struct drm_display_info *display_info = &dp->connector.display_info;
> + struct video_info *video_info = &dp->video_info;
> + struct device_node *dp_node = dp->dev->of_node;
> + int vic;
> +
> + /* interlaces & hsync pol & vsync pol */
> + video_info->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + video_info->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
> + video_info->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> +
> + /* dynamic_range & colorimetry */
> + vic = drm_match_cea_mode(mode);
> + if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
> + (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
> + video_info->dynamic_range = CEA;
> + video_info->ycbcr_coeff = COLOR_YCBCR601;
> + } else if (vic) {
> + video_info->dynamic_range = CEA;
> + video_info->ycbcr_coeff = COLOR_YCBCR709;
> + } else {
> + video_info->dynamic_range = VESA;
> + video_info->ycbcr_coeff = COLOR_YCBCR709;
> + }
> +
> + switch (display_info->bpc) {
> + case 12:
> + video_info->color_depth = COLOR_12;
> + break;
> + case 10:
> + video_info->color_depth = COLOR_10;
> + break;
> + case 8:
> + video_info->color_depth = COLOR_8;
> + break;
> + case 6:
> + video_info->color_depth = COLOR_6;
> + break;
> + default:
> + video_info->color_depth = COLOR_8;
> + break;
> + }
> +
> + if (display_info->color_formats | DRM_COLOR_FORMAT_YCRCB444)
> + video_info->color_space = COLOR_YCBCR444;
> + else if (display_info->color_formats | DRM_COLOR_FORMAT_YCRCB422)
> + video_info->color_space = COLOR_YCBCR422;
> + else if (display_info->color_formats | DRM_COLOR_FORMAT_RGB444)
> + video_info->color_space = COLOR_RGB;
> + else
> + video_info->color_space = COLOR_RGB;
> +
> + /*
> + * NOTE: those property parseing code is used for
s/parseing/parsing/
BTW, you can easily integrate spell-check to vim... It is not that I
search for such misspellings - they are highlighted...
> + * providing backward compatibility for samsung platform.
> + */
> + of_property_read_u32(dp_node, "samsung,color-space",
> + &video_info->color_space);
> + of_property_read_u32(dp_node, "samsung,dynamic-range",
> + &video_info->dynamic_range);
> + of_property_read_u32(dp_node, "samsung,ycbcr-coeff",
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Thu, Sep 3, 2015 at 3:47 AM, Thierry Reding wrote: > On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote: > [...] >> Are there any eDP panels which don't have EDID and need panel details in DT? > > Most panels need information other than EDID. They typically have some > requirements regarding the power up sequence that aren't to be found > anywhere in EDID or detectable by some other mechanism. A decision was > therefore made a long time ago to require panels to be listed in DT with > a specific compatible string. That way all of these details can be > stashed away in drivers that know how to deal with these kinds of > details. I guess I was being hopeful that eDP was improving that situation. Rob
[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY
Am Donnerstag, 3. September 2015, 11:25:00 schrieb Yakir Yang: > å¨ 09/02/2015 09:27 PM, Rob Herring åé: > > On Tue, Sep 1, 2015 at 1:04 AM, Yakir Yang wrote: > >> +- clocks: from common clock binding: handle to dp clock. > >> + of memory mapped region. > >> +- clock-names: from common clock binding: > >> + Required elements: "sclk_dp" "sclk_dp_24m" > >> + > >> +- rockchip,grf: this soc should set GRF regs, so need get grf here. > > > > I have no idea what GRF means. > > GRF is an module of our IC chip, the full name is General Register Files. > I would rather to pick some words from our TRM. > > The general register file will be used to do static set by software, which > is composed of many registers for system control. The general register files are present on all Rockchip SoCs I've seen so far and really are just an aggregation of registers for settings and status indications, ranging from memory stuff, dma-controller settings, usb-phy and settings for a lot of other phys, etc. The most prevalent description in dt-bindings is currently: - rockchip,grf: phandle to the syscon managing the "general register files" Heiko
[PATCH v4 2/2] intel: add drm_intel_bo_use_48b_address_range to symbol-check test
Signed-off-by: Michel Thierry --- intel/intel-symbol-check | 1 + 1 file changed, 1 insertion(+) diff --git a/intel/intel-symbol-check b/intel/intel-symbol-check index c555e6d..64ec4ed 100755 --- a/intel/intel-symbol-check +++ b/intel/intel-symbol-check @@ -39,6 +39,7 @@ drm_intel_bo_subdata drm_intel_bo_unmap drm_intel_bo_unpin drm_intel_bo_unreference +drm_intel_bo_use_48b_address_range drm_intel_bo_wait_rendering drm_intel_bufmgr_check_aperture_space drm_intel_bufmgr_destroy -- 2.5.0
[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Instruction State Heap (ISH) must be in a
32-bit range, because the General State Offset and Instruction State Offset
are limited to 32-bits.
The i915 driver has been modified to provide a flag to set when the 4GB
limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
48-bit range will only be used when explicitly requested.
Callers to the existing drm_intel_bo_emit_reloc function should set the
use_48b_address_range flag beforehand, in order to use full ppgtt range.
v2: Make set/clear functions nops on pre-gen8 platforms, and use them
internally in emit_reloc functions (Ben)
s/48BADDRESS/48B_ADDRESS/ (Dave)
v3: Keep set/clear functions internal, no-one needs to use them directly.
v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
before enabling set/clear function, print full offsets in debug
statements, using port of lower_32_bits and upper_32_bits from linux
kernel (MichaÅ)
References:
http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
Cc: Ben Widawsky
Cc: MichaÅ Winiarski
Signed-off-by: Michel Thierry
---
include/drm/i915_drm.h| 3 +-
intel/intel_bufmgr.c | 11 ++
intel/intel_bufmgr.h | 1 +
intel/intel_bufmgr_gem.c | 88 +--
intel/intel_bufmgr_priv.h | 14
5 files changed, 97 insertions(+), 20 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..426b25c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
#define EXEC_OBJECT_NEEDS_FENCE (1<<0)
#define EXEC_OBJECT_NEEDS_GTT (1<<1)
#define EXEC_OBJECT_WRITE (1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
__u64 flags;
__u64 rsvd1;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 14ea9f9..0856e60 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -293,6 +293,17 @@ drm_intel_bo_madvise(drm_intel_bo *bo, int madv)
}
int
+drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable)
+{
+ if (bo->bufmgr->bo_use_48b_address_range) {
+ bo->bufmgr->bo_use_48b_address_range(bo, enable);
+ return 0;
+ }
+
+ return -ENODEV;
+}
+
+int
drm_intel_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
{
return bo->bufmgr->bo_references(bo, target_bo);
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 95eecb8..a14c78f 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -164,6 +164,7 @@ int drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t *
tiling_mode,
int drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name);
int drm_intel_bo_busy(drm_intel_bo *bo);
int drm_intel_bo_madvise(drm_intel_bo *bo, int madv);
+int drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable);
int drm_intel_bo_disable_reuse(drm_intel_bo *bo);
int drm_intel_bo_is_reusable(drm_intel_bo *bo);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2723e21..09d82d2 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -83,6 +83,22 @@
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
#define MAX2(A, B) ((A) > (B) ? (A) : (B))
+/**
+ * upper_32_bits - return bits 32-63 of a number
+ * @n: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress
+ * the "right shift count >= width of type" warning when that quantity is
+ * 32-bits.
+ */
+#define upper_32_bits(n) ((__u32)(((n) >> 16) >> 16))
+
+/**
+ * lower_32_bits - return bits 0-31 of a number
+ * @n: the number we're accessing
+ */
+#define lower_32_bits(n) ((__u32)(n))
+
typedef struct _drm_intel_bo_gem drm_intel_bo_gem;
struct drm_intel_gem_bo_bucket {
@@ -237,6 +253,15 @@ struct _drm_intel_bo_gem {
bool is_userptr;
/**
+* Boolean of whether this buffer can be placed in the full 48-bit
+* address range on gen8+.
+*
+* By default, buffers will be keep in a 32-bit range, unless this
+* flag is explicitly set.
+*/
+ bool use_48b_address_range;
+
+ /**
* Size in bytes of this buffer and its relocation descendents.
*
* Used to avoid costly tree walking in
@@ -395,14 +420,16 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem
*bufmgr_gem)
drm_intel_bo_gem *target_gem =
(drm_intel_bo_gem *) target_bo;
- DBG("%2d: %d (%s)@0x%08llx -> "
- "%d (%s)@0x%08lx + 0x%08x\n",
+
[PATCH libdrm v4 0/2] 48-bit virtual address support in i915
This new version picks the suggestion from MichaÅ Winiarski related to v3 [1]. 48-bit virtual address range will be enabled in i915 soon, but some objects must be referenced by 32-bit offsets. These patches use a new kernel flag to specify if this restriction applies or not. I'm sending these patches to comply with the i915 merge process. Once the kernel patch is merged, I'll make a new libdrm release and address the mesa build dependency. [1] http://lists.freedesktop.org/archives/dri-devel/2015-August/087837.html Michel Thierry (2): intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag) intel: add drm_intel_bo_use_48b_address_range to symbol-check test include/drm/i915_drm.h| 3 +- intel/intel-symbol-check | 1 + intel/intel_bufmgr.c | 11 ++ intel/intel_bufmgr.h | 1 + intel/intel_bufmgr_gem.c | 88 +-- intel/intel_bufmgr_priv.h | 14 6 files changed, 98 insertions(+), 20 deletions(-) -- 2.5.0
[Bug 91527] 7870 radeon crashes after kernel msg drm:radeon_mn_invalidate_range_start
https://bugs.freedesktop.org/show_bug.cgi?id=91527 JATothrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from JATothrim --- (In reply to Christian König from comment #6) > Well have you tested this with the current upstream kernel? E.g. 4.1 or a > recent rc of 4.2? > > That's usually the first thing you should to to figure out if newer kernels > are already fixed. Phew. I finally managed to compile/test newer kernel v4.2 and this bug is fixed! :) Yay! My tip for radeon 7870 owners: if your screen freezes and turns into a weird rainbow mess try kernel v4.2. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/7a2f4ec0/attachment.html>
[PATCH] drm/msm/dsi: Parse lane swap information from DT
Lane swap configuration is based on the board design.
This change allows the DSI host to get this information
from device tree, instead of hardcoding in driver.
Signed-off-by: Hai Li
---
Documentation/devicetree/bindings/drm/msm/dsi.txt | 13 ++
drivers/gpu/drm/msm/dsi/dsi_host.c| 49 +--
2 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
index d56923c..febcc51 100644
--- a/Documentation/devicetree/bindings/drm/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -44,6 +44,17 @@ Optional properties:
- port: DSI controller output port. This contains one endpoint subnode, with
its
remote-endpoint set to the phandle of the connected panel's endpoint.
See Documentation/devicetree/bindings/graph.txt for device graph info.
+- qcom,dsi-logical-lane-swap: Character string to swap logical lane to physical
+ lane mapping. Supported lane mappings:
+ "0123": Logic 0->Phys 0; Logic 1->Phys 1; Logic 2->Phys 2; Logic 3->Phys 3;
+ "3012": Logic 3->Phys 0; Logic 0->Phys 1; Logic 1->Phys 2; Logic 2->Phys 3;
+ "2301": Logic 2->Phys 0; Logic 3->Phys 1; Logic 0->Phys 2; Logic 1->Phys 3;
+ "1230": Logic 1->Phys 0; Logic 2->Phys 1; Logic 3->Phys 2; Logic 0->Phys 3;
+ "0321": Logic 0->Phys 0; Logic 3->Phys 1; Logic 2->Phys 2; Logic 1->Phys 3;
+ "1032": Logic 1->Phys 0; Logic 0->Phys 1; Logic 3->Phys 2; Logic 2->Phys 3;
+ "2103": Logic 2->Phys 0; Logic 1->Phys 1; Logic 0->Phys 2; Logic 3->Phys 3;
+ "3210": Logic 3->Phys 0; Logic 2->Phys 1; Logic 1->Phys 2; Logic 0->Phys 3;
+ Default value is "0123", which means no lane swap.
DSI PHY:
Required properties:
@@ -129,6 +140,8 @@ Example:
remote-endpoint = <&panel_in>;
};
};
+
+ qcom,dsi-logical-lane-swap = "0123";
};
mdss_dsi_phy0: qcom,mdss_dsi_phy at fd922a00 {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 8d82973f..eaba417 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -131,6 +131,7 @@ struct msm_dsi_host {
enum mipi_dsi_pixel_format format;
unsigned long mode_flags;
+ u32 dlane_swap;
u32 dma_cmd_ctrl_restore;
bool registered;
@@ -684,19 +685,9 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host,
bool enable,
data = DSI_CTRL_CLK_EN;
DBG("lane number=%d", msm_host->lanes);
- if (msm_host->lanes == 2) {
- data |= DSI_CTRL_LANE1 | DSI_CTRL_LANE2;
- /* swap lanes for 2-lane panel for better performance */
- dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
- DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(LANE_SWAP_1230));
- } else {
- /* Take 4 lanes as default */
- data |= DSI_CTRL_LANE0 | DSI_CTRL_LANE1 | DSI_CTRL_LANE2 |
- DSI_CTRL_LANE3;
- /* Do not swap lanes for 4-lane panel */
- dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
- DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(LANE_SWAP_0123));
- }
+ data |= ((DSI_CTRL_LANE0 << msm_host->lanes) - DSI_CTRL_LANE0);
+ dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
+ DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(msm_host->dlane_swap));
if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
dsi_write(msm_host, REG_DSI_LANE_CTRL,
@@ -1289,6 +1280,9 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
int ret;
+ if (dsi->lanes > 4 || dsi->channel > 3)
+ return -EINVAL;
+
msm_host->channel = dsi->channel;
msm_host->lanes = dsi->lanes;
msm_host->format = dsi->format;
@@ -1344,6 +1338,33 @@ static struct mipi_dsi_host_ops dsi_host_ops = {
.transfer = dsi_host_transfer,
};
+static void dsi_parse_dlane_swap(struct msm_dsi_host *msm_host,
+ struct device_node *np)
+{
+ const char *lane_swap;
+
+ lane_swap = of_get_property(np, "qcom,dsi-logical-lane-swap", NULL);
+
+ if (!lane_swap)
+ msm_host->dlane_swap = LANE_SWAP_0123;
+ else if (!strncmp(lane_swap, "3012", 5))
+ msm_host->dlane_swap = LANE_SWAP_3012;
+ else if (!strncmp(lane_swap, "2301", 5))
+ msm_host->dlane_swap = LANE_SWAP_2301;
+ else if (!strncmp(lane_swap, "1230", 5))
+ msm_host->dlane_swap = LANE_SWAP_1230;
+ else if (!strncmp(lane_swap, "0321", 5))
+ msm_host->dlane_swap = LANE_SWAP_0321;
+ else if (!strncmp(lane_swap, "1032", 5))
+ msm_host->dlane_swap = LANE_SWAP_1032;
+ else if (!strncmp(lane_swap, "2103", 5))
+ msm_host->dlane_swap = LANE_SWAP_2103;
+
[PATCH v4 01/16] drm: exynos/dp: fix code style
On 03.09.2015 14:04, Yakir Yang wrote:
> Hi Krzysztof,
>
> å¨ 09/03/2015 08:21 AM, Krzysztof Kozlowski åé:
>> On 01.09.2015 14:46, Yakir Yang wrote:
>>> After run "checkpatch.pl -f --subjective" command, I see there
>>> are lots of alignment problem in exynos_dp driver, so let just
>>> fix them.
>> Hi,
>>
>> Warnings from checkpatch are not a reason for a commit. Reason for a
>> commit could be for example an unreadable code, violation of
>> coding-style leading to decrease in code maintainability or just
>> improving the code readability so it will be easier to review and
>> maintain it.
>>
>> You do not make commits because some tool tells you that. We do not
>> listen to machines :) ... If that would be the case, the commit could be
>> made automatically, without human interaction. Such automated commit
>> could be even easily tested by the machine by comparing object files.
>>
>> Especially that you enabled "subjective" rule. This is not a valid
>> motivation for a commit.
>>
>> Please rephrase this to sensible reason and convince that change is
>> worth the effort.
>
> Oh, nice, thanks for your remind. I would rephrase the commit.
>
>>> - Take Romain suggest, rebase on linux-next branch
>> That comment seems unrelated to the commit. Please remove it.
>
> Done,
>
>>
>>> Signed-off-by: Yakir Yang
>>> ---
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2:
>>> - Take Joe Preches advise, improved commit message more readable, and
>>>avoid using some uncommon style like bellow:
>>>- retval = exynos_dp_read_bytes_from_i2c(...
>>> ...)
>>>+ retval =
>>>+ exynos_dp_read_bytes_from_i2c(..);
>>>
>>> drivers/gpu/drm/exynos/exynos_dp_core.c | 226
>>>
>>> drivers/gpu/drm/exynos/exynos_dp_core.h | 54
>>> drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
>>> 3 files changed, 188 insertions(+), 198 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> index d66ade0..266f7f7 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> @@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> /* Read Extension Flag, Number of 128-byte EDID extension
>>> blocks */
>>> retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
>>> -EDID_EXTENSION_FLAG,
>>> -&extend_block);
>>> + EDID_EXTENSION_FLAG,
>>> + &extend_block);
>>> if (retval)
>>> return retval;
>>> @@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> dev_dbg(dp->dev, "EDID data includes a single extension!\n");
>>> /* Read EDID data */
>>> -retval = exynos_dp_read_bytes_from_i2c(dp,
>>> I2C_EDID_DEVICE_ADDR,
>>> -EDID_HEADER_PATTERN,
>>> -EDID_BLOCK_LENGTH,
>>> -&edid[EDID_HEADER_PATTERN]);
>>> +retval = exynos_dp_read_bytes_from_i2c(
>>> +dp, I2C_EDID_DEVICE_ADDR,
>>> +EDID_HEADER_PATTERN,
>>> +EDID_BLOCK_LENGTH,
>>> +&edid[EDID_HEADER_PATTERN]);
>>> if (retval != 0) {
>>> dev_err(dp->dev, "EDID Read failed!\n");
>>> return -EIO;
>>> @@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> }
>>> /* Read additional EDID data */
>>> -retval = exynos_dp_read_bytes_from_i2c(dp,
>>> -I2C_EDID_DEVICE_ADDR,
>>> -EDID_BLOCK_LENGTH,
>>> -EDID_BLOCK_LENGTH,
>>> -&edid[EDID_BLOCK_LENGTH]);
>>> +retval = exynos_dp_read_bytes_from_i2c(
>>> +dp, I2C_EDID_DEVICE_ADDR,
>>> +EDID_BLOCK_LENGTH,
>>> +EDID_BLOCK_LENGTH,
>>> +&edid[EDID_BLOCK_LENGTH]);
>>> if (retval != 0) {
>>> dev_err(dp->dev, "EDID Read failed!\n");
>>> return -EIO;
>>> @@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> }
>>> exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
>>> -&test_vector);
>>> + &test_vector);
>>> if (test_vector & DP_TEST_LINK_EDID_READ) {
>>> -exynos_dp_write_byte_to_dpcd(dp,
>>> -DP_TEST_EDID_CHECKSUM,
>>> +exynos_dp_write_byte_to_dpcd(
>>> +dp, DP_TEST_EDID_CHECKSUM,
>>> edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
>>> -exynos_dp_write_byte_to_dpcd(dp,
>>> -DP_TEST_RESPONSE,
>>> +exynos_dp_write_byte_to_dpcd(
>>> +dp, DP_TEST_RESPONSE,
>>>
[Bug 91865] [r600g] GPU hang in 'gsraytrace' - NI/Turks (6670)
https://bugs.freedesktop.org/show_bug.cgi?id=91865 --- Comment #4 from Dieter Nützel --- dmesg snipped from another hang: [ 1361.853214] radeon :01:00.0: ring 0 stalled for more than 10099msec [ 1361.853222] radeon :01:00.0: GPU lockup (current fence id 0x000b21b6 last fence id 0x000b21ea on ring 0) [ 1361.873984] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35). [ 1361.874010] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-35). [ 1361.921903] radeon :01:00.0: GPU softreset: 0x0009 [ 1361.921906] radeon :01:00.0: GRBM_STATUS = 0xB2737828 [ 1361.921909] radeon :01:00.0: GRBM_STATUS_SE0 = 0x1E07 [ 1361.921911] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 1361.921913] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 1361.921915] radeon :01:00.0: SRBM_STATUS2 = 0x [ 1361.921917] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 1361.921919] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x400C [ 1361.921921] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00048006 [ 1361.921923] radeon :01:00.0: R_008680_CP_STAT = 0x80268647 [ 1361.921925] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 1361.922215] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 1361.922270] radeon :01:00.0: SRBM_SOFT_RESET=0x0100 [ 1361.923429] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 1361.923431] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 1361.923433] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 1361.923435] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 1361.923437] radeon :01:00.0: SRBM_STATUS2 = 0x [ 1361.923439] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 1361.923441] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 1361.923443] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 1361.923445] radeon :01:00.0: R_008680_CP_STAT = 0x [ 1361.923448] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 1361.923480] radeon :01:00.0: GPU reset succeeded, trying to resume [ 1361.946777] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 1361.949613] [drm] PCIE GART of 1024M enabled (table at 0x00274000). [ 1361.949732] radeon :01:00.0: WB enabled [ 1361.949734] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x88036f42ac00 [ 1361.949736] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x88036f42ac0c [ 1361.951504] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc90003432118 [ 1361.968087] [drm] ring test on 0 succeeded in 2 usecs [ 1361.968099] [drm] ring test on 3 succeeded in 7 usecs [ 1362.145206] [drm] ring test on 5 succeeded in 2 usecs [ 1362.145218] [drm] UVD initialized successfully. [ 1362.165411] [drm] ib test on ring 0 succeeded in 0 usecs [ 1362.165468] [drm] ib test on ring 3 succeeded in 0 usecs [ 1362.817284] [drm] ib test on ring 5 succeeded -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/fbc00adc/attachment.html>
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 --- Comment #10 from Dieter Nützel --- (In reply to Heiko from comment #9) > Created attachment 118054 [details] > kmsg: gsraytrace lockup on HD6850 > > Just noticed the problem today on my HD6850. Unfortunately, it doesn't come > back to life all the time. That is either complete lockup (and reboot) or at > least Xorg being hung in process state D and gsraytrace in state Z. Attached > log produced, when hitting the latter one (though sysrq still worked and > terminal after sysrq-r worked well). The lock contains some of the > sysrq-show-xyz triggers, which are of help maybe (the blocked cat is from > catting one of the radeon sysfs entries). Xorg log only shows event > overflows. > > GPU hang seems to be 100% reproducable with gsraytrace for me. > > Software components being: > media-libs/mesa- (git-4de86e1) > sys-devel/llvm-3.6.2 > sys-kernel/vanilla-sources-4.2.0 > x11-libs/libdrm-2.4.64 > > options radeon audio=1 tv=0 dpm=1 Hello Heiko, I've started this one year ago for _RV730_ (AGP) and it is still open for it. But as you're on HD6850 and I'm on Turks (6670), now I've opened up new one for those, here: bug 91865 I think you should move your logs there. My impression is that they could be related. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/f931a693/attachment.html>
[PATCH v4 01/16] drm: exynos/dp: fix code style
Hi Krzysztof,
å¨ 09/03/2015 01:08 PM, Krzysztof Kozlowski åé:
> On 03.09.2015 14:04, Yakir Yang wrote:
>> Hi Krzysztof,
>>
>> å¨ 09/03/2015 08:21 AM, Krzysztof Kozlowski åé:
>>> On 01.09.2015 14:46, Yakir Yang wrote:
After run "checkpatch.pl -f --subjective" command, I see there
are lots of alignment problem in exynos_dp driver, so let just
fix them.
>>> Hi,
>>>
>>> Warnings from checkpatch are not a reason for a commit. Reason for a
>>> commit could be for example an unreadable code, violation of
>>> coding-style leading to decrease in code maintainability or just
>>> improving the code readability so it will be easier to review and
>>> maintain it.
>>>
>>> You do not make commits because some tool tells you that. We do not
>>> listen to machines :) ... If that would be the case, the commit could be
>>> made automatically, without human interaction. Such automated commit
>>> could be even easily tested by the machine by comparing object files.
>>>
>>> Especially that you enabled "subjective" rule. This is not a valid
>>> motivation for a commit.
>>>
>>> Please rephrase this to sensible reason and convince that change is
>>> worth the effort.
>> Oh, nice, thanks for your remind. I would rephrase the commit.
>>
- Take Romain suggest, rebase on linux-next branch
>>> That comment seems unrelated to the commit. Please remove it.
>> Done,
>>
Signed-off-by: Yakir Yang
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
avoid using some uncommon style like bellow:
- retval = exynos_dp_read_bytes_from_i2c(...
...)
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/exynos/exynos_dp_core.c | 226
drivers/gpu/drm/exynos/exynos_dp_core.h | 54
drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
3 files changed, 188 insertions(+), 198 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..266f7f7 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
/* Read Extension Flag, Number of 128-byte EDID extension
blocks */
retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-EDID_EXTENSION_FLAG,
-&extend_block);
+ EDID_EXTENSION_FLAG,
+ &extend_block);
if (retval)
return retval;
@@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
-retval = exynos_dp_read_bytes_from_i2c(dp,
I2C_EDID_DEVICE_ADDR,
-EDID_HEADER_PATTERN,
-EDID_BLOCK_LENGTH,
-&edid[EDID_HEADER_PATTERN]);
+retval = exynos_dp_read_bytes_from_i2c(
+dp, I2C_EDID_DEVICE_ADDR,
+EDID_HEADER_PATTERN,
+EDID_BLOCK_LENGTH,
+&edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
}
/* Read additional EDID data */
-retval = exynos_dp_read_bytes_from_i2c(dp,
-I2C_EDID_DEVICE_ADDR,
-EDID_BLOCK_LENGTH,
-EDID_BLOCK_LENGTH,
-&edid[EDID_BLOCK_LENGTH]);
+retval = exynos_dp_read_bytes_from_i2c(
+dp, I2C_EDID_DEVICE_ADDR,
+EDID_BLOCK_LENGTH,
+EDID_BLOCK_LENGTH,
+&edid[EDID_BLOCK_LENGTH]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
}
exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-&test_vector);
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
-exynos_dp_write_byte_to_dpcd(dp,
-DP_TEST_EDID_CHECKSUM,
+exynos_dp_write_byte_to_dpcd(
+dp, DP_TEST_EDID_CHECKSUM,
edid[EDID_BLOCK_LENGTH + EDID_CHECKS
[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files
https://bugs.freedesktop.org/show_bug.cgi?id=83226 --- Comment #33 from freddyescobar at hotmail.fr --- I have a DCE4 (HD5770) and i don't know if my monitor supports RGB quantization. I guess it can't (old Philips from 2007). What could you suggest to me ? (Of course, output is Full RGB, and my tv is limited RGB). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/dd8e31f5/attachment.html>
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Hi Krzysztof,
å¨ 09/03/2015 08:58 AM, Krzysztof Kozlowski åé:
> On 01.09.2015 14:49, Yakir Yang wrote:
>> Split the dp core driver from exynos directory to bridge
>> directory, and rename the core driver to analogix_dp_*,
>> leave the platform code to analogix_dp-exynos.
>>
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v4:
>> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery.
>> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
>> "exynos_dp.c"
>> - Take Archit suggest, create a separate folder for analogix code in bridge/
>>
>> Changes in v3:
>> - Take Thierry Reding suggest, move exynos's video_timing code
>>to analogix_dp-exynos platform driver, add get_modes method
>>to struct analogix_dp_plat_data.
>> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
>>
>> Changes in v2:
>> - Take Jingoo Han suggest, remove new copyright
>> - Fix compiled failed dut to analogix_dp_device misspell
>>
>> drivers/gpu/drm/bridge/Kconfig |2 +
>> drivers/gpu/drm/bridge/Makefile|1 +
>> drivers/gpu/drm/bridge/analogix/Kconfig|4 +
>> drivers/gpu/drm/bridge/analogix/Makefile |1 +
>> .../analogix/analogix_dp_core.c} | 817 ++---
>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 283 +
>> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1265
>>
>> .../analogix/analogix_dp_reg.h}| 258 ++--
>> drivers/gpu/drm/exynos/Kconfig |3 +-
>> drivers/gpu/drm/exynos/Makefile|2 +-
>> drivers/gpu/drm/exynos/exynos_dp.c | 306 +
>> drivers/gpu/drm/exynos/exynos_dp_core.h| 282 -
>> drivers/gpu/drm/exynos/exynos_dp_reg.c | 1259
>> ---
>> include/drm/bridge/analogix_dp.h | 24 +
>> 14 files changed, 2357 insertions(+), 2150 deletions(-)
>> create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
>> create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
>> rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
>> bridge/analogix/analogix_dp_core.c} (50%)
>> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
>> bridge/analogix/analogix_dp_reg.h} (64%)
>> create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
>> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
>> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
>> create mode 100644 include/drm/bridge/analogix_dp.h
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 2de52a5..7b5b77a 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
>> ---help---
>>Parade eDP-LVDS bridge chip driver.
>>
>> +source "drivers/gpu/drm/bridge/analogix/Kconfig"
>> +
>> endmenu
>> diff --git a/drivers/gpu/drm/bridge/Makefile
>> b/drivers/gpu/drm/bridge/Makefile
>> index e2eef1c..5366c6b 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
>> obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
>> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
>> b/drivers/gpu/drm/bridge/analogix/Kconfig
>> new file mode 100644
>> index 000..5ff6551
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
>> @@ -0,0 +1,4 @@
>> +config DRM_ANALOGIX_DP
>> +tristate
>> +depends on DRM
>> +select DRM_KMS_HELPER
>> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
>> b/drivers/gpu/drm/bridge/analogix/Makefile
>> new file mode 100644
>> index 000..9107b86
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> similarity index 50%
>> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
>> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index bed0252..7d62f22 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1,14 +1,14 @@
>> /*
>> - * Samsung SoC DP (Display Port) interface driver.
>> - *
>> - * Copyright (C) 2012 Samsung Electronics Co., Ltd.
>> - * Author: Jingoo Han
>> - *
>> - * This program is free software; you can redistribute it and/or modify it
>> - * under the terms of the GNU General Public License as published by the
>> - * Free Software Foundation; eit
[Bug 91865] [r600g] GPU hang in 'gsraytrace' - NI/Turks (6670)
https://bugs.freedesktop.org/show_bug.cgi?id=91865 --- Comment #3 from Dieter Nützel --- Created attachment 118068 --> https://bugs.freedesktop.org/attachment.cgi?id=118068&action=edit gsraytrace_31672_ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/a8c4e51e/attachment.html>
[Bug 91865] [r600g] GPU hang in 'gsraytrace' - NI/Turks (6670)
https://bugs.freedesktop.org/show_bug.cgi?id=91865 --- Comment #2 from Dieter Nützel --- Created attachment 118067 --> https://bugs.freedesktop.org/attachment.cgi?id=118067&action=edit dmesg-4.2.0-1.gefc468a-desktop.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/c487fc30/attachment-0001.html>
[Bug 91865] [r600g] GPU hang in 'gsraytrace' - NI/Turks (6670)
https://bugs.freedesktop.org/show_bug.cgi?id=91865 --- Comment #1 from Dieter Nützel --- Even with R600_DEBUG=nosb mesa-demos/glsl> ./gsraytrace Gallium debugger active. The hang detection timout is 1000 ms. ATTENTION: default value of option vblank_mode overridden by environment. GL_RENDERER = Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.8.0) ESC = exit demo left mouse + drag = rotate camera dd: GPU hang detected! dd: Aborting the process... Abort OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.8.0) OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel (git-6e37304) I'll attach dmesg-4.2.0-1.gefc468a-desktop.log gsraytrace_31672_ (Marek's GREAT Gallium debugger log) [ 5676.604919] radeon :01:00.0: ring 0 stalled for more than 31033msec [ 5676.604988] radeon :01:00.0: GPU lockup (current fence id 0x000a9cea last fence id 0x000a9d18 on ring 0) [ 5676.647958] radeon :01:00.0: Saved 1479 dwords of commands on ring 0. [ 5676.647983] radeon :01:00.0: GPU softreset: 0x000D [ 5676.647986] radeon :01:00.0: GRBM_STATUS = 0xF7631028 [ 5676.647988] radeon :01:00.0: GRBM_STATUS_SE0 = 0xF802 [ 5676.647990] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 5676.647992] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 5676.647994] radeon :01:00.0: SRBM_STATUS2 = 0x [ 5676.647996] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 5676.647998] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x400C [ 5676.648000] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00048002 [ 5676.648002] radeon :01:00.0: R_008680_CP_STAT = 0x80268647 [ 5676.648004] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44483106 [ 5676.664891] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 5676.664945] radeon :01:00.0: SRBM_SOFT_RESET=0x00100100 [ 5676.666105] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 5676.666107] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 5676.666109] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 5676.666111] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 5676.666113] radeon :01:00.0: SRBM_STATUS2 = 0x [ 5676.666115] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 5676.666117] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 5676.666119] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 5676.666121] radeon :01:00.0: R_008680_CP_STAT = 0x [ 5676.666124] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 5676.666158] radeon :01:00.0: GPU reset succeeded, trying to resume [ 5676.689479] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 5676.692387] [drm] PCIE GART of 1024M enabled (table at 0x00274000). [ 5676.692506] radeon :01:00.0: WB enabled [ 5676.692509] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x88003723cc00 [ 5676.692510] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x88003723cc0c [ 5676.694278] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc90003432118 [ 5676.710865] [drm] ring test on 0 succeeded in 2 usecs [ 5676.710877] [drm] ring test on 3 succeeded in 7 usecs [ 5676.887988] [drm] ring test on 5 succeeded in 2 usecs [ 5676.887997] [drm] UVD initialized successfully. [ 5676.935630] [drm] ib test on ring 0 succeeded in 0 usecs [ 5676.935687] [drm] ib test on ring 3 succeeded in 0 usecs [ 5677.587054] [drm] ib test on ring 5 succeeded -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/1a5c700c/attachment.html>
[PATCH v4 01/16] drm: exynos/dp: fix code style
Hi Krzysztof,
å¨ 09/03/2015 08:21 AM, Krzysztof Kozlowski åé:
> On 01.09.2015 14:46, Yakir Yang wrote:
>> After run "checkpatch.pl -f --subjective" command, I see there
>> are lots of alignment problem in exynos_dp driver, so let just
>> fix them.
> Hi,
>
> Warnings from checkpatch are not a reason for a commit. Reason for a
> commit could be for example an unreadable code, violation of
> coding-style leading to decrease in code maintainability or just
> improving the code readability so it will be easier to review and
> maintain it.
>
> You do not make commits because some tool tells you that. We do not
> listen to machines :) ... If that would be the case, the commit could be
> made automatically, without human interaction. Such automated commit
> could be even easily tested by the machine by comparing object files.
>
> Especially that you enabled "subjective" rule. This is not a valid
> motivation for a commit.
>
> Please rephrase this to sensible reason and convince that change is
> worth the effort.
Oh, nice, thanks for your remind. I would rephrase the commit.
>> - Take Romain suggest, rebase on linux-next branch
> That comment seems unrelated to the commit. Please remove it.
Done,
>
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2:
>> - Take Joe Preches advise, improved commit message more readable, and
>>avoid using some uncommon style like bellow:
>>- retval = exynos_dp_read_bytes_from_i2c(...
>> ...)
>>+ retval =
>>+ exynos_dp_read_bytes_from_i2c(..);
>>
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 226
>>
>> drivers/gpu/drm/exynos/exynos_dp_core.h | 54
>> drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
>> 3 files changed, 188 insertions(+), 198 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index d66ade0..266f7f7 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct exynos_dp_device
>> *dp)
>>
>> /* Read Extension Flag, Number of 128-byte EDID extension blocks */
>> retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
>> -EDID_EXTENSION_FLAG,
>> -&extend_block);
>> + EDID_EXTENSION_FLAG,
>> + &extend_block);
>> if (retval)
>> return retval;
>>
>> @@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
>> *dp)
>> dev_dbg(dp->dev, "EDID data includes a single extension!\n");
>>
>> /* Read EDID data */
>> -retval = exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
>> -EDID_HEADER_PATTERN,
>> -EDID_BLOCK_LENGTH,
>> -&edid[EDID_HEADER_PATTERN]);
>> +retval = exynos_dp_read_bytes_from_i2c(
>> +dp, I2C_EDID_DEVICE_ADDR,
>> +EDID_HEADER_PATTERN,
>> +EDID_BLOCK_LENGTH,
>> +&edid[EDID_HEADER_PATTERN]);
>> if (retval != 0) {
>> dev_err(dp->dev, "EDID Read failed!\n");
>> return -EIO;
>> @@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
>> *dp)
>> }
>>
>> /* Read additional EDID data */
>> -retval = exynos_dp_read_bytes_from_i2c(dp,
>> -I2C_EDID_DEVICE_ADDR,
>> -EDID_BLOCK_LENGTH,
>> -EDID_BLOCK_LENGTH,
>> -&edid[EDID_BLOCK_LENGTH]);
>> +retval = exynos_dp_read_bytes_from_i2c(
>> +dp, I2C_EDID_DEVICE_ADDR,
>> +EDID_BLOCK_LENGTH,
>> +EDID_BLOCK_LENGTH,
>> +&edid[EDID_BLOCK_LENGTH]);
>> if (retval != 0) {
>> dev_err(dp->dev, "EDID Read failed!\n");
>> return -EIO;
>> @@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct exynos_dp_device
>> *dp)
>> }
>>
>> exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
>> -&test_vector);
>> + &test_vector);
>> if (test_vector & DP_TEST_LINK_EDID_READ) {
>> -exynos_dp_write_byte_to_dpcd(dp,
>> -DP_TEST_EDID_CHECKSUM,
>> +exynos_dp_write_byte_to_dpcd(
>> +
[PATCH v4 07/16] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
>> -samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
>> +hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
>>
>> ports {
>> port at 0 {
>> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
>> b/arch/arm/boot/dts/exynos5250-spring.dts
>> index c1edd6d..91881d7 100644
>> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> @@ -74,12 +74,10 @@
>> pinctrl-names = "default";
>> pinctrl-0 = <&dp_hpd_gpio>;
>> samsung,color-space = <0>;
>> -samsung,dynamic-range = <0>;
>> -samsung,ycbcr-coeff = <0>;
>> samsung,color-depth = <1>;
>> samsung,link-rate = <0x0a>;
>> samsung,lane-count = <1>;
>> -samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
>> +hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
>> };
>>
>> &ehci {
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> index 8f4d76c..7433683 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> @@ -148,12 +148,10 @@
>> pinctrl-names = "default";
>> pinctrl-0 = <&dp_hpd_gpio>;
>> samsung,color-space = <0>;
>> -samsung,dynamic-range = <0>;
>> -samsung,ycbcr-coeff = <0>;
>> samsung,color-depth = <1>;
>> samsung,link-rate = <0x06>;
>> samsung,lane-count = <2>;
>> -samsung,hpd-gpio = <&gpx2 6 0>;
>> +hpd-gpio = <&gpx2 6 0>;
>>
>> ports {
>> port at 0 {
>> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> index 98871f9..b3df3c1 100644
>> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> @@ -92,8 +92,6 @@
>> pinctrl-names = "default";
>> pinctrl-0 = <&dp_hpd>;
>> samsung,color-space = <0>;
>> -samsung,dynamic-range = <0>;
>> -samsung,ycbcr-coeff = <0>;
>> samsung,color-depth = <1>;
>> samsung,link-rate = <0x0a>;
>> samsung,lane-count = <4>;
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index 7d5b386..b89bff5 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -142,12 +142,10 @@
>> pinctrl-names = "default";
>> pinctrl-0 = <&dp_hpd_gpio>;
>> samsung,color-space = <0>;
>> -samsung,dynamic-range = <0>;
>> -samsung,ycbcr-coeff = <0>;
>> samsung,color-depth = <1>;
>> samsung,link-rate = <0x0a>;
>> samsung,lane-count = <2>;
>> -samsung,hpd-gpio = <&gpx2 6 0>;
>> +hpd-gpios = <&gpx2 6 0>;
>> panel = <&panel>;
>> };
>>
>>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/3058be57/attachment-0001.html>
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Hi Rob, å¨ 09/03/2015 04:17 AM, Rob Herring åé: > On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: >> Some edp screen do not have hpd signal, so we can't just return >> failed when hpd plug in detect failed. > This is a property of the panel (or connector perhaps), so this > property should be located there. At least, it is a common issue and > not specific to this chip. We could have an HDMI connector and failed > to hook up HPD for example. A connector node is also where hpd-gpios > should be located instead (and are already defined by > ../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector > binding, too. Yep, I agree with your front point, it is a property of panel, not specific to eDP controller, so this code should handle in connector logic. But another question, if we just leave this property to connector, then we would need to parse this property in analogix_dp-rockchip.c, and then make an hook in analogix_dp_core.c driver. This is not nice, and if there are some coming platform which alse want to use analogix_dp code and meet this "no-hpd" situation, then they would need duplicate to parse this property and fill the hook in analogix_dp_core.c driver. So it's little bit conflict :-) Beside I can not understand your example very well. Do you mean that there are some HDMI monitor which also do not have HPD signal (just like some eDP panel do not have hpd too), and then the "hpd-gpios" ? Hmm... I don't know how the "hpd-gpios" want to help in this case, would you mind show some sample code :-D > Are there any eDP panels which don't have EDID and need panel details in DT? Oh, I think you want to collect some info that belong to panel property but no indicate in panel EDID message, so those can be collect in eDP connector binding, is it right ? As for me, I just meet this "no-hpd" special situation. - Yakir > > Rob > >> This is an hardware property, so we need add a devicetree property >> "analogix,need-force-hpd" to indicate this sutiation. >> >> Signed-off-by: Yakir Yang >> --- >> Changes in v4: None >> Changes in v3: >> - Add "analogix,need-force-hpd" to indicate whether driver need foce >>hpd when hpd detect failed. >> >> Changes in v2: None >> >> .../devicetree/bindings/drm/bridge/analogix_dp.txt | 4 ++- >> .../bindings/video/analogix_dp-rockchip.txt| 1 + >> .../devicetree/bindings/video/exynos_dp.txt| 1 + >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 >> +++--- >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++ >> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++ >> 6 files changed, 47 insertions(+), 6 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >> b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >> index f54dc3e..c310367 100644 >> --- a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >> +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >> @@ -22,6 +22,9 @@ Required properties for dp-controller: >> from general PHY binding: Should be "dp". >> >> Optional properties for dp-controller: >> + -analogix,need-force-hpd: >> + Indicate driver need force hpd when hpd detect failed, this >> + is used for some eDP screen which don't have hpd signal. >> -hpd-gpios: >> Hotplug detect GPIO. >> Indicates which GPIO should be used for hotplug detection >> @@ -31,7 +34,6 @@ Optional properties for dp-controller: >> * Documentation/devicetree/bindings/video/exynos_dp.txt >> * >> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt >> >> - >> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt >> >> --- >> >> diff --git >> a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt >> b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt >> index 502483e..8b9ed7d 100644 >> --- a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt >> +++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt >> @@ -28,6 +28,7 @@ For the below properties, please refer to Analogix DP >> binding document: >> - phys (required) >> - phy-names (required) >> - hpd-gpios (optional) >> +- analogix,need-force-hpd (optional) >> >> --- >> >> Example: >> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt >> b/Documentation/devicetree/bindings/video/exynos_dp.txt >> index ea03b3a..4f06e80 100644 >> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt >> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt >> @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP >> binding document: >> -phys (required) >>
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Hi Emil, å¨ 09/02/2015 10:50 PM, Emil Velikov åé: > [Dropping the CC list] Hmm...Don't understand what this means. If you can explain, that would be better, so I would not miss your suggest. :-) > Hi Yakir Yang, > > On 1 September 2015 at 06:49, Yakir Yang wrote: >> Split the dp core driver from exynos directory to bridge >> directory, and rename the core driver to analogix_dp_*, >> leave the platform code to analogix_dp-exynos. >> >> Signed-off-by: Yakir Yang >> --- >> Changes in v4: >> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery. >> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to >> "exynos_dp.c" >> - Take Archit suggest, create a separate folder for analogix code in bridge/ >> > "Take X suggest", is grammatically incorrect. You should use > "suggestion(s)" or alternatively use the following approach. > > - Create a separate folder for analogix code in bridge/ (Archit) Thanks for your correct. I prefer to take the last one ;) > Cheers, > Emil > > P.S. Why do you resend the whole series (some 10+ patches) when only a > few patches have been changed ? Are all the patches changed whist > missing that information (vX: rebase on top of A) Yes, those 10+ patches do base on the previous changes, specially when I rebase my series on the latest linux-next branch. Besides, I don't know that how to send parts of this series, and keep the unrelated patches no send. For example if the [v4 03/16] ~ [v4 10/16] need update to v5, and [v4 11/16] ~ [v4 16/16] keep in v4. So should I only send the [v5 03/16] ~ [v5 10/16], no need to send and update [v4 11/16] ~ [v4 16/16] to v5 ? If so I think it would be difficult for guys to comment, cause they can't see the whole series in one reply list . ;) Thanks, - Yakir > >
[Bug 91790] TONGA hang in amdgpu_ring_lock
https://bugs.freedesktop.org/show_bug.cgi?id=91790 --- Comment #15 from Andy Furniss --- (In reply to Andy Furniss from comment #13) > (In reply to Mathias Tillman from comment #11) > > (In reply to Alex Deucher from comment #10) > > > Created attachment 118056 [details] [review] [review] [review] > > > possible fix > > > > > > I think this patch should fix it. > > > > No luck here I'm afraid - I'm having a hard time reproducing it during > > normal desktop usage (with or without the patch), but it did lockup while > > running Unigine Valley. > > I see drm-next-4.3 is now ahead again, haven't tested that yet. > > With patch + drm-next-4.3-wip, I haven't yet managed to lock valley - but > I've only had time to do a couple of runs (45 min then 90 min) from a clean > boot. Maybe later when I've been up a while doing other things I'll try > harder. > > Patch doesn't apply with git apply - did it by hand. I managed to lock it, seems that doing "something" between runs changes things, or first runs are lucky. FWIW I tried running Unreal 4.5 ElementalDemo after my long runs and I got a signal 7. After I later locked/hung valley I rebooted and tried again elemental from a clean boot and it ran OK, but after quitting. it now gives signal 7 again if I try to start it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/fc928ddc/attachment.html>
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
On Thu, Sep 03, 2015 at 10:19:00AM +0100, Russell King - ARM Linux wrote: > On Wed, Sep 02, 2015 at 04:43:38PM -0700, Doug Anderson wrote: > > Russell, > > > > On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux > > wrote: > > > Never copy the of_node from one device to another. That allows the > > > bus matching to unintentionally match the of_node against the wrong > > > driver. > > > > Can you be more specific about what problems you'd expect. It seems > > like a terribly common practice to do this, but maybe I'm > > misunderstanding: > > The problem with copying an of_node from one struct device to another > struct device is of_match_device(). > > Devices in a DT setup are bound to drivers using dev->of_node - when a > new device or driver is registered onto a bus, the new object is matched > against all un-bound objects (devices or drivers as appropriate) > comparing the compatible string gained from dev->of_node against the > list of of_device_id strings provided by the driver. > > When a match is found, the two are attempted to be bound together. > > Consider what happens when you have a platform device with an of_node, > and you bind that to a driver matched via the compatible string. The > driver creates a new platform device, and copies the of_node to this > new device so the new device can have access to the properties of the > of_node. > > What happens next? Does the new device bind to the same driver (and > thus we enter an infinite loop) or does it bind to some other driver > as the author originally hoped? Depends whether the other driver is > earlier in the list of drivers or later, whether it's in the kernel > or not. > > It's less of a problem when you copy the of_node between two different > buses, because they won't match the same driver, but this is a dangerous > act - if stuff copies it in one direction, what's to stop someone copying > it back to a new device on the original bus. As soon as that happens, > things can go awol. > > It would be a good idea if either: > 1) this never happened > or > 2) we had a flag which said "ignore the of_node for driver matching" > > And yes, we do have drivers which do exactly what I said above. They > work through luck rather than design. Perhaps the I2C core needs to be taught to look at the adapter's ->dev.parent->of_node in of_find_i2c_adapter_by_node(). As I understand it the purpose for registering a separate struct device for each I2C controller is so that there's an I2C parent for all slaves. At the same time every controller sets up ->dev.parent, and that parent's OF node is what we really want when we look up an I2C adapter by OF node. In other words, the OF node by which I2C adapters are referenced is always that of its parent device, as far as I can tell. Wolfram, do you know of any cases where adapter->dev.of_node would not be the same as adapter->dev.parent->of_node? Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/80388b69/attachment.sig>
[Bug 91790] TONGA hang in amdgpu_ring_lock
https://bugs.freedesktop.org/show_bug.cgi?id=91790 --- Comment #14 from Mathias Tillman --- Created attachment 118060 --> https://bugs.freedesktop.org/attachment.cgi?id=118060&action=edit Output of amdgpu_regs and amdgpu_fence_info I have attached the output of amdgpu_regs and amdgpu_fence_info. Hang is right after the hang happened, Normal is right after a reboot after the hang (for comparison). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/df127efb/attachment.html>
[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY
Hi Rob,
å¨ 09/02/2015 09:27 PM, Rob Herring åé:
> On Tue, Sep 1, 2015 at 1:04 AM, Yakir Yang wrote:
>> This phy driver would control the Rockchip DisplayPort module
>> phy clock and phy power, it is relate to analogix_dp-rockchip
>> dp driver. If you want DP works rightly on rockchip platform,
>> then you should select both of them.
>>
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v4:
>> - Take Kishon suggest, add commit message, and remove the redundant
>>rockchip_dp_phy_init() function, move those code to probe() method.
>>And remove driver .owner number.
>>
>> Changes in v3:
>> - Take Heiko suggest, add rockchip dp phy driver,
>>collect the phy clocks and power control.
>>
>> Changes in v2: None
>>
>> .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26
> It is preferred that you split binding doc's from driver changes.
Okay, done.
>> drivers/phy/Kconfig| 7 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-rockchip-dp.c | 166
>> +
>> 4 files changed, 200 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> create mode 100644 drivers/phy/phy-rockchip-dp.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> new file mode 100644
>> index 000..5de1088
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> @@ -0,0 +1,26 @@
>> +Rockchip Soc Seroes Display Port PHY
>> +
>> +
>> +Required properties:
>> +- compatible : should be one of the following supported values:
>> +- "rockchip.rk3288-dp-phy"
>> +
>> +- reg : a list of registers used by phy driver
> Please state the size of the list and order of what each entry if more than
> one.
Just like Heiko remind, I don't need the reg number anymore,
"rockchip,grf" is enough for this driver.
Anyway thanks :-)
>> +- clocks: from common clock binding: handle to dp clock.
>> + of memory mapped region.
>> +- clock-names: from common clock binding:
>> + Required elements: "sclk_dp" "sclk_dp_24m"
>> +
>> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> I have no idea what GRF means.
GRF is an module of our IC chip, the full name is General Register Files.
I would rather to pick some words from our TRM.
The general register file will be used to do static set by software, which
is composed of many registers for system control.
>
>> +- #phy-cells : from the generic PHY bindings, must be 0;
>> +
>> +Example:
>> +
>> +edp_phy: phy at ff770274 {
>> + compatilble = "rockchip,rk3288-dp-phy";
>> + reg = <0xff770274 4>;
>> + rockchip,grf = <&grf>;
>> + clocks = <&cru SCLK_EDP_24M>;
>> + clock-names = "24m";
>> + #phy-cells = <0>;
>> +}
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 47da573..8f2bc4f 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
>> help
>>Enable this to support the Rockchip USB 2.0 PHY.
>>
>> +config PHY_ROCKCHIP_DP
>> + tristate "Rockchip Display Port PHY Driver"
>> + depends on ARCH_ROCKCHIP && OF
>> + select GENERIC_PHY
>> + help
>> + Enable this to support the Rockchip Display Port PHY.
>> +
>> config PHY_ST_SPEAR1310_MIPHY
>> tristate "ST SPEAR1310-MIPHY driver"
>> select GENERIC_PHY
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index a5b18c1..e281f35 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
>> phy-s5pv210-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
>> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>> +obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
>> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
>> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
>> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
>> new file mode 100644
>> index 000..e9a726e
>> --- /dev/null
>> +++ b/drivers/phy/phy-rockchip-dp.c
>> @@ -0,0 +1,166 @@
>> +/*
>> + * Rockchip DP PHY driver
>> + *
>> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
>> + * Author: Yakir Yang
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Thu, Sep 03, 2015 at 12:27:47PM +0800, Yakir Yang wrote: > Hi Rob, > > å¨ 09/03/2015 04:17 AM, Rob Herring åé: > >On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: > >>Some edp screen do not have hpd signal, so we can't just return > >>failed when hpd plug in detect failed. > >This is a property of the panel (or connector perhaps), so this > >property should be located there. At least, it is a common issue and > >not specific to this chip. We could have an HDMI connector and failed > >to hook up HPD for example. A connector node is also where hpd-gpios > >should be located instead (and are already defined by > >../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector > >binding, too. > > Yep, I agree with your front point, it is a property of panel, not specific > to eDP controller, so this code should handle in connector logic.
[RFC 11/13] drm/dp: Add helper to dump DPCD
Hi, I'm back from vacation, so I'll be looking at this again. On Thu, Aug 20, 2015 at 04:26:42PM -0700, Rafael Antognolli wrote: > On Mon, Aug 17, 2015 at 10:02:04AM +0300, Jani Nikula wrote: > > On Fri, 14 Aug 2015, Rafael Antognolli > > wrote: > > > On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote: > > >> On Wed, 12 Aug 2015, Thierry Reding wrote: > > >> > From: Thierry Reding > > >> > > > >> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a > > >> > seq_file and can be used to make the DPCD available via debugfs for > > >> > example. > > >> > > >> See i915/i915_debugfs.c for one DPCD dump implementation. > > >> > > >> Around the time that was added, there was also some discussion (and > > >> patches [1]) to expose a read/write debugfs interface to DPCD, letting > > >> userspace access arbitrary DPCD registers. > > >> > > >> Just this week there was some discussion about revisiting that. It was > > >> about accessing some proprietary panel features, but there's also the > > >> ease of debugging without having to keep updating the kernel to dump > > >> more. > > >> > > >> I think it would be great to agree on a common debugfs interface to > > >> access DPCD arbitrarily. Last time I checked, the blocker to that was > > >> access to the aux channel from generic code; it's always driver > > >> specific. SMOP. ;) > > > > > > Do you mean it would require the generic code/interface to somehow route > > > this to the driver specific code? I am not sure yet how this works (if > > > there's something like it around), but I'll take a look. > > > > Drivers can choose to support DP AUX any way they like, and they don't > > have to use the common helpers to do so. It's pretty much an > > implementation detail. I think we could require the use of the common > > helpers to support generic DPCD access from debugfs, but we'd still have > > to come up with a way to get hold of struct drm_dp_aux (again, driver > > internals) given a drm_connector in generic debugfs code. > > I was under the assumption they always used the helpers, but I > understand that's not always the case. > > Anyway, I was going to propose a new helper to "store" the drm_dp_aux > inside the drm_connector. And just expose something on debugfs if it was > used. Something like: > > int drm_dp_aux_store(struct drm_dp_aux *aux, > struct drm_connector *connector); > > The helpers don't seem to know about drm_connector's though, so I'm not sure > this is a good approach. > > > Thierry, do you see any problems with having a connector function to get > > hold of its drm_dp_aux? > > Would this be a new function pointer inside struct drm_connector_funcs? > If so, I'm fine with this approach too. > > Regarding the interface, you mentioned that you didn't like it because > it had a state. What about just dumping the content of the register into > dmesg when one tries to read it, and use a different sintaxe for > writing, passing both the register addr and the value? > > Daniel had another suggestion, regarding an ioctl in debugfs, but I'm > not sure I clearly understand that yet. Regarding the interface, this is the comment Daniel did a while ago: "As mentioned in another thread I think the right approach here is to expose the dp aux interface through some ioctls in debugfs or dev somewhere, and then add simple tools on top of that. Similar to what we have with i2c. That would allow us to implement additional things on top like mst inspection or using the i2c-over-dp-aux sidechannel." If exposing through an ioctl, shouldn't it be yet another DRM ioctl? And if not, then I should create another /dev node/file specifically for this purpose, right? And if we are going with ioctls, I still don't understand exactly how it relates to debugfs. Thanks, Rafael
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_cleanup_fb':
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:272:26: error: 'fb' redeclared as
different kind of symbol
struct drm_framebuffer *fb = old_state->fb;
^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:267:27: note: previous definition of
'fb' was here
struct drm_framebuffer *fb,
^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: At top level:
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: initialization from
incompatible pointer type
.cleanup_fb = mdp5_plane_cleanup_fb,
^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: (near initialization
for 'mdp5_plane_helper_funcs.cleanup_fb')
Caused by commit
a317290af0db ("drm/atomic: Make prepare_fb/cleanup_fb only take state, v3")
Well, that was clearly never build tested :-(
I have used the drm-misc tree from next-20150902 for today.
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote: [...] > Are there any eDP panels which don't have EDID and need panel details in DT? Most panels need information other than EDID. They typically have some requirements regarding the power up sequence that aren't to be found anywhere in EDID or detectable by some other mechanism. A decision was therefore made a long time ago to require panels to be listed in DT with a specific compatible string. That way all of these details can be stashed away in drivers that know how to deal with these kinds of details. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/f4039697/attachment-0001.sig>
[PATCH v4 09/16] drm: rockchip: add bpc and color mode setting
On Wed, Sep 02, 2015 at 06:02:25PM +0800, Yakir Yang wrote: > å¨ 2015/9/2 16:34, Thierry Reding åé: [...] > >At the very least your code must compile when applied against a recent > >upstream tree. I would also expect you to make sure the code works at > >runtime, though, contrary to build testing, not everybody will be able > >to verify that you've actually done so. It is ultimately your platform > >maintainer's (i.e. Heiko's) responsibility to ensure that because they > >will get to deal with user complaints if people can't run an upstream > >kernel on the devices. > > Oh, first time to know this rule. So I should work on Heiko's github > kernel branch at the first time to start send upstream. It's usually not necessary to rebase on a specific platform tree. Most platform trees should feed into linux-next anyway, so linux-next would be the appropriate base in almost all cases. Note, though, that that's only true if you expect somebody else to merge your code. The reason is that whoever will end up applying your patches will likely apply to a tree that feeds into linux-next, and that way you both end up having roughly the same base. On the other hand if you are a maintainer yourself you should be keeping a branch based on the latest -rc1. That's especially important if your tree feeds into linux-next, because basing on linux-next will break very horribly that way. So for this particular case I would expect either Mark or Inki to apply these patches when they're ready. Their trees should be based on the latest -rc1. At least the Exynos DRM tree feeds into linux-next, so you should be fine if you use linux-next as a base. Mark, have you ever considered having your tree added to linux-next? I'm beginning to think that we need to make that a requirement for all DRM drivers so that we can resolve integration issues early on rather than Dave having to deal with them when he pulls code in. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/07896369/attachment.sig>
[Bug 91790] TONGA hang in amdgpu_ring_lock
https://bugs.freedesktop.org/show_bug.cgi?id=91790 --- Comment #13 from Andy Furniss --- (In reply to Mathias Tillman from comment #11) > (In reply to Alex Deucher from comment #10) > > Created attachment 118056 [details] [review] [review] > > possible fix > > > > I think this patch should fix it. > > No luck here I'm afraid - I'm having a hard time reproducing it during > normal desktop usage (with or without the patch), but it did lockup while > running Unigine Valley. I see drm-next-4.3 is now ahead again, haven't tested that yet. With patch + drm-next-4.3-wip, I haven't yet managed to lock valley - but I've only had time to do a couple of runs (45 min then 90 min) from a clean boot. Maybe later when I've been up a while doing other things I'll try harder. Patch doesn't apply with git apply - did it by hand. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/b12a5081/attachment.html>
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
On Wed, Sep 02, 2015 at 04:43:38PM -0700, Doug Anderson wrote: > Russell, > > On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux > wrote: > > Never copy the of_node from one device to another. That allows the > > bus matching to unintentionally match the of_node against the wrong > > driver. > > Can you be more specific about what problems you'd expect. It seems > like a terribly common practice to do this, but maybe I'm > misunderstanding: The problem with copying an of_node from one struct device to another struct device is of_match_device(). Devices in a DT setup are bound to drivers using dev->of_node - when a new device or driver is registered onto a bus, the new object is matched against all un-bound objects (devices or drivers as appropriate) comparing the compatible string gained from dev->of_node against the list of of_device_id strings provided by the driver. When a match is found, the two are attempted to be bound together. Consider what happens when you have a platform device with an of_node, and you bind that to a driver matched via the compatible string. The driver creates a new platform device, and copies the of_node to this new device so the new device can have access to the properties of the of_node. What happens next? Does the new device bind to the same driver (and thus we enter an infinite loop) or does it bind to some other driver as the author originally hoped? Depends whether the other driver is earlier in the list of drivers or later, whether it's in the kernel or not. It's less of a problem when you copy the of_node between two different buses, because they won't match the same driver, but this is a dangerous act - if stuff copies it in one direction, what's to stop someone copying it back to a new device on the original bus. As soon as that happens, things can go awol. It would be a good idea if either: 1) this never happened or 2) we had a flag which said "ignore the of_node for driver matching" And yes, we do have drivers which do exactly what I said above. They work through luck rather than design. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[Bug 91780] Rendering issues with geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=91780 --- Comment #7 from Jonas Wielicki --- (In reply to Jonas Wielicki from comment #6) > This time, I started glxgears first to make sure that everything was set up > properly, PRIME-wise. glxgears was running fine at a reasonable frame rate. > > Then I started the gsraytrace demo, which made the X11 freeze. (I then went > to fetch some tea) Both programs were spamming the above error message when > the GUI had unfreezed. Sorry for the spam, here the output of gsraytrace: ``` GL_RENDERER = Gallium 0.4 on AMD TURKS (DRM 2.42.0, LLVM 3.5.0) ESC = exit demo left mouse + drag = rotate camera radeon: The kernel rejected CS, see dmesg for more information. 0.044456 FPS (1 frames in 22.493999 seconds) radeon: The kernel rejected CS, see dmesg for more information. [⦠the above message repeated a few hundred times before I killed it â¦] ``` -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/a2fe7022/attachment-0001.html>
[Bug 91780] Rendering issues with geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=91780
--- Comment #6 from Jonas Wielicki ---
(In reply to Dieter Nützel from comment #2)
> And maybe test Mesa-demo 'gsraytrace'?
I am having a hard time to get gsraytrace to run. I am not sure whether this is
related to this bug or to PRIME issues, as in general, using the Radeon GPU is
a bit unstable here. The instability manifests in not receiving any rendering
output in the window and sometimes error messages ("radeon: The kernel rejected
CS, see dmesg for more information.").
I made two tests:
FIRST TEST
When trying to run the gsraytrace demo on the radeon, I did not receive visual
output in the window; no rendering took place, the window contents were never
written and were showing what was at that place on the screen before the window
opened. The terminal suggested a frame rate of 1 FPS. No crash happened.
I then tried to distinguish between PRIME failure and demo failure by opening a
glxgears instance on the radeon gpu, which made the whole X11 freeze for a few
seconds and afterwards both glxgears and the gsraytrace demo spammed the above
error message.
SECOND TEST
This time, I started glxgears first to make sure that everything was set up
properly, PRIME-wise. glxgears was running fine at a reasonable frame rate.
Then I started the gsraytrace demo, which made the X11 freeze. (I then went to
fetch some tea) Both programs were spamming the above error message when the
GUI had unfreezed.
At no point I ever saw visual output from the gsraytrace demo. As I said, I am
not sure what of this is purely due to PRIME and what is caused by the bug this
entry refers to. I just wanted to add my data here as it was requested for and
I donât think I will get better results on my own.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/5cbdf57c/attachment.html>
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
On 01.09.2015 14:49, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge
> directory, and rename the core driver to analogix_dp_*,
> leave the platform code to analogix_dp-exynos.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4:
> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery.
> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
> "exynos_dp.c"
> - Take Archit suggest, create a separate folder for analogix code in bridge/
>
> Changes in v3:
> - Take Thierry Reding suggest, move exynos's video_timing code
> to analogix_dp-exynos platform driver, add get_modes method
> to struct analogix_dp_plat_data.
> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
>
> Changes in v2:
> - Take Jingoo Han suggest, remove new copyright
> - Fix compiled failed dut to analogix_dp_device misspell
>
> drivers/gpu/drm/bridge/Kconfig |2 +
> drivers/gpu/drm/bridge/Makefile|1 +
> drivers/gpu/drm/bridge/analogix/Kconfig|4 +
> drivers/gpu/drm/bridge/analogix/Makefile |1 +
> .../analogix/analogix_dp_core.c} | 817 ++---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 283 +
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1265
>
> .../analogix/analogix_dp_reg.h}| 258 ++--
> drivers/gpu/drm/exynos/Kconfig |3 +-
> drivers/gpu/drm/exynos/Makefile|2 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 306 +
> drivers/gpu/drm/exynos/exynos_dp_core.h| 282 -
> drivers/gpu/drm/exynos/exynos_dp_reg.c | 1259 ---
> include/drm/bridge/analogix_dp.h | 24 +
> 14 files changed, 2357 insertions(+), 2150 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
> rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
> bridge/analogix/analogix_dp_core.c} (50%)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
> bridge/analogix/analogix_dp_reg.h} (64%)
> create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
> create mode 100644 include/drm/bridge/analogix_dp.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 2de52a5..7b5b77a 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
> ---help---
> Parade eDP-LVDS bridge chip driver.
>
> +source "drivers/gpu/drm/bridge/analogix/Kconfig"
> +
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index e2eef1c..5366c6b 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
> obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> new file mode 100644
> index 000..5ff6551
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -0,0 +1,4 @@
> +config DRM_ANALOGIX_DP
> + tristate
> + depends on DRM
> + select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> new file mode 100644
> index 000..9107b86
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> similarity index 50%
> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index bed0252..7d62f22 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1,14 +1,14 @@
> /*
> - * Samsung SoC DP (Display Port) interface driver.
> - *
> - * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> - * Author: Jingoo Han
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License as published by the
> - * Free Software Foundation; either version 2 of the License, or (at your
> - * option) any later version.
> - */
> +* Analogix DP (Display Port) core interface driver.
> +*
> +* Copyright (C) 2012 Samsung Electronics Co., Ltd.
> +* Author:
[PATCH 4/6] drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
On Thu, Aug 27, 2015 at 05:23:29PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > A address-only I2C_WRITE can't be replied with a short i2c ack, but I > suppose it could be replied with an i2c defer. So the code should be > prepared for an address-only I2C_WRITE_STATUS_UPDATE. > > Cc: Thierry Reding > Cc: "Terje Bergström" > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/tegra/dpaux.c | 1 + > 1 file changed, 1 insertion(+) Acked-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/663b5712/attachment.sig>
[PATCH v4 01/16] drm: exynos/dp: fix code style
On 01.09.2015 14:46, Yakir Yang wrote:
> After run "checkpatch.pl -f --subjective" command, I see there
> are lots of alignment problem in exynos_dp driver, so let just
> fix them.
Hi,
Warnings from checkpatch are not a reason for a commit. Reason for a
commit could be for example an unreadable code, violation of
coding-style leading to decrease in code maintainability or just
improving the code readability so it will be easier to review and
maintain it.
You do not make commits because some tool tells you that. We do not
listen to machines :) ... If that would be the case, the commit could be
made automatically, without human interaction. Such automated commit
could be even easily tested by the machine by comparing object files.
Especially that you enabled "subjective" rule. This is not a valid
motivation for a commit.
Please rephrase this to sensible reason and convince that change is
worth the effort.
>
> - Take Romain suggest, rebase on linux-next branch
That comment seems unrelated to the commit. Please remove it.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Take Joe Preches advise, improved commit message more readable, and
> avoid using some uncommon style like bellow:
> - retval = exynos_dp_read_bytes_from_i2c(...
> ...)
> + retval =
> + exynos_dp_read_bytes_from_i2c(..);
>
> drivers/gpu/drm/exynos/exynos_dp_core.c | 226
>
> drivers/gpu/drm/exynos/exynos_dp_core.h | 54
> drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
> 3 files changed, 188 insertions(+), 198 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index d66ade0..266f7f7 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
>
> /* Read Extension Flag, Number of 128-byte EDID extension blocks */
> retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
> - EDID_EXTENSION_FLAG,
> - &extend_block);
> + EDID_EXTENSION_FLAG,
> + &extend_block);
> if (retval)
> return retval;
>
> @@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
> dev_dbg(dp->dev, "EDID data includes a single extension!\n");
>
> /* Read EDID data */
> - retval = exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
> - EDID_HEADER_PATTERN,
> - EDID_BLOCK_LENGTH,
> - &edid[EDID_HEADER_PATTERN]);
> + retval = exynos_dp_read_bytes_from_i2c(
> + dp, I2C_EDID_DEVICE_ADDR,
> + EDID_HEADER_PATTERN,
> + EDID_BLOCK_LENGTH,
> + &edid[EDID_HEADER_PATTERN]);
> if (retval != 0) {
> dev_err(dp->dev, "EDID Read failed!\n");
> return -EIO;
> @@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
> }
>
> /* Read additional EDID data */
> - retval = exynos_dp_read_bytes_from_i2c(dp,
> - I2C_EDID_DEVICE_ADDR,
> - EDID_BLOCK_LENGTH,
> - EDID_BLOCK_LENGTH,
> - &edid[EDID_BLOCK_LENGTH]);
> + retval = exynos_dp_read_bytes_from_i2c(
> + dp, I2C_EDID_DEVICE_ADDR,
> + EDID_BLOCK_LENGTH,
> + EDID_BLOCK_LENGTH,
> + &edid[EDID_BLOCK_LENGTH]);
> if (retval != 0) {
> dev_err(dp->dev, "EDID Read failed!\n");
> return -EIO;
> @@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
> }
>
> exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
> - &test_vector);
> + &test_vector);
> if (test_vector & DP_TEST_LINK_EDID_READ) {
> - exynos_dp_write_byte_to_dpcd(dp,
> - DP_TEST_EDID_CHECKSUM,
> + exynos_dp_write_byte_to_dpcd(
> + dp, DP_TEST_EDID_CHECKSUM,
> edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
> - exynos_dp_write_byte_to_dpcd(dp,
> - DP_T
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Thierry, On Thu, Sep 3, 2015 at 2:39 AM, Thierry Reding wrote: > Perhaps the I2C core needs to be taught to look at the adapter's > ->dev.parent->of_node in of_find_i2c_adapter_by_node(). As I understand > it the purpose for registering a separate struct device for each I2C > controller is so that there's an I2C parent for all slaves. At the same > time every controller sets up ->dev.parent, and that parent's OF node is > what we really want when we look up an I2C adapter by OF node. In other > words, the OF node by which I2C adapters are referenced is always that > of its parent device, as far as I can tell. > > Wolfram, do you know of any cases where adapter->dev.of_node would not > be the same as adapter->dev.parent->of_node? This sounds pretty reasonable to me. Certainly it would be a pretty reasonable fallback if adapter->dev.of_node was NULL. -Doug
[PATCH v4 07/16] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
On 01.09.2015 15:01, Yakir Yang wrote:
> After exynos_dp have been splited the common IP code into analogix_dp driver,
s/splited/split/
> the analogix_dp driver have deprecated some samsung platform properties which
s/samsung/Samsung/
> could be dynamic parsed from EDID/MODE/DPCD message, so this is an update for
s/dynamic/dynamically/
> exynos DTS file for dp-controller.
/exynos/Exynos/
>
> Beside analogix_dp have provide the backward compatibility, so there are no
> bisectability break that make this change in a separate patch.
It took me some time to figure out the meaning of this sentence... Did
you want to say that backward compatibility is fully preserved?
You are removing samsung,dynamic-range and samsung,ycbcr-coeff. I would
assume that now:
1. on all these board these values would be parsed from EDID/MODE/DPCD
message?
2. everything would work as previously?
Am I understanding it correctly?
The patch itself looks good.
Best regards,
Krzysztof
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4:
> - Take Krzysztof suggest, separate all DTS changes to a separate patch.
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
> arch/arm/boot/dts/exynos5250-snow.dts | 4 +---
> arch/arm/boot/dts/exynos5250-spring.dts| 4 +---
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +---
> arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
> 7 files changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index db3f65f..4636862 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -124,8 +124,6 @@
> &dp {
> status = "okay";
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index c625e71..cd424d6 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -80,8 +80,6 @@
>
> &dp {
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 0720caa..242b621 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -244,12 +244,10 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd>;
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <2>;
> - samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
> + hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
>
> ports {
> port at 0 {
> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> b/arch/arm/boot/dts/exynos5250-spring.dts
> index c1edd6d..91881d7 100644
> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> @@ -74,12 +74,10 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd_gpio>;
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <1>;
> - samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
> + hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
> };
>
> &ehci {
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 8f4d76c..7433683 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -148,12 +148,10 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd_gpio>;
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x06>;
> samsung,lane-count = <2>;
> - samsung,hpd-gpio = <&gpx2 6 0>;
> + hpd-gpio = <&gpx2 6 0>;
>
> ports {
> port at 0 {
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 98871f9..b3df3c1 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -92,8 +92,6 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd>;
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
[Bug 91790] TONGA hang in amdgpu_ring_lock
https://bugs.freedesktop.org/show_bug.cgi?id=91790 --- Comment #12 from Christian König --- (In reply to Mathias Tillman from comment #11) > No luck here I'm afraid - I'm having a hard time reproducing it during > normal desktop usage (with or without the patch), but it did lockup while > running Unigine Valley. Assuming you can still access the box over the network after the lockup then please provide the output of the following as root: cat /sys/kernel/debug/dri/0/amdgpu_fence_info hexdump -s 0x14fc -n 4 /sys/kernel/debug/dri/0/amdgpu_regs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150903/4fd2e033/attachment.html>
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
On Wed, Sep 02, 2015 at 04:00:07PM -0700, Doug Anderson wrote: > Russell, > > On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux > wrote: > >> I think you may want to add "adap->dev.of_node = hdmi->dev->of_node;" > >> here. That will allow device trees to specify the i2c bus by using an > >> alias. > > > > Never copy the of_node from one device to another. That allows the > > bus matching to unintentionally match the of_node against the wrong > > driver. > > So does that mean we need to create a sub-node for the i2c bus if we > want something like this? > > > > Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect > > that's asking for trouble. > > I doubt it's appropriate. Why do you ask? To find out why you want to "specify the I2C bus". Surely if we're talking about the DDC bus, we either want to use a separate I2C bus (in which case the HDMI DT description needs to specify which I2C bus to use) or we want to use the HDMI-internal I2C bus, which being part of the HDMI driver, the HDMI driver will know how to find it itself - there should be no need to put an explicit ddc-i2c-bus self-reference there in that case. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
