[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote: > ? ??2012-07-26 ? 14:58 +0200?Luca Tettamanti ??? >> - again ACPI video module gets the nodification (in this case >> ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE >> - KDE seems this and muck with the screen configuration :( >> - meanwhile the brightness notification is propagated, the >> hypothetical >> radeon driver does its magic to adjust the screen. >> >> My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to >> the >> acpi notifier chain, and allow the handlers to veto the key press >> (like >> it's done for ACPI_VIDEO_NOTIFY_SWITCH). > > I welcome this approach! > > On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when > AC-power unplug, because BIOS want to nodify video driver do some power > saving stuff. > It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power > unplug. > > At least acpi/video driver need to know this 0x81 event is filed by BIOS > to radeon-acpi for notify but not do video mode switch. That means the > radeon drm need take the video switch responsibility. Probably we'd just want the radeon acpi handler to just forward the events to userspace so that the user can choose what to do with it (xrandr command, etc.), otherwise we'll need to define policy in the driver. Alex > > > Thanks a lot! > Joey Lee >
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #9 from sowad...@miner.mst.edu 2012-07-27 05:39:06 PDT --- I do not see any improvement after applying the proposed patch -- 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
[PATCH] drm/radeon: cleanup and fix crtc while programming mc
On Thu, Jul 26, 2012 at 8:35 PM, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 7:24 PM, wrote:
>> From: Jerome Glisse
>>
>> When we change start address of vram for the GPU memory controller
>> we need to make sure that nothing in the GPU still use the old vram
>> address. This patch cleanup and fix crtc address.
>>
>> However there is still someissue somewhere if we reenable the crtc
>> after updating the address at which they sancout. So to avoid any
>> issue disable crtc. Once we want to do flicker less transition
>> btw uefi and radeon we will probably want to revisit how we program
>> the GPU memory controller.
>>
>> This probably fix :
>> https://bugs.freedesktop.org/show_bug.cgi?id=52467
>> https://bugs.freedesktop.org/show_bug.cgi?id=42373
>>
>> Cc:
>
> this should be stable at vger.kernel.org
>
>> Signed-off-by: Jerome Glisse
>
> Also, I think we probably need to poll on bit 16
> (CRTC_CURRENT_MASTER_EN_STATE) of CRTC_CONTROL to make sure the crtc
> is actually disabled. Something like the following in mc_stop():
>
> WREG32(CRTC_CONTROL, 0);
> while (RREG32(CRTC_CONTROL & CRTC_CURRENT_MASTER_EN_STATE))
> udelay(1);
>
> Any chance you want to fix the rv515_mc_stop() and rv515_mc_resume()
> functions as well?
>
> Alex
I will respin with splitting out what fix and what just
improve/cleanup the code. I might change rv515 but i don't think it
will hit such issue, on rv515 crtc is enabled through VGA, here the
issue seems to only show up with uefi, i am trying to grab some non
uefi laptop with same gpu to check.
Cheers,
Jerome
>
>> ---
>> drivers/gpu/drm/radeon/evergreen.c | 178
>> --
>> drivers/gpu/drm/radeon/radeon_asic.h | 18 +++-
>> 2 files changed, 99 insertions(+), 97 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index e585a3b..c6ede66 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -1227,70 +1227,94 @@ void evergreen_agp_enable(struct radeon_device *rdev)
>> WREG32(VM_CONTEXT1_CNTL, 0);
>> }
>>
>> +static void evergreen_crtc_save(struct radeon_device *rdev, struct
>> evergreen_mc_save *save, unsigned idx)
>> +{
>> + save->crtc[idx].paddress = 0;
>> + save->crtc[idx].saddress = 0;
>> + save->crtc[idx].crtc_control = 0;
>> +
>> + if (idx >= rdev->num_crtc) {
>> + /* it seems accessing non existant crtc trigger high latency
>> */
>> + return;
>> + }
>> +
>> + save->crtc[idx].paddress =
>> RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + save->crtc[idx].offset);
>> + save->crtc[idx].paddress |=
>> ((uint64_t)RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
>> save->crtc[idx].offset)) << 32ULL;
>> + save->crtc[idx].saddress =
>> RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + save->crtc[idx].offset);
>> + save->crtc[idx].saddress |=
>> ((uint64_t)RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH +
>> save->crtc[idx].offset)) << 32ULL;
>> + save->crtc[idx].crtc_control = RREG32(EVERGREEN_CRTC_CONTROL +
>> save->crtc[idx].offset);
>> + /* We need to disable all crtc as for some reason crtc scanout
>> +* base address does not happen properly when changing the
>> +* mc vram start address. Don't remove this or you will break
>> +* things on uefi system.
>> +*/
>> + save->crtc[idx].crtc_control = 0;
>> + save->crtc[idx].vga_control =
>> RREG32(save->crtc[idx].vga_control_offset);
>> +
>> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 1);
>> + WREG32(EVERGREEN_CRTC_CONTROL + save->crtc[idx].offset, 0);
>> + WREG32(save->crtc[idx].vga_control_offset, 0);
>> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 0);
>> +}
>> +
>> void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
>> *save)
>> {
>> - save->vga_control[0] = RREG32(D1VGA_CONTROL);
>> - save->vga_control[1] = RREG32(D2VGA_CONTROL);
>> + save->crtc[0].offset = EVERGREEN_CRTC0_REGISTER_OFFSET;
>> + save->crtc[1].offset = EVERGREEN_CRTC1_REGISTER_OFFSET;
>> + save->crtc[2].offset = EVERGREEN_CRTC2_REGISTER_OFFSET;
>> + save->crtc[3].offset = EVERGREEN_CRTC3_REGISTER_OFFSET;
>> + save->crtc[4].offset = EVERGREEN_CRTC4_REGISTER_OFFSET;
>> + save->crtc[5].offset = EVERGREEN_CRTC5_REGISTER_OFFSET;
>> + save->crtc[0].vga_control_offset = D1VGA_CONTROL;
>> + save->crtc[1].vga_control_offset = D2VGA_CONTROL;
>> + save->crtc[2].vga_control_offset = EVERGREEN_D3VGA_CONTROL;
>> + save->crtc[3].vga_control_offset = EVERGREEN_D4VGA_CONTROL;
>> + save->crtc[4].vga_control_offset = EVERGREEN_D5VGA_CONTROL;
>> + save->crtc[5].vga_control_offset = EVERGREEN_D6VGA_CONTROL;
>> +
>> + save->fb_address = (uint64_t)(RREG32(MC_VM_FB_LOCATION) & 0x) <<
>> 24ULL;
>> sa
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote: > On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti > wrote: > > The other missing bit is how to actually change the brightness... Alex, > > do you know what registers to poke? > > You need to check if the GPU controls the backlight or the system > does. I think the attached patches should point you in the right > direction. Yep :) 0050: ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability : 0050: (union) ATOM_FIRMWARE_CAPABILITY sbfAccess : USHORT GPUControlsBL:1 = 0x0001 (1) The panel is using the INTERNAL_UNIPHY encoder, and I see the UNIPHYTransmitterControl command table. Interaction with video.ko is still a bit messy... Do you already have code for handling the notifications? I'll work on it in the weekend otherwise ;) Luca
[PATCH] drm/radeon: cleanup and fix crtc while programming mc
On Thu, Jul 26, 2012 at 7:24 PM, wrote:
> From: Jerome Glisse
>
> When we change start address of vram for the GPU memory controller
> we need to make sure that nothing in the GPU still use the old vram
> address. This patch cleanup and fix crtc address.
>
> However there is still someissue somewhere if we reenable the crtc
> after updating the address at which they sancout. So to avoid any
> issue disable crtc. Once we want to do flicker less transition
> btw uefi and radeon we will probably want to revisit how we program
> the GPU memory controller.
>
> This probably fix :
> https://bugs.freedesktop.org/show_bug.cgi?id=52467
> https://bugs.freedesktop.org/show_bug.cgi?id=42373
>
> Cc:
this should be stable at vger.kernel.org
> Signed-off-by: Jerome Glisse
Also, I think we probably need to poll on bit 16
(CRTC_CURRENT_MASTER_EN_STATE) of CRTC_CONTROL to make sure the crtc
is actually disabled. Something like the following in mc_stop():
WREG32(CRTC_CONTROL, 0);
while (RREG32(CRTC_CONTROL & CRTC_CURRENT_MASTER_EN_STATE))
udelay(1);
Any chance you want to fix the rv515_mc_stop() and rv515_mc_resume()
functions as well?
Alex
> ---
> drivers/gpu/drm/radeon/evergreen.c | 178
> --
> drivers/gpu/drm/radeon/radeon_asic.h | 18 +++-
> 2 files changed, 99 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index e585a3b..c6ede66 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1227,70 +1227,94 @@ void evergreen_agp_enable(struct radeon_device *rdev)
> WREG32(VM_CONTEXT1_CNTL, 0);
> }
>
> +static void evergreen_crtc_save(struct radeon_device *rdev, struct
> evergreen_mc_save *save, unsigned idx)
> +{
> + save->crtc[idx].paddress = 0;
> + save->crtc[idx].saddress = 0;
> + save->crtc[idx].crtc_control = 0;
> +
> + if (idx >= rdev->num_crtc) {
> + /* it seems accessing non existant crtc trigger high latency
> */
> + return;
> + }
> +
> + save->crtc[idx].paddress =
> RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + save->crtc[idx].offset);
> + save->crtc[idx].paddress |=
> ((uint64_t)RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
> save->crtc[idx].offset)) << 32ULL;
> + save->crtc[idx].saddress =
> RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + save->crtc[idx].offset);
> + save->crtc[idx].saddress |=
> ((uint64_t)RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH +
> save->crtc[idx].offset)) << 32ULL;
> + save->crtc[idx].crtc_control = RREG32(EVERGREEN_CRTC_CONTROL +
> save->crtc[idx].offset);
> + /* We need to disable all crtc as for some reason crtc scanout
> +* base address does not happen properly when changing the
> +* mc vram start address. Don't remove this or you will break
> +* things on uefi system.
> +*/
> + save->crtc[idx].crtc_control = 0;
> + save->crtc[idx].vga_control =
> RREG32(save->crtc[idx].vga_control_offset);
> +
> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 1);
> + WREG32(EVERGREEN_CRTC_CONTROL + save->crtc[idx].offset, 0);
> + WREG32(save->crtc[idx].vga_control_offset, 0);
> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 0);
> +}
> +
> void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
> *save)
> {
> - save->vga_control[0] = RREG32(D1VGA_CONTROL);
> - save->vga_control[1] = RREG32(D2VGA_CONTROL);
> + save->crtc[0].offset = EVERGREEN_CRTC0_REGISTER_OFFSET;
> + save->crtc[1].offset = EVERGREEN_CRTC1_REGISTER_OFFSET;
> + save->crtc[2].offset = EVERGREEN_CRTC2_REGISTER_OFFSET;
> + save->crtc[3].offset = EVERGREEN_CRTC3_REGISTER_OFFSET;
> + save->crtc[4].offset = EVERGREEN_CRTC4_REGISTER_OFFSET;
> + save->crtc[5].offset = EVERGREEN_CRTC5_REGISTER_OFFSET;
> + save->crtc[0].vga_control_offset = D1VGA_CONTROL;
> + save->crtc[1].vga_control_offset = D2VGA_CONTROL;
> + save->crtc[2].vga_control_offset = EVERGREEN_D3VGA_CONTROL;
> + save->crtc[3].vga_control_offset = EVERGREEN_D4VGA_CONTROL;
> + save->crtc[4].vga_control_offset = EVERGREEN_D5VGA_CONTROL;
> + save->crtc[5].vga_control_offset = EVERGREEN_D6VGA_CONTROL;
> +
> + save->fb_address = (uint64_t)(RREG32(MC_VM_FB_LOCATION) & 0x) <<
> 24ULL;
> save->vga_render_control = RREG32(VGA_RENDER_CONTROL);
> save->vga_hdp_control = RREG32(VGA_HDP_CONTROL);
> - save->crtc_control[0] = RREG32(EVERGREEN_CRTC_CONTROL +
> EVERGREEN_CRTC0_REGISTER_OFFSET);
> - save->crtc_control[1] = RREG32(EVERGREEN_CRTC_CONTROL +
> EVERGREEN_CRTC1_REGISTER_OFFSET);
> - if (rdev->num_crtc >= 4) {
> - save->vga_control[2] = RREG32(EVERGREEN_D3VGA_CONTROL);
> - save->vga_control[3] = RREG32(EVERGREEN_D4VG
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote: > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到： >> - again ACPI video module gets the nodification (in this case >> ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE >> - KDE seems this and muck with the screen configuration :( >> - meanwhile the brightness notification is propagated, the >> hypothetical >> radeon driver does its magic to adjust the screen. >> >> My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to >> the >> acpi notifier chain, and allow the handlers to veto the key press >> (like >> it's done for ACPI_VIDEO_NOTIFY_SWITCH). > > I welcome this approach! > > On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when > AC-power unplug, because BIOS want to nodify video driver do some power > saving stuff. > It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power > unplug. > > At least acpi/video driver need to know this 0x81 event is filed by BIOS > to radeon-acpi for notify but not do video mode switch. That means the > radeon drm need take the video switch responsibility. Probably we'd just want the radeon acpi handler to just forward the events to userspace so that the user can choose what to do with it (xrandr command, etc.), otherwise we'll need to define policy in the driver. Alex > > > Thanks a lot! > Joey Lee > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel_audio_dump: add Haswell audio dump support
Add Haswell audio registers definition and dump support.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c | 574 +-
1 file changed, 571 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 8a0f6ee..231d0c6 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -94,6 +94,11 @@ static const char *dip_port[] = {
[3] = "Digital Port D",
};
+static const char *dip_type[] = {
+[0] = "Audio DIP Disabled",
+[1] = "Audio DIP Enabled",
+};
+
static const char *dip_index[] = {
[0] = "Audio DIP",
[1] = "ACP DIP",
@@ -126,9 +131,20 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = "no port",
[1] = "Digital Port B",
- [2] = "Digital Port C",
- [3] = "Digital Port D",
- [4] = "reserved",
+ [2] = "Digital Port B",
+ [3] = "Digital Port B",
+ [4] = "Digital Port B",
+ [5] = "reserved",
+ [6] = "reserved",
+ [7] = "reserved",
+};
+
+static const char *ddi_mode[] = {
+ [0] = "HDMI mode",
+ [1] = "DVI mode",
+ [2] = "DP SST mode",
+ [3] = "DP MST mode",
+ [4] = "DP FDI mode",
[5] = "reserved",
[6] = "reserved",
[7] = "reserved",
@@ -1354,6 +1370,553 @@ static void dump_cpt(void)
}
+#undef AUD_CONFIG_A
+#undef AUD_MISC_CTRL_A
+#undef AUD_VID_DID
+#undef AUD_RID
+#undef AUD_CTS_ENABLE_A
+#undef AUD_PWRST
+#undef AUD_HDMIW_HDMIEDID_A
+#undef AUD_HDMIW_INFOFR_A
+#undef AUD_PORT_EN_HD_CFG
+#undef AUD_OUT_DIG_CNVT_A
+#undef AUD_OUT_STR_DESC_A
+#undef AUD_OUT_CH_STR
+#undef AUD_PINW_CONNLNG_LIST
+#undef AUD_CNTL_ST_A
+#undef AUD_HDMIW_STATUS
+#undef AUD_CONFIG_B
+#undef AUD_MISC_CTRL_B
+#undef AUD_CTS_ENABLE_B
+#undef AUD_HDMIW_HDMIEDID_B
+#undef AUD_HDMIW_INFOFR_B
+#undef AUD_OUT_DIG_CNVT_B
+#undef AUD_OUT_STR_DESC_B
+#undef AUD_CNTL_ST_B
+
+/*Haswell registers*/
+
+/*DisplayPort Transport Control*/
+#define DP_TP_CTL_A0x64040
+#define DP_TP_CTL_B0x64140
+#define DP_TP_CTL_C0x64240
+#define DP_TP_CTL_D0x64340
+#define DP_TP_CTL_E0x64440
+
+/*DisplayPort Transport Status*/
+#define DP_TP_ST_A 0x64044
+#define DP_TP_ST_B 0x64144
+#define DP_TP_ST_C 0x64244
+#define DP_TP_ST_D 0x64344
+#define DP_TP_ST_E 0x6
+
+/*Transcoder configuration*/
+#define TRANS_CONF 0xF0008
+
+/*DDI Buffer Control*/
+#define DDI_BUF_CTL_A0x64000
+#define DDI_BUF_CTL_B0x64100
+#define DDI_BUF_CTL_C0x64200
+#define DDI_BUF_CTL_D0x64300
+#define DDI_BUF_CTL_E0x64400
+
+/*DDI Buffer Translation*/
+#define DDI_BUF_TRANS_A0x64e00
+#define DDI_BUF_TRANS_B0x64e60
+#define DDI_BUF_TRANS_C0x64ec0
+#define DDI_BUF_TRANS_D0x64f20
+#define DDI_BUF_TRANS_E0x64f80
+
+/*DDI Aux Channel*/
+#define DDI_AUX_CHANNEL_CTRL 0x64010
+#define DDI_AUX_DATA 0x64014
+#define DDI_AUX_TST0x64028
+
+/*DDI CRC Control*/
+#define DDI_CRC_CTL_A 0x64050
+#define DDI_CRC_CTL_B 0x64150
+#define DDI_CRC_CTL_C 0x64250
+#define DDI_CRC_CTL_D 0x64350
+#define DDI_CRC_CTL_E 0x64450
+
+/*Pipe DDI Function Control*/
+#define PIPE_DDI_FUNC_CTL_A 0x60400
+#define PIPE_DDI_FUNC_CTL_B 0x61400
+#define PIPE_DDI_FUNC_CTL_C 0x62400
+#define PIPE_DDI_FUNC_CTL_EDP 0x6F400
+
+/*Pipe Configuration*/
+#define PIPE_CONF_A0x70008
+#define PIPE_CONF_B0x71008
+#define PIPE_CONF_C0x72008
+#define PIPE_CONF_EDP 0x7F008
+
+/*Audio registers*/
+#define AUD_CONFIG_A 0x65000
+#define AUD_MISC_CTRL_A 0x65010
+#define AUD_VID_DID 0x65020
+#define AUD_RID 0x65024
+#define AUD_CTS_ENABLE_A 0x65028
+#define AUD_PWRST 0x6504C
+#define AUD_HDMIW_HDMIEDID_A 0x65050
+#define AUD_HDMIW_INFOFR_A0x65054
+#define AUD_PORT_EN_HD_CFG0x6507C
+#define AUD_OUT_DIG_CNVT_A0x65080
+#define AUD_OUT_STR_DESC_A0x65084
+#define AUD_OUT_CHAN_MAP 0x65088
+#define AUD_PINW_CONNLNG_LIST_A 0x650A8
+#define AUD_PINW_CONNLNG_LIST_B 0x651A8
+#define AUD_PINW_CONNLNG_LIST_C 0x652A8
+#define AUD_PIPE_CONN_SEL_CTRL 0x650AC
+#define AUD_PIN_ELD_CP_VLD0x650C0
+#define AUD_HDMIW_STATUS 0x650D4
+#define AUD_CONFIG_B 0x65100
+#define AUD_MISC_CTRL_B 0x65110
+#define AUD_CTS_ENABLE_B 0x65128
+#define AUD_HDMIW_HDMIEDID_B 0x65150
+#define AUD_HDMIW_INFOFR_B0x65154
+#define AUD_OUT_DIG_CNVT_B0x65180
+#define AUD_OUT_STR_DESC_B0x65184
+#define AUD_CONFIG_C 0x65200
+#define AUD_MISC_CTRL_C 0x65210
+#define AUD_CTS_ENABLE_C 0x65228
+#define AUD_HDMIW_HDMIEDID_C 0x65250
+#define AUD_HDMIW_INFOFR_C0x65254
+#define AUD_OUT_DIG_CNVT_C0x65280
+#define AUD_OUT_STR_DESC_C0x65
[PATCH] drm/radeon: cleanup and fix crtc while programming mc
From: Jerome Glisse
When we change start address of vram for the GPU memory controller
we need to make sure that nothing in the GPU still use the old vram
address. This patch cleanup and fix crtc address.
However there is still someissue somewhere if we reenable the crtc
after updating the address at which they sancout. So to avoid any
issue disable crtc. Once we want to do flicker less transition
btw uefi and radeon we will probably want to revisit how we program
the GPU memory controller.
This probably fix :
https://bugs.freedesktop.org/show_bug.cgi?id=52467
https://bugs.freedesktop.org/show_bug.cgi?id=42373
Cc:
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c | 178 --
drivers/gpu/drm/radeon/radeon_asic.h | 18 +++-
2 files changed, 99 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index e585a3b..c6ede66 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1227,70 +1227,94 @@ void evergreen_agp_enable(struct radeon_device *rdev)
WREG32(VM_CONTEXT1_CNTL, 0);
}
+static void evergreen_crtc_save(struct radeon_device *rdev, struct
evergreen_mc_save *save, unsigned idx)
+{
+ save->crtc[idx].paddress = 0;
+ save->crtc[idx].saddress = 0;
+ save->crtc[idx].crtc_control = 0;
+
+ if (idx >= rdev->num_crtc) {
+ /* it seems accessing non existant crtc trigger high latency */
+ return;
+ }
+
+ save->crtc[idx].paddress =
RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + save->crtc[idx].offset);
+ save->crtc[idx].paddress |=
((uint64_t)RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
save->crtc[idx].offset)) << 32ULL;
+ save->crtc[idx].saddress =
RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + save->crtc[idx].offset);
+ save->crtc[idx].saddress |=
((uint64_t)RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH +
save->crtc[idx].offset)) << 32ULL;
+ save->crtc[idx].crtc_control = RREG32(EVERGREEN_CRTC_CONTROL +
save->crtc[idx].offset);
+ /* We need to disable all crtc as for some reason crtc scanout
+* base address does not happen properly when changing the
+* mc vram start address. Don't remove this or you will break
+* things on uefi system.
+*/
+ save->crtc[idx].crtc_control = 0;
+ save->crtc[idx].vga_control =
RREG32(save->crtc[idx].vga_control_offset);
+
+ WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 1);
+ WREG32(EVERGREEN_CRTC_CONTROL + save->crtc[idx].offset, 0);
+ WREG32(save->crtc[idx].vga_control_offset, 0);
+ WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 0);
+}
+
void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
*save)
{
- save->vga_control[0] = RREG32(D1VGA_CONTROL);
- save->vga_control[1] = RREG32(D2VGA_CONTROL);
+ save->crtc[0].offset = EVERGREEN_CRTC0_REGISTER_OFFSET;
+ save->crtc[1].offset = EVERGREEN_CRTC1_REGISTER_OFFSET;
+ save->crtc[2].offset = EVERGREEN_CRTC2_REGISTER_OFFSET;
+ save->crtc[3].offset = EVERGREEN_CRTC3_REGISTER_OFFSET;
+ save->crtc[4].offset = EVERGREEN_CRTC4_REGISTER_OFFSET;
+ save->crtc[5].offset = EVERGREEN_CRTC5_REGISTER_OFFSET;
+ save->crtc[0].vga_control_offset = D1VGA_CONTROL;
+ save->crtc[1].vga_control_offset = D2VGA_CONTROL;
+ save->crtc[2].vga_control_offset = EVERGREEN_D3VGA_CONTROL;
+ save->crtc[3].vga_control_offset = EVERGREEN_D4VGA_CONTROL;
+ save->crtc[4].vga_control_offset = EVERGREEN_D5VGA_CONTROL;
+ save->crtc[5].vga_control_offset = EVERGREEN_D6VGA_CONTROL;
+
+ save->fb_address = (uint64_t)(RREG32(MC_VM_FB_LOCATION) & 0x) <<
24ULL;
save->vga_render_control = RREG32(VGA_RENDER_CONTROL);
save->vga_hdp_control = RREG32(VGA_HDP_CONTROL);
- save->crtc_control[0] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC0_REGISTER_OFFSET);
- save->crtc_control[1] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC1_REGISTER_OFFSET);
- if (rdev->num_crtc >= 4) {
- save->vga_control[2] = RREG32(EVERGREEN_D3VGA_CONTROL);
- save->vga_control[3] = RREG32(EVERGREEN_D4VGA_CONTROL);
- save->crtc_control[2] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC2_REGISTER_OFFSET);
- save->crtc_control[3] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC3_REGISTER_OFFSET);
- }
- if (rdev->num_crtc >= 6) {
- save->vga_control[4] = RREG32(EVERGREEN_D5VGA_CONTROL);
- save->vga_control[5] = RREG32(EVERGREEN_D6VGA_CONTROL);
- save->crtc_control[4] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC4_REGISTER_OFFSET);
- save->crtc_control[5] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC5_REGISTER_OFFSET);
- }
/* Stop all video *
Re: [PATCH] drm/radeon: cleanup and fix crtc while programming mc
On Thu, Jul 26, 2012 at 8:35 PM, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 7:24 PM, wrote:
>> From: Jerome Glisse
>>
>> When we change start address of vram for the GPU memory controller
>> we need to make sure that nothing in the GPU still use the old vram
>> address. This patch cleanup and fix crtc address.
>>
>> However there is still someissue somewhere if we reenable the crtc
>> after updating the address at which they sancout. So to avoid any
>> issue disable crtc. Once we want to do flicker less transition
>> btw uefi and radeon we will probably want to revisit how we program
>> the GPU memory controller.
>>
>> This probably fix :
>> https://bugs.freedesktop.org/show_bug.cgi?id=52467
>> https://bugs.freedesktop.org/show_bug.cgi?id=42373
>>
>> Cc:
>
> this should be sta...@vger.kernel.org
>
>> Signed-off-by: Jerome Glisse
>
> Also, I think we probably need to poll on bit 16
> (CRTC_CURRENT_MASTER_EN_STATE) of CRTC_CONTROL to make sure the crtc
> is actually disabled. Something like the following in mc_stop():
>
> WREG32(CRTC_CONTROL, 0);
> while (RREG32(CRTC_CONTROL & CRTC_CURRENT_MASTER_EN_STATE))
> udelay(1);
>
> Any chance you want to fix the rv515_mc_stop() and rv515_mc_resume()
> functions as well?
>
> Alex
I will respin with splitting out what fix and what just
improve/cleanup the code. I might change rv515 but i don't think it
will hit such issue, on rv515 crtc is enabled through VGA, here the
issue seems to only show up with uefi, i am trying to grab some non
uefi laptop with same gpu to check.
Cheers,
Jerome
>
>> ---
>> drivers/gpu/drm/radeon/evergreen.c | 178
>> --
>> drivers/gpu/drm/radeon/radeon_asic.h | 18 +++-
>> 2 files changed, 99 insertions(+), 97 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index e585a3b..c6ede66 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -1227,70 +1227,94 @@ void evergreen_agp_enable(struct radeon_device *rdev)
>> WREG32(VM_CONTEXT1_CNTL, 0);
>> }
>>
>> +static void evergreen_crtc_save(struct radeon_device *rdev, struct
>> evergreen_mc_save *save, unsigned idx)
>> +{
>> + save->crtc[idx].paddress = 0;
>> + save->crtc[idx].saddress = 0;
>> + save->crtc[idx].crtc_control = 0;
>> +
>> + if (idx >= rdev->num_crtc) {
>> + /* it seems accessing non existant crtc trigger high latency
>> */
>> + return;
>> + }
>> +
>> + save->crtc[idx].paddress =
>> RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + save->crtc[idx].offset);
>> + save->crtc[idx].paddress |=
>> ((uint64_t)RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
>> save->crtc[idx].offset)) << 32ULL;
>> + save->crtc[idx].saddress =
>> RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + save->crtc[idx].offset);
>> + save->crtc[idx].saddress |=
>> ((uint64_t)RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH +
>> save->crtc[idx].offset)) << 32ULL;
>> + save->crtc[idx].crtc_control = RREG32(EVERGREEN_CRTC_CONTROL +
>> save->crtc[idx].offset);
>> + /* We need to disable all crtc as for some reason crtc scanout
>> +* base address does not happen properly when changing the
>> +* mc vram start address. Don't remove this or you will break
>> +* things on uefi system.
>> +*/
>> + save->crtc[idx].crtc_control = 0;
>> + save->crtc[idx].vga_control =
>> RREG32(save->crtc[idx].vga_control_offset);
>> +
>> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 1);
>> + WREG32(EVERGREEN_CRTC_CONTROL + save->crtc[idx].offset, 0);
>> + WREG32(save->crtc[idx].vga_control_offset, 0);
>> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 0);
>> +}
>> +
>> void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
>> *save)
>> {
>> - save->vga_control[0] = RREG32(D1VGA_CONTROL);
>> - save->vga_control[1] = RREG32(D2VGA_CONTROL);
>> + save->crtc[0].offset = EVERGREEN_CRTC0_REGISTER_OFFSET;
>> + save->crtc[1].offset = EVERGREEN_CRTC1_REGISTER_OFFSET;
>> + save->crtc[2].offset = EVERGREEN_CRTC2_REGISTER_OFFSET;
>> + save->crtc[3].offset = EVERGREEN_CRTC3_REGISTER_OFFSET;
>> + save->crtc[4].offset = EVERGREEN_CRTC4_REGISTER_OFFSET;
>> + save->crtc[5].offset = EVERGREEN_CRTC5_REGISTER_OFFSET;
>> + save->crtc[0].vga_control_offset = D1VGA_CONTROL;
>> + save->crtc[1].vga_control_offset = D2VGA_CONTROL;
>> + save->crtc[2].vga_control_offset = EVERGREEN_D3VGA_CONTROL;
>> + save->crtc[3].vga_control_offset = EVERGREEN_D4VGA_CONTROL;
>> + save->crtc[4].vga_control_offset = EVERGREEN_D5VGA_CONTROL;
>> + save->crtc[5].vga_control_offset = EVERGREEN_D6VGA_CONTROL;
>> +
>> + save->fb_address = (uint64_t)(RREG32(MC_VM_FB_LOCATION) & 0x) <<
>> 24ULL;
>> save-
drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Gl?ck wrote: > On 25.07.2012 20:42, Marcin Slusarz wrote: > > Good, below patch should fix this panic. > > > > Note that you can hit an oops in drm_handle_vblank because patch from > > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html > > has not been applied (yet?). > > After applying your patch, it still crashes, although with a slightly > different stack trace. I then also applied the second patch, but that > doesn't make any difference. New log attached. > > Looks like interrupt occurs before nouveau_software_context_new() is > called? Shouldn't the initialization be done from > nouveau_irq_preinstall() so it is available when the irq occurs? Again, > I am not an expert here. Just guessing... I didn't look at it yet, but can you catch panic with maxcpus=1? Marcin
Re: [PATCH] drm/radeon: cleanup and fix crtc while programming mc
On Thu, Jul 26, 2012 at 7:24 PM, wrote:
> From: Jerome Glisse
>
> When we change start address of vram for the GPU memory controller
> we need to make sure that nothing in the GPU still use the old vram
> address. This patch cleanup and fix crtc address.
>
> However there is still someissue somewhere if we reenable the crtc
> after updating the address at which they sancout. So to avoid any
> issue disable crtc. Once we want to do flicker less transition
> btw uefi and radeon we will probably want to revisit how we program
> the GPU memory controller.
>
> This probably fix :
> https://bugs.freedesktop.org/show_bug.cgi?id=52467
> https://bugs.freedesktop.org/show_bug.cgi?id=42373
>
> Cc:
this should be sta...@vger.kernel.org
> Signed-off-by: Jerome Glisse
Also, I think we probably need to poll on bit 16
(CRTC_CURRENT_MASTER_EN_STATE) of CRTC_CONTROL to make sure the crtc
is actually disabled. Something like the following in mc_stop():
WREG32(CRTC_CONTROL, 0);
while (RREG32(CRTC_CONTROL & CRTC_CURRENT_MASTER_EN_STATE))
udelay(1);
Any chance you want to fix the rv515_mc_stop() and rv515_mc_resume()
functions as well?
Alex
> ---
> drivers/gpu/drm/radeon/evergreen.c | 178
> --
> drivers/gpu/drm/radeon/radeon_asic.h | 18 +++-
> 2 files changed, 99 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index e585a3b..c6ede66 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1227,70 +1227,94 @@ void evergreen_agp_enable(struct radeon_device *rdev)
> WREG32(VM_CONTEXT1_CNTL, 0);
> }
>
> +static void evergreen_crtc_save(struct radeon_device *rdev, struct
> evergreen_mc_save *save, unsigned idx)
> +{
> + save->crtc[idx].paddress = 0;
> + save->crtc[idx].saddress = 0;
> + save->crtc[idx].crtc_control = 0;
> +
> + if (idx >= rdev->num_crtc) {
> + /* it seems accessing non existant crtc trigger high latency
> */
> + return;
> + }
> +
> + save->crtc[idx].paddress =
> RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + save->crtc[idx].offset);
> + save->crtc[idx].paddress |=
> ((uint64_t)RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
> save->crtc[idx].offset)) << 32ULL;
> + save->crtc[idx].saddress =
> RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + save->crtc[idx].offset);
> + save->crtc[idx].saddress |=
> ((uint64_t)RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH +
> save->crtc[idx].offset)) << 32ULL;
> + save->crtc[idx].crtc_control = RREG32(EVERGREEN_CRTC_CONTROL +
> save->crtc[idx].offset);
> + /* We need to disable all crtc as for some reason crtc scanout
> +* base address does not happen properly when changing the
> +* mc vram start address. Don't remove this or you will break
> +* things on uefi system.
> +*/
> + save->crtc[idx].crtc_control = 0;
> + save->crtc[idx].vga_control =
> RREG32(save->crtc[idx].vga_control_offset);
> +
> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 1);
> + WREG32(EVERGREEN_CRTC_CONTROL + save->crtc[idx].offset, 0);
> + WREG32(save->crtc[idx].vga_control_offset, 0);
> + WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 0);
> +}
> +
> void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
> *save)
> {
> - save->vga_control[0] = RREG32(D1VGA_CONTROL);
> - save->vga_control[1] = RREG32(D2VGA_CONTROL);
> + save->crtc[0].offset = EVERGREEN_CRTC0_REGISTER_OFFSET;
> + save->crtc[1].offset = EVERGREEN_CRTC1_REGISTER_OFFSET;
> + save->crtc[2].offset = EVERGREEN_CRTC2_REGISTER_OFFSET;
> + save->crtc[3].offset = EVERGREEN_CRTC3_REGISTER_OFFSET;
> + save->crtc[4].offset = EVERGREEN_CRTC4_REGISTER_OFFSET;
> + save->crtc[5].offset = EVERGREEN_CRTC5_REGISTER_OFFSET;
> + save->crtc[0].vga_control_offset = D1VGA_CONTROL;
> + save->crtc[1].vga_control_offset = D2VGA_CONTROL;
> + save->crtc[2].vga_control_offset = EVERGREEN_D3VGA_CONTROL;
> + save->crtc[3].vga_control_offset = EVERGREEN_D4VGA_CONTROL;
> + save->crtc[4].vga_control_offset = EVERGREEN_D5VGA_CONTROL;
> + save->crtc[5].vga_control_offset = EVERGREEN_D6VGA_CONTROL;
> +
> + save->fb_address = (uint64_t)(RREG32(MC_VM_FB_LOCATION) & 0x) <<
> 24ULL;
> save->vga_render_control = RREG32(VGA_RENDER_CONTROL);
> save->vga_hdp_control = RREG32(VGA_HDP_CONTROL);
> - save->crtc_control[0] = RREG32(EVERGREEN_CRTC_CONTROL +
> EVERGREEN_CRTC0_REGISTER_OFFSET);
> - save->crtc_control[1] = RREG32(EVERGREEN_CRTC_CONTROL +
> EVERGREEN_CRTC1_REGISTER_OFFSET);
> - if (rdev->num_crtc >= 4) {
> - save->vga_control[2] = RREG32(EVERGREEN_D3VGA_CONTROL);
> - save->vga_control[3] = RREG32(EVERGREEN_D4VGA_C
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #16 from Jerome Glisse 2012-07-26 23:26:33 PDT --- Created attachment 64759 --> https://bugs.freedesktop.org/attachment.cgi?id=64759 Fixup mc programing This patch should fix your issue. -- 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 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #8 from Jerome Glisse 2012-07-26 23:25:59 PDT --- Created attachment 64758 --> https://bugs.freedesktop.org/attachment.cgi?id=64758 Cleanup and fix mc programing This patch should fix your issue -- 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
[PATCH] drm/radeon: cleanup and fix crtc while programming mc
From: Jerome Glisse
When we change start address of vram for the GPU memory controller
we need to make sure that nothing in the GPU still use the old vram
address. This patch cleanup and fix crtc address.
However there is still someissue somewhere if we reenable the crtc
after updating the address at which they sancout. So to avoid any
issue disable crtc. Once we want to do flicker less transition
btw uefi and radeon we will probably want to revisit how we program
the GPU memory controller.
This probably fix :
https://bugs.freedesktop.org/show_bug.cgi?id=52467
https://bugs.freedesktop.org/show_bug.cgi?id=42373
Cc:
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c | 178 --
drivers/gpu/drm/radeon/radeon_asic.h | 18 +++-
2 files changed, 99 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index e585a3b..c6ede66 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1227,70 +1227,94 @@ void evergreen_agp_enable(struct radeon_device *rdev)
WREG32(VM_CONTEXT1_CNTL, 0);
}
+static void evergreen_crtc_save(struct radeon_device *rdev, struct
evergreen_mc_save *save, unsigned idx)
+{
+ save->crtc[idx].paddress = 0;
+ save->crtc[idx].saddress = 0;
+ save->crtc[idx].crtc_control = 0;
+
+ if (idx >= rdev->num_crtc) {
+ /* it seems accessing non existant crtc trigger high latency */
+ return;
+ }
+
+ save->crtc[idx].paddress =
RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + save->crtc[idx].offset);
+ save->crtc[idx].paddress |=
((uint64_t)RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
save->crtc[idx].offset)) << 32ULL;
+ save->crtc[idx].saddress =
RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + save->crtc[idx].offset);
+ save->crtc[idx].saddress |=
((uint64_t)RREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH +
save->crtc[idx].offset)) << 32ULL;
+ save->crtc[idx].crtc_control = RREG32(EVERGREEN_CRTC_CONTROL +
save->crtc[idx].offset);
+ /* We need to disable all crtc as for some reason crtc scanout
+* base address does not happen properly when changing the
+* mc vram start address. Don't remove this or you will break
+* things on uefi system.
+*/
+ save->crtc[idx].crtc_control = 0;
+ save->crtc[idx].vga_control =
RREG32(save->crtc[idx].vga_control_offset);
+
+ WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 1);
+ WREG32(EVERGREEN_CRTC_CONTROL + save->crtc[idx].offset, 0);
+ WREG32(save->crtc[idx].vga_control_offset, 0);
+ WREG32(EVERGREEN_CRTC_UPDATE_LOCK + save->crtc[idx].offset, 0);
+}
+
void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
*save)
{
- save->vga_control[0] = RREG32(D1VGA_CONTROL);
- save->vga_control[1] = RREG32(D2VGA_CONTROL);
+ save->crtc[0].offset = EVERGREEN_CRTC0_REGISTER_OFFSET;
+ save->crtc[1].offset = EVERGREEN_CRTC1_REGISTER_OFFSET;
+ save->crtc[2].offset = EVERGREEN_CRTC2_REGISTER_OFFSET;
+ save->crtc[3].offset = EVERGREEN_CRTC3_REGISTER_OFFSET;
+ save->crtc[4].offset = EVERGREEN_CRTC4_REGISTER_OFFSET;
+ save->crtc[5].offset = EVERGREEN_CRTC5_REGISTER_OFFSET;
+ save->crtc[0].vga_control_offset = D1VGA_CONTROL;
+ save->crtc[1].vga_control_offset = D2VGA_CONTROL;
+ save->crtc[2].vga_control_offset = EVERGREEN_D3VGA_CONTROL;
+ save->crtc[3].vga_control_offset = EVERGREEN_D4VGA_CONTROL;
+ save->crtc[4].vga_control_offset = EVERGREEN_D5VGA_CONTROL;
+ save->crtc[5].vga_control_offset = EVERGREEN_D6VGA_CONTROL;
+
+ save->fb_address = (uint64_t)(RREG32(MC_VM_FB_LOCATION) & 0x) <<
24ULL;
save->vga_render_control = RREG32(VGA_RENDER_CONTROL);
save->vga_hdp_control = RREG32(VGA_HDP_CONTROL);
- save->crtc_control[0] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC0_REGISTER_OFFSET);
- save->crtc_control[1] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC1_REGISTER_OFFSET);
- if (rdev->num_crtc >= 4) {
- save->vga_control[2] = RREG32(EVERGREEN_D3VGA_CONTROL);
- save->vga_control[3] = RREG32(EVERGREEN_D4VGA_CONTROL);
- save->crtc_control[2] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC2_REGISTER_OFFSET);
- save->crtc_control[3] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC3_REGISTER_OFFSET);
- }
- if (rdev->num_crtc >= 6) {
- save->vga_control[4] = RREG32(EVERGREEN_D5VGA_CONTROL);
- save->vga_control[5] = RREG32(EVERGREEN_D6VGA_CONTROL);
- save->crtc_control[4] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC4_REGISTER_OFFSET);
- save->crtc_control[5] = RREG32(EVERGREEN_CRTC_CONTROL +
EVERGREEN_CRTC5_REGISTER_OFFSET);
- }
/* Stop all video
[PATCH] drm/radeon: properly handle crtc powergating
From: Alex Deucher
Need to make sure the crtc is gated on before modesetting.
Explicitly gate the crtc on in prepare() and set a flag
so that the dpms functions don't gate it off during
mode set.
Noticed by sylware on IRC.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 14 --
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4
drivers/gpu/drm/radeon/radeon_mode.h|1 +
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 9e6f76f..dc279eb 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -259,7 +259,7 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
/* adjust pm to dpms changes BEFORE enabling crtcs */
radeon_pm_compute_clocks(rdev);
/* disable crtc pair power gating before programming */
- if (ASIC_IS_DCE6(rdev))
+ if (ASIC_IS_DCE6(rdev) && !radeon_crtc->in_mode_set)
atombios_powergate_crtc(crtc, ATOM_DISABLE);
atombios_enable_crtc(crtc, ATOM_ENABLE);
if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev))
@@ -279,7 +279,7 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
atombios_enable_crtc(crtc, ATOM_DISABLE);
radeon_crtc->enabled = false;
/* power gating is per-pair */
- if (ASIC_IS_DCE6(rdev)) {
+ if (ASIC_IS_DCE6(rdev) && !radeon_crtc->in_mode_set) {
struct drm_crtc *other_crtc;
struct radeon_crtc *other_radeon_crtc;
list_for_each_entry(other_crtc,
&rdev->ddev->mode_config.crtc_list, head) {
@@ -1635,18 +1635,28 @@ static bool atombios_crtc_mode_fixup(struct drm_crtc
*crtc,
static void atombios_crtc_prepare(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+ struct drm_device *dev = crtc->dev;
+ struct radeon_device *rdev = dev->dev_private;
+ radeon_crtc->in_mode_set = true;
/* pick pll */
radeon_crtc->pll_id = radeon_atom_pick_pll(crtc);
+ /* disable crtc pair power gating before programming */
+ if (ASIC_IS_DCE6(rdev))
+ atombios_powergate_crtc(crtc, ATOM_DISABLE);
+
atombios_lock_crtc(crtc, ATOM_ENABLE);
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
}
static void atombios_crtc_commit(struct drm_crtc *crtc)
{
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
atombios_lock_crtc(crtc, ATOM_DISABLE);
+ radeon_crtc->in_mode_set = false;
}
static void atombios_crtc_disable(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index d5fd615..94b4a1c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -1025,9 +1025,11 @@ static int radeon_crtc_mode_set(struct drm_crtc *crtc,
static void radeon_crtc_prepare(struct drm_crtc *crtc)
{
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct drm_crtc *crtci;
+ radeon_crtc->in_mode_set = true;
/*
* The hardware wedges sometimes if you reconfigure one CRTC
* whilst another is running (see fdo bug #24611).
@@ -1038,6 +1040,7 @@ static void radeon_crtc_prepare(struct drm_crtc *crtc)
static void radeon_crtc_commit(struct drm_crtc *crtc)
{
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct drm_crtc *crtci;
@@ -1048,6 +1051,7 @@ static void radeon_crtc_commit(struct drm_crtc *crtc)
if (crtci->enabled)
radeon_crtc_dpms(crtci, DRM_MODE_DPMS_ON);
}
+ radeon_crtc->in_mode_set = false;
}
static const struct drm_crtc_helper_funcs legacy_helper_funcs = {
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 46d7801..8e1e168 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -288,6 +288,7 @@ struct radeon_crtc {
u16 lut_r[256], lut_g[256], lut_b[256];
bool enabled;
bool can_tile;
+ bool in_mode_set;
uint32_t crtc_offset;
struct drm_gem_object *cursor_bo;
uint64_t cursor_addr;
--
1.7.7.5
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 3:42 PM, Alex Deucher wrote: > On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti > wrote: >> On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote: >>> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti >>> wrote: >>> > The other missing bit is how to actually change the brightness... Alex, >>> > do you know what registers to poke? >>> >>> You need to check if the GPU controls the backlight or the system >>> does. I think the attached patches should point you in the right >>> direction. >> >> Yep :) >> >> 0050: ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability : >> 0050: (union) ATOM_FIRMWARE_CAPABILITY sbfAccess : >> USHORT GPUControlsBL:1 = 0x0001 (1) >> >> The panel is using the INTERNAL_UNIPHY encoder, and I see the >> UNIPHYTransmitterControl command table. >> >> Interaction with video.ko is still a bit messy... >> >> Do you already have code for handling the notifications? I'll work on it >> in the weekend otherwise ;) > > I don't have patches for that. Please feel free to work on it :) One thing worth checking, the sbios may write the requested backlight level to the bios scratch reg, in which case the driver only has to execute the BL_BRIGHTNESS action rather than writing the requested level to the register first. Alex > > Thanks, > > Alex
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti wrote: > On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote: >> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti >> wrote: >> > The other missing bit is how to actually change the brightness... Alex, >> > do you know what registers to poke? >> >> You need to check if the GPU controls the backlight or the system >> does. I think the attached patches should point you in the right >> direction. > > Yep :) > > 0050: ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability : > 0050: (union) ATOM_FIRMWARE_CAPABILITY sbfAccess : > USHORT GPUControlsBL:1 = 0x0001 (1) > > The panel is using the INTERNAL_UNIPHY encoder, and I see the > UNIPHYTransmitterControl command table. > > Interaction with video.ko is still a bit messy... > > Do you already have code for handling the notifications? I'll work on it > in the weekend otherwise ;) I don't have patches for that. Please feel free to work on it :) Thanks, Alex
[PATCH] intel_audio_dump: fix wrong port definition
there're three Ports B/C/D used for selection by each transcoder A/B/C.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 077e096..8a0f6ee 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -126,9 +126,9 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = "no port",
[1] = "Digital Port B",
- [2] = "Digital Port B",
- [3] = "Digital Port B",
- [4] = "Digital Port B",
+ [2] = "Digital Port C",
+ [3] = "Digital Port D",
+ [4] = "reserved",
[5] = "reserved",
[6] = "reserved",
[7] = "reserved",
--
1.7.9.5
[Bug 41265] KMS does not work on Radeon HD6700M
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #17 from Alex Deucher 2012-07-26 22:16:41 PDT --- Probably need to ask Sony where they store the discrete vbios on these systems. -- 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 52563] build failure - struct radeon_renderbuffer has no member named Base
https://bugs.freedesktop.org/show_bug.cgi?id=52563 U. Artie Eoff changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #2 from U. Artie Eoff 2012-07-26 22:08:37 PDT --- verified... thanks :) -- 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 41265] KMS does not work on Radeon HD6700M
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #16 from Ben Alex 2012-07-26 22:08:07 PDT --- As per comment #15, I also have an affected Sony Vaio Z Series (model SVZ13115GGXI). Anything logs/debugs/tests I can provide to assist resolve this issue? -- 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 52563] build failure - struct radeon_renderbuffer has no member named Base
https://bugs.freedesktop.org/show_bug.cgi?id=52563 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul 2012-07-26 21:58:21 PDT --- Just a typo. Fixed. -- 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
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> Add a new header that defines the AMD ACPI interface used
> for laptops, PowerXpress, and chipset specific functionality
> and update the current code to use it.
Great! Now my DSDT makes sense ;)
> Todo:
> - properly verify the ACPI interfaces
> - hook up and handle ACPI notifications
I see a problem here, I've hacked up a standalone test module, but:
> +#define ATIF_FUNCTION_GET_SYSTEM_PARAMETERS0x1
[...]
> + * flags
> + * bits 1:0:
> + * 0 - Notify(VGA, 0x81) is not used for notification
> + * 1 - Notify(VGA, 0x81) is used for notification
My system has this bit set, and the brightness control method does send
the notification.
My module register itself with register_acpi_notifier and gets 2
notifications, one with ACPI_VIDEO_NOTIFY_PROBE (0x81) and the other
with ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS (or DEC, depending on what I
press).
The standard acpi "video" module, however, in response to
ACPI_VIDEO_NOTIFY_PROBE generates a key press sending
KEY_SWITCHVIDEOMODE.
This greatly confuses KDE which messes up my dual screen configuration;
I guess that the spurious KEY_SWITCHVIDEOMODE may be problematic also
with other DEs...
In more detail what happens is the following:
- I press the brightness hotkey, firmware generates a notification on
the relevant device (_SB.PCI0.PEG0.VGA.LCD)
- ACPI video module gets the ACPI_VIDEO_NOTIFY_{DEC,INC}_BRIGHTNESS
notification and tries to adjust the brightness with
acpi_video_device_lcd_set_level, which in turns calls _BCM
- _BCM sets the relevant bits in the AMD-specific structure and does a
Notify (VGA, 0x81)
- again ACPI video module gets the nodification (in this case
ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
- KDE seems this and muck with the screen configuration :(
- meanwhile the brightness notification is propagated, the hypothetical
radeon driver does its magic to adjust the screen.
My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to the
acpi notifier chain, and allow the handlers to veto the key press (like
it's done for ACPI_VIDEO_NOTIFY_SWITCH).
Zhang Rui what do you think about this?
The other missing bit is how to actually change the brightness... Alex,
do you know what registers to poke?
My card is a:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
Thames XT/GL [Radeon HD 600M Series] [1002:6840]
on a Toshiba L855.
Luca
drm/nouveau: crash regression in 3.5
On 25.07.2012 20:42, Marcin Slusarz wrote: > Good, below patch should fix this panic. > > Note that you can hit an oops in drm_handle_vblank because patch from > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html > has not been applied (yet?). After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached. Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing... Thanks, Ortwin -- next part -- Initializing cgroup subsys cpu Linux version 3.5.0 (root at ortwin-hp) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #3 SMP PREEMPT Thu Jul 26 14:42:43 CEST 2012 Command line: root=/dev/sda5 rootfstype=ext4 pciehp_force=1 nouveau.modeset=1 nouveau.noaccel=1 netconsole= at 10.11.1.234/eth0, at 10.11.1.19/00:1a:64:89:71:b8 drm.debug=1 e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e-0x000f] reserved BIOS-e820: [mem 0x0010-0xbefc1fff] usable BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable BIOS-e820: [mem 0xbf80-0xbfff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved BIOS-e820: [mem 0xfec0-0xfec00fff] reserved BIOS-e820: [mem 0xfed1-0xfed13fff] reserved BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved BIOS-e820: [mem 0xfed1b000-0xfed1] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xffd0-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023bff] usable NX (Execute Disable) protection: active DMI 2.6 present. No AGP bridge found e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 init_memory_mapping: [mem 0x-0xbf7f] init_memory_mapping: [mem 0x1-0x23bff] ACPI: RSDP 000fddc0 00024 (v02 HPQOEM) ACPI: XSDT bf7fe120 00094 (v01 HPQOEM SLIC-MPC 000F 0113) ACPI: FACP bf7fc000 000F4 (v03 HPQOEM 1521 000F HP 0001) ACPI: DSDT bf7da000 1C77F (v02 HPQOEM 1521 0001 INTL 20060912) ACPI: FACS bf76 00040 ACPI: HPET bf7fb000 00038 (v01 HPQOEM 1521 0001 HP 0001) ACPI: APIC bf7fa000 000BC (v01 HPQOEM 1521 0001 HP 0001) ACPI: MCFG bf7f9000 0003C (v01 HPQOEM 1521 0001 HP 0001) ACPI: TCPA bf7f7000 00032 (v02 HPQOEM 1521 HP 0001) ACPI: SSDT bf7d7000 00135 (v01 HPQOEM SataAhci 1000 INTL 20060912) ACPI: SSDT bf7d6000 00314 (v01 HPQOEM PtidDevc 1000 INTL 20060912) ACPI: SLIC bf7d5000 00176 (v01 HPQOEM SLIC-MPC 0001 HP 0001) ACPI: SSDT bf7d1000 02576 (v01 HPQOEM NVIDIAGF 0001 INTL 20060912) ACPI: DMAR bf7d 00080 (v01 INTEL CP_DALE 0001 INTL 0001) ACPI: SSDT bf7cf000 00A10 (v01 PmRefCpuPm 3000 INTL 20060912) ACPI: SSDT bf7ce000 00288 (v01 PmRef Cpu0Tst 3000 INTL 20060912) ACPI: SSDT bf7cd000 00225 (v01 PmRefApTst 3000 INTL 20060912) ACPI: ASF! bf7f8000 000A0 (v32 HPQOEM 1521 0001 HP 0001) Zone ranges: DMA [mem 0x0001-0x00ff] DMA32[mem 0x0100-0x] Normal [mem 0x1-0x23bff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0001-0x0009efff] node 0: [mem 0x0010-0xbefc1fff] node 0: [mem 0xbf7ff000-0xbf7f] node 0: [mem 0x1-0x1fbff] node 0: [mem 0x2-0x23bff] ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi
[Bug 52549] New: libdrm 2.4.37 compilation fails if ETIME not defined
https://bugs.freedesktop.org/show_bug.cgi?id=52549 Bug #: 52549 Summary: libdrm 2.4.37 compilation fails if ETIME not defined Classification: Unclassified Product: DRI Version: XOrg CVS Platform: All OS/Version: BSD (Others) Status: NEW Severity: normal Priority: medium Component: libdrm AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: davshao at gmail.com For operating systems such as DragonFly BSD, ETIME may not be defined, let alone POSIX STREAMS implemented. libdrm 2.4.37 in current pkgsrc failed to compile on DragonFly BSD 3.1-DEVEL i386 and x86_64 until a patch was added to define ETIME if it was not already defined: ETIME is not defined on DragonFly BSD, work around it. --- intel/intel_bufmgr_gem.c.orig 2012-07-02 15:22:14.326942000 + +++ intel/intel_bufmgr_gem.c @@ -54,6 +54,9 @@ #include #include "errno.h" +#ifndef ETIME +#define ETIME ETIMEDOUT +#endif #include "libdrm_lists.h" #include "intel_bufmgr.h" #include "intel_bufmgr_priv.h" -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[REGRESSION] [KMS] [INTEL] Wrong resolution in console and XWindow
On Wed, Jul 25, 2012 at 01:55:59PM +0200, Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
> wrote:
> > On ?roda, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
> >> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
> >> > On ?roda, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> >> > > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> >> > > > Last known good: 3.4.4
> >> > > > First bad: 3.5.0
> >> > > >
> >> > > > When booting 3.5.0 resolution (in console, and after in KDE) is set
> >> > > > to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
> >> > >
> >> > > Can you please attach the output of xrandr --verbose for both kernels?
> >> > > Also, please boot with drm.debug=0xe added to your kernel cmdline and
> >> > > grab the dmesg (again for both kernels).
> >> >
> >> > Thanks for the ansfer.
> >> >
> >> > Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
> >> >
> >> > http://mrutecki.pl/download/kernel/3.5/swinka/debug/
> >>
> >> Can you please test this quick hack:
> >>
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> >> b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644
> >> --- a/drivers/gpu/drm/i915/intel_i2c.c
> >> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> >> @@ -405,7 +405,7 @@ clear_err:
> >>* timing out seems to happen when there _is_ a ddc chip present, but
> >>* it's slow responding and only answers on the 2nd retry.
> >>*/
> >> - ret = -ENXIO;
> >> + ret = 0;
> >> if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
> >>10)) {
> >> DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
> >>
> >>
> >> Thanks, Daniel
> >
> > Still the same.
>
> Hm, can you attach the dmesg again (with drm.debug=0xe)? If I haven't
> botched up something, we should now retry at least the ddc transfer
> ...
Also, another little snippet for you to test. Fyi I'll be on vacation next
week, so final patch (this one here should really work) might take a notch
longer.
Yours, Daniel
--
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index bc5e2c9..85eca1c 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -338,6 +338,7 @@ static bool intel_crt_detect_ddc(struct drm_connector
*connector)
BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
+ intel_gmbus_force_bit(i2c, true);
edid = drm_get_edid(connector, i2c);
if (edid) {
@@ -546,12 +547,14 @@ static int intel_crt_get_modes(struct drm_connector
*connector)
struct i2c_adapter *i2c;
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
+ intel_gmbus_force_bit(i2c, true);
ret = intel_ddc_get_modes(connector, i2c);
if (ret || !IS_G4X(dev))
return ret;
/* Try to probe digital port for output in DVI-I -> VGA mode. */
i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
+ intel_gmbus_force_bit(i2c, true);
return intel_ddc_get_modes(connector, i2c);
}
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[Bug 52563] New: build failure - struct radeon_renderbuffer has no member named Base
https://bugs.freedesktop.org/show_bug.cgi?id=52563 Bug #: 52563 Summary: build failure - struct radeon_renderbuffer has no member named Base Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ullysses.a.e...@intel.com mesa fails to compile with latest master commit as of http://cgit.freedesktop.org/mesa/mesa/commit/?id=0e893b42610a2e8f2797bd7da68669dac38d9538 using the following config setup: ./autogen.sh --enable-gles2 --disable-gallium-egl --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi error output is: radeon_span.c: In function 'radeon_renderbuffer_map': radeon_span.c:70:5: error: 'struct radeon_renderbuffer' has no member named 'Base' Last known good commit is http://cgit.freedesktop.org/mesa/mesa/commit/?id=148c8e639da7ee10fc9e002e3c6d60e17d218b21 -- 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 41265] KMS does not work on Radeon HD6700M
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #15 from Alexander E. Patrakov 2012-07-26 20:39:37 PDT --- I also have an affected Sony VAIO laptop, and the failure mode is the same: cannot read BIOS on the AMD card. Is there any debugging information that I can provide (from Windows or from Linux)? Is the BIOS even supposed to be readable? -- 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
[PATCH] drm/radeon: properly handle crtc powergating
From: Alex Deucher
Need to make sure the crtc is gated on before modesetting.
Explicitly gate the crtc on in prepare() and set a flag
so that the dpms functions don't gate it off during
mode set.
Noticed by sylware on IRC.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 14 --
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4
drivers/gpu/drm/radeon/radeon_mode.h|1 +
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 9e6f76f..dc279eb 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -259,7 +259,7 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
/* adjust pm to dpms changes BEFORE enabling crtcs */
radeon_pm_compute_clocks(rdev);
/* disable crtc pair power gating before programming */
- if (ASIC_IS_DCE6(rdev))
+ if (ASIC_IS_DCE6(rdev) && !radeon_crtc->in_mode_set)
atombios_powergate_crtc(crtc, ATOM_DISABLE);
atombios_enable_crtc(crtc, ATOM_ENABLE);
if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev))
@@ -279,7 +279,7 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
atombios_enable_crtc(crtc, ATOM_DISABLE);
radeon_crtc->enabled = false;
/* power gating is per-pair */
- if (ASIC_IS_DCE6(rdev)) {
+ if (ASIC_IS_DCE6(rdev) && !radeon_crtc->in_mode_set) {
struct drm_crtc *other_crtc;
struct radeon_crtc *other_radeon_crtc;
list_for_each_entry(other_crtc,
&rdev->ddev->mode_config.crtc_list, head) {
@@ -1635,18 +1635,28 @@ static bool atombios_crtc_mode_fixup(struct drm_crtc
*crtc,
static void atombios_crtc_prepare(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+ struct drm_device *dev = crtc->dev;
+ struct radeon_device *rdev = dev->dev_private;
+ radeon_crtc->in_mode_set = true;
/* pick pll */
radeon_crtc->pll_id = radeon_atom_pick_pll(crtc);
+ /* disable crtc pair power gating before programming */
+ if (ASIC_IS_DCE6(rdev))
+ atombios_powergate_crtc(crtc, ATOM_DISABLE);
+
atombios_lock_crtc(crtc, ATOM_ENABLE);
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
}
static void atombios_crtc_commit(struct drm_crtc *crtc)
{
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
atombios_lock_crtc(crtc, ATOM_DISABLE);
+ radeon_crtc->in_mode_set = false;
}
static void atombios_crtc_disable(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index d5fd615..94b4a1c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -1025,9 +1025,11 @@ static int radeon_crtc_mode_set(struct drm_crtc *crtc,
static void radeon_crtc_prepare(struct drm_crtc *crtc)
{
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct drm_crtc *crtci;
+ radeon_crtc->in_mode_set = true;
/*
* The hardware wedges sometimes if you reconfigure one CRTC
* whilst another is running (see fdo bug #24611).
@@ -1038,6 +1040,7 @@ static void radeon_crtc_prepare(struct drm_crtc *crtc)
static void radeon_crtc_commit(struct drm_crtc *crtc)
{
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct drm_crtc *crtci;
@@ -1048,6 +1051,7 @@ static void radeon_crtc_commit(struct drm_crtc *crtc)
if (crtci->enabled)
radeon_crtc_dpms(crtci, DRM_MODE_DPMS_ON);
}
+ radeon_crtc->in_mode_set = false;
}
static const struct drm_crtc_helper_funcs legacy_helper_funcs = {
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 46d7801..8e1e168 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -288,6 +288,7 @@ struct radeon_crtc {
u16 lut_r[256], lut_g[256], lut_b[256];
bool enabled;
bool can_tile;
+ bool in_mode_set;
uint32_t crtc_offset;
struct drm_gem_object *cursor_bo;
uint64_t cursor_addr;
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52560] New: Xorg -configure creats useless xorg.conf for tdfx
https://bugs.freedesktop.org/show_bug.cgi?id=52560 Bug #: 52560 Summary: Xorg -configure creats useless xorg.conf for tdfx Classification: Unclassified Product: DRI Version: XOrg CVS Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: tuxra...@hispeed.ch Had want to install my old Voodoo3/2000 PCI that 2 or 3 years ago perfectly work. Now on actual xorg-server at least 1.10 1.11 1.12 I really unable to configure a working 3D. If i use the driver without any xorg.conf I can use at least Software-Rendering. But if i create a xorg.conf using Xorg -configure it gives no 3D. On old xorg-servers the only thing i had to do for 3D on this card was to set the resolution to 1024x768 at 16bit colordepth and it worked. -- 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
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 3:42 PM, Alex Deucher wrote: > On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti wrote: >> On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote: >>> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti >>> wrote: >>> > The other missing bit is how to actually change the brightness... Alex, >>> > do you know what registers to poke? >>> >>> You need to check if the GPU controls the backlight or the system >>> does. I think the attached patches should point you in the right >>> direction. >> >> Yep :) >> >> 0050: ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability : >> 0050: (union) ATOM_FIRMWARE_CAPABILITY sbfAccess : >> USHORT GPUControlsBL:1 = 0x0001 (1) >> >> The panel is using the INTERNAL_UNIPHY encoder, and I see the >> UNIPHYTransmitterControl command table. >> >> Interaction with video.ko is still a bit messy... >> >> Do you already have code for handling the notifications? I'll work on it >> in the weekend otherwise ;) > > I don't have patches for that. Please feel free to work on it :) One thing worth checking, the sbios may write the requested backlight level to the bios scratch reg, in which case the driver only has to execute the BL_BRIGHTNESS action rather than writing the requested level to the register first. Alex > > Thanks, > > Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel_audio_dump: fix wrong port definition
there're three Ports B/C/D used for selection by each transcoder A/B/C.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 077e096..8a0f6ee 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -126,9 +126,9 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = "no port",
[1] = "Digital Port B",
- [2] = "Digital Port B",
- [3] = "Digital Port B",
- [4] = "Digital Port B",
+ [2] = "Digital Port C",
+ [3] = "Digital Port D",
+ [4] = "reserved",
[5] = "reserved",
[6] = "reserved",
[7] = "reserved",
--
1.7.9.5
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti wrote: > On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote: >> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti wrote: >> > The other missing bit is how to actually change the brightness... Alex, >> > do you know what registers to poke? >> >> You need to check if the GPU controls the backlight or the system >> does. I think the attached patches should point you in the right >> direction. > > Yep :) > > 0050: ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability : > 0050: (union) ATOM_FIRMWARE_CAPABILITY sbfAccess : > USHORT GPUControlsBL:1 = 0x0001 (1) > > The panel is using the INTERNAL_UNIPHY encoder, and I see the > UNIPHYTransmitterControl command table. > > Interaction with video.ko is still a bit messy... > > Do you already have code for handling the notifications? I'll work on it > in the weekend otherwise ;) I don't have patches for that. Please feel free to work on it :) Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote: > On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti wrote: > > The other missing bit is how to actually change the brightness... Alex, > > do you know what registers to poke? > > You need to check if the GPU controls the backlight or the system > does. I think the attached patches should point you in the right > direction. Yep :) 0050: ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability : 0050: (union) ATOM_FIRMWARE_CAPABILITY sbfAccess : USHORT GPUControlsBL:1 = 0x0001 (1) The panel is using the INTERNAL_UNIPHY encoder, and I see the UNIPHYTransmitterControl command table. Interaction with video.ko is still a bit messy... Do you already have code for handling the notifications? I'll work on it in the weekend otherwise ;) Luca ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #14 from Alexandre Demers 2012-07-26 05:33:08 PDT --- May well be the same as bug 42373. I'll try to find a way to dig this following 42373 repro steps. -- 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: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti wrote:
> On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeucher at gmail.com wrote:
>> From: Alex Deucher
>>
>> Add a new header that defines the AMD ACPI interface used
>> for laptops, PowerXpress, and chipset specific functionality
>> and update the current code to use it.
>
> Great! Now my DSDT makes sense ;)
>
>> Todo:
>> - properly verify the ACPI interfaces
>> - hook up and handle ACPI notifications
>
> I see a problem here, I've hacked up a standalone test module, but:
>
>> +#define ATIF_FUNCTION_GET_SYSTEM_PARAMETERS0x1
> [...]
>> + * flags
>> + * bits 1:0:
>> + * 0 - Notify(VGA, 0x81) is not used for notification
>> + * 1 - Notify(VGA, 0x81) is used for notification
>
> My system has this bit set, and the brightness control method does send
> the notification.
> My module register itself with register_acpi_notifier and gets 2
> notifications, one with ACPI_VIDEO_NOTIFY_PROBE (0x81) and the other
> with ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS (or DEC, depending on what I
> press).
>
> The standard acpi "video" module, however, in response to
> ACPI_VIDEO_NOTIFY_PROBE generates a key press sending
> KEY_SWITCHVIDEOMODE.
>
> This greatly confuses KDE which messes up my dual screen configuration;
> I guess that the spurious KEY_SWITCHVIDEOMODE may be problematic also
> with other DEs...
>
> In more detail what happens is the following:
> - I press the brightness hotkey, firmware generates a notification on
> the relevant device (_SB.PCI0.PEG0.VGA.LCD)
> - ACPI video module gets the ACPI_VIDEO_NOTIFY_{DEC,INC}_BRIGHTNESS
> notification and tries to adjust the brightness with
> acpi_video_device_lcd_set_level, which in turns calls _BCM
> - _BCM sets the relevant bits in the AMD-specific structure and does a
> Notify (VGA, 0x81)
> - again ACPI video module gets the nodification (in this case
> ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
> - KDE seems this and muck with the screen configuration :(
> - meanwhile the brightness notification is propagated, the hypothetical
> radeon driver does its magic to adjust the screen.
>
> My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to the
> acpi notifier chain, and allow the handlers to veto the key press (like
> it's done for ACPI_VIDEO_NOTIFY_SWITCH).
>
> Zhang Rui what do you think about this?
>
> The other missing bit is how to actually change the brightness... Alex,
> do you know what registers to poke?
You need to check if the GPU controls the backlight or the system
does. I think the attached patches should point you in the right
direction.
Alex
>
> My card is a:
>
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee
> ATI Thames XT/GL [Radeon HD 600M Series] [1002:6840]
>
> on a Toshiba L855.
>
> Luca
-- next part --
A non-text attachment was scrubbed...
Name: 0003-drm-radeon-add-backlight-control-for-atom-devices.patch
Type: text/x-patch
Size: 10962 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120726/6ae6d243/attachment-0003.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-rework-legacy-backlight-control.patch
Type: text/x-patch
Size: 3442 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120726/6ae6d243/attachment-0004.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-track-whether-the-GPU-controls-the-backli.patch
Type: text/x-patch
Size: 1651 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120726/6ae6d243/attachment-0005.bin>
[PATCH] i915: Remove silly test
On Wed, Jul 25, 2012 at 01:51:20PM +0100, Alan Cox wrote: > From: Alan Cox > > drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful > than a chocolate teapot. > > Possibly we should be testing bus != NULL each iteration of the loop > instead ? > > gcc could help by warning too! > > Signed-off-by: Alan Cox All three patches merged for -fixes, thanks. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Re: drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: > On 25.07.2012 20:42, Marcin Slusarz wrote: > > Good, below patch should fix this panic. > > > > Note that you can hit an oops in drm_handle_vblank because patch from > > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html > > has not been applied (yet?). > > After applying your patch, it still crashes, although with a slightly > different stack trace. I then also applied the second patch, but that > doesn't make any difference. New log attached. > > Looks like interrupt occurs before nouveau_software_context_new() is > called? Shouldn't the initialization be done from > nouveau_irq_preinstall() so it is available when the irq occurs? Again, > I am not an expert here. Just guessing... I didn't look at it yet, but can you catch panic with maxcpus=1? Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti wrote:
> On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeuc...@gmail.com wrote:
>> From: Alex Deucher
>>
>> Add a new header that defines the AMD ACPI interface used
>> for laptops, PowerXpress, and chipset specific functionality
>> and update the current code to use it.
>
> Great! Now my DSDT makes sense ;)
>
>> Todo:
>> - properly verify the ACPI interfaces
>> - hook up and handle ACPI notifications
>
> I see a problem here, I've hacked up a standalone test module, but:
>
>> +#define ATIF_FUNCTION_GET_SYSTEM_PARAMETERS0x1
> [...]
>> + * flags
>> + * bits 1:0:
>> + * 0 - Notify(VGA, 0x81) is not used for notification
>> + * 1 - Notify(VGA, 0x81) is used for notification
>
> My system has this bit set, and the brightness control method does send
> the notification.
> My module register itself with register_acpi_notifier and gets 2
> notifications, one with ACPI_VIDEO_NOTIFY_PROBE (0x81) and the other
> with ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS (or DEC, depending on what I
> press).
>
> The standard acpi "video" module, however, in response to
> ACPI_VIDEO_NOTIFY_PROBE generates a key press sending
> KEY_SWITCHVIDEOMODE.
>
> This greatly confuses KDE which messes up my dual screen configuration;
> I guess that the spurious KEY_SWITCHVIDEOMODE may be problematic also
> with other DEs...
>
> In more detail what happens is the following:
> - I press the brightness hotkey, firmware generates a notification on
> the relevant device (_SB.PCI0.PEG0.VGA.LCD)
> - ACPI video module gets the ACPI_VIDEO_NOTIFY_{DEC,INC}_BRIGHTNESS
> notification and tries to adjust the brightness with
> acpi_video_device_lcd_set_level, which in turns calls _BCM
> - _BCM sets the relevant bits in the AMD-specific structure and does a
> Notify (VGA, 0x81)
> - again ACPI video module gets the nodification (in this case
> ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
> - KDE seems this and muck with the screen configuration :(
> - meanwhile the brightness notification is propagated, the hypothetical
> radeon driver does its magic to adjust the screen.
>
> My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to the
> acpi notifier chain, and allow the handlers to veto the key press (like
> it's done for ACPI_VIDEO_NOTIFY_SWITCH).
>
> Zhang Rui what do you think about this?
>
> The other missing bit is how to actually change the brightness... Alex,
> do you know what registers to poke?
You need to check if the GPU controls the backlight or the system
does. I think the attached patches should point you in the right
direction.
Alex
>
> My card is a:
>
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee
> ATI Thames XT/GL [Radeon HD 600M Series] [1002:6840]
>
> on a Toshiba L855.
>
> Luca
From 31f6dff07ecb4cf092292345405b2151c98f0504 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 26 Jul 2012 11:32:03 -0400
Subject: [PATCH 3/3] drm/radeon: add backlight control for atom devices
On systems that use the build in GPU backlight controller,
we can use atom tables to change the brightness level.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 231
drivers/gpu/drm/radeon/radeon_connectors.c | 15 --
drivers/gpu/drm/radeon/radeon_encoders.c | 18 ++-
3 files changed, 248 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index 7dfc62f..60c86ce 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -28,9 +28,238 @@
#include "radeon_drm.h"
#include "radeon.h"
#include "atom.h"
+#include
extern int atom_debug;
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+
+static u8
+radeon_atom_get_backlight_level_from_reg(struct radeon_device *rdev)
+{
+ u8 backlight_level;
+ u32 bios_2_scratch;
+
+ if (rdev->family >= CHIP_R600)
+ bios_2_scratch = RREG32(R600_BIOS_2_SCRATCH);
+ else
+ bios_2_scratch = RREG32(RADEON_BIOS_2_SCRATCH);
+
+ backlight_level = ((bios_2_scratch & ATOM_S2_CURRENT_BL_LEVEL_MASK) >>
+ ATOM_S2_CURRENT_BL_LEVEL_SHIFT);
+
+ return backlight_level;
+}
+
+static void
+radeon_atom_set_backlight_level_to_reg(struct radeon_device *rdev,
+ u8 backlight_level)
+{
+ u32 bios_2_scratch;
+
+ if (rdev->family >= CHIP_R600)
+ bios_2_scratch = RREG32(R600_BIOS_2_SCRATCH);
+ else
+ bios_2_scratch = RREG32(RADEON_BIOS_2_SCRATCH);
+
+ bios_2_scratch &= ~ATOM_S2_CURRENT_BL_LEVEL_MASK;
+ bios_2_scratch |= ((backlight_level << ATOM_S2_CURRENT_BL_LEVEL_SHIFT) &
+ ATOM_S2_CURRENT_BL_LEVEL_MASK);
+
+ if (rdev->family >= CHIP_R600)
+ WREG32(R600_BIOS_2_SCRATCH, bios_2_scratch);
+ else
+ WREG32(RADEON_BIOS_2_SCRATCH, bios_2_scratch);
+}
+
+static void
+atombios_set_panel_brightness(struct radeon_encoder *radeon_encoder)
+{
+ struct drm_e
[Bug 52549] New: libdrm 2.4.37 compilation fails if ETIME not defined
https://bugs.freedesktop.org/show_bug.cgi?id=52549 Bug #: 52549 Summary: libdrm 2.4.37 compilation fails if ETIME not defined Classification: Unclassified Product: DRI Version: XOrg CVS Platform: All OS/Version: BSD (Others) Status: NEW Severity: normal Priority: medium Component: libdrm AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: davs...@gmail.com For operating systems such as DragonFly BSD, ETIME may not be defined, let alone POSIX STREAMS implemented. libdrm 2.4.37 in current pkgsrc failed to compile on DragonFly BSD 3.1-DEVEL i386 and x86_64 until a patch was added to define ETIME if it was not already defined: ETIME is not defined on DragonFly BSD, work around it. --- intel/intel_bufmgr_gem.c.orig 2012-07-02 15:22:14.326942000 + +++ intel/intel_bufmgr_gem.c @@ -54,6 +54,9 @@ #include #include "errno.h" +#ifndef ETIME +#define ETIME ETIMEDOUT +#endif #include "libdrm_lists.h" #include "intel_bufmgr.h" #include "intel_bufmgr_priv.h" -- 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
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Add a new header that defines the AMD ACPI interface used
> for laptops, PowerXpress, and chipset specific functionality
> and update the current code to use it.
Great! Now my DSDT makes sense ;)
> Todo:
> - properly verify the ACPI interfaces
> - hook up and handle ACPI notifications
I see a problem here, I've hacked up a standalone test module, but:
> +#define ATIF_FUNCTION_GET_SYSTEM_PARAMETERS0x1
[...]
> + * flags
> + * bits 1:0:
> + * 0 - Notify(VGA, 0x81) is not used for notification
> + * 1 - Notify(VGA, 0x81) is used for notification
My system has this bit set, and the brightness control method does send
the notification.
My module register itself with register_acpi_notifier and gets 2
notifications, one with ACPI_VIDEO_NOTIFY_PROBE (0x81) and the other
with ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS (or DEC, depending on what I
press).
The standard acpi "video" module, however, in response to
ACPI_VIDEO_NOTIFY_PROBE generates a key press sending
KEY_SWITCHVIDEOMODE.
This greatly confuses KDE which messes up my dual screen configuration;
I guess that the spurious KEY_SWITCHVIDEOMODE may be problematic also
with other DEs...
In more detail what happens is the following:
- I press the brightness hotkey, firmware generates a notification on
the relevant device (_SB.PCI0.PEG0.VGA.LCD)
- ACPI video module gets the ACPI_VIDEO_NOTIFY_{DEC,INC}_BRIGHTNESS
notification and tries to adjust the brightness with
acpi_video_device_lcd_set_level, which in turns calls _BCM
- _BCM sets the relevant bits in the AMD-specific structure and does a
Notify (VGA, 0x81)
- again ACPI video module gets the nodification (in this case
ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
- KDE seems this and muck with the screen configuration :(
- meanwhile the brightness notification is propagated, the hypothetical
radeon driver does its magic to adjust the screen.
My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to the
acpi notifier chain, and allow the handlers to veto the key press (like
it's done for ACPI_VIDEO_NOTIFY_SWITCH).
Zhang Rui what do you think about this?
The other missing bit is how to actually change the brightness... Alex,
do you know what registers to poke?
My card is a:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
Thames XT/GL [Radeon HD 600M Series] [1002:6840]
on a Toshiba L855.
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel_audio_dump: add Haswell audio dump support
Add Haswell audio registers definition and dump support.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c | 574 +-
1 file changed, 571 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 8a0f6ee..231d0c6 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -94,6 +94,11 @@ static const char *dip_port[] = {
[3] = "Digital Port D",
};
+static const char *dip_type[] = {
+[0] = "Audio DIP Disabled",
+[1] = "Audio DIP Enabled",
+};
+
static const char *dip_index[] = {
[0] = "Audio DIP",
[1] = "ACP DIP",
@@ -126,9 +131,20 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = "no port",
[1] = "Digital Port B",
- [2] = "Digital Port C",
- [3] = "Digital Port D",
- [4] = "reserved",
+ [2] = "Digital Port B",
+ [3] = "Digital Port B",
+ [4] = "Digital Port B",
+ [5] = "reserved",
+ [6] = "reserved",
+ [7] = "reserved",
+};
+
+static const char *ddi_mode[] = {
+ [0] = "HDMI mode",
+ [1] = "DVI mode",
+ [2] = "DP SST mode",
+ [3] = "DP MST mode",
+ [4] = "DP FDI mode",
[5] = "reserved",
[6] = "reserved",
[7] = "reserved",
@@ -1354,6 +1370,553 @@ static void dump_cpt(void)
}
+#undef AUD_CONFIG_A
+#undef AUD_MISC_CTRL_A
+#undef AUD_VID_DID
+#undef AUD_RID
+#undef AUD_CTS_ENABLE_A
+#undef AUD_PWRST
+#undef AUD_HDMIW_HDMIEDID_A
+#undef AUD_HDMIW_INFOFR_A
+#undef AUD_PORT_EN_HD_CFG
+#undef AUD_OUT_DIG_CNVT_A
+#undef AUD_OUT_STR_DESC_A
+#undef AUD_OUT_CH_STR
+#undef AUD_PINW_CONNLNG_LIST
+#undef AUD_CNTL_ST_A
+#undef AUD_HDMIW_STATUS
+#undef AUD_CONFIG_B
+#undef AUD_MISC_CTRL_B
+#undef AUD_CTS_ENABLE_B
+#undef AUD_HDMIW_HDMIEDID_B
+#undef AUD_HDMIW_INFOFR_B
+#undef AUD_OUT_DIG_CNVT_B
+#undef AUD_OUT_STR_DESC_B
+#undef AUD_CNTL_ST_B
+
+/*Haswell registers*/
+
+/*DisplayPort Transport Control*/
+#define DP_TP_CTL_A0x64040
+#define DP_TP_CTL_B0x64140
+#define DP_TP_CTL_C0x64240
+#define DP_TP_CTL_D0x64340
+#define DP_TP_CTL_E0x64440
+
+/*DisplayPort Transport Status*/
+#define DP_TP_ST_A 0x64044
+#define DP_TP_ST_B 0x64144
+#define DP_TP_ST_C 0x64244
+#define DP_TP_ST_D 0x64344
+#define DP_TP_ST_E 0x6
+
+/*Transcoder configuration*/
+#define TRANS_CONF 0xF0008
+
+/*DDI Buffer Control*/
+#define DDI_BUF_CTL_A0x64000
+#define DDI_BUF_CTL_B0x64100
+#define DDI_BUF_CTL_C0x64200
+#define DDI_BUF_CTL_D0x64300
+#define DDI_BUF_CTL_E0x64400
+
+/*DDI Buffer Translation*/
+#define DDI_BUF_TRANS_A0x64e00
+#define DDI_BUF_TRANS_B0x64e60
+#define DDI_BUF_TRANS_C0x64ec0
+#define DDI_BUF_TRANS_D0x64f20
+#define DDI_BUF_TRANS_E0x64f80
+
+/*DDI Aux Channel*/
+#define DDI_AUX_CHANNEL_CTRL 0x64010
+#define DDI_AUX_DATA 0x64014
+#define DDI_AUX_TST0x64028
+
+/*DDI CRC Control*/
+#define DDI_CRC_CTL_A 0x64050
+#define DDI_CRC_CTL_B 0x64150
+#define DDI_CRC_CTL_C 0x64250
+#define DDI_CRC_CTL_D 0x64350
+#define DDI_CRC_CTL_E 0x64450
+
+/*Pipe DDI Function Control*/
+#define PIPE_DDI_FUNC_CTL_A 0x60400
+#define PIPE_DDI_FUNC_CTL_B 0x61400
+#define PIPE_DDI_FUNC_CTL_C 0x62400
+#define PIPE_DDI_FUNC_CTL_EDP 0x6F400
+
+/*Pipe Configuration*/
+#define PIPE_CONF_A0x70008
+#define PIPE_CONF_B0x71008
+#define PIPE_CONF_C0x72008
+#define PIPE_CONF_EDP 0x7F008
+
+/*Audio registers*/
+#define AUD_CONFIG_A 0x65000
+#define AUD_MISC_CTRL_A 0x65010
+#define AUD_VID_DID 0x65020
+#define AUD_RID 0x65024
+#define AUD_CTS_ENABLE_A 0x65028
+#define AUD_PWRST 0x6504C
+#define AUD_HDMIW_HDMIEDID_A 0x65050
+#define AUD_HDMIW_INFOFR_A0x65054
+#define AUD_PORT_EN_HD_CFG0x6507C
+#define AUD_OUT_DIG_CNVT_A0x65080
+#define AUD_OUT_STR_DESC_A0x65084
+#define AUD_OUT_CHAN_MAP 0x65088
+#define AUD_PINW_CONNLNG_LIST_A 0x650A8
+#define AUD_PINW_CONNLNG_LIST_B 0x651A8
+#define AUD_PINW_CONNLNG_LIST_C 0x652A8
+#define AUD_PIPE_CONN_SEL_CTRL 0x650AC
+#define AUD_PIN_ELD_CP_VLD0x650C0
+#define AUD_HDMIW_STATUS 0x650D4
+#define AUD_CONFIG_B 0x65100
+#define AUD_MISC_CTRL_B 0x65110
+#define AUD_CTS_ENABLE_B 0x65128
+#define AUD_HDMIW_HDMIEDID_B 0x65150
+#define AUD_HDMIW_INFOFR_B0x65154
+#define AUD_OUT_DIG_CNVT_B0x65180
+#define AUD_OUT_STR_DESC_B0x65184
+#define AUD_CONFIG_C 0x65200
+#define AUD_MISC_CTRL_C 0x65210
+#define AUD_CTS_ENABLE_C 0x65228
+#define AUD_HDMIW_HDMIEDID_C 0x65250
+#define AUD_HDMIW_INFOFR_C0x65254
+#define AUD_OUT_DIG_CNVT_C0x65280
+#define AUD_OUT_STR_DESC_C0
Re: [REGRESSION] [KMS] [INTEL] Wrong resolution in console and XWindow
On Wed, Jul 25, 2012 at 01:55:59PM +0200, Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
> wrote:
> > On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
> >> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
> >> > On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> >> > > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> >> > > > Last known good: 3.4.4
> >> > > > First bad: 3.5.0
> >> > > >
> >> > > > When booting 3.5.0 resolution (in console, and after in KDE) is set
> >> > > > to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
> >> > >
> >> > > Can you please attach the output of xrandr --verbose for both kernels?
> >> > > Also, please boot with drm.debug=0xe added to your kernel cmdline and
> >> > > grab the dmesg (again for both kernels).
> >> >
> >> > Thanks for the ansfer.
> >> >
> >> > Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
> >> >
> >> > http://mrutecki.pl/download/kernel/3.5/swinka/debug/
> >>
> >> Can you please test this quick hack:
> >>
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> >> b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644
> >> --- a/drivers/gpu/drm/i915/intel_i2c.c
> >> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> >> @@ -405,7 +405,7 @@ clear_err:
> >>* timing out seems to happen when there _is_ a ddc chip present, but
> >>* it's slow responding and only answers on the 2nd retry.
> >>*/
> >> - ret = -ENXIO;
> >> + ret = 0;
> >> if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
> >>10)) {
> >> DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
> >>
> >>
> >> Thanks, Daniel
> >
> > Still the same.
>
> Hm, can you attach the dmesg again (with drm.debug=0xe)? If I haven't
> botched up something, we should now retry at least the ddc transfer
> ...
Also, another little snippet for you to test. Fyi I'll be on vacation next
week, so final patch (this one here should really work) might take a notch
longer.
Yours, Daniel
--
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index bc5e2c9..85eca1c 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -338,6 +338,7 @@ static bool intel_crt_detect_ddc(struct drm_connector
*connector)
BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
+ intel_gmbus_force_bit(i2c, true);
edid = drm_get_edid(connector, i2c);
if (edid) {
@@ -546,12 +547,14 @@ static int intel_crt_get_modes(struct drm_connector
*connector)
struct i2c_adapter *i2c;
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
+ intel_gmbus_force_bit(i2c, true);
ret = intel_ddc_get_modes(connector, i2c);
if (ret || !IS_G4X(dev))
return ret;
/* Try to probe digital port for output in DVI-I -> VGA mode. */
i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
+ intel_gmbus_force_bit(i2c, true);
return intel_ddc_get_modes(connector, i2c);
}
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel_audio_dump: fix wrong port definition
there're three Ports B/C/D used for selection by each transcoder A/B/C.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 077e096..8a0f6ee 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -126,9 +126,9 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = "no port",
[1] = "Digital Port B",
- [2] = "Digital Port B",
- [3] = "Digital Port B",
- [4] = "Digital Port B",
+ [2] = "Digital Port C",
+ [3] = "Digital Port D",
+ [4] = "reserved",
[5] = "reserved",
[6] = "reserved",
[7] = "reserved",
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X? It happens long before X, when the nouveau module is loaded. Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)? nouveau.noaccel=1 is already on my cmdline as running X with accel enabled never worked anyway. > Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log? Thanks for the netconsole tip. I have attached the log. I am not an expert but it looks like a crash in the inlined nouveau_software_vblank(). Is the vblank.list already initialized at this point? Thanks, Ortwin Initializing cgroup subsys cpu Linux version 3.5.0 (root@ortwin-hp) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #2 SMP PREEMPT Wed Jul 25 09:39:45 CEST 2012 Command line: root=/dev/sda5 rootfstype=ext4 pciehp_force=1 nouveau.modeset=1 nouveau.noaccel=1 netconsole=@10.11.1.234/eth0,@10.11.1.19/00:1a:64:89:71:b8 e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e-0x000f] reserved BIOS-e820: [mem 0x0010-0xbefc1fff] usable BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable BIOS-e820: [mem 0xbf80-0xbfff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved BIOS-e820: [mem 0xfec0-0xfec00fff] reserved BIOS-e820: [mem 0xfed1-0xfed13fff] reserved BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved BIOS-e820: [mem 0xfed1b000-0xfed1] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xffd0-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023bff] usable NX (Execute Disable) protection: active DMI 2.6 present. No AGP bridge found e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 init_memory_mapping: [mem 0x-0xbf7f] init_memory_mapping: [mem 0x1-0x23bff] ACPI: RSDP 000fddc0 00024 (v02 HPQOEM) ACPI: XSDT bf7fe120 00094 (v01 HPQOEM SLIC-MPC 000F 0113) ACPI: FACP bf7fc000 000F4 (v03 HPQOEM 1521 000F HP 0001) ACPI: DSDT bf7da000 1C77F (v02 HPQOEM 1521 0001 INTL 20060912) ACPI: FACS bf76 00040 ACPI: HPET bf7fb000 00038 (v01 HPQOEM 1521 0001 HP 0001) ACPI: APIC bf7fa000 000BC (v01 HPQOEM 1521 0001 HP 0001) ACPI: MCFG bf7f9000 0003C (v01 HPQOEM 1521 0001 HP 0001) ACPI: TCPA bf7f7000 00032 (v02 HPQOEM 1521 HP 0001) ACPI: SSDT bf7d7000 00135 (v01 HPQOEM SataAhci 1000 INTL 20060912) ACPI: SSDT bf7d6000 00314 (v01 HPQOEM PtidDevc 1000 INTL 20060912) ACPI: SLIC bf7d5000 00176 (v01 HPQOEM SLIC-MPC 0001 HP 0001) ACPI: SSDT bf7d1000 02576 (v01 HPQOEM NVIDIAGF 0001 INTL 20060912) ACPI: DMAR bf7d 00080 (v01 INTEL CP_DALE 0001 INTL 0001) ACPI: SSDT bf7cf000 00A10 (v01 PmRefCpuPm 3000 INTL 20060912) ACPI: SSDT bf7ce000 00288 (v01 PmRef Cpu0Tst 3000 INTL 20060912) ACPI: SSDT bf7cd000 00225 (v01 PmRefApTst 3000 INTL 20060912) ACPI: ASF! bf7f8000 000A0 (v32 HPQOEM 1521 0001 HP 0001) Zone ranges: DMA [mem 0x0001-0x00ff] DMA32[mem 0x0100-0x] Normal [mem 0x1-0x23bff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0001-0x0009efff] node 0: [mem 0x0010-0xbefc1fff] node 0: [mem 0xbf7ff000-0xbf7f] node 0: [mem 0x1-0x1fbff] node 0: [mem 0x2-0x23bff] ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge
Re: drm/nouveau: crash regression in 3.5
On 24.07.2012 19:00, Marcin Slusarz wrote: Please post the crash log. Sorry, I was not precise: it boots until drm performs modesetting (so it seems). The screen goes black and the machine is dead. So there is nothing I could post here, unfortunately. This is a video of 3.5 booting: http://www.odi.ch/VIDEO0010.3gp Don't worry about the external monitor: same behaviour with the built-in panel. Thanks, Ortwin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm tree for v3.6-rc1
Hi Linus, one of the smaller drm -next pulls in ages! Ben (nouveau) has a rewrite in progress but we decided to leave it stew for another cycle, so just some fixes from him. radeon: lots of documentation work, fixes, more ring and locking changes, pcie gen2, more dp fixes, i915: haswell features, gpu reset fixes, /dev/agpgart removal on machines that we never used it on, more VGA/HDP fix., more DP fixes drm core: cleanups from Daniel, sis 64-bit fixes, range allocator colouring. but yeah fairly quiet merge this time, probably because I missed half of it! Dave. The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c: Linux 3.5-rc7 (2012-07-14 15:40:28 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-next for you to fetch changes up to 98c7b42375011ec37251e6fc85a0471cfe499eea: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-07-26 10:40:31 +1000) Alex Deucher (18): drm/radeon: clean up CS functions in r100.c drm/radeon: move r100_enable_bm to a more logic place drm/radeon: update ib_execute for SI (v2) drm/radeon: remove radeon_ring_index() drm/radeon: update rptr saving logic for memory buffers drm/radeon: add rptr save support for r1xx-r5xx drm/radeon: document radeon_device.c (v2) drm/radeon: document radeon_kms.c drm/radeon: document radeon_irq_kms.c drm/radeon: document radeon_asic.c drm/radeon: document radeon_fence.c (v2) drm/radeon: document radeon_ring.c (v4) drm/radeon: document non-VM functions in radeon_gart.c (v2) drm/radeon: document VM functions in radeon_gart.c (v3) drm/radeon: start to document the functions r100.c drm/radeon: start to document evergreen.c drm/radeon: fix up pll selection on DCE5/6 drm/radeon: fix SS setup for DCPLL Ander Conselvan de Oliveira (1): drm/i915: mask tiled bit when updating ILK sprites Ben Skeggs (5): drm/nouveau: dcb table quirk for fdo#50830 drm/nouveau/gem: fix object reference leak in a failure path drm/nouveau: move current gpuobj code out of nouveau_object.c drm/nouveau: mark most of our ioctls as deprecated, move to compat layer drm/nv50: extend vblank semaphore to generic dmaobj + offset pair Ben Widawsky (29): drm/i915: timeout parameter for seqno wait drm/i915: improve i915_wait_request_begin trace drm/i915: wait render timeout ioctl drm/i915: s/i915_wait_request/i915_wait_seqno/g drm/i915: Dynamic Parity Detection handling drm/i915: enable parity error interrupts drm/i915: remap l3 on hw init drm/i915: l3 parity sysfs interface drm/i915: Inifite timeout for wait ioctl drm/i915: Add wait render timeout get param drm/i915: CXT_SIZE register offsets added drm/i915: preliminary context support drm/i915: context basic create & destroy drm/i915: context switch implementation drm/i915: Ivybridge MI_ARB_ON_OFF context w/a drm/i915: PIPE_CONTROL_TLB_INVALIDATE drm/i915: possibly invalidate TLB before context switch drm/i915: use the default context drm/i915: add ccid to error state drm/i915: switch to default context on idle drm/i915/context: create & destroy ioctls drm/i915/context: switch contexts with execbuf2 drm/i915: reset the GPU on context fini drm/i915: disable contexts on old HW drm/i915: set IDICOS to medium uncore resources drm/i915: linuxify create_hw_context() drm/i915/context/: s/CTX/CXT drm/i915/context: Add missing IVB context sizes drm/i915: missing error case in init status page Chris Wilson (18): drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4 drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x drm/i915/hdmi: Query the live connector status bit for G4x drm/i915/dp: For consistency use the DP hotplug synonyms drm/i915/hdmi: Fix reg values for g4x_hdmi_connected drm/i915: Switch off FBC when disabling the primary plane when obscured drm/i915: Group the GT routines together in both code and vtable drm/i915: Implement w/a for sporadic read failures on waking from rc6 drm: Add colouring to the range allocator drm/i915: Only request PM interrupts for the events we handled drm/i915: Disable the BLT on pre-production SNB hardware drm/i915: Add comments to explain the BSD tail write workaround drm/i915: Insert a flush between batches if the breadcrumb was dropped drm/i915: Make the lock for pageflips interruptible drm/i915: Flush the context object from the CPU caches upon switching drm/i915: Add -EIO
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 sowadski at miner.mst.edu changed: What|Removed |Added Version|XOrg CVS|unspecified -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #7 from sowadski at miner.mst.edu 2012-07-25 20:39:10 PDT --- Possible duplicate of BUG 42373? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #6 from sowadski at miner.mst.edu 2012-07-25 20:24:04 PDT --- I am not using grub2, so I do not believe that the workaround in BUG 43655 are relevant. I do not have these lines in my grub.conf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] i915: Remove silly test
On Wed, Jul 25, 2012 at 01:51:20PM +0100, Alan Cox wrote: > From: Alan Cox > > drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful > than a chocolate teapot. > > Possibly we should be testing bus != NULL each iteration of the loop > instead ? > > gcc could help by warning too! > > Signed-off-by: Alan Cox All three patches merged for -fixes, thanks. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #68 from Alexandre Demers 2012-07-25 18:11:54 PDT --- I was thinking about it yesterday: is it possible that we are not tracking something in the virtual addresse spaces that we should be? That could explain why we are getting messages like "radeon :01:00.0: bo 880212cb7000 va 0x00C26000 conflict with (bo 880222cc9400 0x00C26000 0x00C27000)" and so on. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] intel_audio_dump: fix wrong port definition
there're three Ports B/C/D used for selection by each transcoder A/B/C.
Signed-off-by: Wang Xingchao
---
tools/intel_audio_dump.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 077e096..8a0f6ee 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -126,9 +126,9 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = "no port",
[1] = "Digital Port B",
- [2] = "Digital Port B",
- [3] = "Digital Port B",
- [4] = "Digital Port B",
+ [2] = "Digital Port C",
+ [3] = "Digital Port D",
+ [4] = "reserved",
[5] = "reserved",
[6] = "reserved",
[7] = "reserved",
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
