* [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-19 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526555955-29960-11-git-send-email-ilialin@codeaurora.org>
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 10 +++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 164 +++++++++++++++++++++++++++++++++++
4 files changed, 178 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..ae2d1b9
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+#define SILVER_LEAD 0
+#define GOLD_LEAD 2
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id */
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int __init qcom_cpufreq_kryo_driver_init(void)
+{
+ struct device *cpu_dev_silver, *cpu_dev_gold;
+ struct opp_table *opp_silver, *opp_gold;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct platform_device *pdev;
+ struct device_node *np;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev_silver = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_silver))
+ return PTR_ERR(cpu_dev_silver);
+
+ cpu_dev_gold = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_gold))
+ return PTR_ERR(cpu_dev_gold);
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
+ if (IS_ERR_OR_NULL(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ ret = -ENOENT;
+ goto free_np;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ if (IS_ERR(speedbin_nvmem)) {
+ ret = PTR_ERR(speedbin_nvmem);
+ dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n", ret);
+ goto free_np;
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ opp_silver = dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
+ if (IS_ERR(opp_silver)) {
+ dev_err(cpu_dev_silver, "Failed to set supported hardware\n");
+ ret = PTR_ERR(opp_silver);
+ goto free_np;
+ }
+
+ opp_gold = dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
+ if (IS_ERR(opp_gold)) {
+ dev_err(cpu_dev_gold, "Failed to set supported hardware\n");
+ ret = PTR_ERR(opp_gold);
+ goto free_opp_silver;
+ }
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR_OR_NULL(pdev))
+ return 0;
+
+ ret = PTR_ERR(pdev);
+ dev_err(cpu_dev_silver, "Failed to register platform device\n");
+ dev_pm_opp_put_supported_hw(opp_gold);
+
+free_opp_silver:
+ dev_pm_opp_put_supported_hw(opp_silver);
+
+free_np:
+ of_node_put(np);
+
+ return ret;
+}
+late_initcall(qcom_cpufreq_kryo_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v4] pinctrl: msm: fix gpio-hog related boot issues
From: Christian Lamparter @ 2018-05-19 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152654016566.210890.15719083257170941464@swboyd.mtv.corp.google.com>
On Thursday, May 17, 2018 8:56:05 AM CEST Stephen Boyd wrote:
> Quoting Christian Lamparter (2018-05-16 13:29:48)
> > On Wednesday, May 16, 2018 5:31:16 PM CEST Stephen Boyd wrote:
> > > Why can't we register the gpiochip and tell it about the pin ranges in
> > > one API call instead of adding the chip and then adding the ranges? It
> > > doesn't look right to have to go and update all the DT nodes to list
> > > this information that is already known in the driver because the kernel
> > > implementation can't handle the order of operations correctly.
> > The problem is that gpiochip_add_pin_range() was not intended for
> > DT-based pinctrls... but it got used anyway.
>
> Are there more users of this on DT based systems? A quick grep shows a
> couple more potential failures, like the qcom based SPMI gpio controllers
> and a mediatek one.
Yes, it there are a few. In the reply to the original report from Sven I found:
<https://www.spinics.net/lists/linux-arm-msm/msg34726.html>
pinctrl-mt7622, pinctrl-mtk-common.c, pinctrl-abx500.c, pinctrl-msm.c,
pinctrl-as3722.c, pinctrl-at91-pio4.c, pinctrl-axp209.c, pinctrl-coh901.c,
pinctrl-digicolor.c, pinctrl-pistachio.c, pinctrl-sx150x.c
.. And now the new Actions S900 gpio/pinctrl patch as well.
(<https://lkml.org/lkml/2018/5/19/44>)
> It's almost like we should print a huge WARN_ON() if gpio_chip::of_node
> is non-NULL and gpochip_add_pin_range() is called. But that probably
> would be noisy and can't be fixed on older DT blobs. It may also be good
> to bail out of that function if the node pointer exists and the property
> is there in the node so that we don't have to go update each driver for
> the backwards compat mode like was done in this patch. Plus the function
> should get some sort of comment that calling it is not useful on DT
> based platforms so this is all documented.
Agreed. Though, adding a warning now is likely a bit much, since the code
has to be compatible with existing definitions. But if Linus agrees I think
it would be fair to call drivers out with something like "the use of this
function is deprecated for DT" debug level message.
(As for the documentation update to gpiochip_add_pin_range() and
gpiochip_add_pingroup_range(). yeah I'll give it a go.)
> > This topic came up in an earlier post:
> > "Re: pinctrl: qcom: ipq4019: Use of gpio-hog's" [0] (you must have gotten
> > this mail too, since you are on the Cc.) which links to a ML thread titled
> > "Re: [GIT PULL] SPEAr pinctrl updates for v-3.5"
>
> I get quite a bit of email as you can tell.
Everyone does :D.
> >
> > For your convenience: (this post is from 2012-09-03 - so it's 5-6 years
> > old by now and it looks like it predates even the DT pinctrl-msm driver.
> > (Not entirely sure?))
> > <http://thread.gmane.org/gmane.linux.ports.arm.kernel/184943>
> > |[...]
> > |But I want two similar function named:
> > |
> > |gpiochip_add_pin_range();
> > |gpiochip_remove_pin_range();
> > |
> > |*that can be used for platforms that doesn't support DT.*
> > |
> > |For example I'd like to convert over some of my existing
> > |drivers that do not have DT support to do this thing instead
> > |of registering ranges from the pin controller...
> >
> > I think you must have come across similar issues with the
> > "gpio-reserved-ranges" property you recently added. Because
> > from what I can glimpse from the
> > "[2/3] dt-bindings: pinctrl: Add a ngpios-ranges property"
> > <https://patchwork.kernel.org/patch/10153785/> series.
> > The gpio-reserved-ranges property would also need to be added
> > to existing products (msm8996) as well, right?
> > ("I stuck this inside msm8996, but maybe it can go somewhere more generic?")
>
> The gpio-reserved-ranges only affects some SoCs. It should be added to
> the bindings on whatever chips are affected by those firmware quirks as
> optional properties. It would be great if you could add it to the ones
> that may need it. My guess is that it only matters for the pin
> controllers that spread out each pin into a big range of I/O memory
> because otherwise pins aren't locked away from non-secure systems.
(- see text the end - )
> >
> > > Furthermore, it looks like this becomes a silent requirement to add the
> > > gpio-ranges property into the DT so that hogs work, but none of the
> > > bindings have been updated in this patch to indicate that.
> > The pinctrl-msm.c driver will fallback to using gpiochip_add_pin_range(),
> > if the gpio-ranges property is not present. So all existing and compiled
> > devicetree binaries files will remain compatible.
>
> That's good.
> >
> > As for adding the gpio-ranges to the dt binding text files under
> > Documentation/devicetree/bindings/pinctrl/: Sure. No problem. I can add
> > them too :).
>
> Great!
>
> >
> > But I do have a question: Should I also include the missing declaration
> > of the gpio-reserved-ranges properties too? (I can make the patches over
> > the long weekend. If I hear nothing from anyone, I'll post them on Monday).
>
> Sure. Do you have the list of pinctrl devices that may need the
> gpio-reserved-ranges property?
>
Oh, let me clarify. My plan is to add the binding documentation text for
the (now) semi-required gpio-ranges property. And while I'm patching the
files in Documentation/devicetree/bindings/pinctrl/qcom-* I can also add
the new gpio-reserved-ranges as an optional property well. This way it is
in place for the future. (This is nothing fancy. As both properties are
part of the gpio.txt already).
As for the dtsi updates, I don't think I can add any sensible
gpio-reserved-ranges to the individual SoC's dts in
arch/arm(64)/boot/dts/qcom-*dtsi without the HW/SoC or the documentation
which ranges need to be reserved. Because unlike the gpio-ranges values
(which are easy to extract from the drivers in drivers/pinctrl/qcom/)
the gpio-reserved-ranges for each SoCs is not yet documented (or I can't
find it?).
Regards,
Christian
^ permalink raw reply
* [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-19 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518014538.duphof6enscpm5vp@vireshk-i7>
>From c5804e1d17578a63ca87cc8fd839bf756cfe3567 Mon Sep 17 00:00:00 2001
In-Reply-To: <1526555955-29960-11-git-send-email-ilialin@codeaurora.org>
References: <1526555955-29960-11-git-send-email-ilialin@codeaurora.org>
From: Ilia Lin <ilialin@codeaurora.org>
Date: Thu, 17 May 2018 13:55:12 +0300
Subject: [PATCH] cpufreq: Add Kryo CPU scaling driver
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 10 +++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 164
+++++++++++++++++++++++++++++++++++
4 files changed, 178 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..ae2d1b9
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling
Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP
of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+#define SILVER_LEAD 0
+#define GOLD_LEAD 2
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id
*/
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int __init qcom_cpufreq_kryo_driver_init(void)
+{
+ struct device *cpu_dev_silver, *cpu_dev_gold;
+ struct opp_table *opp_silver, *opp_gold;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct platform_device *pdev;
+ struct device_node *np;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev_silver = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_silver))
+ return PTR_ERR(cpu_dev_silver);
+
+ cpu_dev_gold = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_gold))
+ return PTR_ERR(cpu_dev_gold);
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
+ if (IS_ERR_OR_NULL(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ ret = -ENOENT;
+ goto free_np;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ if (IS_ERR(speedbin_nvmem)) {
+ ret = PTR_ERR(speedbin_nvmem);
+ dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
ret);
+ goto free_np;
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ opp_silver =
dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
+ if (IS_ERR(opp_silver)) {
+ dev_err(cpu_dev_silver, "Failed to set supported
hardware\n");
+ ret = PTR_ERR(opp_silver);
+ goto free_np;
+ }
+
+ opp_gold = dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
+ if (IS_ERR(opp_gold)) {
+ dev_err(cpu_dev_gold, "Failed to set supported hardware\n");
+ ret = PTR_ERR(opp_gold);
+ goto free_opp_silver;
+ }
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR_OR_NULL(pdev))
+ return 0;
+
+ ret = PTR_ERR(pdev);
+ dev_err(cpu_dev_silver, "Failed to register platform device\n");
+ dev_pm_opp_put_supported_hw(opp_gold);
+
+free_opp_silver:
+ dev_pm_opp_put_supported_hw(opp_silver);
+
+free_np:
+ of_node_put(np);
+
+ return ret;
+}
+late_initcall(qcom_cpufreq_kryo_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Friday, May 18, 2018 04:46
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: mturquette at baylibre.com; sboyd at kernel.org; robh at kernel.org;
> mark.rutland at arm.com; nm at ti.com; lgirdwood at gmail.com;
> broonie at kernel.org; andy.gross at linaro.org; david.brown at linaro.org;
> catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net; linux-
> clk at vger.kernel.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-
> msm at vger.kernel.org; linux-soc at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; rnayak at codeaurora.org;
> amit.kucheria at linaro.org; nicolas.dechesne at linaro.org;
> celster at codeaurora.org; tfinkel at codeaurora.org
> Subject: Re: [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
>
> On 17-05-18, 14:19, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_driver_init(void)
> > +{
> > + size_t len;
> > + int ret = 0;
> > + u32 versions;
> > + enum _msm8996_version msm8996_version;
> > + u8 *speedbin;
> > + struct device *cpu_dev_silver, *cpu_dev_gold;
> > + struct device_node *np;
> > + struct nvmem_cell *speedbin_nvmem;
> > + struct platform_device *pdev;
> > + struct opp_table *opp_silver = NULL;
> > + struct opp_table *opp_gold = NULL;
>
> No need to initialize them and you may want to arrange all above in
> decreasing order of their length.
>
> > +
> > + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_silver))
> > + return PTR_ERR(cpu_dev_silver);
> > +
> > + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_gold))
> > + return PTR_ERR(cpu_dev_gold);
> > +
> > + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> > + dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
> > + return -ENODEV;
> > + }
> > +
> > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
> > + if (IS_ERR_OR_NULL(np))
> > + return PTR_ERR(np);
> > +
> > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> > + ret = -ENOENT;
> > + goto free_np;
> > + }
> > +
> > + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> > + if (IS_ERR(speedbin_nvmem)) {
> > + ret = PTR_ERR(speedbin_nvmem);
> > + dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
> ret);
> > + goto free_np;
> > + }
> > +
> > + speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> > + nvmem_cell_put(speedbin_nvmem);
> > +
> > + switch (msm8996_version) {
> > + case MSM8996_V3:
> > + versions = 1 << (unsigned int)(*speedbin);
> > + break;
> > + case MSM8996_SG:
> > + versions = 1 << ((unsigned int)(*speedbin) + 4);
> > + break;
> > + default:
> > + BUG();
> > + break;
> > + }
> > +
> > + opp_silver =
> dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_silver)) {
>
> This API doesn't return NULL and so IS_ERR() would be sufficient.
>
> > + dev_err(cpu_dev_silver, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_silver);
> > + goto free_np;
> > + }
> > +
> > + opp_gold =
> dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_gold)) {
>
> same here.
>
> > + dev_err(cpu_dev_gold, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_gold);
> > + goto free_opp_silver;
> > + }
> > +
> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> > + if (!IS_ERR_OR_NULL(pdev))
> > + goto out;
>
> Simply return from here and remove the useless label out.
>
> > +
> > + ret = PTR_ERR(pdev);
> > + dev_err(cpu_dev_silver, "Failed to register platform device\n");
> > + dev_pm_opp_put_supported_hw(opp_gold);
> > +
> > +free_opp_silver:
> > + dev_pm_opp_put_supported_hw(opp_silver);
> > +
> > +free_np:
> > + of_node_put(np);
> > +
> > +out:
> > + return ret;
> > +}
> > +late_initcall(qcom_cpufreq_kryo_driver_init);
>
> Please resend only this patch now or just paste the new code in a mail
here
> so that I can review it quickly and then you can resend the final version.
Most
> of the patches aren't changing anyway.
>
> --
> viresh
^ permalink raw reply related
* [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-19 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518014538.duphof6enscpm5vp@vireshk-i7>
Hi Viresh,
If I send patches in reply, it will produce new patches, instead of answers
in the thread. Please find below the file dump.
->cat drivers/cpufreq/qcom-cpufreq-kryo.c
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2018, The Linux Foundation. All rights reserved.
*/
/*
* In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
* the CPU frequency subset and voltage value of each OPP varies
* based on the silicon variant in use. Qualcomm Process Voltage Scaling
Tables
* defines the voltage and frequency value based on the msm-id in SMEM
* and speedbin blown in the efuse combination.
* The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
SoC
* to provide the OPP framework with required information.
* This is used to determine the voltage and frequency value for each OPP of
* operating-points-v2 table when it is parsed by the OPP framework.
*/
#include <linux/cpu.h>
#include <linux/err.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/nvmem-consumer.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
#include <linux/slab.h>
#include <linux/soc/qcom/smem.h>
#define MSM_ID_SMEM 137
#define SILVER_LEAD 0
#define GOLD_LEAD 2
enum _msm_id {
MSM8996V3 = 0xF6ul,
APQ8096V3 = 0x123ul,
MSM8996SG = 0x131ul,
APQ8096SG = 0x138ul,
};
enum _msm8996_version {
MSM8996_V3,
MSM8996_SG,
NUM_OF_MSM8996_VERSIONS,
};
static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
{
size_t len;
u32 *msm_id;
enum _msm8996_version version;
msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
/* The first 4 bytes are format, next to them is the actual msm-id
*/
msm_id++;
switch ((enum _msm_id)*msm_id) {
case MSM8996V3:
case APQ8096V3:
version = MSM8996_V3;
break;
case MSM8996SG:
case APQ8096SG:
version = MSM8996_SG;
break;
default:
version = NUM_OF_MSM8996_VERSIONS;
}
return version;
}
static int __init qcom_cpufreq_kryo_driver_init(void)
{
struct device *cpu_dev_silver, *cpu_dev_gold;
struct opp_table *opp_silver, *opp_gold;
enum _msm8996_version msm8996_version;
struct nvmem_cell *speedbin_nvmem;
struct platform_device *pdev;
struct device_node *np;
u8 *speedbin;
u32 versions;
size_t len;
int ret;
cpu_dev_silver = get_cpu_device(SILVER_LEAD);
if (IS_ERR_OR_NULL(cpu_dev_silver))
return PTR_ERR(cpu_dev_silver);
cpu_dev_gold = get_cpu_device(SILVER_LEAD);
if (IS_ERR_OR_NULL(cpu_dev_gold))
return PTR_ERR(cpu_dev_gold);
msm8996_version = qcom_cpufreq_kryo_get_msm_id();
if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
return -ENODEV;
}
np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
if (IS_ERR_OR_NULL(np))
return PTR_ERR(np);
if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
ret = -ENOENT;
goto free_np;
}
speedbin_nvmem = of_nvmem_cell_get(np, NULL);
if (IS_ERR(speedbin_nvmem)) {
ret = PTR_ERR(speedbin_nvmem);
dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
ret);
goto free_np;
}
speedbin = nvmem_cell_read(speedbin_nvmem, &len);
nvmem_cell_put(speedbin_nvmem);
switch (msm8996_version) {
case MSM8996_V3:
versions = 1 << (unsigned int)(*speedbin);
break;
case MSM8996_SG:
versions = 1 << ((unsigned int)(*speedbin) + 4);
break;
default:
BUG();
break;
}
opp_silver =
dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
if (IS_ERR(opp_silver)) {
dev_err(cpu_dev_silver, "Failed to set supported
hardware\n");
ret = PTR_ERR(opp_silver);
goto free_np;
}
opp_gold = dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
if (IS_ERR(opp_gold)) {
dev_err(cpu_dev_gold, "Failed to set supported hardware\n");
ret = PTR_ERR(opp_gold);
goto free_opp_silver;
}
pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
if (!IS_ERR_OR_NULL(pdev))
return 0;
ret = PTR_ERR(pdev);
dev_err(cpu_dev_silver, "Failed to register platform device\n");
dev_pm_opp_put_supported_hw(opp_gold);
free_opp_silver:
dev_pm_opp_put_supported_hw(opp_silver);
free_np:
of_node_put(np);
return ret;
}
late_initcall(qcom_cpufreq_kryo_driver_init);
MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
MODULE_LICENSE("GPL v2");
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Friday, May 18, 2018 04:46
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: mturquette at baylibre.com; sboyd at kernel.org; robh at kernel.org;
> mark.rutland at arm.com; nm at ti.com; lgirdwood at gmail.com;
> broonie at kernel.org; andy.gross at linaro.org; david.brown at linaro.org;
> catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net; linux-
> clk at vger.kernel.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-
> msm at vger.kernel.org; linux-soc at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; rnayak at codeaurora.org;
> amit.kucheria at linaro.org; nicolas.dechesne at linaro.org;
> celster at codeaurora.org; tfinkel at codeaurora.org
> Subject: Re: [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
>
> On 17-05-18, 14:19, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_driver_init(void)
> > +{
> > + size_t len;
> > + int ret = 0;
> > + u32 versions;
> > + enum _msm8996_version msm8996_version;
> > + u8 *speedbin;
> > + struct device *cpu_dev_silver, *cpu_dev_gold;
> > + struct device_node *np;
> > + struct nvmem_cell *speedbin_nvmem;
> > + struct platform_device *pdev;
> > + struct opp_table *opp_silver = NULL;
> > + struct opp_table *opp_gold = NULL;
>
> No need to initialize them and you may want to arrange all above in
> decreasing order of their length.
>
> > +
> > + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_silver))
> > + return PTR_ERR(cpu_dev_silver);
> > +
> > + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_gold))
> > + return PTR_ERR(cpu_dev_gold);
> > +
> > + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> > + dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
> > + return -ENODEV;
> > + }
> > +
> > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
> > + if (IS_ERR_OR_NULL(np))
> > + return PTR_ERR(np);
> > +
> > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> > + ret = -ENOENT;
> > + goto free_np;
> > + }
> > +
> > + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> > + if (IS_ERR(speedbin_nvmem)) {
> > + ret = PTR_ERR(speedbin_nvmem);
> > + dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
> ret);
> > + goto free_np;
> > + }
> > +
> > + speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> > + nvmem_cell_put(speedbin_nvmem);
> > +
> > + switch (msm8996_version) {
> > + case MSM8996_V3:
> > + versions = 1 << (unsigned int)(*speedbin);
> > + break;
> > + case MSM8996_SG:
> > + versions = 1 << ((unsigned int)(*speedbin) + 4);
> > + break;
> > + default:
> > + BUG();
> > + break;
> > + }
> > +
> > + opp_silver =
> dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_silver)) {
>
> This API doesn't return NULL and so IS_ERR() would be sufficient.
>
> > + dev_err(cpu_dev_silver, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_silver);
> > + goto free_np;
> > + }
> > +
> > + opp_gold =
> dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_gold)) {
>
> same here.
>
> > + dev_err(cpu_dev_gold, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_gold);
> > + goto free_opp_silver;
> > + }
> > +
> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> > + if (!IS_ERR_OR_NULL(pdev))
> > + goto out;
>
> Simply return from here and remove the useless label out.
>
> > +
> > + ret = PTR_ERR(pdev);
> > + dev_err(cpu_dev_silver, "Failed to register platform device\n");
> > + dev_pm_opp_put_supported_hw(opp_gold);
> > +
> > +free_opp_silver:
> > + dev_pm_opp_put_supported_hw(opp_silver);
> > +
> > +free_np:
> > + of_node_put(np);
> > +
> > +out:
> > + return ret;
> > +}
> > +late_initcall(qcom_cpufreq_kryo_driver_init);
>
> Please resend only this patch now or just paste the new code in a mail
here
> so that I can review it quickly and then you can resend the final version.
Most
> of the patches aren't changing anyway.
>
> --
> viresh
^ permalink raw reply
* [RESEND][PATCH] pwm: Set class for exported channels in sysfs
From: Stefan Wahren @ 2018-05-19 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1b6b62e-8fcb-bff0-b532-aa0879d301ed@st.com>
Hello Fabrice,
> Fabrice Gasnier <fabrice.gasnier@st.com> hat am 30. M?rz 2018 um 14:40 geschrieben:
>
>
> On 09/26/2017 01:59 PM, gohai at sukzessiv.net wrote:
> > Notifications for devices without bus or class set get dropped by
> > dev_uevent_filter. Adding the class to the exported child matches
> > what the gpio subsystem is doing.
> >
> > With this change exporting a channel triggers a udev event, which
> > gives userspace a chance to fixup permissions and makes it possible
> > for non-root users to make use of the pwm subsystem.
> >
> > Signed-off-by: Gottfried Haider <gottfried.haider@gmail.com>
> > CC: Thierry Reding <thierry.reding@gmail.com>
> > CC: H Hartley Sweeten <hsweeten@visionengravers.com>
> > CC: linux-pwm at vger.kernel.org
> > CC: linux-arm-kernel at lists.infradead.org
> > CC: linux-rpi-kernel at lists.infradead.org
> > ---
> > drivers/pwm/sysfs.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> > index a813239..83f2b0b 100644
> > --- a/drivers/pwm/sysfs.c
> > +++ b/drivers/pwm/sysfs.c
> > @@ -263,6 +263,7 @@ static int pwm_export_child(struct device *parent, struct pwm_device *pwm)
> > export->pwm = pwm;
> > mutex_init(&export->lock);
> >
> > + export->child.class = parent->class;
>
> Hi all,
>
> Sorry to raise this old mail thread. I just figured out this patch is
> causing *regression* on v4.16-rcs.
>
> This patch has side effect at my end, with multiple pwm chip. It creates
> a new entry in '/sys/class/pwm' every time a 'pwmX' is exported:
> - echo X > export
>
> This breaks pwm on platforms that have multiple pwmchip:
> - 1st time export will create a /sys/class/pwm/pwmX
> - when another export happens on another pwmchip, it can't be created
> (e.g. -EEXIST)
>
> I looked at /Documentation/ABI/testing/sysfs-class-pwm:
> - pmwX should be there: /sys/class/pwm/pwmchipN/pwmX (only ?)
>
> With this patch:
> - pwmX symlink is created in addition, directly under /sys/class/pwm
>
> Example on stm32 (stm32429i-eval) platform:
> ---
> $ ls /sys/class/pwm
> pwmchip0 pwmchip4
>
> $ cd /sys/class/pwm/pwmchip0/
> $ echo 0 > export
>
> $ ls /sys/class/pwm
> pwm0 pwmchip0 pwmchip4
>
> $ cd /sys/class/pwm/pwmchip4/
> $ echo 0 > export
>
> sysfs: cannot create duplicate filename '/class/pwm/pwm0'
> CPU: 0 PID: 50 Comm: sh Not tainted 4.16.0-rc7-00020-g3361545 #1682
> Hardware name: STM32 (Device Tree Support)
> [<0000c0f1>] (unwind_backtrace) from [<0000b23b>] (show_stack+0xb/0xc)
> [<0000b23b>] (show_stack) from [<0008d2f1>] (sysfs_warn_dup+0x31/0x48)
> [<0008d2f1>] (sysfs_warn_dup) from [<0008d4a5>]
> (sysfs_do_create_link_sd+0x75/0x88)
> [<0008d4a5>] (sysfs_do_create_link_sd) from [<000e8e91>]
> (device_add+0x111/0x374)
> [<000e8e91>] (device_add) from [<000ca795>] (export_store+0xb5/0x12c)
> [<000ca795>] (export_store) from [<0008c899>] (kernfs_fop_write+0x87/0xda)
> [<0008c899>] (kernfs_fop_write) from [<0005a0a5>] (__vfs_write+0x1d/0xcc)
> [<0005a0a5>] (__vfs_write) from [<0005a1c7>] (vfs_write+0x4f/0x7c)
> [<0005a1c7>] (vfs_write) from [<0005a29b>] (SyS_write+0x33/0x70)
> [<0005a29b>] (SyS_write) from [<00009001>] (ret_fast_syscall+0x1/0x58)
> Exception stack...
> -sh: write error: File exists
>
> Not sure what the best fix would be thought :-(
>
> probably pwmX should be named also according with pwmchipN ?
> - dev_set_name(&export->child, "pwm%u", pwm->hwpwm);
> + dev_set_name(&export->child, "pwmchip%d-pwm%u", chip->base, pwm->hwpwm);
> BUT I think this would break existing ABI...
>
> Also this is quite late in the cycle. Maybe a revert would be wise for now ?
sorry i didn't noticed your mail before. Could you please prepare a revert patch?
Thanks
Stefan
^ permalink raw reply
* [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
From: Russell King - ARM Linux @ 2018-05-19 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <018701d3ef61$dfd5e700$9f81b500$@codeaurora.org>
On Sat, May 19, 2018 at 02:09:24PM +0300, ilialin at codeaurora.org wrote:
> +static int __init qcom_cpufreq_kryo_driver_init(void)
> +{
> + struct device *cpu_dev_silver, *cpu_dev_gold;
> + struct opp_table *opp_silver, *opp_gold;
> + enum _msm8996_version msm8996_version;
> + struct nvmem_cell *speedbin_nvmem;
> + struct platform_device *pdev;
> + struct device_node *np;
> + u8 *speedbin;
> + u32 versions;
> + size_t len;
> + int ret;
> +
> + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> + if (IS_ERR_OR_NULL(cpu_dev_silver))
> + return PTR_ERR(cpu_dev_silver);
> +
> + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> + if (IS_ERR_OR_NULL(cpu_dev_gold))
> + return PTR_ERR(cpu_dev_gold);
> +
> + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> + dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
> + return -ENODEV;
> + }
> +
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
> + if (IS_ERR_OR_NULL(np))
> + return PTR_ERR(np);
This function (qcom_cpufreq_kryo_driver_init) returns zero on success.
You are checking "np" here for being an error pointer, or NULL.
What value do you think PTR_ERR() returns in the case of PTR_ERR(NULL)?
IS_ERR_OR_NULL() is considered by some (me included) as being _very_
harmful because programmers generally fail to look at linux/err.h and
consider what it means when used as above.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-05-19 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AexXNEGVoXa9K_GAm+aFLNRQOXOhF_SdKAjV1qmuD2nA@mail.gmail.com>
Hi Fabio,
Thanks for your feedback.
> Hi Lukasz,
>
> On Wed, May 9, 2018 at 12:34 PM, Lukasz Majewski <lukma@denx.de>
> wrote:
>
> > +&iomuxc {
> > + imx53-kp-ddc {
>
> No need for keeping this imx53-kp-ddc.
>
> > diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts
> > b/arch/arm/boot/dts/imx53-kp-hsc.dts new file mode 100644
> > index 000000000000..fff358395c9d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
> > @@ -0,0 +1,53 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2018
> > + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> > + */
> > +
> > +/dts-v1/;
> > +#include "imx53-kp.dtsi"
> > +
> > +/ {
> > + model = "K+P imx53 HSC";
> > + compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
> > +
>
> No need for this blank line.
>
> > +};
> > +
> > +&fec {
> > + status = "okay";
>
> We usually put the status in the last line.
After moving status property to the end:
Error: arch/arm/boot/dts/imx53-kp-hsc.dts:21.2-18 Properties must
precede subnodes FATAL ERROR: Unable to parse input tree
So I opt for leaving it as it was.
>
> > + gpio_buttons {
> > + compatible = "gpio-keys";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpiobuttons>;
> > +
> > + button at 1 {
>
> You pass @1 without a reg property. This triggers a warning when
> building with W=1.
>
> You could remove the @1.
>
> Please make sure this patch does not introduce any W=1 dtc warning.
>
> > +&iomuxc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_kp_common>;
> > +
> > + imx53-kp-common {
>
> No need for this imx53-kp-common
After removing imx53-kp-ddc and imx53-kp-common iomux subnodes I do see
following errors in the dmesg (v4.17-rc5):
imx53-pinctrl 53fa8000.iomuxc: function 'iomuxc' not supported
imx53-pinctrl 53fa8000.iomuxc: invalid function iomuxc in map table
Above statements are not visible when I use the v1 code of this patch.
>
> > +&uart4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart4>;
> > +
>
> No need for this blank line.
I will sent fixed version in v2.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180519/1f5a7146/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-05-19 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509153428.1440-1-lukma@denx.de>
This commit provides support for HSC and DDC boards from
Kieback&Peter GmbH vendor.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Remove not needed #address-cells and #size-cells in
the gpio_buttons node to pass make W=1
- Rename button@{12} to button_{kalt|pwr} nodes to pass make W=1
- Include #include <dt-bindings/input/input.h> to use KEY_F6|F7 directly
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx53-kp-ddc.dts | 146 ++++++++++++++++++++++++++++
arch/arm/boot/dts/imx53-kp-hsc.dts | 51 ++++++++++
arch/arm/boot/dts/imx53-kp.dtsi | 190 +++++++++++++++++++++++++++++++++++++
4 files changed, 389 insertions(+)
create mode 100644 arch/arm/boot/dts/imx53-kp-ddc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp-hsc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fbc04b0db781..00854a5b6ac4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -360,6 +360,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
dtb-$(CONFIG_SOC_IMX53) += \
imx53-ard.dtb \
imx53-cx9020.dtb \
+ imx53-kp-ddc.dtb \
+ imx53-kp-hsc.dtb \
imx53-m53evk.dtb \
imx53-mba53.dtb \
imx53-ppd.dtb \
diff --git a/arch/arm/boot/dts/imx53-kp-ddc.dts b/arch/arm/boot/dts/imx53-kp-ddc.dts
new file mode 100644
index 000000000000..acaf477a52c5
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-ddc.dts
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 DDC";
+ compatible = "kiebackpeter,imx53-ddc", "fsl,imx53";
+
+ backlight_lcd: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 50000>;
+ power-supply = <®_backlight>;
+ brightness-levels = <0 24 28 32 36
+ 40 44 48 52 56
+ 60 64 68 72 76
+ 80 84 88 92 96 100>;
+ default-brightness-level = <20>;
+ };
+
+ lcd_display: disp1 {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_disp>;
+
+ port at 0 {
+ reg = <0>;
+
+ display1_in: endpoint {
+ remote-endpoint = <&ipu_di1_disp1>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ lcd_display_out: endpoint {
+ remote-endpoint = <&lcd_panel_in>;
+ };
+ };
+ };
+
+ lcd_panel: lcd-panel {
+ compatible = "koe,tx14d24vm1bpa";
+ backlight = <&backlight_lcd>;
+ power-supply = <®_3v3>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
+
+ reg_backlight: regulator-backlight {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight-supply";
+ regulator-min-microvolt = <15000000>;
+ regulator-max-microvolt = <15000000>;
+ regulator-always-on;
+ };
+};
+
+&i2c3 {
+ adc at 48 {
+ compatible = "ti,ads1015";
+ reg = <0x48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel at 4 {
+ reg = <4>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+
+ channel at 6 {
+ reg = <6>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+ };
+
+ gpio_expander2 at 21 {
+ compatible = "nxp,pcf8574";
+ reg = <0x21>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
+
+&iomuxc {
+ imx53-kp-ddc {
+ pinctrl_disp: dispgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 0x4
+ MX53_PAD_EIM_DA10__IPU_DI1_PIN15 0x4
+ MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 0x4
+ MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 0x4
+ MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 0x4
+ MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 0x4
+ MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 0x4
+ MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 0x4
+ MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 0x4
+ MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 0x4
+ MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 0x4
+ MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 0x4
+ MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 0x4
+ MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 0x4
+ MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 0x4
+ MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 0x4
+ MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 0x4
+ MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 0x4
+ MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 0x4
+ MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 0x4
+ MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 0x4
+ MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 0x4
+ MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 0x4
+ MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 0x4
+ MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x4
+ MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 0x4
+ MX53_PAD_GPIO_1__PWM2_PWMO 0x4
+ >;
+ };
+ };
+};
+
+&ipu_di1_disp1 {
+ remote-endpoint = <&display1_in>;
+};
+
+&fec {
+ status = "okay";
+};
+
+&pmic {
+ fsl,mc13xxx-uses-touch;
+};
diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts b/arch/arm/boot/dts/imx53-kp-hsc.dts
new file mode 100644
index 000000000000..d68cdd5da819
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 HSC";
+ compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
+};
+
+&fec {
+ status = "okay";
+ fixed-link { /* RMII fixed link to LAN9303 */
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&i2c3 {
+ switch: switch at a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <400>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 { /* RMII fixed link to master */
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&fec>;
+ };
+
+ port at 1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port at 2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx53-kp.dtsi b/arch/arm/boot/dts/imx53-kp.dtsi
new file mode 100644
index 000000000000..f87266843842
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp.dtsi
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-tqma53.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ buzzer {
+ compatible = "pwm-beeper";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_buzzer>;
+
+ pwms = <&pwm1 0 500000>;
+ };
+
+ gpio_buttons {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiobuttons>;
+
+ button_kalt {
+ label = "Kaltstart";
+ linux,code = <KEY_F6>;
+ gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ button_pwr {
+ label = "PowerFailInterrupt";
+ linux,code = <KEY_F7>;
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led_bus {
+ label = "bus";
+ gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led_error {
+ label = "error";
+ gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led_flash {
+ label = "flash";
+ gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+
+ gpio_expander1 at 22 {
+ compatible = "nxp,pcf8574";
+ reg = <0x22>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ rtc at 51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_kp_common>;
+
+ imx53-kp-common {
+ pinctrl_buzzer: buzzergrp {
+ fsl,pins = <
+ MX53_PAD_SD1_DATA3__PWM1_PWMO 0x1e4
+ >;
+ };
+
+ pinctrl_gpiobuttons: gpiobuttonsgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_RW__GPIO2_26 0x1e4
+ MX53_PAD_EIM_D22__GPIO3_22 0x1e4
+ >;
+ };
+
+ pinctrl_kp_common: kpcommongrp {
+ fsl,pins = <
+ MX53_PAD_EIM_CS0__GPIO2_23 0x1e4
+ MX53_PAD_GPIO_19__GPIO4_5 0x1e4
+ MX53_PAD_PATA_DATA6__GPIO2_6 0x1e4
+ MX53_PAD_PATA_DATA7__GPIO2_7 0xe0
+ MX53_PAD_CSI0_DAT14__GPIO6_0 0x1e4
+ MX53_PAD_CSI0_DAT16__GPIO6_2 0x1e4
+ MX53_PAD_CSI0_DAT18__GPIO6_4 0x1e4
+ MX53_PAD_EIM_D17__GPIO3_17 0x1e4
+ MX53_PAD_EIM_D18__GPIO3_18 0x1e4
+ MX53_PAD_EIM_D21__GPIO3_21 0x1e4
+ MX53_PAD_EIM_D29__GPIO3_29 0x1e4
+ MX53_PAD_EIM_DA11__GPIO3_11 0x1e4
+ MX53_PAD_EIM_DA13__GPIO3_13 0x1e4
+ MX53_PAD_EIM_DA14__GPIO3_14 0x1e4
+ MX53_PAD_SD1_DATA0__GPIO1_16 0x1e4
+ MX53_PAD_SD1_CMD__GPIO1_18 0x1e4
+ MX53_PAD_SD1_CLK__GPIO1_20 0x1e4
+ >;
+ };
+
+ pinctrl_leds: ledgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_EB2__GPIO2_30 0x1d4
+ MX53_PAD_EIM_D28__GPIO3_28 0x1d4
+ MX53_PAD_EIM_WAIT__GPIO5_0 0x1d4
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 0x1e4
+ MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 0x1e4
+ >;
+ };
+ };
+};
+
+&pinctrl_uart1 {
+ fsl,pins = <
+ MX53_PAD_EIM_D23__GPIO3_23 0x1e4
+ MX53_PAD_EIM_EB3__GPIO2_31 0x1e4
+ MX53_PAD_EIM_D24__GPIO3_24 0x1e4
+ MX53_PAD_EIM_D25__GPIO3_25 0x1e4
+ MX53_PAD_EIM_D19__GPIO3_19 0x1e4
+ MX53_PAD_EIM_D20__GPIO3_20 0x1e4
+ >;
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbphy0 {
+ status = "disabled";
+};
--
2.11.0
^ permalink raw reply related
* [RFC PATCH] counter: 104-quad-8: quad8_ops can be static
From: kbuild test robot @ 2018-05-19 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <881ede525a87ef68fad76cc757ce0ba72df03e5a.1526487615.git.vilhelm.gray@gmail.com>
Fixes: b3822048aa0b ("counter: 104-quad-8: Add Generic Counter interface support")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
104-quad-8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
index 7c72fb7..8696a512 100644
--- a/drivers/counter/104-quad-8.c
+++ b/drivers/counter/104-quad-8.c
@@ -800,7 +800,7 @@ static int quad8_action_get(struct counter_device *counter,
return 0;
}
-const struct counter_ops quad8_ops = {
+static const struct counter_ops quad8_ops = {
.signal_read = quad8_signal_read,
.count_read = quad8_count_read,
.count_write = quad8_count_write,
^ permalink raw reply related
* [PATCH v6 4/9] counter: 104-quad-8: Add Generic Counter interface support
From: kbuild test robot @ 2018-05-19 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <881ede525a87ef68fad76cc757ce0ba72df03e5a.1526487615.git.vilhelm.gray@gmail.com>
Hi William,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-subsystem/20180519-151353
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/counter/104-quad-8.c:803:26: sparse: symbol 'quad8_ops' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v6 4/9] counter: 104-quad-8: Add Generic Counter interface support
From: William Breathitt Gray @ 2018-05-19 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201805192140.de07sSol%fengguang.wu@intel.com>
On Sat, May 19, 2018 at 09:16:55PM +0800, kbuild test robot wrote:
>Hi William,
>
>I love your patch! Perhaps something to improve:
>
>[auto build test WARNING on linus/master]
>[also build test WARNING on v4.17-rc5 next-20180517]
>[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
>url: https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-subsystem/20180519-151353
>reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
>sparse warnings: (new ones prefixed by >>)
>
>>> drivers/counter/104-quad-8.c:803:26: sparse: symbol 'quad8_ops' was not declared. Should it be static?
>
>Please review and possibly fold the followup patch.
Ah, yes it should be static -- looks like I made a minor mistake. I'll
squash the fix into the next revision of this patchset.
Thank you,
William Breathitt Gray
>
>---
>0-DAY kernel test infrastructure Open Source Technology Center
>https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v6 3/9] docs: Add Generic Counter interface documentation
From: kbuild test robot @ 2018-05-19 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aa4d62315bb11ddc66d0e1a685c81b1721ffe624.1526487615.git.vilhelm.gray@gmail.com>
Hi William,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-subsystem/20180519-151353
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org)
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev'
include/net/cfg80211.h:4216: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev'
include/net/mac80211.h:2282: warning: Function parameter or member 'radiotap_timestamp.units_pos' not described in 'ieee80211_hw'
include/net/mac80211.h:2282: warning: Function parameter or member 'radiotap_timestamp.accuracy' not described in 'ieee80211_hw'
include/net/mac80211.h:955: warning: Function parameter or member 'control.rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info'
include/net/mac80211.h:955: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info'
net/mac80211/sta_info.h:586: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info'
kernel/sched/fair.c:3719: warning: Function parameter or member 'flags' not described in 'attach_entity_load_avg'
include/linux/dma-buf.h:307: warning: Function parameter or member 'cb_excl.cb' not described in 'dma_buf'
include/linux/dma-buf.h:307: warning: Function parameter or member 'cb_excl.poll' not described in 'dma_buf'
include/linux/dma-buf.h:307: warning: Function parameter or member 'cb_excl.active' not described in 'dma_buf'
include/linux/dma-buf.h:307: warning: Function parameter or member 'cb_shared.cb' not described in 'dma_buf'
include/linux/dma-buf.h:307: warning: Function parameter or member 'cb_shared.poll' not described in 'dma_buf'
include/linux/dma-buf.h:307: warning: Function parameter or member 'cb_shared.active' not described in 'dma_buf'
include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array'
>> include/linux/counter.h:330: warning: Function parameter or member 'groups_list' not described in 'counter_device_state'
>> include/linux/counter.h:330: warning: Function parameter or member 'num_groups' not described in 'counter_device_state'
include/linux/gpio/driver.h:142: warning: Function parameter or member 'request_key' not described in 'gpio_irq_chip'
include/linux/iio/iio.h:270: warning: Function parameter or member 'scan_type.sign' not described in 'iio_chan_spec'
include/linux/iio/iio.h:270: warning: Function parameter or member 'scan_type.realbits' not described in 'iio_chan_spec'
include/linux/iio/iio.h:270: warning: Function parameter or member 'scan_type.storagebits' not described in 'iio_chan_spec'
include/linux/iio/iio.h:270: warning: Function parameter or member 'scan_type.shift' not described in 'iio_chan_spec'
include/linux/iio/iio.h:270: warning: Function parameter or member 'scan_type.repeat' not described in 'iio_chan_spec'
include/linux/iio/iio.h:270: warning: Function parameter or member 'scan_type.endianness' not described in 'iio_chan_spec'
include/linux/iio/hw-consumer.h:1: warning: no structured comments found
include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not described in 'key_entry'
include/linux/mtd/rawnand.h:752: warning: Function parameter or member 'timings.sdr' not described in 'nand_data_interface'
include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf' not described in 'nand_op_data_instr'
include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.in' not described in 'nand_op_data_instr'
include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.out' not described in 'nand_op_data_instr'
include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx' not described in 'nand_op_instr'
include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.cmd' not described in 'nand_op_instr'
include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_instr'
include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.data' not described in 'nand_op_instr'
include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.waitrdy' not described in 'nand_op_instr'
include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx' not described in 'nand_op_parser_pattern_elem'
include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_parser_pattern_elem'
include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.data' not described in 'nand_op_parser_pattern_elem'
include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.desc' not described in 'nand_chip'
include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.priv' not described in 'nand_chip'
include/linux/regulator/driver.h:222: warning: Function parameter or member 'resume_early' not described in 'regulator_ops'
drivers/regulator/core.c:4306: warning: Excess function parameter 'state' description in 'regulator_suspend_late'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw0' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw1' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw2' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw3' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.eadm' not described in 'irb'
drivers/usb/typec/mux.c:186: warning: Function parameter or member 'mux' not described in 'typec_mux_unregister'
drivers/usb/typec/mux.c:186: warning: Excess function parameter 'sw' description in 'typec_mux_unregister'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_pin' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_unpin' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_res_obj' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_get_sg_table' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_import_sg_table' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_vmap' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_vunmap' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_mmap' not described in 'drm_driver'
drivers/gpu/drm/drm_prime.c:342: warning: Function parameter or member 'attach' not described in 'drm_gem_unmap_dma_buf'
drivers/gpu/drm/drm_prime.c:342: warning: Function parameter or member 'sgt' not described in 'drm_gem_unmap_dma_buf'
drivers/gpu/drm/drm_prime.c:342: warning: Function parameter or member 'dir' not described in 'drm_gem_unmap_dma_buf'
drivers/gpu/drm/drm_prime.c:438: warning: Function parameter or member 'dma_buf' not described in 'drm_gem_dmabuf_kmap_atomic'
drivers/gpu/drm/drm_prime.c:438: warning: Function parameter or member 'page_num' not described in 'drm_gem_dmabuf_kmap_atomic'
drivers/gpu/drm/drm_prime.c:450: warning: Function parameter or member 'dma_buf' not described in 'drm_gem_dmabuf_kunmap_atomic'
drivers/gpu/drm/drm_prime.c:450: warning: Function parameter or member 'page_num' not described in 'drm_gem_dmabuf_kunmap_atomic'
drivers/gpu/drm/drm_prime.c:450: warning: Function parameter or member 'addr' not described in 'drm_gem_dmabuf_kunmap_atomic'
drivers/gpu/drm/drm_prime.c:461: warning: Function parameter or member 'dma_buf' not described in 'drm_gem_dmabuf_kmap'
drivers/gpu/drm/drm_prime.c:461: warning: Function parameter or member 'page_num' not described in 'drm_gem_dmabuf_kmap'
drivers/gpu/drm/drm_prime.c:473: warning: Function parameter or member 'dma_buf' not described in 'drm_gem_dmabuf_kunmap'
drivers/gpu/drm/drm_prime.c:473: warning: Function parameter or member 'page_num' not described in 'drm_gem_dmabuf_kunmap'
drivers/gpu/drm/drm_prime.c:473: warning: Function parameter or member 'addr' not described in 'drm_gem_dmabuf_kunmap'
include/media/v4l2-dev.h:42: warning: Enum value 'VFL_TYPE_MAX' not described in enum 'vfl_devnode_type'
include/linux/skbuff.h:850: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'skb_mstamp' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'head_frag' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member '__unused' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'pfmemalloc' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'encapsulation' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'encap_hdr_csum' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'csum_valid' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'csum_complete_sw' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'csum_level' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'inner_protocol_type' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'remcsum_offload' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'offload_fwd_mark' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'offload_mr_fwd_mark' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'sender_cpu' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'reserved_tailroom' not described in 'sk_buff'
include/linux/skbuff.h:850: warning: Function parameter or member 'inner_ipproto' not described in 'sk_buff'
include/net/sock.h:234: warning: Function parameter or member 'skc_addrpair' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_portpair' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_ipv6only' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_net_refcnt' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_v6_daddr' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_v6_rcv_saddr' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_cookie' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_listener' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_tw_dr' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_rcv_wnd' not described in 'sock_common'
include/net/sock.h:234: warning: Function parameter or member 'skc_tw_rcv_nxt' not described in 'sock_common'
include/net/sock.h:488: warning: Function parameter or member 'sk_backlog.rmem_alloc' not described in 'sock'
include/net/sock.h:488: warning: Function parameter or member 'sk_backlog.len' not described in 'sock'
include/net/sock.h:488: warning: Function parameter or member 'sk_backlog.head' not described in 'sock'
include/net/sock.h:488: warning: Function parameter or member 'sk_backlog.tail' not described in 'sock'
include/net/sock.h:488: warning: Function parameter or member 'sk_wq_raw' not described in 'sock'
include/net/sock.h:488: warning: Function parameter or member 'tcp_rtx_queue' not described in 'sock'
include/net/sock.h:488: warning: Function parameter or member 'sk_route_forced_caps' not described in 'sock'
include/linux/netdevice.h:1955: warning: Function parameter or member 'adj_list.upper' not described in 'net_device'
include/linux/netdevice.h:1955: warning: Function parameter or member 'adj_list.lower' not described in 'net_device'
include/linux/netdevice.h:1955: warning: Function parameter or member 'gso_partial_features' not described in 'net_device'
include/linux/netdevice.h:1955: warning: Function parameter or member 'switchdev_ops' not described in 'net_device'
include/linux/netdevice.h:1955: warning: Function parameter or member 'l3mdev_ops' not described in 'net_device'
include/linux/netdevice.h:1955: warning: Function parameter or member 'xfrmdev_ops' not described in 'net_device'
include/linux/netdevice.h:1955: warning: Function parameter or member 'name_assign_type' not described in 'net_device'
include/linux/netdevice.h:1955: warning: Function parameter or member 'ieee802154_ptr' not described in 'net_device'
vim +330 include/linux/counter.h
624995ae William Breathitt Gray 2018-05-16 @330
:::::: The code at line 330 was first introduced by commit
:::::: 624995aed3646d19eb4ce4cd7f527fe95a165a92 counter: Introduce the Generic Counter interface
:::::: TO: William Breathitt Gray <vilhelm.gray@gmail.com>
:::::: CC: 0day robot <lkp@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6365 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180519/0eca97a3/attachment-0001.gz>
^ permalink raw reply
* [rjarzmik:work/dma_slave_map 12/14] drivers/mtd/nand/marvell_nand.c:2621:42: error: 'pxad_filter_fn' undeclared; did you mean 'dma_filter_fn'?
From: kbuild test robot @ 2018-05-19 15:40 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/rjarzmik/linux work/dma_slave_map
head: bf8c92cc3a3bd33edd9249f60c2ef96e7f9cd4f5
commit: 308214fe387eaf6b5547d01e573c41bb309a59fb [12/14] dmaengine: pxa: make the filter function internal
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 308214fe387eaf6b5547d01e573c41bb309a59fb
# save the attached .config to linux build tree
make.cross ARCH=sh
All errors (new ones prefixed by >>):
In file included from drivers/mtd/nand/marvell_nand.c:21:0:
drivers/mtd/nand/marvell_nand.c: In function 'marvell_nfc_init_dma':
>> drivers/mtd/nand/marvell_nand.c:2621:42: error: 'pxad_filter_fn' undeclared (first use in this function); did you mean 'dma_filter_fn'?
dma_request_slave_channel_compat(mask, pxad_filter_fn,
^
include/linux/dmaengine.h:1408:46: note: in definition of macro 'dma_request_slave_channel_compat'
__dma_request_slave_channel_compat(&(mask), x, y, dev, name)
^
drivers/mtd/nand/marvell_nand.c:2621:42: note: each undeclared identifier is reported only once for each function it appears in
dma_request_slave_channel_compat(mask, pxad_filter_fn,
^
include/linux/dmaengine.h:1408:46: note: in definition of macro 'dma_request_slave_channel_compat'
__dma_request_slave_channel_compat(&(mask), x, y, dev, name)
^
vim +2621 drivers/mtd/nand/marvell_nand.c
02f26ecf Miquel Raynal 2018-01-09 2588
02f26ecf Miquel Raynal 2018-01-09 2589 static int marvell_nfc_init_dma(struct marvell_nfc *nfc)
02f26ecf Miquel Raynal 2018-01-09 2590 {
02f26ecf Miquel Raynal 2018-01-09 2591 struct platform_device *pdev = container_of(nfc->dev,
02f26ecf Miquel Raynal 2018-01-09 2592 struct platform_device,
02f26ecf Miquel Raynal 2018-01-09 2593 dev);
02f26ecf Miquel Raynal 2018-01-09 2594 struct dma_slave_config config = {};
02f26ecf Miquel Raynal 2018-01-09 2595 struct resource *r;
02f26ecf Miquel Raynal 2018-01-09 2596 dma_cap_mask_t mask;
02f26ecf Miquel Raynal 2018-01-09 2597 struct pxad_param param;
02f26ecf Miquel Raynal 2018-01-09 2598 int ret;
02f26ecf Miquel Raynal 2018-01-09 2599
02f26ecf Miquel Raynal 2018-01-09 2600 if (!IS_ENABLED(CONFIG_PXA_DMA)) {
02f26ecf Miquel Raynal 2018-01-09 2601 dev_warn(nfc->dev,
02f26ecf Miquel Raynal 2018-01-09 2602 "DMA not enabled in configuration\n");
02f26ecf Miquel Raynal 2018-01-09 2603 return -ENOTSUPP;
02f26ecf Miquel Raynal 2018-01-09 2604 }
02f26ecf Miquel Raynal 2018-01-09 2605
02f26ecf Miquel Raynal 2018-01-09 2606 ret = dma_set_mask_and_coherent(nfc->dev, DMA_BIT_MASK(32));
02f26ecf Miquel Raynal 2018-01-09 2607 if (ret)
02f26ecf Miquel Raynal 2018-01-09 2608 return ret;
02f26ecf Miquel Raynal 2018-01-09 2609
02f26ecf Miquel Raynal 2018-01-09 2610 r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
02f26ecf Miquel Raynal 2018-01-09 2611 if (!r) {
02f26ecf Miquel Raynal 2018-01-09 2612 dev_err(nfc->dev, "No resource defined for data DMA\n");
02f26ecf Miquel Raynal 2018-01-09 2613 return -ENXIO;
02f26ecf Miquel Raynal 2018-01-09 2614 }
02f26ecf Miquel Raynal 2018-01-09 2615
02f26ecf Miquel Raynal 2018-01-09 2616 param.drcmr = r->start;
02f26ecf Miquel Raynal 2018-01-09 2617 param.prio = PXAD_PRIO_LOWEST;
02f26ecf Miquel Raynal 2018-01-09 2618 dma_cap_zero(mask);
02f26ecf Miquel Raynal 2018-01-09 2619 dma_cap_set(DMA_SLAVE, mask);
02f26ecf Miquel Raynal 2018-01-09 2620 nfc->dma_chan =
02f26ecf Miquel Raynal 2018-01-09 @2621 dma_request_slave_channel_compat(mask, pxad_filter_fn,
02f26ecf Miquel Raynal 2018-01-09 2622 ¶m, nfc->dev,
02f26ecf Miquel Raynal 2018-01-09 2623 "data");
02f26ecf Miquel Raynal 2018-01-09 2624 if (!nfc->dma_chan) {
02f26ecf Miquel Raynal 2018-01-09 2625 dev_err(nfc->dev,
02f26ecf Miquel Raynal 2018-01-09 2626 "Unable to request data DMA channel\n");
02f26ecf Miquel Raynal 2018-01-09 2627 return -ENODEV;
02f26ecf Miquel Raynal 2018-01-09 2628 }
02f26ecf Miquel Raynal 2018-01-09 2629
02f26ecf Miquel Raynal 2018-01-09 2630 r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
02f26ecf Miquel Raynal 2018-01-09 2631 if (!r)
02f26ecf Miquel Raynal 2018-01-09 2632 return -ENXIO;
02f26ecf Miquel Raynal 2018-01-09 2633
02f26ecf Miquel Raynal 2018-01-09 2634 config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
02f26ecf Miquel Raynal 2018-01-09 2635 config.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
02f26ecf Miquel Raynal 2018-01-09 2636 config.src_addr = r->start + NDDB;
02f26ecf Miquel Raynal 2018-01-09 2637 config.dst_addr = r->start + NDDB;
02f26ecf Miquel Raynal 2018-01-09 2638 config.src_maxburst = 32;
02f26ecf Miquel Raynal 2018-01-09 2639 config.dst_maxburst = 32;
02f26ecf Miquel Raynal 2018-01-09 2640 ret = dmaengine_slave_config(nfc->dma_chan, &config);
02f26ecf Miquel Raynal 2018-01-09 2641 if (ret < 0) {
02f26ecf Miquel Raynal 2018-01-09 2642 dev_err(nfc->dev, "Failed to configure DMA channel\n");
02f26ecf Miquel Raynal 2018-01-09 2643 return ret;
02f26ecf Miquel Raynal 2018-01-09 2644 }
02f26ecf Miquel Raynal 2018-01-09 2645
02f26ecf Miquel Raynal 2018-01-09 2646 /*
02f26ecf Miquel Raynal 2018-01-09 2647 * DMA must act on length multiple of 32 and this length may be
02f26ecf Miquel Raynal 2018-01-09 2648 * bigger than the destination buffer. Use this buffer instead
02f26ecf Miquel Raynal 2018-01-09 2649 * for DMA transfers and then copy the desired amount of data to
02f26ecf Miquel Raynal 2018-01-09 2650 * the provided buffer.
02f26ecf Miquel Raynal 2018-01-09 2651 */
c495a927 Miquel Raynal 2018-01-19 2652 nfc->dma_buf = kmalloc(MAX_CHUNK_SIZE, GFP_KERNEL | GFP_DMA);
02f26ecf Miquel Raynal 2018-01-09 2653 if (!nfc->dma_buf)
02f26ecf Miquel Raynal 2018-01-09 2654 return -ENOMEM;
02f26ecf Miquel Raynal 2018-01-09 2655
02f26ecf Miquel Raynal 2018-01-09 2656 nfc->use_dma = true;
02f26ecf Miquel Raynal 2018-01-09 2657
02f26ecf Miquel Raynal 2018-01-09 2658 return 0;
02f26ecf Miquel Raynal 2018-01-09 2659 }
02f26ecf Miquel Raynal 2018-01-09 2660
:::::: The code at line 2621 was first introduced by commit
:::::: 02f26ecf8c772751d4b24744d487f6b1b20e75d4 mtd: nand: add reworked Marvell NAND controller driver
:::::: TO: Miquel Raynal <miquel.raynal@free-electrons.com>
:::::: CC: Boris Brezillon <boris.brezillon@free-electrons.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 48061 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180519/d18742f6/attachment-0001.gz>
^ permalink raw reply
* [arm-platforms:kvm-arm/pmuv3-32bit 2/5] include/linux/perf/arm_pmuv3.h:21:10: fatal error: asm/arm_pmuv3.h: No such file or directory
From: kbuild test robot @ 2018-05-19 15:42 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm/pmuv3-32bit
head: 582eb41425e31201afb545db00bb25b39d6e3091
commit: b5297bf07d662cccffbb922e0d0488df25245b0a [2/5] arm64: perf: Abstract system register accesses away
config: arm-axm55xx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b5297bf07d662cccffbb922e0d0488df25245b0a
# save the attached .config to linux build tree
make.cross ARCH=arm
Note: the arm-platforms/kvm-arm/pmuv3-32bit HEAD 582eb41425e31201afb545db00bb25b39d6e3091 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from include/kvm/arm_pmu.h:22:0,
from arch/arm/kvm/../../../virt/kvm/arm/arm.c:33:
>> include/linux/perf/arm_pmuv3.h:21:10: fatal error: asm/arm_pmuv3.h: No such file or directory
#include <asm/arm_pmuv3.h>
^~~~~~~~~~~~~~~~~
compilation terminated.
vim +21 include/linux/perf/arm_pmuv3.h
20
> 21 #include <asm/arm_pmuv3.h>
22
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 19846 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180519/3445cbe2/attachment-0001.gz>
^ permalink raw reply
* [GIT PULL] pinctrl: samsung: Stuff for v4.18
From: Krzysztof Kozlowski @ 2018-05-19 15:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Few patches for next cycle.
Best regards,
Krzysztof
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git tags/samsung-pinctrl-4.18
for you to fetch changes up to 0ca0557e3727951bdc44ea47bc6135b37f90338c:
pinctrl: samsung: Remove support for Exynos5440 (2018-05-02 19:08:55 +0200)
----------------------------------------------------------------
Samsung pinctrl drivers changes for v4.18
1. Driver expects specific order of GPIO interrupt banks. For S5Pv220
and Exynos5410 this order was not preserved so fix and document it.
2. Remove support for Exynos5440 (tree-wide, support is dropped because
there are no real users of this platform, it also did not get testing
since long time).
----------------------------------------------------------------
Krzysztof Kozlowski (1):
pinctrl: samsung: Remove support for Exynos5440
Pawe? Chmiel (2):
pinctrl: samsung: Correct EINTG banks order
pinctrl: samsung: Document required order of banks
drivers/pinctrl/samsung/Kconfig | 10 +-
drivers/pinctrl/samsung/Makefile | 1 -
drivers/pinctrl/samsung/pinctrl-exynos-arm.c | 30 +-
drivers/pinctrl/samsung/pinctrl-exynos-arm64.c | 20 +
drivers/pinctrl/samsung/pinctrl-exynos5440.c | 1005 ------------------------
5 files changed, 50 insertions(+), 1016 deletions(-)
delete mode 100644 drivers/pinctrl/samsung/pinctrl-exynos5440.c
^ permalink raw reply
* [PATCH v3 01/26] drm/bridge: allow optionally specifying an owner .odev device
From: Heiko Stuebner @ 2018-05-19 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-2-peda@axentia.se>
Hi Peter,
Am Mittwoch, 16. Mai 2018, 12:14:45 CEST schrieb Peter Rosin:
> Bridge drivers can now (temporarily, in a transition phase) select if
> they want to provide a full owner device or keep just providing an
> of_node.
>
> By providing a full owner device, the bridge drivers no longer need
> to provide an of_node since that node is available via the owner
> device.
>
> When all bridge drivers provide an owner device, that will become
> mandatory and the .of_node member will be removed.
>
> There is an interaction with the rockchip lvds driver, since that
> driver peeks into somewhat private parts of the bridge struct in
> order to find out things about the remote bridge. When there are
> now two ways to get to the remote bridge, the rockchip lvds driver
> has to adapt. That said, the correct thing to do for the rockchip
> lvds driver is to use some other way than DT to find things out
> about the remote bridge, but that is orthogonal to this patch.
>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 4bd94b167d2c..557e0079c98d 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
> }
> if (lvds->panel)
> remote = lvds->panel->dev->of_node;
> - else
> + else if (lvds->bridge->of_node)
> remote = lvds->bridge->of_node;
> + else
> + remote = lvds->bridge->odev->of_node;
> if (of_property_read_string(dev->of_node, "rockchip,output", &name))
> /* default set it as output rgb */
> lvds->output = DISPLAY_OUTPUT_RGB;
for the Rockchip-part
Acked-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH v3 24/26] drm/bridge: remove the .of_node member
From: Heiko Stuebner @ 2018-05-19 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-25-peda@axentia.se>
Am Mittwoch, 16. Mai 2018, 12:15:08 CEST schrieb Peter Rosin:
> It is unused.
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 557e0079c98d..e77d4c909582 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
> }
> if (lvds->panel)
> remote = lvds->panel->dev->of_node;
> - else if (lvds->bridge->of_node)
> - remote = lvds->bridge->of_node;
> else
> remote = lvds->bridge->odev->of_node;
> if (of_property_read_string(dev->of_node, "rockchip,output", &name))
for the Rockchip-part
Acked-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH] PCI: Do not enable PASID when End-to-End TLP is not supported
From: Sinan Kaya @ 2018-05-19 16:52 UTC (permalink / raw)
To: linux-arm-kernel
A PCIe endpoint carries the process address space identifier (PASID) in
the TLP prefix as part of the memory read/write transaction. The address
information in the TLP is relevant only for a given PASID context.
A translation agent takes PASID value and the address information from the
TLP to look up the physical address in the system.
If a bridge drops the TLP prefix, the translation agent can resolve the
address to an incorrect location and cause data corruption. Prevent
this condition by requiring End-to-End TLP prefix to be supported on the
entire data path between the endpoint and the root port.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/ats.c | 16 ++++++++++++++++
include/uapi/linux/pci_regs.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 89305b5..0bcded5 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -265,7 +265,9 @@ EXPORT_SYMBOL_GPL(pci_reset_pri);
int pci_enable_pasid(struct pci_dev *pdev, int features)
{
u16 control, supported;
+ struct pci_dev *bridge;
int pos;
+ u32 cap;
if (WARN_ON(pdev->pasid_enabled))
return -EBUSY;
@@ -274,6 +276,20 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
if (!pos)
return -EINVAL;
+ bridge = pci_upstream_bridge(pdev);
+ while (bridge) {
+ if (!pci_find_capability(bridge, PCI_CAP_ID_EXP))
+ return -EINVAL;
+
+ if (pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &cap))
+ return -EINVAL;
+
+ if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
+ return -EINVAL;
+
+ bridge = pci_upstream_bridge(bridge);
+ }
+
pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
supported &= PCI_PASID_CAP_EXEC | PCI_PASID_CAP_PRIV;
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 103ba79..d91dea5 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -634,6 +634,7 @@
#define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c0000 /* OBFF support mechanism */
#define PCI_EXP_DEVCAP2_OBFF_MSG 0x00040000 /* New message signaling */
#define PCI_EXP_DEVCAP2_OBFF_WAKE 0x00080000 /* Re-use WAKE# for OBFF */
+#define PCI_EXP_DEVCAP2_E2ETLP 0x00200000 /* End-to-End TLP Prefix */
#define PCI_EXP_DEVCTL2 40 /* Device Control 2 */
#define PCI_EXP_DEVCTL2_COMP_TIMEOUT 0x000f /* Completion Timeout Value */
#define PCI_EXP_DEVCTL2_COMP_TMOUT_DIS 0x0010 /* Completion Timeout Disable */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 35/40] iommu/arm-smmu-v3: Add support for PCI ATS
From: Sinan Kaya @ 2018-05-19 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-36-jean-philippe.brucker@arm.com>
On 5/11/2018 3:06 PM, Jean-Philippe Brucker wrote:
> PCIe devices can implement their own TLB, named Address Translation Cache
> (ATC). Enable Address Translation Service (ATS) for devices that support
> it and send them invalidation requests whenever we invalidate the IOTLBs.
>
> Range calculation
> -----------------
>
> The invalidation packet itself is a bit awkward: range must be naturally
> aligned, which means that the start address is a multiple of the range
> size. In addition, the size must be a power of two number of 4k pages. We
> have a few options to enforce this constraint:
>
> (1) Find the smallest naturally aligned region that covers the requested
> range. This is simple to compute and only takes one ATC_INV, but it
> will spill on lots of neighbouring ATC entries.
>
> (2) Align the start address to the region size (rounded up to a power of
> two), and send a second invalidation for the next range of the same
> size. Still not great, but reduces spilling.
>
> (3) Cover the range exactly with the smallest number of naturally aligned
> regions. This would be interesting to implement but as for (2),
> requires multiple ATC_INV.
>
> As I suspect ATC invalidation packets will be a very scarce resource, I'll
> go with option (1) for now, and only send one big invalidation. We can
> move to (2), which is both easier to read and more gentle with the ATC,
> once we've observed on real systems that we can send multiple smaller
> Invalidation Requests for roughly the same price as a single big one.
>
> Note that with io-pgtable, the unmap function is called for each page, so
> this doesn't matter. The problem shows up when sharing page tables with
> the MMU.
>
> Timeout
> -------
>
> ATC invalidation is allowed to take up to 90 seconds, according to the
> PCIe spec, so it is possible to hit the SMMU command queue timeout during
> normal operations.
>
> Some SMMU implementations will raise a CERROR_ATC_INV_SYNC when a CMD_SYNC
> fails because of an ATC invalidation. Some will just abort the CMD_SYNC.
> Others might let CMD_SYNC complete and have an asynchronous IMPDEF
> mechanism to record the error. When we receive a CERROR_ATC_INV_SYNC, we
> could retry sending all ATC_INV since last successful CMD_SYNC. When a
> CMD_SYNC fails without CERROR_ATC_INV_SYNC, we could retry sending *all*
> commands since last successful CMD_SYNC.
>
> We cannot afford to wait 90 seconds in iommu_unmap, let alone MMU
> notifiers. So we'd have to introduce a more clever system if this timeout
> becomes a problem, like keeping hold of mappings and invalidating in the
> background. Implementing safe delayed invalidations is a very complex
> problem and deserves a series of its own. We'll assess whether more work
> is needed to properly handle ATC invalidation timeouts once this code runs
> on real hardware.
>
> Misc
> ----
>
> I didn't put ATC and TLB invalidations in the same functions for three
> reasons:
>
> * TLB invalidation by range is batched and committed with a single sync.
> Batching ATC invalidation is inconvenient, endpoints limit the number of
> inflight invalidations. We'd have to count the number of invalidations
> queued and send a sync periodically. In addition, I suspect we always
> need a sync between TLB and ATC invalidation for the same page.
>
> * Doing ATC invalidation outside tlb_inv_range also allows to send less
> requests, since TLB invalidations are done per page or block, while ATC
> invalidations target IOVA ranges.
>
> * TLB invalidation by context is performed when freeing the domain, at
> which point there isn't any device attached anymore.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Nothing specific about this patch but just a general observation. Last time I
looked at the code, it seemed to require both ATS and PRI support from a given
hardware.
I think you can assume that for ATS 1.1 specification but ATS 1.0 specification
allows a system to have ATS+PASID without PRI.
QDF2400 is ATS 1.0 compatible as an example.
Is this an assumption / my misinterpretation?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add SMP support
From: Sergei Shtylyov @ 2018-05-19 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU9JXvN2GLFGLZGeNOpZ9AdJYokbpTqt-Wy97-Z0tXaCA@mail.gmail.com>
On 05/17/2018 11:23 PM, Geert Uytterhoeven wrote:
>> Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the interrupt
>> delivery masks for the ARM GIC and Architectured Timer.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Thanks for your patch!
>
>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> @@ -30,6 +30,36 @@
>> enable-method = "psci";
>> };
>>
>> + a53_1: cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53","arm,armv8";
>
> Please stop copying spaceless lists ;-)
Oops! Simon, do I need to re-post?
> Gr{oetje,eeting}s,
>
> Geert
MBR, Sergei
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 74/935] drivers/fpga/zynqmp-fpga.c:79:2: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'clflush_cache_range'?
From: kbuild test robot @ 2018-05-19 17:56 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 6b8ad2b85bb2279d13a436396238f0fd150138d1
commit: d91b9e49c2c2663091e2d71a136ad2db919a91b3 [74/935] fpga manager: Adding FPGA Manager support for Xilinx zynqmp
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout d91b9e49c2c2663091e2d71a136ad2db919a91b3
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/fpga/zynqmp-fpga.c: In function 'zynqmp_fpga_ops_write':
>> drivers/fpga/zynqmp-fpga.c:79:2: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'clflush_cache_range'? [-Werror=implicit-function-declaration]
__flush_cache_user_range((unsigned long)kbuf,
^~~~~~~~~~~~~~~~~~~~~~~~
clflush_cache_range
cc1: some warnings being treated as errors
vim +79 drivers/fpga/zynqmp-fpga.c
45
46 static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
47 const char *buf, size_t size)
48 {
49 struct zynqmp_fpga_priv *priv;
50 char *kbuf;
51 size_t dma_size;
52 dma_addr_t dma_addr;
53 u32 transfer_length;
54 int ret;
55 const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
56
57 if (!eemi_ops || !eemi_ops->fpga_load)
58 return -ENXIO;
59
60 priv = mgr->priv;
61
62 if (mgr->flags & IXR_FPGA_ENCRYPTION_EN)
63 dma_size = size + ENCRYPTED_KEY_LEN + ENCRYPTED_IV_LEN;
64 else
65 dma_size = size;
66
67 kbuf = dma_alloc_coherent(priv->dev, dma_size, &dma_addr, GFP_KERNEL);
68 if (!kbuf)
69 return -ENOMEM;
70
71 memcpy(kbuf, buf, size);
72
73 if (mgr->flags & IXR_FPGA_ENCRYPTION_EN) {
74 memcpy(kbuf + size, mgr->key, ENCRYPTED_KEY_LEN);
75 memcpy(kbuf + size + ENCRYPTED_KEY_LEN, mgr->iv,
76 ENCRYPTED_IV_LEN);
77 }
78
> 79 __flush_cache_user_range((unsigned long)kbuf,
80 (unsigned long)kbuf + dma_size);
81
82 /**
83 * Translate size from bytes to number of 32bit words that
84 * the DMA should write to the PCAP interface
85 */
86 if (size & 3)
87 transfer_length = (size >> 2) + 1;
88 else
89 transfer_length = size >> 2;
90
91 ret = eemi_ops->fpga_load(dma_addr, transfer_length, mgr->flags);
92
93 dma_free_coherent(priv->dev, dma_size, kbuf, dma_addr);
94
95 return ret;
96 }
97
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 61100 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180520/f6735637/attachment-0001.gz>
^ permalink raw reply
* [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table
From: Andy Shevchenko @ 2018-05-19 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3427199.r4OBoDP6Xz@z50>
On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote:
>> On Sat, May 19, 2018 at 12:09 AM, Janusz Krzysztofik
>>
>> <jmkrzyszt@gmail.com> wrote:
>> > + gpiod_rdy = devm_gpiod_get_optional(&pdev->dev, "rdy", GPIOD_IN);
>> > + if (!IS_ERR_OR_NULL(gpiod_rdy)) {
>>
>> So, is it optional or not at the end?
>> If it is, why do we check for NULL?
>
> As far as I can understand, nand_chip->dev_ready() callback is optional.
> That's why I decided to use the _optional variant of devm_gpiod_get(). In case
> of ams-delta, the dev_ready() callback depends on availability of the 'rdy'
> GPIO pin. As a consequence, I'm checking for both NULL and ERR in order to
> decide if dev_ready() will be supported.
>
> I can pretty well replace it with the standard form and check for ERR only if
> the purpose of the _optional form is different.
NULL check in practice discards the _optional part of gpiod_get(). So,
either you use non-optional variant and decide how to handle an
errors, or user _optional w/o NULL check.
>> > +err_gpiod:
>> > + if (err == -ENODEV || err == -ENOENT)
>> > + err = -EPROBE_DEFER;
>>
>> Hmm...
>
> Amstrad Delta uses gpio-mmio driver. Unfortunatelty that driver is not
> availble before device init phase, unlike other crucial GPIO drivers which are
> initialized earlier, e.g. during the postcore or at latetst the subsys phase.
> Hence, devices which depend on GPIO pins provided by gpio-mmio must either be
> declared late or fail softly so they get another chance of being probed
> succesfully.
>
> I thought of replacing the gpio-mmio platform driver with bgpio functions it
> exports but for now I haven't implemented it, not even shared the idea.
>
> Does it really hurt to return -EPROBE_DEFER if a GPIO pin can't be obtained?
I'm only concerned if it would be an infinite defer in the case when
driver will never appear.
But I don't remember the details.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 00/15] Add support for R40 HDMI pipeline
From: Jernej Skrabec @ 2018-05-19 18:31 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for R40 HDMI pipeline. It is a bit special
than other already supported pipelines because it has additional unit
called TCON TOP responsible for relationship configuration between
mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
and TV TCONs, TV encoder clock settings and pin muxing between LCD
and TV encoders.
However, it seems that TCON TOP will become a norm, since newer
Allwinner SoCs like H6 also have this unit.
I tested different possible configurations:
- mixer0 <> TCON-TV0 <> HDMI
- mixer0 <> TCON-TV1 <> HDMI
- mixer1 <> TCON-TV0 <> HDMI
- mixer1 <> TCON-TV1 <> HDMI
Please review.
Best regards,
Jernej
Jernej Skrabec (15):
clk: sunxi-ng: r40: Add minimal rate for video PLLs
clk: sunxi-ng: r40: Allow setting parent rate to display related
clocks
clk: sunxi-ng: r40: Export video PLLs
dt-bindings: display: sunxi-drm: Add TCON TOP description
drm/sun4i: Add TCON TOP driver
drm/sun4i: tcon: Add support for tcon-top
dt-bindings: display: sun4i-drm: Add R40 HDMI pipeline
drm/sun4i: DE2 mixer: Add index quirk
drm/sun4i: Add support for R40 mixers
drm/sun4i: Add support for R40 TV TCONs
drm/sun4i: DW HDMI PHY: Add support for second PLL
drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
driver
drm/sun4i: Add support for A64 HDMI PHY
ARM: dts: sun8i: r40: Add HDMI pipeline
ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
.../bindings/display/sunxi/sun4i-drm.txt | 36 ++-
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 50 ++++
arch/arm/boot/dts/sun8i-r40.dtsi | 166 ++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 58 ++--
drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 +-
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 67 +++++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 8 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 8 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 61 ++++-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 ++++--
drivers/gpu/drm/sun4i/sun8i_mixer.c | 30 +-
drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 +
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 256 ++++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 20 ++
include/dt-bindings/clock/sun8i-r40-ccu.h | 4 +
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +
17 files changed, 813 insertions(+), 65 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
--
2.17.0
^ permalink raw reply
* [PATCH 01/15] clk: sunxi-ng: r40: Add minimal rate for video PLLs
From: Jernej Skrabec @ 2018-05-19 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-1-jernej.skrabec@siol.net>
According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.
Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 46 +++++++++++++++-------------
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c16a62a7bdbd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -65,17 +65,18 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
- "osc24M", 0x0010,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video0_clk, "pll-video0",
+ "osc24M", 0x0010,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
@@ -151,17 +152,18 @@ static struct ccu_nk pll_periph1_clk = {
};
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
- "osc24M", 0x030,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video1_clk, "pll-video1",
+ "osc24M", 0x030,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
static struct ccu_nkm pll_sata_clk = {
.enable = BIT(31),
--
2.17.0
^ permalink raw reply related
* [PATCH 02/15] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
From: Jernej Skrabec @ 2018-05-19 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-1-jernej.skrabec@siol.net>
Display related peripherals need precise clocks to operate correctly.
Allow DE2, TCONs and HDMI to set parent clock.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c16a62a7bdbd..fa5317719684 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -655,7 +655,8 @@ static SUNXI_CCU_GATE(dram_deinterlace_clk, "dram-deinterlace", "dram",
static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
- 0x104, 0, 4, 24, 3, BIT(31), 0);
+ 0x104, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mp_clk, "mp", de_parents,
0x108, 0, 4, 24, 3, BIT(31), 0);
@@ -667,9 +668,11 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd0_clk, "tcon-lcd0", tcon_parents,
static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd1_clk, "tcon-lcd1", tcon_parents,
0x114, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv0_clk, "tcon-tv0", tcon_parents,
- 0x118, 0, 4, 24, 3, BIT(31), 0);
+ 0x118, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv1_clk, "tcon-tv1", tcon_parents,
- 0x11c, 0, 4, 24, 3, BIT(31), 0);
+ 0x11c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static const char * const deinterlace_parents[] = { "pll-periph0",
"pll-periph1" };
@@ -699,7 +702,8 @@ static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
static const char * const hdmi_parents[] = { "pll-video0", "pll-video1" };
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
- 0x150, 0, 4, 24, 2, BIT(31), 0);
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_slow_clk, "hdmi-slow", "osc24M",
0x154, BIT(31), 0);
--
2.17.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox