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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E13A7C5518B for ; Wed, 22 Apr 2020 17:24:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C14EF2082E for ; Wed, 22 Apr 2020 17:24:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="fAz/SXRp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726769AbgDVRX7 (ORCPT ); Wed, 22 Apr 2020 13:23:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726057AbgDVRX7 (ORCPT ); Wed, 22 Apr 2020 13:23:59 -0400 Received: from mo6-p01-ob.smtp.rzone.de (mo6-p01-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5301::5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 707F2C03C1A9; Wed, 22 Apr 2020 10:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587576236; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=0rEv5vtIu8s1R6u/s9ENbcEJ/9O1X+purU+T3mOlO00=; b=fAz/SXRpNvzrZQnNuQiahgyYTCE3Hh0/g3eciq8IQbb/HgOe9SnL2LFDjQUv71eNpS jBqT6wKEtvRXoGgALTV9RxbkON6TB8UKjx2cwIMGhCFQwpr8or34KOZA9fOTCfnwt2+E 2vGICsVFvQKGjdHmgY6LUTOv99B5puvReTv67b5amKJJfMhuYRSW4Mw8qzAU4t2585vt ftf5m5mJQef7KZiKjGqeM2xAZ1vl7I1D7R8/7MlesjW22QF+mnZOdcWG3DHrzx1g+sY1 Ro4RPQLTlNP5b7XCDNz2CKa7iOkNML9eh6aY2+tkb6FykalUOZrEQMSP6y+z1ykjhJQp cSrg== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj4Qpw9iZeHmMiw43tskc=" X-RZG-CLASS-ID: mo00 Received: from mbp-13-nikolaus.fritz.box by smtp.strato.de (RZmta 46.6.2 DYNA|AUTH) with ESMTPSA id R0acebw3MHNj3a9 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Wed, 22 Apr 2020 19:23:45 +0200 (CEST) Subject: Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: "H. Nikolaus Schaller" In-Reply-To: Date: Wed, 22 Apr 2020 19:23:52 +0200 Cc: Maxime Ripard , Tony Lindgren , Philipp Rossak , Jonathan Bakker , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , =?iso-8859-1?Q?Beno=EEt_Cousson?= , Ralf Baechle , Paul Burton , James Hogan , Kukjin Kim , Krzysztof Kozlowski , Chen-Yu Tsai , Thomas Bogendoerfer , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , OpenPVRSGX Linux Driver Group , linux-omap , Linux Kernel Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200415130233.rgn7xrtwqicptke2@gilmour.lan> <10969e64-fe1f-d692-4984-4ba916bd2161@gmail.com> <20200420073842.nx4xb3zqvu23arkc@gilmour.lan> <20200421112129.zjmkmzo3aftksgka@gilmour.lan> <20200421141543.GU37466@atomide.com> <20200422065859.quy6ane5v7vsy5tf@gilmour.lan> <1AA57A0C-48E6-49BB-BB9A-2AAFFB371BCD@goldelico.com> <20200422151328.2oyqz7gqkbunmd6o@gilmour.lan> <07923B6C-4CCD-4B81-A98F-E19C43412A89@goldelico.com> To: Paul Cercueil X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, > Am 22.04.2020 um 18:55 schrieb Paul Cercueil : >=20 > Hi Nikolaus, >=20 >=20 > Le mer. 22 avril 2020 =E0 18:09, H. Nikolaus Schaller = a =E9crit : >> Hi Maxime, >>> Am 22.04.2020 um 17:13 schrieb Maxime Ripard : >>> On Wed, Apr 22, 2020 at 09:10:57AM +0200, H. Nikolaus Schaller = wrote: >>>>> Am 22.04.2020 um 08:58 schrieb Maxime Ripard : >>>>>> It also allows to handle different number of clocks (A31 seems to >>>>>> need 4, Samsung, A83 and JZ4780 one) without changing the sgx = bindings >>>>>> or making big lists of conditionals. This variance would be = handled >>>>>> outside the sgx core bindings and driver. >>>>> I disagree. Every other GPU binding and driver is handling that = just fine, and >>>>> the SGX is not special in any case here. >>>> Can you please better explain this? With example or a description >>>> or a proposal? >>> I can't, I don't have any knowledge about this GPU. >> Hm. Now I am fully puzzled. >> You have no knowledge about this GPU but disagree with our proposal? >> Is it just gut feeling? >> Anyways, we need to find a solution. Together. >>>> I simply do not have your experience with "every other GPU" as you = have. >>>> And I admit that I can't read from your statement what we should do >>>> to bring this topic forward. >>>> So please make a proposal how it should be in your view. >>> If you need some inspiration, I guess you could look at the mali and = vivante >>> bindings once you have an idea of what the GPU needs across the SoCs = it's >>> integrated in. >> Well, I do not need inspiration, we need to come to an agreement = about >> img,pvrsgx.yaml and we need some maintainer to finally pick it up. >> I wonder how we can come to this stage. >> If I look at vivante,gc.yaml or arm,mali-utgard.yaml I don't >> see big differences to what we propose and those I see seem to come >> from technical differences between sgx, vivante, mali etc. So there >> is no single scheme that fits all different gpu types. >> One thing we can learn is that "core" seems to be a de facto standard >> for the core clock-name. An alternative "gpu" is used by = nvidia,gk20a.txt. >=20 > The Vivante GPU binding requires "bus", "core" and "shader" clocks. = But if your SoC only has one clock for the GPU, there's nothing that = prevents you from passing the very same clock as "bus", "core" and = "shader". This is what we do on the Ingenic JZ4770 SoC. Fine and good to know. Well, for the SGX we so far only know a single "core" clock (with = different names). Only the A31 seems to be different. Fortunately I finally found a little time to scan through the a31 user manual: = http://dl.linux-sunxi.org/A31/A31%20User%20Manual%20V1.20.pdf There are 3 clock dividers. And there is a single clock PLL8 dedicated = to the gpu. The clock dividers are called "gpu core", "gpu mem", "gpu hyd". Then, there are dedicated clock gating registers. And idle/power status registers. Unfortunately, chapter "5.1. GPU" is almost empty and has no block = diagram. So I have no idea what "HYD" stands for. And if the memory and HYD = clocks are needed and how they should be initialized. If they are different = ones or can all be driven by PLL8 in parallel. That scarce information makes it difficult to form a "proper" bindings document out of it. Any can fit or be false. At least there is something common with all other SGX implementations I am aware of: there is a "core" clock. So I'd suggest to get things moving forwards: * we add a "core" clock-names to the bindings * this can't be wrong for the A31 since it is defined in the data sheet * we make it optional since the omap chips have a clock wrapper * "core" is a name I think all architectures/drivers can live with and can add later "shader", "bus" etc. if needed * any additions for the A31 will be additions If that sounds ok and nobody objects to it, I can submit a new patch version for further review. BR and thanks, Nikolaus