* Re: [PATCH v2 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-05-01 9:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Vladimir Barinov, Rob Herring, Mark Rutland,
linux-renesas-soc, devicetree, linux-arm-kernel
In-Reply-To: <1493384324-29344-1-git-send-email-geert+renesas@glider.be>
On Fri, Apr 28, 2017 at 02:58:39PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> The Renesas Salvator-X and ULCB development board can be equipped with
> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> use separate DTBs, but currently there's no sharing of board-specific
> devices in DTS.
>
> This series reduces duplication by extracting common board support into
> their own .dtsi files. As the level of support varies across boards and
> SoCs, this requires the addition of a few external clocks and
> placeholder devices on R-Car M3-W, so the common board support DTS can
> refer to them.
>
> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> M3-W, which are present in r8a7795.dtsi, and used in
> r8a7795-salvator-x.dts,
> - Patch 3 adds placeholders for devices that are not yet supported
> and/or tested on R-Car M3-W, but used on R-Car H3,
> - Patch 4 extracts common Salvator-X board support,
> - Patch 5 extracts common ULCB board support.
>
> For R-Car H3 based boards, there are no functional changes.
> For R-Car M3-W based boards, some new devices are now described in DT.
>
> Compared to v1, the most important change is a rebase to remove the
> dependency on "[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and
> M3-W SiP" (http://www.spinics.net/lists/devicetree/msg173820.html).
> Please refer to the individual patches for more changelog information.
>
> Dependencies:
> - renesas-devel-20170428-v4.11-rc8.
>
> DTB changes have been inspected using scripts/dtc/dtx_diff.
> This has been tested on Salvator-X (both H3 and M3-W), H3ULCB, and
> M3ULCB.
>
> Thanks for applying!
Thanks, done.
^ permalink raw reply
* Re: [PATCH v5 0/9] Add sbs-manager with smbalert support
From: Wolfram Sang @ 2017-05-01 9:08 UTC (permalink / raw)
To: Phil Reid, Benjamin Tissoires
Cc: robh+dt, mark.rutland, sre, peda, linux-i2c, devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]
On Mon, May 01, 2017 at 04:49:50PM +0800, Phil Reid wrote:
> This is another go of the sbs-manager driver using smbalert for
> irq support from a while ago.
Thanks for keeping at it!
Adding Benjamin Tissoires to CC, he worked lately on I2C device IRQs...
@Benjamin: do you need the patches, too, or do you read the I2C list?
> Enables the existing smbalert driver to be loaded via the device tree.
> Only need to add smbus_alert interrupt to the i2c bus segement in the
> devicetree and the core will then enable the alert driver.
>
> Reorders the rquest irq call in the pca954x driver to ensure each
> muxed i2c segment can handle service smbalerts on that segment before
> irq's are enabled. The pca954x can't mask individual irq's routed thru
> them.
>
> Add the sbs-manager from Karl-Heinz.
> Add the alert call back and gpio interface to allow the battery detect
> logic in the existing sbs-battery driver to work.
>
>
>
> Karl-Heinz Schneider (2):
> Documentation: Add sbs-manager device tree node documentation
> power: Adds support for Smart Battery System Manager
>
> Phil Reid (7):
> i2c: i2c-smbus: Support threaded irqs.
> i2c: i2c-smbus: Add null ptr guard in smb_alert_probe
> i2c: i2c-smbus: add of_i2c_setup_smbus_alert
> i2c: core: call of_i2c_setup_smbus_alert in i2c_register_adapter
> i2c: mux: pca954x: Call request irq after adding mux segments
> power: supply: sbs-battery: Add alert callback
> power: supply: sbs-manager: Add alert callback and battery change
> notification
>
> Documentation/devicetree/bindings/i2c/i2c.txt | 4 +-
> .../bindings/power/supply/sbs,sbs-manager.txt | 64 +++
> drivers/i2c/i2c-core.c | 4 +
> drivers/i2c/i2c-smbus.c | 64 ++-
> drivers/i2c/muxes/i2c-mux-pca954x.c | 52 ++-
> drivers/power/supply/Kconfig | 14 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/sbs-battery.c | 16 +-
> drivers/power/supply/sbs-manager.c | 448 +++++++++++++++++++++
> include/linux/i2c-smbus.h | 9 +
> 10 files changed, 637 insertions(+), 39 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
> create mode 100644 drivers/power/supply/sbs-manager.c
>
> --
> 1.8.3.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v5 9/9] power: supply: sbs-manager: Add alert callback and battery change notification
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
This adds smb alert support via the smbus_alert driver to generate
power_supply_changed notifications when either external power is
removed / applied or a battery inserted / removed.
Use the i2c alert callback to notify the attached battery driver that a
change has occurred.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/power/supply/Kconfig | 1 +
drivers/power/supply/sbs-manager.c | 129 ++++++++++++++++++++++++++++++++++++-
2 files changed, 127 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 8aa5324..a25359c 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -536,6 +536,7 @@ config AXP20X_POWER
config MANAGER_SBS
tristate "Smart Battery System Manager"
depends on I2C && I2C_MUX
+ select I2C_SMBUS
help
Say Y here to include support for Smart Battery System Manager
ICs. The driver reports online and charging status via sysfs.
diff --git a/drivers/power/supply/sbs-manager.c b/drivers/power/supply/sbs-manager.c
index adf9e41..d7f7a92 100644
--- a/drivers/power/supply/sbs-manager.c
+++ b/drivers/power/supply/sbs-manager.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
+#include <linux/gpio.h>
#include <linux/power_supply.h>
#define SBSM_MAX_BATS 4
@@ -30,14 +31,22 @@
#define SBSM_CMD_BATSYSINFO 0x04
#define SBSM_CMD_LTC 0x3c
+#define SBSM_BIT_AC_PRESENT BIT(0)
+
struct sbsm_data {
struct i2c_client *client;
struct i2c_mux_core *muxc;
struct power_supply *psy;
+ struct gpio_chip chip;
+
int cur_chan; /* currently selected channel */
bool is_ltc1760; /* special capabilities */
+
+ unsigned int supported_bats;
+ unsigned int last_state;
+ unsigned int last_state_cont;
};
static enum power_supply_property sbsm_props[] = {
@@ -184,6 +193,116 @@ static int sbsm_select(struct i2c_mux_core *muxc, u32 chan)
return ret;
}
+static int sbsm_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+ struct sbsm_data *data = gpiochip_get_data(gc);
+ int ret;
+
+ ret = sbsm_read_word(data->client, SBSM_CMD_BATSYSSTATE);
+ if (ret < 0)
+ return ret;
+
+ return ret & BIT(off);
+}
+
+/*
+ * This needs to be defined or the GPIO lib fails to register the pin.
+ * But the 'gpio' is always an input.
+ */
+static int sbsm_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ return 0;
+}
+
+static int sbsm_do_alert(struct device *dev, void *d)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_driver *driver;
+
+ if (!client || client->addr != 0x0b)
+ return 0;
+
+ device_lock(dev);
+ if (client->dev.driver) {
+ driver = to_i2c_driver(client->dev.driver);
+ if (driver->alert)
+ driver->alert(client, I2C_PROTOCOL_SMBUS_ALERT, 0);
+ else
+ dev_warn(&client->dev, "no driver alert()!\n");
+ } else
+ dev_dbg(&client->dev, "alert with no driver\n");
+ device_unlock(dev);
+
+ return -EBUSY;
+}
+
+static void sbsm_alert(struct i2c_client *client, enum i2c_alert_protocol prot,
+ unsigned int d)
+{
+ struct sbsm_data *sbsm = i2c_get_clientdata(client);
+
+ int ret, i, irq_bat = 0;
+
+ ret = sbsm_read_word(sbsm->client, SBSM_CMD_BATSYSSTATE);
+ if (ret >= 0)
+ irq_bat = ret ^ sbsm->last_state;
+ sbsm->last_state = ret;
+
+ ret = sbsm_read_word(sbsm->client, SBSM_CMD_BATSYSSTATECONT);
+ if ((ret >= 0) &&
+ ((ret ^ sbsm->last_state_cont) & SBSM_BIT_AC_PRESENT)) {
+ irq_bat |= sbsm->supported_bats;
+ power_supply_changed(sbsm->psy);
+ }
+ sbsm->last_state_cont = ret;
+
+ for (i = 0; i < SBSM_MAX_BATS; i++) {
+ if (irq_bat & BIT(i)) {
+ device_for_each_child(&sbsm->muxc->adapter[i]->dev,
+ NULL, sbsm_do_alert);
+ }
+ }
+}
+
+static int sbsm_gpio_setup(struct sbsm_data *data)
+{
+ struct gpio_chip *gc = &data->chip;
+ struct i2c_client *client = data->client;
+ struct device *dev = &client->dev;
+ struct device_node *of_node = client->dev.of_node;
+ int ret;
+
+ if (!of_get_property(of_node, "gpio-controller", NULL))
+ return 0;
+
+ ret = sbsm_read_word(client, SBSM_CMD_BATSYSSTATE);
+ if (ret < 0)
+ return ret;
+ data->last_state = ret;
+
+ ret = sbsm_read_word(client, SBSM_CMD_BATSYSSTATECONT);
+ if (ret < 0)
+ return ret;
+ data->last_state_cont = ret;
+
+ gc->get = sbsm_gpio_get_value;
+ gc->direction_input = sbsm_gpio_direction_input;
+ gc->can_sleep = true;
+ gc->base = -1;
+ gc->ngpio = SBSM_MAX_BATS;
+ gc->label = client->name;
+ gc->parent = dev;
+ gc->owner = THIS_MODULE;
+
+ ret = devm_gpiochip_add_data(dev, gc, data);
+ if (ret) {
+ dev_err(dev, "devm_gpiochip_add_data failed: %d\n", ret);
+ return ret;
+ }
+
+ return ret;
+}
+
#if defined(CONFIG_OF)
#include <linux/of_device.h>
@@ -214,7 +333,7 @@ static int sbsm_probe(struct i2c_client *client,
struct device *dev = &client->dev;
struct power_supply_desc *psy_desc;
struct power_supply_config psy_cfg = {};
- int ret = 0, i, supported_bats;
+ int ret = 0, i;
/* Device listens only at address 0x0a */
if (client->addr != 0x0a)
@@ -235,7 +354,7 @@ static int sbsm_probe(struct i2c_client *client,
ret = sbsm_read_word(client, SBSM_CMD_BATSYSINFO);
if (ret < 0)
return ret;
- supported_bats = le16_to_cpu(ret) & 0xf;
+ data->supported_bats = le16_to_cpu(ret) & 0xf;
data->muxc = i2c_mux_alloc(adapter, dev, SBSM_MAX_BATS, 0,
I2C_MUX_LOCKED, &sbsm_select, NULL);
@@ -248,7 +367,7 @@ static int sbsm_probe(struct i2c_client *client,
/* register muxed i2c channels. One for each supported battery */
for (i = 0; i < SBSM_MAX_BATS; ++i) {
- if ((1 << i) & supported_bats) {
+ if ((1 << i) & data->supported_bats) {
ret = i2c_mux_add_adapter(data->muxc, 0, i + 1, 0);
if (ret) {
dev_err(dev,
@@ -273,6 +392,9 @@ static int sbsm_probe(struct i2c_client *client,
ret = -ENOMEM;
goto err_psy;
}
+ ret = sbsm_gpio_setup(data);
+ if (ret < 0)
+ goto err_psy;
psy_cfg.drv_data = data;
data->psy = devm_power_supply_register(dev, psy_desc, &psy_cfg);
@@ -316,6 +438,7 @@ static int sbsm_remove(struct i2c_client *client)
},
.probe = sbsm_probe,
.remove = sbsm_remove,
+ .alert = sbsm_alert,
.id_table = sbsm_ids
};
module_i2c_driver(sbsm_driver);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 8/9] power: supply: sbs-battery: Add alert callback
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
To simplify the sbs-manager code and notification of battery removal
use the i2c alert callback to notify the sbs-battery driver that an
event has occurred.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/power/supply/sbs-battery.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
index 8bb2eb3..a719892 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -675,21 +675,30 @@ static int sbs_get_property(struct power_supply *psy,
return 0;
}
-static irqreturn_t sbs_irq(int irq, void *devid)
+static void sbs_supply_changed(struct sbs_info *chip)
{
- struct sbs_info *chip = devid;
struct power_supply *battery = chip->power_supply;
int ret;
ret = gpiod_get_value_cansleep(chip->gpio_detect);
if (ret < 0)
- return ret;
+ return;
chip->is_present = ret;
power_supply_changed(battery);
+}
+static irqreturn_t sbs_irq(int irq, void *devid)
+{
+ sbs_supply_changed(devid);
return IRQ_HANDLED;
}
+static void sbs_alert(struct i2c_client *client, enum i2c_alert_protocol prot,
+ unsigned int data)
+{
+ sbs_supply_changed(i2c_get_clientdata(client));
+}
+
static void sbs_external_power_changed(struct power_supply *psy)
{
struct sbs_info *chip = power_supply_get_drvdata(psy);
@@ -917,6 +926,7 @@ static int sbs_suspend(struct device *dev)
static struct i2c_driver sbs_battery_driver = {
.probe = sbs_probe,
.remove = sbs_remove,
+ .alert = sbs_alert,
.id_table = sbs_id,
.driver = {
.name = "sbs-battery",
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 7/9] power: Adds support for Smart Battery System Manager
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
Cc: Karl-Heinz Schneider
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
From: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
This patch adds support for Smart Battery System Manager.
A SBSM is a device listening at I2C/SMBus address 0x0a and is capable of
communicating up to four I2C smart battery devices. All smart battery
devices are listening at address 0x0b, so the SBSM muliplexes between
them. The driver makes use of the I2C-Mux framework to allow smart
batteries to be bound via device tree, i.e. the sbs-battery driver.
Via sysfs interface the online state and charge type are presented. If
the driver is bound as ltc1760 (an implementation of a Dual Smart Battery
System Manager) the charge type can also be changed from trickle to fast.
Tested-by: Phil Reid <preid@electromag.com.au>
Reviewed-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/power/supply/Kconfig | 13 ++
drivers/power/supply/Makefile | 1 +
drivers/power/supply/sbs-manager.c | 325 +++++++++++++++++++++++++++++++++++++
3 files changed, 339 insertions(+)
create mode 100644 drivers/power/supply/sbs-manager.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index da54ac8..8aa5324 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -533,4 +533,17 @@ config AXP20X_POWER
This driver provides support for the power supply features of
AXP20x PMIC.
+config MANAGER_SBS
+ tristate "Smart Battery System Manager"
+ depends on I2C && I2C_MUX
+ help
+ Say Y here to include support for Smart Battery System Manager
+ ICs. The driver reports online and charging status via sysfs.
+ It presents itself also as I2C mux which allows to bind
+ smart battery driver to its ports.
+ Supported is for example LTC1760.
+
+ This driver can also be built as a module. If so, the module will be
+ called sbs-manager.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 3789a2c..4f53c98 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o
obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
+obj-$(CONFIG_MANAGER_SBS) += sbs-manager.o
diff --git a/drivers/power/supply/sbs-manager.c b/drivers/power/supply/sbs-manager.c
new file mode 100644
index 0000000..adf9e41
--- /dev/null
+++ b/drivers/power/supply/sbs-manager.c
@@ -0,0 +1,325 @@
+/*
+ * Driver for SBS compliant Smart Battery System Managers
+ *
+ * The device communicates via i2c at address 0x0a and multiplexes access to up
+ * to four smart batteries at address 0x0b.
+ *
+ * Via sysfs interface the online state and charge type are presented.
+ *
+ * Datasheet SBSM: http://sbs-forum.org/specs/sbsm100b.pdf
+ * Datasheet LTC1760: http://cds.linear.com/docs/en/datasheet/1760fb.pdf
+ *
+ * Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/power_supply.h>
+
+#define SBSM_MAX_BATS 4
+#define SBSM_RETRY_CNT 3
+
+/* registers addresses */
+#define SBSM_CMD_BATSYSSTATE 0x01
+#define SBSM_CMD_BATSYSSTATECONT 0x02
+#define SBSM_CMD_BATSYSINFO 0x04
+#define SBSM_CMD_LTC 0x3c
+
+struct sbsm_data {
+ struct i2c_client *client;
+ struct i2c_mux_core *muxc;
+
+ struct power_supply *psy;
+
+ int cur_chan; /* currently selected channel */
+ bool is_ltc1760; /* special capabilities */
+};
+
+static enum power_supply_property sbsm_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_CHARGE_TYPE,
+};
+
+static int sbsm_read_word(struct i2c_client *client, u8 address)
+{
+ int reg, retries = SBSM_RETRY_CNT;
+
+ while (retries > 0) {
+ reg = i2c_smbus_read_word_data(client, address);
+ if (reg >= 0)
+ break;
+ --retries;
+ }
+
+ if (reg < 0) {
+ dev_err(&client->dev, "failed to read register %i\n",
+ (int)address);
+ return reg;
+ }
+
+ return le16_to_cpu(reg);
+}
+
+static int sbsm_write_word(struct i2c_client *client, u8 address, u16 word)
+{
+ int ret, retries = SBSM_RETRY_CNT;
+
+ word = cpu_to_le16(word);
+ while (retries > 0) {
+ ret = i2c_smbus_write_word_data(client, address, word);
+ if (ret >= 0)
+ break;
+ --retries;
+ }
+ if (ret < 0)
+ dev_err(&client->dev, "failed to write to register %i\n",
+ (int)address);
+
+ return ret;
+}
+
+static int sbsm_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct sbsm_data *data = power_supply_get_drvdata(psy);
+ int regval = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ regval = sbsm_read_word(data->client, SBSM_CMD_BATSYSSTATECONT);
+ if (regval < 0)
+ return regval;
+ val->intval = !!(regval & 0x1);
+ break;
+
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ regval = sbsm_read_word(data->client, SBSM_CMD_BATSYSSTATE);
+ if (regval < 0)
+ return regval;
+
+ if ((regval & 0x00f0) == 0) {
+ val->intval = POWER_SUPPLY_CHARGE_TYPE_NONE;
+ return 0;
+ }
+ val->intval = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+
+ if (data->is_ltc1760) {
+ /* charge mode fast if turbo is active */
+ regval = sbsm_read_word(data->client, SBSM_CMD_LTC);
+ if (regval < 0)
+ return regval;
+ else if (regval & 0x80)
+ val->intval = POWER_SUPPLY_CHARGE_TYPE_FAST;
+ }
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int sbsm_prop_is_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ struct sbsm_data *data = power_supply_get_drvdata(psy);
+
+ return (psp == POWER_SUPPLY_PROP_CHARGE_TYPE) && data->is_ltc1760;
+}
+
+static int sbsm_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct sbsm_data *data = power_supply_get_drvdata(psy);
+ int ret = -EINVAL;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ /* write 1 to TURBO if type fast is given */
+ if (data->is_ltc1760) {
+ u16 regval = val->intval ==
+ POWER_SUPPLY_CHARGE_TYPE_FAST ? (0x1 << 7) : 0;
+ ret = sbsm_write_word(data->client, SBSM_CMD_LTC,
+ regval);
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return ret;
+}
+
+/*
+ * Switch to battery
+ * Parameter chan is directly the content of SMB_BAT* nibble
+ */
+static int sbsm_select(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct sbsm_data *data = i2c_mux_priv(muxc);
+ int ret = 0;
+ u16 reg;
+
+ if (data->cur_chan == chan)
+ return ret;
+
+ /* chan goes from 1 ... 4 */
+ reg = 1 << (11 + chan);
+ ret = sbsm_write_word(data->client, SBSM_CMD_BATSYSSTATE, reg);
+ if (ret)
+ dev_err(&data->client->dev, "Failed to select channel %i\n",
+ chan);
+ else
+ data->cur_chan = chan;
+
+ return ret;
+}
+
+#if defined(CONFIG_OF)
+
+#include <linux/of_device.h>
+
+static const struct of_device_id sbsm_dt_ids[] = {
+ { .compatible = "sbs,sbs-manager" },
+ { .compatible = "lltc,ltc1760" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sbsm_dt_ids);
+
+#endif
+
+static const struct power_supply_desc sbsm_default_psy_desc = {
+ .type = POWER_SUPPLY_TYPE_MAINS,
+ .properties = sbsm_props,
+ .num_properties = ARRAY_SIZE(sbsm_props),
+ .get_property = &sbsm_get_property,
+ .set_property = &sbsm_set_property,
+ .property_is_writeable = &sbsm_prop_is_writeable,
+};
+
+static int sbsm_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
+ struct sbsm_data *data;
+ struct device *dev = &client->dev;
+ struct power_supply_desc *psy_desc;
+ struct power_supply_config psy_cfg = {};
+ int ret = 0, i, supported_bats;
+
+ /* Device listens only at address 0x0a */
+ if (client->addr != 0x0a)
+ return -ENODEV;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA))
+ return -EPFNOSUPPORT;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, data);
+
+ data->client = client;
+ data->is_ltc1760 = !!strstr(id->name, "ltc1760");
+
+ ret = sbsm_read_word(client, SBSM_CMD_BATSYSINFO);
+ if (ret < 0)
+ return ret;
+ supported_bats = le16_to_cpu(ret) & 0xf;
+
+ data->muxc = i2c_mux_alloc(adapter, dev, SBSM_MAX_BATS, 0,
+ I2C_MUX_LOCKED, &sbsm_select, NULL);
+ if (!data->muxc) {
+ dev_err(dev, "failed to alloc i2c mux\n");
+ ret = -ENOMEM;
+ goto err_mux_alloc;
+ }
+ data->muxc->priv = data;
+
+ /* register muxed i2c channels. One for each supported battery */
+ for (i = 0; i < SBSM_MAX_BATS; ++i) {
+ if ((1 << i) & supported_bats) {
+ ret = i2c_mux_add_adapter(data->muxc, 0, i + 1, 0);
+ if (ret) {
+ dev_err(dev,
+ "failed to register i2c mux channel %d\n",
+ i + 1);
+ goto err_mux_register;
+ }
+ }
+ }
+
+ psy_desc = devm_kmemdup(dev, &sbsm_default_psy_desc,
+ sizeof(struct power_supply_desc),
+ GFP_KERNEL);
+ if (!psy_desc) {
+ ret = -ENOMEM;
+ goto err_psy;
+ }
+
+ psy_desc->name = devm_kasprintf(dev, GFP_KERNEL, "sbsm-%s",
+ dev_name(&client->dev));
+ if (!psy_desc->name) {
+ ret = -ENOMEM;
+ goto err_psy;
+ }
+
+ psy_cfg.drv_data = data;
+ data->psy = devm_power_supply_register(dev, psy_desc, &psy_cfg);
+ if (IS_ERR(data->psy)) {
+ ret = PTR_ERR(data->psy);
+ dev_err(dev, "failed to register power supply %s\n",
+ psy_desc->name);
+ goto err_psy;
+ }
+
+ dev_info(dev, "sbsm registered\n");
+ return 0;
+
+err_psy:
+err_mux_register:
+ i2c_mux_del_adapters(data->muxc);
+
+err_mux_alloc:
+ return ret;
+}
+
+static int sbsm_remove(struct i2c_client *client)
+{
+ struct sbsm_data *data = i2c_get_clientdata(client);
+
+ i2c_mux_del_adapters(data->muxc);
+ return 0;
+}
+
+static const struct i2c_device_id sbsm_ids[] = {
+ { "sbs-manager", 0 },
+ { "ltc1760", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, sbsm_ids);
+
+static struct i2c_driver sbsm_driver = {
+ .driver = {
+ .name = "sbsm",
+ .owner = THIS_MODULE,
+ },
+ .probe = sbsm_probe,
+ .remove = sbsm_remove,
+ .id_table = sbsm_ids
+};
+module_i2c_driver(sbsm_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Karl-Heinz Schneider <karl-heinz@schneider-inet.de>");
+MODULE_DESCRIPTION("SBSM Smart Battery System Manager");
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 6/9] Documentation: Add sbs-manager device tree node documentation
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
Cc: Karl-Heinz Schneider
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
From: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
This patch adds device tree documentation for the sbs-manager
Reviewed-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
.../bindings/power/supply/sbs,sbs-manager.txt | 64 ++++++++++++++++++++++
1 file changed, 64 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
new file mode 100644
index 0000000..c523b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
@@ -0,0 +1,64 @@
+Binding for sbs-manager
+
+Required properties:
+- compatible: should be "lltc,ltc1760" or use "sbs,sbs-manager" as fallback.
+- reg: integer, i2c address of the device. Should be <0xa>.
+Optional properties:
+- gpio-controller: Marks the port as GPIO controller.
+ See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
+- #gpio-cells: Should be <2>. The first cell is the pin number, the second cell
+ is used to specify optional parameters:
+ See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
+
+From OS view the device is basically an i2c-mux used to communicate with up to
+four smart battery devices at address 0xb. The driver actually implements this
+behaviour. So standard i2c-mux nodes can be used to register up to four slave
+batteries. Channels will be numerated starting from 1 to 4.
+
+Example:
+
+batman@0a {
+ compatible = "lltc,ltc1760";
+ reg = <0x0a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ battery@0b {
+ compatible = "ti,bq2060", "sbs,sbs-battery";
+ reg = <0x0b>;
+ sbs,battery-detect-gpios = <&batman 1 1>;
+ };
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ battery@0b {
+ compatible = "ti,bq2060", "sbs,sbs-battery";
+ reg = <0x0b>;
+ sbs,battery-detect-gpios = <&batman 2 1>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ battery@0b {
+ compatible = "ti,bq2060", "sbs,sbs-battery";
+ reg = <0x0b>;
+ sbs,battery-detect-gpios = <&batman 3 1>;
+ };
+ };
+};
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 5/9] i2c: mux: pca954x: Call request irq after adding mux segments
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
The pca954x device do not have the ability to mask interrupts. For
i2c slave devices that also don't have masking ability (eg ltc1760
smbalert output) delay registering the irq until after the mux
segments have been configured. During the mux add_adaptor call the
core i2c system can register an smbalert handler which would then
be called immediately when the irq is registered. This smbalert
handler will then clear the pending irq.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 52 +++++++++++++++++--------------------
1 file changed, 24 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index ad31d21..4299738 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -294,7 +294,7 @@ static int pca954x_irq_setup(struct i2c_mux_core *muxc)
{
struct pca954x *data = i2c_mux_priv(muxc);
struct i2c_client *client = data->client;
- int c, err, irq;
+ int c, irq;
if (!data->chip->has_irq || client->irq <= 0)
return 0;
@@ -314,24 +314,22 @@ static int pca954x_irq_setup(struct i2c_mux_core *muxc)
handle_simple_irq);
}
- err = devm_request_threaded_irq(&client->dev, data->client->irq, NULL,
- pca954x_irq_handler,
- IRQF_ONESHOT | IRQF_SHARED,
- "pca954x", data);
- if (err)
- goto err_req_irq;
+ return 0;
+}
- disable_irq(data->client->irq);
+static void pca954x_cleanup(struct i2c_mux_core *muxc)
+{
+ struct pca954x *data = i2c_mux_priv(muxc);
+ int c, irq;
- return 0;
-err_req_irq:
- for (c = 0; c < data->chip->nchans; c++) {
- irq = irq_find_mapping(data->irq, c);
- irq_dispose_mapping(irq);
+ if (data->irq) {
+ for (c = 0; c < data->chip->nchans; c++) {
+ irq = irq_find_mapping(data->irq, c);
+ irq_dispose_mapping(irq);
+ }
+ irq_domain_remove(data->irq);
}
- irq_domain_remove(data->irq);
-
- return err;
+ i2c_mux_del_adapters(muxc);
}
/*
@@ -422,6 +420,14 @@ static int pca954x_probe(struct i2c_client *client,
}
}
+ if (data->chip->has_irq || client->irq > 0) {
+ ret = devm_request_threaded_irq(&client->dev, data->client->irq,
+ NULL, pca954x_irq_handler, IRQF_ONESHOT | IRQF_SHARED,
+ "pca954x", data);
+ if (ret)
+ goto fail_del_adapters;
+ }
+
dev_info(&client->dev,
"registered %d multiplexed busses for I2C %s %s\n",
num, data->chip->muxtype == pca954x_ismux
@@ -430,25 +436,15 @@ static int pca954x_probe(struct i2c_client *client,
return 0;
fail_del_adapters:
- i2c_mux_del_adapters(muxc);
+ pca954x_cleanup(muxc);
return ret;
}
static int pca954x_remove(struct i2c_client *client)
{
struct i2c_mux_core *muxc = i2c_get_clientdata(client);
- struct pca954x *data = i2c_mux_priv(muxc);
- int c, irq;
- if (data->irq) {
- for (c = 0; c < data->chip->nchans; c++) {
- irq = irq_find_mapping(data->irq, c);
- irq_dispose_mapping(irq);
- }
- irq_domain_remove(data->irq);
- }
-
- i2c_mux_del_adapters(muxc);
+ pca954x_cleanup(muxc);
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 4/9] i2c: core: call of_i2c_setup_smbus_alert in i2c_register_adapter
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
Add a call to of_i2c_setup_smbus_alert when a i2c adapter is registered
so the the smbalert driver can be registered.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/i2c-core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index d2402bb..626471b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -40,6 +40,7 @@
#include <linux/gpio.h>
#include <linux/hardirq.h>
#include <linux/i2c.h>
+#include <linux/i2c-smbus.h>
#include <linux/idr.h>
#include <linux/init.h>
#include <linux/irqflags.h>
@@ -2045,6 +2046,9 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
dev_warn(&adap->dev,
"Failed to create compatibility class link\n");
#endif
+ res = of_i2c_setup_smbus_alert(adap);
+ if (res)
+ goto out_list;
i2c_init_recovery(adap);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 3/9] i2c: i2c-smbus: add of_i2c_setup_smbus_alert
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
This commit adds of_i2c_setup_smbus_alert which allows the smbalert
driver to be attached to an i2c adapter via the device tree.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
Documentation/devicetree/bindings/i2c/i2c.txt | 4 +--
drivers/i2c/i2c-smbus.c | 35 +++++++++++++++++++++++++++
include/linux/i2c-smbus.h | 9 +++++++
3 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index cee9d50..1126398 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -59,8 +59,8 @@ wants to support one of the below features, it should adapt the bindings below.
interrupts used by the device.
- interrupt-names
- "irq" and "wakeup" names are recognized by I2C core, other names are
- left to individual drivers.
+ "irq", "wakeup" and "smbus_alert" names are recognized by I2C core,
+ other names are left to individual drivers.
- host-notify
device uses SMBus host notify protocol instead of interrupt line.
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index df0e2fa..a8f8439 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -21,6 +21,7 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/of_irq.h>
#include <linux/slab.h>
#include <linux/workqueue.h>
@@ -238,6 +239,40 @@ struct i2c_client *i2c_setup_smbus_alert(struct i2c_adapter *adapter,
}
EXPORT_SYMBOL_GPL(i2c_setup_smbus_alert);
+int of_i2c_setup_smbus_alert(struct i2c_adapter *adap)
+{
+ struct i2c_client *client;
+ struct i2c_smbus_alert_setup *setup;
+ struct i2c_board_info info = {
+ I2C_BOARD_INFO("smbus_alert", 0x0c),
+ };
+ int irq;
+
+ if (!adap->dev.of_node)
+ return 0;
+
+ irq = of_irq_get_byname(adap->dev.of_node, "smbus_alert");
+ if (irq == -EINVAL || irq == -ENODATA)
+ return 0;
+ else if (irq < 0)
+ return irq;
+
+ setup = devm_kzalloc(&adap->dev, sizeof(struct i2c_smbus_alert_setup),
+ GFP_KERNEL);
+ if (!setup)
+ return -ENOMEM;
+
+ setup->irq = irq;
+ info.platform_data = setup;
+
+ client = i2c_new_device(adap, &info);
+ if (!client)
+ return -ENODEV;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_i2c_setup_smbus_alert);
+
/**
* i2c_handle_smbus_alert - Handle an SMBus alert
* @ara: the ARA client on the relevant adapter
diff --git a/include/linux/i2c-smbus.h b/include/linux/i2c-smbus.h
index a138502..4732d09 100644
--- a/include/linux/i2c-smbus.h
+++ b/include/linux/i2c-smbus.h
@@ -50,4 +50,13 @@ struct i2c_client *i2c_setup_smbus_alert(struct i2c_adapter *adapter,
struct i2c_smbus_alert_setup *setup);
int i2c_handle_smbus_alert(struct i2c_client *ara);
+#if IS_ENABLED(CONFIG_I2C_SMBUS)
+int of_i2c_setup_smbus_alert(struct i2c_adapter *adap);
+#else
+static inline int of_i2c_setup_smbus_alert(struct i2c_adapter *adap)
+{
+ return 0;
+}
+#endif
+
#endif /* _LINUX_I2C_SMBUS_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 2/9] i2c: i2c-smbus: Add null ptr guard in smb_alert_probe
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
If platdata is not correct setup before registering the device
a null ptr derefence can occur.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/i2c-smbus.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index b272493..df0e2fa 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -151,6 +151,11 @@ static int smbalert_probe(struct i2c_client *ara,
struct i2c_adapter *adapter = ara->adapter;
int res;
+ if (!setup) {
+ dev_err(&adapter->dev, "setup not defined\n");
+ return -ENODATA;
+ }
+
alert = devm_kzalloc(&ara->dev, sizeof(struct i2c_smbus_alert),
GFP_KERNEL);
if (!alert)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 1/9] i2c: i2c-smbus: Support threaded irqs.
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
In-Reply-To: <1493628599-30552-1-git-send-email-preid@electromag.com.au>
handle_nested_irq calls the threaded irq handler. So if the smbus_alert
irq is being generated via this an null address is dereferenced. Split
irq up into separate functions to allow thread / non thread irq to work
correctly.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/i2c-smbus.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index f9271c7..b272493 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -72,13 +72,12 @@ static int smbus_do_alert(struct device *dev, void *addrp)
* The alert IRQ handler needs to hand work off to a task which can issue
* SMBus calls, because those sleeping calls can't be made in IRQ context.
*/
-static void smbus_alert(struct work_struct *work)
+static irqreturn_t smbus_alert(int irq, void *d)
{
- struct i2c_smbus_alert *alert;
+ struct i2c_smbus_alert *alert = d;
struct i2c_client *ara;
unsigned short prev_addr = 0; /* Not a valid address */
- alert = container_of(work, struct i2c_smbus_alert, alert);
ara = alert->ara;
for (;;) {
@@ -115,6 +114,17 @@ static void smbus_alert(struct work_struct *work)
prev_addr = data.addr;
}
+ return IRQ_HANDLED;
+}
+
+static void smbalert_work(struct work_struct *work)
+{
+ struct i2c_smbus_alert *alert;
+
+ alert = container_of(work, struct i2c_smbus_alert, alert);
+
+ smbus_alert(alert->irq, alert);
+
/* We handled all alerts; re-enable level-triggered IRQs */
if (!alert->alert_edge_triggered)
enable_irq(alert->irq);
@@ -148,12 +158,14 @@ static int smbalert_probe(struct i2c_client *ara,
alert->alert_edge_triggered = setup->alert_edge_triggered;
alert->irq = setup->irq;
- INIT_WORK(&alert->alert, smbus_alert);
+ INIT_WORK(&alert->alert, smbalert_work);
alert->ara = ara;
if (setup->irq > 0) {
- res = devm_request_irq(&ara->dev, setup->irq, smbalert_irq,
- 0, "smbus_alert", alert);
+ res = devm_request_threaded_irq(&ara->dev, alert->irq,
+ smbalert_irq, smbus_alert,
+ IRQF_SHARED | IRQF_ONESHOT,
+ "smbus_alert", alert);
if (res)
return res;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 0/9] Add sbs-manager with smbalert support
From: Phil Reid @ 2017-05-01 8:49 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, sre, peda, preid, linux-i2c,
devicetree, linux-pm
This is another go of the sbs-manager driver using smbalert for
irq support from a while ago.
Enables the existing smbalert driver to be loaded via the device tree.
Only need to add smbus_alert interrupt to the i2c bus segement in the
devicetree and the core will then enable the alert driver.
Reorders the rquest irq call in the pca954x driver to ensure each
muxed i2c segment can handle service smbalerts on that segment before
irq's are enabled. The pca954x can't mask individual irq's routed thru
them.
Add the sbs-manager from Karl-Heinz.
Add the alert call back and gpio interface to allow the battery detect
logic in the existing sbs-battery driver to work.
Karl-Heinz Schneider (2):
Documentation: Add sbs-manager device tree node documentation
power: Adds support for Smart Battery System Manager
Phil Reid (7):
i2c: i2c-smbus: Support threaded irqs.
i2c: i2c-smbus: Add null ptr guard in smb_alert_probe
i2c: i2c-smbus: add of_i2c_setup_smbus_alert
i2c: core: call of_i2c_setup_smbus_alert in i2c_register_adapter
i2c: mux: pca954x: Call request irq after adding mux segments
power: supply: sbs-battery: Add alert callback
power: supply: sbs-manager: Add alert callback and battery change
notification
Documentation/devicetree/bindings/i2c/i2c.txt | 4 +-
.../bindings/power/supply/sbs,sbs-manager.txt | 64 +++
drivers/i2c/i2c-core.c | 4 +
drivers/i2c/i2c-smbus.c | 64 ++-
drivers/i2c/muxes/i2c-mux-pca954x.c | 52 ++-
drivers/power/supply/Kconfig | 14 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/sbs-battery.c | 16 +-
drivers/power/supply/sbs-manager.c | 448 +++++++++++++++++++++
include/linux/i2c-smbus.h | 9 +
10 files changed, 637 insertions(+), 39 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
create mode 100644 drivers/power/supply/sbs-manager.c
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clk: r7s72100: add USB bit definitions
From: Simon Horman @ 2017-05-01 8:47 UTC (permalink / raw)
To: Chris Brandt
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170428190134.63895-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Fri, Apr 28, 2017 at 12:01:33PM -0700, Chris Brandt wrote:
> Add the bit locations that correspond to the USB clocks.
>
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Thanks, I have queued up this and the following patch for v4.13.
--
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 v2] powerpc/8xx: Adding support of IRQ in MPC8xx GPIO
From: Christophe Leroy @ 2017-05-01 7:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood, Rob Herring, Mark Rutland
Cc: linux-kernel, linuxppc-dev, devicetree
This patch allows the use of IRQ to notify the change of GPIO status
on MPC8xx CPM IO ports. This then allows to associate IRQs to GPIOs
in the Device Tree.
Ex:
CPM1_PIO_C: gpio-controller@960 {
#gpio-cells = <2>;
compatible = "fsl,cpm1-pario-bank-c";
reg = <0x960 0x10>;
fsl,cpm1-gpio-irq-mask = <0x0fff>;
interrupts = <1 2 6 9 10 11 14 15 23 24 26 31>;
interrupt-parent = <&CPM_PIC>;
gpio-controller;
};
The property 'fsl,cpm1-gpio-irq-mask' defines which of the 16 GPIOs
have the associated interrupts defined in the 'interrupts' property.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2: Updated the binding ; changed property 'interrupt-mask' to 'fsl,cpm1-gpio-irq-mask'
.../devicetree/bindings/soc/fsl/cpm_qe/gpio.txt | 21 +++++++++++++++++-
arch/powerpc/include/asm/cpm1.h | 2 ++
arch/powerpc/sysdev/cpm1.c | 25 ++++++++++++++++++++++
3 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/gpio.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/gpio.txt
index 349f79f..1bcb151 100644
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/gpio.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/gpio.txt
@@ -13,8 +13,17 @@ Required properties:
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the port as GPIO controller.
+Optional property:
+- fsl,cpm1-gpio-irq-mask : For banks having interrupt capability (like port C
+ on CPM1), this item tells which ports have an associated interrupt (ports are
+ listed in the same order as in PCINT register)
+- interrupts : This property provides the list of interrupt for each GPIO having
+ one as described by the fsl,cpm1-gpio-irq-mask property. There should be as
+ many interrupts as number of ones in the mask property. The first interrupt in
+ the list corresponds to the most significant bit of the mask.
+- interrupt-parent : Parent for the above interrupt property.
-Example of three SOC GPIO banks defined as gpio-controller nodes:
+Example of four SOC GPIO banks defined as gpio-controller nodes:
CPM1_PIO_A: gpio-controller@950 {
#gpio-cells = <2>;
@@ -30,6 +39,16 @@ Example of three SOC GPIO banks defined as gpio-controller nodes:
gpio-controller;
};
+ CPM1_PIO_C: gpio-controller@960 {
+ #gpio-cells = <2>;
+ compatible = "fsl,cpm1-pario-bank-c";
+ reg = <0x960 0x10>;
+ fsl,cpm1-gpio-irq-mask = <0x0fff>;
+ interrupts = <1 2 6 9 10 11 14 15 23 24 26 31>;
+ interrupt-parent = <&CPM_PIC>;
+ gpio-controller;
+ };
+
CPM1_PIO_E: gpio-controller@ac8 {
#gpio-cells = <2>;
compatible = "fsl,cpm1-pario-bank-e";
diff --git a/arch/powerpc/include/asm/cpm1.h b/arch/powerpc/include/asm/cpm1.h
index 8ee4211..14ad378 100644
--- a/arch/powerpc/include/asm/cpm1.h
+++ b/arch/powerpc/include/asm/cpm1.h
@@ -560,6 +560,8 @@ typedef struct risc_timer_pram {
#define CPM_PIN_SECONDARY 2
#define CPM_PIN_GPIO 4
#define CPM_PIN_OPENDRAIN 8
+#define CPM_PIN_FALLEDGE 16
+#define CPM_PIN_ANYEDGE 0
enum cpm_port {
CPM_PORTA,
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index 986cd11..c651e66 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -377,6 +377,10 @@ static void cpm1_set_pin16(int port, int pin, int flags)
setbits16(&iop->odr_sor, pin);
else
clrbits16(&iop->odr_sor, pin);
+ if (flags & CPM_PIN_FALLEDGE)
+ setbits16(&iop->intr, pin);
+ else
+ clrbits16(&iop->intr, pin);
}
}
@@ -528,6 +532,9 @@ struct cpm1_gpio16_chip {
/* shadowed data register to clear/set bits safely */
u16 cpdata;
+
+ /* IRQ associated with Pins when relevant */
+ int irq[16];
};
static void cpm1_gpio16_save_regs(struct of_mm_gpio_chip *mm_gc)
@@ -578,6 +585,14 @@ static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
spin_unlock_irqrestore(&cpm1_gc->lock, flags);
}
+static int cpm1_gpio16_to_irq(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio16_chip *cpm1_gc = gpiochip_get_data(&mm_gc->gc);
+
+ return cpm1_gc->irq[gpio] ? : -ENXIO;
+}
+
static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
@@ -618,6 +633,7 @@ int cpm1_gpiochip_add16(struct device_node *np)
struct cpm1_gpio16_chip *cpm1_gc;
struct of_mm_gpio_chip *mm_gc;
struct gpio_chip *gc;
+ u16 mask;
cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
if (!cpm1_gc)
@@ -625,6 +641,14 @@ int cpm1_gpiochip_add16(struct device_node *np)
spin_lock_init(&cpm1_gc->lock);
+ if (!of_property_read_u16(np, "fsl,cpm1-gpio-irq-mask", &mask)) {
+ int i, j;
+
+ for (i = 0, j = 0; i < 16; i++)
+ if (mask & (1 << (15 - i)))
+ cpm1_gc->irq[i] = irq_of_parse_and_map(np, j++);
+ }
+
mm_gc = &cpm1_gc->mm_gc;
gc = &mm_gc->gc;
@@ -634,6 +658,7 @@ int cpm1_gpiochip_add16(struct device_node *np)
gc->direction_output = cpm1_gpio16_dir_out;
gc->get = cpm1_gpio16_get;
gc->set = cpm1_gpio16_set;
+ gc->to_irq = cpm1_gpio16_to_irq;
return of_mm_gpiochip_add_data(np, mm_gc, cpm1_gc);
}
--
2.2.2
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply related
* Re: [PATCH v2 25/30] arm: dts: mt7623: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi
From: Sean Wang @ 2017-05-01 7:06 UTC (permalink / raw)
To: Rob Herring
Cc: matthias.bgg, john, mark.rutland, linux, linus.walleij,
devicetree, linux-mediatek, linux-arm-kernel, linux-gpio,
linux-kernel
In-Reply-To: <20170428203025.gdrtbudfzwy5z4h5@rob-hp-laptop>
On Fri, 2017-04-28 at 15:30 -0500, Rob Herring wrote:
> On Wed, Apr 26, 2017 at 05:26:09PM +0800, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > There are 2 versions of the SoC. MT7623N is almost identical to MT7623A
> > but has some additional multimedia features. The reference boards are
> > available as NAND or MMC and might have a different ethernet setup. In
> > order to reduce the duplication of devicetree code we add an intermediate
> > dtsi file for these reference boards. Additionally Mediatek pointed out,
> > that the EVB is yet another board and the board in question is infact the
> > RFB. Take this into account while renaming the files.
>
> You are breaking compatibility with existing DTs. Just document which
> flavor you want "mediatek,mt7623" to refer to and add the new one. Or
> just add 2 new strings but keep the old one.
>
Hi Rob,
really appreciate your patient guidance.
I prefer to using the way one you suggest: the old one is kept and
refers to mt7623n SoC and new one will be added for mt7623a Soc.
Sean
> >
> > Signed-off-by: John Crispin <john@phrozen.org>
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> >
> > ---
> > Documentation/devicetree/bindings/arm/mediatek.txt | 6 ++--
> > arch/arm/boot/dts/Makefile | 2 +-
> > arch/arm/boot/dts/mt7623-evb.dts | 33 ----------------------
> > arch/arm/boot/dts/mt7623n-rfb-nand.dts | 21 ++++++++++++++
> > arch/arm/boot/dts/mt7623n-rfb.dtsi | 29 +++++++++++++++++++
> > arch/arm/mach-mediatek/mediatek.c | 4 +--
> > arch/arm/mach-mediatek/platsmp.c | 2 +-
> > 7 files changed, 57 insertions(+), 40 deletions(-)
> > delete mode 100644 arch/arm/boot/dts/mt7623-evb.dts
> > create mode 100644 arch/arm/boot/dts/mt7623n-rfb-nand.dts
> > create mode 100644 arch/arm/boot/dts/mt7623n-rfb.dtsi
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
> > index c860b24..7f7c804 100644
> > --- a/Documentation/devicetree/bindings/arm/mediatek.txt
> > +++ b/Documentation/devicetree/bindings/arm/mediatek.txt
> > @@ -12,7 +12,7 @@ compatible: Must contain one of
> > "mediatek,mt6592"
> > "mediatek,mt6755"
> > "mediatek,mt6795"
> > - "mediatek,mt7623"
> > + "mediatek,mt7623n"
> > "mediatek,mt8127"
> > "mediatek,mt8135"
> > "mediatek,mt8173"
^ permalink raw reply
* Re: [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi
From: Sean Wang @ 2017-05-01 6:58 UTC (permalink / raw)
To: Rob Herring
Cc: matthias.bgg, john, mark.rutland, linux, linus.walleij,
devicetree, linux-mediatek, linux-arm-kernel, linux-gpio,
linux-kernel
In-Reply-To: <20170428203727.m6jm5w6nb2iirxih@rob-hp-laptop>
On Fri, 2017-04-28 at 15:37 -0500, Rob Herring wrote:
> On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > Banana Pi team in Sinovoip Co., Limited which are dedicated to
> > design and manufacture open hardware product.
> >
> > Website: http://www.banana-pi.org/
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index ec0bfb9..8ca0f3c 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -44,6 +44,7 @@ avia avia semiconductor
> > avic Shanghai AVIC Optoelectronics Co., Ltd.
> > axentia Axentia Technologies AB
> > axis Axis Communications AB
> > +bananapi Banana Pi SINOVOP CO., LIMITED
>
> s/SINOVOP/SINOVOIP/
Hi Rob,
thanks for your careful reviewing , i will correct it in the next
version.
BTW, Could those related dts changes go through your tree if everything
looks good? Because I find Matthias have been inactive for a while and
the latest branch in his tree seems still staying on 4.10.
Sean
>
> > boe BOE Technology Group Co., Ltd.
> > bosch Bosch Sensortec GmbH
> > boundary Boundary Devices Inc.
> > --
> > 1.9.1
> >
^ permalink raw reply
* Re: [PATCH v2 02/30] pinctrl: mediatek: reuse pinctrl driver for mt7623
From: Sean Wang @ 2017-05-01 6:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Matthias Brugger, John Crispin, Mark Rutland,
Russell King, devicetree@vger.kernel.org,
moderated list:ARM/Mediatek SoC support,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdbR-k3wgD+7KoV6d7yg1uduXpa9MO0+woEibQYPeYzgYw@mail.gmail.com>
On Fri, 2017-04-28 at 10:01 +0200, Linus Walleij wrote:
> On Wed, Apr 26, 2017 at 11:25 AM, <sean.wang@mediatek.com> wrote:
>
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > mt7623 pinctrl driver can be compatible with mt2701 one,
> > so the patch reuses the driver and deletes those redundant
> > ones.
> >
> > Cc: John Crispin <john@phrozen.org>
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>
> Partly correct.
>
> > "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
> > - "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl.
>
> NO don't do this.
>
> "compatible" means exactly this: this hardware is compatible with
> this driver. That is why we have it!
>
> So instead of mt7623 pretending to be mt2701, let the mt2701 driver
> list that it is compatible with mt7623, simple.
>
> So patch pinctrl-mt2701.c mt2701_pctrl_match[] instead.
>
Hi Linus,
really appreciate your clear guidance and reviewing on this
I will fix it up in the next version
Sean
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: Add STM32 MDMA driver
From: Vinod Koul @ 2017-05-01 6:12 UTC (permalink / raw)
To: Pierre Yves MORDRET
Cc: M'boumba Cedric Madianga, mark.rutland@arm.com,
devicetree@vger.kernel.org, Alexandre TORGUE,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <d1d92f79-ce3c-e057-7f47-1fd5e42fa5dc@st.com>
On Wed, Apr 26, 2017 at 12:35:46PM +0000, Pierre Yves MORDRET wrote:
> On 04/06/2017 09:08 AM, Vinod Koul wrote:
> >> +static int stm32_mdma_get_width(struct stm32_mdma_chan *chan,
> >> + enum dma_slave_buswidth width)
> >> +{
> >> + switch (width) {
> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> >> + return STM32_MDMA_BYTE;
> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> >> + return STM32_MDMA_HALF_WORD;
> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> >> + return STM32_MDMA_WORD;
> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> >> + return STM32_MDMA_DOUBLE_WORD;
> >
> > IIUC we can do this with ffs()
>
> I don't believe we can do that. This function translates DMA_SLAVE enum
> into internal register representation.
Yes and internal represenation seemed to be ffs() of dmanegine one.
> >> +subsys_initcall(stm32_mdma_init);
> >
> > why subsys?
> >
>
> subsys_initcall level is to ensure MDMA is going to be probed before its
> clients
Please use deffered probe approach for that
--
~Vinod
^ permalink raw reply
* Re: [PATCH 2/5] dmaengine: Add STM32 DMAMUX driver
From: Vinod Koul @ 2017-05-01 6:03 UTC (permalink / raw)
To: Pierre Yves MORDRET
Cc: M'boumba Cedric Madianga, mark.rutland@arm.com,
devicetree@vger.kernel.org, Alexandre TORGUE,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <d18cb12d-1fd1-39d2-501a-18c000b9982e@st.com>
On Wed, Apr 26, 2017 at 09:17:37AM +0000, Pierre Yves MORDRET wrote:
> >> +
> >> + ret = of_property_read_u32(node, "dma-channels",
> >> + &dmamux->dmamux_channels);
> >
> > can we have property_xxx calls alone, that way driver is not strictly
> > dependent on of
>
> Can you please explain what you are asking for ? Not sure to understand
> correctly.
Use device_property_read_u32() which is a generic property API.
> >> +static int __init stm32_dmamux_init(void)
> >> +{
> >> + return platform_driver_register(&stm32_dmamux_driver);
> >> +}
> >> +arch_initcall(stm32_dmamux_init);
> >
> > why not module init, wouldnt defer probe solve the dependencies
> >
>
> The reason behind many devices (device_initcall level) rely on DMAs. If
> init is deferred DMAMUX driver will be probed twice if dependents rely
> on it. This sounds not a good call. This explains arch_initcall level.
Why not deferred probe was introduced to help with dependencies...
--
~Vinod
^ permalink raw reply
* [PATCH v2 2/2] ARM: sun8i: a83t: Replace underscores with hyphens in pinmux node names
From: Chen-Yu Tsai @ 2017-05-01 3:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170501031408.10469-1-wens-jdAy2FN1RRM@public.gmane.org>
We should use hyphens and not underscores in device node names.
Replace the ones that were just added.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index aecde8be53bc..c0a1e4f74b89 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -174,7 +174,7 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
- mmc0_pins: mmc0_pins {
+ mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
function = "mmc0";
@@ -182,12 +182,12 @@
bias-pull-up;
};
- uart0_pb_pins: uart0_pb_pins {
+ uart0_pb_pins: uart0-pb-pins {
pins = "PB9", "PB10";
function = "uart0";
};
- uart0_pf_pins: uart0_pf_pins {
+ uart0_pf_pins: uart0-pf-pins {
pins = "PF2", "PF4";
function = "uart0";
};
--
2.11.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: sun8i: a83t: Drop leading zeroes from device node addresses
From: Chen-Yu Tsai @ 2017-05-01 3:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170501031408.10469-1-wens-jdAy2FN1RRM@public.gmane.org>
Kbuild now complains about leading zeroes in the address portion of
device node names.
Get rid of them all, except for the uart device node. U-boot currently
hard codes the device node path. We can remove the leading zero for
the uart once we teach U-boot to use the aliases or stdout-path
property.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5f5c10c04dd3..aecde8be53bc 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -162,7 +162,7 @@
#size-cells = <1>;
ranges;
- pio: pinctrl@01c20800 {
+ pio: pinctrl@1c20800 {
compatible = "allwinner,sun8i-a83t-pinctrl";
interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
@@ -193,7 +193,7 @@
};
};
- timer@01c20c00 {
+ timer@1c20c00 {
compatible = "allwinner,sun4i-a10-timer";
reg = <0x01c20c00 0xa0>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
@@ -201,7 +201,7 @@
clocks = <&osc24M>;
};
- watchdog@01c20ca0 {
+ watchdog@1c20ca0 {
compatible = "allwinner,sun6i-a31-wdt";
reg = <0x01c20ca0 0x20>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
@@ -218,7 +218,7 @@
status = "disabled";
};
- gic: interrupt-controller@01c81000 {
+ gic: interrupt-controller@1c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
<0x01c82000 0x2000>,
--
2.11.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 0/2] ARM: sun8i: a83t: device tree cleanup
From: Chen-Yu Tsai @ 2017-05-01 3:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Maxime,
Here's v2 of the A83T device tree cleanup patches. I dropped the change
to the uart device node name for now.
Also added a second patch changing the underscores in device node names
I just added to hyphens. AFAIK that is the preferred naming scheme.
Please squash it into "ARM: sun8i: a83t: Rename pinmux setting names".
Regards
ChenYu
Chen-Yu Tsai (2):
ARM: sun8i: a83t: Drop leading zeroes from device node addresses
ARM: sun8i: a83t: Replace underscores with hyphens in pinmux node
names
arch/arm/boot/dts/sun8i-a83t.dtsi | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--
2.11.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
* Re: [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: David Miller @ 2017-05-01 2:48 UTC (permalink / raw)
To: eric-WhKQ6XTQaPysTnJN9+BGXg
Cc: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
andrew-g2DYL2Zd6BY, netdev-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
rjui-dY08KVG/lbpWk0Htik3J/w, sbranden-dY08KVG/lbpWk0Htik3J/w,
jonmason-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <20170428222204.7103-1-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
From: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Date: Fri, 28 Apr 2017 15:22:03 -0700
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> v2: Reorder the entry in the docs (suggestion by Scott Branden), add
> missing '"'
>
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
The second patch with the DTS file update doesn't apply cleanly
at all to net-next.
So I'm dropping this series.
--
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] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
From: Paul Kocialkowski @ 2017-04-30 20:56 UTC (permalink / raw)
To: Heiko Stuebner, briannorris-F7+t8E8rja9g9hUCZPvPmw
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Russell King
In-Reply-To: <2369975.a4dWayqU5d@phil>
[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]
Le dimanche 30 avril 2017 à 22:37 +0200, Heiko Stuebner a écrit :
> Hi Paul,
>
> Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
> > This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
> > dtsi since it only concerns rk3288 veyron Chromebooks.
> >
> > Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
> > and don't use this dtsi, that only makes sense when used with
> > rk3288-veyron-chromebook anyway.
>
> That isn't true. The gru series (rk3399-based) also uses the
> sbs-battery [0]. And while it is currently limited to Rockchip-based
> Chromebooks it is nevertheless used on more than one platform, so
> the probability is high that it will be used in future series as well.
That's good to know, but as pointed out, other cros devices are using a sbs
battery without this header, so such a generic name isn't really a good fit.
Note that &charger has to be defined (after my subsequent patches), which it is
for devices that also include rk3288-veyron-chromebook, but not necessarily
others.
Overall, I think having one -sbs dtsi file makes sense here because there is
already a rk3288-veyron-chromebook dtsi that veyron chromebooks use. That file
cannot contain the battery bindings because minnie has a different one and it
would be a bit silly to copy it over all devices. That definitely makes sense.
As for other devices, I don't see why we should have a separate include file for
the battery instead of having it in the device's dts. I think this should be the
case on gru/kevin.
Also maybe not *all* gru-based devices will turn out to use a SBS battery, so it
seems early to include this header in the gru dtsi. One last point, gru/kevin
currently don't define a charger, which will break my subsequent patch (that is
however needed for the veyrons that use this file).
To me, it seems that there's little advantage and major drawbacks in keeping
this file the way it is.
> Also, it might be nice to also include some Chromeos people (there should
> be some in the git logs, like Brian who submitted the Gru patches), as they
> might be able to provide more detailed input.
That's a good point, thanks for including them.
>
> Heiko
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/a
> rch/arm64/boot/dts/rockchip/rk3399-gru.dtsi#n886
>
> >
> > Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
> > ---
> > .../boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-sbs.dtsi} | 0
> > arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2
> > +-
> > arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2
> > +-
> > arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2
> > +-
> > arch/arm/boot/dts/rk3288-veyron-speedy.dts | 2
> > +-
> > 5 files changed, 4 insertions(+), 4 deletions(-)
> > rename arch/arm/boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-
> > sbs.dtsi} (100%)
> >
> > diff --git a/arch/arm/boot/dts/cros-ec-sbs.dtsi b/arch/arm/boot/dts/rk3288-
> > veyron-chromebook-sbs.dtsi
> > similarity index 100%
> > rename from arch/arm/boot/dts/cros-ec-sbs.dtsi
> > rename to arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > index d33f5763c39c..f217a978e47a 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > @@ -45,7 +45,7 @@
> > /dts-v1/;
> >
> > #include "rk3288-veyron-chromebook.dtsi"
> > -#include "cros-ec-sbs.dtsi"
> > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> >
> > / {
> > model = "Google Jaq";
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > index cdea751f2a8c..bec607574165 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > @@ -44,7 +44,7 @@
> >
> > /dts-v1/;
> > #include "rk3288-veyron-chromebook.dtsi"
> > -#include "cros-ec-sbs.dtsi"
> > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> >
> > / {
> > model = "Google Jerry";
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > index 995cff42fa43..c81ad5bf1121 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > @@ -44,7 +44,7 @@
> >
> > /dts-v1/;
> > #include "rk3288-veyron-chromebook.dtsi"
> > -#include "cros-ec-sbs.dtsi"
> > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> >
> > / {
> > model = "Google Pinky";
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > index cc0b78cefe34..8aea9c3ff6e2 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > @@ -44,7 +44,7 @@
> >
> > /dts-v1/;
> > #include "rk3288-veyron-chromebook.dtsi"
> > -#include "cros-ec-sbs.dtsi"
> > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> >
> > / {
> > model = "Google Speedy";
> >
>
>
--
Paul Kocialkowski, developer of free digital technology and hardware support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 1/2] input: keyboard: DT bindings for the D-Link DIR-685 touchpad
From: Linus Walleij @ 2017-04-30 20:55 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: Linus Walleij, devicetree
This adds device tree bindings for the D-Link DIR-685 touchpad.
It's a simple homebrewn touchpad on I2C.
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../bindings/input/dlink,dir685-touchpad.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/dlink,dir685-touchpad.txt
diff --git a/Documentation/devicetree/bindings/input/dlink,dir685-touchpad.txt b/Documentation/devicetree/bindings/input/dlink,dir685-touchpad.txt
new file mode 100644
index 000000000000..25bc538a6e39
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlink,dir685-touchpad.txt
@@ -0,0 +1,21 @@
+* D-Link DIR-685 Touchpad
+
+This is a I2C one-off touchpad controller based on the Cypress Semiconductor
+CY8C214 MCU with some firmware in its internal 8KB flash. The circuit
+board inside the router is named E119921.
+
+The touchpad device node should be placed inside an I2C bus node.
+
+Required properties:
+- compatible: must be "dlink,dir685-touchpad"
+- reg: the I2C address of the touchpad
+- interrupts: reference to the interrupt number
+
+Example:
+
+touchpad@26 {
+ compatible = "dlink,dir685-touchpad";
+ reg = <0x26>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+};
--
2.9.3
^ 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