* [PATCH net-next] bcm63xx_enet: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-01 12:39 UTC (permalink / raw)
To: davem, f.fainelli, bcm-kernel-feedback-list, andrew,
linux-arm-kernel
Cc: netdev, YueHaibing, linux-kernel
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 291e4af..620cd3f 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1693,7 +1693,7 @@ static int bcm_enet_probe(struct platform_device *pdev)
struct bcm_enet_priv *priv;
struct net_device *dev;
struct bcm63xx_enet_platform_data *pd;
- struct resource *res_mem, *res_irq, *res_irq_rx, *res_irq_tx;
+ struct resource *res_irq, *res_irq_rx, *res_irq_tx;
struct mii_bus *bus;
int i, ret;
@@ -1719,8 +1719,7 @@ static int bcm_enet_probe(struct platform_device *pdev)
if (ret)
goto out;
- res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->base = devm_ioremap_resource(&pdev->dev, res_mem);
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->base)) {
ret = PTR_ERR(priv->base);
goto out;
@@ -2762,15 +2761,13 @@ struct platform_driver bcm63xx_enetsw_driver = {
/* reserve & remap memory space shared between all macs */
static int bcm_enet_shared_probe(struct platform_device *pdev)
{
- struct resource *res;
void __iomem *p[3];
unsigned int i;
memset(bcm_enet_shared_base, 0, sizeof(bcm_enet_shared_base));
for (i = 0; i < 3; i++) {
- res = platform_get_resource(pdev, IORESOURCE_MEM, i);
- p[i] = devm_ioremap_resource(&pdev->dev, res);
+ p[i] = devm_platform_ioremap_resource(pdev, i);
if (IS_ERR(p[i]))
return PTR_ERR(p[i]);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/4] crypto: amlogic: Add crypto accelerator for amlogic GXL
From: LABBE Corentin @ 2019-08-01 12:46 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: mark.rutland, devicetree, herbert, baylibre-upstreaming, khilman,
linux-kernel, robh+dt, linux-crypto, linux-amlogic, davem,
linux-arm-kernel
In-Reply-To: <CAFBinCD7pgUaBJgeGHTOu-uZRA9a6K2kxPsu+huKe23wcnKPoA@mail.gmail.com>
On Sat, Jul 27, 2019 at 02:17:38PM +0200, Martin Blumenstingl wrote:
> Hi Corentin,
>
> it's great to see you working on this :)
>
> On Thu, Jul 25, 2019 at 9:45 PM Corentin Labbe <clabbe@baylibre.com> wrote:
> >
> > This patch adds support for the amlogic GXL cryptographic offloader present
> > on GXL SoCs.
> >
> > This driver supports AES cipher in CBC/ECB mode.
> >
> > Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> > ---
> > drivers/crypto/Kconfig | 2 +
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/amlogic/Kconfig | 24 ++
> > drivers/crypto/amlogic/Makefile | 2 +
> > drivers/crypto/amlogic/amlogic-cipher.c | 358 ++++++++++++++++++++++++
> > drivers/crypto/amlogic/amlogic-core.c | 326 +++++++++++++++++++++
> > drivers/crypto/amlogic/amlogic.h | 172 ++++++++++++
> > 7 files changed, 885 insertions(+)
> > create mode 100644 drivers/crypto/amlogic/Kconfig
> > create mode 100644 drivers/crypto/amlogic/Makefile
> > create mode 100644 drivers/crypto/amlogic/amlogic-cipher.c
> > create mode 100644 drivers/crypto/amlogic/amlogic-core.c
> > create mode 100644 drivers/crypto/amlogic/amlogic.h
> there are two different crypto IPs on Amlogic SoCs:
> - GXL and newer use the "BLKMV" crypto IP
> - GXBB, Meson8/Meson8b/Meson8m2 (and probably older SoCs) use the
> "NDMA" crypto IP
>
I believed it was the opposite. (BLKMV the older, NDMA the newer)
Anyway, on the datasheet I found (s905d), neither NDMA or BLKMV is mentioned, it is just called Crypto Engine.
So I think GXL is the best choice.
> personally I think it makes sense to either have the IP name (blkmv)
> or SoC name (GXL) in the file or directory names as well as being
> consistent with that in the Kconfig option names
Ok I will rename files to amlogic-gxl-xxx
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 0/3] Make IPA use PM_EM
From: Quentin Perret @ 2019-08-01 12:46 UTC (permalink / raw)
To: edubezval, rui.zhang, javi.merino, viresh.kumar, amit.kachhap,
rjw, catalin.marinas, will, daniel.lezcano
Cc: linux-pm, linux-kernel, quentin.perret, mka, ionela.voinescu,
dietmar.eggemann, linux-arm-kernel
Changes in v6
*************
- Added Daniel's and Viresh's Acked-by to all patches
Changes in v5:
**************
- Changed patch 02 to guard IPA-specific code in cpu_cooling.c with
appropriate ifdefery (Daniel)
- Rebased on 5.2-rc2
Changes in v4:
**************
- Added Viresh's Acked-by to all 3 patches
- Improved commit message of patch 3/3 to explain how it has no
functional impact on existing users (Eduardo)
Changes in v3:
**************
- Changed warning message for unordered tables to something more
explicit (Viresh)
- Changed WARN() into a pr_err() for consistency
Changes in v2:
**************
- Fixed patch 01/03 to actually enable CONFIG_ENERGY_MODEL
- Added "depends on ENERGY_MODEL" to IPA (Daniel)
- Added check to bail out if the freq table is unsorted (Viresh)
Cover letter:
*************
The Intelligent Power Allocator (IPA) thermal governor uses an Energy
Model (or EM) of the CPUs to re-distribute the power budget. To do so,
it builds a table of <frequency, power> tuples where the power values
are computed using the 'dynamic-power-coefficient' DT property. All of
this is done in and only for the thermal subsystem, and more
specifically for CPUs -- the power of other types of devices is obtained
differently.
Recently, the CPU scheduler has seen the introduction of Energy Aware
Scheduling (EAS) patches, which also rely on an EM of the CPUs. This EM,
however, is managed by an independent framework, called PM_EM, aimed to
be used by all kernel subsystems interested in the power consumed by
CPUs, and not only the scheduler.
This patch series follows this logic and removes the (now redundant)
thermal-specific EM computation code to migrate IPA to use PM_EM
instead.
Doing so should have no visible functional impact for existing users of
IPA since:
- during the 5.1 development cycle, a series of patches [1] introduced
in PM_OPP some infrastructure (dev_pm_opp_of_register_em()) enabling
the registration of EMs in PM_EM using the DT property used by IPA;
- the existing upstream cpufreq drivers marked with the
'CPUFREQ_IS_COOLING_DEV' flag all call dev_pm_opp_of_register_em(),
which means they all support PM_EM (the only two exceptions are
qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which
already supports PM_EM without using the PM_OPP infrastructurei
because it read power costs directly from firmware);
So, migrating IPA to using PM_EM should effectively be just plumbing
since for the existing IPA users the PM_EM tables will contain the
exact same power values that IPA used to compute on its own until now.
The only new dependency is to compile in CONFIG_ENERGY_MODEL.
Why is this migration still a good thing ? For three main reasons.
1. it removes redundant code;
2. it introduces an abstraction layer between IPA and the EM
computation. PM_EM offers to EAS and IPA (and potentially other
clients) standardized EM tables and hides 'how' these tables have
been obtained. PM_EM as of now supports power values either coming
from the 'dynamic-power-coefficient' DT property or obtained
directly from firmware using SCMI. The latter is a new feature for
IPA and that comes 'for free' with the migration. This will also be
true in the future every time PM_EM gets support for other ways of
loading the EM. Moreover, PM_EM is documented and has a debugfs
interface which should help adding support for new platforms.
3. it builds a consistent view of the EM of CPUs across kernel
subsystems, which is a pre-requisite for any kind of future work
aiming at a smarter power allocation using scheduler knowledge about
the system for example.
[1] https://lore.kernel.org/lkml/20190204110952.16025-1-quentin.perret@arm.com/
Quentin Perret (3):
arm64: defconfig: Enable CONFIG_ENERGY_MODEL
thermal: cpu_cooling: Make the power-related code depend on IPA
thermal: cpu_cooling: Migrate to using the EM framework
arch/arm64/configs/defconfig | 1 +
drivers/thermal/Kconfig | 1 +
drivers/thermal/cpu_cooling.c | 428 ++++++++++++++--------------------
3 files changed, 178 insertions(+), 252 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/3] arm64: defconfig: Enable CONFIG_ENERGY_MODEL
From: Quentin Perret @ 2019-08-01 12:46 UTC (permalink / raw)
To: edubezval, rui.zhang, javi.merino, viresh.kumar, amit.kachhap,
rjw, catalin.marinas, will, daniel.lezcano
Cc: linux-pm, linux-kernel, quentin.perret, mka, ionela.voinescu,
dietmar.eggemann, linux-arm-kernel
In-Reply-To: <20190801124643.17112-1-quentin.perret@arm.com>
The recently introduced Energy Model (EM) framework manages power cost
tables for the CPUs of the system. Its only user right now is the
scheduler, in the context of Energy Aware Scheduling (EAS).
However, the EM framework also offers a generic infrastructure that
could replace subsystem-specific implementations of the same concepts,
as this is the case in the thermal framework.
So, in order to prepare the migration of the thermal subsystem to use
the EM framework, enable it in the default arm64 defconfig, which is the
most commonly used architecture for IPA. This will also compile-in all
of the EAS code, although it won't be enabled by default -- EAS requires
to use the 'schedutil' CPUFreq governor while arm64 defaults to
'performance'.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..ad0e4944a71f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -71,6 +71,7 @@ CONFIG_COMPAT=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_HIBERNATION=y
CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
+CONFIG_ENERGY_MODEL=y
CONFIG_ARM_CPUIDLE=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT=y
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 2/3] thermal: cpu_cooling: Make the power-related code depend on IPA
From: Quentin Perret @ 2019-08-01 12:46 UTC (permalink / raw)
To: edubezval, rui.zhang, javi.merino, viresh.kumar, amit.kachhap,
rjw, catalin.marinas, will, daniel.lezcano
Cc: linux-pm, linux-kernel, quentin.perret, mka, ionela.voinescu,
dietmar.eggemann, linux-arm-kernel
In-Reply-To: <20190801124643.17112-1-quentin.perret@arm.com>
The core CPU cooling infrastructure has power-related functions
that have only one client: IPA. Since there can be no user of those
functions if IPA is not compiled in, make sure to guard them with
checks on CONFIG_THERMAL_GOV_POWER_ALLOCATOR to not waste space
unnecessarily.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
---
drivers/thermal/cpu_cooling.c | 214 +++++++++++++++++-----------------
1 file changed, 104 insertions(+), 110 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 4c5db59a619b..498f59ab64b2 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -46,7 +46,9 @@
*/
struct freq_table {
u32 frequency;
+#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
u32 power;
+#endif
};
/**
@@ -96,28 +98,6 @@ static DEFINE_IDA(cpufreq_ida);
static DEFINE_MUTEX(cooling_list_lock);
static LIST_HEAD(cpufreq_cdev_list);
-/* Below code defines functions to be used for cpufreq as cooling device */
-
-/**
- * get_level: Find the level for a particular frequency
- * @cpufreq_cdev: cpufreq_cdev for which the property is required
- * @freq: Frequency
- *
- * Return: level corresponding to the frequency.
- */
-static unsigned long get_level(struct cpufreq_cooling_device *cpufreq_cdev,
- unsigned int freq)
-{
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- unsigned long level;
-
- for (level = 1; level <= cpufreq_cdev->max_level; level++)
- if (freq > freq_table[level].frequency)
- break;
-
- return level - 1;
-}
-
/**
* cpufreq_thermal_notifier - notifier callback for cpufreq policy change.
* @nb: struct notifier_block * with callback info.
@@ -171,6 +151,27 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb,
return NOTIFY_OK;
}
+#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
+/**
+ * get_level: Find the level for a particular frequency
+ * @cpufreq_cdev: cpufreq_cdev for which the property is required
+ * @freq: Frequency
+ *
+ * Return: level corresponding to the frequency.
+ */
+static unsigned long get_level(struct cpufreq_cooling_device *cpufreq_cdev,
+ unsigned int freq)
+{
+ struct freq_table *freq_table = cpufreq_cdev->freq_table;
+ unsigned long level;
+
+ for (level = 1; level <= cpufreq_cdev->max_level; level++)
+ if (freq > freq_table[level].frequency)
+ break;
+
+ return level - 1;
+}
+
/**
* update_freq_table() - Update the freq table with power numbers
* @cpufreq_cdev: the cpufreq cooling device in which to update the table
@@ -319,80 +320,6 @@ static u32 get_dynamic_power(struct cpufreq_cooling_device *cpufreq_cdev,
return (raw_cpu_power * cpufreq_cdev->last_load) / 100;
}
-/* cpufreq cooling device callback functions are defined below */
-
-/**
- * cpufreq_get_max_state - callback function to get the max cooling state.
- * @cdev: thermal cooling device pointer.
- * @state: fill this variable with the max cooling state.
- *
- * Callback for the thermal cooling device to return the cpufreq
- * max cooling state.
- *
- * Return: 0 on success, an error code otherwise.
- */
-static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
- unsigned long *state)
-{
- struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
-
- *state = cpufreq_cdev->max_level;
- return 0;
-}
-
-/**
- * cpufreq_get_cur_state - callback function to get the current cooling state.
- * @cdev: thermal cooling device pointer.
- * @state: fill this variable with the current cooling state.
- *
- * Callback for the thermal cooling device to return the cpufreq
- * current cooling state.
- *
- * Return: 0 on success, an error code otherwise.
- */
-static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
- unsigned long *state)
-{
- struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
-
- *state = cpufreq_cdev->cpufreq_state;
-
- return 0;
-}
-
-/**
- * cpufreq_set_cur_state - callback function to set the current cooling state.
- * @cdev: thermal cooling device pointer.
- * @state: set this variable to the current cooling state.
- *
- * Callback for the thermal cooling device to change the cpufreq
- * current cooling state.
- *
- * Return: 0 on success, an error code otherwise.
- */
-static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
- unsigned long state)
-{
- struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
- unsigned int clip_freq;
-
- /* Request state should be less than max_level */
- if (WARN_ON(state > cpufreq_cdev->max_level))
- return -EINVAL;
-
- /* Check if the old cooling action is same as new cooling action */
- if (cpufreq_cdev->cpufreq_state == state)
- return 0;
-
- clip_freq = cpufreq_cdev->freq_table[state].frequency;
- cpufreq_cdev->cpufreq_state = state;
- cpufreq_cdev->clipped_freq = clip_freq;
-
- cpufreq_update_policy(cpufreq_cdev->policy->cpu);
-
- return 0;
-}
-
/**
* cpufreq_get_requested_power() - get the current power
* @cdev: &thermal_cooling_device pointer
@@ -536,22 +463,88 @@ static int cpufreq_power2state(struct thermal_cooling_device *cdev,
power);
return 0;
}
+#endif /* CONFIG_THERMAL_GOV_POWER_ALLOCATOR */
+
+/* cpufreq cooling device callback functions are defined below */
+
+/**
+ * cpufreq_get_max_state - callback function to get the max cooling state.
+ * @cdev: thermal cooling device pointer.
+ * @state: fill this variable with the max cooling state.
+ *
+ * Callback for the thermal cooling device to return the cpufreq
+ * max cooling state.
+ *
+ * Return: 0 on success, an error code otherwise.
+ */
+static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
+
+ *state = cpufreq_cdev->max_level;
+ return 0;
+}
+
+/**
+ * cpufreq_get_cur_state - callback function to get the current cooling state.
+ * @cdev: thermal cooling device pointer.
+ * @state: fill this variable with the current cooling state.
+ *
+ * Callback for the thermal cooling device to return the cpufreq
+ * current cooling state.
+ *
+ * Return: 0 on success, an error code otherwise.
+ */
+static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
+
+ *state = cpufreq_cdev->cpufreq_state;
+
+ return 0;
+}
+
+/**
+ * cpufreq_set_cur_state - callback function to set the current cooling state.
+ * @cdev: thermal cooling device pointer.
+ * @state: set this variable to the current cooling state.
+ *
+ * Callback for the thermal cooling device to change the cpufreq
+ * current cooling state.
+ *
+ * Return: 0 on success, an error code otherwise.
+ */
+static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long state)
+{
+ struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
+ unsigned int clip_freq;
+
+ /* Request state should be less than max_level */
+ if (WARN_ON(state > cpufreq_cdev->max_level))
+ return -EINVAL;
+
+ /* Check if the old cooling action is same as new cooling action */
+ if (cpufreq_cdev->cpufreq_state == state)
+ return 0;
+
+ clip_freq = cpufreq_cdev->freq_table[state].frequency;
+ cpufreq_cdev->cpufreq_state = state;
+ cpufreq_cdev->clipped_freq = clip_freq;
+
+ cpufreq_update_policy(cpufreq_cdev->policy->cpu);
+
+ return 0;
+}
/* Bind cpufreq callbacks to thermal cooling device ops */
static struct thermal_cooling_device_ops cpufreq_cooling_ops = {
- .get_max_state = cpufreq_get_max_state,
- .get_cur_state = cpufreq_get_cur_state,
- .set_cur_state = cpufreq_set_cur_state,
-};
-
-static struct thermal_cooling_device_ops cpufreq_power_cooling_ops = {
.get_max_state = cpufreq_get_max_state,
.get_cur_state = cpufreq_get_cur_state,
.set_cur_state = cpufreq_set_cur_state,
- .get_requested_power = cpufreq_get_requested_power,
- .state2power = cpufreq_state2power,
- .power2state = cpufreq_power2state,
};
/* Notifier for cpufreq policy change */
@@ -659,18 +652,19 @@ __cpufreq_cooling_register(struct device_node *np,
pr_debug("%s: freq:%u KHz\n", __func__, freq);
}
+ cooling_ops = &cpufreq_cooling_ops;
+#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
if (capacitance) {
ret = update_freq_table(cpufreq_cdev, capacitance);
if (ret) {
cdev = ERR_PTR(ret);
goto remove_ida;
}
-
- cooling_ops = &cpufreq_power_cooling_ops;
- } else {
- cooling_ops = &cpufreq_cooling_ops;
+ cooling_ops->get_requested_power = cpufreq_get_requested_power;
+ cooling_ops->state2power = cpufreq_state2power;
+ cooling_ops->power2state = cpufreq_power2state;
}
-
+#endif
cdev = thermal_of_cooling_device_register(np, dev_name, cpufreq_cdev,
cooling_ops);
if (IS_ERR(cdev))
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 3/3] thermal: cpu_cooling: Migrate to using the EM framework
From: Quentin Perret @ 2019-08-01 12:46 UTC (permalink / raw)
To: edubezval, rui.zhang, javi.merino, viresh.kumar, amit.kachhap,
rjw, catalin.marinas, will, daniel.lezcano
Cc: linux-pm, linux-kernel, quentin.perret, mka, ionela.voinescu,
dietmar.eggemann, linux-arm-kernel
In-Reply-To: <20190801124643.17112-1-quentin.perret@arm.com>
The newly introduced Energy Model framework manages power cost tables in
a generic way. Moreover, it supports several types of models since the
tables can come from DT or firmware (through SCMI) for example. On the
other hand, the cpu_cooling subsystem manages its own power cost tables
using only DT data.
In order to avoid the duplication of data in the kernel, and in order to
enable IPA with EMs coming from more than just DT, remove the private
tables from cpu_cooling.c and migrate it to using the centralized EM
framework. Doing so should have no visible functional impact for
existing users of IPA since:
- recent extenstions to the the PM_OPP infrastructure enable the
registration of EMs in PM_EM using the DT property used by IPA;
- the existing upstream cpufreq drivers marked with the
'CPUFREQ_IS_COOLING_DEV' flag all use the aforementioned PM_OPP
infrastructure, which means they all support PM_EM. The only two
exceptions are qoriq-cpufreq which doesn't in fact use an EM and
scmi-cpufreq which doesn't use DT for power costs.
For existing users of cpu_cooling, PM_EM tables will contain the exact
same power values that IPA used to compute on its own until now. The
only new dependency for them is to compile in CONFIG_ENERGY_MODEL.
The case where the thermal subsystem is used without an Energy Model
(cpufreq_cooling_ops) is handled by looking directly at CPUFreq's
frequency table which is already a dependency for cpu_cooling.c anyway.
Since the thermal framework expects the cooling states in a particular
order, bail out whenever the CPUFreq table is unsorted, since that is
fairly uncommon in general, and there are currently no users of
cpu_cooling for this use-case.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
---
drivers/thermal/Kconfig | 1 +
drivers/thermal/cpu_cooling.c | 250 ++++++++++++----------------------
2 files changed, 91 insertions(+), 160 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9966364a6deb..340853a3ca48 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -144,6 +144,7 @@ config THERMAL_GOV_USER_SPACE
config THERMAL_GOV_POWER_ALLOCATOR
bool "Power allocator thermal governor"
+ depends on ENERGY_MODEL
help
Enable this to manage platform thermals by dynamically
allocating and limiting power to devices.
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 498f59ab64b2..83486775e593 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/cpu.h>
#include <linux/cpu_cooling.h>
+#include <linux/energy_model.h>
#include <trace/events/thermal.h>
@@ -36,21 +37,6 @@
* ...
*/
-/**
- * struct freq_table - frequency table along with power entries
- * @frequency: frequency in KHz
- * @power: power in mW
- *
- * This structure is built when the cooling device registers and helps
- * in translating frequency to power and vice versa.
- */
-struct freq_table {
- u32 frequency;
-#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
- u32 power;
-#endif
-};
-
/**
* struct time_in_idle - Idle time stats
* @time: previous reading of the absolute time that this cpu was idle
@@ -72,7 +58,7 @@ struct time_in_idle {
* frequency.
* @max_level: maximum cooling level. One less than total number of valid
* cpufreq frequencies.
- * @freq_table: Freq table in descending order of frequencies
+ * @em: Reference on the Energy Model of the device
* @cdev: thermal_cooling_device pointer to keep track of the
* registered cooling device.
* @policy: cpufreq policy.
@@ -88,7 +74,7 @@ struct cpufreq_cooling_device {
unsigned int cpufreq_state;
unsigned int clipped_freq;
unsigned int max_level;
- struct freq_table *freq_table; /* In descending order */
+ struct em_perf_domain *em;
struct cpufreq_policy *policy;
struct list_head node;
struct time_in_idle *idle_time;
@@ -162,114 +148,40 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb,
static unsigned long get_level(struct cpufreq_cooling_device *cpufreq_cdev,
unsigned int freq)
{
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- unsigned long level;
+ int i;
- for (level = 1; level <= cpufreq_cdev->max_level; level++)
- if (freq > freq_table[level].frequency)
+ for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
+ if (freq > cpufreq_cdev->em->table[i].frequency)
break;
-
- return level - 1;
-}
-
-/**
- * update_freq_table() - Update the freq table with power numbers
- * @cpufreq_cdev: the cpufreq cooling device in which to update the table
- * @capacitance: dynamic power coefficient for these cpus
- *
- * Update the freq table with power numbers. This table will be used in
- * cpu_power_to_freq() and cpu_freq_to_power() to convert between power and
- * frequency efficiently. Power is stored in mW, frequency in KHz. The
- * resulting table is in descending order.
- *
- * Return: 0 on success, -EINVAL if there are no OPPs for any CPUs,
- * or -ENOMEM if we run out of memory.
- */
-static int update_freq_table(struct cpufreq_cooling_device *cpufreq_cdev,
- u32 capacitance)
-{
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- struct dev_pm_opp *opp;
- struct device *dev = NULL;
- int num_opps = 0, cpu = cpufreq_cdev->policy->cpu, i;
-
- dev = get_cpu_device(cpu);
- if (unlikely(!dev)) {
- pr_warn("No cpu device for cpu %d\n", cpu);
- return -ENODEV;
- }
-
- num_opps = dev_pm_opp_get_opp_count(dev);
- if (num_opps < 0)
- return num_opps;
-
- /*
- * The cpufreq table is also built from the OPP table and so the count
- * should match.
- */
- if (num_opps != cpufreq_cdev->max_level + 1) {
- dev_warn(dev, "Number of OPPs not matching with max_levels\n");
- return -EINVAL;
- }
-
- for (i = 0; i <= cpufreq_cdev->max_level; i++) {
- unsigned long freq = freq_table[i].frequency * 1000;
- u32 freq_mhz = freq_table[i].frequency / 1000;
- u64 power;
- u32 voltage_mv;
-
- /*
- * Find ceil frequency as 'freq' may be slightly lower than OPP
- * freq due to truncation while converting to kHz.
- */
- opp = dev_pm_opp_find_freq_ceil(dev, &freq);
- if (IS_ERR(opp)) {
- dev_err(dev, "failed to get opp for %lu frequency\n",
- freq);
- return -EINVAL;
- }
-
- voltage_mv = dev_pm_opp_get_voltage(opp) / 1000;
- dev_pm_opp_put(opp);
-
- /*
- * Do the multiplication with MHz and millivolt so as
- * to not overflow.
- */
- power = (u64)capacitance * freq_mhz * voltage_mv * voltage_mv;
- do_div(power, 1000000000);
-
- /* power is stored in mW */
- freq_table[i].power = power;
}
- return 0;
+ return cpufreq_cdev->max_level - i - 1;
}
static u32 cpu_freq_to_power(struct cpufreq_cooling_device *cpufreq_cdev,
u32 freq)
{
int i;
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- for (i = 1; i <= cpufreq_cdev->max_level; i++)
- if (freq > freq_table[i].frequency)
+ for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
+ if (freq > cpufreq_cdev->em->table[i].frequency)
break;
+ }
- return freq_table[i - 1].power;
+ return cpufreq_cdev->em->table[i + 1].power;
}
static u32 cpu_power_to_freq(struct cpufreq_cooling_device *cpufreq_cdev,
u32 power)
{
int i;
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- for (i = 1; i <= cpufreq_cdev->max_level; i++)
- if (power > freq_table[i].power)
+ for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
+ if (power > cpufreq_cdev->em->table[i].power)
break;
+ }
- return freq_table[i - 1].frequency;
+ return cpufreq_cdev->em->table[i + 1].frequency;
}
/**
@@ -410,7 +322,7 @@ static int cpufreq_state2power(struct thermal_cooling_device *cdev,
struct thermal_zone_device *tz,
unsigned long state, u32 *power)
{
- unsigned int freq, num_cpus;
+ unsigned int freq, num_cpus, idx;
struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
/* Request state should be less than max_level */
@@ -419,7 +331,8 @@ static int cpufreq_state2power(struct thermal_cooling_device *cdev,
num_cpus = cpumask_weight(cpufreq_cdev->policy->cpus);
- freq = cpufreq_cdev->freq_table[state].frequency;
+ idx = cpufreq_cdev->max_level - state;
+ freq = cpufreq_cdev->em->table[idx].frequency;
*power = cpu_freq_to_power(cpufreq_cdev, freq) * num_cpus;
return 0;
@@ -463,8 +376,60 @@ static int cpufreq_power2state(struct thermal_cooling_device *cdev,
power);
return 0;
}
+
+static inline bool em_is_sane(struct cpufreq_cooling_device *cpufreq_cdev,
+ struct em_perf_domain *em) {
+ struct cpufreq_policy *policy;
+ unsigned int nr_levels;
+
+ if (!em)
+ return false;
+
+ policy = cpufreq_cdev->policy;
+ if (!cpumask_equal(policy->related_cpus, to_cpumask(em->cpus))) {
+ pr_err("The span of pd %*pbl is misaligned with cpufreq policy %*pbl\n",
+ cpumask_pr_args(to_cpumask(em->cpus)),
+ cpumask_pr_args(policy->related_cpus));
+ return false;
+ }
+
+ nr_levels = cpufreq_cdev->max_level + 1;
+ if (em->nr_cap_states != nr_levels) {
+ pr_err("The number of cap states in pd %*pbl (%u) doesn't match the number of cooling levels (%u)\n",
+ cpumask_pr_args(to_cpumask(em->cpus)),
+ em->nr_cap_states, nr_levels);
+ return false;
+ }
+
+ return true;
+}
#endif /* CONFIG_THERMAL_GOV_POWER_ALLOCATOR */
+static unsigned int get_state_freq(struct cpufreq_cooling_device *cpufreq_cdev,
+ unsigned long state)
+{
+ struct cpufreq_policy *policy;
+ unsigned long idx;
+
+#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
+ /* Use the Energy Model table if available */
+ if (cpufreq_cdev->em) {
+ idx = cpufreq_cdev->max_level - state;
+ return cpufreq_cdev->em->table[idx].frequency;
+ }
+#endif
+
+ /* Otherwise, fallback on the CPUFreq table */
+ policy = cpufreq_cdev->policy;
+ if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING)
+ idx = cpufreq_cdev->max_level - state;
+ else
+ idx = state;
+
+ return policy->freq_table[idx].frequency;
+}
+
+
/* cpufreq cooling device callback functions are defined below */
/**
@@ -530,7 +495,7 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
if (cpufreq_cdev->cpufreq_state == state)
return 0;
- clip_freq = cpufreq_cdev->freq_table[state].frequency;
+ clip_freq = get_state_freq(cpufreq_cdev, state);
cpufreq_cdev->cpufreq_state = state;
cpufreq_cdev->clipped_freq = clip_freq;
@@ -552,26 +517,12 @@ static struct notifier_block thermal_cpufreq_notifier_block = {
.notifier_call = cpufreq_thermal_notifier,
};
-static unsigned int find_next_max(struct cpufreq_frequency_table *table,
- unsigned int prev_max)
-{
- struct cpufreq_frequency_table *pos;
- unsigned int max = 0;
-
- cpufreq_for_each_valid_entry(pos, table) {
- if (pos->frequency > max && pos->frequency < prev_max)
- max = pos->frequency;
- }
-
- return max;
-}
-
/**
* __cpufreq_cooling_register - helper function to create cpufreq cooling device
* @np: a valid struct device_node to the cooling device device tree node
* @policy: cpufreq policy
* Normally this should be same as cpufreq policy->related_cpus.
- * @capacitance: dynamic power coefficient for these cpus
+ * @em: Energy Model of the cpufreq policy
*
* This interface function registers the cpufreq cooling device with the name
* "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
@@ -583,12 +534,13 @@ static unsigned int find_next_max(struct cpufreq_frequency_table *table,
*/
static struct thermal_cooling_device *
__cpufreq_cooling_register(struct device_node *np,
- struct cpufreq_policy *policy, u32 capacitance)
+ struct cpufreq_policy *policy,
+ struct em_perf_domain *em)
{
struct thermal_cooling_device *cdev;
struct cpufreq_cooling_device *cpufreq_cdev;
char dev_name[THERMAL_NAME_LENGTH];
- unsigned int freq, i, num_cpus;
+ unsigned int i, num_cpus;
int ret;
struct thermal_cooling_device_ops *cooling_ops;
bool first;
@@ -622,55 +574,38 @@ __cpufreq_cooling_register(struct device_node *np,
/* max_level is an index, not a counter */
cpufreq_cdev->max_level = i - 1;
- cpufreq_cdev->freq_table = kmalloc_array(i,
- sizeof(*cpufreq_cdev->freq_table),
- GFP_KERNEL);
- if (!cpufreq_cdev->freq_table) {
- cdev = ERR_PTR(-ENOMEM);
- goto free_idle_time;
- }
-
ret = ida_simple_get(&cpufreq_ida, 0, 0, GFP_KERNEL);
if (ret < 0) {
cdev = ERR_PTR(ret);
- goto free_table;
+ goto free_idle_time;
}
cpufreq_cdev->id = ret;
snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
cpufreq_cdev->id);
- /* Fill freq-table in descending order of frequencies */
- for (i = 0, freq = -1; i <= cpufreq_cdev->max_level; i++) {
- freq = find_next_max(policy->freq_table, freq);
- cpufreq_cdev->freq_table[i].frequency = freq;
-
- /* Warn for duplicate entries */
- if (!freq)
- pr_warn("%s: table has duplicate entries\n", __func__);
- else
- pr_debug("%s: freq:%u KHz\n", __func__, freq);
- }
-
cooling_ops = &cpufreq_cooling_ops;
#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
- if (capacitance) {
- ret = update_freq_table(cpufreq_cdev, capacitance);
- if (ret) {
- cdev = ERR_PTR(ret);
- goto remove_ida;
- }
+ if (em_is_sane(cpufreq_cdev, em)) {
+ cpufreq_cdev->em = em;
cooling_ops->get_requested_power = cpufreq_get_requested_power;
cooling_ops->state2power = cpufreq_state2power;
cooling_ops->power2state = cpufreq_power2state;
- }
+ } else
#endif
+ if (policy->freq_table_sorted == CPUFREQ_TABLE_UNSORTED) {
+ pr_err("%s: unsorted frequency tables are not supported\n",
+ __func__);
+ cdev = ERR_PTR(-EINVAL);
+ goto remove_ida;
+ }
+
cdev = thermal_of_cooling_device_register(np, dev_name, cpufreq_cdev,
cooling_ops);
if (IS_ERR(cdev))
goto remove_ida;
- cpufreq_cdev->clipped_freq = cpufreq_cdev->freq_table[0].frequency;
+ cpufreq_cdev->clipped_freq = get_state_freq(cpufreq_cdev, 0);
mutex_lock(&cooling_list_lock);
/* Register the notifier for first cpufreq cooling device */
@@ -686,8 +621,6 @@ __cpufreq_cooling_register(struct device_node *np,
remove_ida:
ida_simple_remove(&cpufreq_ida, cpufreq_cdev->id);
-free_table:
- kfree(cpufreq_cdev->freq_table);
free_idle_time:
kfree(cpufreq_cdev->idle_time);
free_cdev:
@@ -709,7 +642,7 @@ __cpufreq_cooling_register(struct device_node *np,
struct thermal_cooling_device *
cpufreq_cooling_register(struct cpufreq_policy *policy)
{
- return __cpufreq_cooling_register(NULL, policy, 0);
+ return __cpufreq_cooling_register(NULL, policy, NULL);
}
EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
@@ -737,7 +670,6 @@ of_cpufreq_cooling_register(struct cpufreq_policy *policy)
{
struct device_node *np = of_get_cpu_node(policy->cpu, NULL);
struct thermal_cooling_device *cdev = NULL;
- u32 capacitance = 0;
if (!np) {
pr_err("cpu_cooling: OF node not available for cpu%d\n",
@@ -746,10 +678,9 @@ of_cpufreq_cooling_register(struct cpufreq_policy *policy)
}
if (of_find_property(np, "#cooling-cells", NULL)) {
- of_property_read_u32(np, "dynamic-power-coefficient",
- &capacitance);
+ struct em_perf_domain *em = em_cpu_get(policy->cpu);
- cdev = __cpufreq_cooling_register(np, policy, capacitance);
+ cdev = __cpufreq_cooling_register(np, policy, em);
if (IS_ERR(cdev)) {
pr_err("cpu_cooling: cpu%d failed to register as cooling device: %ld\n",
policy->cpu, PTR_ERR(cdev));
@@ -791,7 +722,6 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
thermal_cooling_device_unregister(cdev);
ida_simple_remove(&cpufreq_ida, cpufreq_cdev->id);
kfree(cpufreq_cdev->idle_time);
- kfree(cpufreq_cdev->freq_table);
kfree(cpufreq_cdev);
}
EXPORT_SYMBOL_GPL(cpufreq_cooling_unregister);
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] serial: mctrl_gpio: Avoid probe failures in case of missing gpiolib
From: Schrempf Frieder @ 2019-08-01 12:46 UTC (permalink / raw)
To: u.kleine-koenig@pengutronix.de, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-imx@nxp.com, Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
Schrempf Frieder, linux-arm-kernel@lists.infradead.org,
Jiri Slaby
From: Frieder Schrempf <frieder.schrempf@kontron.de>
If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
mctrl_gpio_init_noauto() will currently return an error pointer with
-ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
check for this condition to allow continue probing.
To avoid the need for this check in each driver, we return NULL
instead, as all the mctrl_gpio_*() functions are skipped anyway.
We also adapt mctrl_gpio_to_gpiod() to be in line with this change.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
drivers/tty/serial/serial_mctrl_gpio.c | 3 +++
drivers/tty/serial/serial_mctrl_gpio.h | 6 +++---
drivers/tty/serial/sh-sci.c | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
index 2b400189be91..54c43e02e375 100644
--- a/drivers/tty/serial/serial_mctrl_gpio.c
+++ b/drivers/tty/serial/serial_mctrl_gpio.c
@@ -61,6 +61,9 @@ EXPORT_SYMBOL_GPL(mctrl_gpio_set);
struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
enum mctrl_gpio_idx gidx)
{
+ if (gpios == NULL)
+ return NULL;
+
return gpios->gpio[gidx];
}
EXPORT_SYMBOL_GPL(mctrl_gpio_to_gpiod);
diff --git a/drivers/tty/serial/serial_mctrl_gpio.h b/drivers/tty/serial/serial_mctrl_gpio.h
index b7d3cca48ede..1b2ff503b2c2 100644
--- a/drivers/tty/serial/serial_mctrl_gpio.h
+++ b/drivers/tty/serial/serial_mctrl_gpio.h
@@ -114,19 +114,19 @@ static inline
struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
enum mctrl_gpio_idx gidx)
{
- return ERR_PTR(-ENOSYS);
+ return NULL;
}
static inline
struct mctrl_gpios *mctrl_gpio_init(struct uart_port *port, unsigned int idx)
{
- return ERR_PTR(-ENOSYS);
+ return NULL;
}
static inline
struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
{
- return ERR_PTR(-ENOSYS);
+ return NULL;
}
static inline
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index d18c680aa64b..249325b65ee0 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3287,7 +3287,7 @@ static int sci_probe_single(struct platform_device *dev,
return ret;
sciport->gpios = mctrl_gpio_init(&sciport->port, 0);
- if (IS_ERR(sciport->gpios) && PTR_ERR(sciport->gpios) != -ENOSYS)
+ if (IS_ERR(sciport->gpios))
return PTR_ERR(sciport->gpios);
if (sciport->has_rtscts) {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
From: Andrey Konovalov @ 2019-08-01 12:48 UTC (permalink / raw)
To: Kevin Brodsky
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kees Cook,
Ruben Ayrapetyan, Ramana Radhakrishnan, Alex Williamson,
Mauro Carvalho Chehab, Linux ARM, Kostya Serebryany, Dave Hansen,
Greg Kroah-Hartman, Yishai Hadas, LKML, Jens Wiklander, Lee Smith,
Alexander Deucher, Andrew Morton, enh, Robin Murphy,
Christian Koenig, Luc Van Oostenryck
In-Reply-To: <13b4cf53-3ecb-f7e7-b504-d77af15d77aa@arm.com>
On Thu, Aug 1, 2019 at 2:11 PM Kevin Brodsky <kevin.brodsky@arm.com> wrote:
>
> On 31/07/2019 17:50, Dave Hansen wrote:
> > On 7/23/19 10:58 AM, Andrey Konovalov wrote:
> >> The mmap and mremap (only new_addr) syscalls do not currently accept
> >> tagged addresses. Architectures may interpret the tag as a background
> >> colour for the corresponding vma.
> > What the heck is a "background colour"? :)
>
> Good point, this is some jargon that we started using for MTE, the idea being that
> the kernel could set a tag value (specified during mmap()) as "background colour" for
> anonymous pages allocated in that range.
>
> Anyway, this patch series is not about MTE. Andrey, for v20 (if any), I think it's
> best to drop this last sentence to avoid any confusion.
Sure, thanks!
>
> Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] i2c: mxs: use devm_platform_ioremap_resource() to simplify code
From: Wolfram Sang @ 2019-08-01 12:50 UTC (permalink / raw)
To: Anson.Huang
Cc: aisheng.dong, shawnguo, s.hauer, linux-kernel, wsa+renesas,
linux-i2c, kernel, festevam, linux-arm-kernel, Linux-imx
In-Reply-To: <20190717084017.30987-1-Anson.Huang@nxp.com>
[-- Attachment #1.1: Type: text/plain, Size: 368 bytes --]
On Wed, Jul 17, 2019 at 04:40:16PM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Use the new helper devm_platform_ioremap_resource() which wraps the
> platform_get_resource() and devm_ioremap_resource() together, to
> simplify the code.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] i2c: imx-lpi2c: use devm_platform_ioremap_resource() to simplify code
From: Wolfram Sang @ 2019-08-01 12:50 UTC (permalink / raw)
To: Anson.Huang
Cc: aisheng.dong, shawnguo, s.hauer, linux-kernel, wsa+renesas,
linux-i2c, kernel, festevam, linux-arm-kernel, Linux-imx
In-Reply-To: <20190717084017.30987-2-Anson.Huang@nxp.com>
[-- Attachment #1.1: Type: text/plain, Size: 368 bytes --]
On Wed, Jul 17, 2019 at 04:40:17PM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Use the new helper devm_platform_ioremap_resource() which wraps the
> platform_get_resource() and devm_ioremap_resource() together, to
> simplify the code.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/9] arm64: perf: Remove PMU locking
From: Will Deacon @ 2019-08-01 12:58 UTC (permalink / raw)
To: Julien Thierry
Cc: mark.rutland, peterz, Catalin Marinas, will.deacon, acme,
alexander.shishkin, mingo, namhyung, sthotton, jolsa,
linux-arm-kernel, liwei391
In-Reply-To: <1563351432-55652-3-git-send-email-julien.thierry@arm.com>
On Wed, Jul 17, 2019 at 09:17:05AM +0100, Julien Thierry wrote:
> Since the PMU driver uses direct registers for counter
> setup/manipulation, locking around these operations is no longer needed.
>
> For operations that can be called with interrupts enabled, preemption
> still needs to be disabled to ensure the programming of the PMU is
> done on the expected CPU and not migrated mid-programming.
>
> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Jiri Olsa <jolsa@redhat.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/kernel/perf_event.c | 30 ++----------------------------
> 1 file changed, 2 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 838758f..0e2cf5d 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -673,15 +673,10 @@ static inline u32 armv8pmu_getreset_flags(void)
>
> static void armv8pmu_enable_event(struct perf_event *event)
> {
> - unsigned long flags;
> - struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> /*
> * Enable counter and interrupt, and set the counter to count
> * the event that we're interested in.
> */
> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
>
> /*
> * Disable counter
> @@ -702,21 +697,10 @@ static void armv8pmu_enable_event(struct perf_event *event)
> * Enable counter
> */
> armv8pmu_enable_event_counter(event);
> -
> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> }
With the implicit ISBs now removed by virtue of addressing the counter
register directly, what prevents the programming of the evtype being
reordered with respect to disabling/enabling the counter?
> static void armv8pmu_disable_event(struct perf_event *event)
> {
> - unsigned long flags;
> - struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> - /*
> - * Disable counter and interrupt
> - */
> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
> -
> /*
> * Disable counter
> */
> @@ -726,30 +710,20 @@ static void armv8pmu_disable_event(struct perf_event *event)
> * Disable interrupt for this counter
> */
> armv8pmu_disable_event_irq(event);
> -
> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> }
>
> static void armv8pmu_start(struct arm_pmu *cpu_pmu)
> {
> - unsigned long flags;
> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
> + WARN_ON_ONCE(preemptible());
> /* Enable all counters */
> armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> }
>
> static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
> {
> - unsigned long flags;
> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
> + WARN_ON_ONCE(preemptible());
I don't think we need these WARN_ONs -- these are very much per-CPU
operations from the context of the perf core, so we'll be ok.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/3] Make IPA use PM_EM
From: Daniel Lezcano @ 2019-08-01 13:00 UTC (permalink / raw)
To: Quentin Perret, edubezval, rui.zhang, javi.merino, viresh.kumar,
amit.kachhap, rjw, catalin.marinas, will
Cc: linux-pm, linux-kernel, mka, ionela.voinescu, dietmar.eggemann,
linux-arm-kernel
In-Reply-To: <20190801124643.17112-1-quentin.perret@arm.com>
Hi Rui,
is it possible to merge these patches? They are acked-by since May.
Thanks
-- Daniel
On 01/08/2019 14:46, Quentin Perret wrote:
> Changes in v6
> *************
> - Added Daniel's and Viresh's Acked-by to all patches
>
> Changes in v5:
> **************
> - Changed patch 02 to guard IPA-specific code in cpu_cooling.c with
> appropriate ifdefery (Daniel)
> - Rebased on 5.2-rc2
>
> Changes in v4:
> **************
> - Added Viresh's Acked-by to all 3 patches
> - Improved commit message of patch 3/3 to explain how it has no
> functional impact on existing users (Eduardo)
>
> Changes in v3:
> **************
> - Changed warning message for unordered tables to something more
> explicit (Viresh)
> - Changed WARN() into a pr_err() for consistency
>
> Changes in v2:
> **************
> - Fixed patch 01/03 to actually enable CONFIG_ENERGY_MODEL
> - Added "depends on ENERGY_MODEL" to IPA (Daniel)
> - Added check to bail out if the freq table is unsorted (Viresh)
>
> Cover letter:
> *************
>
> The Intelligent Power Allocator (IPA) thermal governor uses an Energy
> Model (or EM) of the CPUs to re-distribute the power budget. To do so,
> it builds a table of <frequency, power> tuples where the power values
> are computed using the 'dynamic-power-coefficient' DT property. All of
> this is done in and only for the thermal subsystem, and more
> specifically for CPUs -- the power of other types of devices is obtained
> differently.
>
> Recently, the CPU scheduler has seen the introduction of Energy Aware
> Scheduling (EAS) patches, which also rely on an EM of the CPUs. This EM,
> however, is managed by an independent framework, called PM_EM, aimed to
> be used by all kernel subsystems interested in the power consumed by
> CPUs, and not only the scheduler.
>
> This patch series follows this logic and removes the (now redundant)
> thermal-specific EM computation code to migrate IPA to use PM_EM
> instead.
>
> Doing so should have no visible functional impact for existing users of
> IPA since:
>
> - during the 5.1 development cycle, a series of patches [1] introduced
> in PM_OPP some infrastructure (dev_pm_opp_of_register_em()) enabling
> the registration of EMs in PM_EM using the DT property used by IPA;
>
> - the existing upstream cpufreq drivers marked with the
> 'CPUFREQ_IS_COOLING_DEV' flag all call dev_pm_opp_of_register_em(),
> which means they all support PM_EM (the only two exceptions are
> qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which
> already supports PM_EM without using the PM_OPP infrastructurei
> because it read power costs directly from firmware);
>
> So, migrating IPA to using PM_EM should effectively be just plumbing
> since for the existing IPA users the PM_EM tables will contain the
> exact same power values that IPA used to compute on its own until now.
> The only new dependency is to compile in CONFIG_ENERGY_MODEL.
>
> Why is this migration still a good thing ? For three main reasons.
>
> 1. it removes redundant code;
>
> 2. it introduces an abstraction layer between IPA and the EM
> computation. PM_EM offers to EAS and IPA (and potentially other
> clients) standardized EM tables and hides 'how' these tables have
> been obtained. PM_EM as of now supports power values either coming
> from the 'dynamic-power-coefficient' DT property or obtained
> directly from firmware using SCMI. The latter is a new feature for
> IPA and that comes 'for free' with the migration. This will also be
> true in the future every time PM_EM gets support for other ways of
> loading the EM. Moreover, PM_EM is documented and has a debugfs
> interface which should help adding support for new platforms.
>
> 3. it builds a consistent view of the EM of CPUs across kernel
> subsystems, which is a pre-requisite for any kind of future work
> aiming at a smarter power allocation using scheduler knowledge about
> the system for example.
>
> [1] https://lore.kernel.org/lkml/20190204110952.16025-1-quentin.perret@arm.com/
>
>
> Quentin Perret (3):
> arm64: defconfig: Enable CONFIG_ENERGY_MODEL
> thermal: cpu_cooling: Make the power-related code depend on IPA
> thermal: cpu_cooling: Migrate to using the EM framework
>
> arch/arm64/configs/defconfig | 1 +
> drivers/thermal/Kconfig | 1 +
> drivers/thermal/cpu_cooling.c | 428 ++++++++++++++--------------------
> 3 files changed, 178 insertions(+), 252 deletions(-)
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/9] arm: perf: save/resore pmsel
From: Will Deacon @ 2019-08-01 13:01 UTC (permalink / raw)
To: Julien Thierry
Cc: mark.rutland, peterz, liwei391, will.deacon, Russell King, acme,
alexander.shishkin, mingo, stable, namhyung, sthotton, jolsa,
linux-arm-kernel
In-Reply-To: <1563351432-55652-4-git-send-email-julien.thierry@arm.com>
[typo in subject: resore ->restore]
On Wed, Jul 17, 2019 at 09:17:06AM +0100, Julien Thierry wrote:
> The callback pmu->read() can be called with interrupts enabled.
> Currently, on ARM, this can cause the following callchain:
>
> armpmu_read() -> armpmu_event_update() -> armv7pmu_read_counter()
Why can't we just disable irqs in armv7pmu_read_counter() ?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] i2c: s3c2410: Mark expected switch fall-through
From: Wolfram Sang @ 2019-08-01 13:01 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Stephen Rothwell, linux-samsung-soc, Kees Cook, linux-kernel,
Krzysztof Kozlowski, Kukjin Kim, linux-i2c, linux-arm-kernel
In-Reply-To: <20190728235138.GA23429@embeddedor>
[-- Attachment #1.1: Type: text/plain, Size: 786 bytes --]
On Sun, Jul 28, 2019 at 06:51:38PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/i2c/busses/i2c-s3c2410.c: In function 'i2c_s3c_irq_nextbyte':
> drivers/i2c/busses/i2c-s3c2410.c:431:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> if (i2c->state == STATE_READ)
> ^
> drivers/i2c/busses/i2c-s3c2410.c:439:2: note: here
> case STATE_WRITE:
> ^~~~
>
> Notice that, in this particular case, the code comment is
> modified in accordance with what GCC is expecting to find.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied to for-current, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/9] arm64: perf: Do not call irq_work_run in NMI context
From: Will Deacon @ 2019-08-01 13:06 UTC (permalink / raw)
To: Julien Thierry
Cc: mark.rutland, peterz, Catalin Marinas, will.deacon, acme,
alexander.shishkin, mingo, namhyung, sthotton, jolsa,
linux-arm-kernel, liwei391
In-Reply-To: <1563351432-55652-7-git-send-email-julien.thierry@arm.com>
On Wed, Jul 17, 2019 at 09:17:09AM +0100, Julien Thierry wrote:
> Function irq_work_run is not NMI safe and should not be called from NMI
> context.
>
> When PMU interrupt is an NMI do not call irq_work_run. Instead rely on the
> IRQ work IPI to run the irq_work queue once NMI/IRQ contexts have been
> exited.
>
> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Jiri Olsa <jolsa@redhat.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/kernel/perf_event.c | 14 +++++---------
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 0e2cf5d..9c959ad 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -776,20 +776,16 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> if (!armpmu_event_set_period(event))
> continue;
>
> + /*
> + * Perf event overflow will queue the processing of the event as
> + * an irq_work which will be taken care of in the handling of
> + * IPI_IRQ_WORK.
> + */
> if (perf_event_overflow(event, &data, regs))
> cpu_pmu->disable(event);
> }
> armv8pmu_start(cpu_pmu);
>
> - /*
> - * Handle the pending perf events.
> - *
> - * Note: this call *must* be run with interrupts disabled. For
> - * platforms that can have the PMU interrupts raised as an NMI, this
> - * will not work.
> - */
> - irq_work_run();
What about the case where NMIs are not being used (e.g. GICv2)?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/9] arm: perf: Remove Remove PMU locking
From: Will Deacon @ 2019-08-01 13:06 UTC (permalink / raw)
To: Julien Thierry
Cc: mark.rutland, peterz, liwei391, will.deacon, Russell King, acme,
alexander.shishkin, mingo, namhyung, sthotton, jolsa,
linux-arm-kernel
In-Reply-To: <1563351432-55652-5-git-send-email-julien.thierry@arm.com>
[extra 'Remove' in subject]
On Wed, Jul 17, 2019 at 09:17:07AM +0100, Julien Thierry wrote:
> Since the PMU interrupt saves and restores the value of the selector
> register, there is no need to serialize register accesses against the
> interrupt contexts.
>
> For operations that can be called with interrupts enabled, preemption
> still needs to be disabled to ensure the programming of the PMU is
> done on the expected CPU and not migrated mid-programming.
>
> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Jiri Olsa <jolsa@redhat.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> ---
> arch/arm/kernel/perf_event_v7.c | 54 ++---------------------------------------
> 1 file changed, 2 insertions(+), 52 deletions(-)
I'm struggling to see why this patch is needed or, if it is, why we're not
doing something similar for v6 and xscale.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Applied "ASoC: zx-tdm: remove redundant assignment to ts_width on error return path" to the asoc tree
From: Mark Brown @ 2019-08-01 13:10 UTC (permalink / raw)
To: Colin Ian King
Cc: alsa-devel, linux-kernel, Takashi Iwai, kernel-janitors,
Liam Girdwood, Jaroslav Kysela, Mark Brown, Jun Nie, Shawn Guo,
linux-arm-kernel
In-Reply-To: <20190731223234.16153-1-colin.king@canonical.com>
The patch
ASoC: zx-tdm: remove redundant assignment to ts_width on error return path
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From f24e41d3d04f326613d8a7ebecf72c3019826f71 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king@canonical.com>
Date: Wed, 31 Jul 2019 23:32:34 +0100
Subject: [PATCH] ASoC: zx-tdm: remove redundant assignment to ts_width on
error return path
The value assigned to ts_width is never read on the error return path
so the assignment is redundant and can be removed. Remove it.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190731223234.16153-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/zte/zx-tdm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/zte/zx-tdm.c b/sound/soc/zte/zx-tdm.c
index 5e877fe9ba7b..0e5a05b25a77 100644
--- a/sound/soc/zte/zx-tdm.c
+++ b/sound/soc/zte/zx-tdm.c
@@ -211,7 +211,6 @@ static int zx_tdm_hw_params(struct snd_pcm_substream *substream,
ts_width = 1;
break;
default:
- ts_width = 0;
dev_err(socdai->dev, "Unknown data format\n");
return -EINVAL;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] tracing: Function stack size and its name mismatch in arm64
From: Steven Rostedt @ 2019-08-01 13:15 UTC (permalink / raw)
To: Jiping Ma
Cc: catalin.marinas, will.deacon, linux-kernel, mingo, joel,
linux-arm-kernel
In-Reply-To: <20190801083340.57075-1-jiping.ma2@windriver.com>
On Thu, 1 Aug 2019 16:33:40 +0800
Jiping Ma <jiping.ma2@windriver.com> wrote:
> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
> index 5d16f73898db..ed80b95abf06 100644
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -40,16 +40,28 @@ static void print_max_stack(void)
>
> pr_emerg(" Depth Size Location (%d entries)\n"
> " ----- ---- --------\n",
> +#ifdef CONFIG_ARM64
> + stack_trace_nr_entries - 1);
> +#else
> stack_trace_nr_entries);
> -
NACK! I do not allow arch specific code in generic code like this.
The stack saving should be the same across all archs. If it is not, it
is a bug with the arch that is different.
-- Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: vexpress: Add missing newline at end of file
From: Sudeep Holla @ 2019-08-01 13:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lorenzo Pieralisi, Liviu Dudau, linux-kernel, linux-arm-kernel,
Sudeep Holla
In-Reply-To: <20190617143547.4721-1-geert+renesas@glider.be>
On Mon, Jun 17, 2019 at 04:35:47PM +0200, Geert Uytterhoeven wrote:
> "git diff" says:
>
> \ No newline at end of file
>
> after modifying the file.
>
Sorry for missing this earlier. Just found this unread and thought of
applying it to v5.4
However doing a quick check on the tree revealed more file and wonder
why you are addressing only handful of them. Why not all in one go ?
My script showed the following files:
Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
arch/arm/boot/dts/vexpress-v2m.dtsi
drivers/media/dvb-frontends/cxd2880/Kconfig
drivers/parport/Makefile
tools/perf/pmu-events/arch/powerpc/power9/cache.json
tools/perf/pmu-events/arch/powerpc/power9/floating-point.json
tools/perf/pmu-events/arch/powerpc/power9/frontend.json
tools/perf/pmu-events/arch/powerpc/power9/marked.json
tools/perf/pmu-events/arch/powerpc/power9/memory.json
tools/perf/pmu-events/arch/powerpc/power9/other.json
tools/perf/pmu-events/arch/powerpc/power9/pipeline.json
tools/perf/pmu-events/arch/powerpc/power9/pmc.json
tools/perf/pmu-events/arch/powerpc/power9/translation.json
tools/perf/pmu-events/arch/x86/bonnell/cache.json
tools/perf/pmu-events/arch/x86/bonnell/floating-point.json
tools/perf/pmu-events/arch/x86/bonnell/frontend.json
tools/perf/pmu-events/arch/x86/bonnell/memory.json
tools/perf/pmu-events/arch/x86/bonnell/other.json
tools/perf/pmu-events/arch/x86/bonnell/pipeline.json
tools/perf/pmu-events/arch/x86/bonnell/virtual-memory.json
tools/perf/pmu-events/arch/x86/broadwell/cache.json
tools/perf/pmu-events/arch/x86/broadwell/floating-point.json
tools/perf/pmu-events/arch/x86/broadwell/frontend.json
tools/perf/pmu-events/arch/x86/broadwell/memory.json
tools/perf/pmu-events/arch/x86/broadwell/other.json
tools/perf/pmu-events/arch/x86/broadwell/pipeline.json
tools/perf/pmu-events/arch/x86/broadwell/uncore.json
tools/perf/pmu-events/arch/x86/broadwell/virtual-memory.json
tools/perf/pmu-events/arch/x86/broadwellde/cache.json
tools/perf/pmu-events/arch/x86/broadwellde/floating-point.json
tools/perf/pmu-events/arch/x86/broadwellde/frontend.json
tools/perf/pmu-events/arch/x86/broadwellde/memory.json
tools/perf/pmu-events/arch/x86/broadwellde/other.json
tools/perf/pmu-events/arch/x86/broadwellde/pipeline.json
tools/perf/pmu-events/arch/x86/broadwellde/virtual-memory.json
tools/perf/pmu-events/arch/x86/broadwellx/cache.json
tools/perf/pmu-events/arch/x86/broadwellx/floating-point.json
tools/perf/pmu-events/arch/x86/broadwellx/frontend.json
tools/perf/pmu-events/arch/x86/broadwellx/memory.json
tools/perf/pmu-events/arch/x86/broadwellx/other.json
tools/perf/pmu-events/arch/x86/broadwellx/pipeline.json
tools/perf/pmu-events/arch/x86/broadwellx/virtual-memory.json
tools/perf/pmu-events/arch/x86/cascadelakex/cache.json
tools/perf/pmu-events/arch/x86/cascadelakex/floating-point.json
tools/perf/pmu-events/arch/x86/cascadelakex/frontend.json
tools/perf/pmu-events/arch/x86/cascadelakex/memory.json
tools/perf/pmu-events/arch/x86/cascadelakex/other.json
tools/perf/pmu-events/arch/x86/cascadelakex/pipeline.json
tools/perf/pmu-events/arch/x86/cascadelakex/virtual-memory.json
tools/perf/pmu-events/arch/x86/goldmont/cache.json
tools/perf/pmu-events/arch/x86/goldmont/frontend.json
tools/perf/pmu-events/arch/x86/goldmont/memory.json
tools/perf/pmu-events/arch/x86/goldmont/other.json
tools/perf/pmu-events/arch/x86/goldmont/pipeline.json
tools/perf/pmu-events/arch/x86/goldmont/virtual-memory.json
tools/perf/pmu-events/arch/x86/goldmontplus/cache.json
tools/perf/pmu-events/arch/x86/goldmontplus/frontend.json
tools/perf/pmu-events/arch/x86/goldmontplus/memory.json
tools/perf/pmu-events/arch/x86/goldmontplus/other.json
tools/perf/pmu-events/arch/x86/goldmontplus/pipeline.json
tools/perf/pmu-events/arch/x86/goldmontplus/virtual-memory.json
tools/perf/pmu-events/arch/x86/haswell/cache.json
tools/perf/pmu-events/arch/x86/haswell/floating-point.json
tools/perf/pmu-events/arch/x86/haswell/frontend.json
tools/perf/pmu-events/arch/x86/haswell/memory.json
tools/perf/pmu-events/arch/x86/haswell/other.json
tools/perf/pmu-events/arch/x86/haswell/pipeline.json
tools/perf/pmu-events/arch/x86/haswell/uncore.json
tools/perf/pmu-events/arch/x86/haswell/virtual-memory.json
tools/perf/pmu-events/arch/x86/haswellx/cache.json
tools/perf/pmu-events/arch/x86/haswellx/floating-point.json
tools/perf/pmu-events/arch/x86/haswellx/frontend.json
tools/perf/pmu-events/arch/x86/haswellx/memory.json
tools/perf/pmu-events/arch/x86/haswellx/other.json
tools/perf/pmu-events/arch/x86/haswellx/pipeline.json
tools/perf/pmu-events/arch/x86/haswellx/virtual-memory.json
tools/perf/pmu-events/arch/x86/ivybridge/cache.json
tools/perf/pmu-events/arch/x86/ivybridge/floating-point.json
tools/perf/pmu-events/arch/x86/ivybridge/frontend.json
tools/perf/pmu-events/arch/x86/ivybridge/memory.json
tools/perf/pmu-events/arch/x86/ivybridge/other.json
tools/perf/pmu-events/arch/x86/ivybridge/pipeline.json
tools/perf/pmu-events/arch/x86/ivybridge/uncore.json
tools/perf/pmu-events/arch/x86/ivybridge/virtual-memory.json
tools/perf/pmu-events/arch/x86/ivytown/cache.json
tools/perf/pmu-events/arch/x86/ivytown/floating-point.json
tools/perf/pmu-events/arch/x86/ivytown/frontend.json
tools/perf/pmu-events/arch/x86/ivytown/memory.json
tools/perf/pmu-events/arch/x86/ivytown/other.json
tools/perf/pmu-events/arch/x86/ivytown/pipeline.json
tools/perf/pmu-events/arch/x86/ivytown/virtual-memory.json
tools/perf/pmu-events/arch/x86/jaketown/cache.json
tools/perf/pmu-events/arch/x86/jaketown/floating-point.json
tools/perf/pmu-events/arch/x86/jaketown/frontend.json
tools/perf/pmu-events/arch/x86/jaketown/memory.json
tools/perf/pmu-events/arch/x86/jaketown/other.json
tools/perf/pmu-events/arch/x86/jaketown/pipeline.json
tools/perf/pmu-events/arch/x86/jaketown/virtual-memory.json
tools/perf/pmu-events/arch/x86/knightslanding/cache.json
tools/perf/pmu-events/arch/x86/knightslanding/frontend.json
tools/perf/pmu-events/arch/x86/knightslanding/memory.json
tools/perf/pmu-events/arch/x86/knightslanding/pipeline.json
tools/perf/pmu-events/arch/x86/knightslanding/virtual-memory.json
tools/perf/pmu-events/arch/x86/nehalemep/cache.json
tools/perf/pmu-events/arch/x86/nehalemep/floating-point.json
tools/perf/pmu-events/arch/x86/nehalemep/frontend.json
tools/perf/pmu-events/arch/x86/nehalemep/memory.json
tools/perf/pmu-events/arch/x86/nehalemep/other.json
tools/perf/pmu-events/arch/x86/nehalemep/pipeline.json
tools/perf/pmu-events/arch/x86/nehalemep/virtual-memory.json
tools/perf/pmu-events/arch/x86/nehalemex/cache.json
tools/perf/pmu-events/arch/x86/nehalemex/floating-point.json
tools/perf/pmu-events/arch/x86/nehalemex/frontend.json
tools/perf/pmu-events/arch/x86/nehalemex/memory.json
tools/perf/pmu-events/arch/x86/nehalemex/other.json
tools/perf/pmu-events/arch/x86/nehalemex/pipeline.json
tools/perf/pmu-events/arch/x86/nehalemex/virtual-memory.json
tools/perf/pmu-events/arch/x86/sandybridge/cache.json
tools/perf/pmu-events/arch/x86/sandybridge/floating-point.json
tools/perf/pmu-events/arch/x86/sandybridge/frontend.json
tools/perf/pmu-events/arch/x86/sandybridge/memory.json
tools/perf/pmu-events/arch/x86/sandybridge/other.json
tools/perf/pmu-events/arch/x86/sandybridge/pipeline.json
tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
tools/perf/pmu-events/arch/x86/sandybridge/virtual-memory.json
tools/perf/pmu-events/arch/x86/silvermont/cache.json
tools/perf/pmu-events/arch/x86/silvermont/frontend.json
tools/perf/pmu-events/arch/x86/silvermont/memory.json
tools/perf/pmu-events/arch/x86/silvermont/other.json
tools/perf/pmu-events/arch/x86/silvermont/pipeline.json
tools/perf/pmu-events/arch/x86/silvermont/virtual-memory.json
tools/perf/pmu-events/arch/x86/skylake/cache.json
tools/perf/pmu-events/arch/x86/skylake/floating-point.json
tools/perf/pmu-events/arch/x86/skylake/frontend.json
tools/perf/pmu-events/arch/x86/skylake/memory.json
tools/perf/pmu-events/arch/x86/skylake/other.json
tools/perf/pmu-events/arch/x86/skylake/pipeline.json
tools/perf/pmu-events/arch/x86/skylake/uncore.json
tools/perf/pmu-events/arch/x86/skylake/virtual-memory.json
tools/perf/pmu-events/arch/x86/skylakex/cache.json
tools/perf/pmu-events/arch/x86/skylakex/floating-point.json
tools/perf/pmu-events/arch/x86/skylakex/frontend.json
tools/perf/pmu-events/arch/x86/skylakex/memory.json
tools/perf/pmu-events/arch/x86/skylakex/other.json
tools/perf/pmu-events/arch/x86/skylakex/pipeline.json
tools/perf/pmu-events/arch/x86/skylakex/virtual-memory.json
tools/perf/pmu-events/arch/x86/westmereep-dp/cache.json
tools/perf/pmu-events/arch/x86/westmereep-dp/floating-point.json
tools/perf/pmu-events/arch/x86/westmereep-dp/frontend.json
tools/perf/pmu-events/arch/x86/westmereep-dp/memory.json
tools/perf/pmu-events/arch/x86/westmereep-dp/other.json
tools/perf/pmu-events/arch/x86/westmereep-dp/pipeline.json
tools/perf/pmu-events/arch/x86/westmereep-dp/virtual-memory.json
tools/perf/pmu-events/arch/x86/westmereep-sp/cache.json
tools/perf/pmu-events/arch/x86/westmereep-sp/floating-point.json
tools/perf/pmu-events/arch/x86/westmereep-sp/frontend.json
tools/perf/pmu-events/arch/x86/westmereep-sp/memory.json
tools/perf/pmu-events/arch/x86/westmereep-sp/other.json
tools/perf/pmu-events/arch/x86/westmereep-sp/pipeline.json
tools/perf/pmu-events/arch/x86/westmereep-sp/virtual-memory.json
tools/perf/pmu-events/arch/x86/westmereex/cache.json
tools/perf/pmu-events/arch/x86/westmereex/floating-point.json
tools/perf/pmu-events/arch/x86/westmereex/frontend.json
tools/perf/pmu-events/arch/x86/westmereex/memory.json
tools/perf/pmu-events/arch/x86/westmereex/other.json
tools/perf/pmu-events/arch/x86/westmereex/pipeline.json
tools/perf/pmu-events/arch/x86/westmereex/virtual-memory.json
tools/perf/scripts/python/bin/intel-pt-events-report
tools/power/cpupower/bench/cpufreq-bench_plot.sh
tools/power/cpupower/bench/cpufreq-bench_script.sh
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] serial: mctrl_gpio: Avoid probe failures in case of missing gpiolib
From: Fabio Estevam @ 2019-08-01 13:19 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, Geert Uytterhoeven,
Greg Kroah-Hartman, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, u.kleine-koenig@pengutronix.de,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190801124446.15703-1-frieder.schrempf@kontron.de>
Hi Schrempf,
On Thu, Aug 1, 2019 at 9:47 AM Schrempf Frieder
<frieder.schrempf@kontron.de> wrote:
>
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
> mctrl_gpio_init_noauto() will currently return an error pointer with
> -ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
> check for this condition to allow continue probing.
>
> To avoid the need for this check in each driver, we return NULL
> instead, as all the mctrl_gpio_*() functions are skipped anyway.
> We also adapt mctrl_gpio_to_gpiod() to be in line with this change.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Looks good to me:
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Also adding Geert on Cc as the patch touches sh-sci.
Thanks
> ---
> drivers/tty/serial/serial_mctrl_gpio.c | 3 +++
> drivers/tty/serial/serial_mctrl_gpio.h | 6 +++---
> drivers/tty/serial/sh-sci.c | 2 +-
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
> index 2b400189be91..54c43e02e375 100644
> --- a/drivers/tty/serial/serial_mctrl_gpio.c
> +++ b/drivers/tty/serial/serial_mctrl_gpio.c
> @@ -61,6 +61,9 @@ EXPORT_SYMBOL_GPL(mctrl_gpio_set);
> struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
> enum mctrl_gpio_idx gidx)
> {
> + if (gpios == NULL)
> + return NULL;
> +
> return gpios->gpio[gidx];
> }
> EXPORT_SYMBOL_GPL(mctrl_gpio_to_gpiod);
> diff --git a/drivers/tty/serial/serial_mctrl_gpio.h b/drivers/tty/serial/serial_mctrl_gpio.h
> index b7d3cca48ede..1b2ff503b2c2 100644
> --- a/drivers/tty/serial/serial_mctrl_gpio.h
> +++ b/drivers/tty/serial/serial_mctrl_gpio.h
> @@ -114,19 +114,19 @@ static inline
> struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
> enum mctrl_gpio_idx gidx)
> {
> - return ERR_PTR(-ENOSYS);
> + return NULL;
> }
>
> static inline
> struct mctrl_gpios *mctrl_gpio_init(struct uart_port *port, unsigned int idx)
> {
> - return ERR_PTR(-ENOSYS);
> + return NULL;
> }
>
> static inline
> struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
> {
> - return ERR_PTR(-ENOSYS);
> + return NULL;
> }
>
> static inline
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index d18c680aa64b..249325b65ee0 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -3287,7 +3287,7 @@ static int sci_probe_single(struct platform_device *dev,
> return ret;
>
> sciport->gpios = mctrl_gpio_init(&sciport->port, 0);
> - if (IS_ERR(sciport->gpios) && PTR_ERR(sciport->gpios) != -ENOSYS)
> + if (IS_ERR(sciport->gpios))
> return PTR_ERR(sciport->gpios);
>
> if (sciport->has_rtscts) {
> --
> 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v2 0/8] arm64: MMU enabled kexec relocation
From: Pavel Tatashin @ 2019-08-01 13:24 UTC (permalink / raw)
To: Pavel Tatashin, James Morris, Sasha Levin, Eric W. Biederman,
kexec mailing list, LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM, Marc Zyngier, James Morse,
Vladimir Murzin, Matthias Brugger, Bhupesh Sharma
In-Reply-To: <20190731153857.4045-1-pasha.tatashin@soleen.com>
I will send a new version soon, so please do not spend time reviewing
this work. In the new version I will fix MMU at EL2 issue by doing
what we are doing in hibernation: reduce to EL1 to do the copying, and
escalate back to to EL2 to branch to new kernel. Also, this will
simplify copying function by actually doing the linear copy as ttbr1
and ttbr0 are always available this way.
Thank you,
Pasha
On Wed, Jul 31, 2019 at 11:38 AM Pavel Tatashin
<pasha.tatashin@soleen.com> wrote:
>
> Changelog from previous RFC:
> - Added trans_table support for both hibernate and kexec.
> - Fixed performance issue, where enabling MMU did not yield the
> actual performance improvement.
>
> Bug:
> With the current state, this patch series works on kernels booted with EL1
> mode, but for some reason, when elevated to EL2 mode reboot freezes in
> both QEMU and on real hardware.
>
> The freeze happens in:
>
> arch/arm64/kernel/relocate_kernel.S
> turn_on_mmu()
>
> Right after sctlr_el2 is written (MMU on EL2 is enabled)
>
> msr sctlr_el2, \tmp1
>
> I've been studying all the relevant control registers for EL2, but do not
> see what might be causing this hang:
>
> MAIR_EL2 is set to be exactly the same as MAIR_EL1 0xbbff440c0400
>
> TCR_EL2 0x80843510
> Enabled bits:
> PS Physical Address Size. (0b100 44 bits, 16TB.)
> SH0 Shareability 11 Inner Shareable
> ORGN0 Normal memory, Outer Write-Back Read-Allocate Write-Allocate Cach.
> IRGN0 Normal memory, Inner Write-Back Read-Allocate Write-Allocate Cach.
> T0SZ 01 0000
>
> SCTLR_EL2 0x30e5183f
> RES1 : Reserve ones
> M : MMU enabled
> A : Align check
> C : Cacheability control
> SA : SP Alignment check enable
> IESB : Implicit Error Synchronization event
> I : Instruction access Cacheability
>
> TTBR0_EL2 0x1b3069000 (address of trans_table)
>
> Any suggestion of what else might be missing that causes this freeze when
> MMU is enabled in EL2?
>
> =====
> Here is the current data from the real hardware:
> (because of bug, I forced EL1 mode by setting el2_switch always to zero in
> cpu_soft_restart()):
>
> For this experiment, the size of kernel plus initramfs is 25M. If initramfs
> was larger, than the improvements would be even greater, as time spent in
> relocation is proportional to the size of relocation.
>
> Previously:
> kernel shutdown 0.022131328s
> relocation 0.440510736s
> kernel startup 0.294706768s
>
> Relocation was taking: 58.2% of reboot time
>
> Now:
> kernel shutdown 0.032066576s
> relocation 0.022158152s
> kernel startup 0.296055880s
>
> Now: Relocation takes 6.3% of reboot time
>
> Total reboot is x2.16 times faster.
>
> Previous approaches and discussions
> -----------------------------------
> https://lore.kernel.org/lkml/20190709182014.16052-1-pasha.tatashin@soleen.com
> reserve space for kexec to avoid relocation, involves changes to generic code
> to optimize a problem that exists on arm64 only:
>
> https://lore.kernel.org/lkml/20190716165641.6990-1-pasha.tatashin@soleen.com
> The first attempt to enable MMU, some bugs that prevented performance
> improvement. The page tables unnecessary configured idmap for the whole
> physical space.
>
> Pavel Tatashin (8):
> kexec: quiet down kexec reboot
> arm64, mm: transitional tables
> arm64: hibernate: switch to transtional page tables.
> kexec: add machine_kexec_post_load()
> arm64, kexec: move relocation function setup and clean up
> arm64, kexec: add expandable argument to relocation function
> arm64, kexec: configure transitional page table for kexec
> arm64, kexec: enable MMU during kexec relocation
>
> arch/arm64/Kconfig | 4 +
> arch/arm64/include/asm/kexec.h | 24 ++-
> arch/arm64/include/asm/pgtable-hwdef.h | 1 +
> arch/arm64/include/asm/trans_table.h | 66 ++++++
> arch/arm64/kernel/asm-offsets.c | 10 +
> arch/arm64/kernel/cpu-reset.S | 4 +-
> arch/arm64/kernel/cpu-reset.h | 8 +-
> arch/arm64/kernel/hibernate.c | 261 ++++++------------------
> arch/arm64/kernel/machine_kexec.c | 168 ++++++++++++---
> arch/arm64/kernel/relocate_kernel.S | 238 +++++++++++++++-------
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/trans_table.c | 272 +++++++++++++++++++++++++
> kernel/kexec.c | 4 +
> kernel/kexec_core.c | 8 +-
> kernel/kexec_file.c | 4 +
> kernel/kexec_internal.h | 2 +
> 16 files changed, 756 insertions(+), 319 deletions(-)
> create mode 100644 arch/arm64/include/asm/trans_table.h
> create mode 100644 arch/arm64/mm/trans_table.c
>
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/6] coresight: etm4x: use explicit barriers on enable/disable
From: Sasha Levin @ 2019-08-01 13:31 UTC (permalink / raw)
To: Sasha Levin, Andrew Murray, Mathieu Poirier; +Cc: stable, linux-arm-kernel
In-Reply-To: <20190730125157.884-3-andrew.murray@arm.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.2.4, v5.1.21, v4.19.62, v4.14.134, v4.9.186, v4.4.186.
v5.2.4: Build OK!
v5.1.21: Build OK!
v4.19.62: Failed to apply! Possible dependencies:
41a75cdde735 ("coresight: Convert driver messages to dev_dbg")
68a147752d04 ("coresight: etmx: Claim devices before use")
e006d89abedd ("coresight: etm4x: Add support for handling errors")
e2a1551a881f ("coresight: etm3: Add support for handling errors")
v4.14.134: Failed to apply! Possible dependencies:
41a75cdde735 ("coresight: Convert driver messages to dev_dbg")
68a147752d04 ("coresight: etmx: Claim devices before use")
e006d89abedd ("coresight: etm4x: Add support for handling errors")
e2a1551a881f ("coresight: etm3: Add support for handling errors")
v4.9.186: Failed to apply! Possible dependencies:
297ab90f15f6 ("coresight: tmc: Cleanup operation mode handling")
2cd541402829 ("coresight: tmc: minor fix for output log")
41a75cdde735 ("coresight: Convert driver messages to dev_dbg")
68a147752d04 ("coresight: etmx: Claim devices before use")
c38e505e2701 ("coresight: tmc: Get rid of mode parameter for helper routines")
e006d89abedd ("coresight: etm4x: Add support for handling errors")
e2a1551a881f ("coresight: etm3: Add support for handling errors")
v4.4.186: Failed to apply! Possible dependencies:
1925a470ce69 ("coresight: etm3x: splitting struct etm_drvdata")
2127154d115d ("coresight: etm3x: implementing user/kernel mode tracing")
22fd532eaa0c ("coresight: etm3x: adding operation mode for etm_enable()")
27b10da8fff2 ("coresight: etb10: moving to local atomic operations")
41a75cdde735 ("coresight: Convert driver messages to dev_dbg")
52210c8745e4 ("coresight: implementing 'cpu_id()' API")
68a147752d04 ("coresight: etmx: Claim devices before use")
882d5e112491 ("coresight: etm3x: implementing perf_enable/disable() API")
b3e94405941e ("coresight: associating path with session rather than tracer")
c04148e708c0 ("coresight: etm3x: moving sysFS entries to dedicated file")
c1f8e57c9e66 ("coresight: etm3x: moving etm_readl/writel to header file")
e2a1551a881f ("coresight: etm3: Add support for handling errors")
e827d4550aa3 ("coresight: etb10: adding operation mode for sink->enable()")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: vexpress: Add missing newline at end of file
From: Geert Uytterhoeven @ 2019-08-01 13:31 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Liviu Dudau, Linux ARM, Geert Uytterhoeven,
Linux Kernel Mailing List
In-Reply-To: <20190801131527.GA23424@e107155-lin>
Hi Sudeep,
On Thu, Aug 1, 2019 at 3:15 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Mon, Jun 17, 2019 at 04:35:47PM +0200, Geert Uytterhoeven wrote:
> > "git diff" says:
> >
> > \ No newline at end of file
> >
> > after modifying the file.
>
> Sorry for missing this earlier. Just found this unread and thought of
> applying it to v5.4
>
> However doing a quick check on the tree revealed more file and wonder
> why you are addressing only handful of them. Why not all in one go ?
I did address all of them, but sent separate patches per subsystem.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: vexpress: Add missing newline at end of file
From: Sudeep Holla @ 2019-08-01 13:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lorenzo Pieralisi, Geert Uytterhoeven, Liviu Dudau,
Linux Kernel Mailing List, Sudeep Holla, Linux ARM
In-Reply-To: <CAMuHMdX+Nd1XH0KDHXmdOa_=UYcBso_EKfugYbZ_Zyd=4e2nGw@mail.gmail.com>
On Thu, Aug 01, 2019 at 03:31:34PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Thu, Aug 1, 2019 at 3:15 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On Mon, Jun 17, 2019 at 04:35:47PM +0200, Geert Uytterhoeven wrote:
> > > "git diff" says:
> > >
> > > \ No newline at end of file
> > >
> > > after modifying the file.
> >
> > Sorry for missing this earlier. Just found this unread and thought of
> > applying it to v5.4
> >
> > However doing a quick check on the tree revealed more file and wonder
> > why you are addressing only handful of them. Why not all in one go ?
>
> I did address all of them, but sent separate patches per subsystem.
>
Ah OK, may be different mailing lists and hence I failed to see them.
Anyways queued this for v5.4. Thanks for the response.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC 0/9] dt-bindings: first tentative of conversion to yaml format
From: Neil Armstrong @ 2019-08-01 13:56 UTC (permalink / raw)
To: robh+dt
Cc: p.zabel, devicetree, linux-watchdog, Neil Armstrong,
jassisinghbrar, linux-spi, linux-crypto, linux-serial,
linux-amlogic, kishon, linux-arm-kernel
This is a first tentative to convert some of the simplest Amlogic
dt-bindings to the yaml format.
All have been tested using :
$ make ARCH=arm64 dtbs_check
Issues with the amlogic arm64 DTs has already been identified thanks
to the validation scripts. The DT fixes will be pushed once these yaml
bindings are acked.
Neil Armstrong (9):
dt-bindings: mailbox: meson-mhu: convert to yaml
dt-bindings: rng: amlogic,meson-rng: convert to yaml
dt-bindings: spi: meson: convert to yaml
dt-bindings: reset: amlogic,meson-reset: convert to yaml
dt-bindings: arm: amlogic: amlogic,meson-gx-ao-secure: convert to yaml
dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
dt-bindings: serial: meson-uart: convert to yaml
dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
.../amlogic/amlogic,meson-gx-ao-secure.txt | 28 -------
.../amlogic/amlogic,meson-gx-ao-secure.yaml | 42 +++++++++++
.../devicetree/bindings/mailbox/meson-mhu.txt | 34 ---------
.../bindings/mailbox/meson-mhu.yaml | 53 +++++++++++++
.../bindings/phy/meson-g12a-usb2-phy.txt | 22 ------
.../bindings/phy/meson-g12a-usb2-phy.yaml | 67 +++++++++++++++++
.../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 ------
.../phy/meson-g12a-usb3-pcie-phy.yaml | 61 +++++++++++++++
.../bindings/reset/amlogic,meson-reset.txt | 19 -----
.../bindings/reset/amlogic,meson-reset.yaml | 40 ++++++++++
.../bindings/rng/amlogic,meson-rng.txt | 21 ------
.../bindings/rng/amlogic,meson-rng.yaml | 37 +++++++++
.../bindings/serial/amlogic,meson-uart.txt | 38 ----------
.../bindings/serial/amlogic,meson-uart.yaml | 75 +++++++++++++++++++
.../bindings/spi/amlogic,meson-gx-spicc.yaml | 74 ++++++++++++++++++
.../bindings/spi/amlogic,meson6-spifc.yaml | 57 ++++++++++++++
.../devicetree/bindings/spi/spi-meson.txt | 55 --------------
.../bindings/watchdog/meson-gxbb-wdt.txt | 16 ----
.../bindings/watchdog/meson-gxbb-wdt.yaml | 37 +++++++++
19 files changed, 543 insertions(+), 255 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
delete mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
create mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
delete mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
delete mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-meson.txt
delete mode 100644 Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.yaml
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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