Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2388827ybl; Thu, 9 Jan 2020 11:54:02 -0800 (PST) X-Google-Smtp-Source: APXvYqyKj8QxiVr/j42tFzBbwxnFVu1dEnfaTpuIPLG2dZ7ScnY/93PPPdn1n9mSY1l7ZEYvGc5G X-Received: by 2002:aca:1103:: with SMTP id 3mr4312535oir.70.1578599642437; Thu, 09 Jan 2020 11:54:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578599642; cv=none; d=google.com; s=arc-20160816; b=u3LweHJOS0hPk2IMnHCPRTQC63/PQSp9dQsrLxmNS5UeJeVtv3mVc29Pct/M+juWZ8 pL1fiqw4AxiciRSTb0QZCWmCfxV+OnXaX5h08S0lZ6xqeruGGijPjriPnnWZNrVOfoMM W9djPgAIfuEF2YW7Xny+EKYOxXkiFAZG5VV0uIvQetRnGkFj+MruI7OdFSKkIBMk7MIc Ca088Zt4V4PyTkRXjFWElyNG36YBkbENxm7eCzodT6RE/ACeM6ZHMr9g3fg/gkNzM3mg RyRMRGD/2qzZvIBNf+4nY3otFJGomhIk5IwK5H/LJUksJhsR4WCjhicJPls6K72pfsFI 2L5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=UwGjM/hxOrlq0AwFhktnlLVBD33qqdAkfs30x1xFX5Q=; b=c+/sDZ2cR3bc3UanOg84vjaWFnD98Lm3neHSxDEo47nQL7Z0XA+taQZ3ijWZQfKkU1 oAQunYSivvjCC5vv7dEKzN7lE2SLxSe0iqio3+tMYsWQxK2QPPK414UR4Z6CeXhJ9ot/ acgJemAxTephOcZiNxAYTHh895OotHDO/zHYk6WY1cCS5wUQnRLBAz0r3N774uPNHOkL IwFEWrCbJLmUiKN3lG4SyWCx2ogFzh1yIeUenPPd1rJpQErREiDV54LIDF/xYHO6WspD vSH4G3vhUJuNnnxjjH//SF9SFNY/IHo8fUwunqvQ97T+whtpNiWoE0+yJRZ3nA8XGbfw H1Zw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r4si4580541otq.188.2020.01.09.11.53.50; Thu, 09 Jan 2020 11:54:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387563AbgAIQ2S (ORCPT + 99 others); Thu, 9 Jan 2020 11:28:18 -0500 Received: from foss.arm.com ([217.140.110.172]:34268 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728840AbgAIQ2R (ORCPT ); Thu, 9 Jan 2020 11:28:17 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CE6271FB; Thu, 9 Jan 2020 08:28:16 -0800 (PST) Received: from localhost (unknown [10.37.6.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 52D173F703; Thu, 9 Jan 2020 08:28:16 -0800 (PST) Date: Thu, 9 Jan 2020 16:28:14 +0000 From: Mark Brown To: Steven Price Cc: Nicolas Boichat , Mark Rutland , Devicetree List , Tomeu Vizoso , David Airlie , lkml , Liam Girdwood , dri-devel@lists.freedesktop.org, Rob Herring , "moderated list:ARM/Mediatek SoC support" , Alyssa Rosenzweig , Hsin-Yi Wang , Matthias Brugger , linux-arm Mailing List Subject: Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU Message-ID: <20200109162814.GB3702@sirena.org.uk> References: <20200108052337.65916-1-drinkcat@chromium.org> <20200108052337.65916-5-drinkcat@chromium.org> <20200108132302.GA3817@sirena.org.uk> <09ddfac3-da8d-c039-92a0-d0f51dc3fea5@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <09ddfac3-da8d-c039-92a0-d0f51dc3fea5@arm.com> X-Cookie: Killing turkeys causes winter. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 09, 2020 at 02:14:42PM +0000, Steven Price wrote: > On 08/01/2020 22:52, Nicolas Boichat wrote: > > That'd be a bit awkward to match, though... Currently all bifrost > > share the same compatible "arm,mali-bifrost", and it'd seem > > weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no > > idea if any other Mali implementation will require a second regulator, > > but with the MT8183 we do need it, see below. This doesn't sound particularly hard, just new. Plenty of other devices have quirks done based on the SoC they're in or the IP revision, this would just be another of those quirks. > > Well if devfreq was working (see patch 7 > > https://patchwork.kernel.org/patch/11322851/ for a partial > > implementation), it would adjust both mali and sram regulators, see > > the OPP table in patch 2 > > (https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to > > be increased for frequencies >=698Mhz. > > Now if you have some better idea how to implement this, I'm all ears! Set a flag based on the compatible, then base runtime decisions off that. > I'm not sure if it's better, but could we just encode the list of > regulators into device tree. I'm a bit worried about special casing an > "sram" regulator given that other platforms might have a similar > situation but call the second regulator a different name. Obviously the list of regulators bound on a given platform is encoded in the device tree but you shouldn't really be relying on that to figure out what to request in the driver - the driver should know what it's expecting. Bear in mind that getting regulator stuff wrong can result in physical damage to the system so it pays to be careful and to consider that platform integrators have a tendency to rely on things that just happen to work but aren't a good idea or accurate representations of the system. It's certainly *possible* to do something like that, the information is there, but I would not in any way recommend doing things that way as it's likely to not be robust. The possibility that the regulator setup may vary on other platforms (which I'd expect TBH) does suggest that just requesting a bunch of supply names optionally and hoping that we got all the ones that are important on a given platform is going to lead to trouble down the line. Steve, please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl4XVJ0ACgkQJNaLcl1U h9AYxwf+KvXLp3chGCrua6k7mYwzuRnBu6lxudNUYlU35S6W/jvj7j24xoetg2SJ 9bvm5PnWREES8yFnNE3P0v0XhwZ7KP223VeOsNEUEXaD34txxpfgIsFJ0pBSl5MY 2s7l8R4CSe0EYuBc2Rg1g+KGb8mOwvdVaOYKdgMXHiscQ4Iq2QNNA+1kVjLFGE72 kTPnycN7SvQLsxzJbMm7zday5eObx2CHrfxZjdlnSjGnao7fIcyIRnc6rjSf4VkG +WjOYltzHe0oe9yfN+4+wjawAPt5OIr9BeD3L/Vdm9Lvy59wTPuairTYgV1e0+oV GDQ1CHWCdcr1P9Yi96zKy/4P4eEShw== =+CID -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13--