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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 C9BD0C2BA1A for ; Fri, 24 Apr 2020 09:52:08 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8F69F20728 for ; Fri, 24 Apr 2020 09:52:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fMIND6fS"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="EeZyZ9Ar" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F69F20728 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goldelico.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:References:Message-Id:Date: In-Reply-To:From:Mime-Version:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=27Nm6ccO50TqrvkjsDs5ic/bY8tBeQfRcvrPSPB4o4Y=; b=fMIND6fSpvSLLD 7gd0/yFBa0hmlM0LXzirCN9l6koz82p4XEcoRr8QLJRz+8u4KTYm4NBqooNHcy6mQOlHvCSkrm2Av OGfAI8a3b6zqDmiQX7qLMzsqiRGRR9cz3PqF/j2RNgYwQrvEmdJYnQtnOxPD3TGVZN4Rw/Xpz8BjB w/F/w8s725mu8jRtN3we9+oiJspwSLwdFoGZuxJvqRNN4JAyzi85UH00xvKEglZzXtiAbaf32lkJE JKm76GyomPO8G4A9g1vSX+1FJNOmdMXl+q92Jam+jJ8QwhdzHKAU9xgu0Ew7h+VYv4P/P+YNyfffe ZacBA0cous9qXVrHhOfg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRv08-0006DK-Un; Fri, 24 Apr 2020 09:52:04 +0000 Received: from mo6-p02-ob.smtp.rzone.de ([2a01:238:20a:202:5302::5]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRv04-0006Cs-Uh for linux-arm-kernel@lists.infradead.org; Fri, 24 Apr 2020 09:52:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587721918; 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=EADzuRL+YsoGCLSE7b2pLcK0IVG9NS9sozBTxA+ffmU=; b=EeZyZ9ArpJ5P2k/vVA5YYfdyorM53EK6XxqyAiVeMur3hMVJSZbvuDU9hIXcVKoagi kDn8pkYdkV/ejlYYP/M43wGbHkcU0LXhcwWebUu5kAI7t5Dd53TSgTct6Cap/CKRvb6b eq+kCa9iOM8vSvrAdKpKzGwYLoDX8/B/h/XHCSokqKmAIXis+reEfP0AmBDc6ctZwCxS B3MabxZWD+tZs1CCdgwWq4Y2KcioaSNNxYDQc5Uwh0HnHj+TNwYGZsX3Vfkg+lX5z30K Q/5cqgTMIFNg1sULZQx7JYsLjdBnxafJG5cvg4m6/kfkBPjN4Altiwe0/s+jPw7v/VMB H5yg== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj5Qpw97WFDlabXA0JT7U=" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 46.6.2 DYNA|AUTH) with ESMTPSA id R0acebw3O9pgAHY (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); Fri, 24 Apr 2020 11:51:42 +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\)) From: "H. Nikolaus Schaller" In-Reply-To: <20200423203642.35ms4aarnv65tfp5@gilmour.lan> Date: Fri, 24 Apr 2020 11:51:42 +0200 Message-Id: References: <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> <43688597-4b99-8f4d-9ad5-548ddff07f52@baylibre.com> <71F2F964-32C7-41E6-8F1A-A73161EA1BB3@goldelico.com> <20200423203642.35ms4aarnv65tfp5@gilmour.lan> To: Maxime Ripard X-Mailer: Apple Mail (2.3124) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200424_025201_580040_AFCE31B0 X-CRM114-Status: GOOD ( 18.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Neil Armstrong , Tony Lindgren , James Hogan , Jonathan Bakker , "open list:DRM PANEL DRIVERS" , Linux Kernel Mailing List , Paul Cercueil , linux-samsung-soc@vger.kernel.org, Paul Burton , Krzysztof Kozlowski , David Airlie , Chen-Yu Tsai , Kukjin Kim , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Rob Herring , linux-omap , arm-soc , Thomas Bogendoerfer , Philipp Rossak , OpenPVRSGX Linux Driver Group , linux-mips@vger.kernel.org, Ralf Baechle , Daniel Vetter , kernel@pyra-handheld.com, Discussions about the Letux Kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, > Am 23.04.2020 um 22:36 schrieb Maxime Ripard : >> My goal is to keep the bindings as minimalistic as possible. And reset >> lines and power domains are (at least for those we have in the works) >> not needed to make working systems. >> >> Therefore, for clocks I also would start with a minimalistic approach >> for a single optional GPU core clock and leave out reset and power >> completely. > > Like I said above, the DT is considered an ABI and you'll have to > maintain backward compatibility (ie, newer kernel running with older > DT). Generally I fully agree to this rule (although I have experienced that exceptions happen more often than I like). But here, we don't have any older DT which define something about SGX. We introduce SGX for the first time with bindings and DT in parallel. So they are in sync. Therefore, newer kernels with SGX support and older DT simply will skip SGX and not load any drivers. So we can't break older DT and older DT can't break SGX. What we introduce is a DT code that is well hung and tested (originating in vendor kernels). It is cast in a bindings.yaml where not everyone is happy with for reasons outside the originally proposed DT. For new SoC not yet supported, I don't see a need to touch the existing ones. This is because I only propose to *add* properties to the bindings for devices that have not been supported with SGX before and are not sufficiently covered by what exists. So backward compatibility is a non-problem. > Therefore, you won't be able to require a new clock, reset or > power-domain later on for example. > > I guess the question I'm really asking is: since you don't really know > how the hardware is integrated at the moment, Like I explained, we do not need to know and model all details about the hardware integration. The register set of an SoC does not always provide bits to control all signals we may see in a block diagram or think they must exist. We have a set of SoC where it is demonstrated to work without need for more detailed knowledge about specific hardware integration. So we know everything of importance for this initial set of SoC to make it work. > why should we have that > discussion *now*. It's really not suprising that you don't know yet, so > I'm not sure why we need to rush in the bindings. Because: * there are people who want to have upstream SGX support for an initial set of SoC *now* * the discussion already lasts ca. 6 months since I posted v1, that should be enough and is not a rush * it is not required to know more details to make a working system * we will not gain more information by waiting for another year or two * problems are not solved by postponing them * there are DTS for some initial SoC, tested to work * it is no longer possible to submit DT without bindings.yaml (or is it?) * we just need to define a bindings.yaml for them, not invent something completely new * we can start with a minimal bindings.yaml for the analysed SoC and *extend* it in the future if really needed * we can discuss changes & extensions for the bindings when they are really proposed * having this patch series upstream is a prerequisite for introducing the sgx kernel driver to staging In other words: your suggestion to postpone everything will keep finished work sitting in front of the door and rotting and blocking unfinished work... And to be honest, we have postponed SGX support already for too long time and could be much farther with more and broader community cooperation. So we should not block ourselves. So if you can contribute new information or proposals to specifically improve the proposed bindings.yaml, you are very welcome. But please do it *now*. BR and thanks, Nikolaus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel