* [PATCH v3 6/7] IIO: add STM32 timer trigger driver
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480673842-20804-1-git-send-email-benjamin.gaignard@st.com>
Timers IPs can be used to generate triggers for other IPs like
DAC, ADC or other timers.
Each trigger may result of timer internals signals like counter enable,
reset or edge, this configuration could be done through "master_mode"
device attribute.
A timer device could be triggered by other timers, we use the trigger
name and is_stm32_iio_timer_trigger() function to distinguish them
and configure IP input switch.
Timer may also decide on which event (edge, level) they could
be activated by a trigger, this configuration is done by writing in
"slave_mode" device attribute.
Since triggers could also be used by DAC or ADC their names are defined
in include/dt-bindings/iio/timer/st,stm32-iio-timer.h so those IPs will be able
to configure themselves in valid_trigger function
Trigger have a "sampling_frequency" attribute which allow to configure
timer sampling frequency without using pwm interface
version 3:
- change compatible to "st,stm32-timer-trigger"
- fix attributes access right
- use string instead of int for master_mode and slave_mode
- document device attributes in sysfs-bus-iio-timer-stm32
version 2:
- keep only one compatible
- use st,input-triggers-names and st,output-triggers-names
to know which triggers are accepted and/or create by the device
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
.../ABI/testing/sysfs-bus-iio-timer-stm32 | 47 ++
drivers/iio/Kconfig | 2 +-
drivers/iio/Makefile | 1 +
drivers/iio/timer/Kconfig | 15 +
drivers/iio/timer/Makefile | 1 +
drivers/iio/timer/stm32-timer-trigger.c | 477 +++++++++++++++++++++
drivers/iio/trigger/Kconfig | 1 -
.../iio/timer/st,stm32-timer-triggers.h | 60 +++
include/linux/iio/timer/stm32-timer-trigger.h | 16 +
9 files changed, 618 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
create mode 100644 drivers/iio/timer/Kconfig
create mode 100644 drivers/iio/timer/Makefile
create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
create mode 100644 include/dt-bindings/iio/timer/st,stm32-timer-triggers.h
create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
new file mode 100644
index 0000000..b70bb2a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
@@ -0,0 +1,47 @@
+What: /sys/bus/iio/devices/iio:deviceX/master_mode_available
+KernelVersion: 4.10
+Contact: benjamin.gaignard at st.com
+Description:
+ Reading returns the list possible master modes which are:
+ - "reset" : The UG bit from the TIMx_EGR register is used as trigger output (TRGO).
+ - "enable" : The Counter Enable signal CNT_EN is used as trigger output.
+ - "update" : The update event is selected as trigger output.
+ For instance a master timer can then be used as a prescaler for a slave timer.
+ - "compare_pulse" : The trigger output send a positive pulse when the CC1IF flag is to be set.
+ - "OC1REF" : OC1REF signal is used as trigger output.
+ - "OC2REF" : OC2REF signal is used as trigger output.
+ - "OC3REF" : OC3REF signal is used as trigger output.
+ - "OC4REF" : OC4REF signal is used as trigger output.
+
+What: /sys/bus/iio/devices/iio:deviceX/master_mode
+KernelVersion: 4.10
+Contact: benjamin.gaignard at st.com
+Description:
+ Reading returns the current master modes.
+ Writing set the master mode
+
+What: /sys/bus/iio/devices/iio:deviceX/slave_mode_available
+KernelVersion: 4.10
+Contact: benjamin.gaignard at st.com
+Description:
+ Reading returns the list possible slave modes which are:
+ - "disabled" : The prescaler is clocked directly by the internal clock.
+ - "encoder_1" : Counter counts up/down on TI2FP1 edge depending on TI1FP2 level.
+ - "encoder_2" : Counter counts up/down on TI1FP2 edge depending on TI2FP1 level.
+ - "encoder_3" : Counter counts up/down on both TI1FP1 and TI2FP2 edges depending
+ on the level of the other input.
+ - "reset" : Rising edge of the selected trigger input reinitializes the counter
+ and generates an update of the registers.
+ - "gated" : The counter clock is enabled when the trigger input is high.
+ The counter stops (but is not reset) as soon as the trigger becomes low.
+ Both start and stop of the counter are controlled.
+ - "trigger" : The counter starts at a rising edge of the trigger TRGI (but it is not
+ reset). Only the start of the counter is controlled.
+ - "external_clock": Rising edges of the selected trigger (TRGI) clock the counter.
+
+What: /sys/bus/iio/devices/iio:deviceX/slave_mode
+KernelVersion: 4.10
+Contact: benjamin.gaignard at st.com
+Description:
+ Reading returns the current slave mode.
+ Writing set the slave mode
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18..2de2a80 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -90,5 +90,5 @@ source "drivers/iio/potentiometer/Kconfig"
source "drivers/iio/pressure/Kconfig"
source "drivers/iio/proximity/Kconfig"
source "drivers/iio/temperature/Kconfig"
-
+source "drivers/iio/timer/Kconfig"
endif # IIO
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c43..b797c08 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -32,4 +32,5 @@ obj-y += potentiometer/
obj-y += pressure/
obj-y += proximity/
obj-y += temperature/
+obj-y += timer/
obj-y += trigger/
diff --git a/drivers/iio/timer/Kconfig b/drivers/iio/timer/Kconfig
new file mode 100644
index 0000000..149a917
--- /dev/null
+++ b/drivers/iio/timer/Kconfig
@@ -0,0 +1,15 @@
+#
+# Timers drivers
+
+menu "Timers"
+
+config IIO_STM32_TIMER_TRIGGER
+ tristate "stm32 timer trigger"
+ depends on ARCH_STM32
+ depends on OF
+ select IIO_TRIGGERED_EVENT
+ select MFD_STM32_GP_TIMER
+ help
+ Select this option to enable stm32 timer trigger
+
+endmenu
diff --git a/drivers/iio/timer/Makefile b/drivers/iio/timer/Makefile
new file mode 100644
index 0000000..4ad95ec9
--- /dev/null
+++ b/drivers/iio/timer/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_IIO_STM32_TIMER_TRIGGER) += stm32-timer-trigger.o
diff --git a/drivers/iio/timer/stm32-timer-trigger.c b/drivers/iio/timer/stm32-timer-trigger.c
new file mode 100644
index 0000000..0c51601
--- /dev/null
+++ b/drivers/iio/timer/stm32-timer-trigger.c
@@ -0,0 +1,477 @@
+/*
+ * stm32-iio-timer.c
+ *
+ * Copyright (C) STMicroelectronics 2016
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/timer/stm32-timer-trigger.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/triggered_event.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/stm32-gptimer.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#define DRIVER_NAME "stm32-timer-trigger"
+#define MAX_MODES 8
+
+struct stm32_timer_trigger_dev {
+ struct device *dev;
+ struct regmap *regmap;
+ struct clk *clk;
+ int irq;
+ bool own_timer;
+ unsigned int sampling_frequency;
+ struct iio_trigger *active_trigger;
+};
+
+static ssize_t _store_frequency(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct stm32_timer_trigger_dev *stm32 = iio_trigger_get_drvdata(trig);
+ unsigned int freq;
+ int ret;
+
+ ret = kstrtouint(buf, 10, &freq);
+ if (ret)
+ return ret;
+
+ stm32->sampling_frequency = freq;
+
+ return len;
+}
+
+static ssize_t _read_frequency(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct stm32_timer_trigger_dev *stm32 = iio_trigger_get_drvdata(trig);
+ unsigned long long freq = stm32->sampling_frequency;
+ u32 psc, arr, cr1;
+
+ regmap_read(stm32->regmap, TIM_CR1, &cr1);
+ regmap_read(stm32->regmap, TIM_PSC, &psc);
+ regmap_read(stm32->regmap, TIM_ARR, &arr);
+
+ if (psc && arr && (cr1 & TIM_CR1_CEN)) {
+ freq = (unsigned long long)clk_get_rate(stm32->clk);
+ do_div(freq, psc);
+ do_div(freq, arr);
+ }
+
+ return sprintf(buf, "%d\n", (unsigned int)freq);
+}
+
+static IIO_DEV_ATTR_SAMP_FREQ(0660, _read_frequency, _store_frequency);
+
+static struct attribute *stm32_trigger_attrs[] = {
+ &iio_dev_attr_sampling_frequency.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group stm32_trigger_attr_group = {
+ .attrs = stm32_trigger_attrs,
+};
+
+static const struct attribute_group *stm32_trigger_attr_groups[] = {
+ &stm32_trigger_attr_group,
+ NULL,
+};
+
+static char *master_mode_table[] = {
+ "reset",
+ "enable",
+ "update",
+ "compare_pulse",
+ "OC1REF",
+ "OC2REF",
+ "OC3REF",
+ "OC4REF"
+};
+
+static
+ssize_t _show_master_mode(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct stm32_timer_trigger_dev *stm32 = iio_priv(indio_dev);
+ u32 cr2;
+
+ regmap_read(stm32->regmap, TIM_CR2, &cr2);
+ cr2 = (cr2 >> 4) & 0x7;
+
+ return snprintf(buf, PAGE_SIZE, "%s\n", master_mode_table[cr2]);
+}
+
+static
+ssize_t _store_master_mode(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct stm32_timer_trigger_dev *stm32 = iio_priv(indio_dev);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(master_mode_table); i++) {
+ if (!strncmp(master_mode_table[i], buf,
+ strlen(master_mode_table[i]))) {
+ regmap_update_bits(stm32->regmap, TIM_CR2,
+ TIM_CR2_MMS, i << 4);
+ return len;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static IIO_CONST_ATTR(master_mode_available,
+ "reset enable update compare_pulse OC1REF OC2REF OC3REF OC4REF");
+
+static IIO_DEVICE_ATTR(master_mode, 0660,
+ _show_master_mode,
+ _store_master_mode,
+ 0);
+
+static char *slave_mode_table[] = {
+ "disabled",
+ "encoder_1",
+ "encoder_2",
+ "encoder_3",
+ "reset",
+ "gated",
+ "trigger",
+ "external_clock",
+};
+
+static
+ssize_t _show_slave_mode(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct stm32_timer_trigger_dev *stm32 = iio_priv(indio_dev);
+ u32 smcr;
+
+ regmap_read(stm32->regmap, TIM_SMCR, &smcr);
+ smcr &= 0x7;
+
+ return snprintf(buf, PAGE_SIZE, "%s\n", slave_mode_table[smcr]);
+}
+
+static
+ssize_t _store_slave_mode(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct stm32_timer_trigger_dev *stm32 = iio_priv(indio_dev);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(slave_mode_table); i++) {
+ if (!strncmp(slave_mode_table[i], buf,
+ strlen(slave_mode_table[i]))) {
+ regmap_update_bits(stm32->regmap,
+ TIM_SMCR, TIM_SMCR_SMS, i);
+ return len;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static IIO_CONST_ATTR(slave_mode_available,
+ "disabled encoder_1 encoder_2 encoder_3 reset gated trigger external_clock");
+
+static IIO_DEVICE_ATTR(slave_mode, 0660,
+ _show_slave_mode,
+ _store_slave_mode,
+ 0);
+
+static struct attribute *stm32_timer_attrs[] = {
+ &iio_dev_attr_master_mode.dev_attr.attr,
+ &iio_const_attr_master_mode_available.dev_attr.attr,
+ &iio_dev_attr_slave_mode.dev_attr.attr,
+ &iio_const_attr_slave_mode_available.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group stm32_timer_attr_group = {
+ .attrs = stm32_timer_attrs,
+};
+
+static int stm32_timer_start(struct stm32_timer_trigger_dev *stm32)
+{
+ unsigned long long prd, div;
+ int prescaler = 0;
+ u32 max_arr = 0xFFFF, cr1;
+
+ if (stm32->sampling_frequency == 0)
+ return 0;
+
+ /* Period and prescaler values depends of clock rate */
+ div = (unsigned long long)clk_get_rate(stm32->clk);
+
+ do_div(div, stm32->sampling_frequency);
+
+ prd = div;
+
+ while (div > max_arr) {
+ prescaler++;
+ div = prd;
+ do_div(div, (prescaler + 1));
+ }
+ prd = div;
+
+ if (prescaler > MAX_TIM_PSC) {
+ dev_err(stm32->dev, "prescaler exceeds the maximum value\n");
+ return -EINVAL;
+ }
+
+ /* Check that we own the timer */
+ regmap_read(stm32->regmap, TIM_CR1, &cr1);
+ if ((cr1 & TIM_CR1_CEN) && !stm32->own_timer)
+ return -EBUSY;
+
+ if (!stm32->own_timer) {
+ stm32->own_timer = true;
+ clk_enable(stm32->clk);
+ }
+
+ regmap_write(stm32->regmap, TIM_PSC, prescaler);
+ regmap_write(stm32->regmap, TIM_ARR, prd - 1);
+ regmap_update_bits(stm32->regmap, TIM_CR1, TIM_CR1_ARPE, TIM_CR1_ARPE);
+
+ /* Force master mode to update mode */
+ regmap_update_bits(stm32->regmap, TIM_CR2, TIM_CR2_MMS, 0x20);
+
+ /* Make sure that registers are updated */
+ regmap_update_bits(stm32->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
+
+ /* Enable interrupt */
+ regmap_write(stm32->regmap, TIM_SR, 0);
+ regmap_update_bits(stm32->regmap, TIM_DIER, TIM_DIER_UIE, TIM_DIER_UIE);
+
+ /* Enable controller */
+ regmap_update_bits(stm32->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
+
+ return 0;
+}
+
+static int stm32_timer_stop(struct stm32_timer_trigger_dev *stm32)
+{
+ if (!stm32->own_timer)
+ return 0;
+
+ /* Stop timer */
+ regmap_update_bits(stm32->regmap, TIM_DIER, TIM_DIER_UIE, 0);
+ regmap_update_bits(stm32->regmap, TIM_CR1, TIM_CR1_CEN, 0);
+ regmap_write(stm32->regmap, TIM_PSC, 0);
+ regmap_write(stm32->regmap, TIM_ARR, 0);
+
+ clk_disable(stm32->clk);
+
+ stm32->own_timer = false;
+ stm32->active_trigger = NULL;
+
+ return 0;
+}
+
+static int stm32_set_trigger_state(struct iio_trigger *trig, bool state)
+{
+ struct stm32_timer_trigger_dev *stm32 = iio_trigger_get_drvdata(trig);
+
+ stm32->active_trigger = trig;
+
+ if (state)
+ return stm32_timer_start(stm32);
+ else
+ return stm32_timer_stop(stm32);
+}
+
+static irqreturn_t stm32_timer_irq_handler(int irq, void *private)
+{
+ struct stm32_timer_trigger_dev *stm32 = private;
+ u32 sr;
+
+ regmap_read(stm32->regmap, TIM_SR, &sr);
+ regmap_write(stm32->regmap, TIM_SR, 0);
+
+ if ((sr & TIM_SR_UIF) && stm32->active_trigger)
+ iio_trigger_poll(stm32->active_trigger);
+
+ return IRQ_HANDLED;
+}
+
+static const struct iio_trigger_ops timer_trigger_ops = {
+ .owner = THIS_MODULE,
+ .set_trigger_state = stm32_set_trigger_state,
+};
+
+static int stm32_setup_iio_triggers(struct stm32_timer_trigger_dev *stm32)
+{
+ int ret;
+ struct property *p;
+ const char *cur = NULL;
+
+ p = of_find_property(stm32->dev->of_node,
+ "st,output-triggers-names", NULL);
+
+ while ((cur = of_prop_next_string(p, cur)) != NULL) {
+ struct iio_trigger *trig;
+
+ trig = devm_iio_trigger_alloc(stm32->dev, "%s", cur);
+ if (!trig)
+ return -ENOMEM;
+
+ trig->dev.parent = stm32->dev->parent;
+ trig->ops = &timer_trigger_ops;
+ trig->dev.groups = stm32_trigger_attr_groups;
+ iio_trigger_set_drvdata(trig, stm32);
+
+ ret = devm_iio_trigger_register(stm32->dev, trig);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * is_stm32_timer_trigger
+ * @trig: trigger to be checked
+ *
+ * return true if the trigger is a valid stm32 iio timer trigger
+ * either return false
+ */
+bool is_stm32_timer_trigger(struct iio_trigger *trig)
+{
+ return (trig->ops == &timer_trigger_ops);
+}
+EXPORT_SYMBOL(is_stm32_timer_trigger);
+
+static int stm32_validate_trigger(struct iio_dev *indio_dev,
+ struct iio_trigger *trig)
+{
+ struct stm32_timer_trigger_dev *dev = iio_priv(indio_dev);
+ int ret;
+
+ if (!is_stm32_timer_trigger(trig))
+ return -EINVAL;
+
+ ret = of_property_match_string(dev->dev->of_node,
+ "st,input-triggers-names",
+ trig->name);
+
+ if (ret < 0)
+ return ret;
+
+ regmap_update_bits(dev->regmap, TIM_SMCR, TIM_SMCR_TS, ret << 4);
+
+ return 0;
+}
+
+static const struct iio_info stm32_trigger_info = {
+ .driver_module = THIS_MODULE,
+ .validate_trigger = stm32_validate_trigger,
+ .attrs = &stm32_timer_attr_group,
+};
+
+static struct stm32_timer_trigger_dev *stm32_setup_iio_device(struct device *dev)
+{
+ struct iio_dev *indio_dev;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(struct stm32_timer_trigger_dev));
+ if (!indio_dev)
+ return NULL;
+
+ indio_dev->name = dev_name(dev);
+ indio_dev->dev.parent = dev;
+ indio_dev->info = &stm32_trigger_info;
+ indio_dev->modes = INDIO_EVENT_TRIGGERED;
+ indio_dev->num_channels = 0;
+ indio_dev->dev.of_node = dev->of_node;
+
+ ret = iio_triggered_event_setup(indio_dev,
+ NULL,
+ stm32_timer_irq_handler);
+ if (ret)
+ return NULL;
+
+ ret = devm_iio_device_register(dev, indio_dev);
+ if (ret) {
+ iio_triggered_event_cleanup(indio_dev);
+ return NULL;
+ }
+
+ return iio_priv(indio_dev);
+}
+
+static int stm32_timer_trigger_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct stm32_timer_trigger_dev *stm32;
+ struct stm32_gptimer_dev *mfd = dev_get_drvdata(pdev->dev.parent);
+ int ret;
+
+ stm32 = stm32_setup_iio_device(dev);
+ if (!stm32)
+ return -ENOMEM;
+
+ stm32->dev = dev;
+ stm32->regmap = mfd->regmap;
+ stm32->clk = mfd->clk;
+
+ stm32->irq = platform_get_irq(pdev, 0);
+ if (stm32->irq < 0)
+ return -EINVAL;
+
+ ret = devm_request_irq(stm32->dev, stm32->irq,
+ stm32_timer_irq_handler, IRQF_SHARED,
+ "timer_event", stm32);
+ if (ret)
+ return ret;
+
+ ret = stm32_setup_iio_triggers(stm32);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, stm32);
+
+ return 0;
+}
+
+static int stm32_timer_trigger_remove(struct platform_device *pdev)
+{
+ struct stm32_timer_trigger_dev *stm32 = platform_get_drvdata(pdev);
+
+ iio_triggered_event_cleanup((struct iio_dev *)stm32);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_trig_of_match[] = {
+ {
+ .compatible = "st,stm32-timer-trigger",
+ },
+};
+MODULE_DEVICE_TABLE(of, stm32_trig_of_match);
+
+static struct platform_driver stm32_timer_trigger_driver = {
+ .probe = stm32_timer_trigger_probe,
+ .remove = stm32_timer_trigger_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = stm32_trig_of_match,
+ },
+};
+module_platform_driver(stm32_timer_trigger_driver);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_DESCRIPTION("STMicroelectronics STM32 timer trigger driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 809b2e7..f2af4fe 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -46,5 +46,4 @@ config IIO_SYSFS_TRIGGER
To compile this driver as a module, choose M here: the
module will be called iio-trig-sysfs.
-
endmenu
diff --git a/include/dt-bindings/iio/timer/st,stm32-timer-triggers.h b/include/dt-bindings/iio/timer/st,stm32-timer-triggers.h
new file mode 100644
index 0000000..a13db63
--- /dev/null
+++ b/include/dt-bindings/iio/timer/st,stm32-timer-triggers.h
@@ -0,0 +1,60 @@
+/*
+ * st,stm32-timer-triggers.h
+ *
+ * Copyright (C) STMicroelectronics 2016
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#ifndef _DT_BINDINGS_STM32_TIMER_TRIGGERS_H_
+#define _DT_BINDINGS_STM32_TIMER_TRIGGERS_H_
+
+#define TIM1_TRGO "tim1_trgo"
+#define TIM1_CH1 "tim1_ch1"
+#define TIM1_CH2 "tim1_ch2"
+#define TIM1_CH3 "tim1_ch3"
+#define TIM1_CH4 "tim1_ch4"
+
+#define TIM2_TRGO "tim2_trgo"
+#define TIM2_CH1 "tim2_ch1"
+#define TIM2_CH2 "tim2_ch2"
+#define TIM2_CH3 "tim2_ch3"
+#define TIM2_CH4 "tim2_ch4"
+
+#define TIM3_TRGO "tim3_trgo"
+#define TIM3_CH1 "tim3_ch1"
+#define TIM3_CH2 "tim3_ch2"
+#define TIM3_CH3 "tim3_ch3"
+#define TIM3_CH4 "tim3_ch4"
+
+#define TIM4_TRGO "tim4_trgo"
+#define TIM4_CH1 "tim4_ch1"
+#define TIM4_CH2 "tim4_ch2"
+#define TIM4_CH3 "tim4_ch3"
+#define TIM4_CH4 "tim4_ch4"
+
+#define TIM5_TRGO "tim5_trgo"
+#define TIM5_CH1 "tim5_ch1"
+#define TIM5_CH2 "tim5_ch2"
+#define TIM5_CH3 "tim5_ch3"
+#define TIM5_CH4 "tim5_ch4"
+
+#define TIM6_TRGO "tim6_trgo"
+
+#define TIM7_TRGO "tim7_trgo"
+
+#define TIM8_TRGO "tim8_trgo"
+#define TIM8_CH1 "tim8_ch1"
+#define TIM8_CH2 "tim8_ch2"
+#define TIM8_CH3 "tim8_ch3"
+#define TIM8_CH4 "tim8_ch4"
+
+#define TIM9_TRGO "tim9_trgo"
+#define TIM9_CH1 "tim9_ch1"
+#define TIM9_CH2 "tim9_ch2"
+
+#define TIM12_TRGO "tim12_trgo"
+#define TIM12_CH1 "tim12_ch1"
+#define TIM12_CH2 "tim12_ch2"
+
+#endif
diff --git a/include/linux/iio/timer/stm32-timer-trigger.h b/include/linux/iio/timer/stm32-timer-trigger.h
new file mode 100644
index 0000000..c22fb3b
--- /dev/null
+++ b/include/linux/iio/timer/stm32-timer-trigger.h
@@ -0,0 +1,16 @@
+/*
+ * stm32-timer-trigger.h
+ *
+ * Copyright (C) STMicroelectronics 2016
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#ifndef _STM32_TIMER_TRIGGER_H_
+#define _STM32_TIMER_TRIGGER_H_
+
+#include <dt-bindings/iio/timer/st,stm32-timer-triggers.h>
+
+bool is_stm32_timer_trigger(struct iio_trigger *trig);
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480673842-20804-1-git-send-email-benjamin.gaignard@st.com>
Add general purpose timers and it sub-nodes into DT for stm32f4.
Define and enable pwm1 and pwm3 for stm32f469 discovery board
version 3:
- use "st,stm32-timer-trigger" in DT
version 2:
- use parameters to describe hardware capabilities
- do not use references for pwm and iio timer subnodes
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 333 +++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/stm32f469-disco.dts | 28 +++
2 files changed, 360 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index bca491d..8c50d03 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,7 +48,7 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
-
+#include <dt-bindings/iio/timer/st,stm32-timer-triggers.h>
/ {
clocks {
clk_hse: clk-hse {
@@ -355,6 +355,21 @@
slew-rate = <2>;
};
};
+
+ pwm1_pins: pwm at 1 {
+ pins {
+ pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
+ <STM32F429_PB13_FUNC_TIM1_CH1N>,
+ <STM32F429_PB12_FUNC_TIM1_BKIN>;
+ };
+ };
+
+ pwm3_pins: pwm at 3 {
+ pins {
+ pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
+ <STM32F429_PB5_FUNC_TIM3_CH2>;
+ };
+ };
};
rcc: rcc at 40023810 {
@@ -426,6 +441,322 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+ gptimer1: gptimer1 at 40010000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40010000 0x400>;
+ clocks = <&rcc 0 160>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm1 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,breakinput;
+ st,complementary;
+ status = "disabled";
+ };
+
+ timer1 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <27>;
+ st,input-triggers-names = TIM5_TRGO,
+ TIM2_TRGO,
+ TIM4_TRGO,
+ TIM3_TRGO;
+ st,output-triggers-names = TIM1_TRGO,
+ TIM1_CH1,
+ TIM1_CH2,
+ TIM1_CH3,
+ TIM1_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer2: gptimer2 at 40000000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000000 0x400>;
+ clocks = <&rcc 0 128>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm2 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,32bits-counter;
+ status = "disabled";
+ };
+
+ timer2 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <28>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM8_TRGO,
+ TIM3_TRGO,
+ TIM4_TRGO;
+ st,output-triggers-names = TIM2_TRGO,
+ TIM2_CH1,
+ TIM2_CH2,
+ TIM2_CH3,
+ TIM2_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer3: gptimer3 at 40000400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000400 0x400>;
+ clocks = <&rcc 0 129>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm3 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ status = "disabled";
+ };
+
+ timer3 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <29>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM8_TRGO,
+ TIM5_TRGO,
+ TIM4_TRGO;
+ st,output-triggers-names = TIM3_TRGO,
+ TIM3_CH1,
+ TIM3_CH2,
+ TIM3_CH3,
+ TIM3_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer4: gptimer4 at 40000800 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000800 0x400>;
+ clocks = <&rcc 0 130>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm4 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ status = "disabled";
+ };
+
+ timer4 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <30>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM2_TRGO,
+ TIM3_TRGO,
+ TIM8_TRGO;
+ st,output-triggers-names = TIM4_TRGO,
+ TIM4_CH1,
+ TIM4_CH2,
+ TIM4_CH3,
+ TIM4_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer5: gptimer5 at 40000C00 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000C00 0x400>;
+ clocks = <&rcc 0 131>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm5 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,32bits-counter;
+ status = "disabled";
+ };
+
+ timer5 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <50>;
+ st,input-triggers-names = TIM2_TRGO,
+ TIM3_TRGO,
+ TIM4_TRGO,
+ TIM8_TRGO;
+ st,output-triggers-names = TIM5_TRGO,
+ TIM5_CH1,
+ TIM5_CH2,
+ TIM5_CH3,
+ TIM5_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer6: gptimer6 at 40001000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001000 0x400>;
+ clocks = <&rcc 0 132>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ timer6 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <54>;
+ st,output-triggers-names = TIM6_TRGO;
+ status = "disabled";
+ };
+ };
+
+ gptimer7: gptimer7 at 40001400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001400 0x400>;
+ clocks = <&rcc 0 133>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ timer7 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <55>;
+ st,output-triggers-names = TIM7_TRGO;
+ status = "disabled";
+ };
+ };
+
+ gptimer8: gptimer8 at 40010400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40010400 0x400>;
+ clocks = <&rcc 0 161>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm8 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,complementary;
+ st,breakinput;
+ status = "disabled";
+ };
+
+ timer8 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <46>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM2_TRGO,
+ TIM4_TRGO,
+ TIM5_TRGO;
+ st,output-triggers-names = TIM8_TRGO,
+ TIM8_CH1,
+ TIM8_CH2,
+ TIM8_CH3,
+ TIM8_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer9: gptimer9 at 40014000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40014000 0x400>;
+ clocks = <&rcc 0 176>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm9 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <2>;
+ status = "disabled";
+ };
+
+ timer9 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <24>;
+ st,input-triggers-names = TIM2_TRGO,
+ TIM3_TRGO;
+ st,output-triggers-names = TIM9_TRGO,
+ TIM9_CH1,
+ TIM9_CH2;
+ status = "disabled";
+ };
+ };
+
+ gptimer10: gptimer10 at 40014400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40014400 0x400>;
+ clocks = <&rcc 0 177>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm10 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
+
+ gptimer11: gptimer11 at 40014800 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40014800 0x400>;
+ clocks = <&rcc 0 178>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm11 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
+
+ gptimer12: gptimer12 at 40001800 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001800 0x400>;
+ clocks = <&rcc 0 134>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm12 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <2>;
+ status = "disabled";
+ };
+
+ timer12 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <43>;
+ st,input-triggers-names = TIM4_TRGO,
+ TIM5_TRGO;
+ st,output-triggers-names = TIM12_TRGO,
+ TIM12_CH1,
+ TIM12_CH2;
+ status = "disabled";
+ };
+ };
+
+ gptimer13: gptimer13 at 40001C00 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001C00 0x400>;
+ clocks = <&rcc 0 135>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm13 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
+
+ gptimer14: gptimer14 at 40002000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40002000 0x400>;
+ clocks = <&rcc 0 136>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm14 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 8a163d7..df4ca7e 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -81,3 +81,31 @@
&usart3 {
status = "okay";
};
+
+&gptimer1 {
+ status = "okay";
+
+ pwm1 at 0 {
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer1 at 0 {
+ status = "okay";
+ };
+};
+
+&gptimer3 {
+ status = "okay";
+
+ pwm3 at 0 {
+ pinctrl-0 = <&pwm3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer3 at 0 {
+ status = "okay";
+ };
+};
--
1.9.1
^ permalink raw reply related
* XHCI controller does not detect USB key insertion
From: Mason @ 2016-12-02 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87inr2vh2l.fsf@linux.intel.com>
On 02/12/2016 10:03, Felipe Balbi wrote:
> Mason wrote:
>
>> I'm trying out a SoC with a brand new USB controller, which is (supposedly)
>> a standard XHCI controller. In theory, I would just need to build the right
>> driver, and everything would auto-magically work, right?
>
> perhaps, but there might be needed initialization of other resources
> like PHYs and stuff like that.
Let me dive into additional details...
First of all, there is a register aptly called "USB3_RESET" which
is used to release several USB3-related blocks from reset.
Of course, that's the first register I tweaked :-)
There are *3* address ranges with USB3-related registers.
1) one called host_usb30_xhcl (I believe "xhcl" is a typo for "xhci")
This is the address I passed to the Linux driver. The first register
is CAPLENGTH_VERSION. I assume these are the standard XHCI registers.
(Last register is XHCL_EXTENDED_CAP3_USB3 at offset 0xc008)
2) one called host_usb30_port
This contains "Device and Port Specific Registers".
Is it standard?
How is Linux supposed to know where to find it?
Contains registers such as
Device Transaction Status
Device UTMI command and status for USB2
Set ISOC Delay
USB3 Function Notification
Rx DMA BD Start Address for Control Endpoint
EP Burst Size
Tx DMA BD Start Address Control Endpoint
EP $N IN/OUT
Device Notification Register
EP_Isochronous Timestamp
Are registers named LTSSM_TIMER_REGISTER{1,2,3} standard?
they have fields such as reg_12_ms_timeout (and other numbers like 2, 6, 100, 300)
3) one called host_usb30
This contains lower-level stuff
0x2e800 CONFIG
0x2e804 CONTROL
0x2e808 TEST
0x2e80c STATUS
0x2e810 CLK_RST_0
0x2e814 CLK_RST_1
0x2e818 PARAM_0
0x2e81c PARAM_1
0x2e820 PARAM_2
0x2e880 SNPS_CR_ADD
0x2e884 SNPS_CR_DATA
0x2e8c0 RESET_CTRL
I haven't touched any of these so far.
>> # lsusb -v
>> Bus 001 Device 001: ID 1d6b:0002
>> Bus 002 Device 001: ID 1d6b:0003
Isn't lsusb verbose supposed to print much more than that?
>> I'd like to hear suggestions about what I can tweak to fix the problem.
>
> go to your documentation and see if you have initialized
> everything. Which SoC is this?
(Sad face) All the documentation I have is in front of me, and nothing
is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI
controller + Synopsys PHY.
The documentation I have:
Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals)
Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers)
PHY databook (very low-level stuff)
SoC register mapping (for how the SoC maps the IP signals to registers)
So far, I'm stumped :-(
Regards.
^ permalink raw reply
* [RFC PATCH] PCI: designware: add host_init() error handling
From: Joao Pinto @ 2016-12-02 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593077-15402-1-git-send-email-srinivas.kandagatla@linaro.org>
Hi Srinivas,
?s 11:51 AM de 12/1/2016, Srinivas Kandagatla escreveu:
> drivers/pci/host/pci-dra7xx.c | 4 +++-
> drivers/pci/host/pci-exynos.c | 4 +++-
> drivers/pci/host/pci-imx6.c | 4 +++-
> drivers/pci/host/pci-keystone.c | 4 +++-
> drivers/pci/host/pci-layerscape.c | 12 ++++++++----
> drivers/pci/host/pcie-armada8k.c | 4 +++-
> drivers/pci/host/pcie-designware-plat.c | 4 +++-
> drivers/pci/host/pcie-designware.c | 4 +++-
> drivers/pci/host/pcie-designware.h | 2 +-
> drivers/pci/host/pcie-qcom.c | 6 ++++--
> drivers/pci/host/pcie-spear13xx.c | 4 +++-
> 11 files changed, 37 insertions(+), 15 deletions(-)
>
Thanks for the patch!
In my opinion your idea is good but only qcom driver is able to detect failure
in the specific host init routine, all others have a 'return 0' even if
something not well init. I would recomend that we take this issue a bit further
and add the error checking to all specific pci drivers in order to make them as
robust as qcom'.
Thanks,
Joao
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Greg KH @ 2016-12-02 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58414BC5.109@free.fr>
On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote:
> >> # lsusb -v
> >> Bus 001 Device 001: ID 1d6b:0002
> >> Bus 002 Device 001: ID 1d6b:0003
>
> Isn't lsusb verbose supposed to print much more than that?
Yes, if you are using the usbutils version of 'lsusb', odds are this is
busybox, right?
And these are just the root hubs, that the USB controller driver creates
as "virtual" USB devices, they are not "real" USB devices on your bus.
hope this helps,
greg k-h
^ permalink raw reply
* [Linaro-acpi] [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Robert Richter @ 2016-12-02 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <30ad6c65-4a4a-6346-00f6-11250133a251@semihalf.com>
On 02.12.16 11:06:24, Tomasz Nowicki wrote:
> On 02.12.2016 07:42, Duc Dang wrote:
> >@@ -98,16 +98,16 @@ struct mcfg_fixup {
> > { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
> > &pci_thunder_ecam_ops }
> > /* SoC pass1.x */
> >- THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
> >- THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
> >- THUNDER_ECAM_QUIRK(2, 0),
> >- THUNDER_ECAM_QUIRK(2, 1),
> >- THUNDER_ECAM_QUIRK(2, 2),
> >- THUNDER_ECAM_QUIRK(2, 3),
> >- THUNDER_ECAM_QUIRK(2, 10),
> >- THUNDER_ECAM_QUIRK(2, 11),
> >- THUNDER_ECAM_QUIRK(2, 12),
> >- THUNDER_ECAM_QUIRK(2, 13),
> >+ THUNDER_PEM_QUIRK(2, 0UL), /* off-chip devices */
> >+ THUNDER_PEM_QUIRK(2, 1UL), /* off-chip devices */
> >+ THUNDER_ECAM_QUIRK(2, 0UL),
> >+ THUNDER_ECAM_QUIRK(2, 1UL),
> >+ THUNDER_ECAM_QUIRK(2, 2UL),
> >+ THUNDER_ECAM_QUIRK(2, 3UL),
> >+ THUNDER_ECAM_QUIRK(2, 10UL),
> >+ THUNDER_ECAM_QUIRK(2, 11UL),
> >+ THUNDER_ECAM_QUIRK(2, 12UL),
> >+ THUNDER_ECAM_QUIRK(2, 13UL),
> >
>
> The UL suffix is needed for *THUNDER_PEM_QUIRK* only. THUNDER_ECAM_QUIRK is
> fine.
We should better make the type cast part of the macro.
+ this:
---
#define THUNDER_MCFG_RES(addr, node) \
DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M)
---
The args in the macro need parentheses.
-Robert
^ permalink raw reply
* [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
From: Will Deacon @ 2016-12-02 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18021c70-a4a0-3007-c861-82ede74f965e@virtualopensystems.com>
On Fri, Dec 02, 2016 at 10:13:43AM +0100, Maciej Bielski wrote:
> Recently we have announced our effort on that:
> https://lkml.org/lkml/2016/11/17/49
>
> For now we have a working solution for hotplug and we are performing
> code cleanup to push the patches soon.
Are these intended to replace or extend Scott's patches? If the former,
please work with Scott's stuff as a base rather than posting a competing
series.
Will
^ permalink raw reply
* [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
From: Maciej Bielski @ 2016-12-02 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202104907.GB8266@arm.com>
On 02/12/2016 11:49, Will Deacon wrote:
> On Fri, Dec 02, 2016 at 10:13:43AM +0100, Maciej Bielski wrote:
>> Recently we have announced our effort on that:
>> https://lkml.org/lkml/2016/11/17/49
>>
>> For now we have a working solution for hotplug and we are performing
>> code cleanup to push the patches soon.
> Are these intended to replace or extend Scott's patches? If the former,
> please work with Scott's stuff as a base rather than posting a competing
> series.
In the piece of code provided by Scott I have seen similar steps to what
is done by us but our work went further since we have the mapping
created and everything is working via the sysfs interface. I am now
having closer look and comparing them.
>
> Will
--
Maciej Bielski
^ permalink raw reply
* [PATCH 1/2] arm64: Get rid of asm/opcodes.h
From: Catalin Marinas @ 2016-12-02 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480589074-809-2-git-send-email-marc.zyngier@arm.com>
On Thu, Dec 01, 2016 at 10:44:33AM +0000, Marc Zyngier wrote:
> The opcodes.h drags in a lot of definition from the 32bit port, most
> of which is not required at all. Clean things up a bit by moving
> the bare minimum of what is required next to the actual users,
> and drop the include file.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/opcodes.h | 5 -----
> arch/arm64/include/asm/sysreg.h | 16 ++++++++++------
> arch/arm64/kernel/armv8_deprecated.c | 5 ++++-
> arch/arm64/kernel/insn.c | 1 -
I applied the first patch. I assume the second one, once it gets into
its final shape, will be merged via the Xen tree.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH 1/3] ARM: da850: fix infinite loop in clk_set_rate()
From: Sekhar Nori @ 2016-12-02 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612516-18853-2-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
On Thursday 01 December 2016 10:45 PM, Bartosz Golaszewski wrote:
> The aemif clock is added twice to the lookup table in da850.c. This
> breaks the children list of pll0_sysclk3 as we're using the same list
> links in struct clk. When calling clk_set_rate(), we get stuck in
> propagate_rate().
>
> Simply add the clock once, but specify both the con_id and dev_id in
> the lookup entry.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The issue is real, but the fix is not going to be this simple, I am
afraid. This will break NAND on all da850 boards including LCDK.
The aemif clock is accessed in two ways. One by the
drivers/memory/ti-aemif.c, using ti-aemif as the device name and NULL
connection id. Second by drivers/mtd/nand/davinci_nand.c and
arch/arm/mach-davinci/aemif.c using davinci-nand as device id and with
"aemif" as the connection id.
We will need to match both. The only way to fix this without breaking
anything is to create two clocks for the two lookups above. Both cannot
be PSC clocks for the same PSC module as that would be racy. Instead
just create a new nand clock node which is a child of the aemif node and
inherits parent's clock rate.
Thanks,
Sekhar
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Mason @ 2016-12-02 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202104208.GA8736@kroah.com>
On 02/12/2016 11:42, Greg KH wrote:
> On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote:
>
>> # lsusb -v
>> Bus 001 Device 001: ID 1d6b:0002
>> Bus 002 Device 001: ID 1d6b:0003
>>
>> Isn't lsusb verbose supposed to print much more than that?
>
> Yes, if you are using the usbutils version of 'lsusb', odds are this is
> busybox, right?
Right. (You win a digital cookie.)
cd buildroot && make menuconfig
Drop BR2_PACKAGE_USBMOUNT (maybe it causes unexpected issues)
Add BR2_PACKAGE_USBUTILS (I want the real deal)
> And these are just the root hubs, that the USB controller driver creates
> as "virtual" USB devices, they are not "real" USB devices on your bus.
# lsusb --version
lsusb (usbutils) 007
I see there's a 008 version.
Am I missing out on important diagnostics?
# lsusb -v
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 3
bMaxPacketSize0 9
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
bcdDevice 4.07
iManufacturer 3 Linux 4.7.0-rc6 xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 30040000.usb3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 31
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
bMaxBurst 0
Hub Descriptor:
bLength 12
bDescriptorType 42
nNbrPorts 1
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
bHubDecLat 0.0 micro seconds
wHubDelay 0 nano seconds
DeviceRemovable 0x00
Hub Port Status:
Port 1: 0000.02a0 5Gbps power Rx.Detect
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 15
bNumDeviceCaps 1
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x0008
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 3
Lowest fully-functional device speed is SuperSpeed (5Gbps)
bU1DevExitLat 0 micro seconds
bU2DevExitLat 0 micro seconds
Device Status: 0x0001
Self Powered
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 4.07
iManufacturer 3 Linux 4.7.0-rc6 xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 30040000.usb3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Device Status: 0x0001
Self Powered
Does everything look normal?
Or are there any investigation-worthy nuggets?
Regards.
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Will Deacon @ 2016-12-02 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480666495-26536-1-git-send-email-sramana@codeaurora.org>
On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
> Extend the trace_clock to support the arch timer cycle
> counter so that we can get the monotonic cycle count
> in the traces. This will help in correlating the traces with the
> timestamps/events in other subsystems in the soc which share
> this common counter for driving their timers.
I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
particular, the "perf" trace_clock hangs off sched_clock, which should
be backed by the architected counter anyway. What does the cycle counter in
isolation tell you, given that the frequency isn't architected?
I think I'm missing something here.
Will
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Greg KH @ 2016-12-02 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58415625.3020703@free.fr>
On Fri, Dec 02, 2016 at 12:08:21PM +0100, Mason wrote:
> On 02/12/2016 11:42, Greg KH wrote:
>
> > On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote:
> >
> >> # lsusb -v
> >> Bus 001 Device 001: ID 1d6b:0002
> >> Bus 002 Device 001: ID 1d6b:0003
> >>
> >> Isn't lsusb verbose supposed to print much more than that?
> >
> > Yes, if you are using the usbutils version of 'lsusb', odds are this is
> > busybox, right?
>
> Right. (You win a digital cookie.)
Yeah!
{munch munch}
> cd buildroot && make menuconfig
> Drop BR2_PACKAGE_USBMOUNT (maybe it causes unexpected issues)
> Add BR2_PACKAGE_USBUTILS (I want the real deal)
>
> > And these are just the root hubs, that the USB controller driver creates
> > as "virtual" USB devices, they are not "real" USB devices on your bus.
>
> # lsusb --version
> lsusb (usbutils) 007
> I see there's a 008 version.
Wow, 008 was released in 2014, what type of old repo are you using that
has 007 as the "latest"?
And I really should go do a new update, lots of bug fixes have happened
since 2014...
> Am I missing out on important diagnostics?
Not really, if you are not doing a lot of USB 3-only device specific
work, which is where the majority of the changes have happened in the
past 2 years in the tool.
>
> # lsusb -v
>
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
<snip>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
<snip>
> Does everything look normal?
Yes, two internal "virtual" hubs.
> Or are there any investigation-worthy nuggets?
You need to figure out why the driver isn't getting interrupts, that's
the main problem for your hardware at the moment, lsusb isn't going to
help you out at all with that...
good luck!
greg k-h
^ permalink raw reply
* [PATCH 3/3] ARM: da850: fix da850_set_pll0rate()
From: Sekhar Nori @ 2016-12-02 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612516-18853-4-git-send-email-bgolaszewski@baylibre.com>
On Thursday 01 December 2016 10:45 PM, Bartosz Golaszewski wrote:
> This function is broken - its second argument is an index to the freq
> table, not the requested clock rate in Hz. It leads to an oops when
> called from clk_set_rate() since this argument isn't bounds checked
> either.
>
> Fix it by iterating over the array of supported frequencies and
> selecting a one that matches or returning -EINVAL for unsupported
> rates.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
When this function was written, it was written for speed. The only user
of setting pll0 rate is drivers/cpufreq/davinci-cpufreq.c (not sure how
you were trying to set pll0 rate). And that driver directly passes the
table index to the set_rate() function.
The idea was to optimize for speed in cpufreq driver and quickly index
into the pll data instead of searching through it.
But I agree, it is confusing and we are better off with maintainable
code. So, no problem with the patch, but this needs to be done along
with updates to cpufreq driver.
> ---
> arch/arm/mach-davinci/da850.c | 22 ++++++++++++++++++----
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 855b720..1c0f296 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1173,14 +1173,28 @@ static int da850_set_armrate(struct clk *clk, unsigned long index)
> return clk_set_rate(pllclk, index);
> }
>
> -static int da850_set_pll0rate(struct clk *clk, unsigned long index)
> +static int da850_set_pll0rate(struct clk *clk, unsigned long requested_rate)
Calling it just 'rate' is fine, IMO. The name of the function is enough
to suggest that its the rate to be set to.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/3] ARM: dts: at91: add dma1 definition to sama5d2
From: Alexandre Belloni @ 2016-12-02 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104949.23985-1-nicolas.ferre@atmel.com>
On 01/12/2016 at 11:49:47 +0100, Nicolas Ferre wrote :
> The sama5d2 SoC has a second DMA controller and can be used just like DMA0.
> By default both DMA controllers are configured as "Secure" in
> MATRIX_SPSELR so we can use whichever we want in a "single Secure World"
> configuration.
> Surprisingly the DMA1 has a lower address than DMA0. To avoid confusion
> place it after DMA0 node anyway.
>
sama5d2.dtsi is probably the only one that is properly ordered and I
feel like we should keep it this way.
If one of the nodes is not ordered properly, other ones will follow...
We don't care about the name, it is just an alias. We only care about
the address.
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/sama5d2.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index ceb9783ff7e1..c791ce9c750c 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -395,6 +395,16 @@
> clock-names = "dma_clk";
> };
>
> + /* Place dma1 here despite its address */
> + dma1: dma-controller at f0004000 {
> + compatible = "atmel,sama5d4-dma";
> + reg = <0xf0004000 0x1000>;
> + interrupts = <7 IRQ_TYPE_LEVEL_HIGH 0>;
> + #dma-cells = <1>;
> + clocks = <&dma1_clk>;
> + clock-names = "dma_clk";
> + };
> +
> pmc: pmc at f0014000 {
> compatible = "atmel,sama5d2-pmc", "syscon";
> reg = <0xf0014000 0x160>;
> --
> 2.9.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] Add crypto driver support for some MediaTek chips
From: mtk09577 @ 2016-12-02 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202081836.GA20128@Red>
Hello,
On Fri, 2016-12-02 at 09:18 +0100, Corentin Labbe wrote:
> Hello
>
> I have some minor comment inline
>
> On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote:
> > This adds support for the MediaTek hardware accelerator on
> > mt7623/mt2701/mt8521p SoC.
> >
> > This driver currently implement:
> > - SHA1 and SHA2 family(HMAC) hash alogrithms.
> > - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
>
> I see also a PRNG but is seems not really used.
Yes, PRNG is not implemented yet, i will remove it temporarily.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > drivers/crypto/Kconfig | 17 +
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/mediatek/Makefile | 2 +
> > drivers/crypto/mediatek/mtk-aes.c | 734 +++++++++++++++++
> > drivers/crypto/mediatek/mtk-platform.c | 575 +++++++++++++
> > drivers/crypto/mediatek/mtk-platform.h | 230 ++++++
> > drivers/crypto/mediatek/mtk-regs.h | 194 +++++
> > drivers/crypto/mediatek/mtk-sha.c | 1384 ++++++++++++++++++++++++++++++++
> > 8 files changed, 3137 insertions(+)
> > create mode 100644 drivers/crypto/mediatek/Makefile
> > create mode 100644 drivers/crypto/mediatek/mtk-aes.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.h
> > create mode 100644 drivers/crypto/mediatek/mtk-regs.h
> > create mode 100644 drivers/crypto/mediatek/mtk-sha.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index 4d2b81f..5d9c803 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
> > This driver interfaces with the hardware crypto accelerator.
> > Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
> >
> > +config CRYPTO_DEV_MEDIATEK
> > + tristate "MediaTek's Cryptographic Engine driver"
> > + depends on ARM && ARCH_MEDIATEK
> > + select NEON
> > + select KERNEL_MODE_NEON
> > + select ARM_CRYPTO
> > + select CRYPTO_AES
> > + select CRYPTO_BLKCIPHER
> > + select CRYPTO_SHA1_ARM_NEON
> > + select CRYPTO_SHA256_ARM
> > + select CRYPTO_SHA512_ARM
> > + select CRYPTO_HMAC
>
> Why do you select accelerated algos ?
> Adding COMPILE_TEST could be helpfull also.
Our Hardware has complex procedure on calculate HMAC, and it get a bad
performance.... So i decide to use ARM NEON instruction as fallback to
speedup it.
I will add COMPILE_TEST.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/aes.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > + mtk_aes_unregister_algs();
> > + mtk_aes_record_free(cryp);
> > +}
> > +EXPORT_SYMBOL(mtk_cipher_alg_release);
>
> Why not EXPORT_SYMBOL_GPL ?
> Furthermore do you really need it to be exported ?
My mistake. I will remove it.
> [...]
> > +
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/pm_runtime.h>
> > +#include <linux/clk.h>
> > +#include <linux/platform_device.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > +static void mtk_prng_reseed(struct mtk_cryp *cryp)
> > +{
> > + /* 8 words to seed the PRNG to provide IVs */
> > + void __iomem *base = cryp->base;
> > + const u32 prng_key[8] = {0x48c24cfd, 0x6c07f742,
> > + 0xaee75681, 0x0f27c239,
> > + 0x79947198, 0xe2991275,
> > + 0x21ac3c7c, 0xd008c4b4};
>
> Why do you seed with thoses constant ?
>
> [...]
> > +
> > +static int mtk_accelerator_init(struct mtk_cryp *cryp)
> > +{
> > + int i, err;
> > +
> > + /* Initialize advanced interrupt controller(AIC) */
> > + for (i = 0; i < 5; i++) {
>
> I see this 5 for interrupt away, so perhaps a define could be used
>
> [...]
>
> here
>
> > + for (i = 0; i < 5; i++) {
> > + cryp->irq[i] = platform_get_irq(pdev, i);
> > + if (cryp->irq[i] < 0) {
> > + dev_err(cryp->dev, "no IRQ:%d resource info\n", i);
> > + return -ENXIO;
> > + }
> > + }
> [...]
> > +#ifndef __MTK_PLATFORM_H_
> > +#define __MTK_PLATFORM_H_
> > +
> > +#include <linux/crypto.h>
> > +#include <crypto/internal/hash.h>
> > +#include <linux/interrupt.h>
>
> Sort headers in alphabetical order
>
> [...]
> > +#define MTK_DESC_FIRST BIT(23)
> > +#define MTK_DESC_BUF_LEN(x) ((x) & 0x1ffff)
> > +#define MTK_DESC_CT_LEN(x) (((x) & 0xff) << 24)
> > +
> > +#define WORD(x) ((x) >> 2)
>
> dangerous and ambigous define
I will define a IRQ_NUM and modify ambiguous definition.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <linux/crypto.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/sha.h>
> > +#include <crypto/internal/hash.h>
>
> Sort headers in alphabetical order
> [...]
> Generally more function comment could be helpfull.
I will sort all header and add more function comment.
Thanks for your review.
> Regards
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-12-02 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com>
On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote:
[...]
> We could add a system call to get the right stack size. But as it depends
> on VL, I'm not sure what it looks like. Particularly if you need determine
> the stack size before creating a thread that uses a specific VL setting.
I missed this point previously -- apologies for that.
What would you think of:
set_vl(vl_for_new_thread);
minsigstksz = get_minsigstksz();
set_vl(my_vl);
This avoids get_minsigstksz() requiring parameters -- which is mainly a
concern because the parameters tomorrow might be different from the
parameters today.
If it is possible to create the new thread without any SVE-dependent code,
then we could
set_vl(vl_for_new_thread);
new_thread_stack = malloc(get_minsigstksz());
new_thread = create_thread(..., new_thread_stack);
set_vl(my_vl);
which has the nice property that the new thread directly inherits the
configuration that was used for get_minsigstksz().
However, it would be necessary to prevent GCC from moving any code
across these statements -- in particular, SVE code that access VL-
dependent data spilled on the stack is liable to go wrong if reordered
with the above. So the sequence would need to go in an external
function (or a single asm...)
Failing that, we could maybe define some extensible struct to
get_minsigstksz().
Thoughts?
Cheers
---Dave
^ permalink raw reply
* [RFC PATCH] PCI: designware: add host_init() error handling
From: Srinivas Kandagatla @ 2016-12-02 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f2c8ebba-e51a-5f47-2d96-c75f7e086c0e@synopsys.com>
On 02/12/16 10:32, Joao Pinto wrote:
>
> Hi Srinivas,
>
> ?s 11:51 AM de 12/1/2016, Srinivas Kandagatla escreveu:
>> drivers/pci/host/pci-dra7xx.c | 4 +++-
>> drivers/pci/host/pci-exynos.c | 4 +++-
>> drivers/pci/host/pci-imx6.c | 4 +++-
>> drivers/pci/host/pci-keystone.c | 4 +++-
>> drivers/pci/host/pci-layerscape.c | 12 ++++++++----
>> drivers/pci/host/pcie-armada8k.c | 4 +++-
>> drivers/pci/host/pcie-designware-plat.c | 4 +++-
>> drivers/pci/host/pcie-designware.c | 4 +++-
>> drivers/pci/host/pcie-designware.h | 2 +-
>> drivers/pci/host/pcie-qcom.c | 6 ++++--
>> drivers/pci/host/pcie-spear13xx.c | 4 +++-
>> 11 files changed, 37 insertions(+), 15 deletions(-)
>>
>
> Thanks for the patch!
>
> In my opinion your idea is good but only qcom driver is able to detect failure
> in the specific host init routine, all others have a 'return 0' even if
> something not well init. I would recomend that we take this issue a bit further
> and add the error checking to all specific pci drivers in order to make them as
> robust as qcom'.
I totally agree with you, I can give this a go in next version.
Thanks,
srini
>
> Thanks,
> Joao
>
^ permalink raw reply
* [PATCH 1/2] Add crypto driver support for some MediaTek chips
From: Ryder Lee @ 2016-12-02 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202081836.GA20128@Red>
Hello,
On Fri, 2016-12-02 at 09:18 +0100, Corentin Labbe wrote:
> Hello
>
> I have some minor comment inline
>
> On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote:
> > This adds support for the MediaTek hardware accelerator on
> > mt7623/mt2701/mt8521p SoC.
> >
> > This driver currently implement:
> > - SHA1 and SHA2 family(HMAC) hash alogrithms.
> > - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
>
> I see also a PRNG but is seems not really used.
Yes, PRNG is not implemented yet, i will remove it temporarily.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > drivers/crypto/Kconfig | 17 +
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/mediatek/Makefile | 2 +
> > drivers/crypto/mediatek/mtk-aes.c | 734 +++++++++++++++++
> > drivers/crypto/mediatek/mtk-platform.c | 575 +++++++++++++
> > drivers/crypto/mediatek/mtk-platform.h | 230 ++++++
> > drivers/crypto/mediatek/mtk-regs.h | 194 +++++
> > drivers/crypto/mediatek/mtk-sha.c | 1384
++++++++++++++++++++++++++++++++
> > 8 files changed, 3137 insertions(+)
> > create mode 100644 drivers/crypto/mediatek/Makefile
> > create mode 100644 drivers/crypto/mediatek/mtk-aes.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.h
> > create mode 100644 drivers/crypto/mediatek/mtk-regs.h
> > create mode 100644 drivers/crypto/mediatek/mtk-sha.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index 4d2b81f..5d9c803 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
> > This driver interfaces with the hardware crypto accelerator.
> > Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher
mode.
> >
> > +config CRYPTO_DEV_MEDIATEK
> > + tristate "MediaTek's Cryptographic Engine driver"
> > + depends on ARM && ARCH_MEDIATEK
> > + select NEON
> > + select KERNEL_MODE_NEON
> > + select ARM_CRYPTO
> > + select CRYPTO_AES
> > + select CRYPTO_BLKCIPHER
> > + select CRYPTO_SHA1_ARM_NEON
> > + select CRYPTO_SHA256_ARM
> > + select CRYPTO_SHA512_ARM
> > + select CRYPTO_HMAC
>
> Why do you select accelerated algos ?
> Adding COMPILE_TEST could be helpfull also.
Our Hardware has complex procedure on calculate HMAC, and it get a bad
performance.... So i decide to use ARM NEON instruction as fallback to
speedup it.
I will add COMPILE_TEST.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/aes.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > + mtk_aes_unregister_algs();
> > + mtk_aes_record_free(cryp);
> > +}
> > +EXPORT_SYMBOL(mtk_cipher_alg_release);
>
> Why not EXPORT_SYMBOL_GPL ?
> Furthermore do you really need it to be exported ?
My mistake. I will remove it.
> [...]
> > +
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/pm_runtime.h>
> > +#include <linux/clk.h>
> > +#include <linux/platform_device.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > +static void mtk_prng_reseed(struct mtk_cryp *cryp)
> > +{
> > + /* 8 words to seed the PRNG to provide IVs */
> > + void __iomem *base = cryp->base;
> > + const u32 prng_key[8] = {0x48c24cfd, 0x6c07f742,
> > + 0xaee75681, 0x0f27c239,
> > + 0x79947198, 0xe2991275,
> > + 0x21ac3c7c, 0xd008c4b4};
>
> Why do you seed with thoses constant ?
>
> [...]
> > +
> > +static int mtk_accelerator_init(struct mtk_cryp *cryp)
> > +{
> > + int i, err;
> > +
> > + /* Initialize advanced interrupt controller(AIC) */
> > + for (i = 0; i < 5; i++) {
>
> I see this 5 for interrupt away, so perhaps a define could be used
>
> [...]
>
> here
>
> > + for (i = 0; i < 5; i++) {
> > + cryp->irq[i] = platform_get_irq(pdev, i);
> > + if (cryp->irq[i] < 0) {
> > + dev_err(cryp->dev, "no IRQ:%d resource info\n",
i);
> > + return -ENXIO;
> > + }
> > + }
> [...]
> > +#ifndef __MTK_PLATFORM_H_
> > +#define __MTK_PLATFORM_H_
> > +
> > +#include <linux/crypto.h>
> > +#include <crypto/internal/hash.h>
> > +#include <linux/interrupt.h>
>
> Sort headers in alphabetical order
>
> [...]
> > +#define MTK_DESC_FIRST BIT(23)
> > +#define MTK_DESC_BUF_LEN(x) ((x) & 0x1ffff)
> > +#define MTK_DESC_CT_LEN(x) (((x) & 0xff) << 24)
> > +
> > +#define WORD(x) ((x) >> 2)
>
> dangerous and ambigous define
I will define a IRQ_NUM and modify ambiguous definition.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <linux/crypto.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/sha.h>
> > +#include <crypto/internal/hash.h>
>
> Sort headers in alphabetical order
> [...]
> Generally more function comment could be helpfull.
I will sort all header and add more function comment.
Thanks for your review.
> Regards
^ permalink raw reply
* [PATCH RESEND 2/2] gpio: axp209: add pinctrl support
From: Linus Walleij @ 2016-12-02 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f46c89f2-478b-93b8-5a66-12d1307d4514@free-electrons.com>
On Tue, Nov 29, 2016 at 11:13 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> So basically:
>
> - first patch for adding pinctrl to the existing driver
> - second patch for moving the driver and binding from gpio to pinctrl
> subsystem
> - third patch for both removing Kconfig entry and Makefile rule from
> gpio subsystem, and adding a Kconfig entry and a Makefile rule in
> pinctrl subsystem
>
> Is that what you want?
No.
Make the patch moving it to pinctrl first. This will be the same as
the patch augmenting Kcongfig and Makefile or it will not compile.
Then a second patch to add the pinctrl features.
Yours,
Linus Walleij
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Arnd Bergmann @ 2016-12-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e15e76e2-b32d-a4d0-eb8b-850626a3946a@linaro.org>
On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> Hi, Arnd
>
> On 2016?12?01? 20:05, Arnd Bergmann wrote:
> > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> >> + 0x20 0x10 /* 1: i2c1 */
> >> + 0x20 0x20 /* 2: i2c2 */
> >> + 0x20 0x8000000>; /* 3: i2c6 */
> >> + };
> >> +
> >> +Specifying reset lines connected to IP modules
> >> +==============================================
> >> +example:
> >> +
> >> + i2c0: i2c at ..... {
> >> + ...
> >> + resets = <&iomcu_rst 0>;
> >> + ...
> >> + };
> > I don't really like this approach, since now the information is
> > in two places. Why not put the data into the reset specifier
> > directly when it is used?
> Any example, still not understand.
> They are consumer and provider.
I mean in the i2c node, have
i2c0: i2c at ..... {
...
resets = <&iomcu_rst 0x20 0x8>;
...
}
> > Also the format seems a little too close to the actual register
> > layout and could be a little more abstract, using bit numbers instead
> > of a bitmask and register numbers instead of offsets.
> We use bit numbers first.
> But in the developing process, we found several bits may be required for
> one driver.
> And they may not be continuous as the bits may already be occupied.
> Directly using offset, we can set several bits together for simple, to
> give more flexibility.
> So after discussion, we directly use offset.
Can you give an example for why this is needed? Is this different
from a device that has multiple reset lines?
Arnd
^ permalink raw reply
* [PATCH] ARM/ARM64: defconfig: drop GPIO_SYSFS on multiplatforms
From: Linus Walleij @ 2016-12-02 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5151997.6RlLpvHqsO@wuerfel>
On Wed, Nov 30, 2016 at 11:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 24, 2016 3:57:52 PM CET Linus Walleij wrote:
>> The sysfs ABI to GPIO is marked obsolete and should not be
>> encouraged. Users should be encouraged to switch to using the
>> character device.
(...)
>> arch/arm/configs/multi_v5_defconfig | 1 -
>> arch/arm/configs/multi_v7_defconfig | 1 -
>> arch/arm64/configs/defconfig | 1 -
>
> Hmm, while this is a trivial change, we normally put the defconfig
> changes for arm and arm64 into two separate next/* branches.
>
> I've split the patch up accordingly and slightly modified the
> changelog text to match.
OK thanks a lot Arnd, I was a bit uncertain about that.
Yours,
Linus Walleij
^ permalink raw reply
* [RESEND PATCH] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Linus Walleij @ 2016-12-02 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480472491-4644-1-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Nov 30, 2016 at 3:21 AM, Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
> the default mode of GPIO16 pin is gpio, when set EINT16 to
> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
> fixed when set its default mode as usb iddig.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Patch applied with Hongzhou's ACK!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] ARM: da850: fix da850_set_pll0rate()
From: Bartosz Golaszewski @ 2016-12-02 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b1d65f7-d9a6-6d4e-00f5-2835b728661c@ti.com>
2016-12-02 12:20 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Thursday 01 December 2016 10:45 PM, Bartosz Golaszewski wrote:
>> This function is broken - its second argument is an index to the freq
>> table, not the requested clock rate in Hz. It leads to an oops when
>> called from clk_set_rate() since this argument isn't bounds checked
>> either.
>>
>> Fix it by iterating over the array of supported frequencies and
>> selecting a one that matches or returning -EINVAL for unsupported
>> rates.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> When this function was written, it was written for speed. The only user
> of setting pll0 rate is drivers/cpufreq/davinci-cpufreq.c (not sure how
> you were trying to set pll0 rate). And that driver directly passes the
> table index to the set_rate() function.
>
Hi Sekhar, thanks for the hints.
The origin of this series is the default pll0 frequency set by
upstream u-boot which caused FIFO underflows in LCDC even with the
pixel clock well below 37.5 MHz. I had already sent a patch to the
u-boot mailing list, but thought I'd try setting the clock from within
tilcdc code. This is when I stumbled upon this issue.
I'll send a v2 of this series.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH 06/12] usb: dwc3: omap: Replace the extcon API
From: Chanwoo Choi @ 2016-12-02 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fum6vh1p.fsf@linux.intel.com>
Hi Felipe,
2016-12-02 18:03 GMT+09:00 Felipe Balbi <balbi@kernel.org>:
>
> Hi,
>
> Chanwoo Choi <cw00.choi@samsung.com> writes:
>> Hi Felipe,
>>
>> On 2016? 11? 30? 19:36, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Chanwoo Choi <cw00.choi@samsung.com> writes:
>>>> This patch uses the resource-managed extcon API for extcon_register_notifier()
>>>> and replaces the deprecated extcon API as following:
>>>> - extcon_get_cable_state_() -> extcon_get_state()
>>>>
>>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>
>>> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>>>
>>
>> Thanks for your review.
>>
>> Each patch has no any dependency among patches.
>> So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?
>
> my tree is closed for v4.10, I can pick it up for v4.11
Thanks for your pickup to 4.11.
--
Best Regards,
Chanwoo Choi
^ 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