* Re: [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Sekhar Nori @ 2016-11-23 11:12 UTC (permalink / raw)
To: David Lechner, Linus Walleij, Rob Herring, Mark Rutland,
Kevin Hilman
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Axel Haslam,
Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <1479871767-20160-4-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
> This SoC has a separate pin controller for configuring pullup/pulldown
> bias on groups of pins.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
> arch/arm/boot/dts/da850.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 8945815..1c0224c 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -210,6 +210,11 @@
> };
>
> };
> + pinconf: pin-controller@22c00c {
> + compatible = "ti,da850-pupd";
> + reg = <0x22c00c 0x8>;
> + status = "disabled";
> + };
Can you please place this below the i2c1 node. I am trying to keep the
nodes sorted by unit address. I know thats broken in many places today,
but lets add the new ones where they should eventually end up.
Thanks,
Sekhar
--
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 0/3] TI DA850/OMAP-L138/AM18x pinconf
From: Sekhar Nori @ 2016-11-23 11:17 UTC (permalink / raw)
To: David Lechner, Linus Walleij, Rob Herring, Mark Rutland,
Kevin Hilman
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
Axel Haslam, Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <1479871767-20160-1-git-send-email-david@lechnology.com>
On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
> This series adds a new driver and DT bindings for TI DA850/OMAP-L138/AM18x
> pinconf (bias pullup/pulldown).
>
> The motivation for this series is LEGO MINDSTORMS EV3 support. It needs most,
> if not all, internal pullup/down resistors disabled in order to work correctly.
This looks really neat to my non-pinconf trained eyes. I have sent some
minor comments. But apart from that:
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
3/3 should go through my tree. If the driver patches are going to get
queued for v4.10, I can queue the DTS portion through my tree.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 0/2] power: supply: add sbs-charger driver
From: Nicolas Saenz Julienne @ 2016-11-23 11:20 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland
Cc: linux-kernel, devicetree, linux-pm, nicolas.saenz
Hi,
This series adds support for all SBS compatible battery chargers, as defined
here: http://sbs-forum.org/specs/sbc110.pdf.
The first patch changes the sbs-battery device name in order to be able to
create a proper supplier/supplied relation between the two of them.
The second introduces the driver.
Regards,
Nicolas
changes since v1:
- added dt bindings
- updated driver with Sebastian's comments
- s/Nicola/Nicolas/ in commits
Nicolas Saenz Julienne (2):
power: supply: add sbs-charger driver
dt-bindings: power: add bindings for sbs-charger
.../bindings/power/supply/sbs_sbs-charger.txt | 22 ++
drivers/power/supply/Kconfig | 6 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/sbs-charger.c | 264 +++++++++++++++++++++
4 files changed, 293 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt
create mode 100644 drivers/power/supply/sbs-charger.c
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] power: supply: add sbs-charger driver
From: Nicolas Saenz Julienne @ 2016-11-23 11:20 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland
Cc: linux-kernel, devicetree, linux-pm, nicolas.saenz
In-Reply-To: <1479900044-19270-1-git-send-email-nicolas.saenz@prodys.net>
This adds support for sbs-charger compilant chips as defined here:
http://sbs-forum.org/specs/sbc110.pdf
This was tested on a arm board connected to an LTC41000 battery charger
chip.
Signed-off-by: Nicolas Saenz Julienne <nicolas.saenz@prodys.net>
---
v1 -> v2:
- add spec link in header
- use proper gpio/interrupt interface
- update regmap configuration (max register & endianness)
- dropped oldschool .supplied_to assignments
- use devm_* APIs
drivers/power/supply/Kconfig | 6 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/sbs-charger.c | 264 +++++++++++++++++++++++++++++++++++++
3 files changed, 271 insertions(+)
create mode 100644 drivers/power/supply/sbs-charger.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 76806a0..42877ff 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -164,6 +164,12 @@ config BATTERY_SBS
Say Y to include support for SBS battery driver for SBS-compliant
gas gauges.
+config CHARGER_SBS
+ tristate "SBS Compliant charger"
+ depends on I2C
+ help
+ Say Y to include support for SBS compilant battery chargers.
+
config BATTERY_BQ27XXX
tristate "BQ27xxx battery driver"
help
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 36c599d..06d9ef5 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_BATTERY_COLLIE) += collie_battery.o
obj-$(CONFIG_BATTERY_IPAQ_MICRO) += ipaq_micro_battery.o
obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
obj-$(CONFIG_BATTERY_SBS) += sbs-battery.o
+obj-$(CONFIG_CHARGER_SBS) += sbs-charger.o
obj-$(CONFIG_BATTERY_BQ27XXX) += bq27xxx_battery.o
obj-$(CONFIG_BATTERY_BQ27XXX_I2C) += bq27xxx_battery_i2c.o
obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
diff --git a/drivers/power/supply/sbs-charger.c b/drivers/power/supply/sbs-charger.c
new file mode 100644
index 0000000..016dd6b
--- /dev/null
+++ b/drivers/power/supply/sbs-charger.c
@@ -0,0 +1,264 @@
+/*
+ * Copyright (c) 2016, Prodys S.L.
+ *
+ * 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 adds support for sbs-charger compilant chips as defined here:
+ * http://sbs-forum.org/specs/sbc110.pdf
+ *
+ * Implemetation based on sbs-battery.c
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/err.h>
+#include <linux/power_supply.h>
+#include <linux/i2c.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/gpio.h>
+#include <linux/regmap.h>
+#include <linux/of_gpio.h>
+#include <linux/bitops.h>
+
+#define SBS_CHARGER_REG_STATUS 0x13
+#define SBS_CHARGER_REG_ALARM_WARNING 0x16
+
+#define SBS_CHARGER_STATUS_CHARGE_INHIBITED BIT(1)
+#define SBS_CHARGER_STATUS_RES_COLD BIT(9)
+#define SBS_CHARGER_STATUS_RES_HOT BIT(10)
+#define SBS_CHARGER_STATUS_BATTERY_PRESENT BIT(14)
+#define SBS_CHARGER_STATUS_AC_PRESENT BIT(15)
+
+#define SBS_CHARGER_POLL_TIME 500
+
+struct sbs_info {
+ struct i2c_client *client;
+ struct power_supply *power_supply;
+ struct regmap *regmap;
+ struct delayed_work work;
+ unsigned int last_state;
+};
+
+static int sbs_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct sbs_info *chip = power_supply_get_drvdata(psy);
+ unsigned int reg;
+
+ reg = chip->last_state;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = !!(reg & SBS_CHARGER_STATUS_BATTERY_PRESENT);
+ break;
+
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = !!(reg & SBS_CHARGER_STATUS_AC_PRESENT);
+ break;
+
+ case POWER_SUPPLY_PROP_STATUS:
+ val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
+
+ if (!(reg & SBS_CHARGER_STATUS_BATTERY_PRESENT))
+ val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ else if (reg & SBS_CHARGER_STATUS_AC_PRESENT &&
+ !(reg & SBS_CHARGER_STATUS_CHARGE_INHIBITED))
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+
+ break;
+
+ case POWER_SUPPLY_PROP_HEALTH:
+ if (reg & SBS_CHARGER_STATUS_RES_COLD)
+ val->intval = POWER_SUPPLY_HEALTH_COLD;
+ if (reg & SBS_CHARGER_STATUS_RES_HOT)
+ val->intval = POWER_SUPPLY_HEALTH_OVERHEAT;
+ else
+ val->intval = POWER_SUPPLY_HEALTH_GOOD;
+
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int sbs_check_state(struct sbs_info *chip)
+{
+ unsigned int reg;
+ int ret;
+
+ ret = regmap_read(chip->regmap, SBS_CHARGER_REG_STATUS, ®);
+ if (!ret && reg != chip->last_state) {
+ chip->last_state = reg;
+ power_supply_changed(chip->power_supply);
+ return 1;
+ }
+
+ return 0;
+}
+
+static void sbs_delayed_work(struct work_struct *work)
+{
+ struct sbs_info *chip = container_of(work, struct sbs_info, work.work);
+
+ sbs_check_state(chip);
+
+ schedule_delayed_work(&chip->work,
+ msecs_to_jiffies(SBS_CHARGER_POLL_TIME));
+}
+
+static irqreturn_t sbs_irq_thread(int irq, void *data)
+{
+ struct sbs_info *chip = data;
+ int ret;
+
+ ret = sbs_check_state(chip);
+
+ return ret ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static enum power_supply_property sbs_properties[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_HEALTH,
+};
+
+static bool sbs_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case SBS_CHARGER_REG_STATUS:
+ return true;
+ }
+
+ return false;
+}
+
+static const struct regmap_config sbs_regmap = {
+ .reg_bits = 8,
+ .val_bits = 16,
+ .max_register = SBS_CHARGER_REG_ALARM_WARNING,
+ .volatile_reg = sbs_volatile_reg,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE, /* since based on SMBus */
+};
+
+static const struct power_supply_desc sbs_desc = {
+ .name = "sbs-charger",
+ .type = POWER_SUPPLY_TYPE_MAINS,
+ .properties = sbs_properties,
+ .num_properties = ARRAY_SIZE(sbs_properties),
+ .get_property = sbs_get_property,
+};
+
+static int sbs_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct power_supply_config psy_cfg = {};
+ struct sbs_info *chip;
+ int ret, val;
+
+ chip = devm_kzalloc(&client->dev, sizeof(struct sbs_info), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->client = client;
+ psy_cfg.of_node = client->dev.of_node;
+ psy_cfg.drv_data = chip;
+
+ i2c_set_clientdata(client, chip);
+
+ chip->regmap = devm_regmap_init_i2c(client, &sbs_regmap);
+ if (IS_ERR(chip->regmap))
+ return PTR_ERR(chip->regmap);
+
+ /*
+ * Before we register, we need to make sure we can actually talk
+ * to the battery.
+ */
+ ret = regmap_read(chip->regmap, SBS_CHARGER_REG_STATUS, &val);
+ if (ret) {
+ dev_err(&client->dev, "Failed to get device status\n");
+ return ret;
+ }
+ chip->last_state = val;
+
+ chip->power_supply = devm_power_supply_register(&client->dev, &sbs_desc,
+ &psy_cfg);
+ if (IS_ERR(chip->power_supply)) {
+ dev_err(&client->dev, "Failed to register power supply\n");
+ return PTR_ERR(chip->power_supply);
+ }
+
+ /*
+ * The sbs-charger spec doesn't impose the use of an interrupt. So in
+ * the case it wasn't provided we use polling in order get the charger's
+ * status.
+ */
+ if (client->irq) {
+ ret = devm_request_threaded_irq(&client->dev, client->irq,
+ NULL, sbs_irq_thread,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ dev_name(&client->dev), chip);
+ if (ret) {
+ dev_err(&client->dev, "Failed to request irq, %d\n", ret);
+ return ret;
+ }
+ } else {
+ INIT_DELAYED_WORK(&chip->work, sbs_delayed_work);
+ schedule_delayed_work(&chip->work,
+ msecs_to_jiffies(SBS_CHARGER_POLL_TIME));
+ }
+
+ dev_info(&client->dev,
+ "%s: smart charger device registered\n", client->name);
+
+ return 0;
+}
+
+static int sbs_remove(struct i2c_client *client)
+{
+ struct sbs_info *chip = i2c_get_clientdata(client);
+
+ cancel_delayed_work_sync(&chip->work);
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id sbs_dt_ids[] = {
+ { .compatible = "sbs,sbs-charger" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, sbs_dt_ids);
+#endif
+
+static const struct i2c_device_id sbs_id[] = {
+ { "sbs-charger", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, sbs_id);
+
+static struct i2c_driver sbs_driver = {
+ .probe = sbs_probe,
+ .remove = sbs_remove,
+ .id_table = sbs_id,
+ .driver = {
+ .name = "sbs-charger",
+ .of_match_table = of_match_ptr(sbs_dt_ids),
+ },
+};
+module_i2c_driver(sbs_driver);
+
+MODULE_AUTHOR("Nicolas Saenz Julienne <nicolassaenzj@gmail.com>");
+MODULE_DESCRIPTION("SBS smart charger driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: power: add bindings for sbs-charger
From: Nicolas Saenz Julienne @ 2016-11-23 11:20 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland
Cc: linux-kernel, devicetree, linux-pm, nicolas.saenz
In-Reply-To: <1479900044-19270-1-git-send-email-nicolas.saenz@prodys.net>
Adds device tree documentation for SBS charger compilant devices as defined
here: http://sbs-forum.org/specs/sbc110.pdf
Signed-off-by: Nicolas Saenz Julienne <nicolas.saenz@prodys.net>
---
.../bindings/power/supply/sbs_sbs-charger.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt
diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt
new file mode 100644
index 0000000..b18ee2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt
@@ -0,0 +1,22 @@
+SBS sbs-charger
+~~~~~~~~~~
+
+Required properties :
+ - compatible : "sbs,sbs-charger"
+
+Optional properties :
+- interrupt-parent: Should be the phandle for the interrupt controller. Use in
+ conjunction with "interrupts".
+- interrupts: Interrupt mapping for GPIO IRQ. Use in conjunction with
+ "interrupt-parent". If an interrupt is not provided the driver will switch
+ automatically to polling.
+
+Example:
+
+ ltc4100@9 {
+ compatible = "sbs,sbs-charger";
+ reg = <0x9>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ };
+
--
2.7.4
^ permalink raw reply related
* [PATCH 1/1] of: of_reserved_mem: Ensure cma reserved region not cross the low/high memory
From: Jason Liu @ 2016-11-23 11:37 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
labbott-H+wXaHxf7aLQT0dZR+AlfA,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Need ensure the cma reserved region not cross the low/high memory boundary
when using the dynamic allocation methond through device-tree, otherwise,
kernel will fail to boot up when cma reserved region cross how/high mem.
Signed-off-by: Jason Liu <jason.hui.liu-3arQi8VN3Tc@public.gmane.org>
Cc: Laura Abbott <labbott-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/of/of_reserved_mem.c | 42 +++++++++++++++++++++++++++++++----------
include/linux/of_reserved_mem.h | 3 ++-
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 366d8c3..852345a 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -31,11 +31,15 @@
#if defined(CONFIG_HAVE_MEMBLOCK)
#include <linux/memblock.h>
-int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
- phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
- phys_addr_t *res_base)
+int __init __weak early_init_dt_alloc_reserved_memory_arch(unsigned long node,
+ phys_addr_t size, phys_addr_t align, phys_addr_t start, phys_addr_t end,
+ bool nomap, phys_addr_t *res_base)
{
phys_addr_t base;
+ phys_addr_t highmem_start;
+
+ highmem_start = __pa(high_memory - 1) + 1;
+
/*
* We use __memblock_alloc_base() because memblock_alloc_base()
* panic()s on allocation failure.
@@ -53,15 +57,33 @@ int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
return -ENOMEM;
}
+ /*
+ * Sanity check for the cma reserved region:If the reserved region
+ * crosses the low/high memory boundary, try to fix it up and then
+ * fall back to allocate the cma region from the low mememory space.
+ */
+
+ if (IS_ENABLED(CONFIG_CMA)
+ && of_flat_dt_is_compatible(node, "shared-dma-pool")
+ && of_get_flat_dt_prop(node, "reusable", NULL) && !nomap) {
+ if (base < highmem_start && (base + size) > highmem_start) {
+ memblock_free(base, size);
+ base = memblock_alloc_range(size, align, start,
+ highmem_start, MEMBLOCK_NONE);
+ if (!base)
+ return -ENOMEM;
+ }
+ }
+
*res_base = base;
if (nomap)
return memblock_remove(base, size);
return 0;
}
#else
-int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
- phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
- phys_addr_t *res_base)
+int __init __weak early_init_dt_alloc_reserved_memory_arch(unsigned long node,
+ phys_addr_t size, phys_addr_t align, phys_addr_t start, phys_addr_t end,
+ bool nomap, phys_addr_t *res_base)
{
pr_err("Reserved memory not supported, ignoring region 0x%llx%s\n",
size, nomap ? " (nomap)" : "");
@@ -155,8 +177,8 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
end = start + dt_mem_next_cell(dt_root_size_cells,
&prop);
- ret = early_init_dt_alloc_reserved_memory_arch(size,
- align, start, end, nomap, &base);
+ ret = early_init_dt_alloc_reserved_memory_arch(node,
+ size, align, start, end, nomap, &base);
if (ret == 0) {
pr_debug("allocated memory for '%s' node: base %pa, size %ld MiB\n",
uname, &base,
@@ -167,8 +189,8 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
}
} else {
- ret = early_init_dt_alloc_reserved_memory_arch(size, align,
- 0, 0, nomap, &base);
+ ret = early_init_dt_alloc_reserved_memory_arch(node,
+ size, align, 0, 0, nomap, &base);
if (ret == 0)
pr_debug("allocated memory for '%s' node: base %pa, size %ld MiB\n",
uname, &base, (unsigned long)size / SZ_1M);
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index f8e1992..a6ee451 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -34,7 +34,8 @@ int of_reserved_mem_device_init_by_idx(struct device *dev,
struct device_node *np, int idx);
void of_reserved_mem_device_release(struct device *dev);
-int early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
+int early_init_dt_alloc_reserved_memory_arch(unsigned long node,
+ phys_addr_t size,
phys_addr_t align,
phys_addr_t start,
phys_addr_t end,
--
1.8.3.2
--
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
* Re: [PATCH] dt-bindings: mfd: Improve readability for TPS65217 interrupt sources
From: Milo Kim @ 2016-11-23 11:38 UTC (permalink / raw)
To: Lee Jones
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w, Tony Lindgren,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Robert Nelson
In-Reply-To: <20161122155759.GG10134-Re9dqnLqz4GzQB+pC5nmwQ@public.gmane.org>
On 11/23/2016 12:57 AM, Lee Jones wrote:
>> pwrbutton {
>> > - interrupts = <TPS65217_IRQ_PB>;
>> > + interrupts = <TPS65217_IRQ_PUSHBUTTON>;
> Push button or power button?
>
According to the datasheet, push button interrupt is correct.
http://www.ti.com/lit/ds/symlink/tps65217.pdf
This is used for a power button input in Beaglebone boards. In other
words, the power button is one of push button usages.
So, I'd like to keep general name for the interrupt.
Best regards,
Milo
--
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 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Laxman Dewangan @ 2016-11-23 11:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Stephen Warren,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Mark Rutland, Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Joe Perches,
Jon Hunter
In-Reply-To: <CACRpkdZK34QfbSBJvshfZekk5TJBU5sZog-9uszLSmFPOGJgiw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tuesday 22 November 2016 06:28 PM, Linus Walleij wrote:
> On Tue, Nov 22, 2016 at 11:20 AM, Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>
>> + rinfo->regulator = devm_regulator_get_optional(dev,
>> + soc_data->cfg[i].vsupply);
> Please just use devm_regulator_get().
>
> As has been discussed at lenth elsewhere "optional" in regulator_get_optional
> does *not* mean "software optional", it means "hardware optional".
>
> Such as a terminal that may have a voltage connected or not be
> connected to anything at all.
>
> If the system does not define a regulator you will anyway get a
> dummy regulator.
>
The issue with dummy regulator is that the other regulator APIs with
dummy regulator fails.
Once we get the dummy regulator, there is no way to know whether the
returned regulator is actual or dummy and when calling the
regulator_get_voltage() it failed.
[ 2.917176] pinctrl-t210-io-pad.0 supply vddio-audio-hv not found,
using dummy regulator
[ 2.925510] pinctrl-tegra-io-pad pinctrl-t210-io-pad.0: Failed to get
voltage for rail vddio-aud2
Here, we need the regulator handle which can support the other regulator
APIs.
In some of platforms, we do not use some of the io-pins and on this
case, we do not connect the IO rail supply for these pins. So this is
like a hardware optional.
If the IO pins are used then it need to have the proper regulator handle.
Missing regulator handle on DT will be like that IO pads are not used.
--
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 0/7] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2016-11-23 11:47 UTC (permalink / raw)
To: Lars-Peter Clausen, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald-Stadler, Jonathan Corbet,
Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b132143c-259b-6ed2-58c5-b223cc2e72df-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
On 2016-11-22 21:58, Lars-Peter Clausen wrote:
> On 11/21/2016 02:17 PM, Peter Rosin wrote:
> [...]
>> I have a piece of hardware that is using the same 3 GPIO pins
>> to control four 8-way muxes. Three of them control ADC lines
>> to an ADS1015 chip with an iio driver, and the last one
>> controls the SDA line of an i2c bus. We have some deployed
>> code to handle this, but you do not want to see it or ever
>> hear about it. I'm not sure why I even mention it. Anyway,
>> the situation has nagged me to no end for quite some time.
>>
>> So, after first getting more intimate with the i2c muxing code
>> and later discovering the drivers/iio/inkern.c file and
>> writing a couple of drivers making use of it, I came up with
>> what I think is an acceptable solution; add a generic mux
>> controller driver (and subsystem) that is shared between all
>> instances, and combine that with an iio mux driver and a new
>> generic i2c mux driver. The new i2c mux I called "simple"
>> since it is only hooking the i2c muxing and the new mux
>> controller (much like the alsa simple card driver does for ASoC).
>
> While abstracting this properly is all nice and good and the way it should
> be done, but it also adds a lot of complexity and the devicetree adds a lot
> of restrictions on what can actually be represented.
This is a characterization without any specifics. But is the
characterization true? You have two complaints, complexity
and restrictions with bindings.
> There is a certain point where the fabric on a PCB becomes so complex that
> it deserves to be a device on its own (like the audio fabric drivers).
> Especially when the hardware is built with a certain application in mind and
> the driver is supposed to impose policy which reflects this application. The
> latter can often not properly be described with the primitives the
> devicetree can offer.
>
> And I think your setup is very borderline what can be done in a declarative
> way only and it adds a lot of complexity over a more imperative solution in
> form of a driver. I think it is worth investigating about having a driver
> that is specific to your fabric and handles the interdependencies of the
> discrete components.
So, there are three "new" concepts:
1. Sticking a mux in front of an AD-converter. That's not all that
novel, nor complex. Quite the opposite, I'd say. In fact, I find it
a bit amazing that there is no in-kernel support for it.
2. Reusing the same GPIO-pins to drive different muxes. There are
obviously chips that work this way (as Jonathan pointed out) and
these will at some point get used in Linux devices. I guess they
already are used, but that people handle them in userspace. Or
something? If this is complex, which I question, it will still need
support at some point. At least that's what I believe.
3. Using the same GPIO pins to mux things handled by different
subsystems. Right, this is a bit crazy, and I'd rather not have this
requirement, but this HW is what it is so I'll need to handle it in
some way. It is also what stops me from falling back to a userspace
solution, which is probably connected to why #1 and #2 is not supported
by the kernel; everybody probably does muxing in userspace. Which is
not necessarily a good idea, nor how it's supposed to be done...
So, the only thing that's out of the ordinary (as I see it), is #3.
The question that then needs an answer is how the in-kernel solution
for #1 and #2 would look if we do not consider #3.
And I claim that the desired solution to #1 and #2 is pretty close
to my proposal.
A. You do not want mux-controller drivers in every subsystem that
needs them.
B. You do not want every mux-consumer to know the specifics of how to
operate every kind of mux; there are muxes that are not controlled
with GPIO pins...
C. When you implement muxing in a subsystem, there will in some cases
be a need to handle parallel muxing, where there is a need to share
mux-controllers.
It just feels right to separate out the mux-controller and refer to
it from where a mux is needed. It solves #1 and #2. And, of course,
as a bonus #3 is also solved. But my bias is obvious.
And that leads us to the restrictions with the bindings. And the same
thing happens; the solution for #2 also solves #3.
So how do you refer to a mux-controller from where it's needed? My
first proposal used a dt phandle, for the second round I put them in
the parent node. It would be super if it was possible for the mux-
consumer to create the mux-controller device from the same dt
node that is already bound to the mux-consumer. The problem is that
the mux-consumer should not hard-code which mux-controller device it
should create. The best I can think of is some kind of 'mux-compatible'
attribute, that works like the standard 'compatible' attribute. That
would simplify the bindings for the normal case (#1) where the mux-
controller isn't shared (#2 and #3). Maybe it's possible to fix this
issue somehow? I simply don't know?
Cheers,
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] of: base: add support to get machine compatible string
From: Sekhar Nori @ 2016-11-23 11:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King, LKML,
arm-soc, linux-drm, linux-devicetree, Jyri Sarha, Tomi Valkeinen,
David Airlie, Laurent Pinchart, Robin Murphy
In-Reply-To: <2a644b8c-d91e-5ab1-200b-00f749a36307-5wv7dgnIgG8@public.gmane.org>
On Wednesday 23 November 2016 03:35 PM, Sudeep Holla wrote:
>
>
> On 23/11/16 07:49, Sekhar Nori wrote:
>> On Tuesday 22 November 2016 09:16 PM, Sudeep Holla wrote:
>>> Hi Sekhar,
>>>
>>> On 22/11/16 15:06, Sekhar Nori wrote:
>>>> Hi Sudeep,
>>>>
>>>> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>>>> Add a function allowing to retrieve the compatible string of the root
>>>>>> node of the device tree.
>>>>>>
>>>>>
>>>>> Rob has queued [1] and it's in -next today. You can reuse that if you
>>>>> are planning to target this for v4.11 or just use open coding in your
>>>>> driver for v4.10 and target this move for v4.11 to avoid cross tree
>>>>> dependencies as I already mentioned in your previous thread.
>>>>
>>>> I dont have your original patch in my mailbox, but I wonder if
>>>> returning a pointer to property string for a node whose reference has
>>>> already been released is safe to do? Probably not an issue for the root
>>>> node, but still feels counter-intuitive.
>>>>
>>>
>>> I am not sure if I understand the issue here. Are you referring a case
>>> where of_root is freed ?
>>
>> Yes, right, thats what I was hinting at. Since you are giving up the
>> reference to the device node before the function returns, the user can
>> be left with a dangling reference.
>>
>
> Yes I agree.
So, the if(!of_node_get()) is just an expensive NULL pointer check. I think
it is better to be explicit about it by not using of_node_get/put() at all.
How about:
+int of_machine_get_model_name(const char **model)
+{
+ int error;
+
+ if (!of_root)
+ return -EINVAL;
+
+ error = of_property_read_string(of_root, "model", model);
+ if (error)
+ error = of_property_read_string_index(of_root, "compatible",
+ 0, model);
+ return error;
+}
+EXPORT_SYMBOL(of_machine_get_model_name);
I know the patch is already in -next so I guess it depends on how strongly
Rob feels about this.
Thanks,
Sekhar
--
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] dt-bindings: mfd: Improve readability for TPS65217 interrupt sources
From: Arnd Bergmann @ 2016-11-23 11:51 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Tony Lindgren, Robert Nelson, linux-kernel, bcousson,
Milo Kim, linux-omap, Lee Jones
In-Reply-To: <bd4944d8-3cef-b3f7-4fba-6de590493047@gmail.com>
On Wednesday, November 23, 2016 8:38:00 PM CET Milo Kim wrote:
> On 11/23/2016 12:57 AM, Lee Jones wrote:
> >> pwrbutton {
> >> > - interrupts = <TPS65217_IRQ_PB>;
> >> > + interrupts = <TPS65217_IRQ_PUSHBUTTON>;
> > Push button or power button?
> >
>
> According to the datasheet, push button interrupt is correct.
>
> http://www.ti.com/lit/ds/symlink/tps65217.pdf
>
> This is used for a power button input in Beaglebone boards. In other
> words, the power button is one of push button usages.
>
> So, I'd like to keep general name for the interrupt.
Ah, the numbers come from the data sheet. Please just remove the
header then, there is no need to keep them as an ABI, in particular
when the driver doesn't even include that header today.
I see you even have names for them in the node:
charger {
- interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
+ interrupts = <TPS65217_IRQ_AC_POWER>, <TPS65217_IRQ_USB_POWER>;
interrupts-names = "AC", "USB";
status = "okay";
What matters here is the binding documentation in
Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
Please fix that instead to mandate that the two interrupts are
required, what their functions are, and what the interrupt-names
(not interrupts-names) property must list.
Arnd
^ permalink raw reply
* Re: [PATCH 1/3] of: base: add support to get machine compatible string
From: Sudeep Holla @ 2016-11-23 12:07 UTC (permalink / raw)
To: Sekhar Nori
Cc: Mark Rutland, linux-devicetree, Tomi Valkeinen, David Airlie,
Kevin Hilman, Michael Turquette, Russell King, linux-drm, LKML,
Bartosz Golaszewski, Rob Herring, Jyri Sarha, Sudeep Holla,
Robin Murphy, Frank Rowand, arm-soc, Laurent Pinchart
In-Reply-To: <ff1ea88a-87c6-6721-8e63-ddb05900cc58@ti.com>
On 23/11/16 11:47, Sekhar Nori wrote:
> On Wednesday 23 November 2016 03:35 PM, Sudeep Holla wrote:
>>
>>
>> On 23/11/16 07:49, Sekhar Nori wrote:
>>> On Tuesday 22 November 2016 09:16 PM, Sudeep Holla wrote:
>>>> Hi Sekhar,
>>>>
>>>> On 22/11/16 15:06, Sekhar Nori wrote:
>>>>> Hi Sudeep,
>>>>>
>>>>> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>>>>> Add a function allowing to retrieve the compatible string of the root
>>>>>>> node of the device tree.
>>>>>>>
>>>>>>
>>>>>> Rob has queued [1] and it's in -next today. You can reuse that if you
>>>>>> are planning to target this for v4.11 or just use open coding in your
>>>>>> driver for v4.10 and target this move for v4.11 to avoid cross tree
>>>>>> dependencies as I already mentioned in your previous thread.
>>>>>
>>>>> I dont have your original patch in my mailbox, but I wonder if
>>>>> returning a pointer to property string for a node whose reference has
>>>>> already been released is safe to do? Probably not an issue for the root
>>>>> node, but still feels counter-intuitive.
>>>>>
>>>>
>>>> I am not sure if I understand the issue here. Are you referring a case
>>>> where of_root is freed ?
>>>
>>> Yes, right, thats what I was hinting at. Since you are giving up the
>>> reference to the device node before the function returns, the user can
>>> be left with a dangling reference.
>>>
>>
>> Yes I agree.
>
> So, the if(!of_node_get()) is just an expensive NULL pointer check. I think
> it is better to be explicit about it by not using of_node_get/put() at all.
> How about:
>
Are we planning to use this in any time sensitive paths? Anyways I am
fine removing them.
> +int of_machine_get_model_name(const char **model)
> +{
> + int error;
> +
> + if (!of_root)
> + return -EINVAL;
> +
> + error = of_property_read_string(of_root, "model", model);
> + if (error)
> + error = of_property_read_string_index(of_root, "compatible",
> + 0, model);
> + return error;
> +}
> +EXPORT_SYMBOL(of_machine_get_model_name);
>
> I know the patch is already in -next so I guess it depends on how strongly
> Rob feels about this.
Frank expressed his concerns and it may be reverted.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/3] of: base: add support to get machine compatible string
From: Sekhar Nori @ 2016-11-23 12:13 UTC (permalink / raw)
To: Sudeep Holla
Cc: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King, LKML,
arm-soc, linux-drm, linux-devicetree, Jyri Sarha, Tomi Valkeinen,
David Airlie, Laurent Pinchart, Robin Murphy
In-Reply-To: <f0ba1a7a-8948-21c3-8a96-d46bf105bb7e-5wv7dgnIgG8@public.gmane.org>
On Wednesday 23 November 2016 05:37 PM, Sudeep Holla wrote:
>> So, the if(!of_node_get()) is just an expensive NULL pointer check. I
>> think
>> it is better to be explicit about it by not using of_node_get/put() at
>> all.
>> How about:
>>
>
> Are we planning to use this in any time sensitive paths? Anyways I am
> fine removing them.
Not worried about the time taken as much as it serving as a bad example
and getting carried over to other places where the impact might actually
be real.
>
>> +int of_machine_get_model_name(const char **model)
>> +{
>> + int error;
>> +
>> + if (!of_root)
>> + return -EINVAL;
>> +
>> + error = of_property_read_string(of_root, "model", model);
>> + if (error)
>> + error = of_property_read_string_index(of_root,
>> "compatible",
>> + 0, model);
>> + return error;
>> +}
>> +EXPORT_SYMBOL(of_machine_get_model_name);
>>
>> I know the patch is already in -next so I guess it depends on how
>> strongly
>> Rob feels about this.
>
> Frank expressed his concerns and it may be reverted.
Didn't notice that. I will check that thread. Thanks!
Regards,
Sekhar
--
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
* [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm, Rob Herring,
Mark Rutland, Ramesh Shanmugasundaram, linux-renesas-soc,
devicetree, linux-arm-kernel, linux-can, Chris Paterson
This patch series adds CAN and CAN FD support to the r8a7796.
Based on renesas-devel-20161122-v4.9-rc6.
Chris Paterson (3):
arm64: dts: r8a7796: Add CAN external clock support
arm64: dts: r8a7796: Add CAN support
arm64: dts: r8a7796: Add CAN FD support
.../devicetree/bindings/net/can/rcar_can.txt | 12 +++--
.../devicetree/bindings/net/can/rcar_canfd.txt | 12 +++--
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 61 ++++++++++++++++++++++
3 files changed, 75 insertions(+), 10 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] arm64: dts: r8a7796: Add CAN external clock support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland, Ramesh Shanmugasundaram,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chris Paterson
Adds external CAN clock node for r8a7796. This clock can be used as
fCAN clock of CAN and CAN FD controller.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 41a050d..91d716e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -69,6 +69,13 @@
clock-frequency = <0>;
};
+ /* External CAN clock - to be overridden by boards that provide it */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
/* External SCIF clock - to be overridden by boards that provide it */
scif_clk: scif {
compatible = "fixed-clock";
--
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
* [PATCH 2/3] arm64: dts: r8a7796: Add CAN support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm, Rob Herring,
Mark Rutland, Ramesh Shanmugasundaram, linux-renesas-soc,
devicetree, linux-arm-kernel, linux-can, Chris Paterson
Adds CAN controller nodes for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
---
.../devicetree/bindings/net/can/rcar_can.txt | 12 +++++----
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++++++++++++++++++++++
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 8d40ab2..06bb7cc 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -10,6 +10,7 @@ Required properties:
"renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC.
"renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
+ "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
"renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
@@ -24,11 +25,12 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
-Required properties for "renesas,can-r8a7795" compatible:
-In R8A7795 SoC, "clkp2" can be CANFD clock. This is a div6 clock and can be
-used by both CAN and CAN FD controller at the same time. It needs to be scaled
-to maximum frequency if any of these controllers use it. This is done using
-the below properties.
+Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
+compatible:
+In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
+and can be used by both CAN and CAN FD controller at the same time. It needs to
+be scaled to maximum frequency if any of these controllers use it. This is done
+using the below properties:
- assigned-clocks: phandle of clkp2(CANFD) clock.
- assigned-clock-rates: maximum frequency of this clock.
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 91d716e..95857fc 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -362,6 +362,36 @@
status = "disabled";
};
+ can0: can@e6c30000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c30000 0 0x1000>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 916>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ can1: can@e6c38000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c38000 0 0x1000>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 915>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: r8a7796: Add CAN FD support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm, Rob Herring,
Mark Rutland, Ramesh Shanmugasundaram, linux-renesas-soc,
devicetree, linux-arm-kernel, linux-can, Chris Paterson
Adds CAN FD controller node for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
---
.../devicetree/bindings/net/can/rcar_canfd.txt | 12 ++++++-----
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 22a6f10..788f273 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible: Must contain one or more of the following:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
+ - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
@@ -23,11 +24,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each
child node supports the "status" property only, which is used to
enable/disable the respective channel.
-Required properties for "renesas,r8a7795-canfd" compatible:
-In R8A7795 SoC, canfd clock is a div6 clock and can be used by both CAN
-and CAN FD controller at the same time. It needs to be scaled to maximum
-frequency if any of these controllers use it. This is done using the
-below properties.
+Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd"
+compatible:
+In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by both
+CAN and CAN FD controller at the same time. It needs to be scaled to maximum
+frequency if any of these controllers use it. This is done using the below
+properties:
- assigned-clocks: phandle of canfd clock.
- assigned-clock-rates: maximum frequency of this clock.
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 95857fc..c069d77 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -392,6 +392,30 @@
status = "disabled";
};
+ canfd: can@e66c0000 {
+ compatible = "renesas,r8a7796-canfd",
+ "renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c0000 0 0x8000>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 914>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
+ };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/3] of: base: add support to get machine compatible string
From: Sudeep Holla @ 2016-11-23 12:15 UTC (permalink / raw)
To: Sekhar Nori
Cc: Sudeep Holla, Bartosz Golaszewski, Kevin Hilman,
Michael Turquette, Rob Herring, Frank Rowand, Mark Rutland,
Peter Ujfalusi, Russell King, LKML, arm-soc, linux-drm,
linux-devicetree, Jyri Sarha, Tomi Valkeinen, David Airlie,
Laurent Pinchart, Robin Murphy
In-Reply-To: <11467504-c700-cbfa-a945-be9ec8776144-l0cyMroinI0@public.gmane.org>
On 23/11/16 12:13, Sekhar Nori wrote:
> On Wednesday 23 November 2016 05:37 PM, Sudeep Holla wrote:
>>> So, the if(!of_node_get()) is just an expensive NULL pointer check. I
>>> think
>>> it is better to be explicit about it by not using of_node_get/put() at
>>> all.
>>> How about:
>>>
>>
>> Are we planning to use this in any time sensitive paths? Anyways I am
>> fine removing them.
>
> Not worried about the time taken as much as it serving as a bad example
> and getting carried over to other places where the impact might actually
> be real.
>
Ah OK, sure.
--
Regards,
Sudeep
--
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 1/2] ARM64: dts: Add support for Meson GXM
From: Martin Blumenstingl @ 2016-11-23 12:23 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161122100046.25899-2-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Tue, Nov 22, 2016 at 11:00 AM, Neil Armstrong
<narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> This commit renames the gxl-s905d-p23x DTSI in a common file for
> S905D p23x and S912 q20x boards.
>
> Then adds a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Tested-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
I have tested this successfully on a Mecool BB2 (similar to the Q200
reference board).
--
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/3] bus: da8xx-mstpri: drop the call to of_flat_dt_get_machine_name()
From: Sekhar Nori @ 2016-11-23 12:25 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart, Robin Murphy,
Sudeep Holla
In-Reply-To: <1479899187-10199-2-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Bartosz,
On Wednesday 23 November 2016 04:36 PM, Bartosz Golaszewski wrote:
> In order to avoid a section mismatch use a locally implemented routine
> instead of of_flat_dt_get_machine_name() when printing the error
> message.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/bus/da8xx-mstpri.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/da8xx-mstpri.c b/drivers/bus/da8xx-mstpri.c
> index 85f0b53..064eeb9 100644
> --- a/drivers/bus/da8xx-mstpri.c
> +++ b/drivers/bus/da8xx-mstpri.c
> @@ -16,7 +16,6 @@
> #include <linux/platform_device.h>
> #include <linux/io.h>
> #include <linux/regmap.h>
> -#include <linux/of_fdt.h>
>
> /*
> * REVISIT: Linux doesn't have a good framework for the kind of performance
> @@ -190,6 +189,26 @@ static const struct da8xx_mstpri_board_priorities da8xx_mstpri_board_confs[] = {
> },
> };
>
> +/*
> + * FIXME Remove this function once of/base gets a general routine for getting
> + * the machine model/compatible string.
> + */
> +static const char *da8xx_mstpri_machine_get_compatible(void)
> +{
> + struct device_node *root;
> + const char *compatible;
> + int ret = -1;
> +
> + root = of_find_node_by_path("/");
> + if (root) {
> + ret = of_property_read_string_index(root, "compatible",
> + 0, &compatible);
> + of_node_put(root);
> + }
> +
> + return ret ? NULL : compatible;
> +}
As I just noted in the thread for v1 of this patch, calling
of_node_put(root) while keeping a reference to its compatible property
for later use sounds really broken.
I think it is safest to fix this by not including the compatible name in
error message at all. The error message will be little less descriptive,
but thats better than adding questionable code.
Thats what Frank suggested first up, but I did not realize at that time
that printing compatible name will be this much effort.
Can you please send a v4?
Thanks,
Sekhar
--
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 v9 00/16] mmc: sdhci-msm: Add clk-rates, DDR, HS400 support
From: Ulf Hansson @ 2016-11-23 12:49 UTC (permalink / raw)
To: Ritesh Harjani
Cc: Stephen Boyd, Andy Gross, linux-mmc, Adrian Hunter, Shawn Lin,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-clk,
David Brown,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Georgi Djakov, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Asutosh Das, David Griego, Sahitya Tummala, Venkat Gopalakrishnan,
Rajendra Nayak
In-Reply-To: <6dd874b4-8f60-471b-d1e7-089b4b035ad2-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 23 November 2016 at 01:05, Ritesh Harjani <riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>
>
> On 11/22/2016 4:41 AM, Stephen Boyd wrote:
>>
>> On 11/21, Ritesh Harjani wrote:
>>>
>>>
>>>
>>> On 11/21/2016 3:36 PM, Ulf Hansson wrote:
>>>>
>>>> On 21 November 2016 at 07:37, Ritesh Harjani <riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> This is v9 version of the patch series which adds support for MSM8996.
>>>>> Adds HS400 driver support as well.
>>>>> These are tested on internal msm8996 & db410c HW.
>>>>>
>>>>> The patch series is ready. Do we think we can apply these
>>>>> patches for next now?
>>>>
>>>>
>>>> I guess the DTS changes can be picked up by Andy, so they can go via
>>>> arm-soc?
>>>
>>> Yes.
>>>
>>>>
>>>> Then, does the mmc changes depend on the clock changes? If so, I can
>>>> pick them as well, but then I need an ack from Stephen....
>>>
>>> Ideal and preferable, would be that clk & mmc changes go in
>>> together. But either ways should be fine.
>>>
>>
>> There's only a runtime dependency where the clk rates will be
>> wrong if clk tree isn't merged. I'd rather just apply the clk
>> ones directly to clk tree and let all three trees come together
>> in linux-next and work.
>
>
> Ok great! So can we queue this patch series to next?
Yes. I have picked up all the mmc patches, including the DT
documentation patch. They are queued for next!
The rest is for Andy and Stephen to pick.
Thanks and kind regards
Uffe
--
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] dt-bindings: mfd: Improve readability for TPS65217 interrupt sources
From: Milo Kim @ 2016-11-23 13:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lee Jones,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcousson-rdvid1DuHRBWk0Htik3J/w,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Robert Nelson
In-Reply-To: <33562327.jVWx4tN2gP@wuerfel>
On 11/23/2016 08:51 PM, Arnd Bergmann wrote:
> Ah, the numbers come from the data sheet. Please just remove the
> header then, there is no need to keep them as an ABI, in particular
> when the driver doesn't even include that header today.
Got it.
> What matters here is the binding documentation in
> Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
OK, in addition to this, the interrupt specifier needs to be added in
Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt.
> Please fix that instead to mandate that the two interrupts are
> required, what their functions are, and what the interrupt-names
> (not interrupts-names) property must list.
Oops, wrong interrupt name property - my bad.
Thanks for all your feedback.
Best regards,
Milo
--
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/3] arm64: dts: r8a7796: Add CAN support
From: Geert Uytterhoeven @ 2016-11-23 13:10 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm,
Rob Herring, Mark Rutland, Ramesh Shanmugasundaram, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-can
In-Reply-To: <1479903279-1950-1-git-send-email-chris.paterson2@renesas.com>
On Wed, Nov 23, 2016 at 1:14 PM, Chris Paterson
<chris.paterson2@renesas.com> wrote:
> Adds CAN controller nodes for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: r8a7796: Add CAN external clock support
From: Geert Uytterhoeven @ 2016-11-23 13:10 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Ramesh Shanmugasundaram, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1479903264-1909-1-git-send-email-chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Wed, Nov 23, 2016 at 1:14 PM, Chris Paterson
<chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> Adds external CAN clock node for r8a7796. This clock can be used as
> fCAN clock of CAN and CAN FD controller.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@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 v6 7/8] drivers:input:ads7846(+tsc2046): fix spi module table
From: Javier Martinez Canillas @ 2016-11-23 13:12 UTC (permalink / raw)
To: Dmitry Torokhov, H. Nikolaus Schaller
Cc: Rob Herring, Mark Rutland, Benoît Cousson, Tony Lindgren,
Russell King, Arnd Bergmann, Michael Welling, Mika Penttilä,
Igor Grinberg, Sebastian Reichel, Andrew F. Davis, Mark Brown,
Jonathan Cameron, Hans de Goede, Sangwon Jee,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
linux-iio-u79uwXL29TY76Z2rM5mHXA, kernel
In-Reply-To: <20161119181824.GB20446@dtor-ws>
Hello Dmitry,
On 11/19/2016 03:18 PM, Dmitry Torokhov wrote:
> On Thu, Oct 27, 2016 at 10:44:20AM +0200, H. Nikolaus Schaller wrote:
>> Fix module table so that the driver is loaded if compiled
>> as module and requested by DT.
>
> We really need to fix it between spi/i23c core and module utils instead
> of keeping adding duplicate IDs all over drivers. We already have OF
> module device table containing the same data, we should be able to use
> it.
>
Agreed, unfortunately until the I2C and SPI core are changed to properly
report OF modaliases, we will have to keep adding these duplicated IDs.
And changing the I2C and SPI core isn't trivial since it could break a
lot of drivers that rely on a platform modalias being reported (i.e: no
OF device IDs present in the drivers even when are registered via DT).
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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
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