The OPP framework supports binning through the 'opp-supported-hw'
devicetree property and some of the SoCs that are using Panfrost,
namely ... MediaTek, are actually binned.
This is especially seen in MT8186, but some other models do actually
support the same.
This series adds basic binning support by simply checking (and reading)
speed-bin from NVMEM (eFuse arrays, usually) and *if and only if* that
is provided, adds the read value with devm_pm_opp_set_supported_hw().
This code expects to receive a value that is compatible with how the
supported_hw checks work in OPP and it should never contain any kind
of platform (or SoC) specific code, since Panfrost is a driver for a
GPU that may be tied to different SoCs... and this is what this series
provides.
Cheers!
AngeloGioacchino Del Regno (2):
dt-bindings: gpu: mali-bifrost: Document nvmem for speedbin support
drm/panfrost: Add basic support for speed binning
.../bindings/gpu/arm,mali-bifrost.yaml | 7 +++++
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 30 +++++++++++++++++++
2 files changed, 37 insertions(+)
--
2.40.0
Some SoCs implementing ARM Mali GPUs may be subject to speed binning
and the usable bin is read from nvmem: document the addition of nvmem
and nvmem-cells for 'speed-bin'.
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
---
.../devicetree/bindings/gpu/arm,mali-bifrost.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index 8a0083800810..1eecb014016c 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -104,6 +104,13 @@ properties:
dma-coherent: true
+ nvmem-cell-names:
+ items:
+ - const: speed-bin
+
+ nvmem-cells:
+ maxItems: 1
+
required:
- compatible
- reg
--
2.40.0
Some SoCs implementing ARM Mali GPUs are subject to speed binning:
this means that some versions of the same SoC model may need to be
limited to a slower frequency compared to the other:
this is being addressed by reading nvmem (usually, an eFuse array)
containing a number that identifies the speed binning of the chip,
which is usually related to silicon quality.
To address such situation, add basic support for reading the
speed-bin through nvmem, as to make it possible to specify the
supported hardware in the OPP table for GPUs.
This commit also keeps compatibility with any platform that does
not specify (and does not even support) speed-binning.
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 30 +++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index fe5f12f16a63..58dfb15a8757 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -4,6 +4,7 @@
#include <linux/clk.h>
#include <linux/devfreq.h>
#include <linux/devfreq_cooling.h>
+#include <linux/nvmem-consumer.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
@@ -82,6 +83,31 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
.get_dev_status = panfrost_devfreq_get_dev_status,
};
+static int panfrost_read_speedbin(struct device *dev)
+{
+ u32 val;
+ int ret;
+
+ ret = nvmem_cell_read_variable_le_u32(dev, "speed-bin", &val);
+ if (ret) {
+ /*
+ * -ENOENT means that this platform doesn't support speedbins
+ * as it didn't declare any speed-bin nvmem: in this case, we
+ * keep going without it; any other error means that we are
+ * supposed to read the bin value, but we failed doing so.
+ */
+ if (ret != -ENOENT) {
+ DRM_DEV_ERROR(dev, "Cannot read speed-bin (%d).", ret);
+ return ret;
+ }
+
+ return 0;
+ }
+ DRM_DEV_DEBUG(dev, "Using speed-bin = 0x%x\n", val);
+
+ return devm_pm_opp_set_supported_hw(dev, &val, 1);
+}
+
int panfrost_devfreq_init(struct panfrost_device *pfdev)
{
int ret;
@@ -101,6 +127,10 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
return 0;
}
+ ret = panfrost_read_speedbin(dev);
+ if (ret)
+ return ret;
+
ret = devm_pm_opp_set_regulators(dev, pfdev->comp->supply_names);
if (ret) {
/* Continue if the optional regulator is missing */
--
2.40.0
On 23/03/2023 10:08, AngeloGioacchino Del Regno wrote:
> Some SoCs implementing ARM Mali GPUs may be subject to speed binning
> and the usable bin is read from nvmem: document the addition of nvmem
> and nvmem-cells for 'speed-bin'.
>
> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
Il 23/03/23 10:08, AngeloGioacchino Del Regno ha scritto:
> Some SoCs implementing ARM Mali GPUs are subject to speed binning:
> this means that some versions of the same SoC model may need to be
> limited to a slower frequency compared to the other:
> this is being addressed by reading nvmem (usually, an eFuse array)
> containing a number that identifies the speed binning of the chip,
> which is usually related to silicon quality.
>
> To address such situation, add basic support for reading the
> speed-bin through nvmem, as to make it possible to specify the
> supported hardware in the OPP table for GPUs.
> This commit also keeps compatibility with any platform that does
> not specify (and does not even support) speed-binning.
>
> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Hello maintainers,
I've seen that this got archived in the dri-devel patchwork; because of that and
only that, I'm sending this ping to get this patch reviewed.
(perhaps we can even get it picked for v6.4?)
Regards,
Angelo
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 30 +++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index fe5f12f16a63..58dfb15a8757 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -4,6 +4,7 @@
> #include <linux/clk.h>
> #include <linux/devfreq.h>
> #include <linux/devfreq_cooling.h>
> +#include <linux/nvmem-consumer.h>
> #include <linux/platform_device.h>
> #include <linux/pm_opp.h>
>
> @@ -82,6 +83,31 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
> .get_dev_status = panfrost_devfreq_get_dev_status,
> };
>
> +static int panfrost_read_speedbin(struct device *dev)
> +{
> + u32 val;
> + int ret;
> +
> + ret = nvmem_cell_read_variable_le_u32(dev, "speed-bin", &val);
> + if (ret) {
> + /*
> + * -ENOENT means that this platform doesn't support speedbins
> + * as it didn't declare any speed-bin nvmem: in this case, we
> + * keep going without it; any other error means that we are
> + * supposed to read the bin value, but we failed doing so.
> + */
> + if (ret != -ENOENT) {
> + DRM_DEV_ERROR(dev, "Cannot read speed-bin (%d).", ret);
> + return ret;
> + }
> +
> + return 0;
> + }
> + DRM_DEV_DEBUG(dev, "Using speed-bin = 0x%x\n", val);
> +
> + return devm_pm_opp_set_supported_hw(dev, &val, 1);
> +}
> +
> int panfrost_devfreq_init(struct panfrost_device *pfdev)
> {
> int ret;
> @@ -101,6 +127,10 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> return 0;
> }
>
> + ret = panfrost_read_speedbin(dev);
> + if (ret)
> + return ret;
> +
> ret = devm_pm_opp_set_regulators(dev, pfdev->comp->supply_names);
> if (ret) {
> /* Continue if the optional regulator is missing */
On Fri, 31 Mar 2023 10:11:07 +0200
AngeloGioacchino Del Regno <[email protected]>
wrote:
> Il 23/03/23 10:08, AngeloGioacchino Del Regno ha scritto:
> > Some SoCs implementing ARM Mali GPUs are subject to speed binning:
> > this means that some versions of the same SoC model may need to be
> > limited to a slower frequency compared to the other:
> > this is being addressed by reading nvmem (usually, an eFuse array)
> > containing a number that identifies the speed binning of the chip,
> > which is usually related to silicon quality.
> >
> > To address such situation, add basic support for reading the
> > speed-bin through nvmem, as to make it possible to specify the
> > supported hardware in the OPP table for GPUs.
> > This commit also keeps compatibility with any platform that does
> > not specify (and does not even support) speed-binning.
> >
> > Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
>
> Hello maintainers,
> I've seen that this got archived in the dri-devel patchwork; because of that and
> only that, I'm sending this ping to get this patch reviewed.
Looks good to me. If you can get a DT maintainer to review the binding
(Rob?), I'd be happy to queue the series to drm-misc-next.
>
> (perhaps we can even get it picked for v6.4?)
>
> Regards,
> Angelo
>
> > ---
> > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 30 +++++++++++++++++++++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > index fe5f12f16a63..58dfb15a8757 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > @@ -4,6 +4,7 @@
> > #include <linux/clk.h>
> > #include <linux/devfreq.h>
> > #include <linux/devfreq_cooling.h>
> > +#include <linux/nvmem-consumer.h>
> > #include <linux/platform_device.h>
> > #include <linux/pm_opp.h>
> >
> > @@ -82,6 +83,31 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
> > .get_dev_status = panfrost_devfreq_get_dev_status,
> > };
> >
> > +static int panfrost_read_speedbin(struct device *dev)
> > +{
> > + u32 val;
> > + int ret;
> > +
> > + ret = nvmem_cell_read_variable_le_u32(dev, "speed-bin", &val);
> > + if (ret) {
> > + /*
> > + * -ENOENT means that this platform doesn't support speedbins
> > + * as it didn't declare any speed-bin nvmem: in this case, we
> > + * keep going without it; any other error means that we are
> > + * supposed to read the bin value, but we failed doing so.
> > + */
> > + if (ret != -ENOENT) {
> > + DRM_DEV_ERROR(dev, "Cannot read speed-bin (%d).", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > + }
> > + DRM_DEV_DEBUG(dev, "Using speed-bin = 0x%x\n", val);
> > +
> > + return devm_pm_opp_set_supported_hw(dev, &val, 1);
> > +}
> > +
> > int panfrost_devfreq_init(struct panfrost_device *pfdev)
> > {
> > int ret;
> > @@ -101,6 +127,10 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> > return 0;
> > }
> >
> > + ret = panfrost_read_speedbin(dev);
> > + if (ret)
> > + return ret;
> > +
> > ret = devm_pm_opp_set_regulators(dev, pfdev->comp->supply_names);
> > if (ret) {
> > /* Continue if the optional regulator is missing */
>
>
Il 31/03/23 10:49, Boris Brezillon ha scritto:
> On Fri, 31 Mar 2023 10:11:07 +0200
> AngeloGioacchino Del Regno <[email protected]>
> wrote:
>
>> Il 23/03/23 10:08, AngeloGioacchino Del Regno ha scritto:
>>> Some SoCs implementing ARM Mali GPUs are subject to speed binning:
>>> this means that some versions of the same SoC model may need to be
>>> limited to a slower frequency compared to the other:
>>> this is being addressed by reading nvmem (usually, an eFuse array)
>>> containing a number that identifies the speed binning of the chip,
>>> which is usually related to silicon quality.
>>>
>>> To address such situation, add basic support for reading the
>>> speed-bin through nvmem, as to make it possible to specify the
>>> supported hardware in the OPP table for GPUs.
>>> This commit also keeps compatibility with any platform that does
>>> not specify (and does not even support) speed-binning.
>>>
>>> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
>>
>> Hello maintainers,
>> I've seen that this got archived in the dri-devel patchwork; because of that and
>> only that, I'm sending this ping to get this patch reviewed.
>
> Looks good to me. If you can get a DT maintainer to review the binding
> (Rob?), I'd be happy to queue the series to drm-misc-next.
>
The binding was acked by Krzysztof already... so, just to be sure:
Krzysztof, can the binding [1] get picked?
Cheers,
Angelo
[1]:
https://lore.kernel.org/all/[email protected]/
On Fri, 31 Mar 2023 10:57:46 +0200
AngeloGioacchino Del Regno <[email protected]>
wrote:
> Il 31/03/23 10:49, Boris Brezillon ha scritto:
> > On Fri, 31 Mar 2023 10:11:07 +0200
> > AngeloGioacchino Del Regno <[email protected]>
> > wrote:
> >
> >> Il 23/03/23 10:08, AngeloGioacchino Del Regno ha scritto:
> >>> Some SoCs implementing ARM Mali GPUs are subject to speed binning:
> >>> this means that some versions of the same SoC model may need to be
> >>> limited to a slower frequency compared to the other:
> >>> this is being addressed by reading nvmem (usually, an eFuse array)
> >>> containing a number that identifies the speed binning of the chip,
> >>> which is usually related to silicon quality.
> >>>
> >>> To address such situation, add basic support for reading the
> >>> speed-bin through nvmem, as to make it possible to specify the
> >>> supported hardware in the OPP table for GPUs.
> >>> This commit also keeps compatibility with any platform that does
> >>> not specify (and does not even support) speed-binning.
> >>>
> >>> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
> >>
> >> Hello maintainers,
> >> I've seen that this got archived in the dri-devel patchwork; because of that and
> >> only that, I'm sending this ping to get this patch reviewed.
> >
> > Looks good to me. If you can get a DT maintainer to review the binding
> > (Rob?), I'd be happy to queue the series to drm-misc-next.
> >
>
> The binding was acked by Krzysztof already... so, just to be sure:
>
> Krzysztof, can the binding [1] get picked?
Oops, sorry, I didn't realize Krzysztof is a DT maintainer.
On Fri, 31 Mar 2023 10:11:07 +0200
AngeloGioacchino Del Regno <[email protected]>
wrote:
> Il 23/03/23 10:08, AngeloGioacchino Del Regno ha scritto:
> > Some SoCs implementing ARM Mali GPUs are subject to speed binning:
> > this means that some versions of the same SoC model may need to be
> > limited to a slower frequency compared to the other:
> > this is being addressed by reading nvmem (usually, an eFuse array)
> > containing a number that identifies the speed binning of the chip,
> > which is usually related to silicon quality.
> >
> > To address such situation, add basic support for reading the
> > speed-bin through nvmem, as to make it possible to specify the
> > supported hardware in the OPP table for GPUs.
> > This commit also keeps compatibility with any platform that does
> > not specify (and does not even support) speed-binning.
> >
> > Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
>
> Hello maintainers,
> I've seen that this got archived in the dri-devel patchwork; because of that and
> only that, I'm sending this ping to get this patch reviewed.
Series queued to drm-misc-next.