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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 802FFC4742C for ; Sat, 31 Oct 2020 12:47:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4E397206CB for ; Sat, 31 Oct 2020 12:47:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604148444; bh=ndOH7hi61IUIAfpZAOwy/FVAFerkwmAJJ+okj4rN0U4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=FmPoBMT883u/wmDJl51zVfSAaHHewJkBjdIxBUcB7g75xF7S9JH6BXL4YOEHXy61j z3fM03E2ofYxIjq2Iw+CHgeWYfvp7hf2X+yqFu9rm2N8iNU+vfGr6NXSM3P7IyB2pP SFnSfW7D0DqX0I/wyZvzAvNvizSJ19Rjgf17awBQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727308AbgJaMrX convert rfc822-to-8bit (ORCPT ); Sat, 31 Oct 2020 08:47:23 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:33696 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726738AbgJaMrW (ORCPT ); Sat, 31 Oct 2020 08:47:22 -0400 Received: by mail-wr1-f65.google.com with SMTP id b8so9354247wrn.0; Sat, 31 Oct 2020 05:47:20 -0700 (PDT) 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:content-transfer-encoding :in-reply-to; bh=+gL7Op3KIBpBphNR+C9mEgS569nJZM4vxaFbpSVbwWo=; b=e1CO85PondYAc5m6el2DSQmEwZHO1oDLOLBz2z5xYIEvTaNlbZ/CPoYjgfysCqqqJ7 61kFMUF/ravAji82JG9Apl+8HPUcN4PuIGtaRW8HsC6DDM2+edjTRBZHNONm381itmcP JfkumnSZXSUtGrjw8Y6DJWOLOhXjFYAkeGqAahxxRa2hZcroXfDS9E5u3RUvVvqC7c4V s/ER6xw9t1rkyDrxpN/C7M2z6Kro1LN4Ql1OUhQMB0Ii6oYDAUBaQNQi/Yo7A5pEmIZG jxCByusNC3LIcUKK1dbfjT9eq9fSbumzao4zV07OLbEvxWTxEO8fSMEG6HgXV37kQhDu iufA== X-Gm-Message-State: AOAM530LJ7dgTN4fqmdAwTxWCFJ4FfW2fXM+/v9GsIdWtYnWTnO0QYJP Ycy+4Joa7NMiT9pnBNJoma8= X-Google-Smtp-Source: ABdhPJw1A1ifmpqW7/JFaic2H98/NtqftCnqT8ZvJegvWDAd8dPgFRVj/GRP3niiuT1wpM0cIHmxrA== X-Received: by 2002:adf:9204:: with SMTP id 4mr1764068wrj.241.1604148440070; Sat, 31 Oct 2020 05:47:20 -0700 (PDT) Received: from kozik-lap (adsl-84-226-167-205.adslplus.ch. [84.226.167.205]) by smtp.googlemail.com with ESMTPSA id 4sm14367078wrp.58.2020.10.31.05.47.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Oct 2020 05:47:18 -0700 (PDT) Date: Sat, 31 Oct 2020 13:47:17 +0100 From: Krzysztof Kozlowski To: Sylwester Nawrocki Cc: georgi.djakov@linaro.org, cw00.choi@samsung.com, devicetree@vger.kernel.org, robh+dt@kernel.org, a.swigon@samsung.com, myungjoo.ham@samsung.com, inki.dae@samsung.com, sw0312.kim@samsung.com, b.zolnierkie@samsung.com, m.szyprowski@samsung.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v7 6/6] drm: exynos: mixer: Add interconnect support Message-ID: <20201031124717.GE9399@kozik-lap> References: <20201030125149.8227-1-s.nawrocki@samsung.com> <20201030125149.8227-7-s.nawrocki@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20201030125149.8227-7-s.nawrocki@samsung.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 30, 2020 at 01:51:49PM +0100, Sylwester Nawrocki wrote: > This patch adds interconnect support to exynos-mixer. The mixer works > the same as before when CONFIG_INTERCONNECT is 'n'. > > For proper operation of the video mixer block we need to ensure the > interconnect busses like DMC or LEFTBUS provide enough bandwidth so > as to avoid DMA buffer underruns in the mixer block. I.e we need to > prevent those busses from operating in low perfomance OPPs when > the mixer is running. > In this patch the bus bandwidth request is done through the interconnect > API, the bandwidth value is calculated from selected DRM mode, i.e. > video plane width, height, refresh rate and pixel format. > > The bandwidth setting is synchronized with VSYNC when we are switching > to lower bandwidth. This is required to ensure enough bandwidth for > the device since new settings are normally being applied in the hardware > synchronously with VSYNC. > > Co-developed-by: Artur Świgoń > Signed-off-by: Marek Szyprowski > Signed-off-by: Sylwester Nawrocki > --- > Changes for v7: > - fixed incorrect setting of the ICC bandwidth when the mixer is > disabled, now the bandwidth is set explicitly to 0 in such case. > > Changes for v6: > - the icc_set_bw() call is now only done when calculated value for > a crtc changes, this avoids unnecessary calls per each video frame > - added synchronization of the interconnect bandwidth setting with > the mixer VSYNC in order to avoid buffer underflow when we lower > the interconnect bandwidth when the hardware still operates with > previous mode settings that require higher bandwidth. This fixed > IOMMU faults observed e.g. during switching from two planes to > a single plane operation. > > Changes for v5: > - renamed soc_path variable to icc_path > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 146 ++++++++++++++++++++++++++++++++-- > 1 file changed, 138 insertions(+), 8 deletions(-) [...] > @@ -1223,19 +1330,33 @@ static int mixer_probe(struct platform_device *pdev) > struct device *dev = &pdev->dev; > const struct mixer_drv_data *drv; > struct mixer_context *ctx; > + struct icc_path *path; > int ret; > > + /* > + * Returns NULL if CONFIG_INTERCONNECT is disabled. You could add here: or if "interconnects" property does not exist. Best regards, Krzysztof