Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp664010pxj; Fri, 14 May 2021 12:29:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjRXxg3z//q5oYp+2KqzEPrTtWlKBFSd22JY2tD9Tgv7pPPZahEruAOd+Em11gbI+rFf4v X-Received: by 2002:a17:906:7fd2:: with SMTP id r18mr45735341ejs.78.1621020571915; Fri, 14 May 2021 12:29:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621020571; cv=none; d=google.com; s=arc-20160816; b=nxplGuE+l196M6MTcxGLFtpQRGJowN8qwFtdU3lT8IZu5rEMLOCWlGpcMJ7/VXewro Toy0Z/jdUHasj4NKVjzD5evejWI/nWOL8z83A8pLENcq1WAABoXrEEcwJx+yKiRzXjky xq2PzUKsTDHGPwOCg011EoVytKJWolU09JND65iMfNhxvJ8qss8ke660wt06dXIOkIwu tjDHB9kf5ERb+Kr5DEx6itZNW3miHAuOfiN0+IM+Yo2t9nKb+0P/Xdl3KRLP04t4cBhW ukEECD8re6314XzRE9ciu+KCZMpIs24Myte4lhSnCNmNL6lN7a+ux8j7H/z+Tv6Txzrv 4xTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=swYrVy4kpBBJEjC/Hd6FJ6QumSu/RFpoHoG/dt3MbD0=; b=rA0b4WZi9KcrSeF/Ti38Td5zCGjD8jfyB79NKuec4s0ZBf6ADDWoe8V0vtQh/oCgkd RBPm3HapZ7WjlRnd1CcRQrwBKji41A7DlXkqisRG9p++hQ4+bd0GQBm8E6gvhNTg3oqk CLak9IhLH7n6+jiOhyA9ieyWp1mZt+Xn4NYw27o6b9cRgTF8w/kk5R4/7iNChC656GDJ Y2d4WIav8Tv8uEszYxsWl0ncQOIeRqL1AzV+rTgxp0lfytFxbtnmJrjRRbTtI7tUFIHP 78H7iDBCm8ukK2Gv+xKhoQM+MnW2lHwS9zRpZmeHQ5ngqBQawvdwKa2WOd9k9i01JO6S nbrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b11si7076915ejq.727.2021.05.14.12.29.08; Fri, 14 May 2021 12:29:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233455AbhENP2Y (ORCPT + 99 others); Fri, 14 May 2021 11:28:24 -0400 Received: from foss.arm.com ([217.140.110.172]:51434 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231419AbhENP2X (ORCPT ); Fri, 14 May 2021 11:28:23 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E6FEA1713; Fri, 14 May 2021 08:27:11 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6D6293F718; Fri, 14 May 2021 08:27:09 -0700 (PDT) Subject: Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU To: Neil Armstrong , Ezequiel Garcia Cc: Nicolas Boichat , Rob Herring , Alyssa Rosenzweig , devicetree , Tomeu Vizoso , fshao@chromium.org, David Airlie , Linux Kernel Mailing List , Rob Herring , Boris Brezillon , "moderated list:ARM/Mediatek SoC support" , dri-devel , hsinyi@chromium.org, Matthias Brugger , hoegsberg@chromium.org, linux-arm-kernel References: <20210421052855.1279713-1-drinkcat@chromium.org> <373d0803-8658-9413-2f51-1e9804c39126@baylibre.com> From: Steven Price Message-ID: Date: Fri, 14 May 2021 16:27:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <373d0803-8658-9413-2f51-1e9804c39126@baylibre.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/05/2021 15:48, Neil Armstrong wrote: > On 13/05/2021 16:55, Ezequiel Garcia wrote: >> Hi Neil, >> >> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote: >>> >>> Hi, >>> >>> On 21/04/2021 07:28, Nicolas Boichat wrote: >>>> Hi! >>>> >>>> This is just a rebase of the v11, untested (but it seems like >>>> Neil Armstrong recently tested it), with small changes in >>>> binding and dts. v11 cover follows: >>>> >>>> Follow-up on the v5 [1], things have gotten significantly >>>> better in the last year, thanks to the efforts on Bifrost >>>> support by the Collabora team (and probably others I'm not >>>> aware of). >>>> >>>> I've been testing this series on a MT8183/kukui device, with a >>>> chromeos-5.10 kernel [2], and got basic Chromium OS UI up with >>>> mesa 20.3.2 (lots of artifacts though). >>>> >>>> devfreq is currently not supported, as we'll need: >>>> - Clock core support for switching the GPU core clock (see 2/4). >>>> - Platform-specific handling of the 2-regulator (see 3/4). >>>> >>>> Since the latter is easy to detect, patch 3/4 just disables >>>> devfreq if the more than one regulator is specified in the >>>> compatible matching table. >>>> >>>> [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drinkcat@chromium.org/ >>>> [2] https://crrev.com/c/2608070 >>>> >>>> Changes in v13: >>>> - devfreq: Fix conflict resolution mistake when rebasing, didn't >>>> even compile. Oops. >>>> >>>> Changes in v12: >>>> - binding: Fix min/maxItems logic (Rob Herring) >>>> - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). >>>> >>>> Changes in v11: >>>> - binding: power-domain-names not power-domainS-names >>>> - mt8183*.dts: remove incorrect supply-names >>>> >>>> Changes in v10: >>>> - Fix the binding to make sure sram-supply property can be provided. >>>> >>>> Changes in v9: >>>> - Explain why devfreq needs to be disabled for GPUs with >1 >>>> regulators. >>>> >>>> Changes in v8: >>>> - Use DRM_DEV_INFO instead of ERROR >>>> >>>> Changes in v7: >>>> - Fix GPU ID in commit message >>>> - Fix GPU ID in commit message >>>> >>>> Changes in v6: >>>> - Rebased, actually tested with recent mesa driver. >>>> - Add gpu regulators to kukui dtsi as well. >>>> - Power domains are now attached to spm, not scpsys >>>> - Drop R-B. >>>> - devfreq: New change >>>> - Context conflicts, reflow the code. >>>> - Use ARRAY_SIZE for power domains too. >>>> >>>> Changes in v5: >>>> - Rename "2d" power domain to "core2" >>>> - Rename "2d" power domain to "core2" (keep R-B again). >>>> - Change power domain name from 2d to core2. >>>> >>>> Changes in v4: >>>> - Add power-domain-names description >>>> (kept Alyssa's reviewed-by as the change is minor) >>>> - Add power-domain-names to describe the 3 domains. >>>> (kept Alyssa's reviewed-by as the change is minor) >>>> - Add power domain names. >>>> >>>> Changes in v3: >>>> - Match mt8183-mali instead of bifrost, as we require special >>>> handling for the 2 regulators and 3 power domains. >>>> >>>> Changes in v2: >>>> - Use sram instead of mali_sram as SRAM supply name. >>>> - Rename mali@ to gpu@. >>>> >>>> Nicolas Boichat (4): >>>> dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 >>>> arm64: dts: mt8183: Add node for the Mali GPU >>>> drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 >>>> drm/panfrost: Add mt8183-mali compatible string >>>> >>>> .../bindings/gpu/arm,mali-bifrost.yaml | 30 ++++- >>>> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + >>>> .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + >>>> .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + >>>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++++++++++++++++++ >>>> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ >>>> drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ >>>> 7 files changed, 168 insertions(+), 1 deletion(-) >>>> >>> >>> Seems this version is ready to be applied if we get a review on the DT ? >>> >>> Mathias ? could you have a look ? >>> >> >> Given Rob has Acked the DT bindings, I think it's OK to apply patches >> 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes. >> >> My two unsolicited cents :-) You make a convincing point - and if everyone is happy for the DT changes to be handled separately I don't see a reason for the other patches to be held up. > Yeah sure, is there a panfrost maintainer in the room ? I can apply them if you ack me. I seem to be applying most Panfrost changes these days, so I'll save you the effort and push 1,3,4 to drm-misc-next. Thanks, Steve