From: Steven Price <steven.price@arm.com>
To: Nicolas Boichat <drinkcat@chromium.org>,
Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
David Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-mediatek@lists.infradead.org,
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
hsinyi@chromium.org, Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 4/7] drm/panfrost: Add support for multiple regulators
Date: Mon, 20 Jan 2020 14:43:10 +0000 [thread overview]
Message-ID: <7e82cac2-efbf-806b-8c2e-04dbd0482b50@arm.com> (raw)
In-Reply-To: <20200114071602.47627-5-drinkcat@chromium.org>
On 14/01/2020 07:15, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
>
> We extend the framework in a generic manner so that we could
> support more than 2 regulators, if required.
>
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>
> ---
>
> v3:
> - Make this more generic, by allowing any number of regulators
> (in practice we fix the maximum number of regulators to 2, but
> this could be increased easily).
> - We only probe the second regulator if the device tree matching
> data asks for it.
> - I couldn't find a way to detect the number of regulators in the
> device tree, if we wanted to refuse to probe the device if there
> are too many regulators, which might be required for safety, see
> the thread on v2 [1].
> - The discussion also included the idea of a separate device tree
> entry for a "soft PDC", or at least a separate driver. I'm not
> sure to understand the full picture, and how different vendors
> implement this, so I'm still integrating everything in the main
> driver. I'd be happy to try to make mt8183 fit into such a
> framework after it's created, but I don't think I'm best placed
> to implement (and again, the main purpose of this was to test
> if the binding is correct).
From discussions offline, I think I've come round to the view that
having a "soft PDC" in device tree isn't the right solution. Device tree
should be describing the hardware and that isn't actually a hardware
component.
I guess we'll have to wait to see how many devices have a similar
'quirk' and whether it's worth representing this is software in a more
generic manner, or if matching on compatible strings will be sufficient
for the devices that need multiple regulators.
One (minor) comment below, but otherwise LGTM.
>
> [1] https://patchwork.kernel.org/patch/11322839/
>
> drivers/gpu/drm/panfrost/panfrost_device.c | 25 ++++++++++++-------
> drivers/gpu/drm/panfrost/panfrost_device.h | 15 +++++++++++-
> drivers/gpu/drm/panfrost/panfrost_drv.c | 28 +++++++++++++++-------
> 3 files changed, 50 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c b/drivers/gpu/drm/panfrost/panfrost_device.c
> index 238fb6d54df4732..c30e0a3772a4f57 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> @@ -87,18 +87,26 @@ static void panfrost_clk_fini(struct panfrost_device *pfdev)
>
> static int panfrost_regulator_init(struct panfrost_device *pfdev)
> {
> - int ret;
> + int ret, i;
>
> - pfdev->regulator = devm_regulator_get(pfdev->dev, "mali");
> - if (IS_ERR(pfdev->regulator)) {
> - ret = PTR_ERR(pfdev->regulator);
> - dev_err(pfdev->dev, "failed to get regulator: %d\n", ret);
> + BUG_ON(pfdev->comp->num_supplies > ARRAY_SIZE(pfdev->regulators));
> +
> + for (i = 0; i < pfdev->comp->num_supplies; i++) {
> + pfdev->regulators[i].supply = pfdev->comp->supply_names[i];
> + }
> +
> + ret = devm_regulator_bulk_get(pfdev->dev,
> + pfdev->comp->num_supplies,
> + pfdev->regulators);
> + if (ret < 0) {
> + dev_err(pfdev->dev, "failed to get regulators: %d\n", ret);
> return ret;
> }
>
> - ret = regulator_enable(pfdev->regulator);
> + ret = regulator_bulk_enable(pfdev->comp->num_supplies,
> + pfdev->regulators);
> if (ret < 0) {
> - dev_err(pfdev->dev, "failed to enable regulator: %d\n", ret);
> + dev_err(pfdev->dev, "failed to enable regulators: %d\n", ret);
> return ret;
> }
>
> @@ -107,7 +115,8 @@ static int panfrost_regulator_init(struct panfrost_device *pfdev)
>
> static void panfrost_regulator_fini(struct panfrost_device *pfdev)
> {
> - regulator_disable(pfdev->regulator);
> + regulator_bulk_disable(pfdev->comp->num_supplies,
> + pfdev->regulators);
> }
>
> int panfrost_device_init(struct panfrost_device *pfdev)
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 06713811b92cdf7..021f063ffb3747f 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -7,6 +7,7 @@
>
> #include <linux/atomic.h>
> #include <linux/io-pgtable.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/spinlock.h>
> #include <drm/drm_device.h>
> #include <drm/drm_mm.h>
> @@ -19,6 +20,7 @@ struct panfrost_job;
> struct panfrost_perfcnt;
>
> #define NUM_JOB_SLOTS 3
> +#define MAX_REGULATORS 2
>
> struct panfrost_features {
> u16 id;
> @@ -51,6 +53,16 @@ struct panfrost_features {
> unsigned long hw_issues[64 / BITS_PER_LONG];
> };
>
> +/*
> + * Features that cannot be automatically detected and need matching using the
> + * compatible string, typically SoC-specific.
> + */
> +struct panfrost_compatible {
> + /* Supplies count and names. */
> + int num_supplies;
> + const char * const *supply_names;
> +};
> +
> struct panfrost_device {
> struct device *dev;
> struct drm_device *ddev;
> @@ -59,10 +71,11 @@ struct panfrost_device {
> void __iomem *iomem;
> struct clk *clock;
> struct clk *bus_clock;
> - struct regulator *regulator;
> + struct regulator_bulk_data regulators[MAX_REGULATORS];
> struct reset_control *rstc;
>
> struct panfrost_features features;
> + const struct panfrost_compatible* comp;
>
> spinlock_t as_lock;
> unsigned long as_in_use_mask;
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 48e3c4165247cea..db3563b80150c9d 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -510,6 +510,10 @@ static int panfrost_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, pfdev);
>
> + pfdev->comp = of_device_get_match_data(&pdev->dev);
> + if (!pfdev->comp)
> + return -ENODEV;
> +
> /* Allocate and initialze the DRM device. */
> ddev = drm_dev_alloc(&panfrost_drm_driver, &pdev->dev);
> if (IS_ERR(ddev))
> @@ -581,16 +585,22 @@ static int panfrost_remove(struct platform_device *pdev)
> return 0;
> }
>
> +const char * const default_supplies[] = { "mali" };
This should be static.
Steve
> +static const struct panfrost_compatible default_data = {
> + .num_supplies = ARRAY_SIZE(default_supplies),
> + .supply_names = default_supplies,
> +};
> +
> static const struct of_device_id dt_match[] = {
> - { .compatible = "arm,mali-t604" },
> - { .compatible = "arm,mali-t624" },
> - { .compatible = "arm,mali-t628" },
> - { .compatible = "arm,mali-t720" },
> - { .compatible = "arm,mali-t760" },
> - { .compatible = "arm,mali-t820" },
> - { .compatible = "arm,mali-t830" },
> - { .compatible = "arm,mali-t860" },
> - { .compatible = "arm,mali-t880" },
> + { .compatible = "arm,mali-t604", .data = &default_data, },
> + { .compatible = "arm,mali-t624", .data = &default_data, },
> + { .compatible = "arm,mali-t628", .data = &default_data, },
> + { .compatible = "arm,mali-t720", .data = &default_data, },
> + { .compatible = "arm,mali-t760", .data = &default_data, },
> + { .compatible = "arm,mali-t820", .data = &default_data, },
> + { .compatible = "arm,mali-t830", .data = &default_data, },
> + { .compatible = "arm,mali-t860", .data = &default_data, },
> + { .compatible = "arm,mali-t880", .data = &default_data, },
> {}
> };
> MODULE_DEVICE_TABLE(of, dt_match);
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-01-20 14:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 7:15 [PATCH v3 0/7] Add dts for mt8183 GPU (and misc panfrost patches) Nicolas Boichat
2020-01-14 7:15 ` [PATCH v3 1/7] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 Nicolas Boichat
2020-01-14 7:15 ` [PATCH v3 2/7] arm64: dts: mt8183: Add node for the Mali GPU Nicolas Boichat
2020-01-14 7:15 ` [PATCH v3 3/7] drm/panfrost: Improve error reporting in panfrost_gpu_power_on Nicolas Boichat
2020-01-14 7:15 ` [PATCH v3 4/7] drm/panfrost: Add support for multiple regulators Nicolas Boichat
2020-01-14 15:16 ` Mark Brown
2020-01-21 4:37 ` Nicolas Boichat
2020-01-22 13:40 ` Steven Price
2020-01-20 14:43 ` Steven Price [this message]
2020-01-20 17:03 ` Mark Brown
2020-01-20 17:09 ` Steven Price
2020-01-14 7:16 ` [PATCH v3 5/7] drm/panfrost: Add support for multiple power domains Nicolas Boichat
2020-01-20 14:53 ` Steven Price
2020-02-07 3:06 ` Nicolas Boichat
2020-01-14 7:16 ` [PATCH v3 6/7, RFC] drm/panfrost: Add mt8183-mali compatible string Nicolas Boichat
2020-01-14 7:16 ` [PATCH v3 7/7, RFC] drm/panfrost: devfreq: Add support for 2 regulators Nicolas Boichat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7e82cac2-efbf-806b-8c2e-04dbd0482b50@arm.com \
--to=steven.price@arm.com \
--cc=airlied@linux.ie \
--cc=alyssa.rosenzweig@collabora.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=drinkcat@chromium.org \
--cc=hsinyi@chromium.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=robh+dt@kernel.org \
--cc=tomeu.vizoso@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).