* [PATCH v5 0/5] Microchip TCB Capture driver
From: Kamel Bouhara @ 2020-05-19 8:37 UTC (permalink / raw)
To: William Breathitt Gray, Rob Herring, Mark Rutland, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Cc: linux-iio, devicetree, Kamel Bouhara, Thomas Petazzoni,
linux-input
Hello,
Here is a new counter driver to support Microchip TCB capture devices.
Each SoC has two TCB blocks, each one including three independent
channels.The following series adds support for two counter modes:
increase and quadrature decoder.
As for the atmel clocksource and pwm, the counter driver needs to fill
some tcb capabilities in order to operate with the right configuration.
This is achieved in first patch of this series.
Please feel free to comment.
Cheers,
Changes in v5:
- Fix duplicate keys errors in yaml dt-schema
Changes in v4:
- Use existing binding to document capture mode of the Microchip TCBs.
Changes in v3:
- Updated the brand name: s/atmel/microchip/.
- Added missing kernel doc for new elements introduced in structure
atmel_tcb_config.
- Removed useless blank line
- Added an explicit clock removing path using devm_add_action_or_reset
Changes in v2:
- Fixed first patch not applying on mainline
- Updated return code to -EINVAL when user is requesting qdec mode on
a counter device not supporting it.
- Added an error case returning -EINVAL when action edge is performed
in
qdec mode.
- Removed no need to explicity setting ops to NULL from static struct
as
it is the default value.
- Changed confusing code by using snprintf for the sake of clarity.
- Changed code to use ARRAY_SIZE so that future reviewers will know
that num_counts matches what's in the atmel_tc_count array without
having to check so themselves.
- Fixed errors reported by dt_binding_check
Alexandre Belloni (2):
dt-bindings: atmel-tcb: convert bindings to json-schema
dt-bindings: microchip: atmel,at91rm9200-tcb: add sama5d2 compatible
Kamel Bouhara (3):
ARM: at91: add atmel tcb capabilities
dt-bindings: counter: microchip-tcb-capture counter
counter: Add microchip TCB capture counter
.../devicetree/bindings/mfd/atmel-tcb.txt | 56 ---
.../soc/microchip/atmel,at91rm9200-tcb.yaml | 176 ++++++++
drivers/counter/Kconfig | 11 +
drivers/counter/Makefile | 1 +
drivers/counter/microchip-tcb-capture.c | 397 ++++++++++++++++++
include/soc/at91/atmel_tcb.h | 5 +
6 files changed, 590 insertions(+), 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
create mode 100644 Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
create mode 100644 drivers/counter/microchip-tcb-capture.c
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 5/5] counter: Add microchip TCB capture counter
From: Kamel Bouhara @ 2020-05-19 8:37 UTC (permalink / raw)
To: William Breathitt Gray, Rob Herring, Mark Rutland, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Cc: linux-iio, devicetree, Kamel Bouhara, Thomas Petazzoni,
linux-input
In-Reply-To: <20200519083716.938384-1-kamel.bouhara@bootlin.com>
This drivers allows to use the capture mode of the Timer Counter Block
hardware block available in Microchip SoCs through the counter subsystem.
Two functions of the counter are supported for the moment: period
capture and quadrature decoder. The latter is only supported by the
SAMA5 series of SoCs.
For the period capture mode a basic setup has been chosen that will
reset the counter each time the period is actually reached. Of course
the device offers much more possibilities.
For quadrature mode, both channel 0 and 1 must be configured even if we
only capture the position (no revolution/rotation).
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
drivers/counter/Kconfig | 11 +
drivers/counter/Makefile | 1 +
drivers/counter/microchip-tcb-capture.c | 397 ++++++++++++++++++++++++
3 files changed, 409 insertions(+)
create mode 100644 drivers/counter/microchip-tcb-capture.c
diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
index c80fa76bb531..2de53ab0dd25 100644
--- a/drivers/counter/Kconfig
+++ b/drivers/counter/Kconfig
@@ -70,4 +70,15 @@ config FTM_QUADDEC
To compile this driver as a module, choose M here: the
module will be called ftm-quaddec.
+config MICROCHIP_TCB_CAPTURE
+ tristate "Microchip Timer Counter Capture driver"
+ depends on HAS_IOMEM && OF
+ select REGMAP_MMIO
+ help
+ Select this option to enable the Microchip Timer Counter Block
+ capture driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called microchip-tcb-capture.
+
endif # COUNTER
diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
index 55142d1f4c43..0a393f71e481 100644
--- a/drivers/counter/Makefile
+++ b/drivers/counter/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_STM32_TIMER_CNT) += stm32-timer-cnt.o
obj-$(CONFIG_STM32_LPTIMER_CNT) += stm32-lptimer-cnt.o
obj-$(CONFIG_TI_EQEP) += ti-eqep.o
obj-$(CONFIG_FTM_QUADDEC) += ftm-quaddec.o
+obj-$(CONFIG_MICROCHIP_TCB_CAPTURE) += microchip-tcb-capture.o
diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c
new file mode 100644
index 000000000000..f7b7743ddb94
--- /dev/null
+++ b/drivers/counter/microchip-tcb-capture.c
@@ -0,0 +1,397 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/**
+ * Copyright (C) 2020 Microchip
+ *
+ * Author: Kamel Bouhara <kamel.bouhara@bootlin.com>
+ */
+#include <linux/clk.h>
+#include <linux/counter.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <soc/at91/atmel_tcb.h>
+
+#define ATMEL_TC_CMR_MASK (ATMEL_TC_LDRA_RISING | ATMEL_TC_LDRB_FALLING | \
+ ATMEL_TC_ETRGEDG_RISING | ATMEL_TC_LDBDIS | \
+ ATMEL_TC_LDBSTOP)
+
+#define ATMEL_TC_QDEN BIT(8)
+#define ATMEL_TC_POSEN BIT(9)
+
+struct mchp_tc_data {
+ const struct atmel_tcb_config *tc_cfg;
+ struct counter_device counter;
+ struct regmap *regmap;
+ int qdec_mode;
+ int num_channels;
+ int channel[2];
+ bool trig_inverted;
+};
+
+enum mchp_tc_count_function {
+ MCHP_TC_FUNCTION_INCREASE,
+ MCHP_TC_FUNCTION_QUADRATURE,
+};
+
+static enum counter_count_function mchp_tc_count_functions[] = {
+ [MCHP_TC_FUNCTION_INCREASE] = COUNTER_COUNT_FUNCTION_INCREASE,
+ [MCHP_TC_FUNCTION_QUADRATURE] = COUNTER_COUNT_FUNCTION_QUADRATURE_X4,
+};
+
+enum mchp_tc_synapse_action {
+ MCHP_TC_SYNAPSE_ACTION_NONE = 0,
+ MCHP_TC_SYNAPSE_ACTION_RISING_EDGE,
+ MCHP_TC_SYNAPSE_ACTION_FALLING_EDGE,
+ MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE
+};
+
+static enum counter_synapse_action mchp_tc_synapse_actions[] = {
+ [MCHP_TC_SYNAPSE_ACTION_NONE] = COUNTER_SYNAPSE_ACTION_NONE,
+ [MCHP_TC_SYNAPSE_ACTION_RISING_EDGE] = COUNTER_SYNAPSE_ACTION_RISING_EDGE,
+ [MCHP_TC_SYNAPSE_ACTION_FALLING_EDGE] = COUNTER_SYNAPSE_ACTION_FALLING_EDGE,
+ [MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE] = COUNTER_SYNAPSE_ACTION_BOTH_EDGES,
+};
+
+static struct counter_signal mchp_tc_count_signals[] = {
+ {
+ .id = 0,
+ .name = "Channel A",
+ },
+ {
+ .id = 1,
+ .name = "Channel B",
+ }
+};
+
+static struct counter_synapse mchp_tc_count_synapses[] = {
+ {
+ .actions_list = mchp_tc_synapse_actions,
+ .num_actions = ARRAY_SIZE(mchp_tc_synapse_actions),
+ .signal = &mchp_tc_count_signals[0]
+ },
+ {
+ .actions_list = mchp_tc_synapse_actions,
+ .num_actions = ARRAY_SIZE(mchp_tc_synapse_actions),
+ .signal = &mchp_tc_count_signals[1]
+ }
+};
+
+static int mchp_tc_count_function_get(struct counter_device *counter,
+ struct counter_count *count,
+ size_t *function)
+{
+ struct mchp_tc_data *const priv = counter->priv;
+
+ if (priv->qdec_mode)
+ *function = MCHP_TC_FUNCTION_QUADRATURE;
+ else
+ *function = MCHP_TC_FUNCTION_INCREASE;
+
+ return 0;
+}
+
+static int mchp_tc_count_function_set(struct counter_device *counter,
+ struct counter_count *count,
+ size_t function)
+{
+ struct mchp_tc_data *const priv = counter->priv;
+ u32 bmr, cmr;
+
+ regmap_read(priv->regmap, ATMEL_TC_BMR, &bmr);
+ regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], CMR), &cmr);
+
+ /* Set capture mode */
+ cmr &= ~ATMEL_TC_WAVE;
+
+ switch (function) {
+ case MCHP_TC_FUNCTION_INCREASE:
+ priv->qdec_mode = 0;
+ /* Set highest rate based on whether soc has gclk or not */
+ bmr &= ~(ATMEL_TC_QDEN | ATMEL_TC_POSEN);
+ if (priv->tc_cfg->has_gclk)
+ cmr |= ATMEL_TC_TIMER_CLOCK2;
+ else
+ cmr |= ATMEL_TC_TIMER_CLOCK1;
+ /* Setup the period capture mode */
+ cmr |= ATMEL_TC_CMR_MASK;
+ cmr &= ~(ATMEL_TC_ABETRG | ATMEL_TC_XC0);
+ break;
+ case MCHP_TC_FUNCTION_QUADRATURE:
+ if (!priv->tc_cfg->has_qdec)
+ return -EINVAL;
+ /* In QDEC mode settings both channels 0 and 1 are required */
+ if (priv->num_channels < 2 || priv->channel[0] != 0 ||
+ priv->channel[1] != 1) {
+ pr_err("Invalid channels number or id for quadrature mode\n");
+ return -EINVAL;
+ }
+ priv->qdec_mode = 1;
+ bmr |= ATMEL_TC_QDEN | ATMEL_TC_POSEN;
+ cmr |= ATMEL_TC_ETRGEDG_RISING | ATMEL_TC_ABETRG | ATMEL_TC_XC0;
+ break;
+ }
+
+ regmap_write(priv->regmap, ATMEL_TC_BMR, bmr);
+ regmap_write(priv->regmap, ATMEL_TC_REG(priv->channel[0], CMR), cmr);
+
+ /* Enable clock and trigger counter */
+ regmap_write(priv->regmap, ATMEL_TC_REG(priv->channel[0], CCR),
+ ATMEL_TC_CLKEN | ATMEL_TC_SWTRG);
+
+ if (priv->qdec_mode) {
+ regmap_write(priv->regmap,
+ ATMEL_TC_REG(priv->channel[1], CMR), cmr);
+ regmap_write(priv->regmap,
+ ATMEL_TC_REG(priv->channel[1], CCR),
+ ATMEL_TC_CLKEN | ATMEL_TC_SWTRG);
+ }
+
+ return 0;
+}
+
+static int mchp_tc_count_signal_read(struct counter_device *counter,
+ struct counter_signal *signal,
+ enum counter_signal_value *val)
+{
+ struct mchp_tc_data *const priv = counter->priv;
+ bool sigstatus;
+ u32 sr;
+
+ regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], SR), &sr);
+
+ if (priv->trig_inverted)
+ sigstatus = (sr & ATMEL_TC_MTIOB);
+ else
+ sigstatus = (sr & ATMEL_TC_MTIOA);
+
+ *val = sigstatus ? COUNTER_SIGNAL_HIGH : COUNTER_SIGNAL_LOW;
+
+ return 0;
+}
+
+static int mchp_tc_count_action_get(struct counter_device *counter,
+ struct counter_count *count,
+ struct counter_synapse *synapse,
+ size_t *action)
+{
+ struct mchp_tc_data *const priv = counter->priv;
+ u32 cmr;
+
+ regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], CMR), &cmr);
+
+ *action = MCHP_TC_SYNAPSE_ACTION_NONE;
+
+ if (cmr & ATMEL_TC_ETRGEDG_NONE)
+ *action = MCHP_TC_SYNAPSE_ACTION_NONE;
+ else if (cmr & ATMEL_TC_ETRGEDG_RISING)
+ *action = MCHP_TC_SYNAPSE_ACTION_RISING_EDGE;
+ else if (cmr & ATMEL_TC_ETRGEDG_FALLING)
+ *action = MCHP_TC_SYNAPSE_ACTION_FALLING_EDGE;
+ else if (cmr & ATMEL_TC_ETRGEDG_BOTH)
+ *action = MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE;
+
+ return 0;
+}
+
+static int mchp_tc_count_action_set(struct counter_device *counter,
+ struct counter_count *count,
+ struct counter_synapse *synapse,
+ size_t action)
+{
+ struct mchp_tc_data *const priv = counter->priv;
+ u32 edge = ATMEL_TC_ETRGEDG_NONE;
+
+ /* QDEC mode is rising edge only */
+ if (priv->qdec_mode)
+ return -EINVAL;
+
+ switch (action) {
+ case MCHP_TC_SYNAPSE_ACTION_NONE:
+ edge = ATMEL_TC_ETRGEDG_NONE;
+ break;
+ case MCHP_TC_SYNAPSE_ACTION_RISING_EDGE:
+ edge = ATMEL_TC_ETRGEDG_RISING;
+ break;
+ case MCHP_TC_SYNAPSE_ACTION_FALLING_EDGE:
+ edge = ATMEL_TC_ETRGEDG_FALLING;
+ break;
+ case MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE:
+ edge = ATMEL_TC_ETRGEDG_BOTH;
+ break;
+ }
+
+ return regmap_write_bits(priv->regmap,
+ ATMEL_TC_REG(priv->channel[0], CMR),
+ ATMEL_TC_ETRGEDG, edge);
+}
+
+static int mchp_tc_count_read(struct counter_device *counter,
+ struct counter_count *count,
+ unsigned long *val)
+{
+ struct mchp_tc_data *const priv = counter->priv;
+ u32 cnt;
+
+ regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], CV), &cnt);
+ *val = cnt;
+
+ return 0;
+}
+
+static struct counter_count mchp_tc_counts[] = {
+ {
+ .id = 0,
+ .name = "Timer Counter",
+ .functions_list = mchp_tc_count_functions,
+ .num_functions = ARRAY_SIZE(mchp_tc_count_functions),
+ .synapses = mchp_tc_count_synapses,
+ .num_synapses = ARRAY_SIZE(mchp_tc_count_synapses),
+ },
+};
+
+static struct counter_ops mchp_tc_ops = {
+ .signal_read = mchp_tc_count_signal_read,
+ .count_read = mchp_tc_count_read,
+ .function_get = mchp_tc_count_function_get,
+ .function_set = mchp_tc_count_function_set,
+ .action_get = mchp_tc_count_action_get,
+ .action_set = mchp_tc_count_action_set
+};
+
+static const struct atmel_tcb_config tcb_rm9200_config = {
+ .counter_width = 16,
+};
+
+static const struct atmel_tcb_config tcb_sam9x5_config = {
+ .counter_width = 32,
+};
+
+static const struct atmel_tcb_config tcb_sama5d2_config = {
+ .counter_width = 32,
+ .has_gclk = true,
+ .has_qdec = true,
+};
+
+static const struct atmel_tcb_config tcb_sama5d3_config = {
+ .counter_width = 32,
+ .has_qdec = true,
+};
+
+static const struct of_device_id atmel_tc_of_match[] = {
+ { .compatible = "atmel,at91rm9200-tcb", .data = &tcb_rm9200_config, },
+ { .compatible = "atmel,at91sam9x5-tcb", .data = &tcb_sam9x5_config, },
+ { .compatible = "atmel,sama5d2-tcb", .data = &tcb_sama5d2_config, },
+ { .compatible = "atmel,sama5d3-tcb", .data = &tcb_sama5d3_config, },
+ { /* sentinel */ }
+};
+
+static void mchp_tc_clk_remove(void *ptr)
+{
+ clk_disable_unprepare((struct clk *)ptr);
+}
+
+static int mchp_tc_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct atmel_tcb_config *tcb_config;
+ const struct of_device_id *match;
+ struct mchp_tc_data *priv;
+ char clk_name[7];
+ struct regmap *regmap;
+ struct clk *clk[3];
+ int channel;
+ int ret, i;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ match = of_match_node(atmel_tc_of_match, np->parent);
+ tcb_config = match->data;
+ if (!tcb_config) {
+ dev_err(&pdev->dev, "No matching parent node found\n");
+ return -ENODEV;
+ }
+
+ regmap = syscon_node_to_regmap(np->parent);
+ if (IS_ERR(priv->regmap))
+ return PTR_ERR(priv->regmap);
+
+ /* max. channels number is 2 when in QDEC mode */
+ priv->num_channels = of_property_count_u32_elems(np, "reg");
+ if (priv->num_channels < 0) {
+ dev_err(&pdev->dev, "Invalid or missing channel\n");
+ return -EINVAL;
+ }
+
+ /* Register channels and initialize clocks */
+ for (i = 0; i < priv->num_channels; i++) {
+ ret = of_property_read_u32_index(np, "reg", i, &channel);
+ if (ret < 0 || channel > 2)
+ return -ENODEV;
+
+ priv->channel[i] = channel;
+
+ snprintf(clk_name, sizeof(clk_name), "t%d_clk", channel);
+
+ clk[i] = of_clk_get_by_name(np->parent, clk_name);
+ if (IS_ERR(clk[i])) {
+ /* Fallback to t0_clk */
+ clk[i] = of_clk_get_by_name(np->parent, "t0_clk");
+ if (IS_ERR(clk[i]))
+ return PTR_ERR(clk[i]);
+ }
+
+ ret = clk_prepare_enable(clk[i]);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(&pdev->dev,
+ mchp_tc_clk_remove,
+ clk[i]);
+ if (ret)
+ return ret;
+
+ dev_dbg(&pdev->dev,
+ "Initialized capture mode on channel %d\n",
+ channel);
+ }
+
+ priv->tc_cfg = tcb_config;
+ priv->regmap = regmap;
+ priv->counter.name = dev_name(&pdev->dev);
+ priv->counter.parent = &pdev->dev;
+ priv->counter.ops = &mchp_tc_ops;
+ priv->counter.num_counts = ARRAY_SIZE(mchp_tc_counts);
+ priv->counter.counts = mchp_tc_counts;
+ priv->counter.num_signals = ARRAY_SIZE(mchp_tc_count_signals);
+ priv->counter.signals = mchp_tc_count_signals;
+ priv->counter.priv = priv;
+
+ return devm_counter_register(&pdev->dev, &priv->counter);
+}
+
+static const struct of_device_id mchp_tc_dt_ids[] = {
+ { .compatible = "microchip,tcb-capture", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mchp_tc_dt_ids);
+
+static struct platform_driver mchp_tc_driver = {
+ .probe = mchp_tc_probe,
+ .driver = {
+ .name = "microchip-tcb-capture",
+ .of_match_table = mchp_tc_dt_ids,
+ },
+};
+module_platform_driver(mchp_tc_driver);
+
+MODULE_AUTHOR("Kamel Bouhara <kamel.bouhara@bootlin.com>");
+MODULE_DESCRIPTION("Microchip TCB Capture driver");
+MODULE_LICENSE("GPL v2");
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 4/5] dt-bindings: counter: microchip-tcb-capture counter
From: Kamel Bouhara @ 2020-05-19 8:37 UTC (permalink / raw)
To: William Breathitt Gray, Rob Herring, Mark Rutland, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Cc: linux-iio, devicetree, Kamel Bouhara, Thomas Petazzoni,
linux-input
In-Reply-To: <20200519083716.938384-1-kamel.bouhara@bootlin.com>
Describe the devicetree binding for the Microchip TCB module.
Each counter blocks exposes three independent counters.
However, when configured in quadrature decoder, both channel <0> and <1>
are required for speed/position and rotation capture (yet only the
position is captured).
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
.../soc/microchip/atmel,at91rm9200-tcb.yaml | 32 +++++++++++++++++--
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
index 38403760f64d..e3319c4501c1 100644
--- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
+++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
@@ -52,14 +52,20 @@ properties:
patternProperties:
"^timer@[0-2]$":
- description: The timer block channels that are used as timers.
+ description: The timer block channels that are used as timers or counters.
type: object
properties:
compatible:
- const: atmel,tcb-timer
+ items:
+ - enum:
+ - atmel,tcb-timer
+ - microchip,tcb-capture
reg:
description:
- List of channels to use for this particular timer.
+ List of channels to use for this particular timer. In Microchip TCB capture
+ mode channels are registered as a counter devices, for the qdec mode TCB0's
+ channel <0> and <1> are required.
+
minItems: 1
maxItems: 3
@@ -148,3 +154,23 @@ examples:
reg = <1>;
};
};
+ /* TCB0 Capture with QDEC: */
+ timer@f800c000 {
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfff7c000 0x100>;
+ interrupts = <18 4>;
+ clocks = <&tcb0_clk>, <&clk32k>;
+ clock-names = "t0_clk", "slow_clk";
+
+ timer@0 {
+ compatible = "microchip,tcb-capture";
+ reg = <0>, <1>;
+ };
+
+ timer@2 {
+ compatible = "atmel,tcb-timer";
+ reg = <2>;
+ };
+ };
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/5] dt-bindings: atmel-tcb: convert bindings to json-schema
From: Kamel Bouhara @ 2020-05-19 8:37 UTC (permalink / raw)
To: William Breathitt Gray, Rob Herring, Mark Rutland, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Cc: linux-iio, devicetree, Thomas Petazzoni, linux-input
In-Reply-To: <20200519083716.938384-1-kamel.bouhara@bootlin.com>
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Convert Atmel Timer Counter Blocks bindings to DT schema format using
json-schema.
Also move it out of mfd as it is not and has never been related to mfd.
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
.../devicetree/bindings/mfd/atmel-tcb.txt | 56 --------
.../soc/microchip/atmel,at91rm9200-tcb.yaml | 126 ++++++++++++++++++
2 files changed, 126 insertions(+), 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
create mode 100644 Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
diff --git a/Documentation/devicetree/bindings/mfd/atmel-tcb.txt b/Documentation/devicetree/bindings/mfd/atmel-tcb.txt
deleted file mode 100644
index c4a83e364cb6..000000000000
--- a/Documentation/devicetree/bindings/mfd/atmel-tcb.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Device tree bindings for Atmel Timer Counter Blocks
-- compatible: Should be "atmel,<chip>-tcb", "simple-mfd", "syscon".
- <chip> can be "at91rm9200" or "at91sam9x5"
-- reg: Should contain registers location and length
-- #address-cells: has to be 1
-- #size-cells: has to be 0
-- interrupts: Should contain all interrupts for the TC block
- Note that you can specify several interrupt cells if the TC
- block has one interrupt per channel.
-- clock-names: tuple listing input clock names.
- Required elements: "t0_clk", "slow_clk"
- Optional elements: "t1_clk", "t2_clk"
-- clocks: phandles to input clocks.
-
-The TCB can expose multiple subdevices:
- * a timer
- - compatible: Should be "atmel,tcb-timer"
- - reg: Should contain the TCB channels to be used. If the
- counter width is 16 bits (at91rm9200-tcb), two consecutive
- channels are needed. Else, only one channel will be used.
-
-Examples:
-
-One interrupt per TC block:
- tcb0: timer@fff7c000 {
- compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xfff7c000 0x100>;
- interrupts = <18 4>;
- clocks = <&tcb0_clk>, <&clk32k>;
- clock-names = "t0_clk", "slow_clk";
-
- timer@0 {
- compatible = "atmel,tcb-timer";
- reg = <0>, <1>;
- };
-
- timer@2 {
- compatible = "atmel,tcb-timer";
- reg = <2>;
- };
- };
-
-One interrupt per TC channel in a TC block:
- tcb1: timer@fffdc000 {
- compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xfffdc000 0x100>;
- interrupts = <26 4>, <27 4>, <28 4>;
- clocks = <&tcb1_clk>, <&clk32k>;
- clock-names = "t0_clk", "slow_clk";
- };
-
-
diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
new file mode 100644
index 000000000000..4b683151265e
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/microchip/atmel,at91rm9200-tcb.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Atmel Timer Counter Block
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+description: |
+ The Atmel (now Microchip) SoCs have timers named Timer Counter Block. Each
+ timer has three channels with two counters each.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - atmel,at91rm9200-tcb
+ - atmel,at91sam9x5-tcb
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ List of interrupts. One interrupt per TCB channel if available or one
+ interrupt for the TC block
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ description:
+ List of clock names. Always includes t0_clk and slow clk. Also includes
+ t1_clk and t2_clk if a clock per channel is available.
+ minItems: 2
+ maxItems: 4
+ items:
+ enum:
+ - t0_clk
+ - t1_clk
+ - t2_clk
+ - slow_clk
+
+ clocks:
+ minItems: 2
+ maxItems: 4
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^timer@[0-2]$":
+ description: The timer block channels that are used as timers.
+ type: object
+ properties:
+ compatible:
+ const: atmel,tcb-timer
+ reg:
+ description:
+ List of channels to use for this particular timer.
+ minItems: 1
+ maxItems: 3
+
+ required:
+ - compatible
+ - reg
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - '#address-cells'
+ - '#size-cells'
+
+examples:
+ - |
+ /* One interrupt per TC block: */
+ tcb0: timer@fff7c000 {
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfff7c000 0x100>;
+ interrupts = <18 4>;
+ clocks = <&tcb0_clk>, <&clk32k>;
+ clock-names = "t0_clk", "slow_clk";
+
+ timer@0 {
+ compatible = "atmel,tcb-timer";
+ reg = <0>, <1>;
+ };
+
+ timer@2 {
+ compatible = "atmel,tcb-timer";
+ reg = <2>;
+ };
+ };
+
+ /* One interrupt per TC channel in a TC block: */
+ tcb1: timer@fffdc000 {
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfffdc000 0x100>;
+ interrupts = <26 4>, <27 4>, <28 4>;
+ clocks = <&tcb1_clk>, <&clk32k>;
+ clock-names = "t0_clk", "slow_clk";
+
+ timer@0 {
+ compatible = "atmel,tcb-timer";
+ reg = <0>;
+ };
+
+ timer@1 {
+ compatible = "atmel,tcb-timer";
+ reg = <1>;
+ };
+ };
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3] arm64: dts: ti: k3-am654-main: Update otap-del-sel values
From: Faiz Abbas @ 2020-05-19 8:20 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: t-kristo, nm, robh+dt, faiz_abbas
According to the latest AM65x Data Manual[1], a different output tap
delay value is optimum for a given speed mode. Update these values.
[1] http://www.ti.com/lit/gpn/am6526
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
v3: Updated values to the latest data manual revision
v2: Updated to the latest mainline kernel
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 11887c72f23a..056130a126f9 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -244,7 +244,17 @@
interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
mmc-ddr-1_8v;
mmc-hs200-1_8v;
- ti,otap-del-sel = <0x2>;
+ ti,otap-del-sel-legacy = <0x0>;
+ ti,otap-del-sel-mmc-hs = <0x0>;
+ ti,otap-del-sel-sd-hs = <0x0>;
+ ti,otap-del-sel-sdr12 = <0x0>;
+ ti,otap-del-sel-sdr25 = <0x0>;
+ ti,otap-del-sel-sdr50 = <0x8>;
+ ti,otap-del-sel-sdr104 = <0x7>;
+ ti,otap-del-sel-ddr50 = <0x5>;
+ ti,otap-del-sel-ddr52 = <0x5>;
+ ti,otap-del-sel-hs200 = <0x5>;
+ ti,otap-del-sel-hs400 = <0x0>;
ti,trm-icp = <0x8>;
dma-coherent;
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: arm64: Register modification during syscall entry/exit stop
From: Will Deacon @ 2020-05-19 8:15 UTC (permalink / raw)
To: Keno Fischer
Cc: Catalin Marinas, Kyle Huey, Oleg Nesterov, linux-arm-kernel,
Linux Kernel Mailing List
In-Reply-To: <CABV8kRz0mKSc=u1LeonQSLroKJLOKWOWktCoGji2nvEBc=e7=w@mail.gmail.com>
Hi Keno,
On Mon, May 18, 2020 at 09:05:30PM -0400, Keno Fischer wrote:
> Continuing my theme of "weird things I encounter
> while trying to use ptrace on arm64", I ran into the
> effect of the following code in the syscall entry/exit
> reporting:
>
> ```
> /*
> * A scratch register (ip(r12) on AArch32, x7 on AArch64) is
> * used to denote syscall entry/exit:
> */
> regno = (is_compat_task() ? 12 : 7);
> saved_reg = regs->regs[regno];
> regs->regs[regno] = dir;
> ```
>
> This seems very weird to me. I can't think of any
> other architecture that does something similar
> (other than unicore32 apparently, but the ptrace
> support there seems like it might have just been
> copied from ARM). I'm able to work around this
> in my application, but it adds another stumbling block.
Yes, we inherited this from ARM and I think strace relies on it. In
hindsight, it is a little odd, although x7 is a parameter register in the
PCS and so it won't be live on entry to a system call.
> Some examples of things that happen:
> - Writes to x7 during syscall exit stops are ignored, so
> if the ptracer tries to emulate a setjmp-type thing, it
> might miss this register (ptracers sometimes like to do
> this to manually serialize execution between different
> threads, puppeteering a single thread of execution
> between different register states).
> - Reads from x7 are incorrect, so if the ptracer saves
> a register state and later tries to set it back to the task,
> it may get x7 incorrect, but user space may be expecting
> the register to be preserved (when might this happen? -
> consider a ptracer that wants to modify some syscall
> arguments, it modifies the arguments, restarts the syscall
> but then incurs a signal, so it tries to restore the original
> registers to let userspace deal with the signal without
> being confused - expect signal traps don't ignore x7
> modifications, so x7 may have been unexpectedly
> modified).
> - We now have seccomp traps, which kind of look and
> act like syscall-entry traps, but don't have this behavior,
> so it's not particularly reliable for ptracers to use.
>
> Furthermore, it seems unnecessary to me on modern
> kernels. We now have PTRACE_GET_SYSCALL_INFO,
> which exposes this information without lying to the ptracer
> about the tracee's registers.
>
> I understand, we can't just change this, since people may
> be relying on it, but I would like to propose adding a ptrace
> option (PTRACE_O_ARM_REGSGOOD?) that turns this
> behavior off. Now, I don't think we currently have any other
> arch-specific ptrace options, so maybe there is a different
> option that would be preferable (e.g. could be a different
> regset), but I do think it would be good to have a way to
> operate on the real x7 value. As I said, I can work around it,
> but hopefully I will be able to save a future implementer
> some headache.
I'm not opposed to extending ptrace so that we can try to wean people off
this interface, but I think we need some concrete situations where the
current behaviour actually causes a problem. Although the examples you've
listed above are interesting, I don't see why x7 is important in any of
them (and we only support up to 6 system call arguments).
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: interrupt-controller: arm, gic: Document resets property
From: Geert Uytterhoeven @ 2020-05-19 8:05 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Andre Przywara
Cc: linux-renesas-soc, devicetree, Geert Uytterhoeven, linux-kernel,
linux-arm-kernel
A generic GIC block embedded in an SoC may be connected to an on-SoC
reset controller. Hence allow the DTS writer to describe this relation,
by documenting the optional presence of a "reset" property.
This gets rid of "make dtbs_check" warnings like:
arch/arm/boot/dts/r8a7791-porter.dt.yaml: interrupt-controller@f1001000: 'resets' does not match any of the regexes: '^v2m@[0-9a-f]+$', 'pinctrl-[0-9]+'
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
.../devicetree/bindings/interrupt-controller/arm,gic.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
index 9a47820ef34649dd..caefcc50bcf92c92 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
@@ -125,6 +125,9 @@ properties:
power-domains:
maxItems: 1
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Arnd Bergmann @ 2020-05-19 7:59 UTC (permalink / raw)
To: Mike Rapoport
Cc: Doug Berger, Stephen Boyd, Kevin Cernekee, Russell King,
Florian Fainelli, Gregory Fong, Linux ARM
In-Reply-To: <20200518194533.GD1059226@linux.ibm.com>
On Mon, May 18, 2020 at 9:45 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> > On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> > > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> > >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> > >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> > >>>
> > >>> ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of
> > >>> system memory can be located deep in the 36-bit address space. Allow
> > >>> FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains
> > >>> the default.
> > >>>
> > >>> This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
> > >>> SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
> > >>> commit message text above. As Arnd pointed out at [2] there doesn't
> > >>> seem to be any reason to tie this specifically to ARMv7, so this has
> > >>> been changed to apply to all multiplatform kernels.
> > >>>
> > >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
> > >>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
> > >>>
> > >>> Cc: Kevin Cernekee <cernekee@gmail.com>
> > >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> > >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> > >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> > >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > >>> ---
> > >>> arch/arm/Kconfig | 5 +++++
> > >>> 1 file changed, 5 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >>> index 5986277296c3..7bb5264a9c3a 100644
> > >>> --- a/arch/arm/Kconfig
> > >>> +++ b/arch/arm/Kconfig
> > >>> @@ -312,6 +312,8 @@ choice
> > >>> config ARCH_MULTIPLATFORM
> > >>> bool "Allow multiple platforms to be selected"
> > >>> depends on MMU
> > >>> + select ARCH_FLATMEM_ENABLE
> > >>> + select ARCH_SPARSEMEM_ENABLE
> > >>
> > >> The logic in mm/Kconfig is quite convoluted, so selecting
> > >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> > >>
> > >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> > >> something like:
> > >
> > > Yes indeed, thanks that does allow me to select between flatmem and
> > > sparsemem from menuconfig correctly now.
> >
> > Mike, do you want to make a formal submission to Russell's patch
> > tracker? If so, feel free to add:
>
> I actually hoped to hear from people what do they think about switching
> over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
> it would make sense.
It seems that at least s5p/exynos and clps711x (armv4) used to default to
sparsemem, and that got lost in the multiplatform conversion.
I also see discontiguous memory ranges in multiple broadcom chips,
on TI dm8168, ecx-2000 and imx.
> Russel, Arnd, can you comment please?
I see no problem with giving users the choice for all multiplatform
builds. No idea on what the default should be really, i.e. whether
only v7 configurations should make it the default, or rather none of
them or all of them.
Maybe lets leave the default unchanged with flatmem but enable it
in multi_v7_defconfig and the configurations for chips that are known
to have discontiguous memory (clps, bcm, imx, exynos, ...).
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] iommu/mediatek-v1: Fix a build warning for a unused variable 'data'
From: Yong Wu @ 2020-05-19 7:57 UTC (permalink / raw)
To: Joerg Roedel
Cc: youlin.pei, anan.sun, srv_heupstream, Will Deacon, linux-kernel,
iommu, linux-mediatek, yong.wu, Matthias Brugger, Robin Murphy,
linux-arm-kernel
This patch fixes a build warning:
drivers/iommu/mtk_iommu_v1.c: In function 'mtk_iommu_release_device':
>> drivers/iommu/mtk_iommu_v1.c:467:25: warning: variable 'data' set but
>> not used [-Wunused-but-set-variable]
467 | struct mtk_iommu_data *data;
| ^~~~
It's reported at:
https://lore.kernel.org/linux-iommu/202005191458.gY38V8bU%25lkp@intel.com/T/#u
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index f353b07..c9d79cf 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -469,12 +469,10 @@ static void mtk_iommu_probe_finalize(struct device *dev)
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- struct mtk_iommu_data *data;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return;
- data = dev_iommu_priv_get(dev);
iommu_fwspec_free(dev);
}
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] ARM: dts: sh73a0: Add missing clocks to sound node
From: Geert Uytterhoeven @ 2020-05-19 7:55 UTC (permalink / raw)
To: Kuninori Morimoto, Magnus Damm
Cc: linux-renesas-soc, devicetree, Geert Uytterhoeven,
linux-arm-kernel
The device node for the FIFO-buffered Serial Interface sound node lacks
the "clocks" property, as the DTS file didn't describe any clocks yet at
its introduction.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
To be queued in renesas-fixes for v5.7 or v5.8, to avoid the
corresponding DT binding update introducing a regression.
arch/arm/boot/dts/sh73a0.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 6688f058087704d3..d7339e511288a4ec 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -601,6 +601,7 @@
compatible = "renesas,fsi2-sh73a0", "renesas,sh_fsi2";
reg = <0xec230000 0x400>;
interrupts = <GIC_SPI 146 0x4>;
+ clocks = <&mstp3_clks SH73A0_CLK_FSI>;
power-domains = <&pd_a4mp>;
status = "disabled";
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 01/20] dt-bindings: arm: gic: Allow combining arm,gic-400 compatible strings
From: Geert Uytterhoeven @ 2020-05-19 7:39 UTC (permalink / raw)
To: Andre Przywara
Cc: Mark Rutland, Rob Herring, Lorenzo Pieralisi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Marc Zyngier, Liviu Dudau, Sudeep Holla, Linux ARM
In-Reply-To: <20200513103016.130417-2-andre.przywara@arm.com>
Hi Andre,
On Wed, May 13, 2020 at 12:31 PM Andre Przywara <andre.przywara@arm.com> wrote:
> The arm,gic-400 compatible is probably the best matching string for the
> GIC in most modern SoCs, but was only introduced later into the kernel.
> For historic reasons and to keep compatibility, some SoC DTs were thus
> using a combination of this name and one of the older strings, which
> currently the binding denies.
>
> Add a stanza to the DT binding to allow "arm,gic-400", followed by
> either "arm,cortex-a15-gic" or "arm,cortex-a7-gic". This fixes binding
> compliance for quite some SoC .dtsi files in the kernel tree.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Thanks for your patch, I was just looking into this issue ;-)
> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
> @@ -39,6 +39,12 @@ properties:
> - qcom,msm-8660-qgic
> - qcom,msm-qgic2
>
> + - items:
> + - const: arm,gic-400
> + - enum:
> + - arm,cortex-a15-gic
> + - arm,cortex-a7-gic
> +
> - items:
> - const: arm,arm1176jzf-devchip-gic
> - const: arm,arm11mp-gic
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/r9a06g032.dtsi#n177
has them in the other order.
What do you think is the preferred solution: reverting the order, or dropping
one or the other?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ti: k3-am654-main: Update otap-del-sel values
From: Faiz Abbas @ 2020-05-19 7:30 UTC (permalink / raw)
To: Tero Kristo, linux-kernel, devicetree, linux-arm-kernel; +Cc: nm, robh+dt
In-Reply-To: <c59653d0-2e24-8917-f5b9-8c1044786bc9@ti.com>
Hi Tero,
On 15/05/20 3:44 pm, Tero Kristo wrote:
> On 07/05/2020 21:15, Faiz Abbas wrote:
>> According to the latest AM65x Data Manual[1], a different output tap
>> delay value is optimum for a given speed mode. Update these values.
>>
>> [1] http://www.ti.com/lit/gpn/am6526
>>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> ---
>> v2: Rebased to the latest mainline kernel
>>
>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index 11887c72f23a..6cd9701e4ead 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -244,7 +244,17 @@
>> interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
>> mmc-ddr-1_8v;
>> mmc-hs200-1_8v;
>> - ti,otap-del-sel = <0x2>;
>> + ti,otap-del-sel-legacy = <0x0>;
>> + ti,otap-del-sel-mmc-hs = <0x0>;
>> + ti,otap-del-sel-sd-hs = <0x0>;
>> + ti,otap-del-sel-sdr12 = <0x0>;
>> + ti,otap-del-sel-sdr25 = <0x0>;
>> + ti,otap-del-sel-sdr50 = <0x8>;
>> + ti,otap-del-sel-sdr104 = <0x5>;
>
> Isn't this wrong? Doc claims the value for sdr104 should be 0x7?
>
Yes. There seems to be an update to the document since I last updated the value.
Thanks for catching. I will post another version soon.
Thanks,
Faiz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 10/10] arm64: dts: Add node for ufs exynos7
From: Krzysztof Kozlowski @ 2020-05-19 7:16 UTC (permalink / raw)
To: Alim Akhtar
Cc: robh, linux-samsung-soc, linux-scsi, martin.petersen, devicetree,
linux-kernel, kwmad.kim, avri.altman, cang, stanley.chu,
linux-arm-kernel
In-Reply-To: <20200514003914.26052-11-alim.akhtar@samsung.com>
On Thu, May 14, 2020 at 06:09:14AM +0530, Alim Akhtar wrote:
> Adding dt node foe UFS and UFS-PHY for exynos7 SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> Tested-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> .../boot/dts/exynos/exynos7-espresso.dts | 4 ++
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 ++++++++++++++++++-
> 2 files changed, 45 insertions(+), 2 deletions(-)
I will pick it up after all bindings get Rob's ack (or are picked up as
well). The second bindings patch are still pending on that.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Geert Uytterhoeven @ 2020-05-19 7:14 UTC (permalink / raw)
To: Qii Wang
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
srv_heupstream, Wolfram Sang, leilk.liu,
Linux Kernel Mailing List, linux-mediatek, Linux I2C, Joe Perches,
Linux ARM
In-Reply-To: <1589857073.25512.34.camel@mhfsdcap03>
Hi Qii,
On Tue, May 19, 2020 at 4:59 AM Qii Wang <qii.wang@mediatek.com> wrote:
> On Mon, 2020-05-18 at 17:44 +0200, Geert Uytterhoeven wrote:
> > On Thu, May 14, 2020 at 3:13 PM Qii Wang <qii.wang@mediatek.com> wrote:
> > > This patch adds a algorithm to calculate some ac-timing parameters
> > > which can fully meet I2C Spec.
> > >
> > > Signed-off-by: Qii Wang <qii.wang@mediatek.com>
> > > ---
> > > drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
> > > 1 file changed, 277 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> > > index 0ca6c38a..7020618 100644
> > > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> >
> > > +/*
> > > + * Check and Calculate i2c ac-timing
> > > + *
> > > + * Hardware design:
> > > + * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
> > > + * xxx_cnt_div = spec->min_xxx_ns / sample_ns
> > > + *
> > > + * Sample_ns is rounded down for xxx_cnt_div would be greater
> > > + * than the smallest spec.
> > > + * The sda_timing is chosen as the middle value between
> > > + * the largest and smallest.
> > > + */
> > > +static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> > > + unsigned int clk_src,
> > > + unsigned int check_speed,
> > > + unsigned int step_cnt,
> > > + unsigned int sample_cnt)
> > > +{
> > > + const struct i2c_spec_values *spec;
> > > + unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> > > + unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> > > + long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
> >
> > So sample_ns is a 64-bit value. Is that really needed?
> >
>
> (1000000000 * (sample_cnt + 1)) / clk_src value is a 32-bit, (1000000000
> * (sample_cnt + 1)) will over 32-bit if sample_cnt is 7.
The intermediate value will indeed not fit in 32-bit.
But that doesn't mean the end result won't fit in 32-bit.
As you divide spec->min_low_ns and spec->min_su_dat_ns (which I assume
are small numbers) by sample_ns below, sample_ns cannot be very large,
or the quotient will be zero anyway.
So just doing the multiplication in 64-bit, followed by a 64-by-32
division is probably fine:
unsigned int sample_ns = div_u64(1000000000ULL * (sample_cnt + 1), clk_src);
You may want to take precautions for the case where the passed value of
clk_src is a small number (can that happen?).
BTW, clk_get_rate() returns "unsigned long", while mtk_i2c_set_speed()
takes an "unsigned int" parent_clk, which may cause future issues.
You may want to change that to "unsigned long", along the whole
propagation path, and use div64_ul() instead of div_u64() above.
> I think 1000000000 and clk_src is too big, maybe I can reduce then with
> be divided all by 1000.
> example:
>
> unsigned int sample_ns;
> unsigned int clk_src_khz = clk_src / 1000;
That may cause too much loss of precision.
>
> if(clk_src_khz)
> sample_ns = (1000000 * (sample_cnt + 1)) / clk_src_khz;
> else
> return -EINVAL;
>
> > > + if (!i2c->dev_comp->timing_adjust)
> > > + return 0;
> > > +
> > > + if (i2c->dev_comp->ltiming_adjust)
> > > + max_sta_cnt = 0x100;
> > > +
> > > + spec = mtk_i2c_get_spec(check_speed);
> > > +
> > > + if (i2c->dev_comp->ltiming_adjust)
> > > + clk_ns = 1000000000 / clk_src;
> > > + else
> > > + clk_ns = sample_ns / 2;
> > > +
> > > + su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
> > > + if (su_sta_cnt > max_sta_cnt)
> > > + return -1;
> > > +
> > > + low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
> >
> > So this is a 32-bit by 64-bit division (indeed, not 64-by-32!)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] pinctrl: samsung: Stuff for v5.8
From: Krzysztof Kozlowski @ 2020-05-19 7:02 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-samsung-soc, Sylwester Nawrocki, linux-kernel,
Krzysztof Kozlowski, Tomasz Figa, linux-gpio, linux-arm-kernel
Hi Linus,
Minor updates for Samsung pinctrl drivers.
Best regards,
Krzysztof
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git tags/samsung-pinctrl-5.8
for you to fetch changes up to f354157a7d184db430c1a564c506434e33b1bec5:
pinctrl: samsung: Save/restore eint_mask over suspend for EINT_TYPE GPIOs (2020-04-28 11:38:11 +0200)
----------------------------------------------------------------
Samsung pinctrl drivers changes for v5.8
Two fixes for S5Pv210 pinctrl driver: setting proper external interrupt
wakeup mask and restoring external interrupt mask value after system
suspend.
----------------------------------------------------------------
Jonathan Bakker (2):
pinctrl: samsung: Correct setting of eint wakeup mask on s5pv210
pinctrl: samsung: Save/restore eint_mask over suspend for EINT_TYPE GPIOs
drivers/pinctrl/samsung/pinctrl-exynos.c | 82 ++++++++++++++++++++++----------
1 file changed, 58 insertions(+), 24 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] soc/memory: samsung: Drivers update for v5.8
From: Krzysztof Kozlowski @ 2020-05-19 7:01 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.8
for you to fetch changes up to 108c31e77594561eb239534fe019d971c1f8fe38:
memory: samsung: exynos5422-dmc: Reduce protected code area in IRQ handler (2020-05-12 15:11:47 +0200)
----------------------------------------------------------------
Samsung SoC drivers changes for v5.8
Fix and minor cleanup of Exynos5422 DMC (Dynamic Memory Controller)
driver.
----------------------------------------------------------------
Bernard Zhao (2):
memory: samsung: exynos5422-dmc: Fix tFAW timings alignment
memory: samsung: exynos5422-dmc: Reduce protected code area in IRQ handler
drivers/memory/samsung/exynos5422-dmc.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64/for-kernelci boot: 26 boots: 0 failed, 26 passed (v5.7-rc6-124-g96bc42ff0a82)
From: kernelci.org bot @ 2020-05-19 6:53 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel, kernel-build-reports
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v5.7-rc6-124-g96bc42ff0a82/plan/baseline/
-------------------------------------------------------------------------------
arm64/for-kernelci boot: 26 boots: 0 failed, 26 passed (v5.7-rc6-124-g96bc42ff0a82)
Full Boot Summary: https://kernelci.org/boot/all/job/arm64/branch/for-kernelci/kernel/v5.7-rc6-124-g96bc42ff0a82/
Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v5.7-rc6-124-g96bc42ff0a82/
Tree: arm64
Branch: for-kernelci
Git Describe: v5.7-rc6-124-g96bc42ff0a82
Git Commit: 96bc42ff0a82ea44f220ea721a5835e479ec8cea
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Tested: 23 unique boards, 7 SoC families, 1 build out of 3
---
For more info write to <info@kernelci.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64/for-kernelci baseline: 24 runs, 1 regressions (v5.7-rc6-124-g96bc42ff0a82)
From: kernelci.org bot @ 2020-05-19 6:53 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel, kernel-build-reports
arm64/for-kernelci baseline: 24 runs, 1 regressions (v5.7-rc6-124-g96bc42ff0a82)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | results
----------------+-------+--------------+----------+-----------+--------
bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v5.7-rc6-124-g96bc42ff0a82/plan/baseline/
Test: baseline
Tree: arm64
Branch: for-kernelci
Describe: v5.7-rc6-124-g96bc42ff0a82
URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
SHA: 96bc42ff0a82ea44f220ea721a5835e479ec8cea
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | results
----------------+-------+--------------+----------+-----------+--------
bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/plan/id/5ec36d7f4f34ecf15e4397c1
Results: 4 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//arm64/for-kernelci/v5.7-rc6-124-g96bc42ff0a82/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.txt
HTML log: https://storage.kernelci.org//arm64/for-kernelci/v5.7-rc6-124-g96bc42ff0a82/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02-11-g17e793fa4728/arm64/baseline/rootfs.cpio.gz
* baseline.dmesg.crit: https://kernelci.org/test/case/id/5ec36d7f4f34ecf15e4397c4
new failure (last pass: v5.7-rc5-98-g51f14e2c02e8)
1 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] arm64: perf: Add support for Perf NMI interrupts
From: Sumit Garg @ 2020-05-19 6:48 UTC (permalink / raw)
To: Mark Rutland
Cc: Jian-Lin Chen, Will Deacon, alexander.shishkin, Catalin Marinas,
jolsa, Linux Kernel Mailing List, acme, Lecopzer Chen,
Peter Zijlstra, mingo, linux-mediatek, linux-arm-kernel,
matthias.bgg, namhyung, Alexandru Elisei, yj.chiang,
julien.thierry.kdev
In-Reply-To: <20200518141946.GA3164@C02TD0UTHF1T.local>
On Mon, 18 May 2020 at 19:49, Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Mon, May 18, 2020 at 07:39:23PM +0530, Sumit Garg wrote:
> > On Mon, 18 May 2020 at 16:47, Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > > On 5/18/20 11:45 AM, Mark Rutland wrote:
> > > > On Mon, May 18, 2020 at 02:26:00PM +0800, Lecopzer Chen wrote:
> > > >> HI Sumit,
> > > >>
> > > >> Thanks for your information.
> > > >>
> > > >> I've already implemented IPI (same as you did [1], little difference
> > > >> in detail), hardlockup detector and perf in last year(2019) for
> > > >> debuggability.
> > > >> And now we tend to upstream to reduce kernel maintaining effort.
> > > >> I'm glad if someone in ARM can do this work :)
> > > >>
> > > >> Hi Julien,
> > > >>
> > > >> Does any Arm maintainers can proceed this action?
> > > > Alexandru (Cc'd) has been rebasing and reworking Julien's patches, which
> > > > is my preferred approach.
> > > >
> > > > I understand that's not quite ready for posting since he's investigating
> > > > some of the nastier subtleties (e.g. mutual exclusion with the NMI), but
> > > > maybe we can put the work-in-progress patches somewhere in the mean
> > > > time.
> > > >
> > > > Alexandru, do you have an idea of what needs to be done, and/or when you
> > > > expect you could post that?
> > >
> > > I'm currently working on rebasing the patches on top of 5.7-rc5, when I have
> > > something usable I'll post a link (should be a couple of days). After that I will
> > > address the review comments, and I plan to do a thorough testing because I'm not
> > > 100% confident that some of the assumptions around the locks that were removed are
> > > correct. My guess is this will take a few weeks.
> > >
> >
> > Thanks Mark, Alex for the status updates on perf NMI feature.
> >
> > Alex,
> >
> > As the hard-lockup detection patch [1] has a dependency on perf NMI
> > patch-set, I will rebase and test hard-lockup detector when you have
> > got a working tree. But due to the dependency, I think patch [1]
> > should be accepted along with perf NMI patch-set. So would you be open
> > to include this patch as part of your series?
> >
> > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html
>
> While it depends on the perf NMI bits, I don't think it makes sense to
> tie that into the series given it's trying to achieve something very
> different.
>
> I think that should be reposted separately once the perf NMI bits are in
> shape.
Okay, fair enough. Will keep it as a separate patch then.
-Sumit
>
> Thanks,
> Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] arm64: Enable perf events based hard lockup detector
From: Sumit Garg @ 2020-05-19 6:36 UTC (permalink / raw)
To: Mark Rutland
Cc: Daniel Thompson, Peter Zijlstra, Catalin Marinas, jolsa,
Douglas Anderson, acme, alexander.shishkin, mingo,
julien.thierry.kdev, namhyung, Thomas Gleixner, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200518145254.pj2mhjxkzk7jnltm@holly.lan>
Hi Mark,
On Mon, 18 May 2020 at 20:22, Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Mon, May 18, 2020 at 03:34:55PM +0100, Mark Rutland wrote:
> > Hi Sumit,
> >
> > On Fri, May 15, 2020 at 02:19:53PM +0530, Sumit Garg wrote:
> > > With the recent feature added to enable perf events to use pseudo NMIs
> > > as interrupts on platforms which support GICv3 or later, its now been
> > > possible to enable hard lockup detector (or NMI watchdog) on arm64
> > > platforms. So enable corresponding support.
> >
> > Where/when do we expect to see this used?
> >
> > I thought for server systems we'd expect to have the SBSA watchdog, so
> > why would we need this?
>
> I view the lockup detector as a debug tool rather than a traditional
> watchdog.
>
> Certainly kernel machinery that prints the stack trace of a CPU that
> has got wedged in a manner where it cannot service interrupts should
> have fairly obvious applications for debugging embedded systems.
>
+1
>
>
> >
> > > One thing to note here is that normally lockup detector is initialized
> > > just after the early initcalls but PMU on arm64 comes up much later as
> > > device_initcall(). So we need to re-initialize lockup detection once
> > > PMU has been initialized.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > ---
> > >
> > > This patch is dependent on perf NMI patch-set [1].
> > >
> > > [1] https://patchwork.kernel.org/cover/11047407/
> > >
> > > arch/arm64/Kconfig | 2 ++
> > > arch/arm64/kernel/perf_event.c | 32 ++++++++++++++++++++++++++++++--
> > > drivers/perf/arm_pmu.c | 11 +++++++++++
> > > include/linux/perf/arm_pmu.h | 2 ++
> > > 4 files changed, 45 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 40fb05d..36f75c2 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -160,6 +160,8 @@ config ARM64
> > > select HAVE_NMI
> > > select HAVE_PATA_PLATFORM
> > > select HAVE_PERF_EVENTS
> > > + select HAVE_PERF_EVENTS_NMI if ARM64_PSEUDO_NMI
> > > + select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && HAVE_PERF_EVENTS_NMI
> > > select HAVE_PERF_REGS
> > > select HAVE_PERF_USER_STACK_DUMP
> > > select HAVE_REGS_AND_STACK_ACCESS_API
> > > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> > > index 3ad5c8f..df57360 100644
> > > --- a/arch/arm64/kernel/perf_event.c
> > > +++ b/arch/arm64/kernel/perf_event.c
> > > @@ -20,6 +20,8 @@
> > > #include <linux/perf/arm_pmu.h>
> > > #include <linux/platform_device.h>
> > > #include <linux/smp.h>
> > > +#include <linux/nmi.h>
> > > +#include <linux/cpufreq.h>
> > >
> > > /* ARMv8 Cortex-A53 specific event types. */
> > > #define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> > > @@ -1190,10 +1192,21 @@ static struct platform_driver armv8_pmu_driver = {
> > >
> > > static int __init armv8_pmu_driver_init(void)
> > > {
> > > + int ret;
> > > +
> > > if (acpi_disabled)
> > > - return platform_driver_register(&armv8_pmu_driver);
> > > + ret = platform_driver_register(&armv8_pmu_driver);
> > > else
> > > - return arm_pmu_acpi_probe(armv8_pmuv3_init);
> > > + ret = arm_pmu_acpi_probe(armv8_pmuv3_init);
> > > +
> > > + /*
> > > + * Try to re-initialize lockup detector after PMU init in
> > > + * case PMU events are triggered via NMIs.
> > > + */
> > > + if (arm_pmu_irq_is_nmi())
> > > + lockup_detector_init();
> > > +
> > > + return ret;
> > > }
> > > device_initcall(armv8_pmu_driver_init)
> > >
> > > @@ -1225,3 +1238,18 @@ void arch_perf_update_userpage(struct perf_event *event,
> > > userpg->time_shift = (u16)shift;
> > > userpg->time_offset = -now;
> > > }
> > > +
> > > +#ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
> > > +#define SAFE_MAX_CPU_FREQ 4000000000UL // 4 GHz
> >
> > Why is 4GHz "safe"?
> >
> > There's no architectural requirement on max frequency, and it's
> > conceviable that there could be parts faster than this.
> >
> > If the frequency is critical, then we should bail out when it is
> > unknown rather than guessing. If it is not cirital then we should
> > explain what the requirements are and why using a hard-coded value is
> > sane.
The frequency is critical in the sense that it shouldn't lead to a
timeout less than watchdog threshold (10 sec.) for hard-lockup
detector. And we can't simply bail out here, since there could be
platforms which doesn't implement cpufreq driver (eg. Developerbox).
I chose 4GHz as a safe maximum here as I couldn't find any real parts
as of now running faster than 4GHz. But I agree with you that
architecture doesn't put any restrictions on max. frequency. So we can
certainly put a higher hardcoded value here and the only side effect
of this would be a bigger hard-lockup detector timeout (which I think
should be acceptable) on parts which are running slower (eg. 1GHz on
Developerbox) and doesn't possess a cpufreq driver.
> >
> > > +u64 hw_nmi_get_sample_period(int watchdog_thresh)
> > > +{
> > > + unsigned int cpu = smp_processor_id();
> > > + unsigned int max_cpu_freq;
> > > +
> > > + max_cpu_freq = cpufreq_get_hw_max_freq(cpu);
> > > + if (max_cpu_freq)
> > > + return (u64)max_cpu_freq * 1000 * watchdog_thresh;
> > > + else
> > > + return (u64)SAFE_MAX_CPU_FREQ * watchdog_thresh;
> > > +}
> >
> > I take it this uses CPU cycles?
Yes its based on perf event with config attribute as PERF_COUNT_HW_CPU_CYCLES.
> >
> > AFAIK those can be gated in idle/retention states (e.g. for WFI/WFE or
> > any other instruction that could block). So if the CPU were blocked on
> > one of those, the counter would never overflow and trigger the
> > interrupt.
> >
> > i.e. this isn't going to detect a hard lockup of that sort.
Isn't this a correct behaviour as we shouldn't raise a false
hard-lockup detection while the CPU is actually in idle/retention
states? IMO, this feature is useful for debugging purposes when a
particular CPU is stuck in a deadlock loop with interrupts disabled.
> >
> > > +#endif
> > > diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> > > index f96cfc4..691dfc9 100644
> > > --- a/drivers/perf/arm_pmu.c
> > > +++ b/drivers/perf/arm_pmu.c
> > > @@ -718,6 +718,17 @@ static int armpmu_get_cpu_irq(struct arm_pmu *pmu, int cpu)
> > > return per_cpu(hw_events->irq, cpu);
> > > }
> > >
> > > +bool arm_pmu_irq_is_nmi(void)
> > > +{
> > > + const struct pmu_irq_ops *irq_ops;
> > > +
> > > + irq_ops = per_cpu(cpu_irq_ops, smp_processor_id());
> > > + if (irq_ops == &pmunmi_ops || irq_ops == &percpu_pmunmi_ops)
> > > + return true;
> > > + else
> > > + return false;
> >
> > You can simplify:
> >
> > | if (x)
> > | return true;
> > | else
> > | return false;
> >
> > ... to:
> >
> > | return x;
> >
Looks clean, will use it instead.
-Sumit
> > Thanks,
> > Mark.
> >
> > > +}
> > > +
> > > /*
> > > * PMU hardware loses all context when a CPU goes offline.
> > > * When a CPU is hotplugged back in, since some hardware registers are
> > > diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> > > index d9b8b76..a71f029 100644
> > > --- a/include/linux/perf/arm_pmu.h
> > > +++ b/include/linux/perf/arm_pmu.h
> > > @@ -155,6 +155,8 @@ int arm_pmu_acpi_probe(armpmu_init_fn init_fn);
> > > static inline int arm_pmu_acpi_probe(armpmu_init_fn init_fn) { return 0; }
> > > #endif
> > >
> > > +bool arm_pmu_irq_is_nmi(void);
> > > +
> > > /* Internal functions only for core arm_pmu code */
> > > struct arm_pmu *armpmu_alloc(void);
> > > struct arm_pmu *armpmu_alloc_atomic(void);
> > > --
> > > 2.7.4
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64/for-kernelci build: 3 builds: 0 failed, 3 passed, 48 warnings (v5.7-rc6-124-g96bc42ff0a82)
From: kernelci.org bot @ 2020-05-19 6:09 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel, kernel-build-reports
arm64/for-kernelci build: 3 builds: 0 failed, 3 passed, 48 warnings (v5.7-rc6-124-g96bc42ff0a82)
Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v5.7-rc6-124-g96bc42ff0a82/
Tree: arm64
Branch: for-kernelci
Git Describe: v5.7-rc6-124-g96bc42ff0a82
Git Commit: 96bc42ff0a82ea44f220ea721a5835e479ec8cea
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture
Warnings Detected:
arm64:
allmodconfig (gcc-8): 24 warnings
defconfig (gcc-8): 24 warnings
Warnings summary:
32 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
6 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
6 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
2 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
2 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
allmodconfig (arm64, gcc-8) — PASS, 0 errors, 24 warnings, 0 section mismatches
Warnings:
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
--------------------------------------------------------------------------------
allnoconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 24 warnings, 0 section mismatches
Warnings:
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
---
For more info write to <info@kernelci.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 3/3] tty: samsung_tty: 32-bit access for TX/RX hold registers
From: Jiri Slaby @ 2020-05-19 5:55 UTC (permalink / raw)
To: Hyunki Koo, Kukjin Kim, Krzysztof Kozlowski, Greg Kroah-Hartman,
Jiri Slaby, linux-arm-kernel, linux-samsung-soc, linux-serial,
linux-kernel
In-Reply-To: <20200506080242.18623-3-hyunki00.koo@samsung.com>
On 06. 05. 20, 10:02, Hyunki Koo wrote:
> Support 32-bit access for the TX/RX hold registers UTXH and URXH.
>
> This is required for some newer SoCs.
>
> Signed-off-by: Hyunki Koo <hyunki00.koo@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Tested on Odroid HC1 (Exynos5422):
> Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> drivers/tty/serial/samsung_tty.c | 62 ++++++++++++++++++++++++++++++++++++----
> 1 file changed, 57 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> index 326b0164609c..6ef614d8648c 100644
> --- a/drivers/tty/serial/samsung_tty.c
> +++ b/drivers/tty/serial/samsung_tty.c
...
> @@ -2000,10 +2023,27 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
> dev_get_platdata(&pdev->dev) :
> ourport->drv_data->def_cfg;
>
> - if (np)
> + if (np) {
> of_property_read_u32(np,
> "samsung,uart-fifosize", &ourport->port.fifosize);
>
> + if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
> + switch (prop) {
> + case 1:
> + ourport->port.iotype = UPIO_MEM;
> + break;
> + case 4:
> + ourport->port.iotype = UPIO_MEM32;
> + break;
> + default:
> + dev_warn(&pdev->dev, "unsupported reg-io-width (%d)\n",
> + prop);
> + ret = -EINVAL;
> + break;
This ret value is unused. Did you intend to return here?
thanks,
--
js
suse labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Qualcomm ARM dts updates for v5.8
From: Bjorn Andersson @ 2020-05-19 5:25 UTC (permalink / raw)
To: arm, soc
Cc: Arnd Bergmann, linux-arm-msm, Daniele Debernardi, Abhishek Sahu,
Andy Gross, Iskren Chernev, Kevin Hilman, Olof Johansson,
Ansuel Smith, linux-arm-kernel
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-dts-for-5.8
for you to fetch changes up to cd13c72c1853f219e1f5577a107f48b9f9c44fdd:
ARM: dts: qcom: msm8974-klte: Add max77826 pmic node (2020-04-21 00:23:27 -0700)
----------------------------------------------------------------
Qualcomm ARM dts updates for v5.8
This adds SCM firmware node for IPQ806x and fixes the high resolution
timer for IPQ4019. Samsung Galaxy S5 gains regulators, eMMC and USB
support.
----------------------------------------------------------------
Abhishek Sahu (1):
ARM: dts: qcom: ipq4019: fix high resolution timer
Ansuel Smith (1):
ARM: dts: qcom: add scm definition to ipq806x
Daniele Debernardi (5):
ARM: dts: qcom: msm8974-klte: Add pma8084 regulator nodes
ARM: dts: qcom: msm8974-klte: Remove inherited vreg_boost node
ARM: dts: qcom: msm8974-klte: Add gpio-keys nodes
ARM: dts: qcom: msm8974-klte: Add sdhci1 node
ARM: dts: qcom: msm8974-klte: Add USB node
Iskren Chernev (1):
ARM: dts: qcom: msm8974-klte: Add max77826 pmic node
arch/arm/boot/dts/qcom-ipq4019.dtsi | 1 +
arch/arm/boot/dts/qcom-ipq8064.dtsi | 6 +
arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts | 405 +++++++++++++++++++++++-
arch/arm/boot/dts/qcom-msm8974.dtsi | 11 +
4 files changed, 421 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Qualcomm driver updates for v5.8
From: Bjorn Andersson @ 2020-05-19 5:25 UTC (permalink / raw)
To: arm, soc
Cc: Maulik Shah, Gustavo A . R . Silva, Stephan Gerhold,
Arnd Bergmann, Jason Yan, Vincent Knecht, linux-arm-msm,
Douglas Anderson, Stephen Boyd, Markus Elfring, Andy Gross,
John Stultz, Sibi Sankar, Kevin Hilman, Olof Johansson,
Srinivas Kandagatla, Raju P . L . S . S . S . N,
Christoph Hellwig, linux-arm-kernel
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-5.8
for you to fetch changes up to 1f7a3eb785e4a4e196729cd3d5ec97bd5f9f2940:
Revert "soc: qcom: rpmh: Allow RPMH driver to be loaded as a module" (2020-05-17 23:13:00 -0700)
----------------------------------------------------------------
Qualcomm driver updates for v5.8
This contains a large set of cleanups, bug fixes, general improvements
and documentation fixes for the RPMH driver. It adds a debugfs mechanism
for inspecting Command DB. Socinfo got the "soc_id" attribute defines
and definitions for a various variants of MSM8939.
RPMH, RPMPD and RPMHPD where made possible to build as modules, but RPMH
had to be reverted due to a compilation issue when tracing is enabled.
RPMHPD gained power-domains for the SM8250 voltage corners.
The SCM driver gained fixes for two build warnings and the SMP2P had an
unnecessary error print removed.
----------------------------------------------------------------
Bjorn Andersson (3):
soc: qcom: rpmhpd: Add SM8250 power domains
soc: qcom: aoss: Add SM8250 compatible
Revert "soc: qcom: rpmh: Allow RPMH driver to be loaded as a module"
Christoph Hellwig (1):
firmware: qcom_scm: fix bogous abuse of dma-direct internals
Douglas Anderson (18):
soc: qcom: rpmh-rsc: Clean code reading/writing TCS regs/cmds
soc: qcom: rpmh-rsc: Document the register layout better
soc: qcom: rpmh-rsc: Fold tcs_ctrl_write() into its single caller
soc: qcom: rpmh-rsc: Remove get_tcs_of_type() abstraction
soc: qcom: rpmh-rsc: Kill cmd_cache and find_match() with fire
soc: qcom: rpmh-rsc: A lot of comments
soc: qcom: rpmh-rsc: tcs_is_free() can just check tcs_in_use
soc: qcom: rpmh-rsc: Don't double-check rpmh payload
soc: qcom: rpmh-rsc: Caller handles tcs_invalidate() exclusivity
soc: qcom: rpmh-rsc: read_tcs_reg()/write_tcs_reg() are not for IRQ
soc: qcom: rpmh: Dirt can only make you dirtier, not cleaner
soc: qcom: rpmh-rsc: Factor "tcs_reg_addr" and "tcs_cmd_addr" calculation
soc: qcom: rpmh-rsc: Timeout after 1 second in write_tcs_reg_sync()
soc: qcom: rpmh-rsc: Correctly ignore CPU_CLUSTER_PM notifications
soc: qcom: rpmh-rsc: We aren't notified of our own failure w/ NOTIFY_BAD
kernel/cpu_pm: Fix uninitted local in cpu_pm
soc: qcom: rpmh-rsc: Simplify locking by eliminating the per-TCS lock
soc: qcom: rpmh-rsc: Remove the pm_lock
Gustavo A. R. Silva (1):
firmware: qcom_scm-legacy: Replace zero-length array with flexible-array
Jason Yan (1):
firmware: qcom_scm: Remove unneeded conversion to bool
John Stultz (3):
soc: qcom: rpmh: Allow RPMH driver to be loaded as a module
soc: qcom: rpmhpd: Allow RPMHPD driver to be loaded as a module
soc: qcom: rpmpd: Allow RPMPD driver to be loaded as a module
Markus Elfring (1):
soc: qcom: smp2p: Delete an error message in qcom_smp2p_probe()
Maulik Shah (4):
soc: qcom: rpmh: Update dirty flag only when data changes
soc: qcom: rpmh: Invalidate SLEEP and WAKE TCSes before flushing new data
soc: qcom: rpmh: Invoke rpmh_flush() for dirty caches
soc: qcom: rpmh-rsc: Allow using free WAKE TCS for active request
Raju P.L.S.S.S.N (1):
soc: qcom: rpmh-rsc: Clear active mode configuration for wake TCS
Sibi Sankar (2):
soc: qcom: cmd-db: Fix compilation error when CMD_DB is disabled
soc: qcom: pdr: Remove impossible error condition
Srinivas Kandagatla (1):
soc: qcom: socinfo: add missing soc_id sysfs entry
Stephan Gerhold (1):
dt-bindings: soc: qcom: apr: Use generic node names for APR services
Stephen Boyd (4):
soc: qcom: cmd-db: Add debugfs dumping file
soc: qcom: cmd-db: Cast sizeof() to int to silence field width warning
soc: qcom: cmd-db: Use 5 digits for printing address
soc: qcom: cmd-db: Properly endian swap the slv_id for debugfs
Vincent Knecht (1):
soc: qcom: socinfo: add msm8936/39 and apq8036/39 soc ids
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
.../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 1 +
.../devicetree/bindings/soc/qcom/qcom,apr.txt | 20 +-
drivers/firmware/qcom_scm-legacy.c | 2 +-
drivers/firmware/qcom_scm.c | 11 +-
drivers/soc/qcom/Kconfig | 6 +-
drivers/soc/qcom/cmd-db.c | 78 ++-
drivers/soc/qcom/pdr_interface.c | 4 -
drivers/soc/qcom/qcom_aoss.c | 1 +
drivers/soc/qcom/rpmh-internal.h | 59 +-
drivers/soc/qcom/rpmh-rsc.c | 746 +++++++++++++++------
drivers/soc/qcom/rpmh.c | 97 ++-
drivers/soc/qcom/rpmhpd.c | 24 +
drivers/soc/qcom/rpmpd.c | 5 +
drivers/soc/qcom/smp2p.c | 4 +-
drivers/soc/qcom/socinfo.c | 6 +
include/dt-bindings/power/qcom-rpmpd.h | 12 +
include/soc/qcom/cmd-db.h | 1 +
kernel/cpu_pm.c | 4 +-
19 files changed, 775 insertions(+), 307 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 DT updates for v5.8
From: Bjorn Andersson @ 2020-05-19 5:25 UTC (permalink / raw)
To: arm, soc
Cc: Maulik Shah, Ulf Hansson, Craig Tatlor, Sandeep Maheswaram,
Rajeshwari, Amit Kucheria, Matthias Kaehlcke, Sai Prakash Ranjan,
Arnd Bergmann, Jonathan Marek, Kevin Hilman, Evan Green,
Andy Gross, Sibi Sankar, Alex Elder, Bryan O'Donoghue,
Mike Leach, Alexey Minnekhanov, Stephan Gerhold, linux-arm-msm,
Sharat Masetty, Sivaprakash Murugesan, Michael Srba,
linux-arm-kernel, Krishna Manikandan, Loic Poulain,
Rajendra Nayak, Douglas Anderson, Robert Foss, Olof Johansson
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.8
for you to fetch changes up to 7d2f29e49477aa51339e719cf73f0945c39c8a9e:
arm64: dts: qcom: sc7180: Correct the pdc interrupt ranges (2020-05-18 20:08:35 -0700)
----------------------------------------------------------------
Qualcomm ARM64 DT updates for v5.8
For SDM845 this defines the IPA network accelerator and the CCI camera
control bus, it defines the required UFS reset and adds WiFi for the
Lenovo Yoga C630 and defines GPIO pin names and adds OV8856 and OC7251
camera nodes for DB845c.
For SC7180 it adds GPU support, defines the modem remoteproc, adds the
IPA network accelerator, Coresight and ETM support, adds cpuidle low
power states and updates the CPUs' compatible.
For SM8250 it adds regulators from the PM8150, PM8150L and PM8009 and
adds voltage corners, it defines the nodes for UFS PHY and controller
and finally corrects a typo in the PDC node to make SPMI functional.
For MSM8916 I2C1 and I2C5 are defined, a node for the CCI camera control
interface bus is added and Coresight is disabled by default to match
some product configurations. The Samsung A3U gained display support and
Samsung A5U gained touchscreen support.
MSM8996 now property describes the power supply chain for the GPU, the
CCI camera control interface bus is added and the DB820c has the
regulators of the secondary PMIC defined.
For QCS404 USB PHYs and controllers are defined and wired up for the
EVB.
SDM630/SDM660 platform support is added and the Xiaomi Redmi Note 7
defined.
It also contains a number of changes throughout to improve DT binding
compliance.
----------------------------------------------------------------
Alex Elder (2):
arm64: dts: sdm845: add IPA iommus property
arm64: dts: qcom: sc7180: add IPA information
Alexey Minnekhanov (2):
dt-bindings: arm: qcom: Add sdm630 and sdm660 SoCs
arm64: dts: qcom: Add Xiaomi Redmi Note 7 (lavender)
Amit Kucheria (5):
dt-bindings: arm: cpus: Add kryo468 compatible
arm64: dts: qcom: sc7180: Fix cpu compatible
arm64: dts: qcom: msm8916: remove unit name for thermal trip points
arm64: dts: qcom: msm8996: remove unit name for thermal trip points
arm64: dts: qcom: msm8998: remove unit name for thermal trip points
Bjorn Andersson (9):
arm64: dts: qcom: qcs404: Add USB devices and PHYs
arm64: dts: qcom: sm8250: Add rpmhpd node
arm64: dts: qcom: sm8250: Fix PDC compatible and reg
arm64: dts: qcom: db820c: Add pmi8994 RPM regulators
arm64: dts: qcom: db820c: Fix invalid pm8994 supplies
arm64: dts: qcom: c630: Add WiFi node
arm64: dts: qcom: c630: Specify UFS device reset
arm64: dts: qcom: msm8996: Make GPU node control GPU_GX GDSC
arm64: dts: qcom: sc7180: Fix ETMv4 power management patch
Bryan O'Donoghue (7):
arm64: dts: qcom: qcs404-evb: Define VBUS pins
arm64: dts: qcom: qcs404-evb: Define USB ID pin
arm64: dts: qcom: qcs404-evb: Describe external VBUS regulator
arm64: dts: qcom: qcs404-evb: Raise vreg_l12_3p3 minimum voltage
arm64: dts: qcom: qcs404-evb: Enable USB controllers
arm64: dts: qcom: sm8250-mtp: Add pm8150, pm8150l and pm8009
arm64: dts: qcom: sm8250: Add UFS controller and PHY
Craig Tatlor (1):
arm64: dts: qcom: Add SDM660 SoC support
Douglas Anderson (3):
arm64: dts: qcom: sc7180: Swap order of gpucc and sdhc_2
arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza
arm64: dts: qcom: sc7180: Add "no-map" to cmd_db reserved area
Evan Green (1):
arm64: dts: qcom: sc7180: Include interconnect definitions
Jonathan Marek (1):
arm64: dts: qcom: fix pm8150 gpio interrupts
Krishna Manikandan (1):
arm64: dts: qcom: sc7180: modify assigned clocks for sc7180 target
Loic Poulain (4):
arm64: dts: qcom: msm8916: Add i2c-qcom-cci node
arm64: dts: qcom: apq8016-sbc: Add CCI/Sensor nodes
arm64: dts: msm8996: Fix CSI IRQ types
arch: arm64: dts: msm8996: Add CCI node
Matthias Kaehlcke (1):
arm64: dts: qcom: sc7180: Add interconnect paths for the video codec
Maulik Shah (2):
arm64: dts: qcom: sc7180: Add cpuidle low power states
arm64: dts: qcom: sc7180: Correct the pdc interrupt ranges
Michael Srba (2):
arm64: dts: qcom: msm8916: Disable coresight by default
arm64: dts: qcom: msm8916-samsung-a3u: add nodes for display panel
Mike Leach (1):
arm64: dts: qcom: msm8916: Add CTI options
Rajendra Nayak (1):
arm64: dts: qcom: db820c: Add vdd_gfx and tie it into mmcc
Rajeshwari (1):
arm64: dts: qcom: sc7180: Changed polling mode in Thermal-zones node
Robert Foss (3):
arm64: dts: qcom: sdm845: Add i2c-qcom-cci node
arm64: dts: qcom: sdm845-db845c: Add pm_8998 gpio names
arm64: dts: qcom: sdm845-db845c: Add ov8856 & ov7251 camera nodes
Sai Prakash Ranjan (2):
arm64: dts: qcom: sc7180: Add Coresight support
arm64: dts: qcom: sc7180: Support ETMv4 power management
Sandeep Maheswaram (3):
arm64: dts: qcom: sdm845: Add generic QUSB2 V2 Phy compatible
arm64: dts: qcom: sc7180: Add generic QUSB2 V2 Phy compatible
arm64: dts: qcom: sc7180: Update QUSB2 V2 Phy params for SC7180 IDP device
Sharat Masetty (2):
dt-bindings: arm-smmu: Add sc7180 compatible string
arm64: dts: qcom: sc7180: Add A618 gpu dt blob
Sibi Sankar (4):
arm64: dts: qcom: sdm845: Add SoC compatible to MTP
arm64: dts: qcom: sc7180: Update reserved memory map
arm64: dts: qcom: sc7180: Add Q6V5 MSS node
arm64: dts: qcom: sc7180: Update Q6V5 MSS node
Sivaprakash Murugesan (1):
arm64: dts: ipq8074: qcom: Re-arrange dts nodes based on address
Stephan Gerhold (7):
arm64: dts: qcom: msm8916: Add blsp_i2c1
arm64: dts: qcom: msm8916: Add blsp_i2c5
arm64: dts: qcom: msm8916-samsung-a2015: Add touchscreen regulator
arm64: dts: qcom: msm8916-samsung-a5u: Add touchscreen
arm64: dts: qcom: msm8916: avoid using _ in node names
arm64: dts: qcom: msm8916: move gpu opp table to gpu node
arm64: dts: qcom: apq8016-sbc: merge -pins.dtsi into main .dtsi
Ulf Hansson (2):
arm64: dts: qcom: msm8916: Conform to the domain-idle-state binding
arm64: dts: qcom: msm8916: Conform to the nodename pattern PSCI subnodes
Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
Documentation/devicetree/bindings/arm/qcom.yaml | 7 +
.../devicetree/bindings/iommu/arm,smmu.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi | 74 --
arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 89 --
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 257 +++++-
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 53 +-
arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 112 ++-
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 474 +++++-----
.../boot/dts/qcom/msm8916-longcheer-l8150.dts | 25 +-
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 221 +++--
.../dts/qcom/msm8916-samsung-a2015-common.dtsi | 98 ++-
.../boot/dts/qcom/msm8916-samsung-a3u-eur.dts | 54 ++
.../boot/dts/qcom/msm8916-samsung-a5u-eur.dts | 35 +
arch/arm64/boot/dts/qcom/msm8916.dtsi | 228 ++++-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 87 +-
arch/arm64/boot/dts/qcom/msm8998.dtsi | 38 +-
arch/arm64/boot/dts/qcom/pm8150.dtsi | 14 +-
arch/arm64/boot/dts/qcom/pm8150b.dtsi | 14 +-
arch/arm64/boot/dts/qcom/pm8150l.dtsi | 14 +-
arch/arm64/boot/dts/qcom/pmi8994.dtsi | 6 +
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 85 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 100 +++
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 66 +-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 955 +++++++++++++++++++--
.../arm64/boot/dts/qcom/sdm660-xiaomi-lavender.dts | 46 +
arch/arm64/boot/dts/qcom/sdm660.dtsi | 372 ++++++++
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 2 +
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 210 +++++
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 98 ++-
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 13 +
arch/arm64/boot/dts/qcom/sm8250-mtp.dts | 351 ++++++++
arch/arm64/boot/dts/qcom/sm8250.dtsi | 126 ++-
35 files changed, 3528 insertions(+), 801 deletions(-)
delete mode 100644 arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi
delete mode 100644 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/sdm660-xiaomi-lavender.dts
create mode 100644 arch/arm64/boot/dts/qcom/sdm660.dtsi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox