Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp563379ybk; Wed, 20 May 2020 06:40:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycexVFNUnvY1GeZzQbKUQEFvh/Fv67QjjwGdFTJ0skA72HAHHQAfs1sJT2V5x1t+SUnERK X-Received: by 2002:a17:906:cecb:: with SMTP id si11mr3681654ejb.122.1589982032280; Wed, 20 May 2020 06:40:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589982032; cv=none; d=google.com; s=arc-20160816; b=oyKeBQcR9f+hVKpnN752SNSfiUUZZoYokYd+O77pSC4hTZVW6lVcoxtOKrUlNeCRRD E4XkkWA/cF89tgQgXYb7ggrGywKGdpd4RN9MGny1XKm/eRo3LrXoxa4+9Z1W8h72GgxL bsU9dRku3WniPATHJB6Dr2Q9LfvUeDkel9EZJwsGLdmMB6jofsr2Icla/y5flvfIdVA5 vF+UsxGR4IqdzxgTkfN8fJA2zMXby+jz8L1r7YcfjdMRWCNa0mE/Y4CT6oz9psdsYvLM Js3Gt2GxBkyHrKeMB2LbtAwZsEPznzyKb5Y4fxd6vs9UQ7qHTNhoXYlvZO5AfpDg5JZq 1fGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Bi+MzVCL7gDDSEmWF785zZO/mj04FI6wqqFJd2ILfDQ=; b=Jt70LyKWSXlkTYcTn0GNrCm4qzmbMaqveTo4amSXfkLMF1mCrHTiZnHRKQ1PmhGyWg K13I1S1QoeCRSo+QPnPLaxtX3eyHvA+549OZvri1mGh7J1INkA5Y5k0YYqnoqYbCyKX3 B+6yac+qNgug/mZdVN48nC51ZYdovdcAGyxGAt7f9HsuuAYGkA9EFsrmzd3PKGgFUWka FDSUNwvXGuPtOaNejK6w79MVN/qbWOg2YOvkupAtylBA5Otw5OwPSgAZ7rvRn5Hze7oM prCyeaB3MAapGM2oi30CfWEqxN7zpURc3u49jPmnDjOAZvpbwBgVPcBFh7KdfyK4P4DY vL3w== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l14si1699385eja.478.2020.05.20.06.40.07; Wed, 20 May 2020 06:40:32 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726791AbgETNib (ORCPT + 99 others); Wed, 20 May 2020 09:38:31 -0400 Received: from v6.sk ([167.172.42.174]:60732 "EHLO v6.sk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726436AbgETNib (ORCPT ); Wed, 20 May 2020 09:38:31 -0400 Received: from localhost (v6.sk [IPv6:::1]) by v6.sk (Postfix) with ESMTP id 0F6AC61300; Wed, 20 May 2020 13:38:28 +0000 (UTC) Date: Wed, 20 May 2020 15:38:24 +0200 From: Lubomir Rintel To: Russell King - ARM Linux admin Cc: Lucas Stach , Fabio Estevam , linux-kernel , DRI mailing list , The etnaviv authors , Christian Gmeiner Subject: Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks Message-ID: <20200520133824.GK1695525@furthur.local> References: <20200513150007.1315395-1-lkundrak@v3.sk> <20200513150007.1315395-3-lkundrak@v3.sk> <1e15be39906034a95b86c026e060ed9866586d94.camel@pengutronix.de> <20200514082755.GN1551@shell.armlinux.org.uk> <20200514085307.GO1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200514085307.GO1551@shell.armlinux.org.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 14, 2020 at 09:53:08AM +0100, Russell King - ARM Linux admin wrote: > On Thu, May 14, 2020 at 10:40:58AM +0200, Lucas Stach wrote: > > Am Donnerstag, den 14.05.2020, 09:27 +0100 schrieb Russell King - ARM Linux admin: > > > On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote: > > > > Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam: > > > > > On Wed, May 13, 2020 at 2:09 PM Fabio Estevam wrote: > > > > > > > > > > > The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml > > > > > > says that only the 'reg' clock could be optional, the others are > > > > > > required. > > > > > > > > > > arch/arm/boot/dts/dove.dtsi only uses the 'core' clock. > > > > > arch/arm/boot/dts/stm32mp157.dtsi uses 'bus' and 'core' > > > > > > > > > > Maybe the binding needs to be updated and it seems that using > > > > > devm_clk_get_optional() like you propose is safe. > > > > > > > > The binding is correct as-is. We want to require those clocks to be > > > > present, but the dove DT was added before the binding was finalized, so > > > > the driver still treats the clocks as optional to not break > > > > compatibility with old DTs. Maybe this warrants a comment in the > > > > code... > > > > > > The binding doc in mainline says: > > > > > > clocks: > > > items: > > > - description: AXI/master interface clock > > > - description: GPU core clock > > > - description: Shader clock (only required if GPU has feature PIPE_3D) > > > - description: AHB/slave interface clock (only required if GPU can gate slave interface independently) > > > minItems: 1 > > > maxItems: 4 > > > > > > clock-names: > > > items: > > > enum: [ bus, core, shader, reg ] > > > minItems: 1 > > > maxItems: 4 > > > > > > which looks correct to me - and means that Dove is compliant with that. > > > > The YAML binding actually did loose something in translation here, > > which I didn't notice. Previously all those clocks were listed under > > "Required properties", with the exceptions listed in parenthesis. So > > the Dove GPU, which is a combined 2D/3D core should have axi, core and > > shader clocks specified. > > That may be your desire, but that is impossible without knowing that > (a) it has the clocks > (b) what those clocks are connected to > > I guess we could "make something up" but as DT is supposed to describe > hardware, I don't see how we can satisfy that and your requirement. > > The only thing that is known from the documentation is that there is > one clock for the GPU on Dove. Yes. This means that in fact "core" is the only required clock for all implementations of vivante,gc and the common binding needs to be updated to reflect that. I'll follow with a patch that does that, unless there are strong objections. If there are implementations that require different clock inputs, then they need to use additional compatible string for the particular flavor and the binding should have conditionals for them. Something like this: if: properties: compatible: contains: const: fsl,imx6sx-gpu then: properties: clocks: minItems: 4 Lubo