[Bug 56541] Sony VAIO VPCZ23A4R: Oops or panic on radeon in error path
https://bugzilla.kernel.org/show_bug.cgi?id=56541 Alexander E. Patrakov changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #2 from Alexander E. Patrakov 2013-04-13 07:43:18 --- Yes, the issue is fixed. Thanks! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Latest randconfig build errors
On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren wrote: > >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of >> `__mod_of_device_table' >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of >> `__mod_of_device_table' >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of >> `__mod_of_device_table' >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > > Rob, I assume you'll do a patch for this one? oh, I apologize for the late reply, I didn't see this email... There is a patch that we can merge to make tilcdc bool instead of tristate[1], which I suppose is ok for a temporary fix. Although I'm all-ears if someone has a better idea about how to fix this. The problem is that we have multiple sub-devices for different possible panel drivers, so that depending on DT tables, the correct ones get loaded for the hw. But they are all built into a single module. Splitting them into multiple modules will be problematic, as panel drivers which are present really need to get probed before the toplevel drm device.. I suppose in theory it is possible to make drm cope better with dynamically loaded outputs, but I'm not sure that there is any way to do this without breaking userspace which expects that all of the connectors/encoders are present once the drm device is loaded. BR, -R [1] https://patchwork.kernel.org/patch/2376061/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]
On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote: > Hi, > > the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling > drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(), > which in case of i915 DRM driver effectively calls > intel_get_load_detect_pipe() that tries to lock crtc->mutex again. > This causes a deadlock, and can be in some cases triggered by VT > switch to framebuffer console on i915. > > This bug is introduced in Linux 3.9-rc1 and still exists > in v3.9-rc6-183-gbf81710. Linux 3.8 is ok. In Dave's drm-fixes branch: commit 89ced125472b8551c65526934b7f6c733a6864fa Author: Daniel Vetter Date: Thu Apr 11 14:26:55 2013 + drm/fb-helper: Fix locking in drm_fb_helper_hotplug_event Driver's and ->fill_modes functions are allowed to grab crtc mutexes (for e.g. load detect). Hence we need to first only grab the general kms mutex, and only in a second step grab all locks to do the modesets. This prevents a deadlock on my gm45 in the tv load detect code called by drm_helper_probe_single_connector_modes. Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Latest randconfig build errors
On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote: > On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren wrote: > > > >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of > >> `__mod_of_device_table' > >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of > >> `__mod_of_device_table' > >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of > >> `__mod_of_device_table' > >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > > > > Rob, I assume you'll do a patch for this one? > > > oh, I apologize for the late reply, I didn't see this email... > > There is a patch that we can merge to make tilcdc bool instead of > tristate[1], which I suppose is ok for a temporary fix. Although I'm > all-ears if someone has a better idea about how to fix this. The > problem is that we have multiple sub-devices for different possible > panel drivers, so that depending on DT tables, the correct ones get > loaded for the hw. But they are all built into a single module. > Splitting them into multiple modules will be problematic, as panel > drivers which are present really need to get probed before the > toplevel drm device.. You could look at the Tegra driver. I had to solve a similar problem there. What I did is basically parse the DT in the host1x driver and add all device nodes which are required by DRM to a list. Later when the individual devices are probed they are removed from that list, so that when the list becomes empty we are sure that all required devices are there and only then call the drm_platform_init() function. This fits very well with how Tegra hardware is designed because host1x is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is probed before any of its children and it can easily parse the DT upfront and initialize the list of required devices. > I suppose in theory it is possible to make drm > cope better with dynamically loaded outputs, but I'm not sure that > there is any way to do this without breaking userspace which expects > that all of the connectors/encoders are present once the drm device is > loaded. I had been thinking about this on and off for a while, but I haven't come up with anything concrete. Ideally we could just have some kind of event that userspace would listen for, so that new outputs can be dynamically added and userspace informed about them. Last time I checked most of the helpers assumed that the complete output configuration is known when the DRM device is registered, so some major rework will be required to efficiently make use of such dynamicity. Thierry pgpMpLUUqSDMZ.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/radeon: minor HDMI improvements
I've managed to track fglrx operations on HDMI regs, so we can finally setup everything in (hopefully) the correct way and order. This changes HDMI setup on Evergreen to mostly match fglrx and was tested on: 1) AMD Radeon HD 6320 (PALM == DCE41) 2) AMD Radeon HD 6970M (BARTS == DCE5) No regressions noticed, I can still play audio, including LPCM, AC3 and DTS. Unfortunately I don't have any DCE4 hardware to test this, but that changes shouldn't cause any regressions. I hope that with such improvements we will finally able to enable audio by default. Rafał Miłecki (6): drm/radeon: add helpers for masking and setting bits in regs drm/radeon: remove HDMI interrupts on Evergreen drm/radeon: add some HDMI comments drm/radeon/evergreen: setup HDMI before enabling it drm/radeon/evergreen: reorder HDMI setup drm/radeon/evergreen: write default channel numbers drivers/gpu/drm/radeon/evergreen.c | 127 +-- drivers/gpu/drm/radeon/evergreen_hdmi.c | 77 +++ drivers/gpu/drm/radeon/evergreend.h |1 + drivers/gpu/drm/radeon/r600_hdmi.c | 16 ++-- drivers/gpu/drm/radeon/radeon.h |2 + drivers/gpu/drm/radeon/radeon_display.c |5 ++ 6 files changed, 76 insertions(+), 152 deletions(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/radeon: add helpers for masking and setting bits in regs
Signed-off-by: Rafał Miłecki
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/r600_hdmi.c | 16 ++--
drivers/gpu/drm/radeon/radeon.h|2 ++
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 21ecc0e..91582a5 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -437,17 +437,15 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
hdmi = HDMI0_ERROR_ACK | HDMI0_ENABLE;
switch (radeon_encoder->encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
- WREG32_P(AVIVO_TMDSA_CNTL, AVIVO_TMDSA_CNTL_HDMI_EN,
-~AVIVO_TMDSA_CNTL_HDMI_EN);
+ WREG32_OR(AVIVO_TMDSA_CNTL, AVIVO_TMDSA_CNTL_HDMI_EN);
hdmi |= HDMI0_STREAM(HDMI0_STREAM_TMDSA);
break;
case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
- WREG32_P(AVIVO_LVTMA_CNTL, AVIVO_LVTMA_CNTL_HDMI_EN,
-~AVIVO_LVTMA_CNTL_HDMI_EN);
+ WREG32_OR(AVIVO_LVTMA_CNTL, AVIVO_LVTMA_CNTL_HDMI_EN);
hdmi |= HDMI0_STREAM(HDMI0_STREAM_LVTMA);
break;
case ENCODER_OBJECT_ID_INTERNAL_DDI:
- WREG32_P(DDIA_CNTL, DDIA_HDMI_EN, ~DDIA_HDMI_EN);
+ WREG32_OR(DDIA_CNTL, DDIA_HDMI_EN);
hdmi |= HDMI0_STREAM(HDMI0_STREAM_DDIA);
break;
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
@@ -504,15 +502,13 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
if (rdev->family >= CHIP_R600 && !ASIC_IS_DCE3(rdev)) {
switch (radeon_encoder->encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
- WREG32_P(AVIVO_TMDSA_CNTL, 0,
-~AVIVO_TMDSA_CNTL_HDMI_EN);
+ WREG32_AND(AVIVO_TMDSA_CNTL, ~AVIVO_TMDSA_CNTL_HDMI_EN);
break;
case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
- WREG32_P(AVIVO_LVTMA_CNTL, 0,
-~AVIVO_LVTMA_CNTL_HDMI_EN);
+ WREG32_AND(AVIVO_LVTMA_CNTL, ~AVIVO_LVTMA_CNTL_HDMI_EN);
break;
case ENCODER_OBJECT_ID_INTERNAL_DDI:
- WREG32_P(DDIA_CNTL, 0, ~DDIA_HDMI_EN);
+ WREG32_AND(DDIA_CNTL, ~DDIA_HDMI_EN);
break;
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
break;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8263af3..1f4559b 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1697,6 +1697,8 @@ void r100_io_wreg(struct radeon_device *rdev, u32 reg,
u32 v);
tmp_ |= ((val) & ~(mask)); \
WREG32(reg, tmp_); \
} while (0)
+#define WREG32_AND(reg, and) WREG32_P(reg, 0, and)
+#define WREG32_OR(reg, or) WREG32_P(reg, or, ~or)
#define WREG32_PLL_P(reg, val, mask) \
do {\
uint32_t tmp_ = RREG32_PLL(reg);\
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/radeon: remove HDMI interrupts on Evergreen
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio info manually.
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/evergreen.c | 127 +---
1 file changed, 1 insertion(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..34d4347 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2702,7 +2702,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
u32 hpd1, hpd2, hpd3, hpd4, hpd5, hpd6;
u32 grbm_int_cntl = 0;
u32 grph1 = 0, grph2 = 0, grph3 = 0, grph4 = 0, grph5 = 0, grph6 = 0;
- u32 afmt1 = 0, afmt2 = 0, afmt3 = 0, afmt4 = 0, afmt5 = 0, afmt6 = 0;
u32 dma_cntl, dma_cntl1 = 0;
if (!rdev->irq.installed) {
@@ -2724,13 +2723,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
hpd5 = RREG32(DC_HPD5_INT_CONTROL) & ~DC_HPDx_INT_EN;
hpd6 = RREG32(DC_HPD6_INT_CONTROL) & ~DC_HPDx_INT_EN;
- afmt1 = RREG32(AFMT_AUDIO_PACKET_CONTROL +
EVERGREEN_CRTC0_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
- afmt2 = RREG32(AFMT_AUDIO_PACKET_CONTROL +
EVERGREEN_CRTC1_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
- afmt3 = RREG32(AFMT_AUDIO_PACKET_CONTROL +
EVERGREEN_CRTC2_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
- afmt4 = RREG32(AFMT_AUDIO_PACKET_CONTROL +
EVERGREEN_CRTC3_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
- afmt5 = RREG32(AFMT_AUDIO_PACKET_CONTROL +
EVERGREEN_CRTC4_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
- afmt6 = RREG32(AFMT_AUDIO_PACKET_CONTROL +
EVERGREEN_CRTC5_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
-
dma_cntl = RREG32(DMA_CNTL) & ~TRAP_ENABLE;
if (rdev->family >= CHIP_CAYMAN) {
@@ -2822,30 +2814,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
DRM_DEBUG("evergreen_irq_set: hpd 6\n");
hpd6 |= DC_HPDx_INT_EN;
}
- if (rdev->irq.afmt[0]) {
- DRM_DEBUG("evergreen_irq_set: hdmi 0\n");
- afmt1 |= AFMT_AZ_FORMAT_WTRIG_MASK;
- }
- if (rdev->irq.afmt[1]) {
- DRM_DEBUG("evergreen_irq_set: hdmi 1\n");
- afmt2 |= AFMT_AZ_FORMAT_WTRIG_MASK;
- }
- if (rdev->irq.afmt[2]) {
- DRM_DEBUG("evergreen_irq_set: hdmi 2\n");
- afmt3 |= AFMT_AZ_FORMAT_WTRIG_MASK;
- }
- if (rdev->irq.afmt[3]) {
- DRM_DEBUG("evergreen_irq_set: hdmi 3\n");
- afmt4 |= AFMT_AZ_FORMAT_WTRIG_MASK;
- }
- if (rdev->irq.afmt[4]) {
- DRM_DEBUG("evergreen_irq_set: hdmi 4\n");
- afmt5 |= AFMT_AZ_FORMAT_WTRIG_MASK;
- }
- if (rdev->irq.afmt[5]) {
- DRM_DEBUG("evergreen_irq_set: hdmi 5\n");
- afmt6 |= AFMT_AZ_FORMAT_WTRIG_MASK;
- }
if (rdev->family >= CHIP_CAYMAN) {
cayman_cp_int_cntl_setup(rdev, 0, cp_int_cntl);
@@ -2890,13 +2858,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, hpd5);
WREG32(DC_HPD6_INT_CONTROL, hpd6);
- WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET,
afmt1);
- WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET,
afmt2);
- WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET,
afmt3);
- WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET,
afmt4);
- WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET,
afmt5);
- WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET,
afmt6);
-
return 0;
}
@@ -2921,13 +2882,6 @@ static void evergreen_irq_ack(struct radeon_device *rdev)
rdev->irq.stat_regs.evergreen.d6grph_int =
RREG32(GRPH_INT_STATUS + EVERGREEN_CRTC5_REGISTER_OFFSET);
}
- rdev->irq.stat_regs.evergreen.afmt_status1 = RREG32(AFMT_STATUS +
EVERGREEN_CRTC0_REGISTER_OFFSET);
- rdev->irq.stat_regs.evergreen.afmt_status2 = RREG32(AFMT_STATUS +
EVERGREEN_CRTC1_REGISTER_OFFSET);
- rdev->irq.stat_regs.evergreen.afmt_status3 = RREG32(AFMT_STATUS +
EVERGREEN_CRTC2_REGISTER_OFFSET);
- rdev->irq.stat_regs.evergreen.afmt_status4 = RREG32(AFMT_STATUS +
EVERGREEN_CRTC3_REGISTER_OFFSET);
- rdev->irq.stat_regs.evergreen.afmt_status5 = RREG32(AFMT_STATUS +
EVERGREEN_CRTC4_REGISTER_OFFSET);
- rdev->irq.stat_regs.evergreen.afmt_status6 = RREG32(AFMT_STATUS +
EVERGREEN_CRTC5_REGISTER_OFFSET);
-
if (rdev->irq.stat_regs.evergreen.d1grph_int & GRPH_PFLIP_INT_OCCURRED)
WREG32(GRPH_INT_STATUS + EVERGREEN_CRTC0_REGISTER_OFFSET,
GRPH_PFLIP_INT_CLEAR);
if (rdev->irq.stat_regs.evergreen.d2grph_int & GRPH_PFLIP_INT_OCCURRED)
@@ -3001,36 +2955,6 @@ static void evergreen_irq_ack(struct radeon_device *rdev)
tmp
[PATCH 3/6] drm/radeon: add some HDMI comments
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
drivers/gpu/drm/radeon/radeon_display.c |5 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 4fdecc2..8b64bf1 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -143,6 +143,13 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
WREG32(HDMI_GC + offset, 0); /* unset HDMI_GC_AVMUTE */
+ /*
+* At this point fglrx reads following regs:
+* DCE41: 0x49c
+* DCE5: 0x480 0x484 0x488
+* Is that something audio related?
+*/
+
err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
@@ -158,6 +165,13 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
evergreen_hdmi_update_avi_infoframe(encoder, buffer, sizeof(buffer));
evergreen_hdmi_update_ACR(encoder, mode->clock);
+ /*
+* At this point fglrx changes following regs:
+* DCE41: 0x7a70
+* DCE5: 0x7a70 and 0x64ec
+* Is that something audio related?
+*/
+
/* it's unknown what these bits do excatly, but it's indeed quite
useful for debugging */
WREG32(AFMT_RAMP_CONTROL0 + offset, 0x00FF);
WREG32(AFMT_RAMP_CONTROL1 + offset, 0x007F);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index e38fd55..a83c272 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1261,6 +1261,11 @@ static void radeon_afmt_init(struct radeon_device *rdev)
rdev->mode_info.afmt[1]->offset =
EVERGREEN_CRTC1_REGISTER_OFFSET;
rdev->mode_info.afmt[1]->id = 1;
}
+ /*
+* According to the commens above we should use !DCE41 || DCE5,
+* condition, however there isn't any DCE5 that is DCE41, so
+* DCE5 check is not needed.
+*/
if (!ASIC_IS_DCE41(rdev)) {
rdev->mode_info.afmt[2] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
if (rdev->mode_info.afmt[2]) {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/radeon/evergreen: setup HDMI before enabling it
Closed source driver fglrx seems to enable infoframes and audio packets at the end, which makes sense, do the same. Signed-off-by: Rafał Miłecki --- drivers/gpu/drm/radeon/evergreen_hdmi.c | 15 +++ drivers/gpu/drm/radeon/evergreend.h |1 + 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c b/drivers/gpu/drm/radeon/evergreen_hdmi.c index 8b64bf1..6b25c1b 100644 --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c @@ -116,7 +116,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, struct drm_display_mode HDMI_AUDIO_PACKETS_PER_LINE(3)); /* should be suffient for all audio modes and small enough for all hblanks */ WREG32(AFMT_AUDIO_PACKET_CONTROL + offset, - AFMT_AUDIO_SAMPLE_SEND | /* send audio packets */ AFMT_60958_CS_UPDATE); /* allow 60958 channel status fields to be updated */ WREG32(HDMI_ACR_PACKET_CONTROL + offset, @@ -129,8 +128,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, struct drm_display_mode HDMI_GC_CONT); /* send general control packets every frame */ WREG32(HDMI_INFOFRAME_CONTROL0 + offset, - HDMI_AVI_INFO_SEND | /* enable AVI info frames */ - HDMI_AVI_INFO_CONT | /* send AVI info frames every frame/field */ HDMI_AUDIO_INFO_SEND | /* enable audio info frames (frames won't be set until audio is enabled) */ HDMI_AUDIO_INFO_CONT); /* required for audio info values to be updated */ @@ -138,7 +135,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, struct drm_display_mode AFMT_AUDIO_INFO_UPDATE); /* required for audio info values to be updated */ WREG32(HDMI_INFOFRAME_CONTROL1 + offset, - HDMI_AVI_INFO_LINE(2) | /* anything other than 0 */ HDMI_AUDIO_INFO_LINE(2)); /* anything other than 0 */ WREG32(HDMI_GC + offset, 0); /* unset HDMI_GC_AVMUTE */ @@ -165,6 +161,14 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, struct drm_display_mode evergreen_hdmi_update_avi_infoframe(encoder, buffer, sizeof(buffer)); evergreen_hdmi_update_ACR(encoder, mode->clock); + WREG32_OR(HDMI_INFOFRAME_CONTROL0 + offset, + HDMI_AVI_INFO_SEND | /* enable AVI info frames */ + HDMI_AVI_INFO_CONT); /* required for audio info values to be updated */ + + WREG32_P(HDMI_INFOFRAME_CONTROL1 + offset, +HDMI_AVI_INFO_LINE(2), /* anything other than 0 */ +~HDMI_AVI_INFO_LINE_MASK); + /* * At this point fglrx changes following regs: * DCE41: 0x7a70 @@ -172,6 +176,9 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, struct drm_display_mode * Is that something audio related? */ + WREG32_OR(AFMT_AUDIO_PACKET_CONTROL + offset, + AFMT_AUDIO_SAMPLE_SEND); /* send audio packets */ + /* it's unknown what these bits do excatly, but it's indeed quite useful for debugging */ WREG32(AFMT_RAMP_CONTROL0 + offset, 0x00FF); WREG32(AFMT_RAMP_CONTROL1 + offset, 0x007F); diff --git a/drivers/gpu/drm/radeon/evergreend.h b/drivers/gpu/drm/radeon/evergreend.h index 982d25a..e39e4f4 100644 --- a/drivers/gpu/drm/radeon/evergreend.h +++ b/drivers/gpu/drm/radeon/evergreend.h @@ -197,6 +197,7 @@ # define HDMI_MPEG_INFO_CONT (1 << 9) #define HDMI_INFOFRAME_CONTROL1 0x7048 # define HDMI_AVI_INFO_LINE(x) (((x) & 0x3f) << 0) +# define HDMI_AVI_INFO_LINE_MASK (0x3f << 0) # define HDMI_AUDIO_INFO_LINE(x) (((x) & 0x3f) << 8) # define HDMI_MPEG_INFO_LINE(x)(((x) & 0x3f) << 16) #define HDMI_GENERIC_PACKET_CONTROL 0x704c -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/radeon/evergreen: reorder HDMI setup
Driver fglrx setups audio and ACR packets after basic initialization,
which sounds sane, do the same.
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 6b25c1b..24d13ac 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -111,17 +111,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
WREG32(AFMT_AUDIO_CRC_CONTROL + offset, 0x1000);
- WREG32(HDMI_AUDIO_PACKET_CONTROL + offset,
- HDMI_AUDIO_DELAY_EN(1) | /* set the default audio delay */
- HDMI_AUDIO_PACKETS_PER_LINE(3)); /* should be suffient for all
audio modes and small enough for all hblanks */
-
- WREG32(AFMT_AUDIO_PACKET_CONTROL + offset,
- AFMT_60958_CS_UPDATE); /* allow 60958 channel status fields to
be updated */
-
- WREG32(HDMI_ACR_PACKET_CONTROL + offset,
- HDMI_ACR_AUTO_SEND | /* allow hw to sent ACR packets when
required */
- HDMI_ACR_SOURCE); /* select SW CTS value */
-
WREG32(HDMI_VBI_PACKET_CONTROL + offset,
HDMI_NULL_SEND | /* send null packets when required */
HDMI_GC_SEND | /* send general control packets */
@@ -146,6 +135,21 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
* Is that something audio related?
*/
+ WREG32(HDMI_AUDIO_PACKET_CONTROL + offset,
+ HDMI_AUDIO_DELAY_EN(1) | /* set the default audio delay */
+ HDMI_AUDIO_PACKETS_PER_LINE(3)); /* should be suffient for all
audio modes and small enough for all hblanks */
+
+ WREG32(AFMT_AUDIO_PACKET_CONTROL + offset,
+ AFMT_60958_CS_UPDATE); /* allow 60958 channel status fields to
be updated */
+
+ /* fglrx clears sth in AFMT_AUDIO_PACKET_CONTROL2 here */
+
+ WREG32(HDMI_ACR_PACKET_CONTROL + offset,
+ HDMI_ACR_AUTO_SEND | /* allow hw to sent ACR packets when
required */
+ HDMI_ACR_SOURCE); /* select SW CTS value */
+
+ evergreen_hdmi_update_ACR(encoder, mode->clock);
+
err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
@@ -159,7 +163,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
}
evergreen_hdmi_update_avi_infoframe(encoder, buffer, sizeof(buffer));
- evergreen_hdmi_update_ACR(encoder, mode->clock);
WREG32_OR(HDMI_INFOFRAME_CONTROL0 + offset,
HDMI_AVI_INFO_SEND | /* enable AVI info frames */
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/radeon/evergreen: write default channel numbers
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 24d13ac..ed46dad 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -150,6 +150,27 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
evergreen_hdmi_update_ACR(encoder, mode->clock);
+ WREG32(AFMT_60958_0 + offset,
+ AFMT_60958_CS_CHANNEL_NUMBER_L(1));
+
+ WREG32(AFMT_60958_1 + offset,
+ AFMT_60958_CS_CHANNEL_NUMBER_R(2));
+
+ WREG32(AFMT_60958_2 + offset,
+ AFMT_60958_CS_CHANNEL_NUMBER_2(3) |
+ AFMT_60958_CS_CHANNEL_NUMBER_3(4) |
+ AFMT_60958_CS_CHANNEL_NUMBER_4(5) |
+ AFMT_60958_CS_CHANNEL_NUMBER_5(6) |
+ AFMT_60958_CS_CHANNEL_NUMBER_6(7) |
+ AFMT_60958_CS_CHANNEL_NUMBER_7(8));
+
+ /* fglrx sets 0x0001005f | (x & 0x00fc) in 0x5f78 here */
+
+ WREG32(AFMT_AUDIO_PACKET_CONTROL2 + offset,
+ AFMT_AUDIO_CHANNEL_ENABLE(0xff));
+
+ /* fglrx sets 0x40 in 0x5f80 here */
+
err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Latest randconfig build errors
On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding wrote: > On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote: >> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren wrote: >> > >> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition >> >> of `__mod_of_device_table' >> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here >> >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition >> >> of `__mod_of_device_table' >> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here >> >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of >> >> `__mod_of_device_table' >> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here >> > >> > Rob, I assume you'll do a patch for this one? >> >> >> oh, I apologize for the late reply, I didn't see this email... >> >> There is a patch that we can merge to make tilcdc bool instead of >> tristate[1], which I suppose is ok for a temporary fix. Although I'm >> all-ears if someone has a better idea about how to fix this. The >> problem is that we have multiple sub-devices for different possible >> panel drivers, so that depending on DT tables, the correct ones get >> loaded for the hw. But they are all built into a single module. >> Splitting them into multiple modules will be problematic, as panel >> drivers which are present really need to get probed before the >> toplevel drm device.. > > You could look at the Tegra driver. I had to solve a similar problem > there. What I did is basically parse the DT in the host1x driver and add > all device nodes which are required by DRM to a list. Later when the > individual devices are probed they are removed from that list, so that > when the list becomes empty we are sure that all required devices are > there and only then call the drm_platform_init() function. thx, ok, I'll have a look at this > This fits very well with how Tegra hardware is designed because host1x > is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is > probed before any of its children and it can easily parse the DT upfront > and initialize the list of required devices. > >> I suppose in theory it is possible to make drm >> cope better with dynamically loaded outputs, but I'm not sure that >> there is any way to do this without breaking userspace which expects >> that all of the connectors/encoders are present once the drm device is >> loaded. > > I had been thinking about this on and off for a while, but I haven't > come up with anything concrete. Ideally we could just have some kind of > event that userspace would listen for, so that new outputs can be > dynamically added and userspace informed about them. Last time I checked > most of the helpers assumed that the complete output configuration is > known when the DRM device is registered, so some major rework will be > required to efficiently make use of such dynamicity. I'm less worried about the kernel re-work.. more worried about the fact that we have no way to know whether userspace knows to listen for this new event. So anything down this path could, I think, be considered as breaking userspace. I think in the end, we need some way to have sort of "dummy" connectors for output drivers which might or might not be probed, so that from userspace perspective, non-present panels appear as displays that are not plugged in. BR, -R > Thierry ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #55 from Alexandre Demers --- (In reply to comment #54) > Just tested with 6970, still fine, no AMD-Vi messages in dmesg. > > I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the > difference between your and mine setups. Maybe, I'll test it later then. After all, I do have gfxmode and gxpayload used in my grub.cfg. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130413/d8a5c8db/attachment.html>
[Bug 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #56 from Vladimir --- I have a panic back on reboot tho, same as in https://bugs.freedesktop.org/attachment.cgi?id=77625 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130413/a807bc5f/attachment.html>
[Bug 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #57 from Alexandre Demers --- (In reply to comment #55) > (In reply to comment #54) > > Just tested with 6970, still fine, no AMD-Vi messages in dmesg. > > > > I have gfxmode/gfxpayload commented out from grub.cfg, maybe that's the > > difference between your and mine setups. > > Maybe, I'll test it later then. After all, I do have gfxmode and gxpayload > used in my grub.cfg. Even with gfxpayload=text (which is working correctly without all the patches), I still have the AMD-Vi IO PAGE FAULT messages. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130413/b5fbfe9a/attachment.html>
[Bug 56541] Sony VAIO VPCZ23A4R: Oops or panic on radeon in error path
https://bugzilla.kernel.org/show_bug.cgi?id=56541 Alexander E. Patrakov changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #2 from Alexander E. Patrakov 2013-04-13 07:43:18 --- Yes, the issue is fixed. Thanks! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Latest randconfig build errors
On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren wrote: > >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of >> `__mod_of_device_table' >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of >> `__mod_of_device_table' >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of >> `__mod_of_device_table' >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > > Rob, I assume you'll do a patch for this one? oh, I apologize for the late reply, I didn't see this email... There is a patch that we can merge to make tilcdc bool instead of tristate[1], which I suppose is ok for a temporary fix. Although I'm all-ears if someone has a better idea about how to fix this. The problem is that we have multiple sub-devices for different possible panel drivers, so that depending on DT tables, the correct ones get loaded for the hw. But they are all built into a single module. Splitting them into multiple modules will be problematic, as panel drivers which are present really need to get probed before the toplevel drm device.. I suppose in theory it is possible to make drm cope better with dynamically loaded outputs, but I'm not sure that there is any way to do this without breaking userspace which expects that all of the connectors/encoders are present once the drm device is loaded. BR, -R [1] https://patchwork.kernel.org/patch/2376061/
drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]
On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote: > Hi, > > the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling > drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(), > which in case of i915 DRM driver effectively calls > intel_get_load_detect_pipe() that tries to lock crtc->mutex again. > This causes a deadlock, and can be in some cases triggered by VT > switch to framebuffer console on i915. > > This bug is introduced in Linux 3.9-rc1 and still exists > in v3.9-rc6-183-gbf81710. Linux 3.8 is ok. In Dave's drm-fixes branch: commit 89ced125472b8551c65526934b7f6c733a6864fa Author: Daniel Vetter Date: Thu Apr 11 14:26:55 2013 + drm/fb-helper: Fix locking in drm_fb_helper_hotplug_event Driver's and ->fill_modes functions are allowed to grab crtc mutexes (for e.g. load detect). Hence we need to first only grab the general kms mutex, and only in a second step grab all locks to do the modesets. This prevents a deadlock on my gm45 in the tv load detect code called by drm_helper_probe_single_connector_modes. Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie -Chris -- Chris Wilson, Intel Open Source Technology Centre
Latest randconfig build errors
On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote: > On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren wrote: > > > >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of > >> `__mod_of_device_table' > >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of > >> `__mod_of_device_table' > >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of > >> `__mod_of_device_table' > >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here > > > > Rob, I assume you'll do a patch for this one? > > > oh, I apologize for the late reply, I didn't see this email... > > There is a patch that we can merge to make tilcdc bool instead of > tristate[1], which I suppose is ok for a temporary fix. Although I'm > all-ears if someone has a better idea about how to fix this. The > problem is that we have multiple sub-devices for different possible > panel drivers, so that depending on DT tables, the correct ones get > loaded for the hw. But they are all built into a single module. > Splitting them into multiple modules will be problematic, as panel > drivers which are present really need to get probed before the > toplevel drm device.. You could look at the Tegra driver. I had to solve a similar problem there. What I did is basically parse the DT in the host1x driver and add all device nodes which are required by DRM to a list. Later when the individual devices are probed they are removed from that list, so that when the list becomes empty we are sure that all required devices are there and only then call the drm_platform_init() function. This fits very well with how Tegra hardware is designed because host1x is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is probed before any of its children and it can easily parse the DT upfront and initialize the list of required devices. > I suppose in theory it is possible to make drm > cope better with dynamically loaded outputs, but I'm not sure that > there is any way to do this without breaking userspace which expects > that all of the connectors/encoders are present once the drm device is > loaded. I had been thinking about this on and off for a while, but I haven't come up with anything concrete. Ideally we could just have some kind of event that userspace would listen for, so that new outputs can be dynamically added and userspace informed about them. Last time I checked most of the helpers assumed that the complete output configuration is known when the DRM device is registered, so some major rework will be required to efficiently make use of such dynamicity. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130413/e0117fe8/attachment.pgp>
drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]
Hi,
the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling
drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(),
which in case of i915 DRM driver effectively calls
intel_get_load_detect_pipe() that tries to lock crtc->mutex again.
This causes a deadlock, and can be in some cases triggered by VT
switch to framebuffer console on i915.
This bug is introduced in Linux 3.9-rc1 and still exists
in v3.9-rc6-183-gbf81710. Linux 3.8 is ok.
This deadlock is probably introduced by
commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
(drm: don't hold crtc mutexes for connector ->detect callbacks).
Steps to reproduce (the deadlock occurs in almost all cases):
LCD panel connected to LVDS1, 915GM, HP nc6120
1. power on
2. $ startx
3. connect monitor to VGA1
4. $ xrandr --output VGA1 --mode 1600x1200 --right-of LVDS1
5. change VT, ALT + CTRL + F2
Krzysiek
...
[ 62.995861] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:13:SVIDEO-1]
[ 62.995870] [drm:intel_get_load_detect_pipe], [CONNECTOR:13:SVIDEO-1],
[ENCODER:14:TV-14]
[ 62.995873]
[ 62.995875] =
[ 62.995877] [ INFO: possible recursive locking detected ]
[ 62.995881] 3.9.0-rc6-00184-gc875d9b #14 Not tainted
# v3.9-rc6-183-gbf81710 + one unrelated local patch.
[ 62.995883] -
[ 62.995885] X/1759 is trying to acquire lock:
[ 62.995903] (&crtc->mutex){+.+.+.}, at: [<803649e4>]
intel_get_load_detect_pipe+0x164/0x3f0
[ 62.995905]
[ 62.995905] but task is already holding lock:
[ 62.995916] (&crtc->mutex){+.+.+.}, at: [<8032d1da>]
drm_modeset_lock_all+0x3a/0x50
[ 62.995918]
[ 62.995918] other info that might help us debug this:
[ 62.995920] Possible unsafe locking scenario:
[ 62.995920]
[ 62.995921]CPU0
[ 62.995923]
[ 62.995926] lock(&crtc->mutex);
[ 62.995930] lock(&crtc->mutex);
[ 62.995931]
[ 62.995931] *** DEADLOCK ***
[ 62.995931]
[ 62.995933] May be due to missing lock nesting notation
[ 62.995933]
[ 62.995936] 3 locks held by X/1759:
[ 62.995948] #0: (console_lock){+.+.+.}, at: [<802fe726>]
vt_ioctl+0xe26/0x1220
[ 62.995958] #1: (&dev->mode_config.mutex){+.+.+.}, at: [<8032d1b5>]
drm_modeset_lock_all+0x15/0x50
[ 62.995968] #2: (&crtc->mutex){+.+.+.}, at: [<8032d1da>]
drm_modeset_lock_all+0x3a/0x50
[ 62.995970]
[ 62.995970] stack backtrace:
[ 62.995974] Pid: 1759, comm: X Not tainted 3.9.0-rc6-00184-gc875d9b #14
[ 62.995976] Call Trace:
[ 62.995985] [<8016d9f8>] __lock_acquire+0x748/0x19e0
[ 62.995991] [<80160008>] ? ktime_get+0xb8/0xf0
[ 62.995998] [<80155f6e>] ? local_clock+0x4e/0x60
[ 62.996005] [<8012c2c5>] ? log_store+0x2d5/0x3b0
[ 62.996011] [<8014fc83>] ? down_trylock+0x13/0x40
[ 62.996017] [<8016b655>] ? mark_held_locks+0x75/0xe0
[ 62.996020] [<8012d9b9>] ? vprintk_emit+0x159/0x4e0
[ 62.996020] [<8016f189>] lock_acquire+0x79/0x90
[ 62.996020] [<803649e4>] ? intel_get_load_detect_pipe+0x164/0x3f0
[ 62.996020] [<8050acf4>] mutex_lock_nested+0x54/0x310
[ 62.996020] [<803649e4>] ? intel_get_load_detect_pipe+0x164/0x3f0
[ 62.996020] [<803649e4>] ? intel_get_load_detect_pipe+0x164/0x3f0
[ 62.996020] [<80327c7a>] ? drm_ut_debug_printk+0x2a/0x50
[ 62.996020] [<803649e4>] intel_get_load_detect_pipe+0x164/0x3f0
[ 62.996020] [<80108707>] ? native_sched_clock+0x27/0xb0
[ 62.996020] [<80155bcc>] ? sched_clock_local.constprop.2+0x3c/0x170
[ 62.996020] [<8038061d>] intel_tv_detect+0x15d/0x570
[ 62.996020] [<8016b98b>] ? trace_hardirqs_off+0xb/0x10
[ 62.996020] [<80155f6e>] ? local_clock+0x4e/0x60
[ 62.996020] [<8012c2c5>] ? log_store+0x2d5/0x3b0
[ 62.996020] [<8014fc83>] ? down_trylock+0x13/0x40
[ 62.996020] [<8031dbd8>] drm_helper_probe_single_connector_modes+0x278/0x330
[ 62.996020] [<80319fc7>]
drm_fb_helper_probe_connector_modes.isra.3+0x37/0x60
[ 62.996020] [<8031bfec>] drm_fb_helper_hotplug_event+0x6c/0xc0
[ 62.996020] [<8031c0d3>] drm_fb_helper_set_par+0x93/0xc0
[ 62.996020] [<802afdaa>] fb_set_var+0x1ea/0x4b0
[ 62.996020] [<8016d6bb>] ? __lock_acquire+0x40b/0x19e0
[ 62.996020] [<80108707>] ? native_sched_clock+0x27/0xb0
[ 62.996020] [<80155bcc>] ? sched_clock_local.constprop.2+0x3c/0x170
[ 62.996020] [<802b964a>] fbcon_blank+0x2aa/0x300
[ 62.996020] [<80307371>] do_unblank_screen+0x91/0x1a0
[ 62.996020] [<802fd876>] complete_change_console+0x56/0xe0
[ 62.996020] [<802fea3f>] vt_ioctl+0x113f/0x1220
[ 62.996020] [<8050d8c7>] ? _raw_spin_unlock+0x27/0x50
[ 62.996020] [<802fd900>] ? complete_change_console+0xe0/0xe0
[ 62.996020] [<802f438a>] tty_ioctl+0x26a/0xb70
[ 62.996020] [<80155bcc>] ? sched_clock_local.constprop.2+0x3c/0x170
[ 62.996020] [<802fd900>] ? complete_change_console+0xe0/0xe0
[ 62.996020] [<80155db5>] ? sched_clock_cpu+0x75/0xd0
[ 62.996020] [<8016b98b>] ? trace_hardirqs_off+0xb/0x10
[
