Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2731689ybz; Sun, 3 May 2020 08:03:34 -0700 (PDT) X-Google-Smtp-Source: APiQypJjdnbFwbLqPTwYpgkhFFrLbbhqtH5tGFl03DWpF5wdvYTjvFl6C78OHpV6b4iuCDrh0Ox7 X-Received: by 2002:a50:bb07:: with SMTP id y7mr11063029ede.358.1588518214703; Sun, 03 May 2020 08:03:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588518214; cv=none; d=google.com; s=arc-20160816; b=c+HPU618uUDfjhSu2K38bUnEwkDk5ZdwcR0Zx+eRl3Q9P+FLQmWzBLVqSOgPl7AFU6 Q9Xkc+DPX5oT0q6G3wy1gE0g0hNh0Zue/vqAeFGrr11fB0pLuYQ5JGAeis0XY8+Wj+EK tEZXAAtV74kDKasXbtuJmduyIN2l3ABbv5gVDFS8DYMqw9OVJHdZx87rkiL5E2KgB+bE w64hhAUqoUexlSGMdk/npAeAffDZ6OAHkNIe7L9rOoAXYEUqcJK2pt8Y19NNcqnKD6q+ 9/2btaxiNL4JrTBk6pWrieVLwhx6/RCzwxBgI8wtt1s47EY5RfVHm2nTAnPacAfeztyd J/eQ== 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=MOBudELWIv4/2x4wDxQ/YoZvV/bvpjKpe6DnOkluq94=; b=MuFeWWDPq+bua2lTw9ae1MqBQVCDIa9xw6CYo7XscXjfMCkTO8U1aJBn4MnZpV/v9P z/LbajYc/ZoSabtTeEEIxaec5OBMSv7EwHuIi+SXKC/DTRK0QBVaXvOLy43uuRAxrY/5 9xY/Fz9V+nyNQqN1DRlXzcVHWBW44VVxoPhLdz3m6DGu9SLVWOJs2334mdkQVLLOuyfj 94i7Jb3xyHouawggn80PLBLTH+/vSlRQvJyd6mAc4A4dEma9jvTc8qnJnA3dtMH7GuW5 GAMx/kf9yenJ8odV1Vy0+4GDyKxlj3InDm9bp1sipyOWE17SiLaNjNXOqRF+8sJe7YEJ 5JTA== 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 ck25si5375964ejb.114.2020.05.03.08.03.10; Sun, 03 May 2020 08:03:34 -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 S1728729AbgECPBt (ORCPT + 99 others); Sun, 3 May 2020 11:01:49 -0400 Received: from muru.com ([72.249.23.125]:52668 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728002AbgECPBs (ORCPT ); Sun, 3 May 2020 11:01:48 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 5955480BF; Sun, 3 May 2020 15:02:34 +0000 (UTC) Date: Sun, 3 May 2020 08:01:43 -0700 From: Tony Lindgren To: Paul Cercueil Cc: "H. Nikolaus Schaller" , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , =?utf-8?Q?Beno=C3=AEt?= Cousson , Ralf Baechle , Paul Burton , James Hogan , Kukjin Kim , Krzysztof Kozlowski , Maxime Ripard , Chen-Yu Tsai , Thomas Bogendoerfer , Jonathan Bakker , Philipp Rossak , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, openpvrsgx-devgroup@letux.org, letux-kernel@openphoenux.org, kernel@pyra-handheld.com, linux-mips@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org Subject: Re: [PATCH v7 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs Message-ID: <20200503150143.GG37466@atomide.com> References: <3a451e360fed84bc40287678b4d6be13821cfbc0.1587760454.git.hns@goldelico.com> <28138EC0-0FA5-4F97-B528-3442BF087C7A@goldelico.com> <3D8B59D6-83E3-4FE6-9C99-E2E5616A8139@goldelico.com> <8EER9Q.C206SXNSICP7@crapouillou.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EER9Q.C206SXNSICP7@crapouillou.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Paul Cercueil [200503 14:19]: > You have a new SoC with a SGX, and you only need to enable one clock to get > it to work. So you create a devicetree node which receives only one clock. > > Turns out, that the bootloader was enabling the other 3 clocks, and since > the last release, it doesn't anymore. You're left with having to support a > broken devicetree. > > That's the kind of problem that can be easily avoided by enforcing the > number of clocks that have to be provided. The number of clocks depends on how it's wired for the SoC. On omaps, there's are no controls for additinoal SGX clocks. Sure some of the clocks may be routed to multple places internally by the wrapper module. But we have no control over that. If we wanted to specify just the "fck" clock on omaps, then we can do it with something like this: allOf: - if: properites: compatible: enum: - "ti,omap4-sgx544-112" - "ti,omap5-sgx544-116" - "ti,dra7-sgx544-116" then: properties: clocks: minItems: 1 maxItems: 1 clock-names: const: fck required: - clocks - clock-names There's no need for the SGX driver to toggle the "fck" here, it's all done by PM runtime alreaedy so we would be just tweaking the usage count for it. But hey, showing the clock rate might be nice. Or maybe we want to at some point scale it, so no problem specifying it. For omap3, we should then specify "fck" and "ick". On omap4 and later, there's no separate control over the "ick". Then for the other SoCs, you can specify whatever clocks you need there. Regards, Tony