From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753454AbdDKUwh (ORCPT ); Tue, 11 Apr 2017 16:52:37 -0400 Received: from gloria.sntech.de ([95.129.55.99]:44340 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753424AbdDKUwe (ORCPT ); Tue, 11 Apr 2017 16:52:34 -0400 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Guillaume Tucker Cc: Neil Armstrong , Rob Herring , Mark Rutland , devicetree@vger.kernel.org, Sjoerd Simons , Wookey , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, John Reitan , Enric Balletbo i Serra , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU Date: Tue, 11 Apr 2017 22:52:29 +0200 Message-ID: <8676554.1IW2xieEGM@diego> User-Agent: KMail/5.2.3 (Linux/4.8.0-2-amd64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <936a53ee-2ed8-11e4-a860-744256676af9@collabora.com> References: <936a53ee-2ed8-11e4-a860-744256676af9@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Guillaume, Am Dienstag, 11. April 2017, 18:40:37 CEST schrieb Guillaume Tucker: > On 03/04/17 09:12, Neil Armstrong wrote: > > On 04/02/2017 09:59 AM, Guillaume Tucker wrote: > >> +Optional: > >> + > >> +- clocks : Phandle to clock for the Mali Midgard device. > >> +- clock-names : Shall be "clk_mali". > >> +- mali-supply : Phandle to regulator for the Mali device. Refer to > >> + Documentation/devicetree/bindings/regulator/regulator.txt for details. > >> +- operating-points : Refer to > >> Documentation/devicetree/bindings/power/opp.txt + for details. > > > > Please add : > > * Must be one of the following: > > "arm,mali-t820" > > > > * And, optionally, one of the vendor specific compatible: > > "amlogic,meson-gxm-mali" > > > > with my Ack for the amlogic platform. > > It seems to me that as long as the GPU architecture hasn't been > modified (I don't think I've ever encountered such a case) then > it has to be a standard ARM Mali type regardless of the SoC > vendor. So unless a Mali-T820 in the Amlogic S912 SoC is not the > same as a T820 in a different SoC, please forgive me but I don't > understand why a vendor compatible string is needed. My main > concern is that it's going to be very hard to keep that list > up-to-date with all existing Midgard SoC variants. If do we need > to add vendor compatible strings to correctly describe the > hardware then I'm happy to add the amlogic one in my patch v3; I > would just like to understand why that's necessary. SoC vendors in most cases hook ip blocks into their socs in different and often strange ways. After all it's not some discrete ic you solder onto a board, but instead a part of the soc itself. So in most cases you will have some hooks outside the actual gpu iospace that can be used to tune different things about how the gpu interacts with the system. Which is probably also the reason the midgard kernel driver has this ugly "platform" subdirectory for compile-time platform selection. On my rk3288 for example we have [0] in the chromeos tree, that handles the oddities of the midgard on the rk3288 used in a lot of Chromebooks. There are soc-specific oddities of frequencies, frequency-scaling and whatnot. And there are also more gpu-specific setting in syscon areas of the soc (pmu and grf) that can also influence the gpus performance and might need tweaking at some point. That doesn't even take into account that there may even be differences on how things are synthesized that we don't know about. See all the variants of the dw_hdmi ip block (imx, rockchip, meson [more?]) . So we really want to have the special compatibles in place, to be prepared for the future per-soc oddities that always appear :-) . Heiko [0] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/gpu/arm/midgard/platform/rk/