[PULL] drm-intel-next
Hi Dave, First feature pull request for 3.13. Highlights: drm-intel-next-2013-09-21: - clock state handling rework from Ville - l3 parity handling fixes for hsw from Ben - some more watermark improvements from Ville - ban badly behaved context from Mika - a few vlv improvements from Jesse - VGA power domain handling from Ville drm-intel-next-2013-09-06: - Basic mipi dsi support from Jani. Not yet converted over to drm_bridge since that was too fresh, but the porting is in progress already. - More vma patches from Ben, this time the code to convert the execbuffer code. Now that the shrinker recursion bug is tracked down we can move ahead here again. Yay! - Optimize hw context switching to not generate needless interrupts (Chris Wilson). Also some shuffling for the oustanding request allocation. - Opregion support for SWSCI, although not yet fully wired up (we need a bit of runtime D3 support for that apparently, due to Windows design deficiencies), from Jani Nikula. - A few smaller changes all over. Plus a backmerge of -rc2 since things became unwielding. Note that this contains the DSI connector/encoder #defines in drm core that Thierry wants to use for tegar (or at least he poked me a while back where they're stuck). Cheers, Daniel The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-09-21-merged for you to fetch changes up to b599c89e8c5cf0c37352e0871be240291f8ce922: Merge tag 'v3.12-rc2' into drm-intel-next (2013-09-24 09:32:53 +0200) Ben Widawsky (14): drm/i915: Convert execbuf code to use vmas drm/i915: Restore the preliminary HW check. drm/i915: Synchronize pread/pwrite with wait_rendering drm/i915: Extract vm specific part of eviction drm/i915: evict VM instead of everything drm/i915: Remove extra "ring" drm/i915: Round l3 parity reads down drm/i915: Fix l3 parity user buffer offset drm/i915: Fix HSW parity test drm/i915: Add second slice l3 remapping drm/i915: Make l3 remapping use the ring drm/i915: Keep a list of all contexts drm/i915: Do remaps for all contexts drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF Chon Ming Lee (3): drm/i915: Modify DP set clock to accomodate more eDP timings v2 drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2 drm/i915: Add additional pipe parameter for vlv_dpio_read and vlv_dpio_write. v2 Chris Wilson (8): drm/i915: Don't destroy the vma placeholder during execbuffer reservation drm/i915: Always prefer CPU relocations with LLC drm/i915: Do not add an interrupt for a context switch drm/i915: Rearrange the comments in i915_add_request() drm/i915: Rename ring->outstanding_lazy_request drm/i915; Preallocate the lazy request drm/i915: Write RING_TAIL once per-request drm/i915: Remove the double-list iteration from bound_any() Damien Lespiau (2): drm/i915: It's its! drm/i915: Remove unused mode_fixup() vfunc of struct intel_dvo_dev_ops Dan Carpenter (1): drm/i915: cleanup a min_t() cast Daniel Vetter (8): drm/i915: inline vma_create into lookup_or_create_vma drm/i915: More vma fixups around unbind/destroy drm/i915/dsi: s/size_t/int/ drm/i915: Fix list corruption in vma_unbind drm/i915: re-layout intel_panel.c to obey 80 char limit drm/i915: garbage-collect vlv refclk function drm/i915: dump crtc timings from the pipe config Merge tag 'v3.12-rc2' into drm-intel-next Jani Nikula (23): drm/i915: add more VLV IOSF sideband ports accessors drm/i915: add VLV pipeconf bit definition for DSI PLL lock drm/i915: add MIPI DSI register definitions drm/i915: add MIPI DSI output type and subtypes drm/i915: add structs for MIPI DSI output drm/i915: add MIPI DSI command sending routines drm/i915: add basic MIPI DSI output support drm/i915: fix PLL assertions for DSI PLL drm/i915: don't enable DPLL for DSI drm/i915: initialize DSI output on VLV drm/i915: add plumbing for SWSCI drm/i915: expose intel_ddi_get_encoder_port() drm/i915: add opregion function to notify bios of encoder enable/disable drm/i915: add opregion function to notify bios of adapter power state drm/i915: do display power state notification on crtc enable/disable drm/i915: name intel dp hooks per platform drm/i915: move backlight enable later in vlv enable sequence drm/i915: clean up power sequencing register port select definitions drm/i915: add support for per-pipe power sequencing on vlv drm/i915: add asserts for cursor disabled drm/i915: only report hpd connector status change when it actua
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #38 from Vladimir Mityukov --- I'm not sure if I have the same issue. In particular, I could not find this error in my dmesg: .. [drm:radeon_acpi_init] *ERROR* Cannot find a backlight controller .. But I do have the issue that my laptop does not wake up fully (the screen is black). There is some noise starts in the notebook and led indicators start blinking, but the screen does not turn ON. I know, there are many possible reasons, but it worked with Catalyst, so, I think it has to be connected to video driver (dri, kms, xf86-video-ati, whatever..). $ lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6520G] 02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] $ uname -a Linux pilat-book 3.11.1-2-ARCH #1 SMP PREEMPT Sun Sep 22 19:45:00 CEST 2013 x86_64 GNU/Linux I use radeon.dpm=1 in the kernel options; Here's the bug-report to Archlinux tracker, but they suggested to file the bug here: https://bugs.archlinux.org/task/37078 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gma500: define do_gma_backlight_set only when used
On Fri, 27 Sep 2013, Patrik Jakobsson wrote: >> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE Hi, while at it, you should probably let backlight be built as module: #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE) Cheers, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Code stereo layouts as an enum in the mode structure
Daniel noticed that it wasn't very smart to keep using one bit per stereo layout now that we don't have to or them. It's a nice final touch to the new stereo mode API extension that we should fix before committing to it. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Code stereo layouts as an enum rather than a bit field
This allows us to use fewer bits in the mode structure, leaving room for
future work while allowing more stereo layouts types than we could have
ever dreamt of.
I also exposed the previously private DRM_MODE_FLAG_3D_MASK to set in
stone that we are using 5 bits for the stereo layout enum, reserving 32
values.
Even with that reservation, we gain 3 bits from the previous encoding.
The code adding the mandatory stereo modes needeed to be adapted as it was
relying or being able to or stereo layouts together.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 47 +++--
include/drm/drm_crtc.h | 9 -
include/uapi/drm/drm_mode.h | 19 ++
3 files changed, 26 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c24af1d..7d1e8a9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2562,16 +2562,16 @@ struct stereo_mandatory_mode {
};
static const struct stereo_mandatory_mode stereo_mandatory_modes[] = {
- { 1920, 1080, 24,
- DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1920, 1080, 24, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
+ { 1920, 1080, 24, DRM_MODE_FLAG_3D_FRAME_PACKING },
{ 1920, 1080, 50,
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
{ 1920, 1080, 60,
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
- { 1280, 720, 50,
- DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
- { 1280, 720, 60,
- DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
+ { 1280, 720, 50, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
+ { 1280, 720, 50, DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1280, 720, 60, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
+ { 1280, 720, 60, DRM_MODE_FLAG_3D_FRAME_PACKING }
};
static bool
@@ -2586,50 +2586,33 @@ stereo_match_mandatory(const struct drm_display_mode
*mode,
drm_mode_vrefresh(mode) == stereo_mode->vrefresh;
}
-static const struct stereo_mandatory_mode *
-hdmi_find_stereo_mandatory_mode(const struct drm_display_mode *mode)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(stereo_mandatory_modes); i++)
- if (stereo_match_mandatory(mode, &stereo_mandatory_modes[i]))
- return &stereo_mandatory_modes[i];
-
- return NULL;
-}
-
static int add_hdmi_mandatory_stereo_modes(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
const struct drm_display_mode *mode;
struct list_head stereo_modes;
- int modes = 0;
+ int modes = 0, i;
INIT_LIST_HEAD(&stereo_modes);
list_for_each_entry(mode, &connector->probed_modes, head) {
- const struct stereo_mandatory_mode *mandatory;
- u32 stereo_layouts, layout;
-
- mandatory = hdmi_find_stereo_mandatory_mode(mode);
- if (!mandatory)
- continue;
-
- stereo_layouts = mandatory->flags & DRM_MODE_FLAG_3D_MASK;
- do {
+ for (i = 0; i < ARRAY_SIZE(stereo_mandatory_modes); i++) {
+ const struct stereo_mandatory_mode *mandatory;
struct drm_display_mode *new_mode;
- layout = 1 << (ffs(stereo_layouts) - 1);
- stereo_layouts &= ~layout;
+ if (!stereo_match_mandatory(mode,
+ &stereo_mandatory_modes[i]))
+ continue;
+ mandatory = &stereo_mandatory_modes[i];
new_mode = drm_mode_duplicate(dev, mode);
if (!new_mode)
continue;
- new_mode->flags |= layout;
+ new_mode->flags |= mandatory->flags;
list_add_tail(&new_mode->head, &stereo_modes);
modes++;
- } while (stereo_layouts);
+ }
}
list_splice_tail(&stereo_modes, &connector->probed_modes);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b2d08ca..eb6b8dc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -181,15 +181,6 @@ struct drm_display_mode {
int hsync; /* in kHz */
};
-#define DRM_MODE_FLAG_3D_MASK (DRM_MODE_FLAG_3D_FRAME_PACKING | \
-DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE | \
-DRM_MODE_FLAG_3D_LINE_ALTERNATIVE | \
-DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL | \
-DRM_MODE_FLAG_3D_L_DEPTH | \
-DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_D
[PATCH 2/3] drm: Revert "drm: Reject modes with more than 1 stereo flags set"
Now that the coding of stereo layout has changed from a bit field to an enum, we need remove that check. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_crtc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 807309f..2ce80ed 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1319,10 +1319,6 @@ static int drm_crtc_convert_umode(struct drm_display_mode *out, if (in->clock > INT_MAX || in->vrefresh > INT_MAX) return -ERANGE; - /* At most, 1 set bit describing the 3D layout of the mode */ - if (hweight32(in->flags & DRM_MODE_FLAG_3D_MASK) > 1) - return -EINVAL; - out->clock = in->clock; out->hdisplay = in->hdisplay; out->hsync_start = in->hsync_start; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: Reject stereo modes with an unknown layout
The kernel shouldn't accept invalid modes, just say No.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 3 +++
include/drm/drm_crtc.h | 2 ++
include/uapi/drm/drm_mode.h | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2ce80ed..d7a8370 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1319,6 +1319,9 @@ static int drm_crtc_convert_umode(struct drm_display_mode
*out,
if (in->clock > INT_MAX || in->vrefresh > INT_MAX)
return -ERANGE;
+ if ((in->flags & DRM_MODE_FLAG_3D_MASK) > DRM_MODE_FLAG_3D_MAX)
+ return -EINVAL;
+
out->clock = in->clock;
out->hdisplay = in->hdisplay;
out->hsync_start = in->hsync_start;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index eb6b8dc..50cedad 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -128,6 +128,8 @@ enum drm_mode_status {
#define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing */
#define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
+#define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+
struct drm_display_mode {
/* Header */
struct list_head head;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7980f89..c2c4ace 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -58,6 +58,10 @@
#define DRM_MODE_FLAG_PIXMUX (1<<11)
#define DRM_MODE_FLAG_DBLCLK (1<<12)
#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+ /*
+ * When adding a new stereo mode don't forget to adjust DRM_MODE_FLAGS_3D_MAX
+ * (define not exposed to user space).
+ */
#define DRM_MODE_FLAG_3D_MASK (0x1f<<14)
#define DRM_MODE_FLAG_3D_NONE (0<<14)
#define DRM_MODE_FLAG_3D_FRAME_PACKING(1<<14)
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH edid-decode 2/3] Include the last VIC in the CEA video block
Signed-off-by: Thomas Wood
---
edid-decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/edid-decode.c b/edid-decode.c
index 3830e0c..b710bb5 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -711,7 +711,7 @@ cea_video_block(unsigned char *x)
int i;
int length = x[0] & 0x1f;
-for (i = 1; i < length; i++) {
+for (i = 1; i <= length; i++) {
unsigned char vic = x[i] & 0x7f;
unsigned char native = x[i] & 0x80;
const char *mode;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH edid-decode 1/3] Add a missing comma to the list of CEA VICs
Signed-off-by: Thomas Wood
---
edid-decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/edid-decode.c b/edid-decode.c
index d3e3118..3830e0c 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -649,7 +649,7 @@ static const char *edid_cea_modes[] = {
"1440x240@60Hz",
"1440x240@60Hz",
"2880x480i@60Hz",
-"2880x480i@60Hz"
+"2880x480i@60Hz",
"2880x240@60Hz",
"2880x240@60Hz",
"1440x480@60Hz",
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH edid-decode 3/3] Print the correct VIC number next to the mode
Signed-off-by: Thomas Wood --- edid-decode.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/edid-decode.c b/edid-decode.c index b710bb5..4265843 100644 --- a/edid-decode.c +++ b/edid-decode.c @@ -715,10 +715,11 @@ cea_video_block(unsigned char *x) unsigned char vic = x[i] & 0x7f; unsigned char native = x[i] & 0x80; const char *mode; + int index; - vic--; - if (vic < ARRAY_SIZE(edid_cea_modes)) - mode = edid_cea_modes[vic]; + index = vic - 1; + if (index < ARRAY_SIZE(edid_cea_modes)) + mode = edid_cea_modes[index]; else mode = "Unknown mode"; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/dp: add defines for downstream port types
Detailed cap info at address 80h is not available with DPCD ver 1.0. Whether such devices exist in the wild I don't know, but there should be no harm done in having the defines for downstream port 0 in address 05h. Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index ae8dbfb..83da4eb 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -77,10 +77,10 @@ #define DP_DOWNSTREAMPORT_PRESENT 0x005 # define DP_DWN_STRM_PORT_PRESENT (1 << 0) # define DP_DWN_STRM_PORT_TYPE_MASK 0x06 -/* 00b = DisplayPort */ -/* 01b = Analog */ -/* 10b = TMDS or HDMI */ -/* 11b = Other */ +# define DP_DWN_STRM_PORT_TYPE_DP (0 << 1) +# define DP_DWN_STRM_PORT_TYPE_ANALOG (1 << 1) +# define DP_DWN_STRM_PORT_TYPE_TMDS (2 << 1) +# define DP_DWN_STRM_PORT_TYPE_OTHER(3 << 1) # define DP_FORMAT_CONVERSION (1 << 3) # define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) /* DPI */ -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915/dp: downstream port capabilities are not present in DPCD 1.0
We haven't read the downstream port caps for DPCD 1.0, so don't use
them.
v2: use defines for DPCD 1.0 downstream port types
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..2f04f0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2817,7 +2817,6 @@ static enum drm_connector_status
intel_dp_detect_dpcd(struct intel_dp *intel_dp)
{
uint8_t *dpcd = intel_dp->dpcd;
- bool hpd;
uint8_t type;
if (!intel_dp_get_dpcd(intel_dp))
@@ -2828,8 +2827,8 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
/* If we're HPD-aware, SINK_COUNT changes dynamically */
- hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD);
- if (hpd) {
+ if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
+ intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
uint8_t reg;
if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
®, 1))
@@ -2843,9 +2842,18 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
/* Well we tried, say unknown for unreliable port types */
- type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
- if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_NON_EDID)
- return connector_status_unknown;
+ if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
+ type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+ if (type == DP_DS_PORT_TYPE_VGA ||
+ type == DP_DS_PORT_TYPE_NON_EDID)
+ return connector_status_unknown;
+ } else {
+ type = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+ DP_DWN_STRM_PORT_TYPE_MASK;
+ if (type == DP_DWN_STRM_PORT_TYPE_ANALOG ||
+ type == DP_DWN_STRM_PORT_TYPE_OTHER)
+ return connector_status_unknown;
+ }
/* Anything else is out of spec, warn and ignore */
DRM_DEBUG_KMS("Broken DP branch device, ignoring\n");
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/edid: add drm_edid_duplicate
We have some code duplication related to EDID duplication. Add a helper.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 12
include/drm/drm_crtc.h |1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c24af1d..412b80f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1264,6 +1264,18 @@ struct edid *drm_get_edid(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_get_edid);
+/**
+ * drm_edid_duplicate - duplicate an EDID and the extensions
+ * @edid: EDID to duplicate
+ *
+ * Return duplicate edid or NULL on allocation failure.
+ */
+struct edid *drm_edid_duplicate(const struct edid *edid)
+{
+ return kmemdup(edid, (edid->extensions + 1) * EDID_LENGTH, GFP_KERNEL);
+}
+EXPORT_SYMBOL(drm_edid_duplicate);
+
/*** EDID parsing ***/
/**
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b2d08ca..8ab633a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -980,6 +980,7 @@ extern int drm_mode_group_init_legacy_group(struct
drm_device *dev, struct drm_m
extern bool drm_probe_ddc(struct i2c_adapter *adapter);
extern struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
+extern struct edid *drm_edid_duplicate(const struct edid *edid);
extern int drm_add_edid_modes(struct drm_connector *connector, struct edid
*edid);
extern void drm_mode_probed_add(struct drm_connector *connector, struct
drm_display_mode *mode);
extern void drm_mode_copy(struct drm_display_mode *dst, const struct
drm_display_mode *src);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/exynos: use drm_edid_duplicate
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4400330..26e089f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -101,7 +101,6 @@ static struct edid *vidi_get_edid(struct device *dev,
{
struct vidi_context *ctx = get_vidi_context(dev);
struct edid *edid;
- int edid_len;
/*
* the edid data comes from user side and it would be set
@@ -112,8 +111,7 @@ static struct edid *vidi_get_edid(struct device *dev,
return ERR_PTR(-EFAULT);
}
- edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
- edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
+ edid = drm_edid_duplicate(ctx->raw_edid);
if (!edid) {
DRM_DEBUG_KMS("failed to allocate edid\n");
return ERR_PTR(-ENOMEM);
@@ -485,7 +483,6 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void
*data,
struct exynos_drm_manager *manager;
struct exynos_drm_display_ops *display_ops;
struct drm_exynos_vidi_connection *vidi = data;
- int edid_len;
if (!vidi) {
DRM_DEBUG_KMS("user data for vidi is null.\n");
@@ -524,8 +521,7 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void
*data,
DRM_DEBUG_KMS("edid data is invalid.\n");
return -EINVAL;
}
- edid_len = (1 + raw_edid->extensions) * EDID_LENGTH;
- ctx->raw_edid = kmemdup(raw_edid, edid_len, GFP_KERNEL);
+ ctx->raw_edid = drm_edid_duplicate(raw_edid);
if (!ctx->raw_edid) {
DRM_DEBUG_KMS("failed to allocate raw_edid.\n");
return -ENOMEM;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/i915/dp: use drm_edid_duplicate
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..aed9d67 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2920,18 +2920,12 @@ intel_dp_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
/* use cached edid if we have one */
if (intel_connector->edid) {
struct edid *edid;
- int size;
/* invalid edid */
if (IS_ERR(intel_connector->edid))
return NULL;
- size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
- edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
- if (!edid)
- return NULL;
-
- return edid;
+ return drm_edid_duplicate(edid);
}
return drm_get_edid(connector, adapter);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/edid: add drm_edid_duplicate
On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote: > We have some code duplication related to EDID duplication. Add a helper. Lgtm, debated the merits of assuming GFP_KERNEL and inlining, then thought better of it. All 3, Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH edid-decode 1/3] Add a missing comma to the list of CEA VICs
On Fri, Sep 27, 2013 at 12:26:59PM +0100, Thomas Wood wrote: > Signed-off-by: Thomas Wood For the series (that fixes 2 embarassing bugs from me and 1 long standing one that wasn't parsing the last CEA VIC): Reviewed-by: Damien Lespiau -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #15 from Bruno Wolff III --- So far I have 26935fb06ee88f1188789807687c03041f3c70d9 as the last known good commit and 48efe453e6b29561f78a1df55c7f58375259cb8c as the first known bad commit. Of the commits there, the most suspicious ones have to do with the strict_strto*() to kstrto*() change as it looks like that might affect parameter parsing. This would be commits 6072ddc8520b86adfac6939ca32fb6e6c4de017a and 57103d7fe1833857cf542a482c1eb8da0bf86e5d. I still expect to have the bisect done by sometime on Monday (or maybe late Sunday). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/edid: add drm_edid_duplicate
On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote: > We have some code duplication related to EDID duplication. Add a helper. git grep kmemdup.*edid drivers/gpu/drm/ also returns 3 hits in nouveau here, should anyone be bored. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66738] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)
https://bugs.freedesktop.org/show_bug.cgi?id=66738 --- Comment #15 from lh --- linux 3.11.2 without radeon dpm, seems stable now. But still have randomly freeze problem with dpm on. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69805] flightgear crashes on r600 (rs880) with llvm backend
https://bugs.freedesktop.org/show_bug.cgi?id=69805 vincent changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |v...@ovi.com |.org| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62231] New: No HDMI audio (pass through) on ASUS F2A55-M (ATI Trinity Aruba GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=62231 Bug ID: 62231 Summary: No HDMI audio (pass through) on ASUS F2A55-M (ATI Trinity Aruba GPU) Product: Drivers Version: 2.5 Kernel Version: 3.12-rc2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: smf.li...@ntlworld.com Regression: No +++ This bug was initially created as a clone of Bug #61981 +++ I think I sent my original bug report to the wrong queue. Simply this system has been configured to use HDMI audio and on this kernel there is no output. I did try on 3.12-rc1 but I had problems booting the system which have been fixed with 3.12-rc2. The system works on 3.11.1 with a hand crafted patch of the early HDMI audio work intended for 3.12 so I know the basic setup works. Since the original bug report I have been attempting to bisect the problem to identify the commit that caused my system to stop working on the 3.12 rc's. Here is my bisect log as you can see the only good commit for me is Alex's please advise: authorAlex Deucher 2013-07-31 20:51:33 (GMT) committerAlex Deucher 2013-08-30 20:30:45 (GMT) commitb530602fd4625f763344e455902981b22f85f609 (patch) treefb1c932b2bf74b76fbbdc198d527a698088500c2 parenta4d39e68949f5b4f7b426be63782b421018f741a (diff) (3.11.0-rc7-00066-gb530602) git bisect start # bad: [4a10c2ac2f368583138b774ca41fac4207911983] Linux 3.12-rc2 git bisect bad 4a10c2ac2f368583138b774ca41fac4207911983 # good: [b530602fd4625f763344e455902981b22f85f609] drm/radeon: add audio support for DCE6/8 GPUs (v12) git bisect good b530602fd4625f763344e455902981b22f85f609 # bad: [57d730924d5cc2c3e280af16a9306587c3a511db] Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad 57d730924d5cc2c3e280af16a9306587c3a511db # bad: [40031da445fb4d269af9c7c445b2adf674f171e7] Merge tag 'pm+acpi-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm git bisect bad 40031da445fb4d269af9c7c445b2adf674f171e7 # bad: [542a086ac72fb193cbc1b996963a572269e57743] Merge tag 'driver-core-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect bad 542a086ac72fb193cbc1b996963a572269e57743 # bad: [1ccfd5eaf8f0135a0ce030728d1739e0eea4e3ce] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect bad 1ccfd5eaf8f0135a0ce030728d1739e0eea4e3ce # bad: [578739259875a93b1869d25cdf4a8bd963b7d0a7] Merge remote-tracking branch 'spi/topic/txx9' into spi-next git bisect bad 578739259875a93b1869d25cdf4a8bd963b7d0a7 # bad: [45bb5065e11cd770fcf4afe9714ccea671333766] Merge remote-tracking branch 'spi/topic/octeon' into spi-next git bisect bad 45bb5065e11cd770fcf4afe9714ccea671333766 # bad: [96b1a28d65bfc942d84fb612b7f33279390b8ba4] Merge remote-tracking branch 'spi/topic/doc' into spi-next git bisect bad 96b1a28d65bfc942d84fb612b7f33279390b8ba4 # bad: [b29bc3df37afa440290f4b8e50cf5dce429ce22f] Merge remote-tracking branch 'spi/topic/bitbang' into spi-next git bisect bad b29bc3df37afa440290f4b8e50cf5dce429ce22f # bad: [c3dbe2b76a835fb4b2633645b0c49359b49eb128] Merge remote-tracking branch 'spi/topic/bcm2835' into spi-next git bisect bad c3dbe2b76a835fb4b2633645b0c49359b49eb128 # bad: [5264af0ca696e19b492f31837a570787f6fd399b] Merge remote-tracking branch 'spi/topic/atmel' into spi-next git bisect bad 5264af0ca696e19b492f31837a570787f6fd399b # bad: [2de024b766bb9e31c357f70c6344d1107f38ce1a] spi/atmel: Fix format specifier warnings git bisect bad 2de024b766bb9e31c357f70c6344d1107f38ce1a # bad: [6c07ef298ac2a05e14cdb059169a78c74badf056] spi/atmel: Annotate lock/unlock functions git bisect bad 6c07ef298ac2a05e14cdb059169a78c74badf056 # bad: [dfec4a6e42286dacc733c7e6be43606a5622ca58] spi: atmel: prepare clk before calling enable git bisect bad dfec4a6e42286dacc733c7e6be43606a5622ca58dfec4a6e42286dacc733c7e6be43606a5622ca58 is the first bad commit commit dfec4a6e42286dacc733c7e6be43606a5622ca58 Author: Boris BREZILLON Date: Tue Jul 16 17:16:22 2013 +0200 spi: atmel: prepare clk before calling enable Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to avoid common clk framework warnings. Signed-off-by: Boris BREZILLON Signed-off-by: Mark Brown :04 04 45e7cb28411864c00b62296a7ff239f9f139d5d9 368391aa85e315792047dfafbb745793634c5672 Mdrivers -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62231] No HDMI audio (pass through) on ASUS F2A55-M (ATI Trinity Aruba GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=62231 --- Comment #1 from Stuart Foster --- *** Bug 61981 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH edid-decode 1/3] Add a missing comma to the list of CEA VICs
On Fri, Sep 27, 2013 at 12:26:59PM +0100, Thomas Wood wrote: > Signed-off-by: Thomas Wood Thanks for the series, all pushed with the virtual nod from Ajax on IRC. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 Johannes Obermayr changed: What|Removed |Added See Also||http://llvm.org/bugs/show_b ||ug.cgi?id=12109, ||https://bugzilla.novell.com ||/show_bug.cgi?id=839074 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #10 from Fredrik Höglund --- The raster backend does all its rendering in an xshm image, so it's likely that the problem is in the ShmPutImage path. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #36 from Michel Dänzer --- commit c45e728107269c6f51599dad4f6a02ccfef703f1 Author: Michel Dänzer Date: Wed Sep 18 10:57:52 2013 +0200 DRI2: Install client callback only once -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62231] No HDMI audio (pass through) on ASUS F2A55-M (ATI Trinity Aruba GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=62231 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher --- In 3.12, hdmi audio is exposed as a connector property so you can enable audio on the fly rather than needing to pass radeon.audio=1 to force it on. E.g., xrandr --output HDMI-0 --set audio auto -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #16 from Michel Dänzer --- Someone who has the necessary powers please reassign according to https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111758.html . -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Thu, 26 Sep 2013, Aaron Lu wrote: > I checked the git log for the commit to use tpacpi_acpi_handle_locate to > locate video controller's ACPI handle, it's: > > commit 122f26726b5e16174bf8a707df14be1d93c49d62 > Author: Henrique de Moraes Holschuh > Date: Mon Aug 9 23:48:18 2010 -0300 Yeah... > So I checked out that commit and found that it shouldn't work either, > since it has the same problem of the current code. > > The ACPI video controller device is given an id of ACPI_VIDEO_HID, but > it's only known to Linux ACPI, not ACPICA, so the function provided by > ACPICA acpi_get_devices will not work in this case, as that function will > really check the control method of _HID under the handle, which does not > exist no matter if Linux ACPI has added an id to its device structure or > not. OTOH, the function provided by Linux ACPI acpi_device_hid will see > the added id. In a word, the add of the HID will not affect the ASL > namespace layout of the device node(thus, no _HID control method will > be added to the device node). Erk. It went broken for a long time, and the users didn't notice(!)... > commit ff413195e830541afeae469fc866ecd0319abd7e > Author: Alex Hung > Date: Tue Apr 24 16:40:52 2012 +0800 > > thinkpad-acpi: fix issuing duplicated key events for brightness up/down > > The tp_features.bright_acpimode will not be set correctly for brightness > control because ACPI_VIDEO_HID will not be located in ACPI. As a result, > a duplicated key event will always be sent. acpi_video_backlight_support() > is sufficient to detect standard ACPI brightness control. > > Signed-off-by: Alex Hung > Signed-off-by: Matthew Garrett Until that. And unfortunately I did not connect the dots at the time. Thanks for explaining the issue properly. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Tue, 24 Sep 2013, Aaron Lu wrote: > The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to > locate handle for ACPI video by HID, the problem is, ACPI video node > doesn't really have HID defined(i.e. no _HID control method is defined > for video device), so.. that function would fail. This can be solved by > enhancing the callback function for acpi_get_devices, where we can use > acpi_device_hid function to check if the ACPI node corresponds to a > video controller. > > In addition to that, the _BCL control method only exists under a video > output device node, not a video controller device node. So to evaluate > _BCL, we need the handle of a video output device node, which is child > of the located video controller node from tpacpi_acpi_handle_locate. > > The two fix are necessary for some Thinkpad models to emit notification > on backlight hotkey press as a result of evaluation of _BCL. > > Signed-off-by: Aaron Lu > Tested-by: Igor Gnatenko Some testing on a *60 (T60,X60...) would also be best, I cannot test this on my T43. Anyway, the code itself looks fine, so: Acked-by: Henrique de Moraes Holschuh -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] Fix compile error in drivers/gpu/drm/msm/msm_drv.c with IOMMU disabled
On Wed, Sep 25, 2013 at 10:49 AM, Joerg Roedel wrote:
> The function msm_iommu_get_ctx() is needed buy the MSM-GPU
> driver with and wiithout IOMMU compiled in. Make the
> function available when no IOMMU driver is there.
>
For this one,
Reviewed-by: Rob Clark
But I am not the right one to merge this one. And, well, if there is
a way to make this work without msm_iommu_get_ctx(), I am interested
in some hints ;-)
Of the other two, 1/3 looks fine and I'll pull that in. And I'll see
if I can come up with a better way for 2/3
BR,
-R
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/msm_iommu.h |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/iommu/msm_iommu.h b/drivers/iommu/msm_iommu.h
> index 5c7c955..da53558 100644
> --- a/drivers/iommu/msm_iommu.h
> +++ b/drivers/iommu/msm_iommu.h
> @@ -108,7 +108,14 @@ struct msm_iommu_ctx_drvdata {
> * Useful for testing and drivers that do not yet fully have IOMMU stuff in
> * their platform devices.
> */
> +#ifdef CONFIG_MSM_IOMMU
> struct device *msm_iommu_get_ctx(const char *ctx_name);
> +#else
> +static inline struct device *msm_iommu_get_ctx(const char *ctx_name)
> +{
> + return NULL;
> +}
> +#endif
>
> /*
> * Interrupt handler for the IOMMU context fault interrupt. Hooking the
> --
> 1.7.9.5
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Code stereo layouts as an enum in the mode structure
On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote: > Daniel noticed that it wasn't very smart to keep using one bit per stereo > layout now that we don't have to or them. It's a nice final touch to the new > stereo mode API extension that we should fix before committing to it. Assuming you still trust me even though I didn't see this possibility during my review of the original series :) For the series: Reviewed-by: Ville Syrjälä -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 Bjorn Helgaas changed: What|Removed |Added CC||kh...@linux-fr.org --- Comment #17 from Bjorn Helgaas --- Bruno or Dieter, can you try Jean's patch from the email mentioned in comment #16? If v3.12-rc2 + Jean's patch solves the problem, it might save you a lot of bisect time. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] Fix compile error in drivers/gpu/drm/msm/msm_drv.c with IOMMU disabled
Hi Rob, On Fri, Sep 27, 2013 at 11:28:36AM -0400, Rob Clark wrote: > But I am not the right one to merge this one. And, well, if there is > a way to make this work without msm_iommu_get_ctx(), I am interested > in some hints ;-) > > Of the other two, 1/3 looks fine and I'll pull that in. And I'll see > if I can come up with a better way for 2/3 Yeah, patch 2/3 was not meant very seriously, it was more a way to say that someone should fix it who knows the best way how to do it ;) Thanks for your review and taking 1/3. Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: constify DP DPCD helpers
None of the DP DPCD helpers need to modify the DPCD.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 16
include/drm/drm_dp_helper.h | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 89e1966..9e978aa 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -228,12 +228,12 @@ i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
EXPORT_SYMBOL(i2c_dp_aux_add_bus);
/* Helpers for DP link training */
-static u8 dp_link_status(u8 link_status[DP_LINK_STATUS_SIZE], int r)
+static u8 dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
{
return link_status[r - DP_LANE0_1_STATUS];
}
-static u8 dp_get_lane_status(u8 link_status[DP_LINK_STATUS_SIZE],
+static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane)
{
int i = DP_LANE0_1_STATUS + (lane >> 1);
@@ -242,7 +242,7 @@ static u8 dp_get_lane_status(u8
link_status[DP_LINK_STATUS_SIZE],
return (l >> s) & 0xf;
}
-bool drm_dp_channel_eq_ok(u8 link_status[DP_LINK_STATUS_SIZE],
+bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count)
{
u8 lane_align;
@@ -262,7 +262,7 @@ bool drm_dp_channel_eq_ok(u8
link_status[DP_LINK_STATUS_SIZE],
}
EXPORT_SYMBOL(drm_dp_channel_eq_ok);
-bool drm_dp_clock_recovery_ok(u8 link_status[DP_LINK_STATUS_SIZE],
+bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count)
{
int lane;
@@ -277,7 +277,7 @@ bool drm_dp_clock_recovery_ok(u8
link_status[DP_LINK_STATUS_SIZE],
}
EXPORT_SYMBOL(drm_dp_clock_recovery_ok);
-u8 drm_dp_get_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
+u8 drm_dp_get_adjust_request_voltage(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane)
{
int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
@@ -290,7 +290,7 @@ u8 drm_dp_get_adjust_request_voltage(u8
link_status[DP_LINK_STATUS_SIZE],
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_voltage);
-u8 drm_dp_get_adjust_request_pre_emphasis(u8 link_status[DP_LINK_STATUS_SIZE],
+u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SIZE],
int lane)
{
int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
@@ -303,7 +303,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(u8
link_status[DP_LINK_STATUS_SIZE],
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
-void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
+void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
udelay(100);
else
@@ -311,7 +311,7 @@ void drm_dp_link_train_clock_recovery_delay(u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
-void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
+void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
udelay(400);
else
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ae8dbfb..88661ad 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -333,20 +333,20 @@ i2c_dp_aux_add_bus(struct i2c_adapter *adapter);
#define DP_LINK_STATUS_SIZE 6
-bool drm_dp_channel_eq_ok(u8 link_status[DP_LINK_STATUS_SIZE],
+bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count);
-bool drm_dp_clock_recovery_ok(u8 link_status[DP_LINK_STATUS_SIZE],
+bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count);
-u8 drm_dp_get_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
+u8 drm_dp_get_adjust_request_voltage(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane);
-u8 drm_dp_get_adjust_request_pre_emphasis(u8 link_status[DP_LINK_STATUS_SIZE],
+u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SIZE],
int lane);
#define DP_RECEIVER_CAP_SIZE 0xf
#define EDP_PSR_RECEIVER_CAP_SIZE 2
-void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
-void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
+void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]);
+void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
u8 drm_dp_link_rate_to_bw_code(int link_rate);
int drm_dp_bw_code_to_link_rate(u8 link_bw);
@@ -379,13 +379,13 @@ struct edp_vsc_psr {
#define EDP_VSC_PSR_CRC_VALUES_VALID (1<<2)
stat
Re: [PATCH] drm/dp: constify DP DPCD helpers
On Fri, Sep 27, 2013 at 07:01:01PM +0300, Jani Nikula wrote:
> None of the DP DPCD helpers need to modify the DPCD.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 16
> include/drm/drm_dp_helper.h | 16
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 89e1966..9e978aa 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -228,12 +228,12 @@ i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
> EXPORT_SYMBOL(i2c_dp_aux_add_bus);
>
> /* Helpers for DP link training */
> -static u8 dp_link_status(u8 link_status[DP_LINK_STATUS_SIZE], int r)
> +static u8 dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
> {
> return link_status[r - DP_LANE0_1_STATUS];
> }
>
> -static u8 dp_get_lane_status(u8 link_status[DP_LINK_STATUS_SIZE],
> +static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
>int lane)
> {
> int i = DP_LANE0_1_STATUS + (lane >> 1);
> @@ -242,7 +242,7 @@ static u8 dp_get_lane_status(u8
> link_status[DP_LINK_STATUS_SIZE],
> return (l >> s) & 0xf;
> }
>
> -bool drm_dp_channel_eq_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count)
> {
> u8 lane_align;
> @@ -262,7 +262,7 @@ bool drm_dp_channel_eq_ok(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_channel_eq_ok);
>
> -bool drm_dp_clock_recovery_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count)
> {
> int lane;
> @@ -277,7 +277,7 @@ bool drm_dp_clock_recovery_ok(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_clock_recovery_ok);
>
> -u8 drm_dp_get_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_voltage(const u8
> link_status[DP_LINK_STATUS_SIZE],
>int lane)
> {
> int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
> @@ -290,7 +290,7 @@ u8 drm_dp_get_adjust_request_voltage(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_voltage);
>
> -u8 drm_dp_get_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane)
> {
> int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
> @@ -303,7 +303,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> -void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
> +void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> udelay(100);
> else
> @@ -311,7 +311,7 @@ void drm_dp_link_train_clock_recovery_delay(u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> -void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
> +void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> udelay(400);
> else
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index ae8dbfb..88661ad 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -333,20 +333,20 @@ i2c_dp_aux_add_bus(struct i2c_adapter *adapter);
>
>
> #define DP_LINK_STATUS_SIZE 6
> -bool drm_dp_channel_eq_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count);
> -bool drm_dp_clock_recovery_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count);
> -u8 drm_dp_get_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_voltage(const u8
> link_status[DP_LINK_STATUS_SIZE],
>int lane);
> -u8 drm_dp_get_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane);
>
> #define DP_RECEIVER_CAP_SIZE 0xf
> #define EDP_PSR_RECEIVER_CAP_SIZE2
>
> -void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
> -void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
> +void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_R
[Bug 62231] No HDMI audio (pass through) on ASUS F2A55-M (ATI Trinity Aruba GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=62231 --- Comment #3 from Stuart Foster --- (In reply to Alex Deucher from comment #2) > In 3.12, hdmi audio is exposed as a connector property so you can enable > audio on the fly rather than needing to pass radeon.audio=1 to force it on. > E.g., > > xrandr --output HDMI-0 --set audio auto Tried the xrandr on 3.12.0-rc2 and it crashed, should I have removed the radeon.audio=1 ? Linux Ariel 3.12.0-rc2 #3 SMP Thu Sep 26 08:35:29 BST 2013 i686 GNU/Linux DMesg: kernel BUG at mm/slub.c:3338! invalid opcode: [#1] SMP Modules linked in: nfsv3 sha256_generic cbc dm_crypt hid_logitech_dj usbhid ohci_pci ohci_hcd psmouse snd_hda_codec_hdmi i2c_piix4 sr_mod cdrom snd_hda_intel acpi_cpufreq processor button thermal_sys tuner msp3400 saa7127 saa7115 ivtv tveeprom cx2341x cifs dm_mod md5 nfs nfsd lockd sunrpc snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_hda_codec_realtek snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore brd loop k10temp fam15h_power eeprom CPU: 1 PID: 1752 Comm: X Not tainted 3.12.0-rc2 #3 Hardware name: System manufacturer System Product Name/F2A55-M, BIOS 6403 07/22/2013 task: f4e762e0 ti: f2212000 task.ti: f2212000 EIP: 0060:[] EFLAGS: 00210246 CPU: 1 EIP is at kfree+0xaa/0xc0 EAX: 8000 EBX: 1800 ECX: 00010005 EDX: 00200292 ESI: f4cda000 EDI: EBP: f5c1e020 ESP: f2213afc DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 80050033 CR2: 0804b7cb CR3: 33263000 CR4: 000407f0 Stack: 00200292 0025 f4cda000 f4f84e60 c138c537 00010005 1880 00028488 1800 f4cda000 b000 f4cda000 b000 c13350c5 000c 0002 f440a400 f440a400 f4cda000 f2097100 Call Trace: [] ? dce6_afmt_write_speaker_allocation+0xb7/0x120 [] ? evergreen_hdmi_setmode+0x2e5/0x840 [] ? dce6_endpoint_rreg+0x50/0x60 [] ? evergreen_hdmi_enable+0xc6/0xe0 [] ? radeon_atom_encoder_mode_set+0x151/0x2c0 [] ? drm_crtc_helper_set_mode+0x41b/0x480 [] ? radeon_property_change_mode.isra.5+0x32/0x40 [] ? radeon_connector_set_property+0x173/0x2a0 [] ? drm_mode_obj_set_property_ioctl+0x142/0x3c0 [] ? kmem_cache_free+0x9a/0xc0 [] ? drm_mode_obj_set_property_ioctl+0x3c0/0x3c0 [] ? drm_mode_connector_property_set_ioctl+0x2e/0x40 [] ? drm_ioctl+0x3e6/0x480 [] ? drm_mode_obj_set_property_ioctl+0x3c0/0x3c0 [] ? sock_aio_read+0xd1/0x100 [] ? drm_copy_field+0x60/0x60 [] ? do_vfs_ioctl+0x34f/0x540 [] ? vfs_read+0xd9/0x120 [] ? SyS_ioctl+0x3a/0x80 [] ? sysenter_do_call+0x12/0x26 Code: e8 c7 c3 3e 00 eb df f7 45 00 00 c0 00 00 74 1b 8b 45 00 31 d2 f6 c4 40 74 03 8b 55 38 83 c4 08 89 e8 5b 5e 5f 5d e9 f6 c3 fc ff <0f> 0b eb 12 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 EIP: [] kfree+0xaa/0xc0 SS:ESP 0068:f2213afc -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #14 from Pierre Ossman --- (In reply to comment #3) > Created attachment 86598 [details] [review] > use hw generated cts and n values rather than the sw programmed values > > Does this patch help? If not, it may be worth adding some slop to the > r600_hdmi_predefined_acr[] table to handle rounding differences so the > appropriate defined values get selected. A quick test indicates that this patch does indeed solve the issue. I've played three minutes of AC3 audio without any interruptions. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #15 from Pierre Ossman ---
(In reply to comment #4)
> Something like this:
>
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index b0fa600..f7d2766 100644
> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
> @@ -63,7 +63,7 @@ static const struct radeon_hdmi_acr
> r600_hdmi_predefined_acr[] = {
> { 27027, 4096, 27027, 6272, 30030, 6144, 27027 }, /*
> 27.00*1.001 MHz */
> { 54000, 4096, 54000, 6272, 6, 6144, 54000 }, /* 54.00
> MHz */
> { 54054, 4096, 54054, 6272, 60060, 6144, 54054 }, /*
> 54.00*1.001 MHz */
> -{ 74175, 11648, 210937, 17836, 234375, 11648, 140625 }, /*
> 74.25/1.001 MHz */
> +{ 74180, 11648, 210937, 17836, 234375, 11648, 140625 }, /*
> 74.25/1.001 MHz */
> { 74250, 4096, 74250, 6272, 82500, 6144, 74250 }, /* 74.25
> MHz */
> { 148351, 11648, 421875, 8918, 234375, 5824, 140625 }, /*
> 148.50/1.001 MHz */
> { 148500, 4096, 148500, 6272, 165000, 6144, 148500 }, /* 148.50
> MHz */
This however does not improve things. But that was because the frequency was
actually 74176, not 74180 (damn all that rounded output).
With that fixed, it *seems* to work. But doing the numbers, the audio clock is
slightly off as those numbers assume a perfect 74.25/1.001 video clock, not the
74.176 approximation. And 33 kHz audio needs a changing CTS even with that. So
it doesn't seem like a robust approach IHMO. I vote for letting the hardware do
its magic.
Somewhat related, the calculation in r600_hdmi_calc_cts() is not very good as
it loses a tonne of precision (roughly ten bits' worth). Given the range of the
inputs, you might need to do the calculations in a 64-bit space.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #18 from Bruno Wolff III --- I'll be able to try it tonight or tomorrow. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Fri, 27 Sep 2013, Yves-Alexis Perez wrote: > On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote: > > Some testing on a *60 (T60,X60...) would also be best, I cannot test > > this on > > my T43. > > > > Anyway, the code itself looks fine, so: > > I can test on T61, would that help? I think so. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915/dp: downstream port capabilities are not present in DPCD 1.0
On Fri, 2013-09-27 at 14:48 +0300, Jani Nikula wrote: > We haven't read the downstream port caps for DPCD 1.0, so don't use > them. > > v2: use defines for DPCD 1.0 downstream port types > > Signed-off-by: Jani Nikula I don't know if I've ever seen a DPCD 1.0 device, but the changes make sense. For the series: Reviewed-by: Adam Jackson - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69889] New: WMV3/VC-1 garbled output with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=69889 Priority: medium Bug ID: 69889 Assignee: dri-devel@lists.freedesktop.org Summary: WMV3/VC-1 garbled output with VDPAU Severity: normal Classification: Unclassified OS: All Reporter: pierre-bugzi...@ossman.eu Hardware: Other Status: NEW Version: 9.2 Component: Drivers/DRI/R600 Product: Mesa I've been trying out the new VDPAU support for Radeon cards, and it works fine except for two issues: 1. Occasional system lockup (haven't found what triggers this yet) 2. No WMV3/VC-1 files will play whatsoever. For every file I get the same thing, mostly black with a few lines of green/purple junk at the top. mesa-libGL-9.2-1.20130919.fc19.x86_64 libvdpau-0.7-1.fc19.x86_64 kernel-3.11.1-200.fc19.x86_64 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570] [1002:6759] Is it possible to get the driver to stop claiming VC-1 support so that I can enjoy the H.264 acceleration until a fix is in place? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
A simple alternative to GEM
Hello I'm new in linux dri development, so please please forgive me if I dont understand something. I'm working on my opensource gpu project. I've already implemented software simulator, and implementation in verilog is 40% complete. Right now I've only 2 problems: LLVM needs to be patched and DRI. Thats why I wrote this letter: DRI is too complicated for me and I think DRI can be safely simplified, and new features will be easily implementable. In my opinion, DRI can be significantly simplified. Just get rid of "buffer" concept. I've read intel and amd docs. Modern GPUs have fully functional MMU on board. Radeons have multiple MMUs. Also GPUs have special registers which describe buffer types and buffer locations within gpu virtual address space. These registers are not related to memory protection. So, memory is protected by GPU's MMU and we can safely allow usermode app to aim texture resource register to ANY valid location in address space associated with app's GPU context. Also, as long as we control allocation of physical pages and page tables, we can allow usermode app to control it's GPU memory map. Implement the folllowing operations: create context, create memmap, alllocate physical pages from a specified pool, map the pages to a valid virtual address, release pages(with memmap invalidation), and execute any GPU command with a memmap-and there will be no need in GEM, TTM and other legacy. This approach is as simple(in lines of code) as a hammer. PBOs and VBOs can be transparently emulated in userspace library, so there will be no need to break api. Btw, this approach enables a very interesring optmization: tile-based page flipping. This feature will be especially useful for partial window updates and resizing of windows in wayland: an app can dynamically reallocate it's buffer and there will be no need for full redraw and XMir driver hacks. Regards, Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69889] WMV3/VC-1 garbled output with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=69889 Christian König changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Christian König --- Well known problem, only VC-1 advanced profile (as found on Blueray disks) is supported by the hardware. *** This bug has been marked as a duplicate of bug 65611 *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65611] UVD accelerated decoding causes hangs (ARUBA - HD 7540D)
https://bugs.freedesktop.org/show_bug.cgi?id=65611 Christian König changed: What|Removed |Added CC||pierre-bugzi...@ossman.eu --- Comment #1 from Christian König --- *** Bug 69889 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/CDF RFC v3 0/3] Migrate CDFv3 into pl111 drm/kms driver
Hi all, This series patches base on Tom's "Initial drm/kms driver for pl111"[1] with linaro release 13.07 and migrate the CDFv3 for evaluation. please notes that I set VGA as default output and tested on RTSM only. [1] http://lwn.net/Articles/561344/ Cheers, Show Liu Show Liu (3): Add display entities and pipe link for pl111 Add display entity and set VGA output(site MB) as default add pipe link for display entity arch/arm/boot/dts/rtsm_ve-motherboard.dtsi | 46 +++ arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts |4 + drivers/gpu/drm/pl111/pl111_drm.h | 23 +- drivers/gpu/drm/pl111/pl111_drm_device.c | 374 ++-- drivers/video/vexpress-dvi.c | 94 +- 5 files changed, 503 insertions(+), 38 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC v3 1/3] Add display entities and pipe link for pl111
---
drivers/gpu/drm/pl111/pl111_drm.h| 23 +-
drivers/gpu/drm/pl111/pl111_drm_device.c | 374 --
2 files changed, 370 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index faf88cb..f81f79e 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -19,6 +19,9 @@
#ifndef _PL111_DRM_H_
#define _PL111_DRM_H_
+#include
+#include
+
/* Defines for drm_mode_create_dumb flags settings */
#define PL111_BO_SCANOUT 0x0001 /* scanout compatible buffer requested */
@@ -149,13 +152,17 @@ struct pl111_drm_crtc {
struct drm_framebuffer *fb);
};
+struct pl111_drm_encoder {
+ struct drm_encoder encoder;
+ unsigned int port;
+};
+
struct pl111_drm_connector {
struct drm_connector connector;
+ struct pl111_drm_encoder *encoder;
+ struct media_pad *pad;
};
-struct pl111_drm_encoder {
- struct drm_encoder encoder;
-};
struct pl111_drm_dev_private {
struct pl111_drm_crtc *pl111_crtc;
@@ -186,6 +193,16 @@ struct pl111_drm_dev_private {
/* Cache for flip resources used to avoid kmalloc on each page flip */
struct kmem_cache *page_flip_slab;
+
+ struct drm_device *ddev;
+
+ /*
+*Display entities and notifier
+*/
+ struct media_device mdev;
+ struct display_entity entity;
+ struct display_entity_notifier notifier;
+
};
enum pl111_cursor_size {
diff --git a/drivers/gpu/drm/pl111/pl111_drm_device.c
b/drivers/gpu/drm/pl111/pl111_drm_device.c
index cf22ead..838506f 100644
--- a/drivers/gpu/drm/pl111/pl111_drm_device.c
+++ b/drivers/gpu/drm/pl111/pl111_drm_device.c
@@ -35,6 +35,25 @@
struct pl111_drm_dev_private priv;
+/*
-
+ * Display Entities
+ */
+static int pl111_entity_set_stream(struct display_entity *ent,
+ unsigned int port,
+ enum display_entity_stream_state state)
+{
+ pr_info("DRM %s\n", __func__);
+ return 0;
+}
+
+static const struct display_entity_video_ops pl111_entity_video_ops = {
+ .set_stream = pl111_entity_set_stream,
+};
+
+static const struct display_entity_ops pl111_entity_ops = {
+ .video = &pl111_entity_video_ops,
+};
+
#ifdef CONFIG_DMA_SHARED_BUFFER_USES_KDS
static void initial_kds_obtained(void *cb1, void *cb2)
{
@@ -94,13 +113,217 @@ struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = pl111_fb_create,
};
+struct pl111_drm_encoder *
+pl111_pad_encoder_create(struct pl111_drm_dev_private *priv,
+unsigned int port,
+struct media_pad *pad)
+{
+ struct pl111_drm_encoder *pl111_encoder;
+ struct device *dev = &priv->amba_dev->dev;
+ unsigned int encoder_type;
+ int ret;
+
+ pl111_encoder = devm_kzalloc(dev, sizeof(*pl111_encoder), GFP_KERNEL);
+ if (pl111_encoder == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ pl111_encoder->port = port;
+
+ /* Find the encoder type. */
+ if (pad) {
+ struct display_entity *entity = to_display_entity(pad->entity);
+ struct display_entity_interface_params params;
+
+ ret = display_entity_get_params(entity, pad->index, ¶ms);
+ if (ret < 0) {
+ pr_err("DRM %s: failed to retrieve display entity %s
parameters\n",
+ __func__,
+ entity->name);
+ return ERR_PTR(ret);
+ }
+
+ switch (params.type) {
+ case DISPLAY_ENTITY_INTERFACE_LVDS:
+ encoder_type = DRM_MODE_ENCODER_DAC;
+ break;
+ case DISPLAY_ENTITY_INTERFACE_VGA:
+ encoder_type = DRM_MODE_ENCODER_DAC;
+ break;
+ case DISPLAY_ENTITY_INTERFACE_DPI:
+ case DISPLAY_ENTITY_INTERFACE_DBI:
+ default:
+ encoder_type = DRM_MODE_ENCODER_NONE;
+ break;
+ }
+
+ } else {
+ /* No external encoder, use the internal encoder type. */
+ pr_err("DRM %s: No external encoder, use the internal encoder
type.\n",
+ __func__);
+ encoder_type = DRM_MODE_ENCODER_DAC;
+ }
+
+ pl111_encoder = pl111_encoder_create(priv->ddev, 1);
+
+ return pl111_encoder;
+}
+
+struct pl111_drm_connector *
+pl111_pad_connector_create(struct pl111_drm_dev_private *priv,
+ struct pl111_drm_encoder *pl111_encoder,
+ struct media_pad *pad)
[PATCH/RFC v3 2/3] Add display entity and set VGA output(site MB) as default
---
drivers/video/vexpress-dvi.c | 94 +-
1 file changed, 83 insertions(+), 11 deletions(-)
diff --git a/drivers/video/vexpress-dvi.c b/drivers/video/vexpress-dvi.c
index cbcb443..ca0e5bd 100644
--- a/drivers/video/vexpress-dvi.c
+++ b/drivers/video/vexpress-dvi.c
@@ -18,6 +18,12 @@
#include
#include
+#include
+#include
+
+struct _mux_fpga {
+struct display_entity entity;
+};
static struct vexpress_config_func *vexpress_dvimode_func;
@@ -146,6 +152,52 @@ static int vexpress_dvi_fb_event_notify(struct
notifier_block *self,
return NOTIFY_OK;
}
+static int mux_fpga_set_state(struct display_entity *entity,
+enum
display_entity_state state)
+{
+ struct media_pad *source;
+ source = media_entity_remote_pad(&entity->entity.pads[0]);
+ if (source == NULL)
+ return -EPIPE;
+
+ switch (state) {
+ case DISPLAY_ENTITY_STATE_OFF:
+ case DISPLAY_ENTITY_STATE_STANDBY:
+
display_entity_set_stream(to_display_entity(source->entity),
+
source->index,
+
DISPLAY_ENTITY_STREAM_STOPPED);
+ break;
+
+ case DISPLAY_ENTITY_STATE_ON:
+
display_entity_set_stream(to_display_entity(source->entity),
+
source->index,
+
DISPLAY_ENTITY_STREAM_CONTINUOUS);
+ break;
+ }
+
+ return 0;
+}
+
+static int mux_fpga_get_params(struct display_entity *entity, unsigned int
port,
+ struct
display_entity_interface_params *params)
+{
+ memset(params, 0, sizeof(*params));
+
+ /* default using VGA interface type */
+ params->type = DISPLAY_ENTITY_INTERFACE_VGA;
+
+ return 0;
+}
+
+static const struct display_entity_control_ops mux_fpga_control_ops = {
+ .set_state = mux_fpga_set_state,
+ .get_params = mux_fpga_get_params,
+};
+
+static const struct display_entity_ops mux_fpga_ops = {
+ .ctrl = &mux_fpga_control_ops,
+};
+
static struct notifier_block vexpress_dvi_fb_notifier = {
.notifier_call = vexpress_dvi_fb_event_notify,
};
@@ -170,7 +222,9 @@ static int vexpress_dvi_probe(struct platform_device *pdev)
enum vexpress_dvi_func func;
const struct of_device_id *match =
of_match_device(vexpress_dvi_of_match, &pdev->dev);
- u32 site;
+ struct _mux_fpga*mux_fpga = NULL;
+
+ int ret = 0;
if (match)
func = (enum vexpress_dvi_func)match->data;
@@ -182,18 +236,36 @@ static int vexpress_dvi_probe(struct platform_device
*pdev)
vexpress_muxfpga_func =
vexpress_config_func_get_by_dev(&pdev->dev);
device_create_file(&pdev->dev, &dev_attr_fb);
- /* hard-coded for test DRM on RTSM
- Set default site = 0
- */
- if (vexpress_dvi_fb < 0){
- /*default site = 0*/
- site = 0;
- vexpress_config_write(vexpress_muxfpga_func, 0, site);
- vexpress_dvi_fb = site;
- }
+
+ /*
+* default using VEXPRESS_SITE_MB
+*/
+ pr_info("Set Site MB as Default\n");
+ vexpress_config_write(vexpress_muxfpga_func, 0,
VEXPRESS_SITE_MB);
+ vexpress_dvi_fb = VEXPRESS_SITE_MB;
+
+ /* initialize display entity */
+ mux_fpga = devm_kzalloc(&pdev->dev, sizeof(*mux_fpga),
GFP_KERNEL);
+ if (mux_fpga == NULL)
+ return -ENOMEM;
+
+ mux_fpga->entity.dev = &pdev->dev;
+ mux_fpga->entity.ops = &mux_fpga_ops;
+ strlcpy(mux_fpga->entity.name, dev_name(&pdev->dev),
sizeof(mux_fpga->entity.name));
+
+ ret = display_entity_init(&mux_fpga->entity, 1, 1);
+ if (ret < 0)
+ return ret;
+
+ ret = display_entity_add(&mux_fpga->entity);
+ if (ret < 0)
+ return ret;
+
+ platform_set_drvdata(pdev, mux_fpga);
break;
case FUNC_DVIMODE:
vexpress_dvimode_func =
+
vexpress_config_fun
[PATCH/RFC v3 3/3] add pipe link for display entity
---
arch/arm/boot/dts/rtsm_ve-motherboard.dtsi | 46
arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts |4 +++
2 files changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
b/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
index 6d12566..b4e032a 100644
--- a/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
+++ b/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
@@ -166,6 +166,17 @@
mode = "VGA";
use_dma = <0>;
framebuffer = <0x1800 0x0018>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ clcd_out: endpoint {
+ };
+ };
+ };
};
};
@@ -214,6 +225,41 @@
muxfpga@0 {
compatible = "arm,vexpress-muxfpga";
arm,vexpress-sysreg,func = <7 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ muxfpga_in: endpoint {
+ remote-endpoint = <&clcd_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ muxfpga_out: endpoint {
+ remote-endpoint = <&con_vga_in>;
+ };
+ };
+
+ };
+ };
+
+ con-vga {
+ compatible = "con-vga";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ con_vga_in: endpoint {
+ remote-endpoint =
<&muxfpga_out>;
+ };
+ };
+ };
};
shutdown@0 {
diff --git a/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
b/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
index c59f4b5..45a07c5 100644
--- a/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
+++ b/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
@@ -230,4 +230,8 @@
};
};
+&clcd_out {
+ remote-endpoint = <&muxfpga_in>;
+};
+
/include/ "clcd-panels.dtsi"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp: add defines for downstream port types
Looks good. Reviewed-by: Todd Previte On Fri, Sep 27, 2013 at 4:48 AM, Jani Nikula wrote: > Detailed cap info at address 80h is not available with DPCD ver > 1.0. Whether such devices exist in the wild I don't know, but there > should be no harm done in having the defines for downstream port 0 in > address 05h. > > Signed-off-by: Jani Nikula > --- > include/drm/drm_dp_helper.h |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index ae8dbfb..83da4eb 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -77,10 +77,10 @@ > #define DP_DOWNSTREAMPORT_PRESENT 0x005 > # define DP_DWN_STRM_PORT_PRESENT (1 << 0) > # define DP_DWN_STRM_PORT_TYPE_MASK 0x06 > -/* 00b = DisplayPort */ > -/* 01b = Analog */ > -/* 10b = TMDS or HDMI */ > -/* 11b = Other */ > +# define DP_DWN_STRM_PORT_TYPE_DP (0 << 1) > +# define DP_DWN_STRM_PORT_TYPE_ANALOG (1 << 1) > +# define DP_DWN_STRM_PORT_TYPE_TMDS (2 << 1) > +# define DP_DWN_STRM_PORT_TYPE_OTHER(3 << 1) > # define DP_FORMAT_CONVERSION (1 << 3) > # define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) /* DPI */ > > -- > 1.7.9.5 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: A simple alternative to GEM
Hi Dmitry, I can't speak for the Intel hardware, but you have a very basic misunderstanding of how the AMD GPU MMU works. The MMU just hides the real address of the buffer, so that switching between different clients just becomes switching between different page tables. But the memory for backing the buffer must still be allocated mostly linearly. Memory that is meant to be scanned out must be allocated linear not matter what. Buffers that are used tilled have a very strict alignment restriction for their base address. This alignment restriction divides the memory into several segments and you must make sure that allocating each segment doesn't swizzles its physical memory address. Otherwise you would end up accessing the wrong bank/channel of VRAM which of course is very counter productive for fast memory access. Basically it gives you a whole bunch of new requirements for your memory allocation. A different story is backing buffers with anonymous system memory. I was told that Jerome just recently did a very interesting talk at XDC about it (didn't have time to look at it myself). Regards, Christian. Am 27.09.2013 20:47, schrieb dm.leontiev7: Hello I'm new in linux dri development, so please please forgive me if I dont understand something. I'm working on my opensource gpu project. I've already implemented software simulator, and implementation in verilog is 40% complete. Right now I've only 2 problems: LLVM needs to be patched and DRI. Thats why I wrote this letter: DRI is too complicated for me and I think DRI can be safely simplified, and new features will be easily implementable. In my opinion, DRI can be significantly simplified. Just get rid of "buffer" concept. I've read intel and amd docs. Modern GPUs have fully functional MMU on board. Radeons have multiple MMUs. Also GPUs have special registers which describe buffer types and buffer locations within gpu virtual address space. These registers are not related to memory protection. So, memory is protected by GPU's MMU and we can safely allow usermode app to aim texture resource register to ANY valid location in address space associated with app's GPU context. Also, as long as we control allocation of physical pages and page tables, we can allow usermode app to control it's GPU memory map. Implement the folllowing operations: create context, create memmap, alllocate physical pages from a specified pool, map the pages to a valid virtual address, release pages(with memmap invalidation), and execute any GPU command with a memmap-and there will be no need in GEM, TTM and other legacy. This approach is as simple(in lines of code) as a hammer. PBOs and VBOs can be transparently emulated in userspace library, so there will be no need to break api. Btw, this approach enables a very interesring optmization: tile-based page flipping. This feature will be especially useful for partial window updates and resizing of windows in wayland: an app can dynamically reallocate it's buffer and there will be no need for full redraw and XMir driver hacks. Regards, Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65611] UVD accelerated decoding causes hangs (ARUBA - HD 7540D)
https://bugs.freedesktop.org/show_bug.cgi?id=65611 --- Comment #2 from Pierre Ossman --- (In reply to bug 65611 comment #1) > Well known problem, only VC-1 advanced profile (as found on Blueray disks) > is supported by the hardware. If that is the case, wouldn't it be an obvious first fix to remove simple and main from the driver's list of supported codecs? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Code stereo layouts as an enum in the mode structure
On Fri, Sep 27, 2013 at 06:36:05PM +0300, Ville Syrjälä wrote: > On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote: > > Daniel noticed that it wasn't very smart to keep using one bit per stereo > > layout now that we don't have to or them. It's a nice final touch to the new > > stereo mode API extension that we should fix before committing to it. > > Assuming you still trust me even though I didn't see this possibility > during my review of the original series :) > > For the series: > Reviewed-by: Ville Syrjälä Merged to dinq, thansk for patches&review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()
The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()". Signed-off-by: Dan Carpenter Acked-by: Maarten Lankhorst --- Somehow this wasn't applied when I sent it earlier. diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index c95decf..e11f8e4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -86,7 +86,7 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head) struct nouveau_drm *drm = nouveau_drm(dev); struct nouveau_disp *pdisp = nouveau_disp(drm->device); - if (WARN_ON_ONCE(head > ARRAY_SIZE(drm->vblank))) + if (WARN_ON_ONCE(head >= ARRAY_SIZE(drm->vblank))) return -EIO; WARN_ON_ONCE(drm->vblank[head].func); drm->vblank[head].func = nouveau_drm_vblank_handler; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch -next] drm/radeon/dpm/btc: off by one in btc_set_mc_special_registers()
It should be ">=" instead of ">" here. The table->mc_reg_address[] array has SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE (16) elements. Signed-off-by: Dan Carpenter --- Resend. diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c index bab0185..55491e7 100644 --- a/drivers/gpu/drm/radeon/btc_dpm.c +++ b/drivers/gpu/drm/radeon/btc_dpm.c @@ -1913,7 +1913,7 @@ static int btc_set_mc_special_registers(struct radeon_device *rdev, } j++; - if (j > SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE) + if (j >= SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE) return -EINVAL; tmp = RREG32(MC_PMG_CMD_MRS); @@ -1928,7 +1928,7 @@ static int btc_set_mc_special_registers(struct radeon_device *rdev, } j++; - if (j > SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE) + if (j >= SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE) return -EINVAL; break; case MC_SEQ_RESERVE_M >> 2: @@ -1942,7 +1942,7 @@ static int btc_set_mc_special_registers(struct radeon_device *rdev, } j++; - if (j > SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE) + if (j >= SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE) return -EINVAL; break; default: ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: A simple alternative to GEM
On Fri, Sep 27, 2013 at 3:08 PM, Christian König wrote: > > A different story is backing buffers with anonymous system memory. I was > told that Jerome just recently did a very interesting talk at XDC about it > (didn't have time to look at it myself). note that this requires a gpu which can page fault (and more importantly, resume after cpu intervenes on page fault).. which I think means modern(ish) radeon or nv.. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()
On Sat, Sep 28, 2013 at 6:17 AM, Dan Carpenter wrote: > The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()". > > Signed-off-by: Dan Carpenter > Acked-by: Maarten Lankhorst > --- > Somehow this wasn't applied when I sent it earlier. Sorry about this slipping through the cracks. It's in my tree now, so it'll make it to Dave at some point. Thanks, Ben. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c > b/drivers/gpu/drm/nouveau/nouveau_drm.c > index c95decf..e11f8e4 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -86,7 +86,7 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head) > struct nouveau_drm *drm = nouveau_drm(dev); > struct nouveau_disp *pdisp = nouveau_disp(drm->device); > > - if (WARN_ON_ONCE(head > ARRAY_SIZE(drm->vblank))) > + if (WARN_ON_ONCE(head >= ARRAY_SIZE(drm->vblank))) > return -EIO; > WARN_ON_ONCE(drm->vblank[head].func); > drm->vblank[head].func = nouveau_drm_vblank_handler; > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.11-rc4] [HD2400] - radeon.dpm
On Fri, Sep 27, 2013 at 1:21 PM, * SAMÍ * wrote: > Hi Alex, > > > could you just point me to the right location in the driver code to play > with? > I am less afraid to play with the driver than to flash my vbios... > Even though, I promise I won't bother you or complain if I break something > :-) rv6xx_parse_pplib_clock_info() in rv6xx_dpm.c is what parses the performance levels for a power state. rv6xx_parse_power_table() in rv6xx_dpm.c is what parses the overall power tables. Alex > > NB: Daniel, although I won't modify my vbios, I still like your solution: it > reminds me of good old time where you just had to edit your game files with > an hex editor to cheat... > > > Regards > Sam > > On 09/26/2013 08:19 PM, Alex Deucher wrote: >> >> On Thu, Sep 26, 2013 at 1:49 PM, wrote: >>> >>> Hi >>> As I suspected, on your system all the performance levels are the same: >>> >>> (...) [8.961704]power level 0sclk: 45000 mclk: 5 vddc: 950 [8.961706]power level 1sclk: 45000 mclk: 5 vddc: 950 [8.961708]power level 2sclk: 45000 mclk: 5 vddc: 950 >>> >>> (...) So there is no dynamic switching supported on your system. >>> >>> I also had this problem and manage to "fix" it (on a HD2600) :) >>> >>> >>> >>> Please be warnned that this is dangerous, requires editing the >>> bios and >>> may brick your card. Also, will not work on recent cards (but a HD2400 >>> should be ok). >>> Also, this is a hack and no one will support you if things go wrong! >>> >>> >>> You need a windows machine, for some steps, but other can use a >>> linux >>> equivalent... but editing the GPU bios i know no alternative to using the >>> windows program. I also don't know is there is any way in linux to load a >>> GPU >>> bios (and avoid the flashing)... we have the firmware, but i think that >>> the >>> firmware is just a subset of the bios. >>> >>> >>> So here is the "HOWTO": >>> >>> Make a usb pendrive bootable to DOS: >>> >>> Get this files: >>> http://files.extremeoverclocking.com/file.php?f=196 >>> >>> http://pt.kioskea.net/download/baixaki-433-hp-usb-disk-storage-format-tool >>> >>> >>> Unzip the windows98 DOS support to a directory and run the HP >>> usb storage >>> app and format the pendrive. Chek the flag "Create a DOS startup disk" >>> and choose >>> the extracted windows98 files. >>> >>> After formating, download and extract the ATI flash to the pen: >>> >>> http://www.techpowerup.com/downloads/1731/ATIFlash_3.79.html >>> >>> Now lets edit the bios. Ddownload this two apps: >>> >>> http://www.techpowerup.com/gpuz/ -> Dump the GPU Bios >>> http://www.techpowerup.com/rbe/ -> ATI/AMD Bios editor >>> >>> use the gpu-z to dump the current bios, backup it up on a >>> pendrive, to >>> revert to the original bios if needed. >>> >>> use the rbe to edit the power levels. be conservative, DO NOT >>> TOUCH the >>> boot power profiles (this way you can always boot the machine), avoid >>> changing >>> the voltage, as it's more dangerous (but it can also save more power). >>> >>> Edit the lower leves to reduce the GPU frequencies and keep the >>> level >>> 2 high. please note that too low or too high frequencies may cause the >>> card >>> to be unstable. DRAM frequencies usually save little power, but may help >>> reducing >>> the heat. For evey change, test it and check if the card is stable, the >>> picture >>> is not corrupted in different resolutions and loads. Again, if something >>> goes >>> wrong, power off the machine and startup again, the boot profile should >>> be the >>> one that always work (don't forget to have a boot entry in grub that >>> disables >>> the dynamic powermanagement, to avoid jumping to a unstable profile). >>> >>> After doing the changes, save the bios and save it to the >>> pendrive. >>> >>> Now shutdown the machine, make sure you have the full charge and >>> have >>> the power connected. If power faills during the flashing of the bios, you >>> may >>> brick the card/laptop. >>> >>> Startup the computer with the pendriver, enter the DOS and run >>> the >>> flash command: >>> >>> atiflash -p 0 .rom >>> >>> where the .rom is the new "tuned" bios. After some seconds >>> and >>> the command line returned, you can reboot and test it. If something >>> fails, >>> flash back the original bios. >>> >>> Test the card, increase the load, let screen/card enter the >>> sleep >>> mode (screensaver/suspend), change resolutions and look at the >>> temperature. >>> If all OK, you can try to tune even more. >>> >>> So this is a possible (and dangerous) solution for this problem, >>> but >>> may help some people. >> >> You can edit the power states in the driver as well if you don't want >> to flash your vbios. However the same cave
Re: [PATCH] drm/dp: constify DP DPCD helpers
On Fri, Sep 27, 2013 at 12:01 PM, Jani Nikula wrote:
> None of the DP DPCD helpers need to modify the DPCD.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_dp_helper.c | 16
> include/drm/drm_dp_helper.h | 16
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 89e1966..9e978aa 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -228,12 +228,12 @@ i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
> EXPORT_SYMBOL(i2c_dp_aux_add_bus);
>
> /* Helpers for DP link training */
> -static u8 dp_link_status(u8 link_status[DP_LINK_STATUS_SIZE], int r)
> +static u8 dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
> {
> return link_status[r - DP_LANE0_1_STATUS];
> }
>
> -static u8 dp_get_lane_status(u8 link_status[DP_LINK_STATUS_SIZE],
> +static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane)
> {
> int i = DP_LANE0_1_STATUS + (lane >> 1);
> @@ -242,7 +242,7 @@ static u8 dp_get_lane_status(u8
> link_status[DP_LINK_STATUS_SIZE],
> return (l >> s) & 0xf;
> }
>
> -bool drm_dp_channel_eq_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count)
> {
> u8 lane_align;
> @@ -262,7 +262,7 @@ bool drm_dp_channel_eq_ok(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_channel_eq_ok);
>
> -bool drm_dp_clock_recovery_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count)
> {
> int lane;
> @@ -277,7 +277,7 @@ bool drm_dp_clock_recovery_ok(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_clock_recovery_ok);
>
> -u8 drm_dp_get_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_voltage(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane)
> {
> int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
> @@ -290,7 +290,7 @@ u8 drm_dp_get_adjust_request_voltage(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_voltage);
>
> -u8 drm_dp_get_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane)
> {
> int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
> @@ -303,7 +303,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> -void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
> +void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> udelay(100);
> else
> @@ -311,7 +311,7 @@ void drm_dp_link_train_clock_recovery_delay(u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> -void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
> +void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> udelay(400);
> else
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index ae8dbfb..88661ad 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -333,20 +333,20 @@ i2c_dp_aux_add_bus(struct i2c_adapter *adapter);
>
>
> #define DP_LINK_STATUS_SIZE 6
> -bool drm_dp_channel_eq_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count);
> -bool drm_dp_clock_recovery_ok(u8 link_status[DP_LINK_STATUS_SIZE],
> +bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count);
> -u8 drm_dp_get_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_voltage(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane);
> -u8 drm_dp_get_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> +u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane);
>
> #define DP_RECEIVER_CAP_SIZE 0xf
> #define EDP_PSR_RECEIVER_CAP_SIZE 2
>
> -void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
> -void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
> +void drm_dp_link_train_clock_recovery_delay(const
Re: [PATCH 1/2] drm/dp: add defines for downstream port types
On Fri, Sep 27, 2013 at 7:48 AM, Jani Nikula wrote: > Detailed cap info at address 80h is not available with DPCD ver > 1.0. Whether such devices exist in the wild I don't know, but there > should be no harm done in having the defines for downstream port 0 in > address 05h. > > Signed-off-by: Jani Nikula Reviewed-by: Alex Deucher > --- > include/drm/drm_dp_helper.h |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index ae8dbfb..83da4eb 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -77,10 +77,10 @@ > #define DP_DOWNSTREAMPORT_PRESENT 0x005 > # define DP_DWN_STRM_PORT_PRESENT (1 << 0) > # define DP_DWN_STRM_PORT_TYPE_MASK 0x06 > -/* 00b = DisplayPort */ > -/* 01b = Analog */ > -/* 10b = TMDS or HDMI */ > -/* 11b = Other */ > +# define DP_DWN_STRM_PORT_TYPE_DP (0 << 1) > +# define DP_DWN_STRM_PORT_TYPE_ANALOG (1 << 1) > +# define DP_DWN_STRM_PORT_TYPE_TMDS (2 << 1) > +# define DP_DWN_STRM_PORT_TYPE_OTHER(3 << 1) > # define DP_FORMAT_CONVERSION (1 << 3) > # define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) /* DPI */ > > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65611] UVD accelerated decoding causes hangs (ARUBA - HD 7540D)
https://bugs.freedesktop.org/show_bug.cgi?id=65611 --- Comment #3 from Pierre Ossman --- I tried this patch: diff -up ./src/gallium/drivers/radeon/radeon_uvd.c.vc1 ./src/gallium/drivers/radeon/radeon_uvd.c --- ./src/gallium/drivers/radeon/radeon_uvd.c.vc12013-09-27 23:10:44.292867514 +0200 +++ ./src/gallium/drivers/radeon/radeon_uvd.c2013-09-27 23:14:45.384398128 +0200 @@ -1094,8 +1094,12 @@ int ruvd_get_video_param(struct pipe_scr case PIPE_VIDEO_CODEC_MPEG12: case PIPE_VIDEO_CODEC_MPEG4: case PIPE_VIDEO_CODEC_MPEG4_AVC: -case PIPE_VIDEO_CODEC_VC1: return true; +case PIPE_VIDEO_CODEC_VC1: +/* Only advanced is supported */ +if (profile == PIPE_VIDEO_PROFILE_VC1_ADVANCED) +return true; +/* fall through... */ default: return false; } Yet my WMV3 file is still going through VDPAU. So either my file is advanced profile and that is broken, or xbmc not fully respecting the list? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #31 from Brian Hall --- Since we have a patch that fixes the problem, can we get it submitted for 3.12, or at least 3.12.1? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #32 from Alex Deucher --- It's already upstream: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 Alex Deucher changed: What|Removed |Added Attachment #86598|0 |1 is obsolete|| --- Comment #16 from Alex Deucher --- Created attachment 86739 --> https://bugs.freedesktop.org/attachment.cgi?id=86739&action=edit patch 1/3 I think this entire patch set should be applied. First patch switches to 64 bit math for the cts calcuation. Second patch patches the radeon acr tables based on the clock values generated by the drm code that generates the 1001 modes. Third patch enables hw generated cts and n values. If there are indeed problems with using the hw generated values, we can disable the 3rd patch on the problematic asics, and the other two patches should do the right thing. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #17 from Alex Deucher --- Created attachment 86740 --> https://bugs.freedesktop.org/attachment.cgi?id=86740&action=edit patch 2/3 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #18 from Alex Deucher --- Created attachment 86741 --> https://bugs.freedesktop.org/attachment.cgi?id=86741&action=edit patch 3/3 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocation
Return -ENOMEM if the allocation fails.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1688ff5..830f750 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2925,6 +2925,8 @@ int drm_edid_to_speaker_allocation(struct edid *edid, u8
**sadb)
/* Speaker Allocation Data Block */
if (dbl == 3) {
*sadb = kmalloc(dbl, GFP_KERNEL);
+ if (!*sadb)
+ return -ENOMEM;
memcpy(*sadb, &db[1], dbl);
count = dbl;
break;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62231] No HDMI audio (pass through) on ASUS F2A55-M (ATI Trinity Aruba GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=62231 Stuart Foster changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DOCUMENTED --- Comment #4 from Stuart Foster --- Removed radeon.audio=1 from boot file and rebuilt with latest Aruba/Tahiti firmware resulted in xrandr sucessfully enabling audio and the system appears stable (power managment also enabled). thanks. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #19 from Anssi Hannula ---
(In reply to comment #16)
> + u64 n, d;
> +
> + if (*CTS == 0) {
> + n = (u64)clock * N;
> + d = 128ULL * (u64)freq;
> + *CTS = div64_u64(n, d);
> + *CTS *= 1000ULL;
> + }
Hmm, I believe we should multiply before division, otherwise the result will
not be right... like this:
+if (*CTS == 0) {
+n = (u64)clock * N * 1000ULL;
+d = 128ULL * (u64)freq;
+*CTS = div64_u64(n, d);
+}
Also, maximum value for d is actually 128*48000, so no need for u64 for it, and
then one can use div_64u(u64,u32) for division. Similarly, CTS/N values are
just 20-bit so no need to u64 them (it might even be confusing), u64 for just
the "n" variable should be enough.
> Subject: [PATCH 3/3] drm/radeon: use hw generated CTS/N values for audio
Just checking: What N value does the Hw use in that mode? The ones written in
by the driver, some hardcoded N or does it select one on its own? Though it
doesn't really matter much (since any reasonable N should work as long as CTS
is correct), except that if it uses the driver-set value we better not remove
the write to the N register :)
(In reply to comment #15)
> Somewhat related, the calculation in r600_hdmi_calc_cts() is not very good
> as it loses a tonne of precision (roughly ten bits' worth). Given the range
> of the inputs, you might need to do the calculations in a 64-bit space.
I'm a bit interested if the calculated values "seem" to work if you only fix
the precisions there (Alex' patch1 plus my first tweak above), without adding
the correct values in the table?
If the actual freq is closer to 74176 instead of 74175.8, the calculated values
should actually be better than the table value (as you noticed, the table
values expect exact /1.001 rate), and it could be the calculation precision
issue (*1000 in the wrong place) then caused the audio issues as the CTS was
more wildly wrong...
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69897] New: OpenCL kernel fails to compile with R600 LLVM backend
https://bugs.freedesktop.org/show_bug.cgi?id=69897 Priority: medium Bug ID: 69897 Assignee: dri-devel@lists.freedesktop.org Summary: OpenCL kernel fails to compile with R600 LLVM backend Severity: normal Classification: Unclassified OS: All Reporter: g...@chown.ath.cx Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa Created attachment 86758 --> https://bugs.freedesktop.org/attachment.cgi?id=86758&action=edit Kernel source code with headers The attached kernel fails to compile with this error message: PRT: /home/greg/build/llvm/lib/Target/R600/AMDILCFGStructurizer.cpp:1115: int ::AMDGPUCFGStructurizer::mergeLoop(llvm::MachineLoop *): Assertion `ExitBlkSet.size() == 1' failed. Stack dump: 0.Running pass 'Function Pass Manager' on module 'radeon'. 1.Running pass 'AMD IL Control Flow Graph structurizer Pass' on function '@shadow_ao' -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69897] OpenCL kernel fails to compile with R600 LLVM backend
https://bugs.freedesktop.org/show_bug.cgi?id=69897 --- Comment #1 from Tom Stellard --- Created attachment 86759 --> https://bugs.freedesktop.org/attachment.cgi?id=86759&action=edit Possible Fix Does this patch help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69897] OpenCL kernel fails to compile with R600 LLVM backend
https://bugs.freedesktop.org/show_bug.cgi?id=69897 --- Comment #2 from Grigori Goronzy --- It seems to fix the initial problem, but now I'm getting something else: PRT: /home/greg/build/llvm/include/llvm/Support/Casting.h:239: typename cast_retty::ret_type llvm::cast(Y *) [X = llvm::BranchInst, Y = llvm::TerminatorInst]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Stack dump: 0.Running pass 'Function Pass Manager' on module 'radeon'. 1.Running pass 'Region Pass Manager' on function '@shadow_ao' 2.Running pass 'Structurize control flow' on basic block '%if.end100' -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69897] OpenCL kernel fails to compile with R600 LLVM backend
https://bugs.freedesktop.org/show_bug.cgi?id=69897 --- Comment #3 from Tom Stellard --- Created attachment 86760 --> https://bugs.freedesktop.org/attachment.cgi?id=86760&action=edit Possible Fix Part 2 Try applying this patch along with the first fix. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69897] OpenCL kernel fails to compile with R600 LLVM backend
https://bugs.freedesktop.org/show_bug.cgi?id=69897 --- Comment #4 from Grigori Goronzy --- Still fails, but it's getting even further: LLVM ERROR: Not supported instr:> -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #19 from Bruno Wolff III --- I tested the referenced patch on top of vanilla 3.12-rc2 and things work correctly. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69897] OpenCL kernel fails to compile with R600 LLVM backend
https://bugs.freedesktop.org/show_bug.cgi?id=69897 --- Comment #5 from Tom Stellard --- Created attachment 86761 --> https://bugs.freedesktop.org/attachment.cgi?id=86761&action=edit Fix part 3 Can you try this patch with the other two? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 Tom Stellard changed: What|Removed |Added Attachment #86004|0 |1 is obsolete|| --- Comment #53 from Tom Stellard --- Created attachment 86762 --> https://bugs.freedesktop.org/attachment.cgi?id=86762&action=edit Possible Fix #3 Can you try this patch? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #20 from Dieter Nützel --- (In reply to Bjorn Helgaas from comment #17) > Bruno or Dieter, can you try Jean's patch from the email mentioned in > comment #16? If v3.12-rc2 + Jean's patch solves the problem, it might save > you a lot of bisect time. 3.12-rc2 + Jean's patch Running with radeon.agpmode=-1. Direct way to 3.12-rc3, please ;-) Tested-by die...@nuetzel-hh.de -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64225] bfgminer --scyte generates Segmentation Fault on Northern Island
https://bugs.freedesktop.org/show_bug.cgi?id=64225 --- Comment #6 from Tom Stellard --- Created attachment 86763 --> https://bugs.freedesktop.org/attachment.cgi?id=86763&action=edit Possible Fix Can you try this patch? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #54 from darkbasic --- No sorry but it doesn't help. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #55 from Tom Stellard --- (In reply to comment #54) > No sorry but it doesn't help. Sorry, I should have mentioned this will only help with pre-SI GPUs. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
