[Bug 37603] r600g with LLVM enabled makes Heroes of Newerth game unplayable
https://bugs.freedesktop.org/show_bug.cgi?id=37603 --- Comment #2 from Pavel Ondračka 2011-05-25 23:13:46 PDT --- This may be similar problem to bug 30901, try to remove libstdc++ bundled with HoN. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37603] r600g with LLVM enabled makes Heroes of Newerth game unplayable
https://bugs.freedesktop.org/show_bug.cgi?id=37603 --- Comment #2 from Pavel Ondra?ka 2011-05-25 23:13:46 PDT --- This may be similar problem to bug 30901, try to remove libstdc++ bundled with HoN. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37603] r600g with LLVM enabled makes Heroes of Newerth game unplayable
https://bugs.freedesktop.org/show_bug.cgi?id=37603 --- Comment #1 from Rene Peinthor 2011-05-25 22:50:13 PDT --- Same problem here on HD4850 and 5770, will try to disable llvm when I'm back home. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37603] r600g with LLVM enabled makes Heroes of Newerth game unplayable
https://bugs.freedesktop.org/show_bug.cgi?id=37603 --- Comment #1 from Rene Peinthor 2011-05-25 22:50:13 PDT --- Same problem here on HD4850 and 5770, will try to disable llvm when I'm back home. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PULL] drm-intel-next
This fixes a simple typo in the Ivybridge code -- an extra semicolon. The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0: drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge (2011-05-18 15:14:39 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Dan Carpenter (1): drm/i915: fix if statement in ivybridge irq handler drivers/gpu/drm/i915/i915_irq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/a6753734/attachment.pgp>
Re: [PULL] drm-intel-next
This fixes a simple typo in the Ivybridge code -- an extra semicolon. The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0: drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge (2011-05-18 15:14:39 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Dan Carpenter (1): drm/i915: fix if statement in ivybridge irq handler drivers/gpu/drm/i915/i915_irq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- keith.pack...@intel.com pgpeJ0KL6QOb1.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix thermal sensor reading on juniper
Uses a different method than other evergreen asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 48 ---
drivers/gpu/drm/radeon/evergreend.h |8 +-
2 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 7c37638..5f0c345 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -88,21 +88,39 @@ u32 evergreen_page_flip(struct radeon_device *rdev, int
crtc_id, u64 crtc_base)
/* get temperature in millidegrees */
int evergreen_get_temp(struct radeon_device *rdev)
{
- u32 temp = (RREG32(CG_MULT_THERMAL_STATUS) & ASIC_T_MASK) >>
- ASIC_T_SHIFT;
- u32 actual_temp = 0;
-
- if (temp & 0x400)
- actual_temp = -256;
- else if (temp & 0x200)
- actual_temp = 255;
- else if (temp & 0x100) {
- actual_temp = temp & 0x1ff;
- actual_temp |= ~0x1ff;
- } else
- actual_temp = temp & 0xff;
+ u32 temp, toffset, actual_temp = 0;
+
+ if (rdev->family == CHIP_JUNIPER) {
+ toffset = (RREG32(CG_THERMAL_CTRL) & TOFFSET_MASK) >>
+ TOFFSET_SHIFT;
+ temp = (RREG32(CG_TS0_STATUS) & TS0_ADC_DOUT_MASK) >>
+ TS0_ADC_DOUT_SHIFT;
+
+ if (toffset & 0x100)
+ actual_temp = temp / 2 - (0x200 - toffset);
+ else
+ actual_temp = temp / 2 + toffset;
+
+ actual_temp = actual_temp * 1000;
+
+ } else {
+ temp = (RREG32(CG_MULT_THERMAL_STATUS) & ASIC_T_MASK) >>
+ ASIC_T_SHIFT;
+
+ if (temp & 0x400)
+ actual_temp = -256;
+ else if (temp & 0x200)
+ actual_temp = 255;
+ else if (temp & 0x100) {
+ actual_temp = temp & 0x1ff;
+ actual_temp |= ~0x1ff;
+ } else
+ actual_temp = temp & 0xff;
+
+ actual_temp = (actual_temp * 1000) / 2;
+ }
- return (actual_temp * 1000) / 2;
+ return actual_temp;
}
int sumo_get_temp(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index f37e91e..1636e34 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -168,10 +168,16 @@
#defineSE_DB_BUSY (1 <<
30)
#defineSE_CB_BUSY (1 <<
31)
/* evergreen */
+#defineCG_THERMAL_CTRL 0x72c
+#defineTOFFSET_MASK0x3FE0
+#defineTOFFSET_SHIFT 5
#defineCG_MULT_THERMAL_STATUS 0x740
#defineASIC_T(x) ((x) << 16)
-#defineASIC_T_MASK 0x7FF
+#defineASIC_T_MASK 0x07FF
#defineASIC_T_SHIFT16
+#defineCG_TS0_STATUS 0x760
+#defineTS0_ADC_DOUT_MASK 0x03FF
+#defineTS0_ADC_DOUT_SHIFT 0
/* APU */
#defineCG_THERMAL_STATUS 0x678
--
1.7.1.1
BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()
On Wed, May 25, 2011 at 11:43:00AM -0400, Alex Deucher wrote: > On Wed, May 25, 2011 at 8:29 AM, Frank van Maarseveen > wrote: > > Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes > > immediately upon start. > > > > Any reason you are not using kms? The help on that kernel configuration option for Radeon and Nouveau looked scary: it warned about pain for old userland and I'd prefer to use the same kernel for older distro (Debian lenny) too, if possible. I'll try it anyway. FC14 and FC15 live images run fine on this system with compiz enabled. > > Alex > [...] -- Frank
[Bug 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)
https://bugs.freedesktop.org/show_bug.cgi?id=36542 --- Comment #5 from Erdem U. Altinyurt 2011-05-25 18:32:15 PDT --- Don't know "nexuiz's timedemo demos/demo1.dem" but my barts (HD6850) hanging up while I am in desktop (with compiz) too. So I don't believe if this is related with just TURKS but BARTS... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)
https://bugs.freedesktop.org/show_bug.cgi?id=36542 --- Comment #5 from Erdem U. Altinyurt 2011-05-25 18:32:15 PDT --- Don't know "nexuiz's timedemo demos/demo1.dem" but my barts (HD6850) hanging up while I am in desktop (with compiz) too. So I don't believe if this is related with just TURKS but BARTS... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)
https://bugs.freedesktop.org/show_bug.cgi?id=36542 --- Comment #4 from Dave Airlie 2011-05-25 18:24:02 PDT --- are you running nexuiz in any particular way? I'm wondering if this is TURKS specific, my BARTS can run gnome-shell + nexuiz timedemo demos/demo1.dem in full here with no hangs. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)
https://bugs.freedesktop.org/show_bug.cgi?id=36542 --- Comment #4 from Dave Airlie 2011-05-25 18:24:02 PDT --- are you running nexuiz in any particular way? I'm wondering if this is TURKS specific, my BARTS can run gnome-shell + nexuiz timedemo demos/demo1.dem in full here with no hangs. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: add missing case for cayman thermal sensor
The rest of the code is already in place.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 86eda1e..aaa19dc 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -487,6 +487,7 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_RV6XX:
case THERMAL_TYPE_RV770:
case THERMAL_TYPE_EVERGREEN:
+ case THERMAL_TYPE_NI:
case THERMAL_TYPE_SUMO:
rdev->pm.int_hwmon_dev = hwmon_device_register(rdev->dev);
if (IS_ERR(rdev->pm.int_hwmon_dev)) {
--
1.7.1.1
[PATCH 2/2] drm/radeon/kms: add blit support for cayman
>@@ -582,11 +588,17 @@ int evergreen_blit_init(struct radeon_device *rdev) > obj_size = ALIGN(obj_size, 256); > > rdev->r600_blit.vs_offset = obj_size; >- obj_size += evergreen_vs_size * 4; >+ if (rdev->family < CHIP_CAYMAN) >+ obj_size += evergreen_vs_size * 4; >+ else >+ obj_size += cayman_vs_size * 4; > obj_size = ALIGN(obj_size, 256); > > rdev->r600_blit.ps_offset = obj_size; >- obj_size += evergreen_ps_size * 4; >+ if (rdev->family < CHIP_CAYMAN) >+ obj_size += evergreen_ps_size * 4; >+ else >+ obj_size += evergreen_ps_size * 4; > obj_size = ALIGN(obj_size, 256); > > r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, > RADEON_GEM_DOMAIN_VRAM, Hi, looks like a c&p error using evergreen_ps_size also for cayman
Re: BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()
>> Any reason you are not using kms? > > Any reason you are not respecting the netiquette ? > Quoting nearly 1000 lines unrelated to your one line answer is quite rude :-( Yeah we knows that only acceptable if you put, Pardon my ignorance I sent this from my phone at the top ;-) Sorry couldn't resist. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()
On 25 May 2011 17:43, Alex Deucher wrote: >> Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes >> immediately upon start. > > Any reason you are not using kms? Any reason you are not respecting the netiquette ? Quoting nearly 1000 lines unrelated to your one line answer is quite rude :-( ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
On 05/23/2011 11:52 PM, Alexey Zaytsev wrote: > On Tue, May 24, 2011 at 00:33, Linus Torvalds > wrote: >> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >>> >>> I really hope there's also a voice that tells you to wait until .42 before >>> cutting 3.0.0! :-) >> >> So I'm toying with 3.0 (and in that case, it really would be "3.0", >> not "3.0.0" - the stable team would get the third digit rather than >> the fourth one. >> >> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a >> fairly nice round number. >> >> There's also the timing issue - since we no longer do version numbers >> based on features, but based on time, just saying "we're about to >> start the third decade" works as well as any other excuse. >> >> But we'll see. > > Maybe, 2011.x, or 11.x, x increasing for every merge window started this year? > This would better reflect the steady nature of the releases, but would > certainly break a lot of scripts. ;) My $0.017 on this. Clearly current process is time based. People have said. * Keep Three digit numbers to retain script compatibility * Make it clear from the version when it was released. * Linus said 3 as for 3rd decade * Nice single increment number progression * Please make it look like a nice version number sys-admins will feel at home with So if you combine all the above: D. Y. N D - Is the decade since birth (1991 not 1990) Y - is the year in the decade so you have 3.1.x, 3.2.x, .. 3.10.x, 4.1.X and so on Nice incremental number. N - The Linus release of this Year. So this 3rd one goes up to 4 most probably. Linus always likes, and feels very poetic about the Christmas version release. He hates it when once it slipped into the next year. So now he gets to increment the second digit as a bonus. The 2nd digit gets to start on a *one*, never zero and goes up to *10*, to symbolize the 1991 birth. And we never have .zero quality, right? The first Digit gets incremented on decade from 1991 so on 2011 and not 2010 So here you have it, who said we need to compromise? Free life Boaz
(Short?) merge window reminder
On Tue, 24 May 2011, Zimny Lech wrote: > Hi, > > 2011/5/24 Lisa Milne : >>> So I'm toying with 3.0 (and in that case, it really would be "3.0", >>> not "3.0.0" - the stable team would get the third digit rather than >>> the fourth one. >> >> How about stardates? > > This is a wonderful idea! :) I'd rather go for a gardensheduler, which can tell me the optimal color for any given moment *and* do the paint job. If it eventually ends this discussion, it could be renamed "completely fair gardensheduler". > >> That'd make a release made now 64860.8 >> >> I really should sleep more... Or drink less coffee ... ;) -- Regards, Martin
[PATCH] drm/radeon/kms: add blit support for cayman (v2)
Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.
v2: fix copy paste typo
Reported-by: Nils Wallm?nius
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cayman_blit_shaders.c | 326 -
drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 505 ++
drivers/gpu/drm/radeon/ni.c | 13 +-
drivers/gpu/drm/radeon/radeon_asic.c |6 +-
5 files changed, 598 insertions(+), 255 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@
const u32 cayman_default_state[] =
{
- /* XXX fill in additional blit state */
+ 0xc0066900,
+ 0x,
+ 0x0060, /* DB_RENDER_CONTROL */
+ 0x, /* DB_COUNT_CONTROL */
+ 0x, /* DB_DEPTH_VIEW */
+ 0x002a, /* DB_RENDER_OVERRIDE */
+ 0x, /* DB_RENDER_OVERRIDE2 */
+ 0x, /* DB_HTILE_DATA_BASE */
0xc0026900,
- 0x0316,
- 0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
- 0x0010, /* */
+ 0x000a,
+ 0x, /* DB_STENCIL_CLEAR */
+ 0x, /* DB_DEPTH_CLEAR */
+
+ 0xc0036900,
+ 0x000f,
+ 0x, /* DB_DEPTH_INFO */
+ 0x, /* DB_Z_INFO */
+ 0x, /* DB_STENCIL_INFO */
+
+ 0xc0016900,
+ 0x0080,
+ 0x, /* PA_SC_WINDOW_OFFSET */
+
+ 0xc00d6900,
+ 0x0083,
+ 0x, /* PA_SC_CLIPRECT_RULE */
+ 0x, /* PA_SC_CLIPRECT_0_TL */
+ 0x20002000, /* PA_SC_CLIPRECT_0_BR */
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x, /* PA_SC_EDGERULE */
+ 0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+ 0x000f, /* CB_TARGET_MASK */
+ 0x000f, /* CB_SHADER_MASK */
+
+ 0xc0226900,
+ 0x0094,
+ 0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+ 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x, /* PA_SC_VPORT_ZMIN_0 */
+ 0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+ 0xc0016900,
+ 0x00d4,
+ 0x, /* SX_MISC */
0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+ 0xc0096900,
+ 0x0100,
+ 0x00ff, /* VGT_MAX_VTX_INDX */
+ 0x, /* VGT_MIN_VTX_INDX */
+ 0x, /* VGT_INDX_OFFSET */
+ 0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+ 0x, /* SX_ALPHA_TEST_CONTROL */
+ 0x, /* CB_BLEND_RED */
+ 0x, /* CB_BLEND_GREEN */
+ 0x, /* CB_BLEND_BLUE */
+ 0x, /* CB_BLEND_ALPHA */
+
+ 0xc0016900,
+ 0x0187,
+ 0x0100, /* SPI_VS_OUT_ID_0 */
+
+ 0xc0026900,
+ 0x0191,
+ 0x0100, /* SPI_PS_INPUT_CNTL_0 */
+ 0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+ 0xc0016900,
+ 0x01b1,
+ 0x, /* SPI_VS_OUT_CONFIG */
+
+ 0xc0106900,
+ 0x01b3,
+ 0x2001, /* SPI_PS_IN_CONTROL_0 */
+ 0x, /* SPI_PS_IN_CONTROL_1 */
+ 0x, /* SPI_INTERP_CONTROL_0 */
+ 0x, /* SPI_INPUT_Z */
+ 0x, /* SPI_FOG_CNTL */
+ 0x0010, /* SPI_BARYC_CNTL */
+ 0x, /* SPI_PS_IN_CONTROL_2 */
+ 0x, /* SPI_COMPUTE_INPUT_CNTL */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_X */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+ 0x, /* SPI_GPR_MGMT */
+ 0x, /* SPI_LDS_MGMT */
+ 0x, /* SPI_STACK_MGMT */
+ 0x, /* SPI_WAVE_MGMT_1 */
+ 0x, /* SPI_WAVE_MGMT_2 */
+
+ 0xc0016900,
+ 0x01e0,
+ 0x, /* CB_BLEND0_CONTROL */
+
+ 0xc00e6900,
+ 0x0200,
+ 0x, /* DB_DEPTH_CONTROL */
+ 0x, /* DB_EQAA */
+ 0x00cc0010, /* CB_COLOR_CONTROL */
+ 0x0210, /* DB_SHADER_CONTROL */
+ 0x0001, /* PA_CL_C
[PATCH] drm/radeon/kms: fix thermal sensor reading on juniper
Uses a different method than other evergreen asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 48 ---
drivers/gpu/drm/radeon/evergreend.h |8 +-
2 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 7c37638..5f0c345 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -88,21 +88,39 @@ u32 evergreen_page_flip(struct radeon_device *rdev, int
crtc_id, u64 crtc_base)
/* get temperature in millidegrees */
int evergreen_get_temp(struct radeon_device *rdev)
{
- u32 temp = (RREG32(CG_MULT_THERMAL_STATUS) & ASIC_T_MASK) >>
- ASIC_T_SHIFT;
- u32 actual_temp = 0;
-
- if (temp & 0x400)
- actual_temp = -256;
- else if (temp & 0x200)
- actual_temp = 255;
- else if (temp & 0x100) {
- actual_temp = temp & 0x1ff;
- actual_temp |= ~0x1ff;
- } else
- actual_temp = temp & 0xff;
+ u32 temp, toffset, actual_temp = 0;
+
+ if (rdev->family == CHIP_JUNIPER) {
+ toffset = (RREG32(CG_THERMAL_CTRL) & TOFFSET_MASK) >>
+ TOFFSET_SHIFT;
+ temp = (RREG32(CG_TS0_STATUS) & TS0_ADC_DOUT_MASK) >>
+ TS0_ADC_DOUT_SHIFT;
+
+ if (toffset & 0x100)
+ actual_temp = temp / 2 - (0x200 - toffset);
+ else
+ actual_temp = temp / 2 + toffset;
+
+ actual_temp = actual_temp * 1000;
+
+ } else {
+ temp = (RREG32(CG_MULT_THERMAL_STATUS) & ASIC_T_MASK) >>
+ ASIC_T_SHIFT;
+
+ if (temp & 0x400)
+ actual_temp = -256;
+ else if (temp & 0x200)
+ actual_temp = 255;
+ else if (temp & 0x100) {
+ actual_temp = temp & 0x1ff;
+ actual_temp |= ~0x1ff;
+ } else
+ actual_temp = temp & 0xff;
+
+ actual_temp = (actual_temp * 1000) / 2;
+ }
- return (actual_temp * 1000) / 2;
+ return actual_temp;
}
int sumo_get_temp(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index f37e91e..1636e34 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -168,10 +168,16 @@
#defineSE_DB_BUSY (1 <<
30)
#defineSE_CB_BUSY (1 <<
31)
/* evergreen */
+#defineCG_THERMAL_CTRL 0x72c
+#defineTOFFSET_MASK0x3FE0
+#defineTOFFSET_SHIFT 5
#defineCG_MULT_THERMAL_STATUS 0x740
#defineASIC_T(x) ((x) << 16)
-#defineASIC_T_MASK 0x7FF
+#defineASIC_T_MASK 0x07FF
#defineASIC_T_SHIFT16
+#defineCG_TS0_STATUS 0x760
+#defineTS0_ADC_DOUT_MASK 0x03FF
+#defineTS0_ADC_DOUT_SHIFT 0
/* APU */
#defineCG_THERMAL_STATUS 0x678
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
On Wed, May 25, 2011 at 7:12 AM, Boaz Harrosh wrote: > So if you combine all the above: > > D. Y. N > D - Is the decade since birth (1991 not 1990) > Y - is the year in the decade so you have 3.1.x, 3.2.x, .. 3.10.x, 4.1.X and > so on > ? ?Nice incremental number. > N - The Linus release of this Year. So this 3rd one goes up to 4 most > probably. > > Linus always likes, and feels very poetic about the Christmas version release. > He hates it when once it slipped into the next year. So now he gets to > increment > the second digit as a bonus. > > The 2nd digit gets to start on a *one*, never zero and goes up to *10*, to > symbolize > the 1991 birth. And we never have .zero quality, right? > > The first Digit gets incremented on decade from 1991 so on 2011 and not 2010 This is clearly the best suggestion so far - small numbers, somewhat date related (but without stuffing a "2011." on the front). No ".0" releases, ever. But best of all it defines now when we will switch to 4.x.y and 5.x.y so we don't have to keep having this discussion whenever someone thinks that the numbers are getting "too big" (well perhaps when we get to the tenth decade or so :-) So the only thing left to argue is whether the upcoming release should be numbered "3.1.1" as the first release in the first year of the 3rd decade ... or whether we should count 2.6.37 .. 2.6.39 as the first three releases this year and thus we ought to start with "3.1.4" (so we start with "pi"!). Linus: If you go with this, you should let Boaz set the new "NAME" as a prize for such an inspired solution. -Tony
(Short?) merge window reminder
On Tue, 24 May 2011, Andy Lutomirski wrote: > Also, when someone in my lab installs here> on a box that's running software I wrote that needs to support > modern high-speed peripherals, then I can say "What? You seriously > expect this stuff to work on Linux 2007? Let's install a slightly less > stable distro from at least 2010." This sounds a lot less nerdy than > "What? You seriously expect this stuff to work on Linux 2.6.27? Let's > install a slightly less stable distro that uses at least 2.6.36." I hate to jump into this excellent example of bike-shedding discussion, but anyway ... Your example doesn't really reflect reality. It's common for older enterprise distributions to gradually incorporate a lot of backported code (and most importantly new hardware support code/drivers) while not upgrading the kernel major version. So yes, you will in reality get 2.6.16 kernel (at least according to uname) with libata with newer service packs of SLES 10, for example (and you could find many of those across distributions). -- Jiri Kosina SUSE Labs
[PATCH] drm/radeon/kms: add missing case for cayman thermal sensor
The rest of the code is already in place.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 86eda1e..aaa19dc 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -487,6 +487,7 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_RV6XX:
case THERMAL_TYPE_RV770:
case THERMAL_TYPE_EVERGREEN:
+ case THERMAL_TYPE_NI:
case THERMAL_TYPE_SUMO:
rdev->pm.int_hwmon_dev = hwmon_device_register(rdev->dev);
if (IS_ERR(rdev->pm.int_hwmon_dev)) {
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37603] New: r600g with LLVM enabled makes Heroes of Newerth game unplayable
https://bugs.freedesktop.org/show_bug.cgi?id=37603 Summary: r600g with LLVM enabled makes Heroes of Newerth game unplayable Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: dam...@grassart.com Created an attachment (id=47162) --> (https://bugs.freedesktop.org/attachment.cgi?id=47162) Blurry loading screen Hi, recent versions of Mesa have made this game go from 30 fps down to under 1 fps, and have caused the bottom of textures to become blurry (see attachment). I've bisected it down to commit a86fc719d6402eb482657707741890e69e81700f (enable LLVM by default on x86 and x86_64). I don't know why LLVM causes this but I've verified that disabling it via configure fixes this problem. I now use: ./configure --prefix=$HOME --enable-gallium-r600 --disable-gallium-r300 --disable-gallium-llvm --disable-gallium-egl --with-state-trackers=dri I know r300g requires LLVM but are there any reasons to enable it for r600g? Thanks, -Damien -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37603] New: r600g with LLVM enabled makes Heroes of Newerth game unplayable
https://bugs.freedesktop.org/show_bug.cgi?id=37603 Summary: r600g with LLVM enabled makes Heroes of Newerth game unplayable Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: damien at grassart.com Created an attachment (id=47162) --> (https://bugs.freedesktop.org/attachment.cgi?id=47162) Blurry loading screen Hi, recent versions of Mesa have made this game go from 30 fps down to under 1 fps, and have caused the bottom of textures to become blurry (see attachment). I've bisected it down to commit a86fc719d6402eb482657707741890e69e81700f (enable LLVM by default on x86 and x86_64). I don't know why LLVM causes this but I've verified that disabling it via configure fixes this problem. I now use: ./configure --prefix=$HOME --enable-gallium-r600 --disable-gallium-r300 --disable-gallium-llvm --disable-gallium-egl --with-state-trackers=dri I know r300g requires LLVM but are there any reasons to enable it for r600g? Thanks, -Damien -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()
Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes immediately upon start. lspci excerpt: 01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series] 01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary) /var/log/messages excerpt: [drm] Setting GART location based on new memory map [drm] Loading R500 Microcode [drm] Num pipes: 1 [drm] writeback test succeeded in 1 usecs [drm] Num pipes: 1 BUG: unable to handle kernel paging request at 6b6b6b6b IP: [] radeon_read_ring_rptr+0x19/0x30 *pdpt = 335ab001 *pde = Oops: [#1] PREEMPT SMP last sysfs file: /sys/devices/pci:00/:00:01.0/:01:00.0/enable Modules linked in: [last unloaded: scsi_wait_scan] May 25 12:23:58 lokka kernel: Pid: 4484, comm: X Not tainted 2.6.39-x255 #1 Dell Inc. Dell DXP051 /0FJ030 EIP: 0060:[] EFLAGS: 00213202 CPU: 1 EIP is at radeon_read_ring_rptr+0x19/0x30 EAX: f3484be0 EBX: f569baa0 ECX: 000a EDX: 6b6b6b6b ESI: f85e5000 EDI: 0040 EBP: f37a1d0c ESP: f37a1d08 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process X (pid: 4484, ti=f37a task=f378b3c0 task.ti=f37a) Stack: c1377387 f37a1d1c c1377b86 f569baa0 0010 f37a1d44 c137a0be 0001 c1a8a2f7 c188cb8a c1a648c4 f6424d60 f569baa0 f37a1d58 c137c7cf f569bbb0 f569baa0 f569baa0 f37a1d6c c137c9b7 f569bab4 f569bbe0 Call Trace: [] ? radeon_get_ring_head+0x47/0x50 [] radeon_commit_ring+0x56/0xb0 [] radeon_do_cp_idle+0xce/0x170 [] radeon_apply_surface_regs+0x2f/0x150 [] free_surface+0xc7/0x100 [] radeon_driver_lastclose+0x45/0x60 [] drm_lastclose+0x40/0x2b0 [] ? drm_release+0x344/0x460 [] drm_release+0x376/0x460 [] __fput+0xa9/0x1c0 [] fput+0x1f/0x30 [] filp_close+0x4d/0x80 [] put_files_struct+0x76/0xe0 [] exit_files+0x42/0x60 [] do_exit+0x231/0x320 [] do_group_exit+0x33/0x90 [] ? sub_preempt_count+0x7b/0xa0 [] get_signal_to_deliver+0x17d/0x2a0 [] do_notify_resume+0xc0/0x180 [] ? mntput+0x13/0x30 [] ? __fput+0x12f/0x1c0 [] ? get_parent_ip+0xb/0x40 [] ? sub_preempt_count+0x7b/0xa0 [] ? _raw_spin_unlock_irq+0x18/0x40 [] ? sigprocmask+0x70/0xf0 [] ? sys_rt_sigprocmask+0xd4/0xf0 [] ? sys_rt_sigprocmask+0xd4/0xf0 [] work_notifysig+0x13/0x1b Code: fe ff 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 f6 80 3a 03 00 00 08 89 e5 75 14 8b 80 e0 00 00 00 83 e2 fc 5d 03 50 14 <8b> 02 c3 8d 74 26 00 8b 80 e0 00 00 00 03 50 14 8b 02 5d c3 8d EIP: [] radeon_read_ring_rptr+0x19/0x30 SS:ESP 0068:f37a1d08 CR2: 6b6b6b6b ---[ end trace 9a6c2c396ea040f5 ]--- Fixing recursive fault but reboot is needed! /var/log/Xorg.0.log: [ 111.905] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [ 111.906] _XSERVTransOpen: transport open failed for inet6/lokka.tasking.nl:0 [ 111.906] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 111.917] X.Org X Server 1.9.5 Release Date: 2011-03-17 [ 111.917] X Protocol Version 11, Revision 0 [ 111.917] Build Operating System: x86-01 2.6.32-71.14.1.el6.x86_64 [ 111.917] Current Operating System: Linux lokka.tasking.nl 2.6.39-x255 #1 SMP PREEMPT Wed May 25 10:34:33 CEST 2011 i686 [ 111.917] Kernel command line: initrd=initrd nomodules panic=60 nmi_watchdog=1 netconsole=@172.17.1.124/,514 at 172.17.1.64/00:12:3f:85:17:52 BOOT_IMAGE=linux-2.6.39-x255 [ 111.917] Build Date: 18 March 2011 12:23:01AM [ 111.917] Build ID: xorg-x11-server 1.9.5-1.fc14 [ 111.918] Current version of pixman: 0.18.4 [ 111.918]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 111.918] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 111.918] (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 25 12:23:57 2011 [ 111.964] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 111.964] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 111.981] (==) No Layout section. Using the first Screen section. [ 111.981] (==) No screen section available. Using defaults. [ 111.981] (**) |-->Screen "Default Screen Section" (0) [ 111.981] (**) | |-->Monitor "" [ 111.982] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 111.982] (==) Automatically adding devices [ 111.982] (==) Automatically enabling devices [ 111.983] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 111.983] (==) ModulePath set to "/usr/lib/xorg/modules" [ 111.983] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 111.983] (II) *** *
[PATCH] drm/radeon/kms: properly set panel mode for eDP
This should make eDP more reliable.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 11 +++
include/drm/drm_dp_helper.h |3 +++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8c0f9e3..892b88d 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -543,6 +543,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder
*encoder,
{
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
+ struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
if (!ASIC_IS_DCE4(rdev))
@@ -550,10 +551,20 @@ static void radeon_dp_set_panel_mode(struct drm_encoder
*encoder,
if (radeon_connector_encoder_is_dp_bridge(connector))
panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
+ else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ u8 tmp = radeon_read_dpcd_reg(radeon_connector,
DP_EDP_CONFIGURATION_CAP);
+ if (tmp & 1)
+ panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
+ }
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
panel_mode);
+
+ if ((connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
+ (panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
+ radeon_write_dpcd_reg(radeon_connector,
DP_EDP_CONFIGURATION_SET, 1);
+ }
}
void radeon_dp_set_link_config(struct drm_connector *connector,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 91567bb..03eb1d6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -72,6 +72,7 @@
#define DP_MAIN_LINK_CHANNEL_CODING 0x006
+#define DP_EDP_CONFIGURATION_CAP0x00d
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e
/* link configuration */
@@ -133,6 +134,8 @@
#define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
# define DP_SET_ANSI_8B10B (1 << 0)
+#define DP_EDP_CONFIGURATION_SET0x10a
+
#define DP_LANE0_1_STATUS 0x202
#define DP_LANE2_3_STATUS 0x203
# define DP_LANE_CR_DONE (1 << 0)
--
1.7.4
[PATCH] uv/x2apic: update for change in pci bridge handling.
From: Dave Airlie
I forgot about the special uv handling code for this, so this
patch fixes it up.
Signed-off-by: Dave Airlie
---
arch/x86/kernel/apic/x2apic_uv_x.c |8
drivers/pci/pci.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 33b10a0..185cd1e 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -599,14 +599,14 @@ late_initcall(uv_init_heartbeat);
/* Direct Legacy VGA I/O traffic to designated IOH */
int uv_set_vga_state(struct pci_dev *pdev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
{
int domain, bus, rc;
- PR_DEVEL("devfn %x decode %d cmd %x chg_brdg %d\n",
- pdev->devfn, decode, command_bits, change_bridge);
+ PR_DEVEL("devfn %x decode %d cmd %x flags %d\n",
+ pdev->devfn, decode, command_bits, flags);
- if (!change_bridge)
+ if (!(flags & PCI_VGA_STATE_CHANGE_BRIDGE))
return 0;
if ((command_bits & PCI_COMMAND_IO) == 0)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a339237..4528ee7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2862,11 +2862,11 @@ void __init
pci_register_set_vga_state(arch_set_vga_state_t func)
}
static int pci_set_vga_state_arch(struct pci_dev *dev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
{
if (arch_set_vga_state)
return arch_set_vga_state(dev, decode, command_bits,
- change_bridge);
+ flags);
return 0;
}
--
1.7.1
[PATCH] drm/radeon/kms: add blit support for cayman (v2)
Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.
v2: fix copy paste typo
Reported-by: Nils Wallménius
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cayman_blit_shaders.c | 326 -
drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 505 ++
drivers/gpu/drm/radeon/ni.c | 13 +-
drivers/gpu/drm/radeon/radeon_asic.c |6 +-
5 files changed, 598 insertions(+), 255 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@
const u32 cayman_default_state[] =
{
- /* XXX fill in additional blit state */
+ 0xc0066900,
+ 0x,
+ 0x0060, /* DB_RENDER_CONTROL */
+ 0x, /* DB_COUNT_CONTROL */
+ 0x, /* DB_DEPTH_VIEW */
+ 0x002a, /* DB_RENDER_OVERRIDE */
+ 0x, /* DB_RENDER_OVERRIDE2 */
+ 0x, /* DB_HTILE_DATA_BASE */
0xc0026900,
- 0x0316,
- 0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
- 0x0010, /* */
+ 0x000a,
+ 0x, /* DB_STENCIL_CLEAR */
+ 0x, /* DB_DEPTH_CLEAR */
+
+ 0xc0036900,
+ 0x000f,
+ 0x, /* DB_DEPTH_INFO */
+ 0x, /* DB_Z_INFO */
+ 0x, /* DB_STENCIL_INFO */
+
+ 0xc0016900,
+ 0x0080,
+ 0x, /* PA_SC_WINDOW_OFFSET */
+
+ 0xc00d6900,
+ 0x0083,
+ 0x, /* PA_SC_CLIPRECT_RULE */
+ 0x, /* PA_SC_CLIPRECT_0_TL */
+ 0x20002000, /* PA_SC_CLIPRECT_0_BR */
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x, /* PA_SC_EDGERULE */
+ 0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+ 0x000f, /* CB_TARGET_MASK */
+ 0x000f, /* CB_SHADER_MASK */
+
+ 0xc0226900,
+ 0x0094,
+ 0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+ 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x, /* PA_SC_VPORT_ZMIN_0 */
+ 0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+ 0xc0016900,
+ 0x00d4,
+ 0x, /* SX_MISC */
0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+ 0xc0096900,
+ 0x0100,
+ 0x00ff, /* VGT_MAX_VTX_INDX */
+ 0x, /* VGT_MIN_VTX_INDX */
+ 0x, /* VGT_INDX_OFFSET */
+ 0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+ 0x, /* SX_ALPHA_TEST_CONTROL */
+ 0x, /* CB_BLEND_RED */
+ 0x, /* CB_BLEND_GREEN */
+ 0x, /* CB_BLEND_BLUE */
+ 0x, /* CB_BLEND_ALPHA */
+
+ 0xc0016900,
+ 0x0187,
+ 0x0100, /* SPI_VS_OUT_ID_0 */
+
+ 0xc0026900,
+ 0x0191,
+ 0x0100, /* SPI_PS_INPUT_CNTL_0 */
+ 0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+ 0xc0016900,
+ 0x01b1,
+ 0x, /* SPI_VS_OUT_CONFIG */
+
+ 0xc0106900,
+ 0x01b3,
+ 0x2001, /* SPI_PS_IN_CONTROL_0 */
+ 0x, /* SPI_PS_IN_CONTROL_1 */
+ 0x, /* SPI_INTERP_CONTROL_0 */
+ 0x, /* SPI_INPUT_Z */
+ 0x, /* SPI_FOG_CNTL */
+ 0x0010, /* SPI_BARYC_CNTL */
+ 0x, /* SPI_PS_IN_CONTROL_2 */
+ 0x, /* SPI_COMPUTE_INPUT_CNTL */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_X */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+ 0x, /* SPI_GPR_MGMT */
+ 0x, /* SPI_LDS_MGMT */
+ 0x, /* SPI_STACK_MGMT */
+ 0x, /* SPI_WAVE_MGMT_1 */
+ 0x, /* SPI_WAVE_MGMT_2 */
+
+ 0xc0016900,
+ 0x01e0,
+ 0x, /* CB_BLEND0_CONTROL */
+
+ 0xc00e6900,
+ 0x0200,
+ 0x, /* DB_DEPTH_CONTROL */
+ 0x, /* DB_EQAA */
+ 0x00cc0010, /* CB_COLOR_CONTROL */
+ 0x0210, /* DB_SHADER_CONTROL */
+ 0x0001, /* PA_C
[patch] drm/i915: fix if statement in ivybridge irq handler
The extra semicolon was not intended. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index b79619a..b9fafe3 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -517,7 +517,7 @@ irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS) if (de_iir & DE_PIPEA_VBLANK_IVB) drm_handle_vblank(dev, 0); - if (de_iir & DE_PIPEB_VBLANK_IVB); + if (de_iir & DE_PIPEB_VBLANK_IVB) drm_handle_vblank(dev, 1); /* check event from PCH */
[PATCH] drm/radeon/kms: clean up the radeon kms Kconfig
- no longer in staging - all radeons supported Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/Kconfig |9 + 1 files changed, 1 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 9746fee..ea92bbe 100644 --- a/drivers/gpu/drm/radeon/Kconfig +++ b/drivers/gpu/drm/radeon/Kconfig @@ -28,11 +28,4 @@ config DRM_RADEON_KMS The kernel will also perform security check on command stream provided by the user, we want to catch and forbid any illegal use of the GPU such as DMA into random system memory or into memory - not owned by the process supplying the command stream. This part - of the code is still incomplete and this why we propose that patch - as a staging driver addition, future security might forbid current - experimental userspace to run. - - This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX - (radeon up to X1950). Works is underway to provide support for R6XX, - R7XX and newer hardware (radeon from HD2XXX to HD4XXX). + not owned by the process supplying the command stream. -- 1.7.1.1
PROBLEM: Oops in drm_vblank_put() 2.6.39-1 intel i915 82915G/GV/910GL
0xf8469000 sr_mod 12668 0 - Live 0xf846 cdrom 30893 1 sr_mod, Live 0xf844f000 sd_mod 25091 4 - Live 0xf8439000 ata_piix 18337 3 - Live 0xf80b1000 pata_acpi 2292 0 - Live 0xf803d000 libata 150925 2 ata_piix,pata_acpi, Live 0xf82a5000 scsi_mod 107918 4 sg,sr_mod,sd_mod,libata, Live 0xf819f000 i915 551141 2 - Live 0xf82f3000 drm_kms_helper 23853 1 i915, Live 0xf8048000 drm 144133 3 i915,drm_kms_helper, Live 0xf80ba000 intel_agp 8496 1 i915, Live 0xf8079000 i2c_algo_bit 4263 1 i915, Live 0xf806a000 button 3518 1 i915, Live 0xf8005000 intel_gtt 11097 3 i915,intel_agp, Live 0xf8055000 agpgart 21456 3 drm,intel_agp,intel_gtt, Live 0xf804 i2c_core 15857 5 i2c_i801,i915,drm_kms_helper,drm,i2c_algo_bit, Live 0xf802a000 video 9652 1 i915, Live 0xf8018000 [milindm at milindm-desktop linux-2.6.39]$ [milindm at milindm-desktop linux-2.6.39]$ cat /proc/iomem - : reserved 0001-0009 : System RAM 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : reserved 000f-000f : System ROM 0010-3f686bff : System RAM 0100-01331dc0 : Kernel code 01331dc1-0147197f : Kernel data 014e6000-015c9fff : Kernel bss 3f686c00-3f688bff : ACPI Non-volatile Storage 3f688c00-3f68abff : ACPI Tables 3f68ac00-3fff : reserved 4000-401f : PCI Bus :02 c000-cfff : :00:02.0 dfa0-dfaf : PCI Bus :04 dfafff00-dfaf : :04:00.0 dfafff00-dfaf : 8139too dfb0-dfbf : PCI Bus :03 dfc0-dfcf : PCI Bus :02 dfcf-dfcf : :02:00.0 dfcf-dfcf : tg3 dfd0-dfdf : PCI Bus :01 dfebfd00-dfebfdff : :00:1e.2 dfebfd00-dfebfdff : Intel ICH6 dfebfe00-dfeb : :00:1e.2 dfebfe00-dfeb : Intel ICH6 dfec-dfef : :00:02.0 dff0-dff7 : :00:02.0 dff8-dfff : :00:02.1 e000-efff : PCI MMCONFIG [bus 00-ff] e000-efff : reserved e000-efff : pnp 00:09 fec0-fed003ff : reserved fec0-fec003ff : IOAPIC 0 fed0-fed003ff : HPET 0 fed2-fed9 : reserved fed2-fed9 : pnp 00:08 feda-fedacfff : pnp 00:09 fee0-feef : reserved fee0-feef : pnp 00:08 fee0-fee00fff : Local APIC ffa80800-ffa80bff : :00:1d.7 ffa80800-ffa80bff : ehci_hcd ffb0- : reserved ffb0-ffbf : pnp 00:08 ffc0- : pnp 00:08 [milindm at milindm-desktop linux-2.6.39]$ Regards, Milind -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/6f5fd735/attachment-0001.htm> -- next part -- 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 04) Subsystem: Dell Device 0179 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [88] Subsystem: Intel Corporation Device Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 4149 Capabilities: [a0] Express (v1) Root Port (Slot-), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled+ Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID 000
[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #6 from Rune K. Svendsen 2011-05-25 12:34:00 PDT --- Created an attachment (id=47160) --> (https://bugs.freedesktop.org/attachment.cgi?id=47160) Second output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz It just happened again. I did a 'thread apply all bt full' again, and I can see that the output isn't the same as the previous time. So I'm attaching this output in case it's relevant. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #6 from Rune K. Svendsen 2011-05-25 12:34:00 PDT --- Created an attachment (id=47160) --> (https://bugs.freedesktop.org/attachment.cgi?id=47160) Second output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz It just happened again. I did a 'thread apply all bt full' again, and I can see that the output isn't the same as the previous time. So I'm attaching this output in case it's relevant. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #5 from Rune K. Svendsen 2011-05-25 12:27:24 PDT --- Created an attachment (id=47157) --> (https://bugs.freedesktop.org/attachment.cgi?id=47157) Output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz (In reply to comment #3) > Looks like it's hanging when trying to acquire the radeon->bo_handles_mutex . > Does running > > thread apply all bt full > > in gdb give backtraces for any other threads? I'm attaching the output of that command here. Please let me know if I'm missing any relevant debug symbols. I can see a lot of the loaded libraries don't have debug symbols, so please let me know which are relevant, if any. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #5 from Rune K. Svendsen 2011-05-25 12:27:24 PDT --- Created an attachment (id=47157) --> (https://bugs.freedesktop.org/attachment.cgi?id=47157) Output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz (In reply to comment #3) > Looks like it's hanging when trying to acquire the radeon->bo_handles_mutex . > Does running > > thread apply all bt full > > in gdb give backtraces for any other threads? I'm attaching the output of that command here. Please let me know if I'm missing any relevant debug symbols. I can see a lot of the loaded libraries don't have debug symbols, so please let me know which are relevant, if any. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37193] Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 --- Comment #6 from Mathias Brodala 2011-05-25 12:09:16 PDT --- Any idea how I at least could prevent the sudden reboots to be able to gather some debugging data? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37193] Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 --- Comment #6 from Mathias Brodala 2011-05-25 12:09:16 PDT --- Any idea how I at least could prevent the sudden reboots to be able to gather some debugging data? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
connector - encoder relationship
On Wed, May 25, 2011 at 4:36 AM, Sascha Hauer wrote: > Hi All, > > I'm currently looking into implementing a SoC graphics core with KMS. > > What I wonder about is the relationship between connectors and encoders. > On my board I have a sii9022 HDMI encoder connected via i2c. This chip > supports reading edid data, tracks the connection status of the display > and needs to be configured when the resolution changes. So my first > guess is that I have to implement an encoder. looking at struct > drm_encoder_funcs there are no callbacks suitable for this. struct > drm_connector_funcs on the other hand has all the callbacks I need. > Now I look at drivers/gpu/drm/i2c. The drivers there implement a > drm_encoder_slave which also has all the callbacks I need. So from > one point of view the functions should be implemented in the connector, > while in the i2c case it's implemented in the (slave-) encoder. > Generally I have the feeling that my sii9022 should be both an encoder > and a connector, but this doesn't fit into the current scheme. > > I'm confused. Could someone clarify this a bit? The general idea is this: framebuffer -> crtc -> encoder -> connector -> monitor - The framebuffer is just a buffer vram that has an image encoded in it as an array of pixels. - The crtc reads the data out of the framebuffer and generates the video mode timing in conjunction with a PLL. The crtc also determines what part of the framebuffer is read; e.g., when multi-head is enabled, each crtc scans out of a different part of vram; in clone mode, each crtc scans out of the same part of vram. - The encoder takes the digital bitstream from the crtc and converts it to the appropriate analog levels for transmission across the connector to the monitor. - The connector provides the appropriate physical plug (HDMI, DVI-D, VGA, S-video, etc.) for the monitor to connect to. crtcs are usually routeable and can be connected to one or many encoders simultaneously. The encoders can also be connected to one or more connectors (e.g., you might have a single TMDS encoder that is connected to the digital portion of a DVI-I port and also to a HDMI port, or you might have a DAC that is connected to a VGA port and an S-video port). Finally i2c lines are associated with connectors, since generally the i2c pins are wired to the connector and in many cases, each connectors has it's own i2c line. For example, you might have a single TMDS encoder that is wired to a DVI-D port with its own i2c line and an HDMI port with its own i2c line. Each connector may have it's own hotplug (HPD) pin as well. That way you could query the EDID from each connector separately for example. Is the sii9022 being driven by the output of a DVO encoder from your display hw? If so your display path would look like: crtc -> DVO (master encoder) -> sii9022 (slave encoder) -> HDMI plug -> monitor The general GPU driver might register the i2c buses that are used by the various parts (encoder, connector), then it's just a matter of plugging in the right parts for each component (e.g. you'd hook up the sii9022 i2c control bus to the DVO encoder, and the ddc i2c bus to the hdmi connector object, etc.). I hope this helps. > > Thanks > ?Sascha > > -- > Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? | > Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?| > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?| > Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917- | > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()
On Wed, May 25, 2011 at 8:29 AM, Frank van Maarseveen wrote: > Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes > immediately upon start. > Any reason you are not using kms? Alex > lspci excerpt: > 01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon > X1300/X1550 Series] > 01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] > (Secondary) > > /var/log/messages excerpt: > [drm] Setting GART location based on new memory map > [drm] Loading R500 Microcode > [drm] Num pipes: 1 > [drm] writeback test succeeded in 1 usecs > [drm] Num pipes: 1 > BUG: unable to handle kernel paging request at 6b6b6b6b > IP: [] radeon_read_ring_rptr+0x19/0x30 > *pdpt = 335ab001 *pde = > Oops: [#1] PREEMPT SMP > last sysfs file: /sys/devices/pci:00/:00:01.0/:01:00.0/enable > Modules linked in: [last unloaded: scsi_wait_scan] > May 25 12:23:58 lokka kernel: > Pid: 4484, comm: X Not tainted 2.6.39-x255 #1 Dell Inc. ? ? ? ? ? ? ? ? Dell > DXP051 ? ? ? ? ? ? ? ? ?/0FJ030 > EIP: 0060:[] EFLAGS: 00213202 CPU: 1 > EIP is at radeon_read_ring_rptr+0x19/0x30 > EAX: f3484be0 EBX: f569baa0 ECX: 000a EDX: 6b6b6b6b > ESI: f85e5000 EDI: 0040 EBP: f37a1d0c ESP: f37a1d08 > DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > Process X (pid: 4484, ti=f37a task=f378b3c0 task.ti=f37a) > Stack: > c1377387 f37a1d1c c1377b86 f569baa0 0010 f37a1d44 c137a0be 0001 > c1a8a2f7 c188cb8a c1a648c4 f6424d60 f569baa0 f37a1d58 > c137c7cf f569bbb0 f569baa0 f569baa0 f37a1d6c c137c9b7 f569bab4 f569bbe0 > Call Trace: > [] ? radeon_get_ring_head+0x47/0x50 > [] radeon_commit_ring+0x56/0xb0 > [] radeon_do_cp_idle+0xce/0x170 > [] radeon_apply_surface_regs+0x2f/0x150 > [] free_surface+0xc7/0x100 > [] radeon_driver_lastclose+0x45/0x60 > [] drm_lastclose+0x40/0x2b0 > [] ? drm_release+0x344/0x460 > [] drm_release+0x376/0x460 > [] __fput+0xa9/0x1c0 > [] fput+0x1f/0x30 > [] filp_close+0x4d/0x80 > [] put_files_struct+0x76/0xe0 > [] exit_files+0x42/0x60 > [] do_exit+0x231/0x320 > [] do_group_exit+0x33/0x90 > [] ? sub_preempt_count+0x7b/0xa0 > [] get_signal_to_deliver+0x17d/0x2a0 > [] do_notify_resume+0xc0/0x180 > [] ? mntput+0x13/0x30 > [] ? __fput+0x12f/0x1c0 > [] ? get_parent_ip+0xb/0x40 > [] ? sub_preempt_count+0x7b/0xa0 > [] ? _raw_spin_unlock_irq+0x18/0x40 > [] ? sigprocmask+0x70/0xf0 > [] ? sys_rt_sigprocmask+0xd4/0xf0 > [] ? sys_rt_sigprocmask+0xd4/0xf0 > [] work_notifysig+0x13/0x1b > Code: fe ff 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 f6 80 3a 03 00 > 00 08 89 e5 75 14 8b 80 e0 00 00 00 83 e2 fc 5d 03 50 14 <8b> 02 c3 8d 74 26 > 00 8b 80 e0 00 00 00 03 50 14 8b 02 5d c3 8d > EIP: [] radeon_read_ring_rptr+0x19/0x30 SS:ESP 0068:f37a1d08 > CR2: 6b6b6b6b > ---[ end trace 9a6c2c396ea040f5 ]--- > Fixing recursive fault but reboot is needed! > > /var/log/Xorg.0.log: > [ ? 111.905] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 > [ ? 111.906] _XSERVTransOpen: transport open failed for > inet6/lokka.tasking.nl:0 > [ ? 111.906] _XSERVTransMakeAllCOTSServerListeners: failed to open listener > for inet6 > [ ? 111.917] > X.Org X Server 1.9.5 > Release Date: 2011-03-17 > [ ? 111.917] X Protocol Version 11, Revision 0 > [ ? 111.917] Build Operating System: x86-01 2.6.32-71.14.1.el6.x86_64 > [ ? 111.917] Current Operating System: Linux lokka.tasking.nl 2.6.39-x255 #1 > SMP PREEMPT Wed May 25 10:34:33 CEST 2011 i686 > [ ? 111.917] Kernel command line: initrd=initrd nomodules panic=60 > nmi_watchdog=1 netconsole=@172.17.1.124/,514 at 172.17.1.64/00:12:3f:85:17:52 > BOOT_IMAGE=linux-2.6.39-x255 > [ ? 111.917] Build Date: 18 March 2011 ?12:23:01AM > [ ? 111.917] Build ID: xorg-x11-server 1.9.5-1.fc14 > [ ? 111.918] Current version of pixman: 0.18.4 > [ ? 111.918] ? ?Before reporting problems, check http://wiki.x.org > ? ? ? ?to make sure that you have the latest version. > [ ? 111.918] Markers: (--) probed, (**) from config file, (==) default > setting, > ? ? ? ?(++) from command line, (!!) notice, (II) informational, > ? ? ? ?(WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ ? 111.918] (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 25 12:23:57 > 2011 > [ ? 111.964] (==) Using config directory: "/etc/X11/xorg.conf.d" > [ ? 111.964] (==) Using system config directory "/usr/share/X11/xorg.conf.d" > [ ? 111.981] (==) No Layout section. ?Using the first Screen section. > [ ? 111.981] (==) No screen section available. Using defaults. > [ ? 111.981] (**) |-->Screen "Default Screen Section" (0) > [ ? 111.981] (**) | ? |-->Monitor "" > [ ? 111.982] (==) No monitor specified for screen "Default Screen Section". > ? ? ? ?Using a default monitor configuration. > [ ? 111.982] (==) Automatically adding devices > [ ? 111.982] (==) Automatically enabling devices > [ ? 111.983] (==) FontPath set to: > ? ? ? ?catalogue:/etc/X11/fontpath.d, > ? ? ? ?built-ins > [ ? 111.983] (==) ModulePath set to "/
(Short?) merge window reminder
On Tuesday 24 May 2011 23:05:30 Jan Engelhardt wrote:
> On Tuesday 2011-05-24 20:48, eschvoca wrote:
> >On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
> >> It's not about features. It hasn't been about features for forever.
> >
> >Using the date also clearly communicates it is not about features.
>
> On the contrary: Whenever a 2.6.x release was set out the door, there
> was at least one new feature in the cycle. Given the endless manpower
> that seems to trail Linux, that seems unlikely to change in the near
> term.
>
> On "It is not about features" - it is not /just/ about features - it
> is also about fixes, which are equally important, and they also
> warrant a version bump of some sort on their own. Pointing out the
> obvious, the stable serieses.
You are mixing up features based versioning and identifier for versions. Linux
has no feature based concept for most parts of their version number (only the
patch part clearly states: fixes, fixes, fixes). We only need something that
is easily readable and maybe has no extreme weird meaning that leads to false
conclusions. And yes, that is what eschvoca meant and not something like
"linux is stagnating".
> "Fleeing" to date-based version numbering seems like an excuse
> for making way for releases without any change whatsoever.
> (IOW, if there were features/fixes, a non-date based scheme of
> incremental numbers could indicate them already.)
Yes, that is usally the case... release the same source tarball again and
again. I always had that feeling when looking at those wine, ubuntu, gentoo,
ms, texlive, iasl, hugin, u-boot, ... developers. They are doing nothing the
whole day and the marketing department does everything.
> >Me, a nobody end user, would prefer a version number that corresponded
> >to the date. Something like:
> >
> >%y.%m.
> >%Y.%m.
>
> Except that LINUX_KERNEL_VERSION has only 8 bits for each,
> so 2011 is out of range, which would need to kept in mind.
> And a 2-digit spec.. nah that does not feel very 100-year
> proof. (Just look at struct tm.tm_year for the mess 2-digits
> made technically.)
What is LINUX_KERNEL_VERSION? I only know LINUX_VERSION_CODE and
KERNEL_VERSION
And the calculation behind it is following:
(((a) << 16) + ((b) << 8) + (c))
So for KERNEL_VERSION(2,6,40) we would get 0x20628 and for
KERNEL_VERSION(2011,2,0) we would get 0x07DB0200. Of course our
grandgrandgrand...grand children would die in agony in the year 65536.
And maybe (probably the module version check guys will kill me) could use a
compressed version of that without hurding the comparison function in out of
kernel modules. KERNEL_VERSION_Y(a,b) would be defined as
#define KERNEL_VERSION_Y(a,b) ({typeof (a) _a = a; \
typeof (b) _b = b; \
KERNEL_VERSION(_a >> 8, _a & 0xff, _b); })
This would bring us to the year 16777216 before everybody gets punched in his
private parts by the versioning scheme. It is also possible to get more out of
32 bits when we can assume that Linus or his grandgrand...grand children will
never do more than 128 releases a year.
But yes, I aggree not to use 2 digit numbers for years unless we want to
start the y2k+100 problem here.
> >Then users would know the significance of the number and when a vendor
> >says they support Linux 11.09 the user will immediately know if they
> >are up to date.
>
> An added issue with that would be that numbers would not increase in
> same-sized steps anymore and leave gaps. (There would probably be no
> 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)
Ok, this is really a good example why we should not use the month for
releases, but an ever increasing number until the first number is also
increased which resets the second number to 0.
Kind regards,
Emil
[PATCH] drm/radeon/kms: properly set panel mode for eDP
This should make eDP more reliable.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 11 +++
include/drm/drm_dp_helper.h |3 +++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8c0f9e3..892b88d 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -543,6 +543,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder
*encoder,
{
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
+ struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
if (!ASIC_IS_DCE4(rdev))
@@ -550,10 +551,20 @@ static void radeon_dp_set_panel_mode(struct drm_encoder
*encoder,
if (radeon_connector_encoder_is_dp_bridge(connector))
panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
+ else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ u8 tmp = radeon_read_dpcd_reg(radeon_connector,
DP_EDP_CONFIGURATION_CAP);
+ if (tmp & 1)
+ panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
+ }
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
panel_mode);
+
+ if ((connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
+ (panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
+ radeon_write_dpcd_reg(radeon_connector,
DP_EDP_CONFIGURATION_SET, 1);
+ }
}
void radeon_dp_set_link_config(struct drm_connector *connector,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 91567bb..03eb1d6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -72,6 +72,7 @@
#define DP_MAIN_LINK_CHANNEL_CODING 0x006
+#define DP_EDP_CONFIGURATION_CAP0x00d
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e
/* link configuration */
@@ -133,6 +134,8 @@
#define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
# define DP_SET_ANSI_8B10B (1 << 0)
+#define DP_EDP_CONFIGURATION_SET0x10a
+
#define DP_LANE0_1_STATUS 0x202
#define DP_LANE2_3_STATUS 0x203
# define DP_LANE_CR_DONE (1 << 0)
--
1.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 and boot freeze
Hello Jean, Thanks for answer, i will take more atention in subjects, > What is the last kernel that works for you? > > Are you running self-built or distribution kernels? > Can we please see the kernel configuration file? My Last kernel working from git repository was 2.6.38-rc8+, the stable line .38.X work fines. I use the git version from kernel.org site pull and build manually be me. The Latest Stable Kernel is from gentoo-sources, and i always compile manually too. I have attached .config kernel in mail. > It would be great > if you were able to get us the kernel logs in a text form, using some > form of serial console. Removing the CONFIG_I2C_CHARDEV has not effect, the panic continues happing I looking for some way to send panic log in text, but no success yet. -- yermandu -- next part -- A non-text attachment was scrubbed... Name: .config Type: application/octet-stream Size: 101119 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/3f09f604/attachment-0001.obj>
connector - encoder relationship
Hi All, I'm currently looking into implementing a SoC graphics core with KMS. What I wonder about is the relationship between connectors and encoders. On my board I have a sii9022 HDMI encoder connected via i2c. This chip supports reading edid data, tracks the connection status of the display and needs to be configured when the resolution changes. So my first guess is that I have to implement an encoder. looking at struct drm_encoder_funcs there are no callbacks suitable for this. struct drm_connector_funcs on the other hand has all the callbacks I need. Now I look at drivers/gpu/drm/i2c. The drivers there implement a drm_encoder_slave which also has all the callbacks I need. So from one point of view the functions should be implemented in the connector, while in the i2c case it's implemented in the (slave-) encoder. Generally I have the feeling that my sii9022 should be both an encoder and a connector, but this doesn't fit into the current scheme. I'm confused. Could someone clarify this a bit? Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] drm/radeon/kms: clean up the radeon kms Kconfig
- no longer in staging - all radeons supported Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/Kconfig |9 + 1 files changed, 1 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 9746fee..ea92bbe 100644 --- a/drivers/gpu/drm/radeon/Kconfig +++ b/drivers/gpu/drm/radeon/Kconfig @@ -28,11 +28,4 @@ config DRM_RADEON_KMS The kernel will also perform security check on command stream provided by the user, we want to catch and forbid any illegal use of the GPU such as DMA into random system memory or into memory - not owned by the process supplying the command stream. This part - of the code is still incomplete and this why we propose that patch - as a staging driver addition, future security might forbid current - experimental userspace to run. - - This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX - (radeon up to X1950). Works is underway to provide support for R6XX, - R7XX and newer hardware (radeon from HD2XXX to HD4XXX). + not owned by the process supplying the command stream. -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/i915: fix if statement in ivybridge irq handler
On Wed, 25 May 2011 12:56:56 +0300, Dan Carpenter wrote: > The extra semicolon was not intended. > > Signed-off-by: Dan Carpenter Merged to drm-intel-next. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/f2220e75/attachment.pgp>
Re: BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()
On Wed, May 25, 2011 at 11:43:00AM -0400, Alex Deucher wrote: > On Wed, May 25, 2011 at 8:29 AM, Frank van Maarseveen > wrote: > > Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes > > immediately upon start. > > > > Any reason you are not using kms? The help on that kernel configuration option for Radeon and Nouveau looked scary: it warned about pain for old userland and I'd prefer to use the same kernel for older distro (Debian lenny) too, if possible. I'll try it anyway. FC14 and FC15 live images run fine on this system with compiz enabled. > > Alex > [...] -- Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: connector - encoder relationship
On Wed, May 25, 2011 at 4:36 AM, Sascha Hauer wrote: > Hi All, > > I'm currently looking into implementing a SoC graphics core with KMS. > > What I wonder about is the relationship between connectors and encoders. > On my board I have a sii9022 HDMI encoder connected via i2c. This chip > supports reading edid data, tracks the connection status of the display > and needs to be configured when the resolution changes. So my first > guess is that I have to implement an encoder. looking at struct > drm_encoder_funcs there are no callbacks suitable for this. struct > drm_connector_funcs on the other hand has all the callbacks I need. > Now I look at drivers/gpu/drm/i2c. The drivers there implement a > drm_encoder_slave which also has all the callbacks I need. So from > one point of view the functions should be implemented in the connector, > while in the i2c case it's implemented in the (slave-) encoder. > Generally I have the feeling that my sii9022 should be both an encoder > and a connector, but this doesn't fit into the current scheme. > > I'm confused. Could someone clarify this a bit? The general idea is this: framebuffer -> crtc -> encoder -> connector -> monitor - The framebuffer is just a buffer vram that has an image encoded in it as an array of pixels. - The crtc reads the data out of the framebuffer and generates the video mode timing in conjunction with a PLL. The crtc also determines what part of the framebuffer is read; e.g., when multi-head is enabled, each crtc scans out of a different part of vram; in clone mode, each crtc scans out of the same part of vram. - The encoder takes the digital bitstream from the crtc and converts it to the appropriate analog levels for transmission across the connector to the monitor. - The connector provides the appropriate physical plug (HDMI, DVI-D, VGA, S-video, etc.) for the monitor to connect to. crtcs are usually routeable and can be connected to one or many encoders simultaneously. The encoders can also be connected to one or more connectors (e.g., you might have a single TMDS encoder that is connected to the digital portion of a DVI-I port and also to a HDMI port, or you might have a DAC that is connected to a VGA port and an S-video port). Finally i2c lines are associated with connectors, since generally the i2c pins are wired to the connector and in many cases, each connectors has it's own i2c line. For example, you might have a single TMDS encoder that is wired to a DVI-D port with its own i2c line and an HDMI port with its own i2c line. Each connector may have it's own hotplug (HPD) pin as well. That way you could query the EDID from each connector separately for example. Is the sii9022 being driven by the output of a DVO encoder from your display hw? If so your display path would look like: crtc -> DVO (master encoder) -> sii9022 (slave encoder) -> HDMI plug -> monitor The general GPU driver might register the i2c buses that are used by the various parts (encoder, connector), then it's just a matter of plugging in the right parts for each component (e.g. you'd hook up the sii9022 i2c control bus to the DVO encoder, and the ddc i2c bus to the hdmi connector object, etc.). I hope this helps. > > Thanks > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > ___ > 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: (Short?) merge window reminder
On Tuesday 24 May 2011 23:05:30 Jan Engelhardt wrote:
> On Tuesday 2011-05-24 20:48, eschvoca wrote:
> >On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
> >> It's not about features. It hasn't been about features for forever.
> >
> >Using the date also clearly communicates it is not about features.
>
> On the contrary: Whenever a 2.6.x release was set out the door, there
> was at least one new feature in the cycle. Given the endless manpower
> that seems to trail Linux, that seems unlikely to change in the near
> term.
>
> On "It is not about features" - it is not /just/ about features - it
> is also about fixes, which are equally important, and they also
> warrant a version bump of some sort on their own. Pointing out the
> obvious, the stable serieses.
You are mixing up features based versioning and identifier for versions. Linux
has no feature based concept for most parts of their version number (only the
patch part clearly states: fixes, fixes, fixes). We only need something that
is easily readable and maybe has no extreme weird meaning that leads to false
conclusions. And yes, that is what eschvoca meant and not something like
"linux is stagnating".
> "Fleeing" to date-based version numbering seems like an excuse
> for making way for releases without any change whatsoever.
> (IOW, if there were features/fixes, a non-date based scheme of
> incremental numbers could indicate them already.)
Yes, that is usally the case... release the same source tarball again and
again. I always had that feeling when looking at those wine, ubuntu, gentoo,
ms, texlive, iasl, hugin, u-boot, ... developers. They are doing nothing the
whole day and the marketing department does everything.
> >Me, a nobody end user, would prefer a version number that corresponded
> >to the date. Something like:
> >
> >%y.%m.
> >%Y.%m.
>
> Except that LINUX_KERNEL_VERSION has only 8 bits for each,
> so 2011 is out of range, which would need to kept in mind.
> And a 2-digit spec.. nah that does not feel very 100-year
> proof. (Just look at struct tm.tm_year for the mess 2-digits
> made technically.)
What is LINUX_KERNEL_VERSION? I only know LINUX_VERSION_CODE and
KERNEL_VERSION
And the calculation behind it is following:
(((a) << 16) + ((b) << 8) + (c))
So for KERNEL_VERSION(2,6,40) we would get 0x20628 and for
KERNEL_VERSION(2011,2,0) we would get 0x07DB0200. Of course our
grandgrandgrand...grand children would die in agony in the year 65536.
And maybe (probably the module version check guys will kill me) could use a
compressed version of that without hurding the comparison function in out of
kernel modules. KERNEL_VERSION_Y(a,b) would be defined as
#define KERNEL_VERSION_Y(a,b) ({typeof (a) _a = a; \
typeof (b) _b = b; \
KERNEL_VERSION(_a >> 8, _a & 0xff, _b); })
This would bring us to the year 16777216 before everybody gets punched in his
private parts by the versioning scheme. It is also possible to get more out of
32 bits when we can assume that Linus or his grandgrand...grand children will
never do more than 128 releases a year.
But yes, I aggree not to use 2 digit numbers for years unless we want to
start the y2k+100 problem here.
> >Then users would know the significance of the number and when a vendor
> >says they support Linux 11.09 the user will immediately know if they
> >are up to date.
>
> An added issue with that would be that numbers would not increase in
> same-sized steps anymore and leave gaps. (There would probably be no
> 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)
Ok, this is really a good example why we should not use the month for
releases, but an ever increasing number until the first number is also
increased which resets the second number to 0.
Kind regards,
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch] drm/i915: fix if statement in ivybridge irq handler
On Wed, 25 May 2011 12:56:56 +0300, Dan Carpenter wrote: > The extra semicolon was not intended. > > Signed-off-by: Dan Carpenter Merged to drm-intel-next. -- keith.pack...@intel.com pgpaxNsQU0ZYr.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31532] [RADEON:KMS:RV670:AGP:R600C-R600G] PCIE gart stalls
https://bugs.freedesktop.org/show_bug.cgi?id=31532 Andy Furniss changed: What|Removed |Added Summary|[RADEON:KMS:RV670:AGP:R600C |[RADEON:KMS:RV670:AGP:R600C |-R600G] rv670 AGP gart +|-R600G] PCIE gart stalls |gallium - GPU lockups. PCIE | |gart runs but stalls| --- Comment #4 from Andy Furniss 2011-05-25 08:11:21 PDT --- Running agpgart with gallium is now fixed and runs without stalls since r600g: bump domain selection up one layer. ecc051d65b6e17115439fb3609cccfd59f6272bf Running with agpmode=-1 + gallium is better than it was, all demos are stall free apart from fbo_firecube, but nexuiz still stalls badly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 31532] [RADEON:KMS:RV670:AGP:R600C-R600G] PCIE gart stalls
https://bugs.freedesktop.org/show_bug.cgi?id=31532 Andy Furniss changed: What|Removed |Added Summary|[RADEON:KMS:RV670:AGP:R600C |[RADEON:KMS:RV670:AGP:R600C |-R600G] rv670 AGP gart +|-R600G] PCIE gart stalls |gallium - GPU lockups. PCIE | |gart runs but stalls| --- Comment #4 from Andy Furniss 2011-05-25 08:11:21 PDT --- Running agpgart with gallium is now fixed and runs without stalls since r600g: bump domain selection up one layer. ecc051d65b6e17115439fb3609cccfd59f6272bf Running with agpmode=-1 + gallium is better than it was, all demos are stall free apart from fbo_firecube, but nexuiz still stalls badly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: (Short?) merge window reminder
On Tue, 24 May 2011, Andy Lutomirski wrote: > Also, when someone in my lab installs here> on a box that's running software I wrote that needs to support > modern high-speed peripherals, then I can say "What? You seriously > expect this stuff to work on Linux 2007? Let's install a slightly less > stable distro from at least 2010." This sounds a lot less nerdy than > "What? You seriously expect this stuff to work on Linux 2.6.27? Let's > install a slightly less stable distro that uses at least 2.6.36." I hate to jump into this excellent example of bike-shedding discussion, but anyway ... Your example doesn't really reflect reality. It's common for older enterprise distributions to gradually incorporate a lot of backported code (and most importantly new hardware support code/drivers) while not upgrading the kernel major version. So yes, you will in reality get 2.6.16 kernel (at least according to uname) with libata with newer service packs of SLES 10, for example (and you could find many of those across distributions). -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()
Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes immediately upon start. lspci excerpt: 01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series] 01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary) /var/log/messages excerpt: [drm] Setting GART location based on new memory map [drm] Loading R500 Microcode [drm] Num pipes: 1 [drm] writeback test succeeded in 1 usecs [drm] Num pipes: 1 BUG: unable to handle kernel paging request at 6b6b6b6b IP: [] radeon_read_ring_rptr+0x19/0x30 *pdpt = 335ab001 *pde = Oops: [#1] PREEMPT SMP last sysfs file: /sys/devices/pci:00/:00:01.0/:01:00.0/enable Modules linked in: [last unloaded: scsi_wait_scan] May 25 12:23:58 lokka kernel: Pid: 4484, comm: X Not tainted 2.6.39-x255 #1 Dell Inc. Dell DXP051 /0FJ030 EIP: 0060:[] EFLAGS: 00213202 CPU: 1 EIP is at radeon_read_ring_rptr+0x19/0x30 EAX: f3484be0 EBX: f569baa0 ECX: 000a EDX: 6b6b6b6b ESI: f85e5000 EDI: 0040 EBP: f37a1d0c ESP: f37a1d08 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process X (pid: 4484, ti=f37a task=f378b3c0 task.ti=f37a) Stack: c1377387 f37a1d1c c1377b86 f569baa0 0010 f37a1d44 c137a0be 0001 c1a8a2f7 c188cb8a c1a648c4 f6424d60 f569baa0 f37a1d58 c137c7cf f569bbb0 f569baa0 f569baa0 f37a1d6c c137c9b7 f569bab4 f569bbe0 Call Trace: [] ? radeon_get_ring_head+0x47/0x50 [] radeon_commit_ring+0x56/0xb0 [] radeon_do_cp_idle+0xce/0x170 [] radeon_apply_surface_regs+0x2f/0x150 [] free_surface+0xc7/0x100 [] radeon_driver_lastclose+0x45/0x60 [] drm_lastclose+0x40/0x2b0 [] ? drm_release+0x344/0x460 [] drm_release+0x376/0x460 [] __fput+0xa9/0x1c0 [] fput+0x1f/0x30 [] filp_close+0x4d/0x80 [] put_files_struct+0x76/0xe0 [] exit_files+0x42/0x60 [] do_exit+0x231/0x320 [] do_group_exit+0x33/0x90 [] ? sub_preempt_count+0x7b/0xa0 [] get_signal_to_deliver+0x17d/0x2a0 [] do_notify_resume+0xc0/0x180 [] ? mntput+0x13/0x30 [] ? __fput+0x12f/0x1c0 [] ? get_parent_ip+0xb/0x40 [] ? sub_preempt_count+0x7b/0xa0 [] ? _raw_spin_unlock_irq+0x18/0x40 [] ? sigprocmask+0x70/0xf0 [] ? sys_rt_sigprocmask+0xd4/0xf0 [] ? sys_rt_sigprocmask+0xd4/0xf0 [] work_notifysig+0x13/0x1b Code: fe ff 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 f6 80 3a 03 00 00 08 89 e5 75 14 8b 80 e0 00 00 00 83 e2 fc 5d 03 50 14 <8b> 02 c3 8d 74 26 00 8b 80 e0 00 00 00 03 50 14 8b 02 5d c3 8d EIP: [] radeon_read_ring_rptr+0x19/0x30 SS:ESP 0068:f37a1d08 CR2: 6b6b6b6b ---[ end trace 9a6c2c396ea040f5 ]--- Fixing recursive fault but reboot is needed! /var/log/Xorg.0.log: [ 111.905] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [ 111.906] _XSERVTransOpen: transport open failed for inet6/lokka.tasking.nl:0 [ 111.906] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 111.917] X.Org X Server 1.9.5 Release Date: 2011-03-17 [ 111.917] X Protocol Version 11, Revision 0 [ 111.917] Build Operating System: x86-01 2.6.32-71.14.1.el6.x86_64 [ 111.917] Current Operating System: Linux lokka.tasking.nl 2.6.39-x255 #1 SMP PREEMPT Wed May 25 10:34:33 CEST 2011 i686 [ 111.917] Kernel command line: initrd=initrd nomodules panic=60 nmi_watchdog=1 netconsole=@172.17.1.124/,514@172.17.1.64/00:12:3f:85:17:52 BOOT_IMAGE=linux-2.6.39-x255 [ 111.917] Build Date: 18 March 2011 12:23:01AM [ 111.917] Build ID: xorg-x11-server 1.9.5-1.fc14 [ 111.918] Current version of pixman: 0.18.4 [ 111.918]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 111.918] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 111.918] (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 25 12:23:57 2011 [ 111.964] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 111.964] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 111.981] (==) No Layout section. Using the first Screen section. [ 111.981] (==) No screen section available. Using defaults. [ 111.981] (**) |-->Screen "Default Screen Section" (0) [ 111.981] (**) | |-->Monitor "" [ 111.982] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 111.982] (==) Automatically adding devices [ 111.982] (==) Automatically enabling devices [ 111.983] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 111.983] (==) ModulePath set to "/usr/lib/xorg/modules" [ 111.983] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 111.983] (II) ***
(Short?) merge window reminder
> So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. How about stardates? That'd make a release made now 64860.8 I really should sleep more... -- Lisa Milne
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #8 from Maggioni Marcello 2011-05-25 03:46:01 PDT --- An update. I noticed that in fullscreen the problem is not present with the new drivers (no corruption at the bottom of the screen) , but the problem with the white dots persists. I also noticed that these dots are in random locations, but they surround point light sources like candles. I thought they were random, because you can see them trough walls , so the candles generating the dots were not directly visible, but behind the wall and I haven't immediatly connected this problem with the lights. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #8 from Maggioni Marcello 2011-05-25 03:46:01 PDT --- An update. I noticed that in fullscreen the problem is not present with the new drivers (no corruption at the bottom of the screen) , but the problem with the white dots persists. I also noticed that these dots are in random locations, but they surround point light sources like candles. I thought they were random, because you can see them trough walls , so the candles generating the dots were not directly visible, but behind the wall and I haven't immediatly connected this problem with the lights. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[patch] drm/i915: fix if statement in ivybridge irq handler
The extra semicolon was not intended. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index b79619a..b9fafe3 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -517,7 +517,7 @@ irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS) if (de_iir & DE_PIPEA_VBLANK_IVB) drm_handle_vblank(dev, 0); - if (de_iir & DE_PIPEB_VBLANK_IVB); + if (de_iir & DE_PIPEB_VBLANK_IVB) drm_handle_vblank(dev, 1); /* check event from PCH */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #7 from Maggioni Marcello 2011-05-25 02:48:12 PDT --- Created an attachment (id=47128) --> (https://bugs.freedesktop.org/attachment.cgi?id=47128) Problem This is the screenshot where the problem is present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #7 from Maggioni Marcello 2011-05-25 02:48:12 PDT --- Created an attachment (id=47128) --> (https://bugs.freedesktop.org/attachment.cgi?id=47128) Problem This is the screenshot where the problem is present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 Maggioni Marcello changed: What|Removed |Added Attachment #46494|0 |1 is obsolete|| --- Comment #6 from Maggioni Marcello 2011-05-25 02:46:50 PDT --- Created an attachment (id=47127) --> (https://bugs.freedesktop.org/attachment.cgi?id=47127) No problem This is the screenshot where the problem is not present. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 Maggioni Marcello changed: What|Removed |Added Attachment #46494|0 |1 is obsolete|| --- Comment #6 from Maggioni Marcello 2011-05-25 02:46:50 PDT --- Created an attachment (id=47127) --> (https://bugs.freedesktop.org/attachment.cgi?id=47127) No problem This is the screenshot where the problem is not present. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #5 from Maggioni Marcello 2011-05-25 02:45:09 PDT --- I tried the RenderTest and it seemed to work fine (the SSAO test was completely white though) . I tried the latest git today and then tested Amnesia again. The situation is improved. The game is not bug free, but now the black area in the bottom of the screen has been substituted by a white area that is present only under certain lighting conditions (I've attached two screenshots , one in which the problem isn't present and one in which it is). Also, when present the "disturbance" flickers at a very high frequency, so it's quite difficult to capture it in a screenshot (you catch it while it is appearing or disappearing on the screen very often), so it is bigger than the one that can be seen in the screenshot. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #5 from Maggioni Marcello 2011-05-25 02:45:09 PDT --- I tried the RenderTest and it seemed to work fine (the SSAO test was completely white though) . I tried the latest git today and then tested Amnesia again. The situation is improved. The game is not bug free, but now the black area in the bottom of the screen has been substituted by a white area that is present only under certain lighting conditions (I've attached two screenshots , one in which the problem isn't present and one in which it is). Also, when present the "disturbance" flickers at a very high frequency, so it's quite difficult to capture it in a screenshot (you catch it while it is appearing or disappearing on the screen very often), so it is bigger than the one that can be seen in the screenshot. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
connector - encoder relationship
Hi All, I'm currently looking into implementing a SoC graphics core with KMS. What I wonder about is the relationship between connectors and encoders. On my board I have a sii9022 HDMI encoder connected via i2c. This chip supports reading edid data, tracks the connection status of the display and needs to be configured when the resolution changes. So my first guess is that I have to implement an encoder. looking at struct drm_encoder_funcs there are no callbacks suitable for this. struct drm_connector_funcs on the other hand has all the callbacks I need. Now I look at drivers/gpu/drm/i2c. The drivers there implement a drm_encoder_slave which also has all the callbacks I need. So from one point of view the functions should be implemented in the connector, while in the i2c case it's implemented in the (slave-) encoder. Generally I have the feeling that my sii9022 should be both an encoder and a connector, but this doesn't fit into the current scheme. I'm confused. Could someone clarify this a bit? Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Monday 23 May 2011, 22:33:48 Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > I really hope there's also a voice that tells you to wait until .42 > > before cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. But hey, do you really want to release a Linux 3.0 kernel without serious layered filesystem functionality? Shame on you, Pete PS.: Sorry for being such a pest in this regard, but filesystem layering is one of the most important missing bits to excel out of the box in * live distros * diskless computing * flash based systems Even the linux based commercial PBX solution (mobydick), I bought, ships with it. PPS.: Bad timing, I know, but I'm glad, that Al is back to life again.. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 20:48, eschvoca wrote: >On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote: >> >> It's not about features. It hasn't been about features for forever. > >Using the date also clearly communicates it is not about features. On the contrary: Whenever a 2.6.x release was set out the door, there was at least one new feature in the cycle. Given the endless manpower that seems to trail Linux, that seems unlikely to change in the near term. On "It is not about features" - it is not /just/ about features - it is also about fixes, which are equally important, and they also warrant a version bump of some sort on their own. Pointing out the obvious, the stable serieses. "Fleeing" to date-based version numbering seems like an excuse for making way for releases without any change whatsoever. (IOW, if there were features/fixes, a non-date based scheme of incremental numbers could indicate them already.) >Me, a nobody end user, would prefer a version number that corresponded >to the date. Something like: > >%y.%m. >%Y.%m. Except that LINUX_KERNEL_VERSION has only 8 bits for each, so 2011 is out of range, which would need to kept in mind. And a 2-digit spec.. nah that does not feel very 100-year proof. (Just look at struct tm.tm_year for the mess 2-digits made technically.) >Then users would know the significance of the number and when a vendor >says they support Linux 11.09 the user will immediately know if they >are up to date. An added issue with that would be that numbers would not increase in same-sized steps anymore and leave gaps. (There would probably be no 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40) My 2円. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Hi, 2011/5/24 Lisa Milne : >> So I'm toying with 3.0 (and in that case, it really would be "3.0", >> not "3.0.0" - the stable team would get the third digit rather than >> the fourth one. > > How about stardates? This is a wonderful idea! :) > That'd make a release made now 64860.8 > > I really should sleep more... > > -- > Lisa Milne > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Slawa! Zimny Lech z Wawelu ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Linus Torvalds wrote: > PS. The voices in my head also tell me that the numbers are getting > too big. I may just call the thing 2.8.0. And I almost guarantee that > this PS is going to result in more discussion than the rest, but when > the voices tell me to do things, I listen. Correct :) I would still prefer the version number change to something like 2011.0 - already proposed at http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux I don't think that it is reasonable to say that it is bad because third party scripts would break - they would break anyway (I would bet that many of them don't expect to see 3.x anyway). And changing now to 3.0 and then incrementing the second one everytime for 10 years will also lead to something like 3.56.7. I would also say that defining the release number using the time of the merge window start/end is easy understandable. "2.6.40" would be the third development cycle this year aka v2011.2 or v2011.2.0 when the patchlevel should always be included. -- Emil Langrock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, 24 May 2011, Matthias Schniedermeyer wrote: On 23.05.2011 13:33, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be "3.0", not "3.0.0" - the stable team would get the third digit rather than the fourth one. What about strictly 3 part versions? Just add a .0. 3.0.0 - Release Kernel 3.0 3.0.1 - Stable 1 3.0.2 - Stable 2 3.1.0 - Release Kernel 3.1 3.1.1 - Stable 1 ... Biggest problem is likely version phobics that get pimples when they see trailing zeros. ;-) since there are always issues discovered with a new kernel is released (which is why the -stable kernels exist), being wary of .0 kernels is not neccessarily a bad thing. I still think a date based approach would be the best. since people are worried about not knowing when a final release will happen, base the date on when the merge window opened or closed (always known at the time of the first -rc kernel) in the thread on lwn, people pointed out that the latest 2.6.32 kernel would still be a 2009.12.X which doesn't reflect the fact that it was released this month. My suggestion for that is to make the X be the number of months (or years.months if you don't like large month values) between the merge window and the release of the -stable release. This would lead to a small problem when there are multiple -stable releases in a month, but since that doesn't last very long I don't see a real problem with just incramenting the month into the future in those cases. David Lang ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote: > On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin wrote: >> >> I think this whole discussion misses the essence of the new development >> model, which is that we no longer do these kinds of feature-based major >> milestones. > > Indeed. > > It's not about features. It hasn't been about features for forever. > > So a renumbering would be purely about dropping the numbers to > something smaller and more easily recognized. The ABI wouldn't change. > The API wouldn't change. There wouldn't be any big "because we finally > did xyz". > Me, a nobody end user, would prefer a version number that corresponded to the date. Something like: %y.%m. %Y.%m. Then users would know the significance of the number and when a vendor says they support Linux 11.09 the user will immediately know if they are up to date. Using the date also clearly communicates it is not about features. When there is a 3.0 (4.0) release people expect big new features and API/ABI breakage. My 2 cents. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 23.05.2011 13:33, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > > I really hope there's also a voice that tells you to wait until .42 before > > cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. What about strictly 3 part versions? Just add a .0. 3.0.0 - Release Kernel 3.0 3.0.1 - Stable 1 3.0.2 - Stable 2 3.1.0 - Release Kernel 3.1 3.1.1 - Stable 1 ... Biggest problem is likely version phobics that get pimples when they see trailing zeros. ;-) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers: Use kzalloc instead of 'kmalloc+memset', where possible.
On Tue, May 24, 2011 at 11:09 PM, Joe Perches wrote:
> On Tue, 2011-05-24 at 22:59 +0600, Rakib Mullick wrote:
> > On 5/23/11, Joe Perches wrote:
> > > On Mon, 2011-05-23 at 23:40 +0600, Rakib Mullick wrote:
> > >> Following patch removes the uses of 'kmalloc+memset' from various
> > >> drivers subsystems, which is replaced by kzalloc. kzalloc take care of
> > >> setting allocated memory with null, so it helps to get rid from using
> > >> memset.
> > >> diff --git a/drivers/gpu/drm/drm_scatter.c
> b/drivers/gpu/drm/drm_scatter.c
> > > []
> > >> - entry->pagelist = kmalloc(pages * sizeof(*entry->pagelist),
> GFP_KERNEL);
> > >> + entry->pagelist = kzalloc(pages * sizeof(*entry->pagelist),
> GFP_KERNEL);
> > > Perhaps it's better to use:
> > > entry->pagelist = kcalloc(pages, sizeof(*entry->pagelist),
> GFP_KERNEL);
> > >> - entry->busaddr = kmalloc(pages * sizeof(*entry->busaddr),
> GFP_KERNEL);
> > >> + entry->busaddr = kzalloc(pages * sizeof(*entry->busaddr),
> GFP_KERNEL);
> > > here too.
> > Is there any significant benefit of using kcalloc here?
>
> Overflow and tradition.
>
> static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
> {
>if (size != 0 && n > ULONG_MAX / size)
>return NULL;
>return __kmalloc(n * size, flags | __GFP_ZERO);
> }
>
> It's been used for allocating memory for an array. Maybe, using kcalloc in
entry->pagelist could be useful. But, not that much sure though. There's no
problem with current implementation.
This patch touches few drivers subsystems, they are added to the CC list.
Thanks,
Rakib
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: > Can we drop most of MCA, EISA and ISA bus if we are going to have a big > version change ? A driver spring clean is much overdue and it's all in > git in case someone wishes to sneak out at midnight and bring some crawly > horror back from the dead. Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a few others still refuse hard to die. Is it worth to setup a system to track success / failure reports for drivers and ditch drivers once there are no success reports for a driver for too long? It may not be a good idea - people tend not report success much more rarely than failure. (On that matter, I wonder if there are 5.25" USB floppy drives ...) Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote: > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > > not "3.0.0" - the stable team would get the third digit rather than > > the fourth one. > > If we change from 2.6.X to 3.X, then if we don't change anything else, > then successive stable release will cause the LINUX_VERSION_CODE to be > incremented. This isn't necessary bad, but it would be a different > from what we have now. It will require another bunch of changes to scripts that try to make sense out of kernel Linux version numbers. It's a minor issue and we might be better off doing something else than version number magic. Not last a new major version number raises expectations - whatever those might be. Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
> So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. How about stardates? That'd make a release made now 64860.8 I really should sleep more... -- Lisa Milne ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 17:46, Ralf Baechle wrote: >On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: > >> Can we drop most of MCA, EISA and ISA bus if we are going to have a big >> version change ? A driver spring clean is much overdue and it's all in >> git in case someone wishes to sneak out at midnight and bring some crawly >> horror back from the dead. > >Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a >few others still refuse hard to die. > >Is it worth to setup a system to track success / failure reports for >drivers and ditch drivers once there are no success reports for a driver >for too long? It may not be a good idea - people tend not report success >much more rarely than failure. > >(On that matter, I wonder if there are 5.25" USB floppy drives ...) If there were, they would appear as Mass Storage devices (at least the 3.5" USB floppy gadgets do), and as such, don't depend on ISA or the classic floppy driver at all. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: add blit support for cayman
Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cayman_blit_shaders.c | 326 -
drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 505 ++
drivers/gpu/drm/radeon/ni.c | 13 +-
drivers/gpu/drm/radeon/radeon_asic.c |6 +-
5 files changed, 598 insertions(+), 255 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@
const u32 cayman_default_state[] =
{
- /* XXX fill in additional blit state */
+ 0xc0066900,
+ 0x,
+ 0x0060, /* DB_RENDER_CONTROL */
+ 0x, /* DB_COUNT_CONTROL */
+ 0x, /* DB_DEPTH_VIEW */
+ 0x002a, /* DB_RENDER_OVERRIDE */
+ 0x, /* DB_RENDER_OVERRIDE2 */
+ 0x, /* DB_HTILE_DATA_BASE */
0xc0026900,
- 0x0316,
- 0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
- 0x0010, /* */
+ 0x000a,
+ 0x, /* DB_STENCIL_CLEAR */
+ 0x, /* DB_DEPTH_CLEAR */
+
+ 0xc0036900,
+ 0x000f,
+ 0x, /* DB_DEPTH_INFO */
+ 0x, /* DB_Z_INFO */
+ 0x, /* DB_STENCIL_INFO */
+
+ 0xc0016900,
+ 0x0080,
+ 0x, /* PA_SC_WINDOW_OFFSET */
+
+ 0xc00d6900,
+ 0x0083,
+ 0x, /* PA_SC_CLIPRECT_RULE */
+ 0x, /* PA_SC_CLIPRECT_0_TL */
+ 0x20002000, /* PA_SC_CLIPRECT_0_BR */
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x, /* PA_SC_EDGERULE */
+ 0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+ 0x000f, /* CB_TARGET_MASK */
+ 0x000f, /* CB_SHADER_MASK */
+
+ 0xc0226900,
+ 0x0094,
+ 0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+ 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x, /* PA_SC_VPORT_ZMIN_0 */
+ 0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+ 0xc0016900,
+ 0x00d4,
+ 0x, /* SX_MISC */
0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+ 0xc0096900,
+ 0x0100,
+ 0x00ff, /* VGT_MAX_VTX_INDX */
+ 0x, /* VGT_MIN_VTX_INDX */
+ 0x, /* VGT_INDX_OFFSET */
+ 0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+ 0x, /* SX_ALPHA_TEST_CONTROL */
+ 0x, /* CB_BLEND_RED */
+ 0x, /* CB_BLEND_GREEN */
+ 0x, /* CB_BLEND_BLUE */
+ 0x, /* CB_BLEND_ALPHA */
+
+ 0xc0016900,
+ 0x0187,
+ 0x0100, /* SPI_VS_OUT_ID_0 */
+
+ 0xc0026900,
+ 0x0191,
+ 0x0100, /* SPI_PS_INPUT_CNTL_0 */
+ 0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+ 0xc0016900,
+ 0x01b1,
+ 0x, /* SPI_VS_OUT_CONFIG */
+
+ 0xc0106900,
+ 0x01b3,
+ 0x2001, /* SPI_PS_IN_CONTROL_0 */
+ 0x, /* SPI_PS_IN_CONTROL_1 */
+ 0x, /* SPI_INTERP_CONTROL_0 */
+ 0x, /* SPI_INPUT_Z */
+ 0x, /* SPI_FOG_CNTL */
+ 0x0010, /* SPI_BARYC_CNTL */
+ 0x, /* SPI_PS_IN_CONTROL_2 */
+ 0x, /* SPI_COMPUTE_INPUT_CNTL */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_X */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+ 0x, /* SPI_GPR_MGMT */
+ 0x, /* SPI_LDS_MGMT */
+ 0x, /* SPI_STACK_MGMT */
+ 0x, /* SPI_WAVE_MGMT_1 */
+ 0x, /* SPI_WAVE_MGMT_2 */
+
+ 0xc0016900,
+ 0x01e0,
+ 0x, /* CB_BLEND0_CONTROL */
+
+ 0xc00e6900,
+ 0x0200,
+ 0x, /* DB_DEPTH_CONTROL */
+ 0x, /* DB_EQAA */
+ 0x00cc0010, /* CB_COLOR_CONTROL */
+ 0x0210, /* DB_SHADER_CONTROL */
+ 0x0001, /* PA_CL_CLIP_CNTL */
+ 0x0004, /* PA_SU_SC_MODE_CNTL *
[PATCH 1/2] drm/radeon/kms/blit: workaround some hw issues on evergreen+
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index ba06a69..4086729 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -199,6 +199,16 @@ static void
set_scissors(struct radeon_device *rdev, int x1, int y1,
int x2, int y2)
{
+ /* workaround some hw bugs */
+ if (x2 == 0)
+ x1 = 1;
+ if (y2 == 0)
+ y1 = 1;
+ if (rdev->family == CHIP_CAYMAN) {
+ if ((x2 == 1) && (y2 == 1))
+ x2 = 2;
+ }
+
radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONTEXT_REG, 2));
radeon_ring_write(rdev, (PA_SC_SCREEN_SCISSOR_TL -
PACKET3_SET_CONTEXT_REG_START) >> 2);
radeon_ring_write(rdev, (x1 << 0) | (y1 << 16));
--
1.7.1.1
(Short?) merge window reminder
On Monday 23 May 2011, 22:33:48 Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > I really hope there's also a voice that tells you to wait until .42 > > before cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. But hey, do you really want to release a Linux 3.0 kernel without serious layered filesystem functionality? Shame on you, Pete PS.: Sorry for being such a pest in this regard, but filesystem layering is one of the most important missing bits to excel out of the box in * live distros * diskless computing * flash based systems Even the linux based commercial PBX solution (mobydick), I bought, ships with it. PPS.: Bad timing, I know, but I'm glad, that Al is back to life again..
