[PATCH v2] drm/radeon: Fix kernel panic with HDMI w/o SAD
Alex Deucher
alexdeucher at gmail.com
Mon Jan 5 10:29:56 PST 2015
On Mon, Jan 5, 2015 at 1:16 PM, Takashi Iwai <tiwai at suse.de> wrote:
> At Mon, 5 Jan 2015 12:48:05 -0500,
> Alex Deucher wrote:
>>
>> On Mon, Jan 5, 2015 at 12:23 PM, Takashi Iwai <tiwai at suse.de> wrote:
>> > At Mon, 5 Jan 2015 12:07:52 -0500,
>> > Alex Deucher wrote:
>> >>
>> >> On Sat, Jan 3, 2015 at 5:09 AM, Takashi Iwai <tiwai at suse.de> wrote:
>> >> > A BUG_ON() call in dce3_2_afmt_write_sad_regs() is triggered when a
>> >> > HDMI monitor without audio is plugged:
>> >>
>> >> I have a slightly different fix already queued up:
>> >> http://lists.freedesktop.org/archives/dri-devel/2014-December/073672.html
>> >
>> > Oh, that's identical with my v1 patch :) But, with that fix, an error
>> > message will be shown at each time you plug such a monitor, right?
>> > This doesn't look right, so I revised the patch.
>>
>> Yes, but if the monitor claims to support audio, it should supply
>> SADs. If it doesn't, the driver has no way of knowing what type of
>> audio the monitor supports.
>
> IMO, we may assume that the monitor has no audio at all if sad_count =
> 0. Or are there any monitors that do support audio even without
> SAD...?
I don't remember off hand. We'd need to check the CEA edid extension spec.
The radeon hdmi code should be restructured a bit to enable hdmi
features in a more fine grained way. If the monitor supports hdmi, we
try and enable audio in addition to the other hdmi packets. We should
be using drm_detect_monitor_audio() to decide whether to enable audio
features. We have some patches internally which cleans a lot of this
up that should be available soon.
>
>> I'm fine with removing the error message
>> or making it debug only however.
>
> If sad_count = 0 is an invalid state that shouldn't happen, then
> printing an error is correct behavior. So, the question comes to the
> point whether sad_count = 0 is a sane value or not.
>
>> > Also, can we skip the register write completely? I thought of a case
>> > like we replug a monitor from the one with audio to another without
>> > audio...
>>
>> Changing the monitor will generally trigger a full probe and modeset
>> again anyway. The register writes are just there to pass the audio
>> information supported by the monitor along to the audio driver.
>
> OK, thanks for clarification.
>
>
> In anyway, I still think we should kill BUG_ON() there. But this can
> be a separate patch, of course.
Yeah, agreed.
Alex
>
>
> Takashi
>
>>
>> Alex
>>
>> >
>> >
>> > thanks,
>> >
>> > Takashi
>> >
>> >>
>> >> Alex
>> >>
>> >> >
>> >> > kernel BUG at ../drivers/gpu/drm/radeon/dce3_1_afmt.c:110!
>> >> > invalid opcode: 0000 [#1] PREEMPT SMP
>> >> > CPU: 2 PID: 967 Comm: Xorg Tainted: PO 3.16.7-7-desktop #1
>> >> > Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401 05/18/2011
>> >> > task: ffff8800cea86350 ti: ffff8800c1880000 task.ti: ffff8800c1880000
>> >> > RIP: 0010:[<ffffffffa0126c50>] dce3_1_hdmi_setmode+0x570/0x5a0 [radeon]
>> >> > Call Trace:
>> >> > [<ffffffffa00a6936>] drm_crtc_helper_set_mode+0x346/0x520 [drm_kms_helper]
>> >> > [<ffffffffa00a7678>] drm_crtc_helper_set_config+0x8a8/0xad0 [drm_kms_helper]
>> >> > [<ffffffffa00ede3f>] radeon_crtc_set_config+0x3f/0x110 [radeon]
>> >> > [<ffffffffa001edc1>] drm_mode_set_config_internal+0x61/0xe0 [drm]
>> >> > [<ffffffffa00a9a6b>] restore_fbdev_mode+0xab/0xd0 [drm_kms_helper]
>> >> > [<ffffffffa00a9aae>] drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30 [drm_kms_helper]
>> >> > [<ffffffffa00ab642>] drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper]
>> >> > [<ffffffffa00ab5cb>] drm_fb_helper_hotplug_event+0x8b/0xe0 [drm_kms_helper]
>> >> > [<ffffffffa00ab65a>] drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper]
>> >> > [<ffffffff813818ce>] fb_set_var+0x15e/0x3b0
>> >> > [<ffffffff81378d0b>] fbcon_blank+0x1cb/0x2b0
>> >> > [<ffffffff813f2a31>] do_unblank_screen+0xa1/0x1b0
>> >> > [<ffffffff813e8fd3>] complete_change_console+0x53/0xe0
>> >> > [<ffffffff813e9fa9>] vt_ioctl+0xf49/0x10d0
>> >> > [<ffffffff813ddfdc>] tty_ioctl+0x26c/0xb70
>> >> > [<ffffffff811cad17>] do_vfs_ioctl+0x2e7/0x4c0
>> >> > [<ffffffff811caf71>] SyS_ioctl+0x81/0xa0
>> >> > [<ffffffff81622a2d>] system_call_fastpath+0x1a/0x1f
>> >> > [<00007f2fae8c6397>] 0x7f2fae8c6396
>> >> >
>> >> > Actually the BUG_ON() check is wrong, since sads may be NULL when
>> >> > sad_count is zero. This patch removes the BUG_ON() and adds the
>> >> > proper NULL initialization of sads.
>> >> >
>> >> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=911356
>> >> > Cc: <stable at vger.kernel.org>
>> >> > Signed-off-by: Takashi Iwai <tiwai at suse.de>
>> >> > ---
>> >> > drivers/gpu/drm/radeon/dce3_1_afmt.c | 3 +--
>> >> > 1 file changed, 1 insertion(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c b/drivers/gpu/drm/radeon/dce3_1_afmt.c
>> >> > index 2fe8cfc966d9..7ca23f45829e 100644
>> >> > --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
>> >> > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
>> >> > @@ -72,7 +72,7 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
>> >> > struct radeon_device *rdev = encoder->dev->dev_private;
>> >> > struct drm_connector *connector;
>> >> > struct radeon_connector *radeon_connector = NULL;
>> >> > - struct cea_sad *sads;
>> >> > + struct cea_sad *sads = NULL;
>> >> > int i, sad_count;
>> >> >
>> >> > static const u16 eld_reg_to_type[][2] = {
>> >> > @@ -107,7 +107,6 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
>> >> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
>> >> > return;
>> >> > }
>> >> > - BUG_ON(!sads);
>> >> >
>> >> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
>> >> > u32 value = 0;
>> >> > --
>> >> > 2.2.0
>> >> >
>> >> > _______________________________________________
>> >> > dri-devel mailing list
>> >> > dri-devel at lists.freedesktop.org
>> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >>
>>
More information about the dri-devel
mailing list