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 X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52212C2D0A3 for ; Thu, 29 Oct 2020 08:51:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 BCE7520791 for ; Thu, 29 Oct 2020 08:51:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eMR5mejL"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="kqfds7Bp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCE7520791 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7wY0GIpNfmzbhzwbwUo1uQnnDZBysn2sCS1+zEJl8bM=; b=eMR5mejLUK0V8W+L6eisSfhs6 M7NzQLK/mULJrmxjSUQAIG8McJif5YfVXoOE32PluJrNLhBLq0lFY4EDHXp1W6Pot+41HW/i6oe0M bN5vTWPZHOiSPRW4z96Hf5HJ6oJmzYGru2v9hgVBVDHfoq0yf74P9xl6v8PwB4JITy/rHh+XlS8ks sbEo1wPl1CVyPYyb8kJhVnECbARo3c8XB22rCZagwMposQw6fHT+tKDpFABp1jYx2trA05+rKl5BC PcBQcme+rT59wHCPpt7h+Qxcki0WVYC3ybin6REqjCXhxKTx/g4kc0O3wManm357tCsdqvKWRtStb 9maFc65qQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kY3eL-0002nr-BK; Thu, 29 Oct 2020 08:51:13 +0000 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kY3eH-0002nC-Dr for linux-arm-kernel@lists.infradead.org; Thu, 29 Oct 2020 08:51:10 +0000 Received: by mail-wm1-x342.google.com with SMTP id v5so1602646wmh.1 for ; Thu, 29 Oct 2020 01:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=cDd95LZV0TwPx9wdyCCMZmzh5fYR+hqDBeGlboAji9U=; b=kqfds7Bp4W6z9KuFzDVR9T6Tl5PsxJrR2qLNmSLLkDSDx2OgCHeINisTB3uGekRXcH ypFsRLcJCs2y9YfPBOA99oCYcwZwKLznndQiMldjMbpQ3QW14jCqMF35J3uqY5AUP7FH TDWJ5LckfasONVE1r8EFkrgF2J/7z2TR2T658= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cDd95LZV0TwPx9wdyCCMZmzh5fYR+hqDBeGlboAji9U=; b=IrgUMdTVMN8HbXmuwbtBU7eXPVrdR1LeT7lpLd3zqLQrd3ZFrOvWd95urX/bF8gzF6 +kwVLwSu06JKGUxUgUdMsmG8y/YQ4Grf1w3945zE5nK6mHKjXj3a2Rh6t1RQ4xPkJzhP 4cQdCEqOgPaiDsV+Z5qlJWpzOGYCwdRPa/PYP39pyXSOaG9gNIr23clEP48gIw1TgKI+ xLPWkHXaiFyV70udzM3uauk6GKfzq2WNFTKSS+RlAX6GSv0iCgLXzb1dylbUbnmhKhPs R64Jdgueb0zTGtYYzo/hUzxprDCPkwdxiqTm8PxqYQ7Clo9JhYqSvpWT8bFynF+y5y6B yF8g== X-Gm-Message-State: AOAM532KQxgdU4RKwfRs6bIGzaHmZ+6zRjpfhnZUTTWk3RHv1+LO/VIx Q6AeY34pBY+QlMYYxxH8xh9rqQ== X-Google-Smtp-Source: ABdhPJx8StI6TRBf10Vf2PWnL/5voNMrzNUFCeJkXzaHkB7puxbbn91kh3E9XUeAD8WZA4ySma0R1Q== X-Received: by 2002:a1c:9a93:: with SMTP id c141mr3345421wme.168.1603961467630; Thu, 29 Oct 2020 01:51:07 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id f7sm3892055wrx.64.2020.10.29.01.51.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Oct 2020 01:51:06 -0700 (PDT) Date: Thu, 29 Oct 2020 09:51:04 +0100 From: Daniel Vetter To: Maxime Ripard Subject: Re: [PATCH v2 4/7] drm/vc4: kms: Document the muxing corner cases Message-ID: <20201029085104.GA401619@phenom.ffwll.local> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201029_045109_539802_5988C103 X-CRM114-Status: GOOD ( 34.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Tim Gover , Dave Stevenson , David Airlie , Maarten Lankhorst , dri-devel@lists.freedesktop.org, Phil Elwell , Eric Anholt , Rob Herring , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, Thomas Zimmermann , Daniel Vetter , Frank Rowand , Hoegeun Kwon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 28, 2020 at 01:41:01PM +0100, Maxime Ripard wrote: > We've had a number of muxing corner-cases with specific ways to reproduce > them, so let's document them to make sure they aren't lost and introduce > regressions later on. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/vc4/vc4_kms.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c > index 4aa0577bd055..b0043abec16d 100644 > --- a/drivers/gpu/drm/vc4/vc4_kms.c > +++ b/drivers/gpu/drm/vc4/vc4_kms.c > @@ -612,6 +612,28 @@ static const struct drm_private_state_funcs vc4_load_tracker_state_funcs = { > }; > > > +/* > + * The BCM2711 HVS has up to 7 output connected to the pixelvalves and > + * the TXP (and therefore all the CRTCs found on that platform). > + * > + * The naive (and our initial) implementation would just iterate over > + * all the active CRTCs, try to find a suitable FIFO, and then remove it > + * from the available FIFOs pool. However, there's a few corner cases > + * that need to be considered: > + * > + * - When running in a dual-display setup (so with two CRTCs involved), > + * we can update the state of a single CRTC (for example by changing > + * its mode using xrandr under X11) without affecting the other. In > + * this case, the other CRTC wouldn't be in the state at all, so we > + * need to consider all the running CRTCs in the DRM device to assign > + * a FIFO, not just the one in the state. > + * > + * - Since we need the pixelvalve to be disabled and enabled back when > + * the FIFO is changed, we should keep the FIFO assigned for as long > + * as the CRTC is enabled, only considering it free again once that > + * CRTC has been disabled. This can be tested by booting X11 on a > + * single display, and changing the resolution down and then back up. This is a bit much. With planes we have the same problem, and we're solving this with the drm_plane_state->commit tracker. If you have one of these per fifo then you can easily sync against the disabling crtc if the fifo becomes free. Note to avoid locking headaches this would mean you'd need a per-fifo private state object. You can avoid this if you just track the ->disabling_commit per fifo, and sync against that when enabling it on a different fifo. Note that it's somewhat tricky to do this correctly, since you need to copy that commit on each state duplication around, until it's either used in a new crtc (and hence tracked under that) or the commit has completed (but this is only an optimization, you could just keep them around forever for unused fifo that have been used in the past, it's a tiny struct with nothing hanging of it). -Daniel > + */ > static int vc4_pv_muxing_atomic_check(struct drm_device *dev, > struct drm_atomic_state *state) > { > -- > git-series 0.9.1 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel