* [PATCHv3 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: tthayer @ 2016-11-02 14:32 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, dinguyen, linux, arnd, gregkh
Cc: davem, geert, devicetree, linux-kernel, linux-arm-kernel,
Thor Thayer
In-Reply-To: <1478097178-24341-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Altera Arria10 DevKit System Resource Monitor functionality
to the MFD device.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
v2 Change from -mon to -monitor for clarity
v3 Shorten driver name (remove altr_).
---
drivers/mfd/altera-a10sr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
index 06e1f7f..2ddf235 100644
--- a/drivers/mfd/altera-a10sr.c
+++ b/drivers/mfd/altera-a10sr.c
@@ -30,9 +30,13 @@
static const struct mfd_cell altr_a10sr_subdev_info[] = {
{
- .name = "altr_a10sr_gpio",
+ .name = "a10sr_gpio",
.of_compatible = "altr,a10sr-gpio",
},
+ {
+ .name = "a10sr_monitor",
+ .of_compatible = "altr,a10sr-monitor",
+ },
};
static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
--
1.9.1
^ permalink raw reply related
* [PATCHv3 2/4] misc: Add Altera Arria10 System Resource Control
From: tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx @ 2016-11-02 14:32 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thor Thayer
In-Reply-To: <1478097178-24341-1-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
This patch adds the Altera Arria10 control & monitoring
functions to the Arria10 System Resource chip.
Signed-off-by: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
---
v2 Change compatible string and filename from -mon to -monitor
Change CONFIG from module to builtin.
Make wm_rst register writeable.
v3 Remove unused ret variable.
Shorten driver name (remove altr_).
---
MAINTAINERS | 1 +
drivers/misc/Kconfig | 7 ++
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 175 ++++++++++++++++++++++++++++++++++++
4 files changed, 184 insertions(+)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b180821..baf2404 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -635,6 +635,7 @@ M: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
S: Maintained
F: drivers/gpio/gpio-altera-a10sr.c
F: drivers/mfd/altera-a10sr.c
+F: drivers/misc/altera-a10sr-monitor.c
F: include/linux/mfd/altera-a10sr.h
ALTERA TRIPLE SPEED ETHERNET DRIVER
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 64971ba..f42d459 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -766,6 +766,13 @@ config PANEL_BOOT_MESSAGE
An empty message will only clear the display at driver init time. Any other
printf()-formatted message is valid with newline and escape codes.
+config ALTERA_A10SR_MONITOR
+ bool "Altera Arria10 System Resource Monitor"
+ depends on MFD_ALTERA_A10SR
+ help
+ This enables the System Resource monitor driver for the Altera
+ Arria10 DevKit.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 3198336..9f6e77a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -43,6 +43,7 @@ obj-y += ti-st/
obj-y += lis3lv02d/
obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
+obj-$(CONFIG_ALTERA_A10SR_MONITOR) += altera-a10sr-monitor.o
obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
diff --git a/drivers/misc/altera-a10sr-monitor.c b/drivers/misc/altera-a10sr-monitor.c
new file mode 100644
index 0000000..66338e0
--- /dev/null
+++ b/drivers/misc/altera-a10sr-monitor.c
@@ -0,0 +1,175 @@
+/*
+ * Altera Arria10 DevKit System Resource Chip Monitor Driver
+ *
+ * Author: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
+ *
+ * Copyright Intel Corporation (C) 2014-2016. All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Monitor driver for the Altera Arria10 MAX5 System Resource Chip
+ * Adapted from ics932s401.c
+ */
+
+#include <linux/err.h>
+#include <linux/mfd/altera-a10sr.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+struct altr_a10sr_regs {
+ struct regmap *regmap;
+ struct attribute_group attr_grp;
+};
+
+static ssize_t a10sr_show(struct device *dev,
+ struct device_attribute *devattr, char *buf);
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count);
+
+/* Define FS entries */
+static DEVICE_ATTR(max5_version, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_led, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_button, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_button_irq, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pg1, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg2, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg3, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_fmcab, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_hps_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_per_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpa, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpb, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_i2c_master, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst_key, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pmbus, 0644, a10sr_show, a10sr_store);
+
+static struct attribute *altr_a10sr_attr[] = {
+ &dev_attr_max5_version.attr,
+ &dev_attr_max5_led.attr,
+ &dev_attr_max5_button.attr,
+ &dev_attr_max5_button_irq.attr,
+ &dev_attr_max5_pg1.attr,
+ &dev_attr_max5_pg2.attr,
+ &dev_attr_max5_pg3.attr,
+ &dev_attr_max5_fmcab.attr,
+ &dev_attr_max5_hps_resets.attr,
+ &dev_attr_max5_per_resets.attr,
+ &dev_attr_max5_sfpa.attr,
+ &dev_attr_max5_sfpb.attr,
+ &dev_attr_max5_i2c_master.attr,
+ &dev_attr_max5_wm_rst.attr,
+ &dev_attr_max5_wm_rst_key.attr,
+ &dev_attr_max5_pmbus.attr,
+ NULL
+};
+
+static const struct attribute_group a10sr_attr_group = {
+ .attrs = altr_a10sr_attr,
+};
+
+static ssize_t a10sr_show(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ int i, ret;
+ unsigned int val;
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit set by regmap for Read */
+ i <<= 1;
+ ret = regmap_read(a10sr_regs->regmap, i, &val);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%X\n", val);
+}
+
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count)
+{
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+ unsigned long val;
+ int i, ret;
+
+ ret = kstrtol(buf, 0, &val);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit cleared by regmap for Write */
+ i <<= 1;
+ ret = regmap_write(a10sr_regs->regmap, i, val);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static int altr_a10sr_regs_probe(struct platform_device *pdev)
+{
+ struct altr_a10sr_regs *a10regs;
+ struct altr_a10sr *a10sr = dev_get_drvdata(pdev->dev.parent);
+
+ a10regs = devm_kzalloc(&pdev->dev, sizeof(*a10regs), GFP_KERNEL);
+ if (!a10regs)
+ return -ENOMEM;
+
+ a10regs->regmap = a10sr->regmap;
+ a10regs->attr_grp = a10sr_attr_group;
+
+ platform_set_drvdata(pdev, a10regs);
+
+ return sysfs_create_group(&pdev->dev.kobj, &a10sr_attr_group);
+}
+
+static int altr_a10sr_regs_remove(struct platform_device *pdev)
+{
+ struct altr_a10sr_regs *a10regs = platform_get_drvdata(pdev);
+
+ sysfs_remove_group(&pdev->dev.kobj, &a10regs->attr_grp);
+
+ return 0;
+}
+
+static const struct of_device_id altr_a10sr_regs_of_match[] = {
+ { .compatible = "altr,a10sr-monitor" },
+ { },
+};
+
+static struct platform_driver altr_a10sr_regs_driver = {
+ .probe = altr_a10sr_regs_probe,
+ .remove = altr_a10sr_regs_remove,
+ .driver = {
+ .name = "a10sr_monitor",
+ .of_match_table = altr_a10sr_regs_of_match,
+ },
+};
+
+builtin_platform_driver(altr_a10sr_regs_driver);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv3 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx @ 2016-11-02 14:32 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thor Thayer
In-Reply-To: <1478097178-24341-1-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Add the Arria10 DevKit System Resource Chip register and state
monitoring module to the MFD.
Signed-off-by: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
---
Note: This needs to be applied to the bindings document that
was Acked & Applied but didn't reach the for-next branch.
See https://patchwork.ozlabs.org/patch/629397/
---
v2 Change compatible string -mon to -monitor for clarity
v3 Replace node name a10sr_monitor with just monitor.
Replace node name a10sr_gpio with just gpio.
---
Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
index ea151f2..69243d2 100644
--- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
+++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
@@ -17,7 +17,8 @@ The A10SR consists of these sub-devices:
Device Description
------ ----------
-a10sr_gpio GPIO Controller
+gpio GPIO Controller
+monitor Register and State Monitoring
Arria10 GPIO
Required Properties:
@@ -27,6 +28,10 @@ Required Properties:
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+Arria10 Register and State Monitor
+Required Properties:
+- compatible : Should be "altr,a10sr-monitor"
+
Example:
resource-manager@0 {
@@ -43,4 +48,8 @@ Example:
gpio-controller;
#gpio-cells = <2>;
};
+
+ monitor {
+ compatible = "altr,a10sr-monitor";
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv3 0/4] Add Altera A10SR Status & Control Monitor
From: tthayer @ 2016-11-02 14:32 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, dinguyen, linux, arnd, gregkh
Cc: davem, geert, devicetree, linux-kernel, linux-arm-kernel,
Thor Thayer
From: Thor Thayer <tthayer@opensource.altera.com>
his patch series adds the Altera Arria10 DevKit System Resource
chip's Status and Control Monitor to the A10SR Multi-Function
Device. An earlier patch added this to the hwmon class which
wasn't the proper place so this functionality is added to the
misc directory.
Version 2 changes the DT names from -mon to -monitor for better
readability and clarity and changed the previous version from
modular to built-in.
Version 3 improves the DT bindings naming and removes an unused
variable.
Thor Thayer (4):
dt-bindings: mfd: Add Altera Arria10 SR Monitor
misc: Add Altera Arria10 System Resource Control
mfd: altr-a10sr: Add Arria10 SR Monitor
ARM: socfpga: dts: Add Monitor to A10-SR MFD
.../devicetree/bindings/mfd/altera-a10sr.txt | 11 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 +
drivers/mfd/altera-a10sr.c | 6 +-
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 175 +++++++++++++++++++++
7 files changed, 203 insertions(+), 2 deletions(-)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
--
1.9.1
^ permalink raw reply
* Re: [PATCH] ARM: DT: stm32: move dma translation to board files
From: Alexandre Torgue @ 2016-11-02 14:32 UTC (permalink / raw)
To: Radosław Pietrzyk, Bruno Herrera
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
Arnd Bergmann, linux-I+IVW8TIWO2tmTQ+vhA3Yw, >, >,
Maxime Coquelin, Lee Jones,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAFvLkMTCkRcwbRc8GVNBoJFAvKWHYDjOPabueQPjTseZrucadA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi
On 10/31/2016 07:58 PM, Radosław Pietrzyk wrote:
> I think wlcore driver searches dma-ranges in its parent that's why sdio
> node needs it.
Yes I agree. In this case it is needed as you have subnode in sdio node.
So IMO empty dma-ranges could be removed from ethernet and usb node, but
kept in future sdio subnode.
Bruno,
Do you plan to push sdio support ?
>
> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
>
> On Mon, Oct 31, 2016 at 12:14 PM, Radosław Pietrzyk
> <radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
> wrote:
> > This is weird because dma ddresses are recalculated using parent's
> > dma-ranges property and soc already has it so there should be absolutely no
> > problem.
>
> These are my DTS and DTSI file.
> >
> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
> >>
> >> On Fri, Oct 28, 2016 at 5:09 AM, Radosław Pietrzyk
> >> <radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
> >> > Have you defined your sdio node within soc node ?
> >>
> >> It is in the SOC node of the DSTI file.
> >>
> >> >
> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
> >> >>
> >> >> Hi Alex,
> >> >>
> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
> >> >> <alexandre.torgue-qxv4g6HH51o@public.gmane.org <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>> wrote:
> >> >> > Hi Bruno,
> >> >> >
> >> >> >
> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
> >> >> >>
> >> >> >> Hi Alex,
> >> >> >>
> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
> >> >> >> <alexandre.torgue-qxv4g6HH51o@public.gmane.org <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
> wrote:
> >> >> >>>
> >> >> >>> Hi Bruno,
> >> >> >>>
> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Hi Alexandre,
> >> >> >>>>
> >> >> >>>>>
> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
> start address
> >> >> >>>>> remapping
> >> >> >>>>> (to @0) to boost performances. A DMA translation through
> >> >> >>>>> "dma-ranges"
> >> >> >>>>> property was needed for other masters than the M4 CPU.
> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
> this DMA
> >> >> >>>>> translation.
> >> >> >>>>> This patches moves this DMA translation definition from
> stm32f429
> >> >> >>>>> soc
> >> >> >>>>> file
> >> >> >>>>> to board files.
> >> >> >>>>>
> >> >> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org
> <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
> >> >> >>>>>
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> index 13c7cd2..a763c15 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> @@ -82,6 +82,10 @@
> >> >> >>>>> };
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> + soc {
> >> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> + };
> >> >> >>>>> +
> >> >> >>>>> usbotg_hs_phy: usbphy {
> >> >> >>>>> #phy-cells = <0>;
> >> >> >>>>> compatible = "usb-nop-xceiv";
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Shouldn't also the peripheral dma-ranges property move to
> board
> >> >> >>>> specific
> >> >> >>>> too?
> >> >> >>>> I had this patch for while but I didn't had the time to
> submit:
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
> ysterday on
> >> >> >>> IIRC,
> >> >> >>> empty dma-ranges is not needed. Can you test on your side by
> >> >> >>> removing
> >> >> >>> dma-ranges in usb node please ?
> >> >> >>
> >> >> >> Unfortunately will take a time for me to set up this
> environment on
> >> >> >> the STM32F4-EVAL board.
> >> >> >> And on the discovery boards we dont have this scenario.
> That was the
> >> >> >> main reason I did not submit the patch right away.
> >> >> >> My conclusion and I might be wrong but is based on the my
> tests with
> >> >> >> SDIO device at STM32F469I-DISCO board.
> >> >> >>
> >> >> >> I started this issue as discussion at ST Forum but Maxime
> gave me
> >> >> >> the
> >> >> >> hint.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44>
> >> >> >>
> >> >> >>> I will push a v2 by removing empty dma-ranges if tests are
> ok in
> >> >> >>> your
> >> >> >>> side.
> >> >> >>
> >> >> >>
> >> >> >> From my understating/conclusion is: when empty
> property(dma-ranges)
> >> >> >> is
> >> >> >> the device node, the mapping will be taken in consideration
> when
> >> >> >> using
> >> >> >> DMA otherwise the mapping is ignored.
> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
> question
> >> >> >> so
> >> >> >> I suppose it can work without the property.
> >> >> >
> >> >> >
> >> >> > For sure translation has to be done but I'm not sure that an
> empty
> >> >> > "dma-ranges" is needed in device node to activate it. For
> Ethernet
> >> >> > empty
> >> >> > "dma-ranges" is not needed. I will try with usb.
> >> >>
> >> >> In the case of SDIO it is needed. As example this is my
> working SDIO
> >> >> node:
> >> >>
> >> >> sdio: sdio@40012c00 {
> >> >> compatible = "arm,pl18x", "arm,primecell";
> >> >> arm,primecell-periphid = <0x00480181>;
> >> >> reg = <0x40012c00 0x400>;
> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
> >> >> dma-names = "rx", "tx";
> >> >> clocks = <&rcc 0 171>;
> >> >> clock-names = "apb_pclk";
> >> >> interrupts = <49>;
> >> >> status = "disabled";
> >> >> };
> >> >>
> >> >> &sdio {
> >> >> status = "okay";
> >> >> vmmc-supply = <&wlan_en>;
> >> >> bus-width = <4>;
> >> >> max-frequency = <24000000>;
> >> >> pinctrl-names = "default";
> >> >> pinctrl-0 = <&sdio_pins>;
> >> >> ti,non-removable;
> >> >> ti,needs-special-hs-handling;
> >> >> dma-ranges;
> >> >> cap-power-off-card;
> >> >> keep-power-in-suspend;
> >> >>
> >> >> #address-cells = <1>;
> >> >> #size-cells = <0>;
> >> >> wlcore: wlcore@0 {
> >> >> compatible = "ti,wl1835";
> >> >> reg = <2>;
> >> >> interrupt-parent = <&gpioa>;
> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
> >> >> };
> >> >> };
> >> >>
> >> >> >
> >> >> > alex
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>>
> >> >> >>> Thanks in advance
> >> >> >>> Alex
> >> >> >>>
> >> >> >>>
> >> >> >>>>
> >> >> >>>> Author: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
> >> >> >>>>
> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board not
> at dtsi
> >> >> >>>> file
> >> >> >>>>
> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> index 6bfc595..2a22a82 100644
> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> @@ -52,6 +52,10 @@
> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL board";
> >> >> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
> >> >> >>>>
> >> >> >>>> + soc {
> >> >> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
> >> >> >>>> + };
> >> >> >>>> +
> >> >> >>>> chosen {
> >> >> >>>> bootargs = "root=/dev/ram rdinit=/linuxrc";
> >> >> >>>> stdout-path = "serial0:115200n8";
> >> >> >>>> @@ -96,6 +100,7 @@
> >> >> >>>>
> >> >> >>>> ðernet0 {
> >> >> >>>> status = "okay";
> >> >> >>>> + dma-ranges;
> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
> >> >> >>>> pinctrl-names = "default";
> >> >> >>>> phy-mode = "mii-id";
> >> >> >>>> @@ -116,6 +121,7 @@
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> &usbotg_hs {
> >> >> >>>> + dma-ranges;
> >> >> >>>> dr_mode = "host";
> >> >> >>>> phys = <&usbotg_hs_phy>;
> >> >> >>>> phy-names = "usb2-phy";
> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> index 7d624a2..697a133 100644
> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> @@ -59,7 +59,6 @@
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> soc {
> >> >> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>
> >> >> >>>> timer2: timer@40000000 {
> >> >> >>>> compatible = "st,stm32-timer";
> >> >> >>>> @@ -472,13 +471,11 @@
> >> >> >>>> st,syscon = <&syscfg 0x4>;
> >> >> >>>> snps,pbl = <8>;
> >> >> >>>> snps,mixed-burst;
> >> >> >>>> - dma-ranges;
> >> >> >>>> status = "disabled";
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> usbotg_hs: usb@40040000 {
> >> >> >>>> compatible = "snps,dwc2";
> >> >> >>>> - dma-ranges;
> >> >> >>>> reg = <0x40040000 0x40000>;
> >> >> >>>> interrupts = <77>;
> >> >> >>>> clocks = <&rcc 0 29>;
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> index 0596d60..3a1cfdd 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> @@ -59,8 +59,6 @@
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> soc {
> >> >> >>>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> -
> >> >> >>>>> timer2: timer@40000000 {
> >> >> >>>>> compatible = "st,stm32-timer";
> >> >> >>>>> reg = <0x40000000 0x400>;
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> index 9e73656..c2213c0 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> @@ -64,6 +64,10 @@
> >> >> >>>>> aliases {
> >> >> >>>>> serial0 = &usart3;
> >> >> >>>>> };
> >> >> >>>>> +
> >> >> >>>>> + soc {
> >> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> + };
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> &clk_hse {
> >> >> >>>>> --
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Br.,
> >> >> >>>> Bruno
> >> >> >>>>
> >> >> >>>
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> linux-arm-kernel mailing list
> >> >> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> <mailto:linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
> >> >
> >> >
> >
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 4/9] Documentation: devicetree: mfd: da9062/61 MFD binding
From: Lee Jones @ 2016-11-02 14:32 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, Mark Rutland, Rob Herring,
Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-PM,
LINUX-WATCHDOG, Liam Girdwood, Mark Brown, Support Opensource,
Wim Van Sebroeck, Zhang Rui
In-Reply-To: <502d13b97c67023f2193abfa235e8884eb0ea02f.1477929725.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Mon, 31 Oct 2016, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> Extend existing DA9062 binding information to include the DA9061 PMIC for
> MFD core and regulators.
>
> Add a da9062-onkey link to the existing onkey binding file.
>
> Add a da9062-thermal link to the new temperature monitoring binding file.
>
> Delete the da9062-watchdog section and replace it with a link to the new
> DA9061/62 binding information file.
>
> Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> ---
> This patch applies against linux-next and v4.8
>
> v2 -> v3
> - Patch renamed from [PATCH V2 04/10] to [PATCH V3 4/9]
> - Ensure binding description concentrates on the device not the
> device driver
> - Separate the DA9061 and DA9062 sub-device tables to distinguish
> the difference between the two devices
> - Update the commit message to describe this change
> - Add e-mail information about associated patches from this set
> without describing them as being explicitly dependent on this
> binding
>
> v1 -> v2
> - Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
>
> Hi,
>
> Other information:
> The device driver from this patch set (associated with this binding) is
>
> - [PATCH V3 1/9] mfd: da9061: MFD core support
>
> and also the following binding file changes:
>
> - [PATCH V3 1/9] Binding for onkey
> - [PATCH V3 2/9] Binding for watchdog
> - [PATCH V3 3/9] Binding for thermal
>
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
>
>
> Documentation/devicetree/bindings/mfd/da9062.txt | 52 ++++++++++++++++++------
> 1 file changed, 40 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 38802b5..56491c3 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -1,22 +1,39 @@
> * Dialog DA9062 Power Management Integrated Circuit (PMIC)
>
> -DA9062 consists of a large and varied group of sub-devices:
> +Product information for the DA9062 and DA9061 devices can be found here:
> +- http://www.dialog-semiconductor.com/products/da9062
> +- http://www.dialog-semiconductor.com/products/da9061
> +
> +The DA9062 PMIC consists of:
>
> Device Supply Names Description
> ------ ------------ -----------
> da9062-regulator : : LDOs & BUCKs
> da9062-rtc : : Real-Time Clock
> +da9062-onkey : : On Key
> +da9062-watchdog : : Watchdog Timer
> +da9062-thermal : : Thermal
> +
> +The DA9061 PMIC consists of:
> +
> +Device Supply Names Description
> +------ ------------ -----------
> +da9062-regulator : : LDOs & BUCKs
> +da9062-onkey : : On Key
> da9062-watchdog : : Watchdog Timer
> +da9062-thermal : : Thermal
>
> ======
>
> Required properties:
>
> -- compatible : Should be "dlg,da9062".
> +- compatible : Should be
> + "dlg,da9062" for DA9062
> + "dlg,da9061" for DA9061
> - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
> modified to match the chip's OTP settings).
> - interrupt-parent : Specifies the reference to the interrupt controller for
> - the DA9062.
> + the DA9062 or DA9061.
> - interrupts : IRQ line information.
> - interrupt-controller
>
> @@ -25,8 +42,8 @@ further information on IRQ bindings.
>
> Sub-nodes:
>
> -- regulators : This node defines the settings for the LDOs and BUCKs. The
> - DA9062 regulators are bound using their names listed below:
> +- regulators : This node defines the settings for the LDOs and BUCKs.
> + The DA9062 regulators are bound using their names listed below:
>
> buck1 : BUCK_1
> buck2 : BUCK_2
> @@ -37,6 +54,16 @@ Sub-nodes:
> ldo3 : LDO_3
> ldo4 : LDO_4
>
> + The DA9061 regulators are bound using their names listed below:
> +
> + buck1 : BUCK_1
> + buck2 : BUCK_2
> + buck3 : BUCK_3
> + ldo1 : LDO_1
> + ldo2 : LDO_2
> + ldo3 : LDO_3
> + ldo4 : LDO_4
> +
> The component follows the standard regulator framework and the bindings
> details of individual regulator device can be found in:
> Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -46,9 +73,14 @@ Sub-nodes:
> with the DA9062. There are currently no entries in this binding, however
> compatible = "dlg,da9062-rtc" should be added if a node is created.
>
> -- watchdog: This node defines the settings for the watchdog driver associated
> - with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
> - if a node is created.
> +
> +- onkey : See ../input/da9062-onkey.txt
> +
> +
> +- watchdog: See ../watchdog/da9062-watchdog.txt
> +
> +
> +- thermal : See ../thermal/da9062-thermal.txt
Remove all those extra lines in between.
> Example:
> @@ -64,10 +96,6 @@ Example:
> compatible = "dlg,da9062-rtc";
> };
>
> - watchdog {
> - compatible = "dlg,da9062-watchdog";
> - };
> -
Why don't you include a sub-node per child device and use
of_platform_populate() to register the devices?
> regulators {
> DA9062_BUCK1: buck1 {
> regulator-name = "BUCK1";
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 5/9] mfd: da9061: MFD core support
From: Lee Jones @ 2016-11-02 14:28 UTC (permalink / raw)
To: Steve Twiss
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <72145ea5055e95d7b6f05168c641927e4f3830d9.1477929725.git.stwiss.opensource@diasemi.com>
On Mon, 31 Oct 2016, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> MFD support for DA9061 is provided as part of the DA9062 device driver.
>
> The registers header file adds two new chip variant IDs defined in DA9061
> and DA9062 hardware. The core header file adds new software enumerations
> for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
> for distinguishing between DA9061/62 devices in software.
>
> The core source code adds a new .compatible of_device_id entry. This is
> extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
> .data entry now holds a reference to the enumerated device type.
>
> A new regmap_irq_chip model is added for DA9061 and this supports the new
> list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
> new sub system components for DA9061. Support is added for a new DA9061
> regmap_config which lists the correct readable, writable and volatile
> ranges for this chip.
>
> The probe function uses the device tree compatible string to switch on the
> da9062_compatible_types and configure the correct mfd cells, irq chip and
> regmap config.
>
> Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and v4.8
>
> v2 -> v3
> - NO CODE CHANGE
> - Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]
>
> v1 -> v2
> - Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Fixed typo in the commit message "readble" to "readable"
> - Removed the explicit cross-check to decide if there is a conflict
> between the device tree compatible string and the hardware definition.
> This patch assumes the device tree is correctly written and therefore
> removes the need for a hardware/DT sanity check.
> - Removed extra semicolon in drivers/mfd/da9062-core.c:877
> - Re-write compatible entries into numerical order
>
> Lee,
>
> This patch adds support for the DA9061 PMIC. This is done as part of the
> existing DA9062 device driver by extending the of_device_id match table.
> This in turn allows new MFD cells, irq chip and regmap definitions to
> support DA9061.
>
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
>
>
> drivers/mfd/Kconfig | 5 +-
> drivers/mfd/da9062-core.c | 427 +++++++++++++++++++++++++++++++++--
> include/linux/mfd/da9062/core.h | 27 ++-
> include/linux/mfd/da9062/registers.h | 2 +
> 4 files changed, 441 insertions(+), 20 deletions(-)
[...]
> @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> return -EINVAL;
> }
>
> - chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
> + switch (chip->chip_type) {
> + case(COMPAT_TYPE_DA9061):
> + cell = da9061_devs;
> + cell_num = ARRAY_SIZE(da9061_devs);
> + irq_chip = &da9061_irq_chip;
> + config = &da9061_regmap_config;
> + break;
> + case(COMPAT_TYPE_DA9062):
> + cell = da9062_devs;
> + cell_num = ARRAY_SIZE(da9062_devs);
> + irq_chip = &da9062_irq_chip;
> + config = &da9062_regmap_config;
> + break;
> + default:
> + dev_err(chip->dev, "Unrecognised chip type\n");
> + return -ENODEV;
> + }
I very much dislike when MFD and OF functionality is mixed.
In your case you can use da9062_get_device_type() to dynamically
interrogate the device and register using the correct MFD cells that
way.
> + chip->regmap = devm_regmap_init_i2c(i2c, config);
> if (IS_ERR(chip->regmap)) {
> ret = PTR_ERR(chip->regmap);
> dev_err(chip->dev, "Failed to allocate register map: %d\n",
> @@ -493,7 +891,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
>
> ret = regmap_add_irq_chip(chip->regmap, i2c->irq,
> IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_SHARED,
> - -1, &da9062_irq_chip,
> + -1, irq_chip,
What is -1?
> &chip->regmap_irq);
> if (ret) {
> dev_err(chip->dev, "Failed to request IRQ %d: %d\n",
> @@ -503,8 +901,8 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
>
> irq_base = regmap_irq_chip_get_base(chip->regmap_irq);
>
> - ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, da9062_devs,
> - ARRAY_SIZE(da9062_devs), NULL, irq_base,
> + ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, cell,
> + cell_num, NULL, irq_base,
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Cédric Le Goater @ 2016-11-02 14:28 UTC (permalink / raw)
To: Joel Stanley, Arnd Bergmann
Cc: devicetree, Corey Minyard, Benjamin Herrenschmidt, Rob Herring,
openipmi-developer, linux-arm-kernel
In-Reply-To: <CACPK8XcM1_xmmUu-cCZrSR67Y_qeXuSJ4Xmd_2gcgDT321LdBQ@mail.gmail.com>
On 11/02/2016 02:56 PM, Joel Stanley wrote:
> On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday 02 November 2016, Cédric Le Goater wrote:
>>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
>>> other is H8S/2168 compliant.
>>>
>>> The current ipmi/bt-bmc driver implements the IPMI version and we
>>> should reflect its nature in the compatible node name using
>>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
>>> latter should be used for a H8S interface driver if it is implemented
>>> one day.
>>>
>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>
>> We generally try to avoid changing the compatible strings after the
>> fact, but it's probably ok in this case.
As the device tree changes are not merged yet, we thought we had some
more time to fine tune the naming.
>> I don't understand who decides which of the two interfaces is used:
>> is it the same register set that can be driven by either one or the
>> other driver, or do you expect to have two drivers that can both
>> be active in the same system and talk to different hardware once
>> you get there?
>
> It's the second case. The H8S BT has a different register layout so it
> would require a different driver.
yes.
> We don't yet have a driver for the other BT device, but there was
> recent talk of using it as an alternate (non-ipmi channel) between the
> BMC and the host. Before that discussion I wasn't aware that the H8S
> BT existed. I suggested we fix this up before it hits a final release.
>
> Cédric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a
> better job of describing the hardware here?
The specs refer to the two interfaces as BT (non IPMI) and iBT (IPMI).
I think we can keep the same naming.
> While we're modifying the binding, should we add a compat string for
> the ast2500?
Well, if the change in this patch is fine for all, may be we can add
the ast2500 compat string in a followup patch ?
Thanks,
C.
> Cheers,
>
> Joel
>
>>
>> If the first one of these is true, it seems a little awkward to
>> use the DT compatible string to decide which driver to use rather
>> than making the decision in the OS.
>>
>> Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/2] MAINTAINERS: oxnas: Add new files definitions
From: Neil Armstrong @ 2016-11-02 14:18 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-oxnas-Xt5XgHjqiBU06sgRBLv0+0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Neil Armstrong
In-Reply-To: <20161102141850.25164-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Fix the dts files maintained by the OXNAS platform, add a new board.
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..29d8853 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1478,8 +1478,9 @@ L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
L: linux-oxnas-Xt5XgHjqiBU06sgRBLv0+0B+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
-F: arch/arm/boot/dts/oxnas*
+F: arch/arm/boot/dts/ox8*.dtsi
F: arch/arm/boot/dts/wd-mbwe.dts
+F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
N: oxnas
ARM/Mediatek RTC DRIVER
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/2] ARM: dts: Add support for OX820 and Pogoplug V3
From: Neil Armstrong @ 2016-11-02 14:18 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linux-oxnas, devicetree; +Cc: Neil Armstrong
In-Reply-To: <20161102141850.25164-1-narmstrong@baylibre.com>
Add device tree for the Oxford Seminconductor OX820 SoC and the
Cloud Engines PogoPlug v3 board.
Add the SoC and board compatible strings to oxnas bindings.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
arch/arm/boot/dts/ox820.dtsi | 296 +++++++++++++++++++++
4 files changed, 397 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt
index b9e4971..ac64e60 100644
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ b/Documentation/devicetree/bindings/arm/oxnas.txt
@@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following properties:
Required root node property:
compatible: "oxsemi,ox810se"
+Boards with the OX820 SoC shall have the following properties:
+ Required root node property:
+ compatible: "oxsemi,ox820"
+
Board compatible values:
- "wd,mbwe" (OX810SE)
+ - "cloudengines,pogoplugv3" (OX820)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..3b0c74f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -604,7 +604,8 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
dtb-$(CONFIG_ARCH_OXNAS) += \
- wd-mbwe.dtb
+ wd-mbwe.dtb \
+ cloudengines-pogoplug-series-3.dtb
dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8060-dragonboard.dtb \
qcom-apq8064-arrow-sd-600eval.dtb \
diff --git a/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
new file mode 100644
index 0000000..bfde32e
--- /dev/null
+++ b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
@@ -0,0 +1,94 @@
+/*
+ * cloudengines-pogoplug-series-3.dtsi - Device tree file for Cloud Engines PogoPlug Series 3
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+#include "ox820.dtsi"
+
+/ {
+ model = "Cloud Engines PogoPlug Series 3";
+
+ compatible = "cloudengines,pogoplugv3", "oxsemi,ox820";
+
+ chosen {
+ bootargs = "earlyprintk";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ /* 128Mbytes DDR */
+ reg = <0x60000000 0x8000000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ blue {
+ label = "pogoplug:blue";
+ gpios = <&gpio0 2 0>;
+ default-state = "keep";
+ };
+
+ orange {
+ label = "pogoplug:orange";
+ gpios = <&gpio1 16 1>;
+ default-state = "keep";
+ };
+
+ green {
+ label = "pogoplug:green";
+ gpios = <&gpio1 17 1>;
+ default-state = "keep";
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+};
+
+&nandc {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nand>;
+
+ nand@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "hamming";
+
+ partition@0 {
+ label = "boot";
+ reg = <0x00000000 0x00e00000>;
+ read-only;
+ };
+
+ partition@e00000 {
+ label = "ubi";
+ reg = <0x00e00000 0x07200000>;
+ };
+ };
+};
+
+ða {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_etha_mdio>;
+};
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
new file mode 100644
index 0000000..e40f282
--- /dev/null
+++ b/arch/arm/boot/dts/ox820.dtsi
@@ -0,0 +1,296 @@
+/*
+ * ox820.dtsi - Device tree file for Oxford Semiconductor OX820 SoC
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "oxsemi,ox820";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "oxsemi,ox820-smp";
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <0>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <1>;
+ };
+ };
+
+ memory {
+ /* Max 512MB @ 0x60000000 */
+ reg = <0x60000000 0x20000000>;
+ };
+
+ clocks {
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ gmacclk: gmacclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ sysclk: sysclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <4>;
+ clock-mult = <1>;
+ clocks = <&osc>;
+ };
+
+ plla: plla {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <850000000>;
+ };
+
+ armclk: armclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ clocks = <&plla>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&gic>;
+
+ nandc: nand-controller@41000000 {
+ compatible = "oxsemi,ox820-nand";
+ reg = <0x41000000 0x100000>;
+ clocks = <&stdclk 11>;
+ resets = <&reset 15>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ etha: ethernet@40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk 9>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset 6>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+ };
+
+ apb-bridge@44000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x44000000 0x1000000>;
+
+ pinctrl: pinctrl {
+ compatible = "oxsemi,ox820-pinctrl";
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ pinctrl_uart0: uart0 {
+ uart0 {
+ pins = "gpio30", "gpio31";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart0_modem: uart0_modem {
+ uart0_modem_a {
+ pins = "gpio24", "gpio24", "gpio26", "gpio27";
+ function = "fct4";
+ };
+ uart0_modem_b {
+ pins = "gpio28", "gpio29";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart1: uart1 {
+ uart1 {
+ pins = "gpio7", "gpio8";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_uart1_modem: uart1_modem {
+ uart1_modem {
+ pins = "gpio5", "gpio6", "gpio40", "gpio41", "gpio42", "gpio43";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_etha_mdio: etha_mdio {
+ etha_mdio {
+ pins = "gpio3", "gpio4";
+ function = "fct1";
+ };
+ };
+
+ pinctrl_nand: nand {
+ nand {
+ pins = "gpio12", "gpio13", "gpio14", "gpio15",
+ "gpio16", "gpio17", "gpio18", "gpio19",
+ "gpio20", "gpio21", "gpio22", "gpio23",
+ "gpio24";
+ function = "fct1";
+ };
+ };
+ };
+
+ gpio0: gpio@000000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x000000 0x100000>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <32>;
+ oxsemi,gpio-bank = <0>;
+ gpio-ranges = <&pinctrl 0 0 32>;
+ };
+
+ gpio1: gpio@100000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x100000 0x100000>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <18>;
+ oxsemi,gpio-bank = <1>;
+ gpio-ranges = <&pinctrl 0 32 18>;
+ };
+
+ uart0: serial@200000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset 17>;
+ };
+
+ uart1: serial@300000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset 18>;
+ };
+
+ rps@400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x400000 0x100000>;
+
+ intc: interrupt-controller@0 {
+ compatible = "oxsemi,ox820-rps-irq", "oxsemi,ox810se-rps-irq";
+ interrupt-controller;
+ reg = <0 0x200>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ valid-mask = <0xFFFFFFFF>;
+ clear-mask = <0>;
+ };
+
+ timer0: timer@200 {
+ compatible = "oxsemi,ox820-rps-timer";
+ reg = <0x200 0x40>;
+ clocks = <&sysclk>;
+ interrupt-parent = <&intc>;
+ interrupts = <4>;
+ };
+ };
+
+ sys: sys-ctrl@e00000 {
+ compatible = "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd";
+ reg = <0xe00000 0x200000>;
+
+ reset: reset-controller {
+ compatible = "oxsemi,ox820-reset", "oxsemi,ox810se-reset";
+ #reset-cells = <1>;
+ };
+
+ stdclk: stdclk {
+ compatible = "oxsemi,ox820-stdclk", "oxsemi,ox810se-stdclk";
+ #clock-cells = <1>;
+ };
+ };
+ };
+
+ apb-bridge@47000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x47000000 0x1000000>;
+
+ scu: scu@0 {
+ compatible = "arm,arm11mp-scu";
+ reg = <0x0 0x100>;
+ };
+
+ local-timer@600 {
+ compatible = "arm,arm11mp-twd-timer";
+ reg = <0x600 0x20>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(3)|IRQ_TYPE_LEVEL_HIGH)>;
+ clocks = <&armclk>;
+ };
+
+ gic: gic@1000 {
+ compatible = "arm,arm11mp-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x1000 0x1000>,
+ <0x100 0x500>;
+ };
+ };
+ };
+};
--
2.7.0
^ permalink raw reply related
* [PATCH v2 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings
From: Neil Armstrong @ 2016-11-02 14:18 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linux-oxnas, devicetree; +Cc: Neil Armstrong
This patchset updates the ARM DTS for the Oxnas platform by :
- Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
- Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance
Changes since v1 at http://lkml.kernel.org/r/20161021151037.20112-1-narmstrong@baylibre.com :
- Due to a dt-bindings include dependency from clk and reset, the includes
are removed for the next release, and will be re-introduced after next
merge window.
Neil Armstrong (2):
ARM: dts: Add support for OX820 and Pogoplug V3
MAINTAINERS: oxnas: Add new files definitions
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
MAINTAINERS | 3 +-
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
arch/arm/boot/dts/ox820.dtsi | 296 +++++++++++++++++++++
5 files changed, 399 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
--
2.7.0
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Neil Armstrong @ 2016-11-02 14:02 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue
Cc: Neil Armstrong, netdev, linux-oxnas, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20161102140237.6955-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
new file mode 100644
index 0000000..df0534e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
@@ -0,0 +1,39 @@
+* Oxford Semiconductor OXNAS DWMAC Ethernet controller
+
+The device inherits all the properties of the dwmac/stmmac devices
+described in the file stmmac.txt in the current directory with the
+following changes.
+
+Required properties on all platforms:
+
+- compatible: For the OX820 SoC, it should be :
+ - "oxsemi,ox820-dwmac" to select glue
+ - "snps,dwmac-3.512" to select IP version.
+
+- clocks: Should contain phandles to the following clocks
+- clock-names: Should contain the following:
+ - "stmmaceth" for the host clock - see stmmac.txt
+ - "gmac" for the peripheral gate clock
+
+- oxsemi,sys-ctrl: a phandle to the system controller syscon node
+
+Example :
+
+etha: ethernet@40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset RESET_MAC>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+};
--
2.7.0
^ permalink raw reply related
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Joel Stanley @ 2016-11-02 13:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Cédric Le Goater, Corey Minyard,
openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benjamin Herrenschmidt
In-Reply-To: <201611021415.51081.arnd-r2nGTMty4D4@public.gmane.org>
On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday 02 November 2016, Cédric Le Goater wrote:
>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
>> other is H8S/2168 compliant.
>>
>> The current ipmi/bt-bmc driver implements the IPMI version and we
>> should reflect its nature in the compatible node name using
>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
>> latter should be used for a H8S interface driver if it is implemented
>> one day.
>>
>> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
>
> We generally try to avoid changing the compatible strings after the
> fact, but it's probably ok in this case.
>
> I don't understand who decides which of the two interfaces is used:
> is it the same register set that can be driven by either one or the
> other driver, or do you expect to have two drivers that can both
> be active in the same system and talk to different hardware once
> you get there?
It's the second case. The H8S BT has a different register layout so it
would require a different driver.
We don't yet have a driver for the other BT device, but there was
recent talk of using it as an alternate (non-ipmi channel) between the
BMC and the host. Before that discussion I wasn't aware that the H8S
BT existed. I suggested we fix this up before it hits a final release.
Cédric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a
better job of describing the hardware here?
While we're modifying the binding, should we add a compat string for
the ast2500?
Cheers,
Joel
>
> If the first one of these is true, it seems a little awkward to
> use the DT compatible string to decide which driver to use rather
> than making the decision in the OS.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 4/4] spi: sun6i: Support Allwinner H3 SPI controller
From: Maxime Ripard @ 2016-11-02 13:40 UTC (permalink / raw)
To: Milo Kim
Cc: Chen-Yu Tsai, Mark Brown, devicetree, linux-arm-kernel, linux-spi,
linux-kernel
In-Reply-To: <20161028065412.23008-5-woogyom.kim@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Fri, Oct 28, 2016 at 03:54:12PM +0900, Milo Kim wrote:
> H3 has two SPI controllers. The size of the buffer is 64 * 8.
> (8 bit transfer by 64 entry FIFO)
> A31 has four controllers. The size of the buffer is 128 * 8.
> (8 bit transfer by 128 entry FIFO)
>
> Register maps are sharable, so sun6i SPI driver is reusable with
> device configuration.
>
> Use the variable, 'fifo_depth' instead of fixed value to support both SPI
> controllers.
>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] ARM: dts: sun8i: Support NanoPi SBCs
From: Maxime Ripard @ 2016-11-02 13:33 UTC (permalink / raw)
To: Milo Kim
Cc: Chen-Yu Tsai, devicetree, linux-arm-kernel, linux-kernel,
James Pettigrew
In-Reply-To: <20161028065903.23298-1-woogyom.kim@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Fri, Oct 28, 2016 at 03:59:00PM +0900, Milo Kim wrote:
> NanoPi M1 and NEO have common features, so duplicate properties can be
> moved into new dtsi file.
Applied all three, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: sun9i: Enable SDIO-based WiFi
From: Maxime Ripard @ 2016-11-02 13:32 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20161028101154.7350-1-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
On Fri, Oct 28, 2016 at 06:11:51PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> Now that we have support for both PMICs, we can turn on the
> regulators needed for the onboard WiFi chips.
>
> This is a fairly simple series. The WiFi chips themselves are
> supported by the brcmfmac driver, but the user needs to get an
> nvram.txt file and put it in their firmware directory, in
> addition to the firmware file in linux-firmware. Otherwise we
> just need to enable the mmc controller and supply the vmmc and
> vqmmc regulators.
Applied all three, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH V3 8/9] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Lukasz Luba @ 2016-11-02 13:28 UTC (permalink / raw)
To: Steve Twiss, Eduardo Valentin, LINUX-KERNEL, LINUX-PM, Zhang Rui
Cc: DEVICETREE, Dmitry Torokhov, Guenter Roeck, LINUX-INPUT,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck
In-Reply-To: <52d74c72cc445d2bc911014f38b79c1f10426878.1477929725.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Hi Steve,
Please find my comments below.
Apart from these 2 comments, 10sec is not to long
(waiting for the temperature change)?
On 31/10/16 16:02, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> Add junction temperature monitoring supervisor device driver, compatible
> with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
>
> If the PMIC's internal junction temperature rises above TEMP_WARN (125
> degC) an interrupt is issued. This TEMP_WARN level is defined as the
> THERMAL_TRIP_HOT trip-wire inside the device driver.
>
> The thermal triggering mechanism is interrupt based and happens when the
> temperature rises above a given threshold level. The component cannot
> return an exact temperature, it only has knowledge if the temperature is
> above or below a given threshold value. A status bit must be polled to
> detect when the temperature falls below that threshold level again. A
> kernel work queue is configured to repeatedly poll and detect when the
> temperature falls below this trip-wire, between 1 and 10 second intervals
> (defaulting at 3 seconds).
>
> This first level of temperature supervision is intended for non-invasive
> temperature control, where the necessary measures for cooling the system
> down are left to the host software.
>
> Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> ---
> This patch applies against linux-next and v4.8
>
> v2 -> v3
> - Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
> - Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions
>
> v1 -> v2
> - Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - List the header files in alphabetical order
> - Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
> copyright "GNU Public License v2 or later" option in the header
> comment for this file. See the allowed identifiers in the file
> include/linux/module.h +170
> - Remove notify function "da9062_thermal_notify" function.
> - MODULE_AUTHOR() macros removes Company Name and just gives Name in
> accordance with include/linux/module.h +200
> - Remove the compatible "dlg,da9061-thermal" option in the of_device_id
> struct table. This patch now assumes the use of a DA9062 fallback
> compatible string in the DTS when using the DA9061 thermal component
> of the DA9061 device.
> - Re-ordered some assignments earlier in the probe() for thermal->hw,
> thermal->polling_period, thermal->mode, thermal->dev
> - Added further information in the patch description to explain the use
> of the device driver's built-in work-queue.
>
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
>
>
> drivers/thermal/Kconfig | 10 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/da9062-thermal.c | 291 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 302 insertions(+)
> create mode 100644 drivers/thermal/da9062-thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 2d702ca..da58e54 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -272,6 +272,16 @@ config DB8500_CPUFREQ_COOLING
> bound cpufreq cooling device turns active to set CPU frequency low to
> cool down the CPU.
>
> +config DA9062_THERMAL
> + tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
> + depends on MFD_DA9062
> + depends on OF
> + help
> + Enable this for the Dialog Semiconductor thermal sensor driver.
> + This will report PMIC junction over-temperature for one thermal trip
> + zone.
> + Compatible with the DA9062 and DA9061 PMICs.
> +
> config INTEL_POWERCLAMP
> tristate "Intel PowerClamp idle injection driver"
> depends on THERMAL
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 10b07c1..0a2b3f2 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> obj-$(CONFIG_TANGO_THERMAL) += tango_thermal.o
> obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
> obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
> +obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
> obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
> obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
> obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE) += intel_soc_dts_iosf.o
> diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
> new file mode 100644
> index 0000000..1f0af22
> --- /dev/null
> +++ b/drivers/thermal/da9062-thermal.c
> @@ -0,0 +1,291 @@
> +/*
> + * Thermal device driver for DA9062 and DA9061
> + * Copyright (C) 2016 Dialog Semiconductor Ltd.
> + *
> + * This program 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 program 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.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/thermal.h>
> +#include <linux/workqueue.h>
> +
> +#include <linux/mfd/da9062/core.h>
> +#include <linux/mfd/da9062/registers.h>
> +
> +#define DA9062_DEFAULT_POLLING_MS_PERIOD 3000
> +#define DA9062_MAX_POLLING_MS_PERIOD 10000
> +#define DA9062_MIN_POLLING_MS_PERIOD 1000
> +
> +#define DA9062_MILLI_CELSIUS(t) ((t)*1000)
> +
> +struct da9062_thermal_config {
> + const char *name;
> +};
> +
> +struct da9062_thermal {
> + struct da9062 *hw;
> + struct delayed_work work;
> + struct thermal_zone_device *zone;
> + enum thermal_device_mode mode;
> + unsigned int polling_period;
> + struct mutex lock;
> + int temperature;
> + int irq;
> + const struct da9062_thermal_config *config;
> + struct device *dev;
> +};
> +
> +static void da9062_thermal_poll_on(struct work_struct *work)
> +{
> + struct da9062_thermal *thermal = container_of(work,
> + struct da9062_thermal,
> + work.work);
> + unsigned int val;
> + int ret;
> +
> + /* clear E_TEMP */
> + ret = regmap_write(thermal->hw->regmap,
> + DA9062AA_EVENT_B,
> + DA9062AA_E_TEMP_MASK);
> + if (ret < 0) {
> + dev_err(thermal->dev,
> + "Cannot clear the TJUNC temperature status\n");
> + goto err_enable_irq;
> + }
> +
> + /* Now read E_TEMP again: it is acting like a status bit.
> + * If over-temperature, then this status will be true.
> + * If not over-temperature, this status will be false.
> + */
> + ret = regmap_read(thermal->hw->regmap,
> + DA9062AA_EVENT_B,
> + &val);
> + if (ret < 0) {
> + dev_err(thermal->dev,
> + "Cannot check the TJUNC temperature status\n");
> + goto err_enable_irq;
> + } else {
> + if (val & DA9062AA_E_TEMP_MASK) {
> + mutex_lock(&thermal->lock);
> + thermal->temperature = DA9062_MILLI_CELSIUS(125);
> + mutex_unlock(&thermal->lock);
> + thermal_zone_device_update(thermal->zone);
> +
> + schedule_delayed_work(&thermal->work,
> + msecs_to_jiffies(thermal->polling_period));
> + return;
> + } else {
> + mutex_lock(&thermal->lock);
> + thermal->temperature = DA9062_MILLI_CELSIUS(0);
> + mutex_unlock(&thermal->lock);
> + thermal_zone_device_update(thermal->zone);
> + }
> + }
> +
> +err_enable_irq:
> + enable_irq(thermal->irq);
> +}
> +
> +static irqreturn_t da9062_thermal_irq_handler(int irq, void *data)
> +{
> + struct da9062_thermal *thermal = data;
> +
> + disable_irq_nosync(thermal->irq);
> + schedule_delayed_work(&thermal->work, 0);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int da9062_thermal_get_mode(struct thermal_zone_device *z,
> + enum thermal_device_mode *mode)
> +{
> + struct da9062_thermal *thermal = z->devdata;
> + *mode = thermal->mode;
> + return 0;
> +}
> +
> +static int da9062_thermal_get_trip_type(struct thermal_zone_device *z,
> + int trip,
> + enum thermal_trip_type *type)
> +{
> + struct da9062_thermal *thermal = z->devdata;
> +
> + switch (trip) {
> + case 0:
> + *type = THERMAL_TRIP_HOT;
> + break;
> + default:
> + dev_err(thermal->dev,
> + "Driver does not support more than 1 trip-wire\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int da9062_thermal_get_trip_temp(struct thermal_zone_device *z,
> + int trip,
> + int *temp)
> +{
> + struct da9062_thermal *thermal = z->devdata;
> +
> + switch (trip) {
> + case 0:
> + *temp = DA9062_MILLI_CELSIUS(125);
> + break;
> + default:
> + dev_err(thermal->dev,
> + "Driver does not support more than 1 trip-wire\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int da9062_thermal_get_temp(struct thermal_zone_device *z,
> + int *temp)
> +{
> + struct da9062_thermal *thermal = z->devdata;
> +
> + mutex_lock(&thermal->lock);
> + *temp = thermal->temperature;
> + mutex_unlock(&thermal->lock);
> +
> + return 0;
> +}
> +
> +static struct thermal_zone_device_ops da9062_thermal_ops = {
> + .get_temp = da9062_thermal_get_temp,
> + .get_mode = da9062_thermal_get_mode,
> + .get_trip_type = da9062_thermal_get_trip_type,
> + .get_trip_temp = da9062_thermal_get_trip_temp,
> +};
> +
> +static const struct da9062_thermal_config da9062_config = {
> + .name = "da9062-thermal",
> +};
> +
> +static const struct of_device_id da9062_compatible_reg_id_table[] = {
> + { .compatible = "dlg,da9062-thermal", .data = &da9062_config },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, da9062_compatible_reg_id_table);
> +
> +static int da9062_thermal_probe(struct platform_device *pdev)
> +{
> + struct da9062 *chip = dev_get_drvdata(pdev->dev.parent);
> + struct da9062_thermal *thermal;
> + unsigned int pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
> + const struct of_device_id *match;
> + int ret = 0;
> +
> + match = of_match_node(da9062_compatible_reg_id_table,
> + pdev->dev.of_node);
> + if (!match)
> + return -ENXIO;
> +
> + if (pdev->dev.of_node) {
> + if (!of_property_read_u32(pdev->dev.of_node,
> + "dlg,tjunc-temp-polling-period-ms",
> + &pp_tmp)) {
> + if (pp_tmp < DA9062_MIN_POLLING_MS_PERIOD ||
> + pp_tmp > DA9062_MAX_POLLING_MS_PERIOD)
> + pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
Maybe it's worth to add some print here just to mention about
the DT value out of range. When you saw a dmesg with
this print on some bug report, you would know about wrong DT entry
(even if debug was not set).
> + }
> +
> + dev_dbg(&pdev->dev,
> + "TJUNC temp polling period set at %d ms\n",
> + pp_tmp);
> + }
> +
> + thermal = devm_kzalloc(&pdev->dev, sizeof(struct da9062_thermal),
> + GFP_KERNEL);
> + if (!thermal) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + thermal->config = match->data;
> + thermal->hw = chip;
> + thermal->polling_period = pp_tmp;
> + thermal->mode = THERMAL_DEVICE_ENABLED;
> + thermal->dev = &pdev->dev;
> +
> + INIT_DELAYED_WORK(&thermal->work, da9062_thermal_poll_on);
> + mutex_init(&thermal->lock);
> +
> + thermal->zone = thermal_zone_device_register(thermal->config->name,
> + 1, 0, thermal,
> + &da9062_thermal_ops, NULL, 0,
> + 0);
> + if (IS_ERR(thermal->zone)) {
> + dev_err(&pdev->dev, "Cannot register thermal zone device\n");
> + ret = PTR_ERR(thermal->zone);
> + goto err;
> + }
> +
> + ret = platform_get_irq_byname(pdev, "THERMAL");
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to get platform IRQ.\n");
> + goto err_zone;
> + }
> + thermal->irq = ret;
> +
> + ret = request_threaded_irq(thermal->irq, NULL,
> + da9062_thermal_irq_handler,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> + "THERMAL", thermal);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "Failed to request thermal device IRQ.\n");
> + goto err_zone;
> + }
> +
> + platform_set_drvdata(pdev, thermal);
> + return 0;
> +
> +err_zone:
> + thermal_zone_device_unregister(thermal->zone);
> +err:
> + return ret;
> +}
> +
> +static int da9062_thermal_remove(struct platform_device *pdev)
> +{
> + struct da9062_thermal *thermal = platform_get_drvdata(pdev);
> +
> + free_irq(thermal->irq, thermal);
> + thermal_zone_device_unregister(thermal->zone);
> + cancel_delayed_work_sync(&thermal->work);
You should change the order for these two functions
and cancel the work before unregistering thermal zone device.
> + return 0;
> +}
> +
> +static struct platform_driver da9062_thermal_driver = {
> + .probe = da9062_thermal_probe,
> + .remove = da9062_thermal_remove,
> + .driver = {
> + .name = "da9062-thermal",
> + .of_match_table = da9062_compatible_reg_id_table,
> + },
> +};
> +
> +module_platform_driver(da9062_thermal_driver);
> +
> +MODULE_AUTHOR("Steve Twiss");
> +MODULE_DESCRIPTION("Thermal TJUNC device driver for Dialog DA9062 and DA9061");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:da9062-thermal");
>
Regards,
Lukasz Luba
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig symbol
From: Patrice Chotard @ 2016-11-02 13:22 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
rui.zhang-ral2JQCrhuEAvxtiuMwx3w,
edubezval-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161024101408.GA10440@griffinp-ThinkPad-X1-Carbon-2nd>
On 10/24/2016 12:14 PM, Peter Griffin wrote:
> Hi Patrice,
>
> On Fri, 21 Oct 2016, patrice.chotard-qxv4g6HH51o@public.gmane.org wrote:
>
>> From: Patrice Chotard <patrice.chotard-qxv4g6HH51o@public.gmane.org>
>>
>> Driver code has been already removed, see
>> http://www.spinics.net/lists/devicetree/msg143322.html
>> Remove the multi_v7_defconfig part
>>
>> Signed-off-by: Patrice Chotard <patrice.chotard-qxv4g6HH51o@public.gmane.org>
>> Cc: <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> arch/arm/configs/multi_v7_defconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index 15b2f99..45e252b 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
>> CONFIG_ARMADA_THERMAL=y
>> CONFIG_DAVINCI_WATCHDOG=m
>> CONFIG_EXYNOS_THERMAL=m
>> -CONFIG_ST_THERMAL_MEMMAP=y
>
Hi Peter
> Are you sure you want to remove this?
Well spotted, you are right. It must be kept.
Thanks
>
> This Kconfig symbol is still used for the stih407 family
> thermal parts in drivers/thermal/st/st_thermal_memmap.c?
>
> My patch only removed the stih415/6 parts from the driver.
>
> regards,
>
> Peter.
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Arnd Bergmann @ 2016-11-02 13:15 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Corey Minyard,
openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Joel Stanley,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478073426-3714-2-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Wednesday 02 November 2016, Cédric Le Goater wrote:
> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
> other is H8S/2168 compliant.
>
> The current ipmi/bt-bmc driver implements the IPMI version and we
> should reflect its nature in the compatible node name using
> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
> latter should be used for a H8S interface driver if it is implemented
> one day.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
We generally try to avoid changing the compatible strings after the
fact, but it's probably ok in this case.
I don't understand who decides which of the two interfaces is used:
is it the same register set that can be driven by either one or the
other driver, or do you expect to have two drivers that can both
be active in the same system and talk to different hardware once
you get there?
If the first one of these is true, it seems a little awkward to
use the DT compatible string to decide which driver to use rather
than making the decision in the OS.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 1/2] iio: adc: spmi-vadc: Update changes to support reporting of Raw adc code.
From: Phani A, Rama Krishna @ 2016-11-02 13:12 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
smohanad-sgV2jX0FEOL9JmXXK+q4OQ, mgautam-sgV2jX0FEOL9JmXXK+q4OQ,
sivaa-sgV2jX0FEOL9JmXXK+q4OQ, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
Julia.Lawall-L2FTfq7BK8M
In-Reply-To: <de2a0283-201d-fdab-98d0-be45ca71f5ea-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Hi Jonathan,
On 02-Nov-16 12:00 AM, Jonathan Cameron wrote:
> On 31/10/16 08:48, Rama Krishna Phani A wrote:
>> Hi Jonathan,
>>
>> On 30-Oct-16 11:05 PM, Jonathan Cameron wrote:
>>> On 26/10/16 15:41, Rama Krishna Phani A wrote:
>>>> Logic to convert adc code to voltage is generic across all channels.
>>>> Different scaling can be done on the obtained voltage to report in physical
>>>> units. Implement separate function for generic conversion logic.
>>>> Scaling functionality can be changed per channel. Update changes to support
>>>> reporting of Raw adc code.
>>> Pleas rewrite this description. Perhaps give examples of the changes
>>> it makes to what is read from the various attributes?
>> There are several channels in the ADC of PMIC which can be used to
>> measure voltage, temperature, current etc., Hardware provides
>> readings for all channels in adc code. That adc code needs to be
>> converted to voltage. The logic for conversion of adc code to voltage
>> is common for all ADC channels(voltage, temperature and current
>> .,etc). Once voltage is obtained ., scaling is done on that voltage.
>>
>> For Ex., Thermal SW wants to know the temperature of thermistor on
>> PMIC and it expects the temperature to be reported in millidegC. ADC
>> channel is used to read the adc code and convert it to voltage. Once
>> the voltage is available based on the thermistor spec that voltage is
>> mapped to a temperature and then that value is reported to Thermal
>> SW.
>>
>> Mapping of voltage to temperature is called scaling for that channel
>> and scaling function can be different per channel based on how the
>> voltage is reported.
> Is the thermistor always part of the device? (i.e. in the chip) in which
> case this might be fine. If it's external then it needs to be described
> by a separate device which acts as a consumer of the IIO channel and
> in turn provides the scaled output to thermal.
>
> The thermistor should really be separately described. This is already
> done in drivers/hwmon/ntc_thermistor
>
> Are any of these scalings characteristics of the chip supported by
> this driver, or are they the result of external hardware?
All the VADC channels i.e., Voltage, temperature(thermistors and other
channels) are part of PMIC chip. The scaling functionalities supported
in this driver are for the adc channels which are part of PMIC chip.
>>>
>>> I haven't immediately followed what this change is actually doing.
>>>
>>> I 'think' the point here is to not apply the calibration to
>>> the raw adc counts when a true raw read is requested?
>>>
>> When a true raw read is requested .,Scaling is not applied.
>>> There are several unconnected looking changes in here...
>>>>
>>>> Signed-off-by: Rama Krishna Phani A <rphani-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> ---
>>>> drivers/iio/adc/qcom-spmi-vadc.c | 54 +++++++++++++++++++++-------------------
>>>> 1 file changed, 28 insertions(+), 26 deletions(-)
>>>>
>>>> diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c
>>>> index c2babe5..ff4d549 100644
>>>> --- a/drivers/iio/adc/qcom-spmi-vadc.c
>>>> +++ b/drivers/iio/adc/qcom-spmi-vadc.c
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2012-2014, The Linux Foundation. All rights reserved.
>>>> + * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
>>>> *
>>>> * This program is free software; you can redistribute it and/or modify
>>>> * it under the terms of the GNU General Public License version 2 and
>>>> @@ -84,7 +84,7 @@
>>>> #define VADC_MAX_ADC_CODE 0xa800
>>>>
>>>> #define VADC_ABSOLUTE_RANGE_UV 625000
>>>> -#define VADC_RATIOMETRIC_RANGE_UV 1800000
>>>> +#define VADC_RATIOMETRIC_RANGE 1800
>>>>
>>>> #define VADC_DEF_PRESCALING 0 /* 1:1 */
>>>> #define VADC_DEF_DECIMATION 0 /* 512 */
>>>> @@ -418,7 +418,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>>>> u16 read_1, read_2;
>>>> int ret;
>>>>
>>>> - vadc->graph[VADC_CALIB_RATIOMETRIC].dx = VADC_RATIOMETRIC_RANGE_UV;
>>>> + vadc->graph[VADC_CALIB_RATIOMETRIC].dx = VADC_RATIOMETRIC_RANGE;
>>>> vadc->graph[VADC_CALIB_ABSOLUTE].dx = VADC_ABSOLUTE_RANGE_UV;
>>>>
>>>> prop = vadc_get_channel(vadc, VADC_REF_1250MV);
>>>> @@ -468,21 +468,30 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>>>> return ret;
>>>> }
>>>>
>>>> -static s32 vadc_calibrate(struct vadc_priv *vadc,
>>>> - const struct vadc_channel_prop *prop, u16 adc_code)
>>>> +static void vadc_scale_calib(struct vadc_priv *vadc, u16 adc_code,
>>>> + const struct vadc_channel_prop *prop,
>>>> + s64 *scale_voltage)
>>>> {
>>>> - const struct vadc_prescale_ratio *prescale;
>>>> - s64 voltage;
>>>> + *scale_voltage = (adc_code -
>>>> + vadc->graph[prop->calibration].gnd);
>>>> + *scale_voltage *= vadc->graph[prop->calibration].dx;
>>>> + *scale_voltage = div64_s64(*scale_voltage,
>>>> + vadc->graph[prop->calibration].dy);
>>>> + if (prop->calibration == VADC_CALIB_ABSOLUTE)
>>>> + *scale_voltage +=
>>>> + vadc->graph[prop->calibration].dx;
>>>>
>>>> - voltage = adc_code - vadc->graph[prop->calibration].gnd;
>>>> - voltage *= vadc->graph[prop->calibration].dx;
>>>> - voltage = div64_s64(voltage, vadc->graph[prop->calibration].dy);
>>>> + if (*scale_voltage < 0)
>>>> + *scale_voltage = 0;
>>>> +}
>>>>
>>>> - if (prop->calibration == VADC_CALIB_ABSOLUTE)
>>>> - voltage += vadc->graph[prop->calibration].dx;
>>>> +static s64 vadc_scale_fn(struct vadc_priv *vadc,
>>>> + const struct vadc_channel_prop *prop, u16 adc_code)
>>>> +{
>>>> + const struct vadc_prescale_ratio *prescale;
>>>> + s64 voltage = 0;
>>>>
>>>> - if (voltage < 0)
>>>> - voltage = 0;
>>>> + vadc_scale_calib(vadc, adc_code, prop, &voltage);
>>>>
>>>> prescale = &vadc_prescale_ratios[prop->prescale];
>>>>
>>>> @@ -552,11 +561,8 @@ static int vadc_read_raw(struct iio_dev *indio_dev,
>>>> if (ret)
>>>> break;
>>>>
>>>> - *val = vadc_calibrate(vadc, prop, adc_code);
>>>> + *val = vadc_scale_fn(vadc, prop, adc_code);
>>>>
>>>> - /* 2mV/K, return milli Celsius */
>>>> - *val /= 2;
>>>> - *val -= KELVINMIL_CELSIUSMIL;
>>>> return IIO_VAL_INT;
>>>> case IIO_CHAN_INFO_RAW:
>>>> prop = &vadc->chan_props[chan->address];
>>>> @@ -564,12 +570,8 @@ static int vadc_read_raw(struct iio_dev *indio_dev,
>>>> if (ret)
>>>> break;
>>>>
>>>> - *val = vadc_calibrate(vadc, prop, adc_code);
>>>> + *val = (int)adc_code;
>>>> return IIO_VAL_INT;
>>> So this is 'more raw'.
>> Yes., its raw value.
>>>> - case IIO_CHAN_INFO_SCALE:
>>>> - *val = 0;
>>>> - *val2 = 1000;
>>>> - return IIO_VAL_INT_PLUS_MICRO;
>>>> default:
>>>> ret = -EINVAL;
>>>> break;
>>>> @@ -616,8 +618,8 @@ struct vadc_channels {
>>>> VADC_CHAN(_dname, IIO_TEMP, BIT(IIO_CHAN_INFO_PROCESSED), _pre) \
>>>>
>>>> #define VADC_CHAN_VOLT(_dname, _pre) \
>>>> - VADC_CHAN(_dname, IIO_VOLTAGE, \
>>>> - BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE), \
>>>> + VADC_CHAN(_dname, IIO_VOLTAGE, \
>>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED),\
>>>> _pre) \
>>> It very unusual to report both raw and processed values. Please explain
>>> why that is needed here? It may be valid to maintain backwards compatibility
>>> of ABI. Which would be fine. However if I read the above correctly you are
>>> changing what comes out of reading the raw value so the ABI just changed...
>>>
>> With the help of IIO sysfs ., we can read the ADC channel readings
>> either in RAW format or in processed format. There are two separate
>> individual entries to read the ADC channel either in Raw format or in
>> processed format. Most of the clients for ADC expect the readings in
>> processed format.
> If we are talking in kernel, that is worked out by the application of
> scale. The IIO in kernel interfaces will do this automatically.
>
> I we are talking in userspace, then the userspace needs to be
> extended to support raw and scale reading.
Every channel present in adc has an unique conversion formula for
obtained voltage, suggested by Hardware designers.
Ex: For die_temp channel., Temp = 2mv/Kelvin
Above formula has to be applied on obtained voltage in order for the
channel to report the temperature in milldegC.
Like wise every channel has unique way of conversion logic suggested by
HW folks. That conversion logic is done in ADC driver.
>>>
>
>>>> /*
>>>> @@ -850,9 +852,9 @@ static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node *node)
>>>>
>>>> iio_chan->channel = prop.channel;
>>>> iio_chan->datasheet_name = vadc_chan->datasheet_name;
>>>> + iio_chan->extend_name = child->name;
>>> What's this change?
>> We can choose how we want to display our adc channel entries in sysfs. Am using the child node name to be displayed as the sysfs entry rather than channel number for easy interpretation.
>>
>> For ex: for vcoin(coin battery voltage channel.,) with this change it appears like below in iio adc sysfs
>>
>> "in_voltage_vcoin_input"
> No. This introduces a mass of undocumented (and uncontrolled) ABI.
> If there are reasons to add such a label then it should not be done
> in the file name.
"extended_name" is an existing field in "iio_chan_spec" structure,
present in iio.h(include\linux\iio) and has documentation regarding the
functionality. Pasting it here for quick reference.
* @extend_name:Allows labeling of channel attributes with an
* informative name. Note this has no effect codes etc,
* unlike modifiers.
Am trying to use the existing field here., initializing it with a value
which is easy for interpretation of channel attributes.
>>
>>>> iio_chan->info_mask_separate = vadc_chan->info_mask;
>>>> iio_chan->type = vadc_chan->type;
>>>> - iio_chan->indexed = 1;
>>> Or for that matter this one...
>> reason explained above.
>>>> iio_chan->address = index++;
>>>>
>>>> iio_chan++;
>>>>
>>>
>>
>> Thanks,
>> Ramakrishna
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks,
Ramakrishna
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] soc: qcom: Add SoC info driver
From: Arnd Bergmann @ 2016-11-02 13:11 UTC (permalink / raw)
To: Imran Khan
Cc: andy.gross, David Brown, Rob Herring, Mark Rutland,
open list:ARM/QUALCOMM SUPPORT, open list:ARM/QUALCOMM SUPPORT,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <ee68877b-6837-1c35-b440-2a12bb4e1225@codeaurora.org>
On Wednesday 02 November 2016, Imran Khan wrote:
> On 10/27/2016 7:11 PM, Arnd Bergmann wrote:
> > On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote:
> >> On 10/26/2016 8:16 PM, Arnd Bergmann wrote:
> >>> On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote:
> >>
> >> Yes. Having a manufacturing process as part of foundry-id can provide a more
> >> thorough information.
> >
> > Ok, sounds good. Let's do it like this. We can always add support for
> > in-kernel matching of this string if needed later.
> >
>
> Thanks for the feedback. So how should I proceed now, should I
>
> i. send one patch first that adds the serial_number and foundry_id fields
> in generic soc_dev_attribute structure and then send my modified socinfo
> driver as per new soc_dev_attribute structure
>
> or
>
> ii. send both the changes as 2 separate patches of the same patch set.
>
> or
>
> iii. Continue with the current soc_dev_attribute structure and modify
> the socinfo driver once soc_dev_attribute structure has serial_number
> and foundry_id fields.
It's not overly important, but I'd prefer the third approach, the advantage
being that we can review the driver and merge it independently of
any possible further discussion on the added attributes. Sending
this as a series of three patches (1. add the driver, 2. add the
infrastructure, 3. use the infrastructure in your driver) is probably
best.
Arnd
^ permalink raw reply
* Re: [PATCH v3 3/6] [media] rc-core: add support for IR raw transmitters
From: kbuild test robot @ 2016-11-02 12:34 UTC (permalink / raw)
Cc: kbuild-all, Mauro Carvalho Chehab, Sean Young, Rob Herring,
Mark Rutland, Richard Purdie, Jacek Anaszewski, linux-media,
devicetree, linux-leds, linux-kernel, Andi Shyti, Andi Shyti
In-Reply-To: <20161102104010.26959-4-andi.shyti@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 5444 bytes --]
Hi Andi,
[auto build test WARNING on hid/for-next]
[also build test WARNING on v4.9-rc3]
[cannot apply to linuxtv-media/master next-20161028]
[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/Andi-Shyti/Add-support-for-IR-transmitters/20161102-184657
base: https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-next
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
include/linux/init.h:1: warning: no structured comments found
include/linux/workqueue.h:392: warning: No description found for parameter '...'
include/linux/workqueue.h:392: warning: Excess function parameter 'args' description in 'alloc_workqueue'
include/linux/workqueue.h:413: warning: No description found for parameter '...'
include/linux/workqueue.h:413: warning: Excess function parameter 'args' description in 'alloc_ordered_workqueue'
include/linux/kthread.h:26: warning: No description found for parameter '...'
kernel/sys.c:1: warning: no structured comments found
drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
include/linux/fence-array.h:61: warning: No description found for parameter 'fence'
include/sound/core.h:324: warning: No description found for parameter '...'
include/sound/core.h:335: warning: No description found for parameter '...'
include/sound/core.h:388: warning: No description found for parameter '...'
include/media/media-entity.h:1054: warning: No description found for parameter '...'
>> include/media/rc-core.h:39: warning: bad line: driver requires pulse/space data sequence.
include/net/mac80211.h:2148: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:2153: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:3202: ERROR: Unexpected indentation.
include/net/mac80211.h:3205: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:3207: ERROR: Unexpected indentation.
include/net/mac80211.h:3208: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:1435: WARNING: Inline emphasis start-string without end-string.
include/net/mac80211.h:1172: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:1173: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:814: ERROR: Unexpected indentation.
include/net/mac80211.h:815: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:820: ERROR: Unexpected indentation.
include/net/mac80211.h:821: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:2489: ERROR: Unexpected indentation.
include/net/mac80211.h:1768: ERROR: Unexpected indentation.
include/net/mac80211.h:1772: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:1746: WARNING: Inline emphasis start-string without end-string.
kernel/sched/fair.c:7252: WARNING: Inline emphasis start-string without end-string.
kernel/time/timer.c:1230: ERROR: Unexpected indentation.
kernel/time/timer.c:1232: ERROR: Unexpected indentation.
kernel/time/timer.c:1233: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:121: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:124: ERROR: Unexpected indentation.
include/linux/wait.h:126: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/time/hrtimer.c:1021: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/signal.c:317: WARNING: Inline literal start-string without end-string.
drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent.
drivers/message/fusion/mptbase.c:5054: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/tty/serial/serial_core.c:1893: WARNING: Definition list ends without a blank line; unexpected unindent.
include/linux/spi/spi.h:369: ERROR: Unexpected indentation.
WARNING: dvipng command 'dvipng' cannot be run (needed for math display), check the imgmath_dvipng setting
vim +39 include/media/rc-core.h
23 #include <media/rc-map.h>
24
25 extern int rc_core_debug;
26 #define IR_dprintk(level, fmt, ...) \
27 do { \
28 if (rc_core_debug >= level) \
29 printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \
30 } while (0)
31
32 /**
33 * enum rc_driver_type - type of the RC output
34 *
35 * @RC_DRIVER_SCANCODE: Driver or hardware generates a scancode
36 * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space sequences.
37 * It needs a Infra-Red pulse/space decoder
38 * @RC_DRIVER_IR_RAW_TX: Device transmitter only,
> 39 driver requires pulse/space data sequence.
40 */
41 enum rc_driver_type {
42 RC_DRIVER_SCANCODE = 0,
43 RC_DRIVER_IR_RAW,
44 RC_DRIVER_IR_RAW_TX,
45 };
46
47 /**
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6432 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ARM: shmobile: r8a7745: add CPG clock index macros
From: Geert Uytterhoeven @ 2016-11-02 11:17 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Michael Turquette, linux-clk, Stephen Boyd, Rob Herring,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux-Renesas, Simon Horman
In-Reply-To: <2946846.zhWOBzBeGa-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
On Thu, Oct 27, 2016 at 10:42 PM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> Add macros usable by the device tree sources to reference the R8A7745 CPG
> clocks by index. The data comes from the table 7.2c in the revision 0.50
> of the RZ/G Series User's Manual.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: kbuild test robot @ 2016-11-02 10:49 UTC (permalink / raw)
Cc: kbuild-all, thierry.reding, swarren, linus.walleij, robh+dt,
mark.rutland, jonathanh, yamada.masahiro, linux-gpio, devicetree,
linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478077742-25437-3-git-send-email-ldewangan@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 12563 bytes --]
Hi Laxman,
[auto build test ERROR on tegra/for-next]
[also build test ERROR on v4.9-rc3 next-20161028]
[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/Laxman-Dewangan/pinctrl-tegra-Add-support-for-IO-pad-control/20161102-173122
base: https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:42:20: error: field 'pad_id' has incomplete type
enum tegra_io_pad pad_id;
^~~~~~
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c: In function 'tegra_io_pad_pinconf_get':
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:103:7: error: variable 'pad_id' has initializer but incomplete type
enum tegra_io_pad pad_id = pad_cfg->pad_id;
^~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:103:20: error: storage size of 'pad_id' isn't known
enum tegra_io_pad pad_id = pad_cfg->pad_id;
^~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:109:9: error: implicit declaration of function 'tegra_io_pad_get_voltage' [-Werror=implicit-function-declaration]
ret = tegra_io_pad_get_voltage(pad_id);
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:116:9: error: implicit declaration of function 'tegra_io_pad_power_get_status' [-Werror=implicit-function-declaration]
ret = tegra_io_pad_power_get_status(pad_id);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:103:20: warning: unused variable 'pad_id' [-Wunused-variable]
enum tegra_io_pad pad_id = pad_cfg->pad_id;
^~~~~~
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c: In function 'tegra_io_pad_pinconf_set':
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:150:10: error: implicit declaration of function 'tegra_io_pad_set_voltage' [-Werror=implicit-function-declaration]
ret = tegra_io_pad_set_voltage(pad_id, param_val);
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:161:11: error: implicit declaration of function 'tegra_io_pad_power_disable' [-Werror=implicit-function-declaration]
ret = tegra_io_pad_power_disable(pad_id);
^~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:163:11: error: implicit declaration of function 'tegra_io_pad_power_enable' [-Werror=implicit-function-declaration]
ret = tegra_io_pad_power_enable(pad_id);
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c: At top level:
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:307:13: error: 'TEGRA_IO_PAD_AUDIO' undeclared here (not in a function)
.pad_id = TEGRA_IO_PAD_##_pad_id, \
^
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:232:2: note: in expansion of macro 'TEGRA_IO_PAD_INFO'
_entry_(0, "audio", AUDIO, true, false), \
^~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:313:2: note: in expansion of macro 'TEGRA124_PAD_INFO_TABLE'
TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
^~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:307:13: error: 'TEGRA_IO_PAD_BB' undeclared here (not in a function)
.pad_id = TEGRA_IO_PAD_##_pad_id, \
^
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:233:2: note: in expansion of macro 'TEGRA_IO_PAD_INFO'
_entry_(1, "bb", BB, true, false), \
^~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:313:2: note: in expansion of macro 'TEGRA124_PAD_INFO_TABLE'
TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
^~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:307:13: error: 'TEGRA_IO_PAD_CAM' undeclared here (not in a function)
.pad_id = TEGRA_IO_PAD_##_pad_id, \
^
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:234:2: note: in expansion of macro 'TEGRA_IO_PAD_INFO'
_entry_(2, "cam", CAM, true, false), \
^~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:313:2: note: in expansion of macro 'TEGRA124_PAD_INFO_TABLE'
TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
^~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:307:13: error: 'TEGRA_IO_PAD_COMP' undeclared here (not in a function)
.pad_id = TEGRA_IO_PAD_##_pad_id, \
^
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:235:2: note: in expansion of macro 'TEGRA_IO_PAD_INFO'
_entry_(3, "comp", COMP, true, false), \
^~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:313:2: note: in expansion of macro 'TEGRA124_PAD_INFO_TABLE'
TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
^~~~~~~~~~~~~~~~~~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:307:13: error: 'TEGRA_IO_PAD_CSIA' undeclared here (not in a function)
.pad_id = TEGRA_IO_PAD_##_pad_id, \
^
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:236:2: note: in expansion of macro 'TEGRA_IO_PAD_INFO'
_entry_(4, "csia", CSIA, true, false), \
^~~~~~~
>> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:313:2: note: in expansion of macro 'TEGRA124_PAD_INFO_TABLE'
TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
^~~~~~~~~~~~~~~~~~~~~~~
vim +/pad_id +42 drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
36 },
37 };
38
39 struct tegra_io_pads_cfg_info {
40 const char *name;
41 const unsigned int pins[1];
> 42 enum tegra_io_pad pad_id;
43 bool voltage_can_change;
44 bool support_low_power_state;
45 };
46
47 struct tegra_io_pad_soc_data {
48 const struct tegra_io_pads_cfg_info *pads_cfg;
49 int num_pads_cfg;
50 const struct pinctrl_pin_desc *pins_desc;
51 int num_pins_desc;
52 };
53
54 struct tegra_io_pads_info {
55 struct device *dev;
56 struct pinctrl_dev *pctl;
57 const struct tegra_io_pad_soc_data *soc_data;
58 };
59
60 static int tegra_iop_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
61 {
62 struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
63
64 return tiopi->soc_data->num_pads_cfg;
65 }
66
67 static const char *tegra_iop_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
68 unsigned int group)
69 {
70 struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
71
72 return tiopi->soc_data->pads_cfg[group].name;
73 }
74
75 static int tegra_iop_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
76 unsigned int group,
77 const unsigned int **pins,
78 unsigned int *num_pins)
79 {
80 struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
81
82 *pins = tiopi->soc_data->pads_cfg[group].pins;
83 *num_pins = 1;
84
85 return 0;
86 }
87
88 static const struct pinctrl_ops tegra_iop_pinctrl_ops = {
89 .get_groups_count = tegra_iop_pinctrl_get_groups_count,
90 .get_group_name = tegra_iop_pinctrl_get_group_name,
91 .get_group_pins = tegra_iop_pinctrl_get_group_pins,
92 .dt_node_to_map = pinconf_generic_dt_node_to_map_pin,
93 .dt_free_map = pinctrl_utils_free_map,
94 };
95
96 static int tegra_io_pad_pinconf_get(struct pinctrl_dev *pctldev,
97 unsigned int pin, unsigned long *config)
98 {
99 struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
100 int param = pinconf_to_config_param(*config);
101 const struct tegra_io_pads_cfg_info *pad_cfg =
102 &tiopi->soc_data->pads_cfg[pin];
> 103 enum tegra_io_pad pad_id = pad_cfg->pad_id;
104 int arg = 0;
105 int ret;
106
107 switch (param) {
108 case TEGRA_IO_PAD_POWER_SOURCE_VOLTAGE:
> 109 ret = tegra_io_pad_get_voltage(pad_id);
110 if (ret < 0)
111 return ret;
112 arg = ret;
113 break;
114
115 case PIN_CONFIG_LOW_POWER_MODE:
> 116 ret = tegra_io_pad_power_get_status(pad_id);
117 if (ret < 0)
118 return ret;
119 arg = !ret;
120 break;
121
122 default:
123 dev_err(tiopi->dev, "The parameter %d not supported\n", param);
124 return -EINVAL;
125 }
126
127 *config = pinconf_to_config_packed(param, (u16)arg);
128 return 0;
129 }
130
131 static int tegra_io_pad_pinconf_set(struct pinctrl_dev *pctldev,
132 unsigned int pin, unsigned long *configs,
133 unsigned int num_configs)
134 {
135 struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
136 const struct tegra_io_pads_cfg_info *pad_cfg =
137 &tiopi->soc_data->pads_cfg[pin];
138 int pad_id = pad_cfg->pad_id;
139 u16 param_val;
140 int param;
141 int ret;
142 int i;
143
144 for (i = 0; i < num_configs; i++) {
145 param = pinconf_to_config_param(configs[i]);
146 param_val = pinconf_to_config_argument(configs[i]);
147
148 switch (param) {
149 case TEGRA_IO_PAD_POWER_SOURCE_VOLTAGE:
> 150 ret = tegra_io_pad_set_voltage(pad_id, param_val);
151 if (ret < 0) {
152 dev_err(tiopi->dev,
153 "Failed to set voltage %d of pin %u: %d\n",
154 param_val, pin, ret);
155 return ret;
156 }
157 break;
158
159 case PIN_CONFIG_LOW_POWER_MODE:
160 if (param_val)
> 161 ret = tegra_io_pad_power_disable(pad_id);
162 else
> 163 ret = tegra_io_pad_power_enable(pad_id);
164 if (ret < 0) {
165 dev_err(tiopi->dev,
166 "Failed to set DPD %d of pin %u: %d\n",
167 param_val, pin, ret);
168 return ret;
169 }
170 break;
171
172 default:
173 dev_err(tiopi->dev, "The parameter %d not supported\n",
174 param);
175 return -EINVAL;
176 }
177 }
178
179 return 0;
180 }
181
182 static const struct pinconf_ops tegra_io_pad_pinconf_ops = {
183 .pin_config_get = tegra_io_pad_pinconf_get,
184 .pin_config_set = tegra_io_pad_pinconf_set,
185 };
186
187 static struct pinctrl_desc tegra_iop_pinctrl_desc = {
188 .name = "pinctrl-tegra-io-pads",
189 .pctlops = &tegra_iop_pinctrl_ops,
190 .confops = &tegra_io_pad_pinconf_ops,
191 .custom_params = tegra_io_pads_cfg_params,
192 .num_custom_params = ARRAY_SIZE(tegra_io_pads_cfg_params),
193 };
194
195 static int tegra_iop_pinctrl_probe(struct platform_device *pdev)
196 {
197 struct device *dev = &pdev->dev;
198 const struct platform_device_id *id = platform_get_device_id(pdev);
199 struct device_node *np_parent = pdev->dev.parent->of_node;
200 struct tegra_io_pads_info *tiopi;
201
202 if (!np_parent) {
203 dev_err(&pdev->dev, "PMC should be register from DT\n");
204 return -ENODEV;
205 }
206
207 tiopi = devm_kzalloc(&pdev->dev, sizeof(*tiopi), GFP_KERNEL);
208 if (!tiopi)
209 return -ENOMEM;
210
211 tiopi->dev = &pdev->dev;
212 pdev->dev.of_node = np_parent;
213 tiopi->soc_data = (const struct tegra_io_pad_soc_data *)id->driver_data;
214 tegra_iop_pinctrl_desc.pins = tiopi->soc_data->pins_desc;
215 tegra_iop_pinctrl_desc.npins = tiopi->soc_data->num_pins_desc;
216 platform_set_drvdata(pdev, tiopi);
217
218 tiopi->pctl = devm_pinctrl_register(dev, &tegra_iop_pinctrl_desc,
219 tiopi);
220 if (IS_ERR(tiopi->pctl)) {
221 int ret = PTR_ERR(tiopi->pctl);
222
223 dev_err(dev, "Failed to register io-pad pinctrl driver: %d\n",
224 ret);
225 return ret;
226 }
227
228 return 0;
229 }
230
231 #define TEGRA124_PAD_INFO_TABLE(_entry_) \
> 232 _entry_(0, "audio", AUDIO, true, false), \
233 _entry_(1, "bb", BB, true, false), \
234 _entry_(2, "cam", CAM, true, false), \
235 _entry_(3, "comp", COMP, true, false), \
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 58490 bytes --]
^ permalink raw reply
* [PATCH v3 6/6] [media] rc: add support for IR LEDs driven through SPI
From: Andi Shyti @ 2016-11-02 10:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andi Shyti, Andi Shyti
In-Reply-To: <20161102104010.26959-1-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.
The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through an rc character device. The chardev
is handled by the LIRC framework and its functionality basically
provides:
- write: the driver gets a pulse/space signal and translates it
to a binary signal that will be streamed to the IR led through
the SPI framework.
- set frequency: sets the frequency whith which the data should
be sent. This is handle with ioctl with the
LIRC_SET_SEND_CARRIER flag (as per lirc documentation)
- set duty cycle: this is also handled with ioctl with the
LIRC_SET_SEND_DUTY_CYCLE flag. The driver handles duty cycles
of 50%, 60%, 70%, 75%, 80% and 90%, calculated on 16bit data.
The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.
Example of usage:
fd = open("/dev/lirc0", O_RDWR);
if (fd < 0)
return -1;
val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val);
if (ret < 0)
return -1;
val = 60;
ret = ioctl(fd, LIRC_SET_SEND_DUTY_CYCLE, &val);
if (ret < 0)
return -1;
n = write(fd, buffer, BUF_LEN);
if (n < 0 || n != BUF_LEN)
ret = -1;
close(fd);
Signed-off-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Sean Young <sean-hENCXIMQXOg@public.gmane.org>
---
drivers/media/rc/Kconfig | 9 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-spi.c | 205 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 215 insertions(+)
create mode 100644 drivers/media/rc/ir-spi.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 370e16e..207dfcc 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -261,6 +261,15 @@ config IR_REDRAT3
To compile this driver as a module, choose M here: the
module will be called redrat3.
+config IR_SPI
+ tristate "SPI connected IR LED"
+ depends on SPI && LIRC
+ ---help---
+ Say Y if you want to use an IR LED connected through SPI bus.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ir-spi.
+
config IR_STREAMZAP
tristate "Streamzap PC Remote IR Receiver"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..1417c8d 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
obj-$(CONFIG_IR_RX51) += ir-rx51.o
+obj-$(CONFIG_IR_SPI) += ir-spi.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
new file mode 100644
index 0000000..fcda1e4
--- /dev/null
+++ b/drivers/media/rc/ir-spi.c
@@ -0,0 +1,205 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Author: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * SPI driven IR LED device driver
+ */
+
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spi/spi.h>
+#include <media/rc-core.h>
+
+#define IR_SPI_DRIVER_NAME "ir-spi"
+
+/* pulse value for different duty cycles */
+#define IR_SPI_PULSE_DC_50 0xff00
+#define IR_SPI_PULSE_DC_60 0xfc00
+#define IR_SPI_PULSE_DC_70 0xf800
+#define IR_SPI_PULSE_DC_75 0xf000
+#define IR_SPI_PULSE_DC_80 0xc000
+#define IR_SPI_PULSE_DC_90 0x8000
+
+#define IR_SPI_DEFAULT_FREQUENCY 38000
+#define IR_SPI_BIT_PER_WORD 8
+#define IR_SPI_MAX_BUFSIZE 4096
+
+struct ir_spi_data {
+ u32 freq;
+ u8 duty_cycle;
+ bool negated;
+
+ u16 tx_buf[IR_SPI_MAX_BUFSIZE];
+ u16 pulse;
+ u16 space;
+
+ struct rc_dev *rc;
+ struct spi_device *spi;
+ struct regulator *regulator;
+};
+
+static int ir_spi_tx(struct rc_dev *dev,
+ unsigned int *buffer, unsigned int count)
+{
+ int i;
+ int ret;
+ unsigned int len = 0;
+ struct ir_spi_data *idata = dev->priv;
+ struct spi_transfer xfer;
+
+ /* convert the pulse/space signal to raw binary signal */
+ for (i = 0; i < count; i++) {
+ int j;
+ u16 val = ((i+1) % 2) ? idata->pulse : idata->space;
+
+ if (len + buffer[i] >= IR_SPI_MAX_BUFSIZE)
+ return -EINVAL;
+
+ /*
+ * the first value in buffer is a pulse, so that 0, 2, 4, ...
+ * contain a pulse duration. On the contrary, 1, 3, 5, ...
+ * contain a space duration.
+ */
+ val = (i % 2) ? idata->space : idata->pulse;
+ for (j = 0; j < buffer[i]; j++)
+ idata->tx_buf[len++] = val;
+ }
+
+ memset(&xfer, 0, sizeof(xfer));
+
+ xfer.speed_hz = idata->freq;
+ xfer.len = len * sizeof(*idata->tx_buf);
+ xfer.tx_buf = idata->tx_buf;
+
+ ret = regulator_enable(idata->regulator);
+ if (ret)
+ return ret;
+
+ ret = spi_sync_transfer(idata->spi, &xfer, 1);
+ if (ret)
+ dev_err(&idata->spi->dev, "unable to deliver the signal\n");
+
+ regulator_disable(idata->regulator);
+
+ return ret ? ret : count;
+}
+
+static int ir_spi_set_tx_carrier(struct rc_dev *dev, u32 carrier)
+{
+ struct ir_spi_data *idata = dev->priv;
+
+ if (!carrier)
+ return -EINVAL;
+
+ idata->freq = carrier;
+
+ return 0;
+}
+
+static int ir_spi_set_duty_cycle(struct rc_dev *dev, u32 duty_cycle)
+{
+ struct ir_spi_data *idata = dev->priv;
+
+ if (duty_cycle >= 90)
+ idata->pulse = IR_SPI_PULSE_DC_90;
+ else if (duty_cycle >= 80)
+ idata->pulse = IR_SPI_PULSE_DC_80;
+ else if (duty_cycle >= 75)
+ idata->pulse = IR_SPI_PULSE_DC_75;
+ else if (duty_cycle >= 70)
+ idata->pulse = IR_SPI_PULSE_DC_70;
+ else if (duty_cycle >= 60)
+ idata->pulse = IR_SPI_PULSE_DC_60;
+ else
+ idata->pulse = IR_SPI_PULSE_DC_50;
+
+ if (idata->negated) {
+ idata->pulse = ~idata->pulse;
+ idata->space = 0xffff;
+ } else {
+ idata->space = 0;
+ }
+
+ return 0;
+}
+
+static int ir_spi_probe(struct spi_device *spi)
+{
+ int ret;
+ u8 dc;
+ struct ir_spi_data *idata;
+
+ idata = devm_kzalloc(&spi->dev, sizeof(*idata), GFP_KERNEL);
+ if (!idata)
+ return -ENOMEM;
+
+ idata->regulator = devm_regulator_get(&spi->dev, "irda_regulator");
+ if (IS_ERR(idata->regulator))
+ return PTR_ERR(idata->regulator);
+
+ idata->rc = rc_allocate_device(RC_DRIVER_IR_RAW_TX);
+ if (!idata->rc)
+ return -ENOMEM;
+
+ idata->rc->tx_ir = ir_spi_tx;
+ idata->rc->s_tx_carrier = ir_spi_set_tx_carrier;
+ idata->rc->s_tx_duty_cycle = ir_spi_set_duty_cycle;
+ idata->rc->driver_name = IR_SPI_DRIVER_NAME;
+ idata->rc->priv = idata;
+ idata->spi = spi;
+
+ idata->negated = of_property_read_bool(spi->dev.of_node,
+ "led-active-low");
+ ret = of_property_read_u8(spi->dev.of_node, "duty-cycle", &dc);
+ if (ret)
+ dc = 50;
+
+ ret = ir_spi_set_duty_cycle(idata->rc, dc);
+ if (ret)
+ return ret;
+
+ idata->freq = IR_SPI_DEFAULT_FREQUENCY;
+
+ ret = rc_register_device(idata->rc);
+ if (ret)
+ rc_free_device(idata->rc);
+
+ return ret;
+}
+
+static int ir_spi_remove(struct spi_device *spi)
+{
+ struct ir_spi_data *idata = spi_get_drvdata(spi);
+
+ rc_unregister_device(idata->rc);
+
+ return 0;
+}
+
+static const struct of_device_id ir_spi_of_match[] = {
+ { .compatible = "ir-spi-led" },
+ {},
+};
+
+static struct spi_driver ir_spi_driver = {
+ .probe = ir_spi_probe,
+ .remove = ir_spi_remove,
+ .driver = {
+ .name = IR_SPI_DRIVER_NAME,
+ .of_match_table = ir_spi_of_match,
+ },
+};
+
+module_spi_driver(ir_spi_driver);
+
+MODULE_AUTHOR("Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("SPI IR LED");
+MODULE_LICENSE("GPL v2");
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
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