* [PATCH 4/5] regulator: Add support for TI TWL6032
From: Rosia, Nicolae @ 2016-11-26 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611270236.UFgW5zDA%fengguang.wu@intel.com>
Hi,
On Sun, 2016-11-27 at 02:55 +0800, kbuild test robot wrote:
> Hi Nicolae,
>
> [auto build test ERROR on omap/for-next]
> [also build test ERROR on v4.9-rc6]
> [cannot apply to next-20161125]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
>
> url:????https://github.com/0day-ci/linux/commits/Nicolae-Rosia/mfd-tw
> l-improvements-and-new-regulator-driver/20161127-022201
> base:???https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-
> omap.git for-next
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> ????????# save the attached .config to linux build tree
> ????????make ARCH=i386?
>
> All error/warnings (new ones prefixed by >>):
>
> ???In file included from drivers/regulator/twl6032-regulator.c:11:0:
> > > drivers/regulator/twl6032-regulator.c:557:31: error:
> > > 'twl6032_regulator_driver_ids' undeclared here (not in a
> > > function)
>
> ????MODULE_DEVICE_TABLE(platform, twl6032_regulator_driver_ids);
> ??????????????????????????????????^
> ???include/linux/module.h:213:21: note: in definition of macro
> 'MODULE_DEVICE_TABLE'
> ????extern const typeof(name)
> __mod_##type##__##name##_device_table??\
> ????????????????????????^~~~
> > > include/linux/module.h:213:27: error:
> > > '__mod_platform__twl6032_regulator_driver_ids_device_table'
> > > aliased to undefined symbol 'twl6032_regulator_driver_ids'
>
> ????extern const typeof(name)
> __mod_##type##__##name##_device_table??\
> ??????????????????????????????^
> > > drivers/regulator/twl6032-regulator.c:557:1: note: in expansion
> > > of macro 'MODULE_DEVICE_TABLE'
>
> ????MODULE_DEVICE_TABLE(platform, twl6032_regulator_driver_ids);
> ????^~~~~~~~~~~~~~~~~~~
>
> vim +/twl6032_regulator_driver_ids +557 drivers/regulator/twl6032-
> regulator.c
>
> ???551
> ???552 static const struct of_device_id twl6032_dt_match[] = {
> ???553 { .compatible = "ti,twl6032-regulator" },
> ???554 { /* last entry */ }
> ???555 };
> ???556
> ?> 557 MODULE_DEVICE_TABLE(platform,
> twl6032_regulator_driver_ids);
> ???558
> ???559 static struct platform_driver twl6032_regulator_driver
> = {
> ???560 .driver = {
Thanks, I did not notice this since I was only testing using built-in
module.
I will wait for comments before sending V2, untill then here's an
inline patch with the fix.
Best regards,
Nicolae
^ permalink raw reply
* [PATCH 15/22] arm64/cpuinfo: Make hotplug notifier symmetric
From: Sebastian Andrzej Siewior @ 2016-11-26 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126231350.10321-1-bigeasy@linutronix.de>
From: Anna-Maria Gleixner <anna-maria@linutronix.de>
There is no requirement to keep the sysfs files around until the CPU is
completely dead. Remove them during the DOWN_PREPARE notification. This is
a preparatory patch for converting to the hotplug state machine.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/arm64/kernel/cpuinfo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index b3d5b3e8fbcb..19aad7041e14 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -272,9 +272,10 @@ static int cpuid_callback(struct notifier_block *nb,
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
+ case CPU_DOWN_FAILED:
rc = cpuid_add_regs(cpu);
break;
- case CPU_DEAD:
+ case CPU_DOWN_PREPARE:
rc = cpuid_remove_regs(cpu);
break;
}
--
2.10.2
^ permalink raw reply related
* [PATCH 16/22] arm64/cpuinfo: Convert to hotplug state machine
From: Sebastian Andrzej Siewior @ 2016-11-26 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126231350.10321-1-bigeasy@linutronix.de>
From: Anna-Maria Gleixner <anna-maria@linutronix.de>
Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/arm64/kernel/cpuinfo.c | 37 +++++++++----------------------------
1 file changed, 9 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 19aad7041e14..7b7be71e87bf 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -227,7 +227,7 @@ static struct attribute_group cpuregs_attr_group = {
.name = "identification"
};
-static int cpuid_add_regs(int cpu)
+static int cpuid_cpu_online(unsigned int cpu)
{
int rc;
struct device *dev;
@@ -248,7 +248,7 @@ static int cpuid_add_regs(int cpu)
return rc;
}
-static int cpuid_remove_regs(int cpu)
+static int cpuid_cpu_offline(unsigned int cpu)
{
struct device *dev;
struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu);
@@ -264,41 +264,22 @@ static int cpuid_remove_regs(int cpu)
return 0;
}
-static int cpuid_callback(struct notifier_block *nb,
- unsigned long action, void *hcpu)
-{
- int rc = 0;
- unsigned long cpu = (unsigned long)hcpu;
-
- switch (action & ~CPU_TASKS_FROZEN) {
- case CPU_ONLINE:
- case CPU_DOWN_FAILED:
- rc = cpuid_add_regs(cpu);
- break;
- case CPU_DOWN_PREPARE:
- rc = cpuid_remove_regs(cpu);
- break;
- }
-
- return notifier_from_errno(rc);
-}
-
static int __init cpuinfo_regs_init(void)
{
- int cpu;
-
- cpu_notifier_register_begin();
+ int cpu, ret;
for_each_possible_cpu(cpu) {
struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu);
kobject_init(&info->kobj, &cpuregs_kobj_type);
- if (cpu_online(cpu))
- cpuid_add_regs(cpu);
}
- __hotcpu_notifier(cpuid_callback, 0);
- cpu_notifier_register_done();
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm64/cpuinfo:online",
+ cpuid_cpu_online, cpuid_cpu_offline);
+ if (ret < 0) {
+ pr_err("cpuinfo: failed to register hotplug callbacks.\n");
+ return ret;
+ }
return 0;
}
static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Nicolas Pitre @ 2016-11-27 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123103640.GC14217@n2100.armlinux.org.uk>
On Wed, 23 Nov 2016, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 09:33:32AM +0000, Russell King - ARM Linux wrote:
> > So, I still think the whole approach is wrong - it's added extra
> > fragility that wasn't there with the armksyms.c approach.
>
> Here's what the diffstat and patch looks like when you combine the
> original commit and the three fixes. The LoC delta of 25 lines can
> be accounted for as deleted commentry. So, I think (as I've detailed
> above) that the _technical_ benefit of the approach is very low.
>
> If we want to move the exports into assembly files, I've no problem
> with that, provided we can do it better than this - and by better I
> mean not creating the fragile asm-prototypes.h which divorses the
> prototypes from everything else.
I think we agree on that.
I see that the revert made it to Linus' tree. That's probably the best
outcome for now.
I was working on that better solution I alluded to previously. And it
isn't really complicated either, with much fewer lines of code. But
this can wait for the next merge window.
Nicolas
^ permalink raw reply
* [PATCH 1/2] Documentation: sample averaging for imx6ul_tsc
From: Guy Shapiro @ 2016-11-27 7:44 UTC (permalink / raw)
To: linux-arm-kernel
The i.MX6UL internal touchscreen controller contains an option to
average upon samples. This feature reduces noise from the produced
touch locations.
This patch introduces a new device tree optional property for this
feature. It provides control over the amount of averaged samples per
touch event.
The property was inspired by a similar property on the
"brcm,iproc-touchscreen" binding.
Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
---
.../devicetree/bindings/input/touchscreen/imx6ul_tsc.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
index 853dff9..a66069f 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
@@ -17,6 +17,13 @@ Optional properties:
This value depends on the touch screen.
- pre-charge-time: the touch screen need some time to precharge.
This value depends on the touch screen.
+- average-samples: Number of data samples which are averaged for each read.
+ Valid values 0-4
+ 0 = 1 sample
+ 1 = 4 samples
+ 2 = 8 samples
+ 3 = 16 samples
+ 4 = 32 samples
Example:
tsc: tsc at 02040000 {
@@ -32,5 +39,6 @@ Example:
xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
measure-delay-time = <0xfff>;
pre-charge-time = <0xffff>;
+ average-samples = <4>;
status = "okay";
};
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] input: touchscreen: sample averaging for imx6ul_tsc
From: Guy Shapiro @ 2016-11-27 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480232698-23075-1-git-send-email-guy.shapiro@mobi-wize.com>
The i.MX6UL internal touchscreen controller contains an option to
average upon samples. This feature reduces noise from the produced
touch locations.
This patch adds sample averaging support to the imx6ul_tsc device
driver.
Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
---
drivers/input/touchscreen/imx6ul_tsc.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/input/touchscreen/imx6ul_tsc.c b/drivers/input/touchscreen/imx6ul_tsc.c
index 8275267..31724d9 100644
--- a/drivers/input/touchscreen/imx6ul_tsc.c
+++ b/drivers/input/touchscreen/imx6ul_tsc.c
@@ -25,6 +25,7 @@
/* ADC configuration registers field define */
#define ADC_AIEN (0x1 << 7)
#define ADC_CONV_DISABLE 0x1F
+#define ADC_AVGE (0x1 << 5)
#define ADC_CAL (0x1 << 7)
#define ADC_CALF 0x2
#define ADC_12BIT_MODE (0x2 << 2)
@@ -32,6 +33,7 @@
#define ADC_CLK_DIV_8 (0x03 << 5)
#define ADC_SHORT_SAMPLE_MODE (0x0 << 4)
#define ADC_HARDWARE_TRIGGER (0x1 << 13)
+#define ADC_AVGS_SHIFT 14
#define SELECT_CHANNEL_4 0x04
#define SELECT_CHANNEL_1 0x01
#define DISABLE_CONVERSION_INT (0x0 << 7)
@@ -86,6 +88,7 @@ struct imx6ul_tsc {
int measure_delay_time;
int pre_charge_time;
+ int average_samples;
struct completion completion;
};
@@ -107,6 +110,8 @@ static int imx6ul_adc_init(struct imx6ul_tsc *tsc)
adc_cfg = readl(tsc->adc_regs + REG_ADC_CFG);
adc_cfg |= ADC_12BIT_MODE | ADC_IPG_CLK;
adc_cfg |= ADC_CLK_DIV_8 | ADC_SHORT_SAMPLE_MODE;
+ if (tsc->average_samples)
+ adc_cfg |= (tsc->average_samples - 1) << ADC_AVGS_SHIFT;
adc_cfg &= ~ADC_HARDWARE_TRIGGER;
writel(adc_cfg, tsc->adc_regs + REG_ADC_CFG);
@@ -118,6 +123,8 @@ static int imx6ul_adc_init(struct imx6ul_tsc *tsc)
/* start ADC calibration */
adc_gc = readl(tsc->adc_regs + REG_ADC_GC);
adc_gc |= ADC_CAL;
+ if (tsc->average_samples)
+ adc_gc |= ADC_AVGE;
writel(adc_gc, tsc->adc_regs + REG_ADC_GC);
timeout = wait_for_completion_timeout
@@ -450,6 +457,16 @@ static int imx6ul_tsc_probe(struct platform_device *pdev)
if (err)
tsc->pre_charge_time = 0xfff;
+ err = of_property_read_u32(np, "average-samples",
+ &tsc->average_samples);
+ if (err)
+ tsc->average_samples = 0;
+ if (tsc->average_samples > 4) {
+ dev_err(&pdev->dev, "average-samples (%u) must be [0-4]\n",
+ tsc->average_samples);
+ return -EINVAL;
+ }
+
err = input_register_device(tsc->input);
if (err) {
dev_err(&pdev->dev,
--
2.1.4
^ permalink raw reply related
* [LINUX RFC v4 0/4] Add stripe support for ZynqMP SoC GQSPI controller
From: Naga Sureshkumar Relli @ 2016-11-27 8:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is continuation to previous patches mentioned in below link
http://marc.info/?l=linux-spi&m=145009963109143&w=2
i am re-initiating this series, Could you please help us to get this done?
what is dual parallel mode?
---------------------------
ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
2) Chip selects, data lines and clock are differ to both the flash devices
3) This mode is targeted for faster read/write speed and also doubles the size
4) Commands/data can be transmitted/received from both the devices(mirror),
or only upper or only lower flash memory devices.
5) Data arrangement:
With stripe enabled,
Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
i have tested this on top of latest git-hub master.
kindly suggest us the way, so that we can proceed further to add this support.
Naga Sureshkumar Relli (4):
spi: adding support for data stripe feature in core
mtd: add spi_device instance to spi_nor struct
mtd: spi-nor: add stripe support
spi: zynqmp: gqspi: add support for stripe feature
drivers/mtd/devices/m25p80.c | 1 +
drivers/mtd/spi-nor/spi-nor.c | 130 ++++++++++++++++++++++++++++++++---------
drivers/spi/spi-zynqmp-gqspi.c | 26 ++++++++-
drivers/spi/spi.c | 8 +++
include/linux/mtd/spi-nor.h | 3 +
include/linux/spi/spi.h | 11 ++++
6 files changed, 149 insertions(+), 30 deletions(-)
--
2.10.2
^ permalink raw reply
* [LINUX RFC v4 1/4] spi: adding support for data stripe feature in core
From: Naga Sureshkumar Relli @ 2016-11-27 8:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables data stripe feature in spi core. This feature is
required to support dual parallel mode of ZynqMP GQSPI controller.
To achieve the same an API SPI_MASTER_DATA_STRIPE is added.
With data stripe enabled,
- even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
- odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus.
To support data stripe; need to assert both chip selects once.
This is achieved through API SPI_MASTER_BOTH_CS.
Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
---
Changes for v4:
- No changes, sending the previous one as is
Change for v3:
- Updated comments for newly added APIs
- Changed patch description for ease of understanding
Changes for v2:
- Added error handling condition for newly added features
---
drivers/spi/spi.c | 8 ++++++++
include/linux/spi/spi.h | 11 +++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5787b72..01980af 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2538,6 +2538,14 @@ static int __spi_validate(struct spi_device *spi, struct spi_message *message)
if (list_empty(&message->transfers))
return -EINVAL;
+ /*
+ * Data stripe option is selected if and only if when
+ * two chips are enabled
+ */
+ if ((master->flags & SPI_MASTER_DATA_STRIPE)
+ && !(master->flags & SPI_MASTER_BOTH_CS))
+ return -EINVAL;
+
/* Half-duplex links include original MicroWire, and ones with
* only one data pin like SPI_3WIRE (switches direction) or where
* either MOSI or MISO is missing. They can also be caused by
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 4b743ac..94a5e6a 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -443,6 +443,17 @@ struct spi_master {
#define SPI_MASTER_MUST_RX BIT(3) /* requires rx */
#define SPI_MASTER_MUST_TX BIT(4) /* requires tx */
+ /* Controller may support data stripe feature when more than one
+ * chips are present.
+ * Setting data stripe will send data in following manner:
+ * -> even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
+ * -> odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus
+ */
+#define SPI_MASTER_DATA_STRIPE BIT(7) /* support data stripe */
+ /* Controller may support asserting more than one chip select at once.
+ * This flag will enable that feature.
+ */
+#define SPI_MASTER_BOTH_CS BIT(8) /* assert both chip selects */
/*
* on some hardware transfer / message size may be constrained
* the limit may depend on device transfer settings
--
2.10.2
^ permalink raw reply related
* [LINUX RFC v4 2/4] mtd: add spi_device instance to spi_nor struct
From: Naga Sureshkumar Relli @ 2016-11-27 8:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds struct spi_device instacne to the spi_nor structure.
Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
---
Changes for v4:
- No change
Changes for v3:
- No change
Changes for v2:
- This is new patch, basically splitted on request of Mark Brown
---
drivers/mtd/devices/m25p80.c | 1 +
include/linux/mtd/spi-nor.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 9cf7fcd..58cfb42 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -219,6 +219,7 @@ static int m25p_probe(struct spi_device *spi)
spi_set_drvdata(spi, flash);
flash->spi = spi;
+ nor->spi = spi;
if (spi->mode & SPI_RX_QUAD)
mode = SPI_NOR_QUAD;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index c425c7b..84f3ce5 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -157,6 +157,7 @@ struct spi_nor {
struct mtd_info mtd;
struct mutex lock;
struct device *dev;
+ struct spi_device *spi;
u32 page_size;
u8 addr_width;
u8 erase_opcode;
--
2.10.2
^ permalink raw reply related
* [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
From: Naga Sureshkumar Relli @ 2016-11-27 8:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds stripe support and it is needed for GQSPI parallel
configuration mode by:
- Adding required parameters like stripe and shift to spi_nor
structure.
- Initializing all added parameters in spi_nor_scan()
- Updating read_sr() and read_fsr() for getting status from both
flashes
- Increasing page_size, sector_size, erase_size and toatal flash
size as and when required.
- Dividing address by 2
- Updating spi->master->flags for qspi driver to change CS
Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
---
Changes for v4:
- rename isparallel to stripe
Changes for v3:
- No change
Changes for v2:
- Splitted to separate MTD layer changes from SPI core changes
---
drivers/mtd/spi-nor/spi-nor.c | 130 ++++++++++++++++++++++++++++++++----------
include/linux/mtd/spi-nor.h | 2 +
2 files changed, 103 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d0fc165..4252239 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -22,6 +22,7 @@
#include <linux/of_platform.h>
#include <linux/spi/flash.h>
#include <linux/mtd/spi-nor.h>
+#include <linux/spi/spi.h>
/* Define max times to check status register before we give up. */
@@ -89,15 +90,24 @@ static const struct flash_info *spi_nor_match_id(const char *name);
static int read_sr(struct spi_nor *nor)
{
int ret;
- u8 val;
+ u8 val[2];
- ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
- if (ret < 0) {
- pr_err("error %d reading SR\n", (int) ret);
- return ret;
+ if (nor->stripe) {
+ ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
+ if (ret < 0) {
+ pr_err("error %d reading SR\n", (int) ret);
+ return ret;
+ }
+ val[0] |= val[1];
+ } else {
+ ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
+ if (ret < 0) {
+ pr_err("error %d reading SR\n", (int) ret);
+ return ret;
+ }
}
- return val;
+ return val[0];
}
/*
@@ -108,15 +118,24 @@ static int read_sr(struct spi_nor *nor)
static int read_fsr(struct spi_nor *nor)
{
int ret;
- u8 val;
+ u8 val[2];
- ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
- if (ret < 0) {
- pr_err("error %d reading FSR\n", ret);
- return ret;
+ if (nor->stripe) {
+ ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 2);
+ if (ret < 0) {
+ pr_err("error %d reading FSR\n", ret);
+ return ret;
+ }
+ val[0] &= val[1];
+ } else {
+ ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 1);
+ if (ret < 0) {
+ pr_err("error %d reading FSR\n", ret);
+ return ret;
+ }
}
- return val;
+ return val[0];
}
/*
@@ -290,9 +309,16 @@ static int spi_nor_wait_till_ready(struct spi_nor *nor)
*/
static int erase_chip(struct spi_nor *nor)
{
+ u32 ret;
+
dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
- return nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
+ ret = nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
+ if (ret)
+ return ret;
+
+ return ret;
+
}
static int spi_nor_lock_and_prep(struct spi_nor *nor, enum spi_nor_ops ops)
@@ -349,7 +375,7 @@ static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
- u32 addr, len;
+ u32 addr, len, offset;
uint32_t rem;
int ret;
@@ -399,9 +425,13 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
/* "sector"-at-a-time erase */
} else {
while (len) {
+
write_enable(nor);
+ offset = addr;
+ if (nor->stripe)
+ offset /= 2;
- ret = spi_nor_erase_sector(nor, addr);
+ ret = spi_nor_erase_sector(nor, offset);
if (ret)
goto erase_err;
@@ -525,6 +555,8 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
bool use_top;
int ret;
+ ofs = ofs >> nor->shift;
+
status_old = read_sr(nor);
if (status_old < 0)
return status_old;
@@ -610,6 +642,8 @@ static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
bool use_top;
int ret;
+ ofs = ofs >> nor->shift;
+
status_old = read_sr(nor);
if (status_old < 0)
return status_old;
@@ -709,6 +743,8 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
if (ret)
return ret;
+ ofs = ofs >> nor->shift;
+
ret = nor->flash_lock(nor, ofs, len);
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_UNLOCK);
@@ -724,6 +760,8 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
if (ret)
return ret;
+ ofs = ofs >> nor->shift;
+
ret = nor->flash_unlock(nor, ofs, len);
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK);
@@ -1018,6 +1056,9 @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
u8 id[SPI_NOR_MAX_ID_LEN];
const struct flash_info *info;
+ nor->spi->master->flags &= ~(SPI_MASTER_BOTH_CS |
+ SPI_MASTER_DATA_STRIPE);
+
tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
if (tmp < 0) {
dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
@@ -1041,6 +1082,7 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
+ u32 offset = from;
dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
@@ -1049,7 +1091,13 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
return ret;
while (len) {
- ret = nor->read(nor, from, len, buf);
+
+ offset = from;
+
+ if (nor->stripe)
+ offset /= 2;
+
+ ret = nor->read(nor, offset, len, buf);
if (ret == 0) {
/* We shouldn't see 0-length reads */
ret = -EIO;
@@ -1161,6 +1209,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
struct spi_nor *nor = mtd_to_spi_nor(mtd);
size_t page_offset, page_remain, i;
ssize_t ret;
+ u32 offset;
dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
@@ -1178,9 +1227,13 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
/* the size of data remaining on the first page */
page_remain = min_t(size_t,
nor->page_size - page_offset, len - i);
+ offset = (to + i);
+
+ if (nor->stripe)
+ offset /= 2;
write_enable(nor);
- ret = nor->write(nor, to + i, page_remain, buf + i);
+ ret = nor->write(nor, (offset), page_remain, buf + i);
if (ret < 0)
goto write_err;
written = ret;
@@ -1302,22 +1355,22 @@ static int spi_nor_check(struct spi_nor *nor)
int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
{
- const struct flash_info *info = NULL;
+ struct flash_info *info = NULL;
struct device *dev = nor->dev;
struct mtd_info *mtd = &nor->mtd;
struct device_node *np = spi_nor_get_flash_node(nor);
- int ret;
- int i;
+ struct device_node *np_spi;
+ int ret, i, xlnx_qspi_mode;
ret = spi_nor_check(nor);
if (ret)
return ret;
if (name)
- info = spi_nor_match_id(name);
+ info = (struct flash_info *)spi_nor_match_id(name);
/* Try to auto-detect if chip name wasn't specified or not found */
if (!info)
- info = spi_nor_read_id(nor);
+ info = (struct flash_info *)spi_nor_read_id(nor);
if (IS_ERR_OR_NULL(info))
return -ENOENT;
@@ -1341,7 +1394,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
*/
dev_warn(dev, "found %s, expected %s\n",
jinfo->name, info->name);
- info = jinfo;
+ info = (struct flash_info *)jinfo;
}
}
@@ -1370,6 +1423,27 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
mtd->size = info->sector_size * info->n_sectors;
mtd->_erase = spi_nor_erase;
mtd->_read = spi_nor_read;
+#ifdef CONFIG_OF
+ np_spi = of_get_next_parent(np);
+
+ if (of_property_read_u32(np_spi, "xlnx,qspi-mode",
+ &xlnx_qspi_mode) < 0) {
+ nor->shift = 0;
+ nor->stripe = 0;
+ } else if (xlnx_qspi_mode == 2) {
+ nor->shift = 1;
+ info->sector_size <<= nor->shift;
+ info->page_size <<= nor->shift;
+ mtd->size <<= nor->shift;
+ nor->stripe = 1;
+ nor->spi->master->flags |= (SPI_MASTER_BOTH_CS |
+ SPI_MASTER_DATA_STRIPE);
+ }
+#else
+ /* Default to single */
+ nor->shift = 0;
+ nor->stripe = 0;
+#endif
/* NOR protection support for STmicro/Micron chips and similar */
if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
@@ -1400,10 +1474,10 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
/* prefer "small sector" erase if possible */
if (info->flags & SECT_4K) {
nor->erase_opcode = SPINOR_OP_BE_4K;
- mtd->erasesize = 4096;
+ mtd->erasesize = 4096 << nor->shift;
} else if (info->flags & SECT_4K_PMC) {
nor->erase_opcode = SPINOR_OP_BE_4K_PMC;
- mtd->erasesize = 4096;
+ mtd->erasesize = 4096 << nor->shift;
} else
#endif
{
@@ -1508,16 +1582,14 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
dev_info(dev, "%s (%lld Kbytes)\n", info->name,
(long long)mtd->size >> 10);
- dev_dbg(dev,
- "mtd .name = %s, .size = 0x%llx (%lldMiB), "
+ dev_dbg(dev, "mtd .name = %s, .size = 0x%llx (%lldMiB), "
".erasesize = 0x%.8x (%uKiB) .numeraseregions = %d\n",
mtd->name, (long long)mtd->size, (long long)(mtd->size >> 20),
mtd->erasesize, mtd->erasesize / 1024, mtd->numeraseregions);
if (mtd->numeraseregions)
for (i = 0; i < mtd->numeraseregions; i++)
- dev_dbg(dev,
- "mtd.eraseregions[%d] = { .offset = 0x%llx, "
+ dev_dbg(dev, "mtd.eraseregions[%d] = { .offset = 0x%llx, "
".erasesize = 0x%.8x (%uKiB), "
".numblocks = %d }\n",
i, (long long)mtd->eraseregions[i].offset,
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 84f3ce5..673ec68 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -165,6 +165,8 @@ struct spi_nor {
u8 read_dummy;
u8 program_opcode;
enum read_mode flash_read;
+ bool shift;
+ bool stripe;
bool sst_write_second;
u32 flags;
u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE];
--
2.10.2
^ permalink raw reply related
* [LINUX RFC v4 4/4] spi: zynqmp: gqspi: add support for stripe feature
From: Naga Sureshkumar Relli @ 2016-11-27 8:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support of dual parallel mode configuration
for Zynq Ultrascale+ MPSoC GQSPI controller driver.
Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
---
Changes for v4:
- No changes
Changes for v3:
- No change
Changes for v2:
- No change
---
drivers/spi/spi-zynqmp-gqspi.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 18aeace..dc7cf03 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -153,6 +153,7 @@ enum mode_type {GQSPI_MODE_IO, GQSPI_MODE_DMA};
* @dma_rx_bytes: Remaining bytes to receive by DMA mode
* @dma_addr: DMA address after mapping the kernel buffer
* @genfifoentry: Used for storing the genfifoentry instruction.
+ * @isinstr: To determine whether the transfer is instruction
* @mode: Defines the mode in which QSPI is operating
*/
struct zynqmp_qspi {
@@ -170,6 +171,7 @@ struct zynqmp_qspi {
u32 dma_rx_bytes;
dma_addr_t dma_addr;
u32 genfifoentry;
+ bool isinstr;
enum mode_type mode;
};
@@ -404,11 +406,24 @@ static void zynqmp_qspi_chipselect(struct spi_device *qspi, bool is_high)
u32 genfifoentry = 0x0, statusreg;
genfifoentry |= GQSPI_GENFIFO_MODE_SPI;
+
+
+ if (qspi->master->flags & SPI_MASTER_BOTH_CS) {
+ zynqmp_gqspi_selectslave(xqspi,
+ GQSPI_SELECT_FLASH_CS_BOTH,
+ GQSPI_SELECT_FLASH_BUS_BOTH);
+ } else {
+ zynqmp_gqspi_selectslave(xqspi,
+ GQSPI_SELECT_FLASH_CS_LOWER,
+ GQSPI_SELECT_FLASH_BUS_LOWER);
+ }
+
genfifoentry |= xqspi->genfifobus;
if (!is_high) {
genfifoentry |= xqspi->genfifocs;
genfifoentry |= GQSPI_GENFIFO_CS_SETUP;
+ xqspi->isinstr = true;
} else {
genfifoentry |= GQSPI_GENFIFO_CS_HOLD;
}
@@ -665,6 +680,7 @@ static irqreturn_t zynqmp_qspi_irq(int irq, void *dev_id)
if ((xqspi->bytes_to_receive == 0) && (xqspi->bytes_to_transfer == 0)
&& ((status & GQSPI_IRQ_MASK) == GQSPI_IRQ_MASK)) {
zynqmp_gqspi_write(xqspi, GQSPI_IDR_OFST, GQSPI_ISR_IDR_MASK);
+ xqspi->isinstr = false;
spi_finalize_current_transfer(master);
ret = IRQ_HANDLED;
}
@@ -828,6 +844,9 @@ static int zynqmp_qspi_start_transfer(struct spi_master *master,
genfifoentry |= xqspi->genfifocs;
genfifoentry |= xqspi->genfifobus;
+ if ((!xqspi->isinstr) && (master->flags & SPI_MASTER_DATA_STRIPE))
+ genfifoentry |= GQSPI_GENFIFO_STRIPE;
+
zynqmp_qspi_txrxsetup(xqspi, transfer, &genfifoentry);
if (xqspi->mode == GQSPI_MODE_DMA)
@@ -980,6 +999,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
struct zynqmp_qspi *xqspi;
struct resource *res;
struct device *dev = &pdev->dev;
+ u32 num_cs;
master = spi_alloc_master(&pdev->dev, sizeof(*xqspi));
if (!master)
@@ -1040,7 +1060,11 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
goto clk_dis_all;
}
- master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+ ret = of_property_read_u32(pdev->dev.of_node, "num-cs", &num_cs);
+ if (ret < 0)
+ master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+ else
+ master->num_chipselect = num_cs;
master->setup = zynqmp_qspi_setup;
master->set_cs = zynqmp_qspi_chipselect;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-11-27 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162421.800-2-icenowy@aosc.xyz>
22.11.2016, 00:26, "Icenowy Zheng" <icenowy@aosc.xyz>:
> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>
> Add a device tree file for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Changes since v2:
> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
> - removed uart3, which is not accessible on Orange Pi Zero.
> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
> ??sun8i-h3.dtsi.
> - Removed allwinner,sun8i-h3 compatible.
>
> ?arch/arm/boot/dts/Makefile | 1 +
> ?arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
> ?2 files changed, 138 insertions(+)
> ?create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 802a10d..51a1dd7 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> ?????????sun8i-a33-sinlinx-sina33.dtb \
> ?????????sun8i-a83t-allwinner-h8homlet-v2.dtb \
> ?????????sun8i-a83t-cubietruck-plus.dtb \
> + sun8i-h2plus-orangepi-zero.dtb \
> ?????????sun8i-h3-bananapi-m2-plus.dtb \
> ?????????sun8i-h3-nanopi-neo.dtb \
> ?????????sun8i-h3-orangepi-2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> new file mode 100644
> index 0000000..b428e47
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
> + *
> + * Based on sun8i-h3-orangepi-one.dts, which is:
> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-h3.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> + model = "Xunlong Orange Pi Zero";
> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
> +
> + pwr_led {
> + label = "orangepi:green:pwr";
> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + status_led {
> + label = "orangepi:red:status";
> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> + cd-inverted;
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&pio {
> + leds_opi0: led_pins at 0 {
> + pins = "PA17";
> + function = "gpio_out";
> + };
> +};
> +
> +&r_pio {
> + leds_r_opi0: led_pins at 0 {
> + pins = "PL10";
> + function = "gpio_out";
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins_a>;
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins>;
> + status = "disabled";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins>;
> + status = "disabled";
> +};
> +
> +&usbphy {
> + /* USB VBUS is always on */
> + status = "okay";
> +};
Something more interesting happened.
Xunlong made a add-on board for Orange Pi Zero, which exposes the two USB Controllers exported at expansion bus as USB Type-A connectors.
Also it exposes a analog A/V jack and a microphone.
Should I enable {e,o}hci{2.3} in the device tree?
> --
> 2.10.2
^ permalink raw reply
* [PATCH 1/2] Documentation: sample averaging for imx6ul_tsc
From: Fabio Estevam @ 2016-11-27 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480232698-23075-1-git-send-email-guy.shapiro@mobi-wize.com>
On Sun, Nov 27, 2016 at 5:44 AM, Guy Shapiro <guy.shapiro@mobi-wize.com> wrote:
> The i.MX6UL internal touchscreen controller contains an option to
> average upon samples. This feature reduces noise from the produced
> touch locations.
>
> This patch introduces a new device tree optional property for this
> feature. It provides control over the amount of averaged samples per
> touch event.
>
> The property was inspired by a similar property on the
> "brcm,iproc-touchscreen" binding.
>
> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/2] input: touchscreen: sample averaging for imx6ul_tsc
From: Fabio Estevam @ 2016-11-27 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480232698-23075-2-git-send-email-guy.shapiro@mobi-wize.com>
On Sun, Nov 27, 2016 at 5:44 AM, Guy Shapiro <guy.shapiro@mobi-wize.com> wrote:
> The i.MX6UL internal touchscreen controller contains an option to
> average upon samples. This feature reduces noise from the produced
> touch locations.
>
> This patch adds sample averaging support to the imx6ul_tsc device
> driver.
>
> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2 1/7] MFD: add bindings for stm32 general purpose timer driver
From: Jonathan Cameron @ 2016-11-27 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480000463-9625-2-git-send-email-benjamin.gaignard@st.com>
On 24/11/16 15:14, Benjamin Gaignard wrote:
> Add bindings information for stm32 general purpose timer
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../bindings/mfd/stm32-general-purpose-timer.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> new file mode 100644
> index 0000000..2f10e67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> @@ -0,0 +1,43 @@
> +STM32 general purpose timer driver
> +
> +Required parameters:
> +- compatible: must be "st,stm32-gptimer"
> +
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ..reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- iiotimer: See ../iio/timer/stm32-iio-timer.txt
Naming issue here. Can't mention IIO as that's a linux subsystem and all
bindings must be independent of OS.
Perhaps adc-trigger-timer?
> +
> +Example:
> + gptimer1: gptimer1 at 40010000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> +
> + iiotimer1 at 0 {
> + compatible = "st,stm32-iio-timer";
Again, avoid the use of iio in here (same issue you had with mfd in the previous
version).
> + interrupts = <27>;
> + st,input-triggers-names = TIM5_TRGO,
Docs for these should be introduced before they are used in an example.
Same for the PWM ones above. Expand the detail fo the example as you add
the other elements.
> + TIM2_TRGO,
> + TIM4_TRGO,
> + TIM3_TRGO;
> + st,output-triggers-names = TIM1_TRGO;
> + };
> + };
>
^ permalink raw reply
* [PATCH v2 3/7] PWM: add pwm-stm32 DT bindings
From: Jonathan Cameron @ 2016-11-27 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480000463-9625-4-git-send-email-benjamin.gaignard@st.com>
On 24/11/16 15:14, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..36263f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,37 @@
> +STMicroelectronics PWM driver bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm"
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes
> + for PWM module.
> + For Pinctrl properties, please refer to [1].
> +
> +Optional parameters:
> +- st,breakinput: Set if the hardware have break input capabilities
> +- st,breakinput-polarity: Set break input polarity. Default is 0
> + The value define the active polarity:
> + - 0 (active LOW)
> + - 1 (active HIGH)
> +- st,pwm-num-chan: Number of available PWM channels. Default is 0.
> +- st,32bits-counter: Set if the hardware have a 32 bits counter
> +- st,complementary: Set if the hardware have complementary output channels
> +
> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +Example:
> + gptimer1: gptimer1 at 40010000 {
Given the example includes chunks for the other binding, make sure to have
explicit cross references in the document.
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> + };
>
^ permalink raw reply
* [PATCH v2 5/7] IIO: add bindings for stm32 IIO timer driver
From: Jonathan Cameron @ 2016-11-27 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480000463-9625-6-git-send-email-benjamin.gaignard@st.com>
On 24/11/16 15:14, Benjamin Gaignard wrote:
> Define bindings for stm32 IIO timer
>
> version 2:
> - only keep one compatible
> - add DT parameters to set lists of the triggers:
> one list describe the triggers created by the device
> another one give the triggers accepted by the device
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../bindings/iio/timer/stm32-iio-timer.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
> new file mode 100644
> index 0000000..840b417
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
> @@ -0,0 +1,41 @@
> +timer IIO trigger bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
Add a cross reference...
> +
> +Required parameters:
> +- compatible: must be "st,stm32-iio-timer"
st,stm32-adc-timer or something like that.
> +- interrupts: Interrupt for this device
> + See ../interrupt-controller/st,stm32-exti.txt
> +
> +Optional parameters:
> +- st,input-triggers-names: List of the possible input triggers for
> + the device
> +- st,output-triggers-names: List of the possible output triggers for
> + the device
What are input / output triggers?
> +
> +Possible triggers are defined in include/dt-bindings/iio/timer/st,stm32-iio-timer.h
> +
> +Example:
> + gptimer1: gptimer1 at 40010000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> +
> + iiotimer1 at 0 {
> + compatible = "st,stm32-iio-timer";
> + interrupts = <27>;
> + st,input-triggers-names = TIM5_TRGO,
> + TIM2_TRGO,
> + TIM4_TRGO,
> + TIM3_TRGO;
> + st,output-triggers-names = TIM1_TRGO;
> + };
> + };
>
^ permalink raw reply
* [PATCH v2 1/7] MFD: add bindings for stm32 general purpose timer driver
From: Jonathan Cameron @ 2016-11-27 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b751c4a-3038-4220-05d8-d745c51a3691@kernel.org>
On 27/11/16 14:10, Jonathan Cameron wrote:
> On 24/11/16 15:14, Benjamin Gaignard wrote:
>> Add bindings information for stm32 general purpose timer
>>
>> version 2:
>> - rename stm32-mfd-timer to stm32-gptimer
>> - only keep one compatible string
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../bindings/mfd/stm32-general-purpose-timer.txt | 43 ++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>> new file mode 100644
>> index 0000000..2f10e67
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>> @@ -0,0 +1,43 @@
>> +STM32 general purpose timer driver
>> +
>> +Required parameters:
>> +- compatible: must be "st,stm32-gptimer"
>> +
>> +- reg: Physical base address and length of the controller's
>> + registers.
>> +- clock-names: Set to "clk_int".
>> +- clocks: Phandle to the clock used by the timer module.
>> + For Clk properties, please refer to ../clock/clock-bindings.txt
>> +
>> +Optional parameters:
>> +- resets: Phandle to the parent reset controller.
>> + See ..reset/st,stm32-rcc.txt
>> +
>> +Optional subnodes:
>> +- pwm: See ../pwm/pwm-stm32.txt
>> +- iiotimer: See ../iio/timer/stm32-iio-timer.txt
> Naming issue here. Can't mention IIO as that's a linux subsystem and all
> bindings must be independent of OS.
>
> Perhaps adc-trigger-timer?
>> +
>> +Example:
>> + gptimer1: gptimer1 at 40010000 {
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm1 at 0 {
>> + compatible = "st,stm32-pwm";
>> + st,pwm-num-chan = <4>;
>> + st,breakinput;
>> + st,complementary;
>> + };
>> +
>> + iiotimer1 at 0 {
>> + compatible = "st,stm32-iio-timer";
> Again, avoid the use of iio in here (same issue you had with mfd in the previous
> version).
>> + interrupts = <27>;
>> + st,input-triggers-names = TIM5_TRGO,
> Docs for these should be introduced before they are used in an example.
> Same for the PWM ones above. Expand the detail fo the example as you add
> the other elements.
I've just dived into the datasheet for these timers.
http://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf
I think you need a binding that describes the capabilities of each of the timers
explicitly. Down to the level of whether there is a repetition counter or not.
Each should exists as a separate entity in device tree.
They then have an existence as timers separate to the description of what they
are used for.
Here the only way we are saying they exist is by their use which doesn't feel
right to me.
So I think you need to move back to what you had in the first place. The key
thing is that ever timer needs describing fully. They are different enough
that for example the datasheet doesn't even try to describe them in one section.
(it has 4 separate chapters covering different sets of these hardware blocks).
The naming isn't really based on index, we are talking different hardware
that the datasheet authors have decided not to give different names to!
If they'd called them
advanced timers
generic timers
basic timers
really basic timers meant for driving the DAC (6 and 7)
We'd all have been quite happy with different compatible strings giving away
what they can do.
What you have here is far too specific to what you are trying to do with them
right now.
These things are separately capable of timing capture (which is I guess where
the IIO device later comes in).
So my expectation is that we end up potentially instantiating:
1) An MFD to handle the shared elements of the timers.
2) Up to 12ish timers each with separate existence as a device in the driver model
and in device tree.
(nasty corner cases here are using timers as perscalers for other timers - I'd be
tempted to leave that for now)
Note that each of these devices has a different register set I think? Any shared
bits are handled via the mfd above (if we even need that MFD which I'm starting
to doubt looking at the datasheet).
3) Up to N pwms again with there own existence in the device model. These don't
do much other than wrap the timer and stick it in output mode.
4) Up to N iio triggers - this is basically using the timer as a periodic interrupt
(though without the interrupt having visibility to the kernel) which fires off
sampling on associated ADCs.
5) Up to N iio capture devices for all channels that support timing capture.
Note there is also hardware encoder capture support in these which should be
correctly handled as well. This comes back to an ancient discussion on the
TI ecap units which have similar capabilities (driver never went anywhere but
I think that was because the author left TI).
Certainly for the IIO devices these should no be bound up into one instance
as you have done here.
Anyhow, I fear that right now this discussion is missing the key ingredient
that the hardware is horrendously variable in it's capabilities and really
is 4-5 different types of hardware that just happen to share a few bits of
their offsets in their register maps.
So after all that I'm almost more confused than I was at the start!
Jonathan
>> + TIM2_TRGO,
>> + TIM4_TRGO,
>> + TIM3_TRGO;
>> + st,output-triggers-names = TIM1_TRGO;
>> + };
>> + };
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2 6/7] IIO: add STM32 IIO timer driver
From: Jonathan Cameron @ 2016-11-27 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480000463-9625-7-git-send-email-benjamin.gaignard@st.com>
I delved into the datasheet after trying to figure this out, so I think
I now sort of understand your intent, but please do answer the questions
inline.
On 24/11/16 15:14, Benjamin Gaignard wrote:
> 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.
The presence of an IIO device in here was a suprise.. What is it actually for?
I think this needs some examples of usage to make it clear what the aim is.
I was basically expecting to see a driver instantiating one iio trigger
per timer that can act as a trigger. Those would each have sampling frequency
controls and basica enable / disable.
I'm seeing something much more complex here so additional explanation is
needed.
>
> 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.
Really? Sounds like magic numbers in sysfs which is never a good idea.
Please document those attributes / or break them up into elements that
don't require magic numbers.
>
> 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 2:
> - keep only one compatible
Hmm. I'm not sure I like this as such. We are actually dealing with lots
of instances of a hardware block with only a small amount of shared
infrastrcuture (which is classic mfd teritory). So to my mind we
should have a separate device for each.
> - use st,input-triggers-names and st,output-triggers-names
> to know which triggers are accepted and/or create by the device
I'm not following why we have this cascade setup?
These are triggers, not devices in the IIO context. We need some detailed
description of why you have it setup like this. This would include the
ABI with examples of how you are using it.
Basically I don't currently understand what you are doing :(
Thanks,
Jonathan
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/iio/Kconfig | 2 +-
> drivers/iio/Makefile | 1 +
> drivers/iio/timer/Kconfig | 15 +
> drivers/iio/timer/Makefile | 1 +
> drivers/iio/timer/stm32-iio-timer.c | 448 +++++++++++++++++++++
> drivers/iio/trigger/Kconfig | 1 -
> include/dt-bindings/iio/timer/st,stm32-iio-timer.h | 23 ++
> include/linux/iio/timer/stm32-iio-timers.h | 16 +
> 8 files changed, 505 insertions(+), 2 deletions(-)
> create mode 100644 drivers/iio/timer/Kconfig
> create mode 100644 drivers/iio/timer/Makefile
> create mode 100644 drivers/iio/timer/stm32-iio-timer.c
> create mode 100644 include/dt-bindings/iio/timer/st,stm32-iio-timer.h
> create mode 100644 include/linux/iio/timer/stm32-iio-timers.h
>
> 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..7a73bc6
> --- /dev/null
> +++ b/drivers/iio/timer/Kconfig
> @@ -0,0 +1,15 @@
> +#
> +# Timers drivers
> +
> +menu "Timers"
> +
> +config IIO_STM32_TIMER
> + tristate "stm32 iio timer"
> + depends on ARCH_STM32
> + depends on OF
> + select IIO_TRIGGERED_EVENT
> + select MFD_STM32_GP_TIMER
> + help
> + Select this option to enable stm32 timers hardware IPs
> +
> +endmenu
> diff --git a/drivers/iio/timer/Makefile b/drivers/iio/timer/Makefile
> new file mode 100644
> index 0000000..a360c9f
> --- /dev/null
> +++ b/drivers/iio/timer/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_IIO_STM32_TIMER) += stm32-iio-timer.o
> diff --git a/drivers/iio/timer/stm32-iio-timer.c b/drivers/iio/timer/stm32-iio-timer.c
> new file mode 100644
> index 0000000..35f2687
> --- /dev/null
> +++ b/drivers/iio/timer/stm32-iio-timer.c
> @@ -0,0 +1,448 @@
> +/*
> + * 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-iio-timers.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-iio-timer"
> +
> +struct stm32_iio_timer_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_iio_timer_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_iio_timer_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(S_IWUSR | S_IRUGO,
> + _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
> +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_iio_timer_dev *stm32 = iio_priv(indio_dev);
> + u32 cr2;
> +
> + regmap_read(stm32->regmap, TIM_CR2, &cr2);
> +
> + return snprintf(buf, PAGE_SIZE, "%d\n", (cr2 >> 4) & 0x7);
> +}
> +
> +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_iio_timer_dev *stm32 = iio_priv(indio_dev);
> + u8 mode;
> + int ret;
> +
> + ret = kstrtou8(buf, 10, &mode);
> + if (ret)
> + return ret;
> +
> + if (mode > 0x7)
> + return -EINVAL;
> +
> + regmap_update_bits(stm32->regmap, TIM_CR2, TIM_CR2_MMS, mode << 4);
> +
> + return len;
> +}
> +
> +static IIO_DEVICE_ATTR(master_mode, S_IRUGO | S_IWUSR,
> + _show_master_mode,
> + _store_master_mode,
> + 0);
> +
> +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_iio_timer_dev *stm32 = iio_priv(indio_dev);
> + u32 smcr;
> +
> + regmap_read(stm32->regmap, TIM_SMCR, &smcr);
> +
> + return snprintf(buf, PAGE_SIZE, "%d\n", smcr & 0x3);
> +}
> +
> +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_iio_timer_dev *stm32 = iio_priv(indio_dev);
> + u8 mode;
> + int ret;
> +
> + ret = kstrtou8(buf, 10, &mode);
> + if (ret)
> + return ret;
> +
> + if (mode > 0x7)
> + return -EINVAL;
How is something called slave mode going to be fed a number between 0 and 7?
Rule of thumb is no magic numbers in sysfs and right now this is looking
rather cryptic to say the least!
> +
> + regmap_update_bits(stm32->regmap, TIM_SMCR, TIM_SMCR_SMS, mode);
> +
> + return len;
> +}
> +
> +static IIO_DEVICE_ATTR(slave_mode, S_IRUGO | S_IWUSR,
There is an iritating move (in terms of noise it's generating) to use values
directly instead fo these defines. Still if you don't fix it here I'll only
get a patch 'fixing' it soon after...
> + _show_slave_mode,
> + _store_slave_mode,
> + 0);
> +
> +static struct attribute *stm32_timer_attrs[] = {
> + &iio_dev_attr_master_mode.dev_attr.attr,
> + &iio_dev_attr_slave_mode.dev_attr.attr,
New ABI so must be documented under Documentation/ABI/testing/sysfs-bus-iio-*
> + NULL,
> +};
> +
> +static const struct attribute_group stm32_timer_attr_group = {
> + .attrs = stm32_timer_attrs,
> +};
> +
> +static int stm32_timer_start(struct stm32_iio_timer_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_iio_timer_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_iio_timer_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_iio_timer_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);
This is acting like a trigger cascading off another trigger?
Normally this interrupt handler would be directly associated with the
trigger hardware - in this case the timer.
> +
> + 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_iio_timer_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_iio_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_iio_timer_trigger(struct iio_trigger *trig)
> +{
> + return (trig->ops == &timer_trigger_ops);
> +}
> +EXPORT_SYMBOL(is_stm32_iio_timer_trigger);
> +
> +static int stm32_validate_trigger(struct iio_dev *indio_dev,
> + struct iio_trigger *trig)
> +{
> + struct stm32_iio_timer_dev *dev = iio_priv(indio_dev);
> + int ret;
> +
> + if (!is_stm32_iio_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_iio_timer_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_iio_timer_dev));
> + if (!indio_dev)
> + return NULL;
This is 'unusual'. Why does a trigger driver need an iio_dev at all?
> +
> + 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);
So the iio_dev exists to provide the ability to fire this interrupt from
another trigger? Why do you want to do this?
> + 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_iio_timer_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct stm32_iio_timer_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,
> + "iiotimer_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_iio_timer_remove(struct platform_device *pdev)
> +{
> + struct stm32_iio_timer_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-iio-timer",
> + },
> +};
> +MODULE_DEVICE_TABLE(of, stm32_trig_of_match);
> +
> +static struct platform_driver stm32_iio_timer_driver = {
> + .probe = stm32_iio_timer_probe,
> + .remove = stm32_iio_timer_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = stm32_trig_of_match,
> + },
> +};
> +module_platform_driver(stm32_iio_timer_driver);
> +
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_DESCRIPTION("STMicroelectronics STM32 iio timer 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.
> -
Clear this out...
> endmenu
> diff --git a/include/dt-bindings/iio/timer/st,stm32-iio-timer.h b/include/dt-bindings/iio/timer/st,stm32-iio-timer.h
> new file mode 100644
> index 0000000..d39bf16
> --- /dev/null
> +++ b/include/dt-bindings/iio/timer/st,stm32-iio-timer.h
> @@ -0,0 +1,23 @@
> +/*
> + * st,stm32-iio-timer.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_IIO_TIMER_H_
> +#define _DT_BINDINGS_IIO_TIMER_H_
> +
> +#define TIM1_TRGO "tim1_trgo"
> +#define TIM2_TRGO "tim2_trgo"
> +#define TIM3_TRGO "tim3_trgo"
> +#define TIM4_TRGO "tim4_trgo"
> +#define TIM5_TRGO "tim5_trgo"
> +#define TIM6_TRGO "tim6_trgo"
> +#define TIM7_TRGO "tim7_trgo"
> +#define TIM8_TRGO "tim8_trgo"
> +#define TIM9_TRGO "tim9_trgo"
> +#define TIM12_TRGO "tim12_trgo"
> +
> +#endif
> diff --git a/include/linux/iio/timer/stm32-iio-timers.h b/include/linux/iio/timer/stm32-iio-timers.h
> new file mode 100644
> index 0000000..5d1b86c
> --- /dev/null
> +++ b/include/linux/iio/timer/stm32-iio-timers.h
> @@ -0,0 +1,16 @@
> +/*
> + * stm32-iio-timers.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_IIO_TIMERS_H_
> +#define _STM32_IIO_TIMERS_H_
> +
> +#include <dt-bindings/iio/timer/st,stm32-iio-timer.h>
> +
> +bool is_stm32_iio_timer_trigger(struct iio_trigger *trig);
> +
> +#endif
>
^ permalink raw reply
* [PATCH v2 5/7] IIO: add bindings for stm32 IIO timer driver
From: Benjamin Gaignard @ 2016-11-27 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b2002a81-49fe-af2a-f13a-9f09831aa530@kernel.org>
2016-11-27 15:25 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
> On 24/11/16 15:14, Benjamin Gaignard wrote:
>> Define bindings for stm32 IIO timer
>>
>> version 2:
>> - only keep one compatible
>> - add DT parameters to set lists of the triggers:
>> one list describe the triggers created by the device
>> another one give the triggers accepted by the device
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../bindings/iio/timer/stm32-iio-timer.txt | 41 ++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>> new file mode 100644
>> index 0000000..840b417
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>> @@ -0,0 +1,41 @@
>> +timer IIO trigger bindings for STM32
>> +
>> +Must be a sub-node of STM32 general purpose timer driver
> Add a cross reference...
I will add it in v3
>> +
>> +Required parameters:
>> +- compatible: must be "st,stm32-iio-timer"
> st,stm32-adc-timer or something like that.
I would prefer use st,stm32-timer-trigger because triggers can be used
for multiple other devices (dac, adc, timers)
>> +- interrupts: Interrupt for this device
>> + See ../interrupt-controller/st,stm32-exti.txt
>> +
>> +Optional parameters:
>> +- st,input-triggers-names: List of the possible input triggers for
>> + the device
>> +- st,output-triggers-names: List of the possible output triggers for
>> + the device
> What are input / output triggers?
each hardware block can be the source of triggers (output triggers) or customer
of some other trigger (input triggers).That what I have tried to
describe in those two
parameters
>> +
>> +Possible triggers are defined in include/dt-bindings/iio/timer/st,stm32-iio-timer.h
>> +
>> +Example:
>> + gptimer1: gptimer1 at 40010000 {
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm1 at 0 {
>> + compatible = "st,stm32-pwm";
>> + st,pwm-num-chan = <4>;
>> + st,breakinput;
>> + st,complementary;
>> + };
>> +
>> + iiotimer1 at 0 {
>> + compatible = "st,stm32-iio-timer";
>> + interrupts = <27>;
>> + st,input-triggers-names = TIM5_TRGO,
>> + TIM2_TRGO,
>> + TIM4_TRGO,
>> + TIM3_TRGO;
>> + st,output-triggers-names = TIM1_TRGO;
>> + };
>> + };
>>
>
^ permalink raw reply
* [PATCH v2 5/7] IIO: add bindings for stm32 IIO timer driver
From: Jonathan Cameron @ 2016-11-27 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6LC5M3B01nRWh-bO79OOE11QcsypDXGpFAPzZ7Goc=Fw@mail.gmail.com>
On 27/11/16 15:45, Benjamin Gaignard wrote:
> 2016-11-27 15:25 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>> On 24/11/16 15:14, Benjamin Gaignard wrote:
>>> Define bindings for stm32 IIO timer
>>>
>>> version 2:
>>> - only keep one compatible
>>> - add DT parameters to set lists of the triggers:
>>> one list describe the triggers created by the device
>>> another one give the triggers accepted by the device
>>>
>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>> ---
>>> .../bindings/iio/timer/stm32-iio-timer.txt | 41 ++++++++++++++++++++++
>>> 1 file changed, 41 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>> new file mode 100644
>>> index 0000000..840b417
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>> @@ -0,0 +1,41 @@
>>> +timer IIO trigger bindings for STM32
>>> +
>>> +Must be a sub-node of STM32 general purpose timer driver
>> Add a cross reference...
>
> I will add it in v3
>
>>> +
>>> +Required parameters:
>>> +- compatible: must be "st,stm32-iio-timer"
>> st,stm32-adc-timer or something like that.
>
> I would prefer use st,stm32-timer-trigger because triggers can be used
> for multiple other devices (dac, adc, timers)
>
>>> +- interrupts: Interrupt for this device
>>> + See ../interrupt-controller/st,stm32-exti.txt
>>> +
>>> +Optional parameters:
>>> +- st,input-triggers-names: List of the possible input triggers for
>>> + the device
>>> +- st,output-triggers-names: List of the possible output triggers for
>>> + the device
>> What are input / output triggers?
>
> each hardware block can be the source of triggers (output triggers) or customer
> of some other trigger (input triggers).That what I have tried to
> describe in those two
> parameters
So this is really about using one timer as a prescaler for another?
I'd be tempted in the first instance to drop that functionality and just
describe the ones that drive the device sampling.
It's complex to describe and there is enough complexity in here already
to keep things busy for a while!
>
>>> +
>>> +Possible triggers are defined in include/dt-bindings/iio/timer/st,stm32-iio-timer.h
>>> +
>>> +Example:
>>> + gptimer1: gptimer1 at 40010000 {
>>> + compatible = "st,stm32-gptimer";
>>> + reg = <0x40010000 0x400>;
>>> + clocks = <&rcc 0 160>;
>>> + clock-names = "clk_int";
>>> +
>>> + pwm1 at 0 {
>>> + compatible = "st,stm32-pwm";
>>> + st,pwm-num-chan = <4>;
>>> + st,breakinput;
>>> + st,complementary;
>>> + };
>>> +
>>> + iiotimer1 at 0 {
>>> + compatible = "st,stm32-iio-timer";
>>> + interrupts = <27>;
>>> + st,input-triggers-names = TIM5_TRGO,
>>> + TIM2_TRGO,
>>> + TIM4_TRGO,
>>> + TIM3_TRGO;
>>> + st,output-triggers-names = TIM1_TRGO;
>>> + };
>>> + };
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andreas Färber @ 2016-11-27 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgw7ilg9.fsf@free-electrons.com>
Am 25.11.2016 um 17:16 schrieb Gregory CLEMENT:
> On ven., nov. 25 2016, Uwe Kleine-K?nig <uwe@kleine-koenig.org> wrote:
>> This machine is an open hardware router by cz.nic driven by a
>> Marvell Armada 385.
>>
>> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
>
> Applied on mvebu/dt with few changes:
[...]
>> +&spi0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&spi0_pins &spi0cs0_pins>;
>> + status = "okay";
>> +
>> + spi-nor at 0 {
>> + compatible = "spansion,s25fl164k", "jedec,spi-nor";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0>;
>> + spi-max-frequency = <40000000>;
>> +
>
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> it is mandatory since v4.4 to use this pattern for partitions.
>
>
>> + partition at 0 {
>> + reg = <0x0 0x00100000>;
>> + label = "U-Boot";
>> + };
>> +
>> + partition at 1 {
> @0x100000
> We should use the reg value here ^
The unit name should be without 0x though. In your tree you seem to have
it correctly.
@Uwe: Note that I had already told CZ.NIC's Michal ~two weeks ago that I
have a WIP .dts for the Omnia - looks like no one knows what the other
is doing. :( My branch includes cleanups for 385 .dtsi and bug fixes for
the switch that I am not seeing in your series:
https://github.com/afaerber/linux/commits/omnia-next
I am still looking into phy backtraces when the network interfaces go down.
@Gregory: Can we please follow up with cleaning up these ugly
internal-regs and pcie-controller nodes for consistency?
Regards,
Andreas
>> + reg = <0x00100000 0x00700000>;
>> + label = "Rescue system";
>> + };
>
> + };
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-27 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7f47999-ec83-6cc8-8119-0087dee17bac@suse.de>
Hallo Andreas,
On 11/27/2016 05:00 PM, Andreas F?rber wrote:
> @Uwe: Note that I had already told CZ.NIC's Michal ~two weeks ago that I
> have a WIP .dts for the Omnia - looks like no one knows what the other
> is doing. :( My branch includes cleanups for 385 .dtsi and bug fixes for
> the switch that I am not seeing in your series:
I'm not in contact with a Michal at cz.nic.
Does the switch work in your setup with DSA?
> @Gregory: Can we please follow up with cleaning up these ugly
> internal-regs and pcie-controller nodes for consistency?
I bet the answer will be: Please send your patches to lakml for review.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161127/47a365dd/attachment.sig>
^ permalink raw reply
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-27 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7f47999-ec83-6cc8-8119-0087dee17bac@suse.de>
> @Uwe: Note that I had already told CZ.NIC's Michal ~two weeks ago that I
> have a WIP .dts for the Omnia - looks like no one knows what the other
> is doing.
Hi Andreas
Did you post to the list? Comment on the earlier versions of the
patches? The list is the please to coordinate these activities.
Andrew
^ permalink raw reply
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andreas Färber @ 2016-11-27 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1fc18002-0144-8300-1888-09f456860ef0@kleine-koenig.org>
Hi Uwe,
Am 27.11.2016 um 17:05 schrieb Uwe Kleine-K?nig:
> On 11/27/2016 05:00 PM, Andreas F?rber wrote:
>> @Uwe: Note that I had already told CZ.NIC's Michal ~two weeks ago that I
>> have a WIP .dts for the Omnia - looks like no one knows what the other
>> is doing. :( My branch includes cleanups for 385 .dtsi and bug fixes for
>> the switch that I am not seeing in your series:
>
> I'm not in contact with a Michal at cz.nic.
Right, but you have a Bedricha in CC from the same company!
> Does the switch work in your setup with DSA?
Not really:
omnia:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 532
link/ether d8:58:d7:00:61:70 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 532
link/ether d8:58:d7:00:61:6e brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 532
link/ether d8:58:d7:00:61:6f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 brd 192.168.1.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 2003:86:6702:9f00:da58:d7ff:fe00:616f/64 scope global
mngtmpaddr dynamic
valid_lft 7050sec preferred_lft 1650sec
inet6 fe80::da58:d7ff:fe00:616f/64 scope link
valid_lft forever preferred_lft forever
5: sit0 at NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
link/sit 0.0.0.0 brd 0.0.0.0
6: lan0 at eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state
DOWN group default qlen 1000
link/ether d8:58:d7:00:61:6e brd ff:ff:ff:ff:ff:ff
7: lan1 at eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state
DOWN group default qlen 1000
link/ether d8:58:d7:00:61:6e brd ff:ff:ff:ff:ff:ff
8: lan2 at eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state
DOWN group default qlen 1000
link/ether d8:58:d7:00:61:6e brd ff:ff:ff:ff:ff:ff
9: lan3 at eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state
DOWN group default qlen 1000
link/ether d8:58:d7:00:61:6e brd ff:ff:ff:ff:ff:ff
10: lan4 at eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state
DOWN group default qlen 1000
link/ether d8:58:d7:00:61:6e brd ff:ff:ff:ff:ff:ff
I get some interfaces for the switch, but I've not been able to get them
up/usable. Feel free to browse my commits, maybe I'm doing something
stupid - I already tried with and without fixed links, but the driver
seems to use only one of the two cpu links.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ 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