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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFE40C433EF for ; Sun, 3 Oct 2021 20:09:56 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ADEE7611F2 for ; Sun, 3 Oct 2021 20:09:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ADEE7611F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6A3B46E881; Sun, 3 Oct 2021 20:09:54 +0000 (UTC) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by gabe.freedesktop.org (Postfix) with ESMTPS id 64E006E880 for ; Sun, 3 Oct 2021 20:09:52 +0000 (UTC) Received: by mail-wm1-x330.google.com with SMTP id b136-20020a1c808e000000b0030d60716239so3569745wmd.4 for ; Sun, 03 Oct 2021 13:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jEAW2JDycPrYbnmrUhgv36yBgTx5v6E09lPMQlvzCRM=; b=hWH4k5HOvygjKKNcDdamAbSwFECinkYE/CxaQE1LmVRZddWH4zv9gQ6oDqWrAZxka4 QLHPGOQ6r3ZS2t7BlQqcdtuEPWeiRoyPIaiseCq261bjKl3vwqAb99t4SPpnE9NlEs5R Zpa2fxfbiH6ld0uM/YRi5efsqN5TYxLAdEhLM7G88+VrtP4ZVr/oX7jCVccfX/rst/0h kj9kDfPH+FI5RVxFYItyFnP5aCLA6NpcUAvudiem/So6PACb05MdrjH8HN5zuybz+J4Q q3yty092tskhviHiDiXj7bt5IJOvc9tr5naDl2hSBqgdWDWD9QfRswMbbdTN3y7uBJwW oyRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jEAW2JDycPrYbnmrUhgv36yBgTx5v6E09lPMQlvzCRM=; b=s5S72GJd5EAvgnVTpObO5/EdioiEzomnDdnDRSwCDAXvGrMauRbeoI4cHbA4XsPdir 45PpRkC3skBi23Ope/ZX0fE/3IKEs6UkefsnYyrJDlqYldRyZQVLJRbJ0MWsP5XB8wsx zt3XlDiwtrqTJygSrcbcqzkEQ1EboTHAHFLg1Dxq4bHGC/OGDWc43d2nMNdnmehWvRUt tUi8SGZXvl6EJbLZNmYoXZVkKUNkKD2ncvGeH0XQR1chMIrWqJnzGcpugS7J8WRGIkwA 4qDM0TqCcAuhi2CWvOWMkjxrPMVF0opjkkwIFoXjCK1ktQ6SKNZtG+b2Fgzfc63cPEoP sTrg== X-Gm-Message-State: AOAM53381wR9GzCGC+48UuFhXPcX9uCt16lzuvgZZxmsDlsYZwHjyebd uLB7QZg/S7zEno95sxuoA9E= X-Google-Smtp-Source: ABdhPJzYwjzAKP1V/lVGtyNTF8UAtIkwPGTrL1vjoZFASQjjSNshv8vl95gUctiJ47zXQ/uhzU5xSA== X-Received: by 2002:a1c:a9d3:: with SMTP id s202mr6327534wme.128.1633291790673; Sun, 03 Oct 2021 13:09:50 -0700 (PDT) Received: from [192.168.0.14] (095160158079.dynamic-2-waw-k-4-2-0.vectranet.pl. [95.160.158.79]) by smtp.gmail.com with ESMTPSA id i6sm1706254wrv.61.2021.10.03.13.09.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Oct 2021 13:09:50 -0700 (PDT) Subject: Re: Questions over DSI within DRM. To: Laurent Pinchart , Maxime Ripard Cc: Dave Stevenson , DRI Development , Kieran Bingham References: <20210706151320.kwn4dwu6buvy4isa@gilmour> <20210715095022.5plcocz6plxnb3xr@gilmour> From: Andrzej Hajda Message-ID: Date: Sun, 3 Oct 2021 22:09:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, Thanks Laurent for reviving the thread, I have missed it entirely. On 03.10.2021 16:16, Laurent Pinchart wrote: > Hello, > > Reviving a bit of an old thread. > > On Thu, Jul 15, 2021 at 11:50:22AM +0200, Maxime Ripard wrote: >> On Tue, Jul 06, 2021 at 05:44:58PM +0100, Dave Stevenson wrote: >>> On Tue, 6 Jul 2021 at 16:13, Maxime Ripard wrote: >>>>>>> On a similar theme, some devices want the clock lane in HS mode early >>>>>>> so they can use it in place of an external oscillator, but the data >>>>>>> lanes still in LP-11. There appears to be no way for the >>>>>>> display/bridge to signal this requirement or it be achieved. >>>>>> >>>>>> You're right. A loooong time ago, the omapdrm driver had an internal >>>>>> infrastructure that didn't use drm_bridge or drm_panel and instead >>>>>> required omapdrm-specific drivers for those components. It used to model >>>>>> the display pipeline in a different way than drm_bridge, with the sync >>>>>> explicitly setting the source state. A DSI sink could thus control its >>>>>> enable sequence, interleaving programming of the sink with control of >>>>>> the source. >>>>>> >>>>>> Migrating omapdrm to the drm_bridge model took a really large effort, >>>>>> which makes me believe that transitioning the whole subsystem to >>>>>> sink-controlled sources would be close to impossible. We could add >>>>>> DSI-specific operations, or add another enable bridge operation >>>>>> (post_pre_enable ? :-D). Neither would scale, but it may be enough. >>>>> >>>>> I haven't thought it through for all generic cases, but I suspect it's >>>>> more a pre_pre_enable that is needed to initialise the PHY etc, >>>>> probably from source to sink. > > I believe it could be implemented as a pre-pre-enable indeed. It feels > like a bit of a hack, as the next time we need more fine-grained control > over the startup sequence, we'll have to add a pre-pre-pre-enable. Given > that the startup sequence requirements come from the sink device, it > would make sense to let it explicitly control the initialization, > instead of driving it from the source. I don't think we'll be able to > rework the bridge API in that direction though, so I'm fine with a hack. As I remember I have suggested in similar discussion [1] adding to mipi_dsi_host_ops requested operations: power_on - power on DSI bus (do we really need it?) init - enter LP11 (or HS-stop state if I remember correctly) and then call them from the right place in DSI device, probably pre_enable callback. This way we could avoid polluting drm_bridge_ops, with DSI specific stuff. [1]: https://lore.kernel.org/dri-devel/6700c90f-d0e0-5cbf-1616-0c1d158441b1@samsung.com/#t Sorry for addressing only this issue, but I need to read whole thread, to re-read whole thread, and today it is too late for me :) Regards Andrzej