* [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Sinan Kaya @ 2018-05-16 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526495029-25783-1-git-send-email-okaya@codeaurora.org>
On 5/16/2018 2:23 PM, Sinan Kaya wrote:
> + if (win_start <= base && win_end >= base + win_size - 1) {
> + base += window->offset;
> + break;
> + }
I should probably add window->offset!=0 to the if statement in order not to
break non-translating case.
Any other comments?
--
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
* [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Timur Tabi @ 2018-05-16 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526495029-25783-1-git-send-email-okaya@codeaurora.org>
On 05/16/2018 01:23 PM, Sinan Kaya wrote:
> + win_start = window->res->start - window->offset;
Can you guarantee that window->res->start is always >= window->offset?
> + win_size = window->res->end - window->res->start + 1;
Use resource_size() instead.
--
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
* [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Sinan Kaya @ 2018-05-16 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3120434b-9831-bf33-25b8-11aba1c1b648@codeaurora.org>
On 5/16/2018 2:31 PM, Timur Tabi wrote:
> On 05/16/2018 01:23 PM, Sinan Kaya wrote:
>> +??????? win_start = window->res->start - window->offset;
>
> Can you guarantee that window->res->start is always >= window->offset?
>
Resource offset is generally 0 when not translating or a positive number
that you subtract from the resource start to reach to the translating window.
Having a bigger offset than resource start should be considered a BIOS bug.
>> +??????? win_size = window->res->end - window->res->start + 1;
>
> Use resource_size() instead.
>
I'll fix it.
--
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 v2] coresight: documentation: update sysfs section
From: Jonathan Corbet @ 2018-05-16 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514121959.a9a3d2fb3d3d270849ffbc39@arm.com>
On Mon, 14 May 2018 12:19:59 -0500
Kim Phillips <kim.phillips@arm.com> wrote:
> - Align and show updated ls devices output from the TC2, based on
> current driver
>
> - Provide an example from an ETMv4 based system (Juno)
>
> - Reflect changes to the way the RAM write pointer is accessed since
> it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
> management entries").
So I was going to apply this, but it's been pretty badly corrupted by
your mailer. Could I ask you to retry, please?
Thanks,
jon
^ permalink raw reply
* [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
From: Florian Fainelli @ 2018-05-16 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516043218.7ktq5vjq2rhcszz5@vireshk-i7>
On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> On 15-05-18, 20:49, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> Most CPUfreq drivers (at least on ARM) seem to be sorting the available
>> frequencies from lowest to highest. To match this behaviour, we reverse
>> the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
>> highest.
>
> The reasoning isn't correct. Just because everyone else is doing it
> doesn't make it right and so you shouldn't change just because of
> that.
>
> What you must written instead in the commit log is that the cpufreq
> core performs better if the table is sorted (in any order), and so we
> must sort it as well.
Is there a reason why set_freq_table_sorted() tries an ascending or
descending sort, but does not enforce one versus another for all drivers?
>
> But I feel the table is already sorted for your platform, isn't it?
> And I don't see a clear advantage of merging this patch.
The patch changes the order to have the lowest to highest, whereas the
current implementation has them from highest to lowest. From what you
are saying, it sounds like this is unnecessary, since the sorting is
already making things efficient enough, so this is just a cosmetic thing?
>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> ---
>> drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> index b07559b9ed99..7dac3205d3eb 100644
>> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> @@ -403,7 +403,7 @@ brcm_avs_get_freq_table(struct device *dev, struct private_data *priv)
>> {
>> struct cpufreq_frequency_table *table;
>> unsigned int pstate;
>> - int i, ret;
>> + int p, i, ret;
>>
>> /* Remember P-state for later */
>> ret = brcm_avs_get_pstate(priv, &pstate);
>> @@ -415,12 +415,13 @@ brcm_avs_get_freq_table(struct device *dev, struct private_data *priv)
>> if (!table)
>> return ERR_PTR(-ENOMEM);
>>
>> - for (i = AVS_PSTATE_P0; i <= AVS_PSTATE_MAX; i++) {
>> - ret = brcm_avs_set_pstate(priv, i);
>> + for (p = AVS_PSTATE_MAX, i = 0; p >= 0; p--, i++) {
>> + ret = brcm_avs_set_pstate(priv, p);
>> if (ret)
>> return ERR_PTR(ret);
>> table[i].frequency = brcm_avs_get_frequency(priv->base);
>> - table[i].driver_data = i;
>> + /* Store the corresponding P-state with each frequency */
>> + table[i].driver_data = p;
>> }
>> table[i].frequency = CPUFREQ_TABLE_END;
>>
>> --
>> 2.7.4
>
--
Florian
^ permalink raw reply
* [PATCH v2 3/4] coresight: allow to build as modules
From: Kim Phillips @ 2018-05-16 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3826d737-c180-7b9e-8013-be54f6d7302d@infradead.org>
Allow to build coresight as modules. This greatly enhances developer
efficiency by allowing the development to take place exclusively on the
target, and without needing to reboot in between changes.
- Kconfig bools become tristates, to allow =m
- MODULE_* macros added: Please correct me if I'm wrong:
- assume LICENSE is "GPL v2"
- tried to get as close to original authors for MODULE_AUTHOR
- The 'select' Kconfig statements are replaced with 'depends on'
clauses, to specify the dependencies between the modules including
other fixes, e.g., coresight-stm unconditionally calls
stm_register_device, it therefore depends on STM.
- use -objs to denote merge object directives in Makefile, adds a
coresight-core nomenclature for the base module.
- add a coresight_exit() that unregisters the coresight bus, add remove
fns for most others.
- fix up modules with ID tables for autoloading on boot, add missing
__exit attributes
- move coresight_vpid_to_pid to an externed, single instance in
coresight-core, to be used by all submodules.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
Changes from v1:
- remove depends on coresight that are in the if CORESIGHT block
(Randy Dunlap)
- actually call tmc_read_unprepare() in tmc_remove() this time,
instead of open-coding the kfree, dma_free_coherent calls.
- rebased and removed coresight_vpid_to_pid relocation on this
new series this patch now depends on:
https://www.spinics.net/lists/arm-kernel/msg652755.html
That new series eliminates patch 2/4 from this series (patches
1 and 4 of this series remain the same).
Changes from versions previous to v1, sent only to coresight mailing
list:
- tmc_remove: free buffer used by TMC-ETR and TMC-ETF by calling
tmc_read_unprepare()
- fixed an unbalanced pm_runtime_enable in coresight-replicator
- etm[4]_remove(): call cpuhp_remove_state_nocalls() and
etm_perf_symlink(.., false) to clear up cpuhp and symlink state
- add module parent checks for all enable/disable functions, source
and sink modules
- refactored device ptr dereferences by introducing a new parent_dev
variable
- corrected replicator author
- whitespace fix in funnel driver
- added user Kconfig help text with the names of the modules.
- Addressed Mathieu's comments:
- renamed coresight-link-sink-tmc coresight-tmc-core
- prevent ability to crash the system by removing drivers from an
active path by adding try_module_get() and module_put() calls in
funnel and replicator drivers' enable and disable functions (thanks for
figuring that out, Mathieu).
- Addressed most of Mathieu's comments:
- rm __inits causing linker section mismatch errors
- barrier_pkt made static, moved to coresight_priv.h
- rm unnecessary tmc_* EXPORT_SYMBOL leftovers
- add some missing MODULE_AUTHORs
drivers/hwtracing/coresight/Kconfig | 60 +++++++++++++------
drivers/hwtracing/coresight/Makefile | 28 ++++++---
.../hwtracing/coresight/coresight-cpu-debug.c | 2 +
.../coresight/coresight-dynamic-replicator.c | 30 +++++++++-
drivers/hwtracing/coresight/coresight-etb10.c | 32 +++++++++-
.../hwtracing/coresight/coresight-etm-cp14.c | 4 ++
.../hwtracing/coresight/coresight-etm-perf.c | 13 +++-
.../hwtracing/coresight/coresight-etm-perf.h | 2 +-
.../coresight/coresight-etm3x-sysfs.c | 6 ++
drivers/hwtracing/coresight/coresight-etm3x.c | 37 +++++++++++-
.../coresight/coresight-etm4x-sysfs.c | 6 ++
drivers/hwtracing/coresight/coresight-etm4x.c | 38 +++++++++++-
.../hwtracing/coresight/coresight-funnel.c | 30 +++++++++-
drivers/hwtracing/coresight/coresight-priv.h | 10 +++-
.../coresight/coresight-replicator.c | 33 +++++++++-
drivers/hwtracing/coresight/coresight-stm.c | 27 ++++++++-
.../hwtracing/coresight/coresight-tmc-etf.c | 2 +
.../hwtracing/coresight/coresight-tmc-etr.c | 2 +
drivers/hwtracing/coresight/coresight-tmc.c | 22 ++++++-
drivers/hwtracing/coresight/coresight-tpiu.c | 31 +++++++++-
drivers/hwtracing/coresight/coresight.c | 26 +++++---
include/linux/coresight.h | 2 +-
22 files changed, 380 insertions(+), 63 deletions(-)
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c164e1..c1e782d4c217 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -2,8 +2,8 @@
# Coresight configuration
#
menuconfig CORESIGHT
- bool "CoreSight Tracing Support"
- select ARM_AMBA
+ tristate "CoreSight Tracing Support"
+ depends on ARM_AMBA
select PERF_EVENTS
help
This framework provides a kernel interface for the CoreSight debug
@@ -12,17 +12,23 @@ menuconfig CORESIGHT
specification and configure the right series of components when a
trace source gets enabled.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-core.
+
if CORESIGHT
config CORESIGHT_LINKS_AND_SINKS
- bool "CoreSight Link and Sink drivers"
+ tristate "CoreSight Link and Sink drivers"
help
This enables support for CoreSight link and sink drivers that are
responsible for transporting and collecting the trace data
respectively. Link and sinks are dynamically aggregated with a trace
entity at run time to form a complete trace path.
+ To compile this code as modules, choose M here: the
+ modules will be called coresight-funnel and coresight-replicator.
+
config CORESIGHT_LINK_AND_SINK_TMC
- bool "Coresight generic TMC driver"
+ tristate "Coresight generic TMC driver"
depends on CORESIGHT_LINKS_AND_SINKS
help
This enables support for the Trace Memory Controller driver.
@@ -31,8 +37,11 @@ config CORESIGHT_LINK_AND_SINK_TMC
complies with the generic implementation of the component without
special enhancement or added features.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-tmc-core.
+
config CORESIGHT_SINK_TPIU
- bool "Coresight generic TPIU driver"
+ tristate "Coresight generic TPIU driver"
depends on CORESIGHT_LINKS_AND_SINKS
help
This enables support for the Trace Port Interface Unit driver,
@@ -42,56 +51,70 @@ config CORESIGHT_SINK_TPIU
connected to an external host for use case capturing more traces than
the on-board coresight memory can handle.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-tpiu.
+
config CORESIGHT_SINK_ETBV10
- bool "Coresight ETBv1.0 driver"
+ tristate "Coresight ETBv1.0 driver"
depends on CORESIGHT_LINKS_AND_SINKS
help
This enables support for the Embedded Trace Buffer version 1.0 driver
that complies with the generic implementation of the component without
special enhancement or added features.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-etb10.
+
config CORESIGHT_SOURCE_ETM3X
- bool "CoreSight Embedded Trace Macrocell 3.x driver"
- depends on !ARM64
- select CORESIGHT_LINKS_AND_SINKS
+ tristate "CoreSight Embedded Trace Macrocell 3.x driver"
+ depends on !ARM64 && CORESIGHT_LINKS_AND_SINKS
help
This driver provides support for processor ETM3.x and PTM1.x modules,
which allows tracing the instructions that a processor is executing
This is primarily useful for instruction level tracing. Depending
the ETM version data tracing may also be available.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-etm3x-core.
+
config CORESIGHT_SOURCE_ETM4X
- bool "CoreSight Embedded Trace Macrocell 4.x driver"
- depends on ARM64
- select CORESIGHT_LINKS_AND_SINKS
+ tristate "CoreSight Embedded Trace Macrocell 4.x driver"
+ depends on ARM64 && CORESIGHT_LINKS_AND_SINKS
help
This driver provides support for the ETM4.x tracer module, tracing the
instructions that a processor is executing. This is primarily useful
for instruction level tracing. Depending on the implemented version
data tracing may also be available.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-etm4x-core.
+
config CORESIGHT_DYNAMIC_REPLICATOR
- bool "CoreSight Programmable Replicator driver"
+ tristate "CoreSight Programmable Replicator driver"
depends on CORESIGHT_LINKS_AND_SINKS
help
This enables support for dynamic CoreSight replicator link driver.
The programmable ATB replicator allows independent filtering of the
trace data based on the traceid.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-dynamic-replicator.
+
config CORESIGHT_STM
- bool "CoreSight System Trace Macrocell driver"
+ tristate "CoreSight System Trace Macrocell driver"
depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
- select CORESIGHT_LINKS_AND_SINKS
- select STM
+ depends on STM && CORESIGHT_LINKS_AND_SINKS
help
This driver provides support for hardware assisted software
instrumentation based tracing. This is primarily used for
logging useful software events or data coming from various entities
in the system, possibly running different OSs
+ To compile this code as a module, choose M here: the
+ module will be called coresight-stm.
+
config CORESIGHT_CPU_DEBUG
tristate "CoreSight CPU Debug driver"
- depends on ARM || ARM64
depends on DEBUG_FS
help
This driver provides support for coresight debugging module. This
@@ -103,4 +126,7 @@ config CORESIGHT_CPU_DEBUG
properly, please refer Documentation/trace/coresight-cpu-debug.txt
for detailed description and the example for usage.
+ To compile this code as a module, choose M here: the
+ module will be called coresight-cpu-debug.
+
endif
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 61db9dd0d571..5990710289c2 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -2,19 +2,29 @@
#
# Makefile for CoreSight drivers.
#
-obj-$(CONFIG_CORESIGHT) += coresight.o coresight-etm-perf.o
-obj-$(CONFIG_OF) += of_coresight.o
-obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o \
- coresight-tmc-etf.o \
- coresight-tmc-etr.o
+obj-$(CONFIG_CORESIGHT) += coresight-core.o
+coresight-core-objs := coresight.o \
+ of_coresight.o
+
+obj-$(CONFIG_CORESIGHT) += coresight-etm-perf.o
+
+obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc-core.o
+coresight-tmc-core-objs := coresight-tmc.o \
+ coresight-tmc-etf.o \
+ coresight-tmc-etr.o
obj-$(CONFIG_CORESIGHT_SINK_TPIU) += coresight-tpiu.o
obj-$(CONFIG_CORESIGHT_SINK_ETBV10) += coresight-etb10.o
obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
coresight-replicator.o
-obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o \
- coresight-etm3x-sysfs.o
-obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
- coresight-etm4x-sysfs.o
+
+obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x-core.o
+coresight-etm3x-core-objs := coresight-etm3x.o \
+ coresight-etm-cp14.o \
+ coresight-etm3x-sysfs.o
+
+obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x-core.o
+coresight-etm4x-core-objs := coresight-etm4x.o coresight-etm4x-sysfs.o
+
obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
index 45b2460f3166..1efe9626eb6c 100644
--- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -671,6 +671,8 @@ static const struct amba_id debug_ids[] = {
{ 0, 0 },
};
+MODULE_DEVICE_TABLE(amba, debug_ids);
+
static struct amba_driver debug_driver = {
.drv = {
.name = "coresight-cpu-debug",
diff --git a/drivers/hwtracing/coresight/coresight-dynamic-replicator.c b/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
index f6d0571ab9dd..bc42b8022556 100644
--- a/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
@@ -37,7 +37,12 @@ struct replicator_state {
static int replicator_enable(struct coresight_device *csdev, int inport,
int outport)
{
- struct replicator_state *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct replicator_state *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
CS_UNLOCK(drvdata->base);
@@ -63,7 +68,9 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
static void replicator_disable(struct coresight_device *csdev, int inport,
int outport)
{
- struct replicator_state *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct replicator_state *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
CS_UNLOCK(drvdata->base);
@@ -75,6 +82,7 @@ static void replicator_disable(struct coresight_device *csdev, int inport,
CS_LOCK(drvdata->base);
+ module_put(module);
dev_info(drvdata->dev, "REPLICATOR disabled\n");
}
@@ -159,6 +167,15 @@ static int replicator_probe(struct amba_device *adev, const struct amba_id *id)
return PTR_ERR_OR_ZERO(drvdata->csdev);
}
+static int __exit replicator_remove(struct amba_device *adev)
+{
+ struct replicator_state *drvdata = dev_get_drvdata(&adev->dev);
+
+ coresight_unregister(drvdata->csdev);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int replicator_runtime_suspend(struct device *dev)
{
@@ -200,6 +217,8 @@ static const struct amba_id replicator_ids[] = {
{ 0, 0 },
};
+MODULE_DEVICE_TABLE(amba, replicator_ids);
+
static struct amba_driver replicator_driver = {
.drv = {
.name = "coresight-dynamic-replicator",
@@ -207,6 +226,11 @@ static struct amba_driver replicator_driver = {
.suppress_bind_attrs = true,
},
.probe = replicator_probe,
+ .remove = replicator_remove,
.id_table = replicator_ids,
};
-builtin_amba_driver(replicator_driver);
+module_amba_driver(replicator_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_DESCRIPTION("ARM Coresight Dynamic Replicator Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 9b6c55523c58..8825a3e4e47a 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -135,7 +135,12 @@ static int etb_enable(struct coresight_device *csdev, u32 mode)
{
u32 val;
unsigned long flags;
- struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct etb_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
val = local_cmpxchg(&drvdata->mode,
CS_MODE_DISABLED, mode);
@@ -256,7 +261,9 @@ static void etb_dump_hw(struct etb_drvdata *drvdata)
static void etb_disable(struct coresight_device *csdev)
{
- struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct etb_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
unsigned long flags;
spin_lock_irqsave(&drvdata->spinlock, flags);
@@ -266,6 +273,7 @@ static void etb_disable(struct coresight_device *csdev)
local_set(&drvdata->mode, CS_MODE_DISABLED);
+ module_put(module);
dev_info(drvdata->dev, "ETB disabled\n");
}
@@ -712,6 +720,16 @@ static int etb_probe(struct amba_device *adev, const struct amba_id *id)
return ret;
}
+static int __exit etb_remove(struct amba_device *adev)
+{
+ struct etb_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+
+ misc_deregister(&drvdata->miscdev);
+ coresight_unregister(drvdata->csdev);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int etb_runtime_suspend(struct device *dev)
{
@@ -746,6 +764,8 @@ static const struct amba_id etb_ids[] = {
{ 0, 0},
};
+MODULE_DEVICE_TABLE(amba, etb_ids);
+
static struct amba_driver etb_driver = {
.drv = {
.name = "coresight-etb10",
@@ -755,6 +775,12 @@ static struct amba_driver etb_driver = {
},
.probe = etb_probe,
+ .remove = etb_remove,
.id_table = etb_ids,
};
-builtin_amba_driver(etb_driver);
+module_amba_driver(etb_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("Arm CoreSight Embedded Trace Buffer driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-etm-cp14.c b/drivers/hwtracing/coresight/coresight-etm-cp14.c
index 4174a8d355d2..68ca423aa088 100644
--- a/drivers/hwtracing/coresight/coresight-etm-cp14.c
+++ b/drivers/hwtracing/coresight/coresight-etm-cp14.c
@@ -582,3 +582,7 @@ int etm_writel_cp14(u32 reg, u32 val)
return 0;
}
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_DESCRIPTION("Arm CoreSight ETM CP14 driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 677695635211..feb287083ba5 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -466,6 +466,7 @@ int etm_perf_symlink(struct coresight_device *csdev, bool link)
return 0;
}
+EXPORT_SYMBOL_GPL(etm_perf_symlink);
static int __init etm_perf_init(void)
{
@@ -493,4 +494,14 @@ static int __init etm_perf_init(void)
return ret;
}
-device_initcall(etm_perf_init);
+module_init(etm_perf_init);
+
+static void __exit etm_perf_exit(void)
+{
+ perf_pmu_unregister(&etm_pmu);
+}
+module_exit(etm_perf_exit);
+
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("Arm CoreSight tracer perf driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index 4197df4faf5e..539b250df455 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -43,7 +43,7 @@ struct etm_filters {
};
-#ifdef CONFIG_CORESIGHT
+#if IS_ENABLED(CONFIG_CORESIGHT)
int etm_perf_symlink(struct coresight_device *csdev, bool link);
#else
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 75487b3fad86..84fa5e0fe07b 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -7,6 +7,7 @@
#include <linux/pid_namespace.h>
#include <linux/pm_runtime.h>
#include <linux/sysfs.h>
+#include <linux/coresight.h>
#include "coresight-etm.h"
#include "coresight-priv.h"
@@ -1294,3 +1295,8 @@ const struct attribute_group *coresight_etm_groups[] = {
&coresight_etm_mgmt_group,
NULL,
};
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace sysfs driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 7c74263c333d..a2357b26b3a2 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -514,7 +514,12 @@ static int etm_enable(struct coresight_device *csdev,
{
int ret;
u32 val;
- struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct etm_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode);
@@ -611,7 +616,9 @@ static void etm_disable(struct coresight_device *csdev,
struct perf_event *event)
{
u32 mode;
- struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct etm_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
/*
* For as long as the tracer isn't disabled another entity can't
@@ -636,6 +643,8 @@ static void etm_disable(struct coresight_device *csdev,
if (mode)
local_set(&drvdata->mode, CS_MODE_DISABLED);
+
+ module_put(module);
}
static const struct coresight_ops_source etm_source_ops = {
@@ -864,6 +873,20 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
return ret;
}
+static int __exit etm_remove(struct amba_device *adev)
+{
+ struct etm_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+
+ etm_perf_symlink(drvdata->csdev, false);
+
+ cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
+ cpuhp_remove_state_nocalls(hp_online);
+
+ coresight_unregister(drvdata->csdev);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int etm_runtime_suspend(struct device *dev)
{
@@ -924,6 +947,8 @@ static const struct amba_id etm_ids[] = {
{ 0, 0},
};
+MODULE_DEVICE_TABLE(amba, etm_ids);
+
static struct amba_driver etm_driver = {
.drv = {
.name = "coresight-etm3x",
@@ -932,6 +957,12 @@ static struct amba_driver etm_driver = {
.suppress_bind_attrs = true,
},
.probe = etm_probe,
+ .remove = etm_remove,
.id_table = etm_ids,
};
-builtin_amba_driver(etm_driver);
+module_amba_driver(etm_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
index a0365e23678e..9194184123ae 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
@@ -7,6 +7,7 @@
#include <linux/pid_namespace.h>
#include <linux/pm_runtime.h>
#include <linux/sysfs.h>
+#include <linux/coresight.h>
#include "coresight-etm4x.h"
#include "coresight-priv.h"
@@ -2173,3 +2174,8 @@ const struct attribute_group *coresight_etmv4_groups[] = {
&coresight_etmv4_trcidr_group,
NULL,
};
+EXPORT_SYMBOL_GPL(coresight_etmv4_groups);
+
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace v4 sysfs driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 9bc04c50d45b..a6ff152ab61d 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -280,7 +280,12 @@ static int etm4_enable(struct coresight_device *csdev,
{
int ret;
u32 val;
- struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode);
@@ -387,7 +392,9 @@ static void etm4_disable(struct coresight_device *csdev,
struct perf_event *event)
{
u32 mode;
- struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
/*
* For as long as the tracer isn't disabled another entity can't
@@ -409,6 +416,8 @@ static void etm4_disable(struct coresight_device *csdev,
if (mode)
local_set(&drvdata->mode, CS_MODE_DISABLED);
+
+ module_put(module);
}
static const struct coresight_ops_source etm4_source_ops = {
@@ -1045,6 +1054,20 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
return ret;
}
+static int __exit etm4_remove(struct amba_device *adev)
+{
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+
+ etm_perf_symlink(drvdata->csdev, false);
+
+ cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
+ cpuhp_remove_state_nocalls(hp_online);
+
+ coresight_unregister(drvdata->csdev);
+
+ return 0;
+}
+
static const struct amba_id etm4_ids[] = {
{ /* ETM 4.0 - Cortex-A53 */
.id = 0x000bb95d,
@@ -1064,12 +1087,21 @@ static const struct amba_id etm4_ids[] = {
{ 0, 0},
};
+MODULE_DEVICE_TABLE(amba, etm4_ids);
+
static struct amba_driver etm4x_driver = {
.drv = {
.name = "coresight-etm4x",
+ .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = etm4_probe,
+ .remove = etm4_remove,
.id_table = etm4_ids,
};
-builtin_amba_driver(etm4x_driver);
+module_amba_driver(etm4x_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace v4 driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 448145a36675..c355a66bcc51 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -61,7 +61,12 @@ static void funnel_enable_hw(struct funnel_drvdata *drvdata, int port)
static int funnel_enable(struct coresight_device *csdev, int inport,
int outport)
{
- struct funnel_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct funnel_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
funnel_enable_hw(drvdata, inport);
@@ -85,10 +90,13 @@ static void funnel_disable_hw(struct funnel_drvdata *drvdata, int inport)
static void funnel_disable(struct coresight_device *csdev, int inport,
int outport)
{
- struct funnel_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct funnel_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
funnel_disable_hw(drvdata, inport);
+ module_put(module);
dev_info(drvdata->dev, "FUNNEL inport %d disabled\n", inport);
}
@@ -211,6 +219,15 @@ static int funnel_probe(struct amba_device *adev, const struct amba_id *id)
return PTR_ERR_OR_ZERO(drvdata->csdev);
}
+static int __exit funnel_remove(struct amba_device *adev)
+{
+ struct funnel_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+
+ coresight_unregister(drvdata->csdev);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int funnel_runtime_suspend(struct device *dev)
{
@@ -250,6 +267,8 @@ static const struct amba_id funnel_ids[] = {
{ 0, 0},
};
+MODULE_DEVICE_TABLE(amba, funnel_ids);
+
static struct amba_driver funnel_driver = {
.drv = {
.name = "coresight-funnel",
@@ -258,6 +277,11 @@ static struct amba_driver funnel_driver = {
.suppress_bind_attrs = true,
},
.probe = funnel_probe,
+ .remove = funnel_remove,
.id_table = funnel_ids,
};
-builtin_amba_driver(funnel_driver);
+module_amba_driver(funnel_driver);
+
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("ARM Coresight Funnel Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 0e5a74dae6a6..896958c2dd44 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -57,7 +57,13 @@ static DEVICE_ATTR_RO(name)
#define coresight_simple_reg64(type, name, lo_off, hi_off) \
__coresight_simple_func(type, NULL, name, lo_off, hi_off)
-extern const u32 barrier_pkt[5];
+/*
+ * When losing synchronisation a new barrier packet needs to be inserted at the
+ * beginning of the data collected in a buffer. That way the decoder knows that
+ * it needs to look for another sync sequence.
+ */
+static const u32 barrier_pkt[5] = {0x7fffffff, 0x7fffffff,
+ 0x7fffffff, 0x7fffffff, 0x0};
enum etm_addr_type {
ETM_ADDR_TYPE_NONE,
@@ -136,7 +142,7 @@ struct list_head *coresight_build_path(struct coresight_device *csdev,
struct coresight_device *sink);
void coresight_release_path(struct list_head *path);
-#ifdef CONFIG_CORESIGHT_SOURCE_ETM3X
+#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
extern int etm_readl_cp14(u32 off, unsigned int *val);
extern int etm_writel_cp14(u32 off, u32 val);
#else
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 8d2eaaab6c2f..6f16dcd7e107 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -33,7 +33,12 @@ struct replicator_drvdata {
static int replicator_enable(struct coresight_device *csdev, int inport,
int outport)
{
- struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct replicator_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
dev_info(drvdata->dev, "REPLICATOR enabled\n");
return 0;
@@ -42,8 +47,11 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
static void replicator_disable(struct coresight_device *csdev, int inport,
int outport)
{
- struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct replicator_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+ module_put(module);
dev_info(drvdata->dev, "REPLICATOR disabled\n");
}
@@ -112,6 +120,17 @@ static int replicator_probe(struct platform_device *pdev)
return ret;
}
+static int __exit replicator_remove(struct platform_device *pdev)
+{
+ struct replicator_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+ coresight_unregister(drvdata->csdev);
+
+ pm_runtime_disable(&pdev->dev);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int replicator_runtime_suspend(struct device *dev)
{
@@ -144,8 +163,11 @@ static const struct of_device_id replicator_match[] = {
{}
};
+MODULE_DEVICE_TABLE(of, replicator_match);
+
static struct platform_driver replicator_driver = {
.probe = replicator_probe,
+ .remove = replicator_remove,
.driver = {
.name = "coresight-replicator",
.of_match_table = replicator_match,
@@ -153,4 +175,9 @@ static struct platform_driver replicator_driver = {
.suppress_bind_attrs = true,
},
};
-builtin_platform_driver(replicator_driver);
+module_platform_driver(replicator_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("ARM Coresight Replicator Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index c46c70aec1d5..9997ba0dbd54 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -194,7 +194,12 @@ static int stm_enable(struct coresight_device *csdev,
struct perf_event *event, u32 mode)
{
u32 val;
- struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct stm_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
if (mode != CS_MODE_SYSFS)
return -EINVAL;
@@ -882,6 +887,17 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
return ret;
}
+static int __exit stm_remove(struct amba_device *adev)
+{
+ struct stm_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+
+ coresight_unregister(drvdata->csdev);
+
+ stm_unregister_device(&drvdata->stm);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int stm_runtime_suspend(struct device *dev)
{
@@ -922,6 +938,8 @@ static const struct amba_id stm_ids[] = {
{ 0, 0},
};
+MODULE_DEVICE_TABLE(amba, stm_ids);
+
static struct amba_driver stm_driver = {
.drv = {
.name = "coresight-stm",
@@ -930,7 +948,12 @@ static struct amba_driver stm_driver = {
.suppress_bind_attrs = true,
},
.probe = stm_probe,
+ .remove = stm_remove,
.id_table = stm_ids,
};
-builtin_amba_driver(stm_driver);
+module_amba_driver(stm_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_DESCRIPTION("Arm CoreSight System Trace Macrocell driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 61d849b11c26..168b2c41632d 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -617,3 +617,5 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
return 0;
}
+
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 02f747afa2ba..24a5fd4be4cd 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -330,3 +330,5 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
return 0;
}
+
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index 456f122df74f..eb3cdb832f84 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -429,6 +429,19 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
return ret;
}
+static int __exit tmc_remove(struct amba_device *adev)
+{
+ struct tmc_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+
+ /* free ETB/ETF or ETR memory */
+ tmc_read_unprepare(drvdata);
+
+ misc_deregister(&drvdata->miscdev);
+ coresight_unregister(drvdata->csdev);
+
+ return 0;
+}
+
static const struct amba_id tmc_ids[] = {
{
.id = 0x000bb961,
@@ -453,6 +466,8 @@ static const struct amba_id tmc_ids[] = {
{ 0, 0},
};
+MODULE_DEVICE_TABLE(amba, tmc_ids);
+
static struct amba_driver tmc_driver = {
.drv = {
.name = "coresight-tmc",
@@ -460,6 +475,11 @@ static struct amba_driver tmc_driver = {
.suppress_bind_attrs = true,
},
.probe = tmc_probe,
+ .remove = tmc_remove,
.id_table = tmc_ids,
};
-builtin_amba_driver(tmc_driver);
+module_amba_driver(tmc_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_DESCRIPTION("Arm CoreSight Trace Memory Controller driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 01b7457fe8fc..9622f2a5a451 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -69,7 +69,12 @@ static void tpiu_enable_hw(struct tpiu_drvdata *drvdata)
static int tpiu_enable(struct coresight_device *csdev, u32 mode)
{
- struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct tpiu_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
+
+ if (!try_module_get(module))
+ return -ENODEV;
tpiu_enable_hw(drvdata);
@@ -95,10 +100,13 @@ static void tpiu_disable_hw(struct tpiu_drvdata *drvdata)
static void tpiu_disable(struct coresight_device *csdev)
{
- struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct device *parent_dev = csdev->dev.parent;
+ struct tpiu_drvdata *drvdata = dev_get_drvdata(parent_dev);
+ struct module *module = parent_dev->driver->owner;
tpiu_disable_hw(drvdata);
+ module_put(module);
dev_info(drvdata->dev, "TPIU disabled\n");
}
@@ -164,6 +172,15 @@ static int tpiu_probe(struct amba_device *adev, const struct amba_id *id)
return PTR_ERR_OR_ZERO(drvdata->csdev);
}
+static int __exit tpiu_remove(struct amba_device *adev)
+{
+ struct tpiu_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+
+ coresight_unregister(drvdata->csdev);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int tpiu_runtime_suspend(struct device *dev)
{
@@ -207,6 +224,8 @@ static const struct amba_id tpiu_ids[] = {
{ 0, 0},
};
+MODULE_DEVICE_TABLE(amba, tpiu_ids);
+
static struct amba_driver tpiu_driver = {
.drv = {
.name = "coresight-tpiu",
@@ -215,6 +234,12 @@ static struct amba_driver tpiu_driver = {
.suppress_bind_attrs = true,
},
.probe = tpiu_probe,
+ .remove = tpiu_remove,
.id_table = tpiu_ids,
};
-builtin_amba_driver(tpiu_driver);
+module_amba_driver(tpiu_driver);
+
+MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("Arm CoreSight TPIU (Trace Port Interface Unit) driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 29e834aab539..c00229b0db52 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -46,14 +46,6 @@ static DEFINE_PER_CPU(struct list_head *, tracer_path);
*/
static struct list_head *stm_path;
-/*
- * When losing synchronisation a new barrier packet needs to be inserted at the
- * beginning of the data collected in a buffer. That way the decoder knows that
- * it needs to look for another sync sequence.
- */
-const u32 barrier_pkt[5] = {0x7fffffff, 0x7fffffff,
- 0x7fffffff, 0x7fffffff, 0x0};
-
static int coresight_id_match(struct device *dev, void *data)
{
int trace_id, i_trace_id;
@@ -310,6 +302,7 @@ void coresight_disable_path(struct list_head *path)
}
}
}
+EXPORT_SYMBOL_GPL(coresight_disable_path);
int coresight_enable_path(struct list_head *path, u32 mode)
{
@@ -361,6 +354,7 @@ int coresight_enable_path(struct list_head *path, u32 mode)
coresight_disable_path(path);
goto out;
}
+EXPORT_SYMBOL_GPL(coresight_enable_path);
struct coresight_device *coresight_get_sink(struct list_head *path)
{
@@ -376,6 +370,7 @@ struct coresight_device *coresight_get_sink(struct list_head *path)
return csdev;
}
+EXPORT_SYMBOL_GPL(coresight_get_sink);
static int coresight_enabled_sink(struct device *dev, void *data)
{
@@ -400,6 +395,7 @@ static int coresight_enabled_sink(struct device *dev, void *data)
return 0;
}
+EXPORT_SYMBOL_GPL(coresight_enabled_sink);
/**
* coresight_get_enabled_sink - returns the first enabled sink found on the bus
@@ -422,6 +418,7 @@ struct coresight_device *coresight_get_enabled_sink(bool deactivate)
return dev ? to_coresight_device(dev) : NULL;
}
+EXPORT_SYMBOL_GPL(coresight_get_enabled_sink);
/**
* _coresight_build_path - recursively build a path from a @csdev to a sink.
@@ -501,6 +498,7 @@ struct list_head *coresight_build_path(struct coresight_device *source,
return path;
}
+EXPORT_SYMBOL_GPL(coresight_build_path);
/**
* coresight_release_path - release a previously built path.
@@ -525,6 +523,7 @@ void coresight_release_path(struct list_head *path)
kfree(path);
path = NULL;
}
+EXPORT_SYMBOL_GPL(coresight_release_path);
/** coresight_validate_source - make sure a source has the right credentials
* @csdev: the device structure for a source.
@@ -941,6 +940,7 @@ int coresight_timeout(void __iomem *addr, u32 offset, int position, int value)
return -EAGAIN;
}
+EXPORT_SYMBOL_GPL(coresight_timeout);
struct bus_type coresight_bustype = {
.name = "coresight",
@@ -952,6 +952,12 @@ static int __init coresight_init(void)
}
postcore_initcall(coresight_init);
+static void __exit coresight_exit(void)
+{
+ bus_unregister(&coresight_bustype);
+}
+module_exit(coresight_exit);
+
struct coresight_device *coresight_register(struct coresight_desc *desc)
{
int i;
@@ -1049,3 +1055,7 @@ void coresight_unregister(struct coresight_device *csdev)
device_unregister(&csdev->dev);
}
EXPORT_SYMBOL_GPL(coresight_unregister);
+
+MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
+MODULE_DESCRIPTION("ARM Coresight Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index e5421b83e4e6..548fa56b29bd 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -236,7 +236,7 @@ struct coresight_ops {
const struct coresight_ops_source *source_ops;
};
-#ifdef CONFIG_CORESIGHT
+#if IS_ENABLED(CONFIG_CORESIGHT)
extern struct coresight_device *
coresight_register(struct coresight_desc *desc);
extern void coresight_unregister(struct coresight_device *csdev);
--
2.17.0
^ permalink raw reply related
* [PATCH RFC 3/6] hwmon: Add support for RPi voltage sensor
From: Stefan Wahren @ 2018-05-16 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516182144.GB22705@roeck-us.net>
Hi Guenter,
> Guenter Roeck <linux@roeck-us.net> hat am 16. Mai 2018 um 20:21 geschrieben:
>
>
> On Wed, May 16, 2018 at 03:37:04PM +0200, Stefan Wahren wrote:
> > Currently there is no easy way to detect under-voltage conditions on a remote
> > Raspberry Pi. This hwmon driver retrieves the state of the under-voltage sensor
> > via mailbox interface. The handling based on Noralf's modifications to the
> > downstream firmware driver. In case of an under-voltage condition only an entry
> > is written to the kernel log.
> >
>
> My major concern is how this is displayed with the 'sensors' command.
> Can you test and report ?
I get the following output:
rpi_volt-isa-0000
Adapter: ISA adapter
in0: N/A
>
> Of course, it would be much better if the firmware would also report
> the actual voltage, but I guess we can't have everything.
I think this isn't possible because the hardware only provide a binary value (GPIO).
>
> More comments inline.
>
> Thanks,
> Guenter
>
> > CC: "Noralf Tr?nnes" <noralf@tronnes.org>
> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> > drivers/hwmon/Kconfig | 10 ++
> > drivers/hwmon/Makefile | 1 +
> > drivers/hwmon/raspberrypi-hwmon.c | 207 ++++++++++++++++++++++++++++++++++++++
>
> Please also provide Documentation/hwmon/raspberrypi-hwmon.
>
> > 3 files changed, 218 insertions(+)
> > create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
> >
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 768aed5..7f935cf 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
> > This driver can also be built as a module. If so, the module
> > will be called pwm-fan.
> >
> > +config SENSORS_RASPBERRYPI_HWMON
> > + tristate "Raspberry Pi voltage monitor"
> > + depends on (ARCH_BCM2835 && RASPBERRYPI_FIRMWARE) || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
> > + help
> > + If you say yes here you get support for voltage sensor on the
> > + Raspberry Pi.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called raspberrypi-hwmon.
> > +
> > config SENSORS_SHT15
> > tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
> > depends on GPIOLIB || COMPILE_TEST
> > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> > index e7d52a3..a929770 100644
> > --- a/drivers/hwmon/Makefile
> > +++ b/drivers/hwmon/Makefile
> > @@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> > obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> > obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> > obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> > +obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o
> > obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
> > obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
> > obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
> > diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
> > new file mode 100644
> > index 0000000..2003f6c
> > --- /dev/null
> > +++ b/drivers/hwmon/raspberrypi-hwmon.c
> > @@ -0,0 +1,207 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Raspberry Pi voltage sensor driver
> > + *
> > + * Based on firmware/raspberrypi.c by Noralf Tr?nnes
> > + *
> > + * Copyright (C) 2018 Stefan Wahren <stefan.wahren@i2se.com>
> > + */
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/hwmon.h>
> > +#include <linux/hwmon-sysfs.h>
>
> Unnecessary include
>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +#include <linux/workqueue.h>
> > +#include <soc/bcm2835/raspberrypi-firmware.h>
> > +
> > +#define UNDERVOLTAGE_STICKY_BIT BIT(16)
> > +
> > +struct rpi_hwmon_data {
> > + struct device *hwmon_dev;
> > + struct rpi_firmware *fw;
> > + u32 last_throttled;
> > + struct delayed_work get_values_poll_work;
> > +};
> > +
> > +static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> > +{
> > + u32 new_uv, old_uv, value;
> > + int ret;
> > +
> > + /* Clear sticky bits */
>
> Please make more explicit that this is a request/command sent to the firmware.
>
> > + value = 0xffff;
> > +
> > + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
> > + &value, sizeof(value));
> > + if (ret) {
> > + dev_err_once(data->hwmon_dev, "%s: Failed to get throttled (%d)\n",
> > + __func__, ret);
>
> The function name seems unnecessary.
>
> > + return;
> > + }
> > +
> > + new_uv = value & UNDERVOLTAGE_STICKY_BIT;
> > + old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
> > + data->last_throttled = value;
> > +
> > + if (new_uv == old_uv)
> > + return;
> > +
> > + if (new_uv)
> > + dev_crit(data->hwmon_dev, "Under-voltage detected! (0x%08x)\n",
> > + value);
> > + else
> > + dev_info(data->hwmon_dev, "Voltage normalised (0x%08x)\n",
> > + value);
>
> What value do those hex values provide to the user ?
The actual definition of the bits can be found in the commit log of patch #1. But this isn't very helpful for an end user.
>
> > +
> > + sysfs_notify(&data->hwmon_dev->kobj, NULL, "in0_lcrit_alarm");
> > +}
> > +
> > +static void get_values_poll(struct work_struct *work)
> > +{
> > + struct rpi_hwmon_data *data;
> > +
> > + data = container_of(work, struct rpi_hwmon_data,
> > + get_values_poll_work.work);
> > +
> > + rpi_firmware_get_throttled(data);
> > +
> > + /*
> > + * We can't run faster than the sticky shift (100ms) since we get
> > + * flipping in the sticky bits that are cleared.
> > + */
> > + schedule_delayed_work(&data->get_values_poll_work, 2 * HZ);
> > +}
> > +
> > +static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
> > + u32 attr, int channel, long *val)
> > +{
> > + struct rpi_hwmon_data *data = dev_get_drvdata(dev);
> > +
> > + if (type != hwmon_in)
> > + return -EOPNOTSUPP;
> > +
> > + if (attr != hwmon_in_lcrit_alarm)
> > + return -EOPNOTSUPP;
> > +
> > + if (channel)
> > + return -EOPNOTSUPP;
> > +
> There is only one channel, one attribute, and one type supported.
> As such, the checks are unnecessary.
>
> > + *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
> > + return 0;
> > +}
> > +
> > +static umode_t rpi_is_visible(const void *_data, enum hwmon_sensor_types type,
> > + u32 attr, int channel)
> > +{
> > + if (type != hwmon_in)
> > + return 0;
> > +
> > + if (attr != hwmon_in_lcrit_alarm)
> > + return 0;
> > +
> > + if (channel)
> > + return 0;
>
> Same as above. In the list below, there is not a single conditional attribute.
> Given that, the checks should be unnecessary, and it should be sufficient to
> just return 0444.
>
> > +
> > + return 0444;
> > +}
> > +
> > +static const u32 rpi_in_config[] = {
> > + HWMON_I_LCRIT_ALARM,
> > + 0
> > +};
> > +
> > +static const struct hwmon_channel_info rpi_in = {
> > + .type = hwmon_in,
> > + .config = rpi_in_config,
> > +};
> > +
> > +static const struct hwmon_channel_info *rpi_info[] = {
> > + &rpi_in,
> > + NULL
> > +};
> > +
> > +static const struct hwmon_ops rpi_hwmon_ops = {
> > + .is_visible = rpi_is_visible,
> > + .read = rpi_read,
> > +};
> > +
> > +static const struct hwmon_chip_info rpi_chip_info = {
> > + .ops = &rpi_hwmon_ops,
> > + .info = rpi_info,
> > +};
> > +
> > +static int rpi_hwmon_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *fw_node;
> > + struct rpi_hwmon_data *data;
> > + int ret;
> > +
> > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + fw_node = of_get_parent(dev->of_node);
> > + if (!fw_node) {
> > + dev_err(dev, "Missing firmware node\n");
> > + return -ENOENT;
> > + }
> > +
> > + data->fw = rpi_firmware_get(fw_node);
> > + of_node_put(fw_node);
> > + if (!data->fw)
> > + return -EPROBE_DEFER;
> > +
> > + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
> > + &data->last_throttled,
> > + sizeof(data->last_throttled));
> > + if (ret) {
> > + dev_info(dev, "Firmware doesn't support GET_THROTTLED\n");
>
> If this is an error -> dev_err().
I wasn't sure. If the firmware is too old, we cannot provide this feature and it's a waste of resources to load this driver. On the other side i don't want to confuse people this is something bad.
Stefan
>
> > + return -EOPNOTSUPP;
>
> or return -ENODEV.
>
> > + }
> > +
> > + data->hwmon_dev = devm_hwmon_device_register_with_info(dev, "rpi_volt",
> > + data,
> > + &rpi_chip_info,
> > + NULL);
> > +
> > + INIT_DELAYED_WORK(&data->get_values_poll_work, get_values_poll);
> > + platform_set_drvdata(pdev, data);
> > +
> > + if (!PTR_ERR_OR_ZERO(data->hwmon_dev))
> > + schedule_delayed_work(&data->get_values_poll_work, 2 * HZ);
> > +
> > + return PTR_ERR_OR_ZERO(data->hwmon_dev);
> > +}
> > +
> > +static int rpi_hwmon_remove(struct platform_device *pdev)
> > +{
> > + struct rpi_hwmon_data *data = platform_get_drvdata(pdev);
> > +
> > + cancel_delayed_work_sync(&data->get_values_poll_work);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id rpi_hwmon_of_match[] = {
> > + { .compatible = "raspberrypi,bcm2835-hwmon", },
> > + { /* sentinel */},
> > +};
> > +MODULE_DEVICE_TABLE(of, rpi_hwmon_of_match);
> > +
> > +static struct platform_driver rpi_hwmon_driver = {
> > + .probe = rpi_hwmon_probe,
> > + .remove = rpi_hwmon_remove,
> > + .driver = {
> > + .name = "raspberrypi-hwmon",
> > + .of_match_table = rpi_hwmon_of_match,
> > + },
> > +};
> > +module_platform_driver(rpi_hwmon_driver);
> > +
> > +MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
> > +MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] coresight: documentation: update sysfs section
From: Kim Phillips @ 2018-05-16 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516131823.4b1a3ecb@lwn.net>
On Wed, 16 May 2018 13:18:23 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> On Mon, 14 May 2018 12:19:59 -0500
> Kim Phillips <kim.phillips@arm.com> wrote:
>
> > - Align and show updated ls devices output from the TC2, based on
> > current driver
> >
> > - Provide an example from an ETMv4 based system (Juno)
> >
> > - Reflect changes to the way the RAM write pointer is accessed since
> > it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
> > management entries").
>
> So I was going to apply this, but it's been pretty badly corrupted by
> your mailer. Could I ask you to retry, please?
I had sent a v3 that corrected the issue, in the same thread, here:
https://lkml.org/lkml/2018/5/14/1190
Mathieu acked that one.
Thanks,
Kim
^ permalink raw reply
* [PATCH v2 1/3] rtc: stm32: rework register management to prepare other version of RTC
From: Alexandre Belloni @ 2018-05-16 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525880770-22263-2-git-send-email-amelie.delaunay@st.com>
Hi,
On 09/05/2018 17:46:08+0200, Amelie Delaunay wrote:
> static void stm32_rtc_wpr_unlock(struct stm32_rtc *rtc)
> {
> - writel_relaxed(RTC_WPR_1ST_KEY, rtc->base + STM32_RTC_WPR);
> - writel_relaxed(RTC_WPR_2ND_KEY, rtc->base + STM32_RTC_WPR);
> + struct stm32_rtc_registers regs = rtc->data->regs;
regs should probably be a pointer to ensure that no copy is made. I've
actually checked and it doesn't make a difference because gcc is smart
enough to not make the copy.
> +
> + writel_relaxed(RTC_WPR_1ST_KEY, rtc->base + regs.wpr);
> + writel_relaxed(RTC_WPR_2ND_KEY, rtc->base + regs.wpr);
> }
>
...
> static irqreturn_t stm32_rtc_alarm_irq(int irq, void *dev_id)
> {
> struct stm32_rtc *rtc = (struct stm32_rtc *)dev_id;
> - unsigned int isr, cr;
> + struct stm32_rtc_registers regs = rtc->data->regs;
> + struct stm32_rtc_events evts = rtc->data->events;
Ditto for evts.
> + unsigned int status, cr;
>
> mutex_lock(&rtc->rtc_dev->ops_lock);
>
> - isr = readl_relaxed(rtc->base + STM32_RTC_ISR);
> - cr = readl_relaxed(rtc->base + STM32_RTC_CR);
> + status = readl_relaxed(rtc->base + regs.isr);
> + cr = readl_relaxed(rtc->base + regs.cr);
>
> - if ((isr & STM32_RTC_ISR_ALRAF) &&
> + if ((status & evts.alra) &&
> (cr & STM32_RTC_CR_ALRAIE)) {
> /* Alarm A flag - Alarm interrupt */
> dev_dbg(&rtc->rtc_dev->dev, "Alarm occurred\n");
...
> @@ -641,7 +710,7 @@ static int stm32_rtc_probe(struct platform_device *pdev)
>
> /*
> * After a system reset, RTC_ISR.INITS flag can be read to check if
> - * the calendar has been initalized or not. INITS flag is reset by a
> + * the calendar has been initialized or not. INITS flag is reset by a
> * power-on reset (no vbat, no power-supply). It is not reset if
> * rtc_ck parent clock has changed (so RTC prescalers need to be
> * changed). That's why we cannot rely on this flag to know if RTC
> @@ -666,7 +735,7 @@ static int stm32_rtc_probe(struct platform_device *pdev)
> "alarm won't be able to wake up the system");
>
> rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name,
> - &stm32_rtc_ops, THIS_MODULE);
> + &stm32_rtc_ops, THIS_MODULE);
> if (IS_ERR(rtc->rtc_dev)) {
> ret = PTR_ERR(rtc->rtc_dev);
> dev_err(&pdev->dev, "rtc device registration failed, err=%d\n",
Those two changes should go into a separate cleanup patch.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4] pinctrl: msm: fix gpio-hog related boot issues
From: Christian Lamparter @ 2018-05-16 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152648467672.210890.17814748620132622851@swboyd.mtv.corp.google.com>
On Wednesday, May 16, 2018 5:31:16 PM CEST Stephen Boyd wrote:
> Quoting Linus Walleij (2018-04-26 05:03:45)
> > On Thu, Apr 12, 2018 at 9:01 PM, Christian Lamparter <chunkeey@gmail.com> wrote:
> >
> > > Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
> > > Setting up any gpio-hog in the device-tree for his device would
> > > "kill the bootup completely":
> > >
> > > | [ 0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl at 1000000/serial_pinmux, deferring probe
> > > | [ 0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl at 1000000/spi_0_pinmux, deferring probe
> > > | [ 1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517
> > > | [ 1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register
> > > | [ 1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip
> > > | [ 1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl at 1000000/serial_pinmux, deferring probe
> > > | [ 1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl at 1000000/spi_0_pinmux, deferri
> > >
> > > This was also verified on a RT-AC58U (IPQ4018) which would
> > > no longer boot, if a gpio-hog was specified. (Tried forcing
> > > the USB LED PIN (GPIO0) to high.).
> > >
> > > The problem is that Pinctrl+GPIO registration is currently
> > > peformed in the following order in pinctrl-msm.c:
> > > 1. pinctrl_register()
> > > 2. gpiochip_add()
> > > 3. gpiochip_add_pin_range()
> > >
> > > The actual error code -517 == -EPROBE_DEFER is coming from
> > > pinctrl_get_device_gpio_range(), which is called through:
> > > gpiochip_add
> > > of_gpiochip_add
> > > of_gpiochip_scan_gpios
> > > gpiod_hog
> > > gpiochip_request_own_desc
> > > __gpiod_request
> > > chip->request
> > > gpiochip_generic_request
> > > pinctrl_gpio_request
> > > pinctrl_get_device_gpio_range
> > >
> > > pinctrl_get_device_gpio_range() is unable to find any valid
> > > pin ranges, since nothing has been added to the pinctrldev_list yet.
> > > so the range can't be found, and the operation fails with -EPROBE_DEFER.
> > >
> > > This patch fixes the issue by adding the "gpio-ranges" property to
> > > the pinctrl device node of all upstream Qcom SoC. The pin ranges are
> > > then added by the gpio core.
> > >
> > > In order to remain compatible with older, existing DTs (and ACPI)
> > > a check for the "gpio-ranges" property has been added to
> > > msm_gpio_init(). This prevents the driver of adding the same entry
> > > to the pinctrldev_list twice.
> > >
> > > Reported-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
> > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> >
> > This patch looks VERY good to me.
> >
>
> 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.
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"
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?")
> 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.
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 :).
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).
(Also, it looks like the nvidia tegra pinctrl-driver has the gpio-ranges
property in the DTS, but not in the binding documentation. I'll add
that to the nvidia pile.)
Thanks,
Christian
[0] <https://www.spinics.net/lists/linux-arm-msm/msg34833.html>
^ permalink raw reply
* [PATCH v2 3/3] rtc: stm32: add stm32mp1 rtc support
From: Alexandre Belloni @ 2018-05-16 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525880770-22263-4-git-send-email-amelie.delaunay@st.com>
On 09/05/2018 17:46:10+0200, Amelie Delaunay wrote:
> struct stm32_rtc_registers {
> @@ -86,6 +98,9 @@ struct stm32_rtc_registers {
> u8 prer;
> u8 alrmar;
> u8 wpr;
> + u8 sr;
> + u8 scr;
> + u16 verr;
All those offsets should probably be u16 or u32...
> + if (regs.verr != UNDEF_REG) {
...else, this is not working, as reported by kbuild
> + u32 ver = readl_relaxed(rtc->base + regs.verr);
> +
> + dev_info(&pdev->dev, "registered rev:%d.%d\n",
> + (ver >> STM32_RTC_VERR_MAJREV_SHIFT) & 0xF,
> + (ver >> STM32_RTC_VERR_MINREV_SHIFT) & 0xF);
> + }
> +
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API
From: Jacob Pan @ 2018-05-16 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-2-jean-philippe.brucker@arm.com>
On Fri, 11 May 2018 20:06:02 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> Shared Virtual Addressing (SVA) provides a way for device drivers to
> bind process address spaces to devices. This requires the IOMMU to
> support page table format and features compatible with the CPUs, and
> usually requires the system to support I/O Page Faults (IOPF) and
> Process Address Space ID (PASID). When all of these are available,
> DMA can access virtual addresses of a process. A PASID is allocated
> for each process, and the device driver programs it into the device
> in an implementation-specific way.
>
> Add a new API for sharing process page tables with devices. Introduce
> two IOMMU operations, sva_device_init() and sva_device_shutdown(),
> that prepare the IOMMU driver for SVA. For example allocate PASID
> tables and fault queues. Subsequent patches will implement the bind()
> and unbind() operations.
>
> Support for I/O Page Faults will be added in a later patch using a new
> feature bit (IOMMU_SVA_FEAT_IOPF). With the current API users must pin
> down all shared mappings. Other feature bits that may be added in the
> future are IOMMU_SVA_FEAT_PRIVATE, to support private PASID address
> spaces, and IOMMU_SVA_FEAT_NO_PASID, to bind the whole device address
> space to a process.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>
> ---
> v1->v2:
> * Add sva_param structure to iommu_param
> * CONFIG option is only selectable by IOMMU drivers
> ---
> drivers/iommu/Kconfig | 4 ++
> drivers/iommu/Makefile | 1 +
> drivers/iommu/iommu-sva.c | 110
> ++++++++++++++++++++++++++++++++++++++ include/linux/iommu.h |
> 32 +++++++++++ 4 files changed, 147 insertions(+)
> create mode 100644 drivers/iommu/iommu-sva.c
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7564237f788d..cca8e06903c7 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -74,6 +74,10 @@ config IOMMU_DMA
> select IOMMU_IOVA
> select NEED_SG_DMA_LENGTH
>
> +config IOMMU_SVA
> + bool
> + select IOMMU_API
> +
> config FSL_PAMU
> bool "Freescale IOMMU support"
> depends on PCI
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 1fb695854809..1dbcc89ebe4c 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_IOMMU_API) += iommu.o
> obj-$(CONFIG_IOMMU_API) += iommu-traces.o
> obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
> obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
> +obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> new file mode 100644
> index 000000000000..8b4afb7c63ae
> --- /dev/null
> +++ b/drivers/iommu/iommu-sva.c
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Manage PASIDs and bind process address spaces to devices.
> + *
> + * Copyright (C) 2018 ARM Ltd.
> + */
> +
> +#include <linux/iommu.h>
> +#include <linux/slab.h>
> +
> +/**
> + * iommu_sva_device_init() - Initialize Shared Virtual Addressing
> for a device
> + * @dev: the device
> + * @features: bitmask of features that need to be initialized
> + * @max_pasid: max PASID value supported by the device
> + *
> + * Users of the bind()/unbind() API must call this function to
> initialize all
> + * features required for SVA.
> + *
> + * The device must support multiple address spaces (e.g. PCI PASID).
> By default
> + * the PASID allocated during bind() is limited by the IOMMU
> capacity, and by
> + * the device PASID width defined in the PCI capability or in the
> firmware
> + * description. Setting @max_pasid to a non-zero value smaller than
> this limit
> + * overrides it.
> + *
seems the min_pasid never gets used. do you really need it?
> + * The device should not be performing any DMA while this function
> is running,
> + * otherwise the behavior is undefined.
> + *
> + * Return 0 if initialization succeeded, or an error.
> + */
> +int iommu_sva_device_init(struct device *dev, unsigned long features,
> + unsigned int max_pasid)
> +{
> + int ret;
> + struct iommu_sva_param *param;
> + struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> +
> + if (!domain || !domain->ops->sva_device_init)
> + return -ENODEV;
> +
> + if (features)
> + return -EINVAL;
should it be !features?
> +
> + param = kzalloc(sizeof(*param), GFP_KERNEL);
> + if (!param)
> + return -ENOMEM;
> +
> + param->features = features;
> + param->max_pasid = max_pasid;
> +
> + /*
> + * IOMMU driver updates the limits depending on the IOMMU
> and device
> + * capabilities.
> + */
> + ret = domain->ops->sva_device_init(dev, param);
> + if (ret)
> + goto err_free_param;
> +
> + mutex_lock(&dev->iommu_param->lock);
> + if (dev->iommu_param->sva_param)
> + ret = -EEXIST;
> + else
> + dev->iommu_param->sva_param = param;
> + mutex_unlock(&dev->iommu_param->lock);
> + if (ret)
> + goto err_device_shutdown;
> +
> + return 0;
> +
> +err_device_shutdown:
> + if (domain->ops->sva_device_shutdown)
> + domain->ops->sva_device_shutdown(dev, param);
> +
> +err_free_param:
> + kfree(param);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_sva_device_init);
> +
> +/**
> + * iommu_sva_device_shutdown() - Shutdown Shared Virtual Addressing
> for a device
> + * @dev: the device
> + *
> + * Disable SVA. Device driver should ensure that the device isn't
> performing any
> + * DMA while this function is running.
> + */
> +int iommu_sva_device_shutdown(struct device *dev)
> +{
> + struct iommu_sva_param *param;
> + struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> +
> + if (!domain)
> + return -ENODEV;
> +
> + mutex_lock(&dev->iommu_param->lock);
> + param = dev->iommu_param->sva_param;
> + dev->iommu_param->sva_param = NULL;
> + mutex_unlock(&dev->iommu_param->lock);
> + if (!param)
> + return -ENODEV;
> +
> + if (domain->ops->sva_device_shutdown)
> + domain->ops->sva_device_shutdown(dev, param);
seems a little mismatch here, do you need pass the param. I don't think
there is anything else model specific iommu driver need to do for the
param.
> +
> + kfree(param);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iommu_sva_device_shutdown);
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 0933f726d2e6..2efe7738bedb 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -212,6 +212,12 @@ struct page_response_msg {
> u64 private_data;
> };
>
> +struct iommu_sva_param {
> + unsigned long features;
> + unsigned int min_pasid;
> + unsigned int max_pasid;
> +};
> +
> /**
> * struct iommu_ops - iommu ops and capabilities
> * @capable: check capability
> @@ -219,6 +225,8 @@ struct page_response_msg {
> * @domain_free: free iommu domain
> * @attach_dev: attach device to an iommu domain
> * @detach_dev: detach device from an iommu domain
> + * @sva_device_init: initialize Shared Virtual Adressing for a device
> + * @sva_device_shutdown: shutdown Shared Virtual Adressing for a
> device
> * @map: map a physically contiguous memory region to an iommu domain
> * @unmap: unmap a physically contiguous memory region from an iommu
> domain
> * @map_sg: map a scatter-gather list of physically contiguous
> memory chunks @@ -256,6 +264,10 @@ struct iommu_ops {
>
> int (*attach_dev)(struct iommu_domain *domain, struct device
> *dev); void (*detach_dev)(struct iommu_domain *domain, struct device
> *dev);
> + int (*sva_device_init)(struct device *dev,
> + struct iommu_sva_param *param);
> + void (*sva_device_shutdown)(struct device *dev,
> + struct iommu_sva_param *param);
> int (*map)(struct iommu_domain *domain, unsigned long iova,
> phys_addr_t paddr, size_t size, int prot);
> size_t (*unmap)(struct iommu_domain *domain, unsigned long
> iova, @@ -413,6 +425,7 @@ struct iommu_fault_param {
> * struct iommu_param - collection of per-device IOMMU data
> *
> * @fault_param: IOMMU detected device fault reporting data
> + * @sva_param: SVA parameters
> *
> * TODO: migrate other per device data pointers under
> iommu_dev_data, e.g.
> * struct iommu_group *iommu_group;
> @@ -421,6 +434,7 @@ struct iommu_fault_param {
> struct iommu_param {
> struct mutex lock;
> struct iommu_fault_param *fault_param;
> + struct iommu_sva_param *sva_param;
> };
>
> int iommu_device_register(struct iommu_device *iommu);
> @@ -920,4 +934,22 @@ static inline int iommu_sva_invalidate(struct
> iommu_domain *domain,
> #endif /* CONFIG_IOMMU_API */
>
> +#ifdef CONFIG_IOMMU_SVA
> +extern int iommu_sva_device_init(struct device *dev, unsigned long
> features,
> + unsigned int max_pasid);
> +extern int iommu_sva_device_shutdown(struct device *dev);
> +#else /* CONFIG_IOMMU_SVA */
> +static inline int iommu_sva_device_init(struct device *dev,
> + unsigned long features,
> + unsigned int max_pasid)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int iommu_sva_device_shutdown(struct device *dev)
> +{
> + return -ENODEV;
> +}
> +#endif /* CONFIG_IOMMU_SVA */
> +
> #endif /* __LINUX_IOMMU_H */
[Jacob Pan]
^ permalink raw reply
* [PATCH] pinctrl: mvebu: use correct MPP sel value for dev pins
From: Chris Packham @ 2018-05-16 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbAaMrHJ8TjJTtNyVtoOSRAEf2Z8gRthFH0ze4RyybBag@mail.gmail.com>
On 17/05/18 00:55, Linus Walleij wrote:
> On Mon, May 7, 2018 at 4:25 AM, Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>
>> The "dev" function is selected with the value 0x4 not 0x01.
>>
>> Fixes: commit d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC")
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>
> Patch applied.
>
> Does it need to go into fixes? Stable?
By "fixes" do you mean into 4.17? Yes please.
Stable would be good. Although all the boards I'm aware of rely on the
pin configuration being done by the bootloader so I've not heard of
anyone experiencing problems.
^ permalink raw reply
* [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties
From: Niklas Söderlund @ 2018-05-16 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526488352-898-2-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-16 18:32:27 +0200, Jacopo Mondi wrote:
> Describe the optional endpoint properties for endpoint nodes of port at 0
> and port at 1 of the R-Car VIN driver device tree bindings documentation.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1..c53ce4e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> from external SoC pins described in video-interfaces.txt[1].
> Describing more then one endpoint in port 0 is invalid. Only VIN
> instances that are connected to external pins should have port 0.
> +
> + - Optional properties for endpoint nodes of port at 0:
> + - hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> + respectively. Default is active high.
> + - vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> + respectively. Default is active high.
> +
> + If both HSYNC and VSYNC polarities are not specified, embedded
> + synchronization is selected.
> +
> - port 1 - sub-nodes describing one or more endpoints connected to
> the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> use the following schema.
> @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> - Endpoint 2 - sub-node describing the endpoint connected to CSI40
> - Endpoint 3 - sub-node describing the endpoint connected to CSI41
>
> + Endpoint nodes of port at 1 do not support any optional endpoint property.
> +
> Device node example for Gen2 platforms
> --------------------------------------
>
> @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite video input)
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH] arm64: dts: juno: fix graph node unit addresses for coresight components
From: Mathieu Poirier @ 2018-05-16 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd4796b7-a078-27db-0fdc-099a834ce8bc@arm.com>
On 16 May 2018 at 11:40, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 16/05/18 18:29, Mathieu Poirier wrote:
>> On 16 May 2018 at 05:49, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>>
>>> On 16/05/18 12:23, Suzuki K Poulose wrote:
>>>> On 05/16/2018 11:34 AM, Sudeep Holla wrote:
>>>
>>> [..]
>>>
>>>>> Hi Suzuki/Mathieu,
>>>>>
>>>>> I did a quick scan @ drivers/hwtracing/coresight/of_coresight.c to
>>>>> check if reg field is being used or not and whether this change
>>>>> causes any regression. I don't think so, but I may be wrong, let me
>>>>> know.
>>>>
>>>> Unfortunately, I think this would break the components like funnel,
>>>> where we need the input port number for the connected master to enable
>>>> the port. Similarly for the output port number for master components in
>>>> the paths. I have a set of patches which address this by taking care of
>>>> the port number order to find out the hardware port number.
>>>>
>>>
>>> Ah ok, I now see of_graph_parse_endpoint, sorry for missing that.
>>
>> The problem is not with of_graph_parse_endpoint(), that will work just
>> fine. In fact you can add whatever number you want there without
>> impact on how devices see each other in the framework. The problem is
>> that the port numbering doesn't reflect the HW layout anymore and as
>> such you can't rely on the port value when configuring the HW.
>>
>
> Exactly, I had a chat with Suzuki. One option is to introduce new hwid
> field to fix that. If the field is present, it will be used and reg
> field will be ignored. In that way, you won't break the compatibility.
I had the same idea a while back and something Grant Likely and I
talked about at ELC-E 2017 in Prague. This is the way I would prefer
to move forward on this.
> Just my thoughts. I am not sure if we need to support old kernel with
> updated DTs though. That may be difficult.
Not sure that can be done. The only way to do that would be to
continue using the reg property, which isn't possible anymore. As
such said DT wouldn't be upstream and I'm not sure we need to care
about those.
>
>>>
>>>> I will dust it up and send it. That would bring up another important
>>>> question.
>>>>
>>>
>>> Cool
>>>
>>>> How do we deal with the change in the port number scheme ? e.g, should
>>>> the new kernel support DTBs with old scheme ?
>>>
>>
>> DT files following the old scheme will spew out warnings like we're
>> getting on Juno and are bound to be fixed.
>>
> True, they can pick up the new changes too along with changes just
> fixing the warning.
>
>>> IIUC, that's needed for backward compatibility as it was used schema.
>>> Again I may be wrong.
>>>
>>>> If so, how do we specify that the DT uses new scheme.
>>>
>>> Perhaps, add something to indicate the change in numbering scheme ?
>>
>> The current customers should be moved to the new scheme. That way we
>> don't have to support two different DT scheme (where one will die
>> eventually).
>>
>
> But the problem is if someone has DT which can't be modified and we move
> to new scheme only in the kernel, then they will see regression on their
> platforms. If that's fine, it simplifies things a lot. But I am not so
> sure of that ...
You have a point. The code could check for both reg and hwid
properties. If both are there hwid is preferred. Otherwise the reg
property is used. That wouldn't be too difficult to implement and
avoid introducing a regression. Of course all this is fantasy until
we actually try things out.
Thanks,
Mathieu
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active
From: Niklas Söderlund @ 2018-05-16 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526488352-898-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your work.
On 2018-05-16 18:32:28 +0200, Jacopo Mondi wrote:
> Document 'data-active' property in R-Car VIN device tree bindings.
> The property is optional when running with explicit synchronization
> (eg. BT.601) but mandatory when embedded synchronization is in use (eg.
> BT.656) as specified by the hardware manual.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index c53ce4e..17eac8a 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> If both HSYNC and VSYNC polarities are not specified, embedded
> synchronization is selected.
>
> + - data-active: active state of data enable signal (CLOCKENB pin).
I'm not sure what you mean by active state here. video-interfaces.txt
defines data-active as 'similar to HSYNC and VSYNC, specifies data line
polarity' so I assume this is the polarity of the CLOCKENB pin?
> + 0/1 for LOW/HIGH respectively. If not specified, use HSYNC as
> + data enable signal. When using embedded synchronization this
> + property is mandatory.
I'm confused, why is this mandatory if we have no embedded sync (that is
hsync-active and vsync-active not defined)? I can't find any reference
to this in the Gen2 datasheet but I'm sure I'm just missing it :-)
> +
> - port 1 - sub-nodes describing one or more endpoints connected to
> the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> use the following schema.
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Niklas Söderlund @ 2018-05-16 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526488352-898-6-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your work.
On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> driver and only confuse users. Remove them in all Gen2 SoC that used
> them.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> arch/arm/boot/dts/r8a7793-gose.dts | 3 ---
> arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> arch/arm/boot/dts/r8a7794-silk.dts | 1 -
> 6 files changed, 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index 063fdb6..b56b309 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -873,10 +873,8 @@
> port {
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
I can't really make up my mind if this is a good thing or not. Device
tree describes the hardware and not what the drivers make use of. And
the fact is that this bus is 24 bits wide. So I'm not sure we should
remove these properties. But I would love to hear what others think
about this.
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -895,7 +893,6 @@
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index f40321a..9967666 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -849,10 +849,8 @@
>
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -870,7 +868,6 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> index c14e6fe..055a7f1 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -391,7 +391,6 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index 9ed6961..9d3fba2 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -759,10 +759,8 @@
>
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -781,7 +779,6 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180_out>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
> index 26a8834..4bbb9cc 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -380,7 +380,6 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> index 351cb3b..c0c5d31 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -480,7 +480,6 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH 6/6] ARM: dts: rcar-gen2: Add 'data-active' property
From: Niklas Söderlund @ 2018-05-16 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526488352-898-7-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your work.
On 2018-05-16 18:32:32 +0200, Jacopo Mondi wrote:
> The 'data-active' property needs to be specified when using embedded
> synchronization. Add it to the Gen-2 boards using composite video input.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> arch/arm/boot/dts/r8a7790-lager.dts | 1 +
> arch/arm/boot/dts/r8a7791-koelsch.dts | 1 +
> arch/arm/boot/dts/r8a7791-porter.dts | 1 +
> arch/arm/boot/dts/r8a7793-gose.dts | 1 +
> arch/arm/boot/dts/r8a7794-alt.dts | 1 +
> arch/arm/boot/dts/r8a7794-silk.dts | 1 +
> 6 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index b56b309..48fcb44 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -893,6 +893,7 @@
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 9967666..fa0b25f 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -868,6 +868,7 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
Depending on how we interpret the data-active property this can be good
or bad. But if we interpret it as the polarity of the VIn_CLKENB pin
this is not good as this is not connected for the adv7180 on Koelsch.
I have not checked all the Gen2 schematics as I'm still not sure how to
interpret the property.
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> index 055a7f1..96b9605 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -391,6 +391,7 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index 9d3fba2..80b4fa8 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -779,6 +779,7 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180_out>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
> index 4bbb9cc..00df605d 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -380,6 +380,7 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> index c0c5d31..ed17376 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -480,6 +480,7 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input
From: Niklas Söderlund @ 2018-05-16 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526478129-16465-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-16 15:42:08 +0200, Jacopo Mondi wrote:
> Describe CVBS video input through analog video decoder ADV7180
> connected to video input interface VIN4.
>
> The video input signal path is shared with HDMI video input, and
> selected by on-board switches SW-53 and SW-54 with CVBS input selected
> by the default switches configuration.
You are missing your SoB line :-)
Reviewed-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 36 ++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index d03f194..9aba28f 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -142,6 +142,11 @@
> groups = "usb0";
> function = "usb0";
> };
> +
> + vin4_pins_cvbs: vin4 {
> + groups = "vin4_data8", "vin4_sync", "vin4_clk";
> + function = "vin4";
> + };
> };
>
> &i2c0 {
> @@ -154,6 +159,17 @@
> reg = <0x50>;
> pagesize = <8>;
> };
> +
> + analog-video at 20 {
> + compatible = "adi,adv7180";
> + reg = <0x20>;
> +
> + port {
> + adv7180_out: endpoint {
> + remote-endpoint = <&vin4_in>;
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -246,3 +262,23 @@
> timeout-sec = <60>;
> status = "okay";
> };
> +
> +&vin4 {
> + pinctrl-0 = <&vin4_pins_cvbs>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + vin4_in: endpoint {
> + remote-endpoint = <&adv7180_out>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Niklas Söderlund @ 2018-05-16 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526478129-16465-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-16 15:42:09 +0200, Jacopo Mondi wrote:
> Describe HDMI input connector and ADV7612 HDMI decoder installed on
> R-Car Gen3 Draak board.
>
> The video signal routing to the HDMI decoder to the video input interface
> VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> on-board switches SW-49, SW-50, SW-51 and SW-52.
>
> As the default board switches configuration connects CVBS input to VIN4,
> leave the HDMI decoder unconnected in DTS.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
I'm not sure we have a policy about describing hardware which can't be
used without flipping switches. I have no opinion on if we should do
that or not I leave that to others, but for the change itself.
Reviewed-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
I think it's good we describe it as it's part of the Draak board itself
and not an expansion board which we have seen a lot of :-) Maybe even
add a commented out line in the adv7612 port at 2 which hints which VIN
this is connected to if the switches are flipped?
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 38 ++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index 9aba28f..ea99dc9 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -59,6 +59,17 @@
> };
> };
>
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&adv7612_in>;
> + };
> + };
> + };
> +
> memory at 48000000 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> @@ -170,6 +181,33 @@
> };
> };
> };
> +
> + hdmi-decoder at 4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + default-input = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7612_in: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> + };
> +
> + port at 2 {
> + reg = <2>;
> + adv7612_out: endpoint {
> + pclk-sample = <0>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* linux-next: manual merge of the mvebu tree with the arm-soc tree
From: Stephen Rothwell @ 2018-05-16 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the mvebu tree got a conflict in:
arch/arm/configs/multi_v7_defconfig
between various commits from the arm-soc tree and commit:
873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration")
from the mvebu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/configs/multi_v7_defconfig
index 0c7abc87f01a,2b008248fb52..000000000000
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@@ -169,26 -153,14 +153,16 @@@ CONFIG_IPV6_MIP6=
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_NET_DSA=m
- CONFIG_NET_SWITCHDEV=y
CONFIG_CAN=y
- CONFIG_CAN_RAW=y
- CONFIG_CAN_BCM=y
- CONFIG_CAN_DEV=y
CONFIG_CAN_AT91=m
CONFIG_CAN_FLEXCAN=m
- CONFIG_CAN_RCAR=m
+ CONFIG_CAN_SUN4I=y
CONFIG_CAN_XILINXCAN=y
+ CONFIG_CAN_RCAR=m
CONFIG_CAN_MCP251X=y
- CONFIG_NET_DSA_BCM_SF2=m
- CONFIG_B53=m
- CONFIG_B53_SPI_DRIVER=m
- CONFIG_B53_MDIO_DRIVER=m
- CONFIG_B53_MMAP_DRIVER=m
- CONFIG_B53_SRAB_DRIVER=m
- CONFIG_CAN_SUN4I=y
CONFIG_BT=m
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_BCM=y
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
CONFIG_CFG80211=m
@@@ -272,17 -247,15 +249,16 @@@ CONFIG_DWMAC_DWC_QOS_ETH=
CONFIG_TI_CPSW=y
CONFIG_XILINX_EMACLITE=y
CONFIG_AT803X_PHY=y
- CONFIG_MARVELL_PHY=y
- CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
- CONFIG_REALTEK_PHY=y
+ CONFIG_MARVELL_PHY=y
CONFIG_MICREL_PHY=y
- CONFIG_FIXED_PHY=y
+ CONFIG_REALTEK_PHY=y
CONFIG_ROCKCHIP_PHY=y
+ CONFIG_SMSC_PHY=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8152=m
+CONFIG_USB_LAN78XX=m
CONFIG_USB_USBNET=y
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
@@@ -363,13 -334,10 +337,11 @@@ CONFIG_SERIAL_ST_ASC=
CONFIG_SERIAL_ST_ASC_CONSOLE=y
CONFIG_SERIAL_STM32=y
CONFIG_SERIAL_STM32_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
- CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
+ CONFIG_HW_RANDOM=y
+ CONFIG_HW_RANDOM_ST=y
CONFIG_I2C_CHARDEV=y
- CONFIG_I2C_DAVINCI=y
- CONFIG_I2C_MESON=y
- CONFIG_I2C_MUX=y
CONFIG_I2C_ARB_GPIO_CHALLENGE=m
CONFIG_I2C_MUX_PCA954x=y
CONFIG_I2C_MUX_PINCTRL=y
@@@ -381,8 -350,7 +354,8 @@@ CONFIG_I2C_DESIGNWARE_PLATFORM=
CONFIG_I2C_DIGICOLOR=m
CONFIG_I2C_EMEV2=m
CONFIG_I2C_GPIO=m
- CONFIG_I2C_EXYNOS5=y
CONFIG_I2C_IMX=y
++CONFIG_I2C_MESON=y
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_RIIC=y
CONFIG_I2C_RK3X=y
@@@ -643,13 -602,17 +608,18 @@@ CONFIG_DRM_RCAR_LVDS=
CONFIG_DRM_SUN4I=m
CONFIG_DRM_FSL_DCU=m
CONFIG_DRM_TEGRA=y
+ CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_SAMSUNG_LD9040=m
+CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03=m
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
- CONFIG_DRM_PANEL_SIMPLE=y
+ CONFIG_DRM_DUMB_VGA_DAC=m
+ CONFIG_DRM_NXP_PTN3460=m
+ CONFIG_DRM_PARADE_PS8622=m
CONFIG_DRM_SII9234=m
+ CONFIG_DRM_I2C_ADV7511=m
+ CONFIG_DRM_I2C_ADV7511_AUDIO=y
CONFIG_DRM_STI=m
- CONFIG_DRM_VC4=y
+ CONFIG_DRM_VC4=m
CONFIG_DRM_ETNAVIV=m
CONFIG_DRM_MXSFB=m
CONFIG_FB_ARMCLCD=y
@@@ -953,8 -901,9 +908,10 @@@ CONFIG_PWM=
CONFIG_PWM_ATMEL=m
CONFIG_PWM_ATMEL_HLCDC_PWM=m
CONFIG_PWM_ATMEL_TCB=m
+ CONFIG_PWM_BCM2835=y
+ CONFIG_PWM_BRCMSTB=m
CONFIG_PWM_FSL_FTM=m
+CONFIG_PWM_MESON=m
CONFIG_PWM_RCAR=m
CONFIG_PWM_RENESAS_TPU=y
CONFIG_PWM_ROCKCHIP=m
@@@ -962,31 -912,25 +920,26 @@@ CONFIG_PWM_STI=
CONFIG_PWM_SUN4I=y
CONFIG_PWM_TEGRA=y
CONFIG_PWM_VT8500=y
+ CONFIG_KEYSTONE_IRQ=y
++CONFIG_PHY_STM32_USBPHYC=y
+ CONFIG_PHY_SUN4I_USB=y
+ CONFIG_PHY_SUN9I_USB=y
CONFIG_PHY_HIX5HD2_SATA=y
- CONFIG_E1000E=y
- CONFIG_PWM_STI=y
- CONFIG_PWM_BCM2835=y
- CONFIG_PWM_BRCMSTB=m
- CONFIG_PHY_DM816X_USB=m
- CONFIG_OMAP_USB2=y
- CONFIG_TI_PIPE3=y
- CONFIG_TWL4030_USB=m
+ CONFIG_PHY_BERLIN_SATA=y
CONFIG_PHY_BERLIN_USB=y
CONFIG_PHY_CPCAP_USB=m
- CONFIG_PHY_BERLIN_SATA=y
+ CONFIG_PHY_QCOM_APQ8064_SATA=m
+ CONFIG_PHY_RCAR_GEN2=m
CONFIG_PHY_ROCKCHIP_DP=m
CONFIG_PHY_ROCKCHIP_USB=y
- CONFIG_PHY_QCOM_APQ8064_SATA=m
+ CONFIG_PHY_SAMSUNG_USB2=m
CONFIG_PHY_MIPHY28LP=y
- CONFIG_PHY_RCAR_GEN2=m
CONFIG_PHY_STIH407_USB=y
- CONFIG_PHY_STM32_USBPHYC=y
- CONFIG_PHY_SUN4I_USB=y
- CONFIG_PHY_SUN9I_USB=y
- CONFIG_PHY_SAMSUNG_USB2=m
CONFIG_PHY_TEGRA_XUSB=y
- CONFIG_PHY_BRCM_SATA=y
- CONFIG_NVMEM=y
+ CONFIG_PHY_DM816X_USB=m
+ CONFIG_OMAP_USB2=y
+ CONFIG_TI_PIPE3=y
+ CONFIG_TWL4030_USB=m
CONFIG_NVMEM_IMX_OCOTP=y
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_VF610_OCOTP=y
-------------- 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/20180517/98b2243d/attachment.sig>
^ permalink raw reply
* linux-next: manual merge of the renesas tree with the mvebu tree
From: Stephen Rothwell @ 2018-05-16 22:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the renesas tree got a conflict in:
arch/arm/configs/multi_v7_defconfig
between commit:
873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration")
from the mvebu tree and commits:
57eec170e954 ("ARM: multi_v7_defconfig: Disable CONFIG_FB_SH_MOBILE_MERAM")
eedd7902366b ("ARM: multi_v7_defconfig: Enable RENESAS_WDT")
from the renesas tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/configs/multi_v7_defconfig
index 8bcf3be58047,374a40945b0f..000000000000
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@@ -463,23 -489,20 +464,24 @@@ CONFIG_XILINX_WATCHDOG=
CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_AT91SAM9X_WATCHDOG=y
CONFIG_SAMA5D4_WATCHDOG=y
+CONFIG_DW_WATCHDOG=y
+CONFIG_DAVINCI_WATCHDOG=m
CONFIG_ORION_WATCHDOG=y
CONFIG_RN5T618_WATCHDOG=y
-CONFIG_ST_LPC_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=y
CONFIG_IMX2_WDT=y
+CONFIG_ST_LPC_WATCHDOG=y
CONFIG_TEGRA_WATCHDOG=m
CONFIG_MESON_WATCHDOG=y
-CONFIG_DW_WATCHDOG=y
CONFIG_DIGICOLOR_WATCHDOG=y
+ CONFIG_RENESAS_WDT=m
-CONFIG_BCM2835_WDT=y
CONFIG_BCM47XX_WDT=y
-CONFIG_BCM7038_WDT=m
+CONFIG_BCM2835_WDT=y
CONFIG_BCM_KONA_WDT=y
+CONFIG_BCM7038_WDT=m
+CONFIG_BCMA_HOST_SOC=y
+CONFIG_BCMA_DRIVER_GMAC_CMN=y
+CONFIG_BCMA_DRIVER_GPIO=y
CONFIG_MFD_ACT8945A=y
CONFIG_MFD_AS3711=y
CONFIG_MFD_AS3722=y
-------------- 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/20180517/3abedbbc/attachment.sig>
^ permalink raw reply
* [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware
From: Brian Norris @ 2018-05-16 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526354560-23135-4-git-send-email-hl@rock-chips.com>
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
Please rerun checkpatch next time. You've got a bunch of whitespace
issues in cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link().
Brian
^ permalink raw reply
* [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Jacob Pan @ 2018-05-16 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-4-jean-philippe.brucker@arm.com>
On Fri, 11 May 2018 20:06:04 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> Allocate IOMMU mm structures and binding them to devices. Four
> operations are added to IOMMU drivers:
>
> * mm_alloc(): to create an io_mm structure and perform architecture-
> specific operations required to grab the process (for instance on
> ARM, pin down the CPU ASID so that the process doesn't get assigned a
> new ASID on rollover).
>
> There is a single valid io_mm structure per Linux mm. Future
> extensions may also use io_mm for kernel-managed address spaces,
> populated with map()/unmap() calls instead of bound to process
> address spaces. This patch focuses on "shared" io_mm.
>
> * mm_attach(): attach an mm to a device. The IOMMU driver checks that
> the device is capable of sharing an address space, and writes the
> PASID table entry to install the pgd.
>
> Some IOMMU drivers will have a single PASID table per domain, for
> convenience. Other can implement it differently but to help these
> drivers, mm_attach and mm_detach take 'attach_domain' and
> 'detach_domain' parameters, that tell whether they need to set and
> clear the PASID entry or only send the required TLB invalidations.
>
> * mm_detach(): detach an mm from a device. The IOMMU driver removes
> the PASID table entry and invalidates the IOTLBs.
>
> * mm_free(): free a structure allocated by mm_alloc(), and let arch
> release the process.
>
> mm_attach and mm_detach operations are serialized with a spinlock.
> When trying to optimize this code, we should at least prevent
> concurrent attach()/detach() on the same domain (so multi-level PASID
> table code can allocate tables lazily). mm_alloc() can sleep, but
> mm_free must not (because we'll have to call it from call_srcu later
> on).
>
> At the moment we use an IDR for allocating PASIDs and retrieving
> contexts. We also use a single spinlock. These can be refined and
> optimized later (a custom allocator will be needed for top-down PASID
> allocation).
>
> Keeping track of address spaces requires the use of MMU notifiers.
> Handling process exit with regard to unbind() is tricky, so it is
> left for another patch and we explicitly fail mm_alloc() for the
> moment.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>
> ---
> v1->v2: sanity-check of flags
> ---
> drivers/iommu/iommu-sva.c | 380
> +++++++++++++++++++++++++++++++++++++- drivers/iommu/iommu.c |
> 1 + include/linux/iommu.h | 28 +++
> 3 files changed, 406 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index 8d98f9c09864..6ac679c48f3c 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -5,8 +5,298 @@
> * Copyright (C) 2018 ARM Ltd.
> */
>
> +#include <linux/idr.h>
> #include <linux/iommu.h>
> +#include <linux/sched/mm.h>
> #include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +/**
> + * DOC: io_mm model
> + *
> + * The io_mm keeps track of process address spaces shared between
> CPU and IOMMU.
> + * The following example illustrates the relation between structures
> + * iommu_domain, io_mm and iommu_bond. An iommu_bond is a link
> between io_mm and
> + * device. A device can have multiple io_mm and an io_mm may be
> bound to
> + * multiple devices.
> + * ___________________________
> + * | IOMMU domain A |
> + * | ________________ |
> + * | | IOMMU group | +------- io_pgtables
> + * | | | |
> + * | | dev 00:00.0 ----+------- bond --- io_mm X
> + * | |________________| \ |
> + * | '----- bond ---.
> + * |___________________________| \
> + * ___________________________ \
> + * | IOMMU domain B | io_mm Y
> + * | ________________ | / /
> + * | | IOMMU group | | / /
> + * | | | | / /
> + * | | dev 00:01.0 ------------ bond -' /
> + * | | dev 00:01.1 ------------ bond --'
> + * | |________________| |
> + * | +------- io_pgtables
> + * |___________________________|
> + *
> + * In this example, device 00:00.0 is in domain A, devices 00:01.*
> are in domain
> + * B. All devices within the same domain access the same address
> spaces. Device
> + * 00:00.0 accesses address spaces X and Y, each corresponding to an
> mm_struct.
> + * Devices 00:01.* only access address space Y. In addition each
> + * IOMMU_DOMAIN_DMA domain has a private address space, io_pgtable,
> that is
> + * managed with iommu_map()/iommu_unmap(), and isn't shared with the
> CPU MMU.
> + *
> + * To obtain the above configuration, users would for instance issue
> the
> + * following calls:
> + *
> + * iommu_sva_bind_device(dev 00:00.0, mm X, ...) -> PASID 1
> + * iommu_sva_bind_device(dev 00:00.0, mm Y, ...) -> PASID 2
> + * iommu_sva_bind_device(dev 00:01.0, mm Y, ...) -> PASID 2
> + * iommu_sva_bind_device(dev 00:01.1, mm Y, ...) -> PASID 2
> + *
> + * A single Process Address Space ID (PASID) is allocated for each
> mm. In the
> + * example, devices use PASID 1 to read/write into address space X
> and PASID 2
> + * to read/write into address space Y.
> + *
> + * Hardware tables describing this configuration in the IOMMU would
> typically
> + * look like this:
> + *
> + * PASID tables
> + * of domain A
> + * .->+--------+
> + * / 0 | |-------> io_pgtable
> + * / +--------+
> + * Device tables / 1 | |-------> pgd X
> + * +--------+ / +--------+
> + * 00:00.0 | A |-' 2 | |--.
> + * +--------+ +--------+ \
> + * : : 3 | | \
> + * +--------+ +--------+ --> pgd Y
> + * 00:01.0 | B |--. /
> + * +--------+ \ |
> + * 00:01.1 | B |----+ PASID tables |
> + * +--------+ \ of domain B |
> + * '->+--------+ |
> + * 0 | |-- | --> io_pgtable
> + * +--------+ |
> + * 1 | | |
> + * +--------+ |
> + * 2 | |---'
> + * +--------+
> + * 3 | |
> + * +--------+
> + *
I am a little confused about domain vs. pasid relationship. If
each domain represents a address space, should there be a domain for
each pasid?
> + * With this model, a single call binds all devices in a given
> domain to an
> + * address space. Other devices in the domain will get the same bond
> implicitly.
> + * However, users must issue one bind() for each device, because
> IOMMUs may
> + * implement SVA differently. Furthermore, mandating one bind() per
> device
> + * allows the driver to perform sanity-checks on device capabilities.
> + *
> + * On Arm and AMD IOMMUs, entry 0 of the PASID table can be used to
> hold
> + * non-PASID translations. In this case PASID 0 is reserved and
> entry 0 points
> + * to the io_pgtable base. On Intel IOMMU, the io_pgtable base would
> be held in
> + * the device table and PASID 0 would be available to the allocator.
> + */
> +
> +struct iommu_bond {
> + struct io_mm *io_mm;
> + struct device *dev;
> + struct iommu_domain *domain;
> +
> + struct list_head mm_head;
> + struct list_head dev_head;
> + struct list_head domain_head;
> +
> + void *drvdata;
> +};
> +
> +/*
> + * Because we're using an IDR, PASIDs are limited to 31 bits (the
> sign bit is
> + * used for returning errors). In practice implementations will use
> at most 20
> + * bits, which is the PCI limit.
> + */
> +static DEFINE_IDR(iommu_pasid_idr);
> +
> +/*
> + * For the moment this is an all-purpose lock. It serializes
> + * access/modifications to bonds, access/modifications to the PASID
> IDR, and
> + * changes to io_mm refcount as well.
> + */
> +static DEFINE_SPINLOCK(iommu_sva_lock);
> +
> +static struct io_mm *
> +io_mm_alloc(struct iommu_domain *domain, struct device *dev,
> + struct mm_struct *mm, unsigned long flags)
> +{
> + int ret;
> + int pasid;
> + struct io_mm *io_mm;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + if (!domain->ops->mm_alloc || !domain->ops->mm_free)
> + return ERR_PTR(-ENODEV);
> +
> + io_mm = domain->ops->mm_alloc(domain, mm, flags);
> + if (IS_ERR(io_mm))
> + return io_mm;
> + if (!io_mm)
> + return ERR_PTR(-ENOMEM);
> +
> + /*
> + * The mm must not be freed until after the driver frees the
> io_mm
> + * (which may involve unpinning the CPU ASID for instance,
> requiring a
> + * valid mm struct.)
> + */
> + mmgrab(mm);
> +
> + io_mm->flags = flags;
> + io_mm->mm = mm;
> + io_mm->release = domain->ops->mm_free;
> + INIT_LIST_HEAD(&io_mm->devices);
> +
> + idr_preload(GFP_KERNEL);
> + spin_lock(&iommu_sva_lock);
> + pasid = idr_alloc(&iommu_pasid_idr, io_mm, param->min_pasid,
> + param->max_pasid + 1, GFP_ATOMIC);
> + io_mm->pasid = pasid;
> + spin_unlock(&iommu_sva_lock);
> + idr_preload_end();
> +
> + if (pasid < 0) {
> + ret = pasid;
> + goto err_free_mm;
> + }
> +
> + /* TODO: keep track of mm. For the moment, abort. */
> + ret = -ENOSYS;
> + spin_lock(&iommu_sva_lock);
> + idr_remove(&iommu_pasid_idr, io_mm->pasid);
> + spin_unlock(&iommu_sva_lock);
> +
> +err_free_mm:
> + domain->ops->mm_free(io_mm);
> + mmdrop(mm);
> +
> + return ERR_PTR(ret);
> +}
> +
> +static void io_mm_free(struct io_mm *io_mm)
> +{
> + struct mm_struct *mm = io_mm->mm;
> +
> + io_mm->release(io_mm);
> + mmdrop(mm);
> +}
> +
> +static void io_mm_release(struct kref *kref)
> +{
> + struct io_mm *io_mm;
> +
> + io_mm = container_of(kref, struct io_mm, kref);
> + WARN_ON(!list_empty(&io_mm->devices));
> +
> + idr_remove(&iommu_pasid_idr, io_mm->pasid);
> +
> + io_mm_free(io_mm);
> +}
> +
> +/*
> + * Returns non-zero if a reference to the io_mm was successfully
> taken.
> + * Returns zero if the io_mm is being freed and should not be used.
> + */
> +static int io_mm_get_locked(struct io_mm *io_mm)
> +{
> + if (io_mm)
> + return kref_get_unless_zero(&io_mm->kref);
> +
> + return 0;
> +}
> +
> +static void io_mm_put_locked(struct io_mm *io_mm)
> +{
> + kref_put(&io_mm->kref, io_mm_release);
> +}
> +
> +static void io_mm_put(struct io_mm *io_mm)
> +{
> + spin_lock(&iommu_sva_lock);
> + io_mm_put_locked(io_mm);
> + spin_unlock(&iommu_sva_lock);
> +}
> +
> +static int io_mm_attach(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, void *drvdata)
> +{
> + int ret;
> + bool attach_domain = true;
> + int pasid = io_mm->pasid;
> + struct iommu_bond *bond, *tmp;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + if (!domain->ops->mm_attach || !domain->ops->mm_detach)
> + return -ENODEV;
> +
> + if (pasid > param->max_pasid || pasid < param->min_pasid)
> + return -ERANGE;
> +
> + bond = kzalloc(sizeof(*bond), GFP_KERNEL);
> + if (!bond)
> + return -ENOMEM;
> +
> + bond->domain = domain;
> + bond->io_mm = io_mm;
> + bond->dev = dev;
> + bond->drvdata = drvdata;
> +
> + spin_lock(&iommu_sva_lock);
> + /*
> + * Check if this io_mm is already bound to the domain. In
> which case the
> + * IOMMU driver doesn't have to install the PASID table
> entry.
> + */
> + list_for_each_entry(tmp, &domain->mm_list, domain_head) {
> + if (tmp->io_mm == io_mm) {
> + attach_domain = false;
> + break;
> + }
> + }
> +
> + ret = domain->ops->mm_attach(domain, dev, io_mm,
> attach_domain);
> + if (ret) {
> + kfree(bond);
> + spin_unlock(&iommu_sva_lock);
> + return ret;
> + }
> +
> + list_add(&bond->mm_head, &io_mm->devices);
> + list_add(&bond->domain_head, &domain->mm_list);
> + list_add(&bond->dev_head, ¶m->mm_list);
> + spin_unlock(&iommu_sva_lock);
> +
> + return 0;
> +}
> +
> +static void io_mm_detach_locked(struct iommu_bond *bond)
> +{
> + struct iommu_bond *tmp;
> + bool detach_domain = true;
> + struct iommu_domain *domain = bond->domain;
> +
> + list_for_each_entry(tmp, &domain->mm_list, domain_head) {
> + if (tmp->io_mm == bond->io_mm && tmp->dev !=
> bond->dev) {
> + detach_domain = false;
> + break;
> + }
> + }
> +
> + domain->ops->mm_detach(domain, bond->dev, bond->io_mm,
> detach_domain); +
> + list_del(&bond->mm_head);
> + list_del(&bond->domain_head);
> + list_del(&bond->dev_head);
> + io_mm_put_locked(bond->io_mm);
> +
> + kfree(bond);
> +}
>
> /**
> * iommu_sva_device_init() - Initialize Shared Virtual Addressing
> for a device @@ -47,6 +337,7 @@ int iommu_sva_device_init(struct
> device *dev, unsigned long features,
> param->features = features;
> param->max_pasid = max_pasid;
> + INIT_LIST_HEAD(¶m->mm_list);
>
> /*
> * IOMMU driver updates the limits depending on the IOMMU
> and device @@ -114,13 +405,87 @@
> EXPORT_SYMBOL_GPL(iommu_sva_device_shutdown); int
> __iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, int
> *pasid, unsigned long flags, void *drvdata) {
> - return -ENOSYS; /* TODO */
> + int i, ret = 0;
> + struct io_mm *io_mm = NULL;
> + struct iommu_domain *domain;
> + struct iommu_bond *bond = NULL, *tmp;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + domain = iommu_get_domain_for_dev(dev);
> + if (!domain)
> + return -EINVAL;
> +
> + /*
> + * The device driver does not call sva_device_init/shutdown
> and
> + * bind/unbind concurrently, so no need to take the param
> lock.
> + */
> + if (WARN_ON_ONCE(!param) || (flags & ~param->features))
> + return -EINVAL;
> +
> + /* If an io_mm already exists, use it */
> + spin_lock(&iommu_sva_lock);
> + idr_for_each_entry(&iommu_pasid_idr, io_mm, i) {
> + if (io_mm->mm == mm && io_mm_get_locked(io_mm)) {
> + /* ... Unless it's already bound to this
> device */
> + list_for_each_entry(tmp, &io_mm->devices,
> mm_head) {
> + if (tmp->dev == dev) {
> + bond = tmp;
> + io_mm_put_locked(io_mm);
> + break;
> + }
> + }
> + break;
> + }
> + }
> + spin_unlock(&iommu_sva_lock);
> +
> + if (bond)
> + return -EEXIST;
> +
> + /* Require identical features within an io_mm for now */
> + if (io_mm && (flags != io_mm->flags)) {
> + io_mm_put(io_mm);
> + return -EDOM;
> + }
> +
> + if (!io_mm) {
> + io_mm = io_mm_alloc(domain, dev, mm, flags);
> + if (IS_ERR(io_mm))
> + return PTR_ERR(io_mm);
> + }
> +
> + ret = io_mm_attach(domain, dev, io_mm, drvdata);
> + if (ret)
> + io_mm_put(io_mm);
> + else
> + *pasid = io_mm->pasid;
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_bind_device);
>
> int __iommu_sva_unbind_device(struct device *dev, int pasid)
> {
> - return -ENOSYS; /* TODO */
> + int ret = -ESRCH;
> + struct iommu_domain *domain;
> + struct iommu_bond *bond = NULL;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + domain = iommu_get_domain_for_dev(dev);
> + if (!param || WARN_ON(!domain))
> + return -EINVAL;
> +
> + spin_lock(&iommu_sva_lock);
> + list_for_each_entry(bond, ¶m->mm_list, dev_head) {
> + if (bond->io_mm->pasid == pasid) {
> + io_mm_detach_locked(bond);
> + ret = 0;
> + break;
> + }
> + }
> + spin_unlock(&iommu_sva_lock);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
>
> @@ -132,6 +497,15 @@ EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
> */
> void __iommu_sva_unbind_dev_all(struct device *dev)
> {
> - /* TODO */
> + struct iommu_sva_param *param;
> + struct iommu_bond *bond, *next;
> +
> + param = dev->iommu_param->sva_param;
> + if (param) {
> + spin_lock(&iommu_sva_lock);
> + list_for_each_entry_safe(bond, next,
> ¶m->mm_list, dev_head)
> + io_mm_detach_locked(bond);
> + spin_unlock(&iommu_sva_lock);
> + }
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_unbind_dev_all);
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index bd2819deae5b..333801e1519c 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1463,6 +1463,7 @@ static struct iommu_domain
> *__iommu_domain_alloc(struct bus_type *bus, domain->type = type;
> /* Assume all sizes by default; the driver may override this
> later */ domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap;
> + INIT_LIST_HEAD(&domain->mm_list);
>
> return domain;
> }
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index da59c20c4f12..d5f21719a5a0 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -100,6 +100,20 @@ struct iommu_domain {
> void *handler_token;
> struct iommu_domain_geometry geometry;
> void *iova_cookie;
> +
> + struct list_head mm_list;
> +};
> +
> +struct io_mm {
> + int pasid;
> + /* IOMMU_SVA_FEAT_* */
> + unsigned long flags;
> + struct list_head devices;
> + struct kref kref;
> + struct mm_struct *mm;
> +
> + /* Release callback for this mm */
> + void (*release)(struct io_mm *io_mm);
> };
>
> enum iommu_cap {
> @@ -216,6 +230,7 @@ struct iommu_sva_param {
> unsigned long features;
> unsigned int min_pasid;
> unsigned int max_pasid;
> + struct list_head mm_list;
> };
>
> /**
> @@ -227,6 +242,11 @@ struct iommu_sva_param {
> * @detach_dev: detach device from an iommu domain
> * @sva_device_init: initialize Shared Virtual Adressing for a device
> * @sva_device_shutdown: shutdown Shared Virtual Adressing for a
> device
> + * @mm_alloc: allocate io_mm
> + * @mm_free: free io_mm
> + * @mm_attach: attach io_mm to a device. Install PASID entry if
> necessary
> + * @mm_detach: detach io_mm from a device. Remove PASID entry and
> + * flush associated TLB entries.
> * @map: map a physically contiguous memory region to an iommu domain
> * @unmap: unmap a physically contiguous memory region from an iommu
> domain
> * @map_sg: map a scatter-gather list of physically contiguous
> memory chunks @@ -268,6 +288,14 @@ struct iommu_ops {
> struct iommu_sva_param *param);
> void (*sva_device_shutdown)(struct device *dev,
> struct iommu_sva_param *param);
> + struct io_mm *(*mm_alloc)(struct iommu_domain *domain,
> + struct mm_struct *mm,
> + unsigned long flags);
> + void (*mm_free)(struct io_mm *io_mm);
> + int (*mm_attach)(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, bool attach_domain);
> + void (*mm_detach)(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, bool detach_domain);
> int (*map)(struct iommu_domain *domain, unsigned long iova,
> phys_addr_t paddr, size_t size, int prot);
> size_t (*unmap)(struct iommu_domain *domain, unsigned long
> iova,
[Jacob Pan]
^ permalink raw reply
* [PATCH v3 0/3] fix free pmd/pte page handlings on x86
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
This series fixes two issues in the x86 ioremap free page handlings
for pud/pmd mappings.
Patch 01 fixes BUG_ON on x86-PAE reported by Joerg. It disables
the free page handling on x86-PAE.
Patch 02-03 fixes a possible issue with speculation which can cause
stale page-directory cache.
- Patch 02 is from Chintan's v9 01/04 patch [1], which adds a new arg
'addr', with my merge change to patch 01.
- Patch 03 adds a TLB purge (INVLPG) to purge page-structure caches
that may be cached by speculation. See the patch descriptions for
more detal.
[1] https://patchwork.kernel.org/patch/10371015/
v3:
- Fixed a build error in v2.
v2:
- Reordered patch-set, so that patch 01 can be applied independently.
- Added a NULL pointer check for the page alloc in patch 03.
---
Toshi Kani (2):
1/3 x86/mm: disable ioremap free page handling on x86-PAE
3/3 x86/mm: add TLB purge to free pmd/pte page interfaces
Chintan Pandya (1):
2/3 ioremap: Update pgtable free interfaces with addr
---
arch/arm64/mm/mmu.c | 4 +--
arch/x86/mm/pgtable.c | 59 +++++++++++++++++++++++++++++++++++++------
include/asm-generic/pgtable.h | 8 +++---
lib/ioremap.c | 4 +--
4 files changed, 59 insertions(+), 16 deletions(-)
^ 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