From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB4CFC001E0 for ; Wed, 2 Aug 2023 17:52:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231555AbjHBRwI (ORCPT ); Wed, 2 Aug 2023 13:52:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229863AbjHBRvv (ORCPT ); Wed, 2 Aug 2023 13:51:51 -0400 Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68EDC35A1 for ; Wed, 2 Aug 2023 10:50:39 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-79969c14964so45159241.2 for ; Wed, 02 Aug 2023 10:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; t=1690998628; x=1691603428; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xGq1aIBCGxiEXrqQEhQT2LiB068qDotkWqP0YLxkeNY=; b=VE5dAkKjhFGny8iA1SHzqW1gjkpPyzpJFeCvCiaMmYrYz136cFMNC2wBIbAIpyYvG8 PcRFVQlMWLR3IyZu1ZbABkwfBOos+L3H4YyKb0sxceiTZN7kffAtSWidSEwB6sm+WOfg RB8VB9ot6MVX10g89RfjV6H83XBT/9+O3hA0t3Urr7/zSuunnEHEK4VDHBAUkNMnpOvo tDqP0rKHdn9wTIcG/u6Q2vqXUA/jjPED33xazSaZOT2mDzVUPtCzgzTtDQfQmZME6LmS oyYOCB/iNzBwv7KLufHbEpC68ObAZITaI5lh2GNzADEaKEbeq+hoi/5/FRdj1/SUMFgb lRyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690998628; x=1691603428; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xGq1aIBCGxiEXrqQEhQT2LiB068qDotkWqP0YLxkeNY=; b=XdEpqseeZltxRbhJr6OMhxNzLcnC2S4T1ZjdbNixSKGirEGKw/rKDP/FX8bJuGMDWc Aku2Sggsbwa6eRcbrbnhdI2X9LYK28NRwzwj4hLTvq4pbc30SuE+HmGA+Hl3eYNZd8w7 yrj7XoSZy2fwJude39imXC602/8JIhT1YcG9W9isaZqQ+wCc9bEw0CAKtPdxpRaa8dw6 o6IB/xrGsoCkWG6RcZA5UxcNIhDvf9JdJABvWa1tVwPZKwN2s9E0m+jbAUqgj833GIxS jz9XppobtMEy6O7CB5PWBVLxcmJyg3GStL5E6SnZsTJeppnFBj2gyoTy8OCMHYwzSeZh /gbQ== X-Gm-Message-State: ABy/qLYP4hmuUPT3A0eSZRzzTTCCjm/3Wn9tmAOVXgX76qb/TPrF/8XZ JqWnnM3ZmovXP5lh3JBlOCT0yelLQt7Ptrlp7IwDZg== X-Google-Smtp-Source: APBJJlEKR2Jf7TabvMSTmOGKPPwR3l8uT7K3XVNms8a2Ktc3rqhSqafmYxy++abfkChGUgUk+R2wfEAjkMi811bR0sM= X-Received: by 2002:a05:6102:2c5:b0:447:4fbe:17f8 with SMTP id h5-20020a05610202c500b004474fbe17f8mr5295171vsh.23.1690998627720; Wed, 02 Aug 2023 10:50:27 -0700 (PDT) MIME-Version: 1.0 References: <20230725203545.2260506-1-dianders@chromium.org> <20230725133443.v3.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid> <64ca91a3.0d0a0220.8e58d.89b3@mx.google.com> In-Reply-To: <64ca91a3.0d0a0220.8e58d.89b3@mx.google.com> From: Dave Stevenson Date: Wed, 2 Aug 2023 18:50:11 +0100 Message-ID: Subject: Re: [PATCH v3 02/10] drm/panel: Check for already prepared/enabled in drm_panel To: Chris Morgan Cc: Maxime Ripard , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Benjamin Tissoires , Krzysztof Kozlowski , Sam Ravnborg , Frank Rowand , linux-input@vger.kernel.org, hsinyi@google.com, devicetree@vger.kernel.org, Conor Dooley , cros-qcom-dts-watchers@chromium.org, linux-arm-msm@vger.kernel.org, yangcong5@huaqin.corp-partner.google.com, Jiri Kosina , Rob Herring , Neil Armstrong , Bjorn Andersson , Dmitry Torokhov , Doug Anderson , Konrad Dybcio , Thomas Zimmermann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, 2 Aug 2023 at 18:26, Chris Morgan wrote: > > * Spam * > On Mon, Jul 31, 2023 at 07:03:07PM +0200, Maxime Ripard wrote: > > Hi, > > > > On Mon, Jul 31, 2023 at 11:33:22AM -0500, Chris Morgan wrote: > > > In my case a few different panel drivers disable the regulators in the > > > unprepare/disable routines. > > > > And that's totally fine. > > > > > For at least the Rockchip DSI implementations for some reason the > > > panel gets unprepared more than once, which triggers an unbalanced > > > regulator disable. > > > > "For some reason" being that DW-DSI apparently finds it ok to bypass any > > kind of abstraction and randomly calling panel functions by itself: > > > > https://elixir.bootlin.com/linux/v6.4.7/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L868 > > > > It looks like it's fixed it current drm-misc-next though. > > Good, when I get a chance I will test it out with the existing panels > I have at my disposal and submit some patches to clean them up. > > > > > > Obviously though the correct course of action is to fix the reason why > > > the panel is disabled more than once, but that's at least the root > > > cause of this behavior on the few panels I've worked with. > > > > Like I said we already have a commit on the way to fix that, so it > > shouldn't be an issue anymore. > > > > I stand by what I was saying earlier though, I think it's mostly > > cargo-cult or drivers being very wrong. If anything, the DW-DSI stuff > > made me even more convinced that we shouldn't even entertain that idea > > :) DW-DSI is hacking around the fact that DSI panels may want to send DCS commands in unprepare, however the DSI host driver shuts down the controller in the DSI bridge post_disable which gets called first. That ordering can now be reversed with pre_enable_prev_first flag in struct drm_bridge, or prepare_prev_first in drm_panel, hence no need for the DSI controller to jump around the bridge chain. Dave > > Maxime > > Thank you, and yes if a driver is doing something it shouldn't we > shouldn't be patching around that, we should be fixing things. Thanks > for providing me with the additional info. > > Chris >