From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f41.google.com (mail-yx1-f41.google.com [74.125.224.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C226195811 for ; Tue, 21 Apr 2026 02:31:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776738693; cv=none; b=skY79mUMoCfHRmbB8poGdR/r3V2LJSPn9JWpldd1xUDb8B9qVwcOfGcGi4cGc0BdsEUvdZkfr0tRP6bXZeGmXgG1GwHNMU67D1hEzoT733j2in0UVfu78iRTH4dndmRDMPikOsWnVqny2yVJdhrl5yU3m0dEpQaHFtnlBFZyWso= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776738693; c=relaxed/simple; bh=sp3R6bmYxrno0C9baRRapNxuKoTU+SdyfvK5YZwdvZI=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=Obq4JPUIVnJ7spQ0vnZRF0ZcaXQQpcREdiH5BPROa5/+lRaUpRQ12dEnNNrEQhqfOLq5ocVtz5cz/pg6KoxvWve/4JSobvMwhiAbpJyCfmzCUVbGoddPsYCdAc1aPiaTsN4YovqzKL8ybh5LRZ0ArbUpUneTdUiiyyI9b6DNaX0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZcDX6BhZ; arc=none smtp.client-ip=74.125.224.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZcDX6BhZ" Received: by mail-yx1-f41.google.com with SMTP id 956f58d0204a3-6500ff16c0aso401609d50.3 for ; Mon, 20 Apr 2026 19:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776738691; x=1777343491; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=ipI0idJGNrZodVG5ZIm4eDtcetTLm6jd3SJUdqoCiio=; b=ZcDX6BhZtNbLhUpJbhYyKmq3eStaasVn5q9t0RT4t5Hpg+VgtEmnvJA9S8GyOOURj2 ar6nJ7gHivNtPdhjByT5yC/av83bTY3VYqIYRIAojkkDSjupyuyMDyAJdj7gE7XR1VUN Lkoomj7qlltUkriSffcb7nLIQhiYLdcJyjiHS7h4+VI2GOSTHzYA7+4CixCaAMcSepyA +GtlEmFGJiAg2WBXa65No0/aZfD+xhrqoHFPGgb26B2TEr6VH+I9Ct9XG/iiAJPSHmd7 AYQAkAHiVSBMwKAjzEFmsTE2ncyGCznBdz9wYkR1Q9cOZQ6poFG3J6adtuOzn8dp0MYL A/ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776738691; x=1777343491; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ipI0idJGNrZodVG5ZIm4eDtcetTLm6jd3SJUdqoCiio=; b=HBSWspVX81qAQyYeIjixmfFJSYJoI1oCAofsCTvwhJ7AOQN0rmqgT1pLzhwItEiHN5 1dKp94787lt9sOWVV+CzE2uYsHnTmPHhEgkB1tjpVodv5IhyW2+JSuR5l9J6rJMHQ3/i uk08QntAo3F1Kdje544MBuv1gt5AmFu4s2InUMhp94BO8EFm3exXiYZ+OSLJJRZjQ4SH NDck3Wc2GKCDglP1m2KIqmDHoxVHzG7fGu3+zLzL9qR/xXK4l4GBDi3JM8mKCRb7ikGI mq45lyS5033gv5qz4Ex4VkZnhs0s2/yEKs0R3St7RSDimNTu/zXpIaDpFKs+MUAfo8km PhQQ== X-Forwarded-Encrypted: i=1; AFNElJ+0/eBxwBy6OHLTPExl/WFNIVD61Y40Py/x6c9xe+On4DCDs/OymXlU8lfFr/WY7haffZNTc6IF3xvr/Kc=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+1A3tHMY6rXpRxNKOOQ/ALQJJB5oivIH/yplb/JLIald7iew/ ZTJZN1mv3y6uEQjaPEyjLuwrgO+H/uN0JjGCSY4/LjeHBlxowfF3TmCp X-Gm-Gg: AeBDieuYNwT1LXi5Ru4TqxpFbdcw7et+FfhDy0s5i9Mr0Dx2qmnbaCKeR5gFNZzzZp1 HJqsYG2rY8P3eN+Y9KL/4tedR9HxUJGabDqeDdPtPNVzO60iwX1VvbsxMXNCJs6zi8CUxfUtWkf K3t3lHiq2V52hZWdjikPp6U/vrljfs+IRuvym5Gz2mEmW6S3JcIilyiV8TARa28fWQABGZJj6fH V58JmDCKgDKDv+4D1eGTFce5tox7a6IiIIdE5v+IMDNxFV1WkO2M7yX/WBDBpuNp6NVVI2fUVDW Vh4brxnTQPr+SIqaPoaZU+pFbnlhmcmujNgEPY818l1XsVvrY/zS4N+w37spc9CLnPneihAcE9P RMmp7GTAnuuI0ndiJCll3DlME/UFkZolFeQ5zRHr7w1A8yYM2tsVDwCtOx7v5sRQ7dCWp/Vajfm T9y3x64ReBog5T1OHTKNYMf6C02vP/RQ5DXXqBGuFblWpbO+p1+J6loyW7133T0YrZfDmE0oZNM MZ+iQM1SIuIua8= X-Received: by 2002:a05:690c:4b92:b0:7b1:c8e4:3271 with SMTP id 00721157ae682-7b9ed12bbc9mr119038577b3.3.1776738691366; Mon, 20 Apr 2026 19:31:31 -0700 (PDT) Received: from [192.168.11.79] (2607-8700-5500-a805-0000-0000-0000-0002.16clouds.com. [2607:8700:5500:a805::2]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7b9ee8be8e4sm52804197b3.14.2026.04.20.19.31.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Apr 2026 19:31:30 -0700 (PDT) Message-ID: <99f6fde4-ac69-4e7d-a345-a378762eb9bb@gmail.com> Date: Tue, 21 Apr 2026 10:31:19 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Frank Zhang Subject: Re: [PATCH v2] drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down To: Dmitry Baryshkov Cc: andrzej.hajda@intel.com, neil.armstrong@linaro.org, rfoss@kernel.org, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, detlev.casanova@collabora.com, cristian.ciocaltea@collabora.com, Laurent.pinchart@ideasonboard.com, jonas@kwiboo.se, jernej.skrabec@gmail.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260418101936.7731-1-rmxpzlb@gmail.com> <9c198d0e-a675-4d7e-a485-5a8ee4d97f88@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/20/26 17:00, Dmitry Baryshkov wrote: > On Mon, Apr 20, 2026 at 02:11:28PM +0800, Frank Zhang wrote: >> On 4/19/26 08:40, Dmitry Baryshkov wrote: >>> On Sat, Apr 18, 2026 at 06:19:36PM +0800, Frank Zhang wrote: >>>> The following panic was observed during system reboot: >>>> >>>> Kernel panic - not syncing: Asynchronous SError Interrupt >>>> CPU: 7 UID: 1000 PID: 2637 Comm: pipewire ... 6.19.10-300.fc44.aarch64 >>>> Call trace: >>>> ... >>>> regmap_update_bits_base+0x5c/0x90 >>>> dw_hdmi_qp_bridge_clear_infoframe+0xb0/0x120 [dw_hdmi_qp] >>>> drm_bridge_connector_clear_infoframe+0x28/0x48 [drm_display_helper] >>>> ... >>>> dw_hdmi_qp_audio_disable+0x24/0xb8 [dw_hdmi_qp] >>>> drm_bridge_connector_audio_shutdown+0x30/0x60 [drm_display_helper] >>>> drm_connector_hdmi_audio_shutdown+0x24/0x38 [drm_display_helper] >>>> hdmi_codec_shutdown+0x60/0x90 [snd_soc_hdmi_codec] >>>> ... >>>> snd_pcm_release_substream.part.0+0x44/0xd8 [snd_pcm] >>>> snd_pcm_release+0x60/0xe8 [snd_pcm] >>>> ... >>>> >>>> The root cause is pipewire tries to close the HDMI audio device after >>>> atomic_disable(), which sets tmds_char_rate to 0 and disable the PHY. >>>> >>>> In this case, dw_hdmi_qp_audio_disable() will call >>>> drm_atomic_helper_connector_hdmi_clear_audio_infoframe() directly, >>>> accessing registers without checking tmds_char_rate. >>>> >>>> Move drm_atomic_helper_connector_hdmi_clear_audio_infoframe() inside the >>>> if (hdmi->tmds_char_rate) of dw_hdmi_qp_audio_disable(). >>>> >>>> Fixes: fd0141d1a8a2 ("drm/bridge: synopsys: Add audio support for dw-hdmi-qp") >>>> Signed-off-by: Frank Zhang >>>> >>>> --- >>>> Changes in v2: >>>> - Move drm_atomic_helper_connector_hdmi_clear_audio_infoframe() inside >>>> the if (hdmi->tmds_char_rate) of dw_hdmi_qp_audio_disable(). >>>> - Link to v1: https://lore.kernel.org/all/20260416093150.13853-1-rmxpzlb@gmail.com/ >>>> >>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c >>>> index d649a1cf07f5..7760527484c8 100644 >>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c >>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c >>>> @@ -526,10 +526,10 @@ static void dw_hdmi_qp_audio_disable(struct drm_bridge *bridge, >>>> { >>>> struct dw_hdmi_qp *hdmi = dw_hdmi_qp_from_bridge(bridge); >>>> - drm_atomic_helper_connector_hdmi_clear_audio_infoframe(connector); >>>> - >>>> - if (hdmi->tmds_char_rate) >>>> + if (hdmi->tmds_char_rate) { >>>> + drm_atomic_helper_connector_hdmi_clear_audio_infoframe(connector); >>>> dw_hdmi_qp_audio_disable_regs(hdmi); >>>> + } >>> >>> Will audio and audio infoframe remain disabled after consequetive >>> atomic_enable() call? >>> >>>> } >>>> static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, >>>> -- >>>> 2.53.0 >>>> >>> >> >> Sorry, I missed clearing the audio infoframe when the PHY is down. The next >> atomic_enable() will write the stale audio infoframe. My mistake. >> >> To clear the stale audio infoframe, dw_hdmi_qp_audio_disable() can handle it >> in the else branch directly, but this seems like a layering violation for a >> bridge driver >> >> I think the better approach is to add a 'reset_audio_infoframe' interface in >> drm_hdmi_state_helper.c that does basically the same as >> drm_atomic_helper_connector_hdmi_clear_audio_infoframe(), but only clearing >> the software state without calling clear_infoframe(). It's also a bit odd >> since it would only be used by dw-hdmi-qp. > > That sounds too fine-grained and it also will not work straight ahead... > > Just for my understanding, let's consider the opposite situation: the > user tries to start audio playback before setting the mode. How is it > handled in the driver? > audio_prepare() will return -ENODEV before the mode is set. I admit modifying dw-hdmi-qp is more reasonable. I have a new approach: dw-hdmi-qp should have an internal function to clear the audio infoframe related registers. dw_hdmi_qp_bridge_clear_audio_infoframe() should check tmds_char_rate, call the new function only when tmds_char_rate is available. dw_hdmi_qp_bridge_write_audio_infoframe() should call the new function directly instead of dw_hdmi_qp_bridge_clear_audio_infoframe(), without checking tmds_char_rate. dw_hdmi_qp_audio_disable() doesn't need any modification. With this approach, clear_audio_infoframe guards register access by checking tmds_char_rate, while write_audio_infoframe does not need to check it again. How about it? Thanks, Frank Zhang >> >> I'd like to get the maintainers' opinion about adding such an interface. >> >> Thanks, >> Frank Zhang >> >