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 F0CCCC6FD1D for ; Thu, 30 Mar 2023 06:56:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229829AbjC3G4L (ORCPT ); Thu, 30 Mar 2023 02:56:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229864AbjC3G4K (ORCPT ); Thu, 30 Mar 2023 02:56:10 -0400 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A7DC19F for ; Wed, 29 Mar 2023 23:56:09 -0700 (PDT) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-544f7c176easo337629637b3.9 for ; Wed, 29 Mar 2023 23:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; t=1680159368; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3A+wpr19CmQ1TBVKKYT6GbRWSRYO793ifnsMOlUiwbE=; b=OABucgc84fkecsB2apt/ogKzIf6bvpjaTQB9vmPKnxOjgqC3jbY5/6bWVmEs92Cyfb nUeuA2iJSLy46uwgpJxLgHKX6VHnAIltBZ5zi+aR26/iSoPeYRGWPUWbCU/pLnwSqLG0 KcCsjBrSKWMx3nX1saQmuhKlPvarup2xrLNt0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680159368; h=content-transfer-encoding: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=3A+wpr19CmQ1TBVKKYT6GbRWSRYO793ifnsMOlUiwbE=; b=d9OxkXKGE06SxcG35vI56BapPONmyxGnfcV2QlZZKXP0omY4HwTZeb/3bf/US0S3sN 0faZOcBAS3TuMCklGXmQO99+BOAmf2v94jqBo9x39FlBuNGyIXU+PbKTztSXFtc3CqHg jrO5gQuDgaZWtdfsZTByCOOwziBqALV4UxeB9xgZuZlVtMxebayaTP3wzhvG7iy3vOzz lzYNe0+rIVMZECUTRTCg1MIyEoRTpixS1sDXCNrHzlgAQTRJ67jrMCxafQLqu968LOed sbP2y/vbVl3LEDVZqsl/RWDX3VCTgOiCpLuG8TJ+yeZv1KzDGxgZm6mASNrl79wA7j29 RQag== X-Gm-Message-State: AAQBX9cekniDa60vfUafg7Y3vii27ET5xrCSD6v7w8g3joP1nBiOLeI1 dwYt67Rg2l8fc25KLXr/b3UIRFSn8ZVUpOhoRJG7EL2cMq4pymAA8Jt0zg== X-Google-Smtp-Source: AKy350ZHJjZhJJwBBtdUqfaY6RG/76vwwThMMt3oK5B3TbQQEDFWJx0IY4u2AwSvrLkQBQtu5ALiwx0jgs6FaeAsOf0= X-Received: by 2002:a81:ac46:0:b0:544:6828:3c09 with SMTP id z6-20020a81ac46000000b0054468283c09mr11139395ywj.0.1680159368210; Wed, 29 Mar 2023 23:56:08 -0700 (PDT) MIME-Version: 1.0 References: <20230329131929.1328612-1-jagan@amarulasolutions.com> <20230329164638.v43la4l7rxut6hk6@penduick> In-Reply-To: <20230329164638.v43la4l7rxut6hk6@penduick> From: Jagan Teki Date: Thu, 30 Mar 2023 12:25:56 +0530 Message-ID: Subject: Re: [PATCH v7 10/12] drm/bridge: Implement enable_next_first to alter bridge init order To: Maxime Ripard , Dave Stevenson Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Sam Ravnborg , Rob Herring , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, Marek Vasut , linux-amarula Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Mar 29, 2023 at 10:16=E2=80=AFPM Maxime Ripard = wrote: > > On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote: > > On Wed, 29 Mar 2023 at 14:19, Jagan Teki w= rote: > > > > > > DSI sink devices typically send the MIPI-DCS commands to the DSI host > > > via general MIPI_DSI_DCS read and write API. > > > > > > The classical DSI sequence mentioned that the DSI host receives MIPI-= DCS > > > commands from the DSI sink first in order to switch HS mode properly. > > > Once the DSI host switches to HS mode any MIPI-DCS commands from the > > > DSI sink are unfunctional. > > > > That statement contradicts the spec. > > The DSI spec section 8.11.1 Transmission Packet Sequences says that > > during any BLLP (Blanking or Low Power) period the host can do any of: > > - remain in LP-11 > > - transmit one or more non-video packets from host to peripheral in esc= ape mode > > - transmit one or more non-video packets from host to peripheral in > > using HS mode > > - receive one or more packets from peripheral to host using escape mode > > - transmit data on a different virtual channel. > > > > Indeed if the sink doesn't set MIPI_DSI_MODE_LPM / > > MIPI_DSI_MSG_USE_LPM, then the expectation is that any data transfer > > will be in HS mode. > > > > That makes me confused as to the need for this patch. > > Yeah, and it looks like that would break the expectation that, in > enable, a bridge can expect its controller to be in HS mode. > > I think that was Jagan is trying to do is to work around an issue with > the Allwinner DSI driver: > https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/su= n6i_mipi_dsi.c#L775 Correct and I can see it seems to be a classic DSI sequence observed in dw-mipi-dsi as well - based on Neil's comments. https://lore.kernel.org/all/9aa3d19d-4378-aaf3-6857-c40be5d252c7@baylibre.c= om/ In fact, I did follow and initialize the command-mode mode_set which set low-speed DCS and switch back to video-mode @enable and switch to HS but could see the same issue as the host cannot accept DCS as before (I might implement improper sequence, but not sure due to lack of documentation). But this sequence has issues with calling post_disable twice even on dw-mipi-dsi. May be Neill, can comment here? Thanks, Jagan.