From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.mainlining.org (mail.mainlining.org [5.75.144.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 000FB346A13 for ; Fri, 24 Apr 2026 15:50:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=5.75.144.95 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777045844; cv=none; b=T6fPer75UmFiBPh7nnnMMxAQ8TsSBxvrTSa+w5iAjOLMTdK2T9agcEqok8s9qN7BVlT2SH72GzOKnwNfIfVn3HTAbAOM4u3oe598Zl0igydbdRy/BooxlcHAmzZLtQ56XEb9fQ2HkY0C0DpDWaDdWVRH7dDuVEbfJnIBPj2ELCA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777045844; c=relaxed/simple; bh=CpQymQMFV738753WIAcgEHHOVwhjytlOxQnPx8O8FTA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aPmNpdJIntZdmGilEsfjQh+1j1FFNiV8+0+5LetXGwRPO1lhhRyRCoAj30s8T4svrETkIFIM3QO0l63dRa127ZS0LJggKr014O5f3byJwiMJaV0ggQOTeZ700BpmBlkJGwpms9g8SzjkPnYvallwSR2EQEP1Xsdk5PDgLXbYnZs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mainlining.org; spf=pass smtp.mailfrom=mainlining.org; dkim=pass (2048-bit key) header.d=mainlining.org header.i=@mainlining.org header.b=Z8cy4U0o; dkim=permerror (0-bit key) header.d=mainlining.org header.i=@mainlining.org header.b=htZZZhYq; arc=none smtp.client-ip=5.75.144.95 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mainlining.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mainlining.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mainlining.org header.i=@mainlining.org header.b="Z8cy4U0o"; dkim=permerror (0-bit key) header.d=mainlining.org header.i=@mainlining.org header.b="htZZZhYq" DKIM-Signature: v=1; a=rsa-sha256; s=202507r; d=mainlining.org; c=relaxed/relaxed; h=From:To:Subject:Date:Message-ID; t=1777045831; bh=5MfdXn4neewtBeoGofSafFV JRMgd66CxCyuNytqkaXg=; b=Z8cy4U0oISU8nWoUym5VEeB1uDhgk41Y9+k9pcTL1OTGicEuzT PI4RDd98yrGL32uzntdWauHnz5B2OwkLyDQXRGon9e+xJ3AlqJMUJkMnvCpFO9hpFjeSRf33cV0 VBuQE+8u2gwS2ZKVqmrqFM3AWlRkvDSRK/BcUER7xt0BFj3H+IsPylCR7HXc9p5qY4Meo2JbG/G w473z6lkg+UPZc9acE38pazR9m3zWMUrmZSnflTur20aF7IstCB+z3C8+x7raxLTa/gzenwrmib tCPzSjBpVqDhZFaBXVceMd6R+PWldBUbJ09H4EtAwOtCwLPbdWya6R4RVKblITwoeSQ==; DKIM-Signature: v=1; a=ed25519-sha256; s=202507e; d=mainlining.org; c=relaxed/relaxed; h=From:To:Subject:Date:Message-ID; t=1777045831; bh=5MfdXn4neewtBeoGofSafFV JRMgd66CxCyuNytqkaXg=; b=htZZZhYq/aZSSSlv6IZmfPvtKftxQQ18W2qOc4cm8x3lSsuGn9 OtqXEE5a8fUjas//mTR7FlcKKv6z01dEXYAQ==; Message-ID: <0c0460c2-a2a0-4f61-8d23-80c3e9592cb5@mainlining.org> Date: Fri, 24 Apr 2026 11:50:28 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drm/panel/boe-tv101wum-nl6: set MIPI_DSI_MODE_LPM after sending panel disable cmds To: Neil Armstrong , Jessica Zhang , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260421153147.4378-2-brady.norander@mainlining.org> <0cc98ad2-bce8-476a-8f27-2c201eed9828@linaro.org> Content-Language: en-US From: Brady Norander In-Reply-To: <0cc98ad2-bce8-476a-8f27-2c201eed9828@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/24/26 05:30, Neil Armstrong wrote: > On 4/21/26 17:31, Brady Norander wrote: >> A recent change to Mediatek drm driver enabled HS mode support. With that >> change, my MT8183-based krane sku176 chromebook display's colors would >> look darker >> and desaturated after turning the display off and back on. Looking at >> other panel >> drivers, it seems common to enable HS mode to send the disable >> commands and to >> disable HS mode afterwards. However, the boe-tv101wum-nl6 driver would >> never >> disable HS mode, leading to this issue. Update the behavior of >> boe_panel_disable >> to match those other panel drivers. As a side note, I did also test >> removing the >> line which enables HS mode during panel_disable. This worked fine for >> my device, >> but just in case that doesn't work for other devices, I chose to keep >> that and >> instead disable HS mode after sending the panel disable commands. >> >> Signed-off-by: Brady Norander >> >> diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/ >> gpu/drm/panel/panel-boe-tv101wum-nl6.c >> index d5fe105bdbdd..f69b5bd776c0 100644 >> --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c >> +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c >> @@ -1326,6 +1326,8 @@ static int boe_panel_disable(struct drm_panel >> *panel) >>       mipi_dsi_msleep(&ctx, 150); >> +    boe->dsi->mode_flags |= MIPI_DSI_MODE_LPM; >> + >>       return ctx.accum_err; >>   } > > Could you add a Fixes tag ? > > Neil I can add a fixes tag and send a v2. Just one thing I'm not sure about, do I tag the mediatek drm commit which git bisect found, or do I tag the commit which added the panel driver since this faulty logic has existed since the driver was added?