Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1278032imm; Tue, 5 Jun 2018 11:51:28 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJHtKWitiUPZrhhOEKIZHAOOpkRqRkelnM4EVAux5K6LsHoYCcPoU+2HFuKlgUoiVK87+j4 X-Received: by 2002:a65:4146:: with SMTP id x6-v6mr21811424pgp.221.1528224688295; Tue, 05 Jun 2018 11:51:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528224688; cv=none; d=google.com; s=arc-20160816; b=uUjpf0EB0CguKGeM/T0tGmHsz4iT3u+d6qxx0ha5Jy4juWimJVJMNu0uHWF+TPylIZ bibgN7LTE62SpVXqp9ZlkZteQwk1pIfzWWExULce1f4weMLZhxXqFr3xJpEoLR2EkkbX mStATKnOxpjumJbkqV9U0ynt3U+W/J3pot2U0yGnwBM4jgA3/NHXVuZ1bV5j//CTCSfm ZDSuBwCU0p7Mv+hhR3AMCTzi5VureBRPS7o2Dh0VyzuVa036OFtKkQPXx61ZMTGhRGgU /lCcPr5u8mEVvcaRiJ3/Xngu7xPqDcW3umI04ouJeAeEoU1/Py1hHM5uJMaMpvjTMxRG w/LA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from :arc-authentication-results; bh=fV2RbWKmKZgpxEdkbCp0Oh7KRg6K7utIyM7xoFKvOyM=; b=mZVjcYFukvO1r0xcM0Lp6YpUQZlvQfPREksYkqszVrARsRnzf+j9lY+csXyd7gWas8 xqy4qKgMsvW+s47JWSCGN9mgZpyP30+kZbaUH8Fg1Of3Ffn5UvJt7urraBSz9lNWzcIK HqfiEoqQ/EnlnXmQKrYqt9ks8thUkjEv84qYAqt3Sg95ljKK1MLj/HtIUL0O7MuVMmoD KHWCZI71SftoQUsnTzb8Y3QNOstCcRhmHjab0XW2vqXGHJxezqWVZbCtgMH/MOFwOTVh lEKa5aKzhOPafTXd+zcF0MUlH+C3TxIGuSOYxwNwZyO4iFy4DcTKCufwvOpukzKEdSMu zwqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k6-v6si11973458pgk.256.2018.06.05.11.51.14; Tue, 05 Jun 2018 11:51:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751926AbeFESt6 (ORCPT + 99 others); Tue, 5 Jun 2018 14:49:58 -0400 Received: from anholt.net ([50.246.234.109]:40434 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751816AbeFESt5 (ORCPT ); Tue, 5 Jun 2018 14:49:57 -0400 Received: from localhost (localhost [127.0.0.1]) by anholt.net (Postfix) with ESMTP id 74F8410A1642; Tue, 5 Jun 2018 11:49:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at anholt.net Received: from anholt.net ([127.0.0.1]) by localhost (kingsolver.anholt.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pLF57ZBegG3F; Tue, 5 Jun 2018 11:49:54 -0700 (PDT) Received: from eliezer.anholt.net (localhost [127.0.0.1]) by anholt.net (Postfix) with ESMTP id B9B1710A0F77; Tue, 5 Jun 2018 11:49:54 -0700 (PDT) Received: by eliezer.anholt.net (Postfix, from userid 1000) id 3C3192FE2D7C; Tue, 5 Jun 2018 11:49:54 -0700 (PDT) From: Eric Anholt To: Andrzej Hajda , dri-devel@lists.freedesktop.org Cc: Kevin Quigley , Boris Brezillon , linux-kernel@vger.kernel.org, James Hughes , Archit Taneja Subject: Re: [PATCH] drm/vc4: Enable the DSI module and link before other enables. In-Reply-To: <20180605082532eucas1p21328ec5bea7d588c81480829f862bdfd~1NhnMydDJ0562405624eucas1p2l@eucas1p2.samsung.com> References: <20180604194437.13790-1-eric@anholt.net> <20180605082532eucas1p21328ec5bea7d588c81480829f862bdfd~1NhnMydDJ0562405624eucas1p2l@eucas1p2.samsung.com> User-Agent: Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/25.2.2 (x86_64-pc-linux-gnu) Date: Tue, 05 Jun 2018 11:49:53 -0700 Message-ID: <87lgbtt6em.fsf@anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Andrzej Hajda writes: > On 04.06.2018 21:44, Eric Anholt wrote: >> We want the DSI PHY to be enabled and the DSI module clocked before a >> panel or bridge's prepare() function, since most DSI panel drivers >> with a prepare() hook are doing DCS transactions inside of them. >> >> Signed-off-by: Eric Anholt >> Cc: Kevin Quigley >> Cc: James Hughes >> Cc: Boris Brezillon >> --- >> >> I'm not sure it makes sense to enable CRTCs before encoders on vc4 at >> all. Why start scanning pixels before the encoder is ready to hear >> about VSTART? However, this patch will hopefully unblock people >> trying to attach other panels to rpi > > But this patch is about enabling encoder before panel/bridge prepare. Or > am I missing something. > Anyway I would be more precise here, MIPI-DSI bus is used for two things: > - control bus - accessing DSI device (configuration/detection,...), > - video data bus - sending video stream. > > I suspect in prepare/pre_enable phase of DSI panel/bridge only control > bus should be functional, video stream transfer does not make sense. > So the best solution (I guess) would be to split DSI-encoder enable > sequence into control bus enable and video transfer enable parts and > call the former before 1st transfer request from device and the latter > in encoder enable callback. Of course there will be a problem then with > disabling sequence, ie stopping video stream should be performed in > encoder's disable, but when we should disable control bus? If we do it > in encoder's disable callback we could not perform transfers in > post_disable cb of the bridge - in most cases (maybe all currently > present in kernel) it will work, but it does not look ideal. > All this recalls me discussion that hardwiring bridge callbacks into drm > core is problematic and maybe it would be better to call downstream > callbacks explicitly from upstream element - the callback order should > depend on the local bus protocol, and should not be fixed in drm core. It does seem like for DSI encoders they generally would need to be able to control when the call down to the bridge happens. However, from my experience with panels, drivers are bad about calling both prepare and enable, if their particular panel only cares about one of them. So, how about: - encoders can call drm_bridge_disable_midlayer_calls() (any naming suggestions?) to flag this bridge as not wanting the calls from the atomic helpers. - atomic helpers WARN if bridge midlayer_calls flag was set and drm_bridge_pre_enable/enable/disable/post_disable failed to be called by the encoder - drm_bridge_detach() clears disable_midlayer_calls flag for the next encoder --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlsW21EACgkQtdYpNtH8 nugQUg//QG8RdjfWVnErEusS3Hgz6j3s13xE2CYARmN71xz8wIrezEjJCcS7BFnE 6RIhGKBpityf29/bmEsIMGey+jkW0FgshAY3Z0v+q0dvj0hmge9qsMBSxRm4RCHL mIXPa8KLndCUpiFKNLrwG7yNAo6aR3fn5E2Pdt+9wh1Ry8Mod+uSJH3s0SxL4+/s 66VmO2BlCnJKt1wWPNQ5qM+PqEapjpLmJvA3czN6NnvOlUasasr6eb8wIeTKHuTo rg3iT7DqLvITRXidRv4ZMLPRZLhqnpObp3ApyEElToMFaYDgvu5VkMLJbzqA4+U3 cXGnjx9TV+D3iQG092GUV6GqFGI99OxGeGbx9A2NlUPuKlObo0HbFmX8qWWKBgCK QsM+AYanClEFrofAyhLWY9RyvsRGS407cVpoy/tmpaZrais9oS862p1r4Ga1L9oB 8bHQPHazAOuRj9TkYr3yiIPTr4Kn/gKyZFymOo6pGgL6kezXcy8fLm/EW73bWJdB nYchbQd7ri/TPJWCcN8wBlxH7DSqECPeRyr9QSjfhO8yOWW1oiWi7bsuA6BdLVh3 qmImGeM0PK6wNbIAWsrGIAoJyIhqVLgI0leOomKJ13KWQDZly4EO4mNpsx9C8g7U yPME2kVFijK0+Xda/OR8xwp9ULyzzShfuKYkxK5wdBBMqbj1pXE= =zJgH -----END PGP SIGNATURE----- --=-=-=--