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 0B8FAC5518C for ; Wed, 22 Apr 2020 16:09:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DB7F420776 for ; Wed, 22 Apr 2020 16:09:26 +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="Z92zmf5z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727002AbgDVQJ0 (ORCPT ); Wed, 22 Apr 2020 12:09:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726183AbgDVQJY (ORCPT ); Wed, 22 Apr 2020 12:09:24 -0400 Received: from mo6-p02-ob.smtp.rzone.de (mo6-p02-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5302::9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBBE2C03C1A9; Wed, 22 Apr 2020 09:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587571762; 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=ceaM0Q57EWu8SAKxL8w74OvIguml9sO5tkQvRprE6B8=; b=Z92zmf5zc5DAwK/4sqYPnPboFccD1cImi6PPOfixec3c/E69kLkMo3qtjNS5JkQh9s RHOnVQnUSzwgID+0WyNm9hsbTcUw1JMGhOmyY1sfMqCrEGQ+n4zm396nzyfHmbU1wPTu vHG8La6UEk+wavIXlNHebRDWldJKTxVdcrO/QJpTkw7Be+O2DwrcnpmSIHoFqg0h1Wzm TB/0Eetbzh9TOHDDy2wNkKXVgf0dc/ur1esrCeOIfyta9SSPQc/qWC7PcgyMqVpZcjAP SR0vj8kipr2LX0Dvx0srUmXJaZmqqabdNUDZRDxLNOs8ckxJ4FkoExkQTh0LskpP1Zw+ 3W/g== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj4Qpw9iZeHmMiw43tskc=" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 46.6.2 DYNA|AUTH) with ESMTPSA id R0acebw3MG923NL (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 18:09:02 +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=us-ascii From: "H. Nikolaus Schaller" In-Reply-To: <20200422151328.2oyqz7gqkbunmd6o@gilmour.lan> Date: Wed, 22 Apr 2020 18:09:01 +0200 Cc: Tony Lindgren , Philipp Rossak , Jonathan Bakker , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Paul Cercueil , Ralf Baechle , Paul Burton , James Hogan , Kukjin Kim , Krzysztof Kozlowski , Chen-Yu Tsai , Thomas Bogendoerfer , "open list:DRM PANEL DRIVERS" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List , linux-omap , OpenPVRSGX Linux Driver Group , Discussions about the Letux Kernel , kernel@pyra-handheld.com, linux-mips@vger.kernel.org, arm-soc , linux-samsung-soc@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <07923B6C-4CCD-4B81-A98F-E19C43412A89@goldelico.com> 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> To: Maxime Ripard 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 Maxime, > Am 22.04.2020 um 17:13 schrieb Maxime Ripard : >=20 > On Wed, Apr 22, 2020 at 09:10:57AM +0200, H. Nikolaus Schaller wrote: >>> Am 22.04.2020 um 08:58 schrieb Maxime Ripard : >>>>=20 >>>> 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. >>>=20 >>> I disagree. Every other GPU binding and driver is handling that just = fine, and >>> the SGX is not special in any case here. >>=20 >> Can you please better explain this? With example or a description >> or a proposal? >=20 > 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. >=20 >> 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. >>=20 >> So please make a proposal how it should be in your view. >=20 > 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=20 for the core clock-name. An alternative "gpu" is used by = nvidia,gk20a.txt. BR and thanks, Nikolaus