* [PATCH v4 6/8] i2c: use an IRQ to report Host Notify events, not alert
From: Benjamin Tissoires @ 2016-10-10 16:42 UTC (permalink / raw)
To: Wolfram Sang, Dmitry Torokhov
Cc: Jean Delvare, Jonathan Corbet, KT Liao, linux-i2c, linux-input,
linux-doc, linux-kernel
In-Reply-To: <1476117755-8113-1-git-send-email-benjamin.tissoires@redhat.com>
The current SMBus Host Notify implementation relies on .alert() to
relay its notifications. However, the use cases where SMBus Host
Notify is needed currently is to signal data ready on touchpads.
This is closer to an IRQ than a custom API through .alert().
Given that the 2 touchpad manufacturers (Synaptics and Elan) that
use SMBus Host Notify don't put any data in the SMBus payload, the
concept actually matches one to one.
Benefits are multiple:
- simpler code and API: the client just needs to get the IRQ through
i2c_smbus_host_notify_to_irq(), nothing needs to be added in the
adapter beside internally enabling it.
- no more specific workqueue, the threading is handled by IRQ core
directly (when required)
- no more races when removing the device (the drivers are already
required to disable irq on remove)
- simpler handling for drivers: use plain regular IRQs
- no more dependency on i2c-smbus for i2c-i801 (and any other adapter)
- the IRQ domain is created automatically when the adapter exports
the Host Notify capability, but the IRQ are allocated on demand
- the domain is automatically destroyed on remove
- fewer lines of code (minus 20, yeah!)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
new in v4
---
Documentation/i2c/smbus-protocol | 10 ++--
drivers/i2c/busses/i2c-i801.c | 31 +++--------
drivers/i2c/i2c-core.c | 117 +++++++++++++++++++++++++++++++++++++++
drivers/i2c/i2c-smbus.c | 102 ----------------------------------
include/linux/i2c-smbus.h | 27 ---------
include/linux/i2c.h | 5 ++
6 files changed, 135 insertions(+), 157 deletions(-)
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index 14d4ec1..8a29ba3 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -200,10 +200,12 @@ alerting device's address.
[S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
This is implemented in the following way in the Linux kernel:
-* I2C bus drivers which support SMBus Host Notify should call
- i2c_setup_smbus_host_notify() to setup SMBus Host Notify support.
-* I2C drivers for devices which can trigger SMBus Host Notify should implement
- the optional alert() callback.
+* I2C bus drivers which support SMBus Host Notify should report
+ I2C_FUNC_SMBUS_HOST_NOTIFY.
+* I2C drivers for devices which can trigger SMBus Host Notify should request
+ a Host Notify IRQ through i2c_smbus_host_notify_to_irq().
+
+There is currently no way to retrieve the data parameter from the client.
Packet Error Checking (PEC)
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 42a6a89..a016b48 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -266,7 +266,6 @@ struct i801_priv {
*/
bool acpi_reserved;
struct mutex acpi_lock;
- struct smbus_host_notify *host_notify;
};
#define FEATURE_SMBUS_PEC BIT(0)
@@ -582,10 +581,10 @@ static irqreturn_t i801_host_notify_isr(struct i801_priv *priv)
/*
* With the tested platforms, reading SMBNTFDDAT (22 + (p)->smba)
- * always returns 0 and is safe to read.
- * We just use 0 given we have no use of the data right now.
+ * always returns 0. Our current implementation doesn't provide
+ * data, so we just ignore it.
*/
- i2c_handle_smbus_host_notify(priv->host_notify, addr, 0);
+ i2c_handle_smbus_host_notify(&priv->adapter, addr);
/* clear Host Notify bit and return */
outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
@@ -941,17 +940,12 @@ static u32 i801_func(struct i2c_adapter *adapter)
I2C_FUNC_SMBUS_HOST_NOTIFY : 0);
}
-static int i801_enable_host_notify(struct i2c_adapter *adapter)
+static void i801_enable_host_notify(struct i2c_adapter *adapter)
{
struct i801_priv *priv = i2c_get_adapdata(adapter);
if (!(priv->features & FEATURE_HOST_NOTIFY))
- return -ENOTSUPP;
-
- if (!priv->host_notify)
- priv->host_notify = i2c_setup_smbus_host_notify(adapter);
- if (!priv->host_notify)
- return -ENOMEM;
+ return;
priv->original_slvcmd = inb_p(SMBSLVCMD(priv));
@@ -961,8 +955,6 @@ static int i801_enable_host_notify(struct i2c_adapter *adapter)
/* clear Host Notify bit to allow a new notification */
outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
-
- return 0;
}
static void i801_disable_host_notify(struct i801_priv *priv)
@@ -1631,14 +1623,7 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
return err;
}
- /*
- * Enable Host Notify for chips that supports it.
- * It is done after i2c_add_adapter() so that we are sure the work queue
- * is not used if i2c_add_adapter() fails.
- */
- err = i801_enable_host_notify(&priv->adapter);
- if (err && err != -ENOTSUPP)
- dev_warn(&dev->dev, "Unable to enable SMBus Host Notify\n");
+ i801_enable_host_notify(&priv->adapter);
i801_probe_optional_slaves(priv);
/* We ignore errors - multiplexing is optional */
@@ -1691,9 +1676,7 @@ static int i801_resume(struct device *dev)
struct i801_priv *priv = pci_get_drvdata(pci_dev);
int err;
- err = i801_enable_host_notify(&priv->adapter);
- if (err && err != -ENOTSUPP)
- dev_warn(dev, "Unable to enable SMBus Host Notify\n");
+ i801_enable_host_notify(&priv->adapter);
return 0;
}
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 79ce9e1..9d5bcf9 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -65,6 +65,9 @@
#define I2C_ADDR_OFFSET_TEN_BIT 0xa000
#define I2C_ADDR_OFFSET_SLAVE 0x1000
+#define I2C_ADDR_7BITS_MAX 0x77
+#define I2C_ADDR_7BITS_COUNT (I2C_ADDR_7BITS_MAX + 1)
+
/* core_lock protects i2c_adapter_idr, and guarantees
that device detection, deletion of detected devices, and attach_adapter
calls are serialized */
@@ -1781,6 +1784,110 @@ static const struct i2c_lock_operations i2c_adapter_lock_ops = {
.unlock_bus = i2c_adapter_unlock_bus,
};
+static void i2c_host_notify_irq_teardown(struct i2c_adapter *adap)
+{
+ struct irq_domain *domain = adap->host_notify_domain;
+ irq_hw_number_t hwirq;
+
+ if (!domain)
+ return;
+
+ for (hwirq = 0 ; hwirq < I2C_ADDR_7BITS_COUNT ; hwirq++)
+ irq_dispose_mapping(irq_find_mapping(domain, hwirq));
+
+ irq_domain_remove(domain);
+ adap->host_notify_domain = NULL;
+}
+
+static int i2c_host_notify_irq_map(struct irq_domain *h,
+ unsigned int virq,
+ irq_hw_number_t hw_irq_num)
+{
+ irq_set_chip_and_handler(virq, &dummy_irq_chip, handle_simple_irq);
+
+ return 0;
+}
+
+static struct irq_domain_ops i2c_host_notify_irq_ops = {
+ .map = i2c_host_notify_irq_map,
+};
+
+static int i2c_setup_host_notify_irq_domain(struct i2c_adapter *adap)
+{
+ struct irq_domain *domain;
+
+ if (!i2c_check_functionality(adap, I2C_FUNC_SMBUS_HOST_NOTIFY))
+ return 0;
+
+ domain = irq_domain_create_linear(adap->dev.fwnode,
+ I2C_ADDR_7BITS_COUNT,
+ &i2c_host_notify_irq_ops, adap);
+ if (!domain)
+ return -ENOMEM;
+
+ adap->host_notify_domain = domain;
+
+ return 0;
+}
+
+/**
+ * i2c_handle_smbus_host_notify - Forward a Host Notify event to the correct
+ * I2C client.
+ * @adap: the adapter
+ * @addr: the I2C address of the notifying device
+ * Context: can't sleep
+ *
+ * Helper function to be called from an I2C bus driver's interrupt
+ * handler. It will schedule the Host Notify IRQ.
+ */
+int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short addr)
+{
+ int irq;
+
+ if (!adap)
+ return -EINVAL;
+
+ irq = irq_find_mapping(adap->host_notify_domain, addr);
+ if (irq <= 0)
+ return -ENXIO;
+
+ generic_handle_irq(irq);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(i2c_handle_smbus_host_notify);
+
+/**
+ * i2c_smbus_host_notify_to_irq - Gets a Host Notify IRQ number associated to
+ * the I2C client.
+ * @client: the I2C client
+ *
+ * Will return a valid IRQ number or an error. The Host Notify interrupts
+ * only work currently with 7 bits addresses.
+ */
+int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
+{
+ struct i2c_adapter *adap = client->adapter;
+ unsigned int irq;
+
+ if (!adap->host_notify_domain)
+ return -ENXIO;
+
+ if (client->flags & I2C_CLIENT_TEN) {
+ dev_err(&client->dev,
+ "Host Notify not supported on 10 bits addresses.\n");
+ return -EINVAL;
+ }
+
+ irq = irq_find_mapping(adap->host_notify_domain, client->addr);
+ if (!irq)
+ irq = irq_create_mapping(adap->host_notify_domain,
+ client->addr);
+
+ return irq > 0 ? irq : -ENXIO;
+}
+EXPORT_SYMBOL_GPL(i2c_smbus_host_notify_to_irq);
+
static int i2c_register_adapter(struct i2c_adapter *adap)
{
int res = -EINVAL;
@@ -1812,6 +1919,14 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
if (adap->timeout == 0)
adap->timeout = HZ;
+ /* register soft irqs for Host Notify */
+ res = i2c_setup_host_notify_irq_domain(adap);
+ if (res) {
+ pr_err("adapter '%s': can't create Host Notify IRQs (%d)\n",
+ adap->name, res);
+ goto out_list;
+ }
+
dev_set_name(&adap->dev, "i2c-%d", adap->nr);
adap->dev.bus = &i2c_bus_type;
adap->dev.type = &i2c_adapter_type;
@@ -2049,6 +2164,8 @@ void i2c_del_adapter(struct i2c_adapter *adap)
pm_runtime_disable(&adap->dev);
+ i2c_host_notify_irq_teardown(adap);
+
/* wait until all references to the device are gone
*
* FIXME: This is old code and should ideally be replaced by an
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index b0d2679..f9271c7 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -241,108 +241,6 @@ int i2c_handle_smbus_alert(struct i2c_client *ara)
}
EXPORT_SYMBOL_GPL(i2c_handle_smbus_alert);
-static void smbus_host_notify_work(struct work_struct *work)
-{
- struct alert_data alert;
- struct i2c_adapter *adapter;
- unsigned long flags;
- u16 payload;
- u8 addr;
- struct smbus_host_notify *data;
-
- data = container_of(work, struct smbus_host_notify, work);
-
- spin_lock_irqsave(&data->lock, flags);
- payload = data->payload;
- addr = data->addr;
- adapter = data->adapter;
-
- /* clear the pending bit and release the spinlock */
- data->pending = false;
- spin_unlock_irqrestore(&data->lock, flags);
-
- if (!adapter || !addr)
- return;
-
- alert.type = I2C_PROTOCOL_SMBUS_HOST_NOTIFY;
- alert.addr = addr;
- alert.data = payload;
-
- device_for_each_child(&adapter->dev, &alert, smbus_do_alert);
-}
-
-/**
- * i2c_setup_smbus_host_notify - Allocate a new smbus_host_notify for the given
- * I2C adapter.
- * @adapter: the adapter we want to associate a Host Notify function
- *
- * Returns a struct smbus_host_notify pointer on success, and NULL on failure.
- * The resulting smbus_host_notify must not be freed afterwards, it is a
- * managed resource already.
- */
-struct smbus_host_notify *i2c_setup_smbus_host_notify(struct i2c_adapter *adap)
-{
- struct smbus_host_notify *host_notify;
-
- host_notify = devm_kzalloc(&adap->dev, sizeof(struct smbus_host_notify),
- GFP_KERNEL);
- if (!host_notify)
- return NULL;
-
- host_notify->adapter = adap;
-
- spin_lock_init(&host_notify->lock);
- INIT_WORK(&host_notify->work, smbus_host_notify_work);
-
- return host_notify;
-}
-EXPORT_SYMBOL_GPL(i2c_setup_smbus_host_notify);
-
-/**
- * i2c_handle_smbus_host_notify - Forward a Host Notify event to the correct
- * I2C client.
- * @host_notify: the struct host_notify attached to the relevant adapter
- * @addr: the I2C address of the notifying device
- * @data: the payload of the notification
- * Context: can't sleep
- *
- * Helper function to be called from an I2C bus driver's interrupt
- * handler. It will schedule the Host Notify work, in turn calling the
- * corresponding I2C device driver's alert function.
- *
- * host_notify should be a valid pointer previously returned by
- * i2c_setup_smbus_host_notify().
- */
-int i2c_handle_smbus_host_notify(struct smbus_host_notify *host_notify,
- unsigned short addr, unsigned int data)
-{
- unsigned long flags;
- struct i2c_adapter *adapter;
-
- if (!host_notify || !host_notify->adapter)
- return -EINVAL;
-
- adapter = host_notify->adapter;
-
- spin_lock_irqsave(&host_notify->lock, flags);
-
- if (host_notify->pending) {
- spin_unlock_irqrestore(&host_notify->lock, flags);
- dev_warn(&adapter->dev, "Host Notify already scheduled.\n");
- return -EBUSY;
- }
-
- host_notify->payload = data;
- host_notify->addr = addr;
-
- /* Mark that there is a pending notification and release the lock */
- host_notify->pending = true;
- spin_unlock_irqrestore(&host_notify->lock, flags);
-
- return schedule_work(&host_notify->work);
-}
-EXPORT_SYMBOL_GPL(i2c_handle_smbus_host_notify);
-
module_i2c_driver(smbalert_driver);
MODULE_AUTHOR("Jean Delvare <jdelvare@suse.de>");
diff --git a/include/linux/i2c-smbus.h b/include/linux/i2c-smbus.h
index c2e3324..a138502 100644
--- a/include/linux/i2c-smbus.h
+++ b/include/linux/i2c-smbus.h
@@ -50,31 +50,4 @@ 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);
-/**
- * smbus_host_notify - internal structure used by the Host Notify mechanism.
- * @adapter: the I2C adapter associated with this struct
- * @work: worker used to schedule the IRQ in the slave device
- * @lock: spinlock to check if a notification is already pending
- * @pending: flag set when a notification is pending (any new notification will
- * be rejected if pending is true)
- * @payload: the actual payload of the Host Notify event
- * @addr: the address of the slave device which raised the notification
- *
- * This struct needs to be allocated by i2c_setup_smbus_host_notify() and does
- * not need to be freed. Internally, i2c_setup_smbus_host_notify() uses a
- * managed resource to clean this up when the adapter get released.
- */
-struct smbus_host_notify {
- struct i2c_adapter *adapter;
- struct work_struct work;
- spinlock_t lock;
- bool pending;
- u16 payload;
- u8 addr;
-};
-
-struct smbus_host_notify *i2c_setup_smbus_host_notify(struct i2c_adapter *adap);
-int i2c_handle_smbus_host_notify(struct smbus_host_notify *host_notify,
- unsigned short addr, unsigned int data);
-
#endif /* _LINUX_I2C_SMBUS_H */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 4a4099d..5fbef64 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -30,6 +30,7 @@
#include <linux/device.h> /* for struct device */
#include <linux/sched.h> /* for completion */
#include <linux/mutex.h>
+#include <linux/irqdomain.h> /* for Host Notify IRQ */
#include <linux/of.h> /* for struct device_node */
#include <linux/swab.h> /* for swab16 */
#include <uapi/linux/i2c.h>
@@ -567,6 +568,8 @@ struct i2c_adapter {
struct i2c_bus_recovery_info *bus_recovery_info;
const struct i2c_adapter_quirks *quirks;
+
+ struct irq_domain *host_notify_domain;
};
#define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
@@ -738,6 +741,8 @@ static inline u8 i2c_8bit_addr_from_msg(const struct i2c_msg *msg)
return (msg->addr << 1) | (msg->flags & I2C_M_RD ? 1 : 0);
}
+int i2c_smbus_host_notify_to_irq(const struct i2c_client *client);
+int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short addr);
/**
* module_i2c_driver() - Helper macro for registering a modular I2C driver
* @__i2c_driver: i2c_driver struct
--
2.7.4
^ permalink raw reply related
* [PATCH v4 7/8] Input: elan_i2c - store the irq in struct elan_tp_data
From: Benjamin Tissoires @ 2016-10-10 16:42 UTC (permalink / raw)
To: Wolfram Sang, Dmitry Torokhov
Cc: Jean Delvare, Jonathan Corbet, KT Liao, linux-i2c, linux-input,
linux-doc, linux-kernel
In-Reply-To: <1476117755-8113-1-git-send-email-benjamin.tissoires@redhat.com>
And make sure we have one available.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
new in v4
---
drivers/input/mouse/elan_i2c_core.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index d15b338..6f16eb4 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -62,6 +62,7 @@ struct elan_tp_data {
struct i2c_client *client;
struct input_dev *input;
struct regulator *vcc;
+ int irq;
const struct elan_transport_ops *ops;
@@ -457,7 +458,7 @@ static int elan_update_firmware(struct elan_tp_data *data,
dev_dbg(&client->dev, "Starting firmware update....\n");
- disable_irq(client->irq);
+ disable_irq(data->irq);
data->in_fw_update = true;
retval = __elan_update_firmware(data, fw);
@@ -471,7 +472,7 @@ static int elan_update_firmware(struct elan_tp_data *data,
}
data->in_fw_update = false;
- enable_irq(client->irq);
+ enable_irq(data->irq);
return retval;
}
@@ -599,7 +600,7 @@ static ssize_t calibrate_store(struct device *dev,
if (retval)
return retval;
- disable_irq(client->irq);
+ disable_irq(data->irq);
data->mode |= ETP_ENABLE_CALIBRATE;
retval = data->ops->set_mode(client, data->mode);
@@ -645,7 +646,7 @@ out_disable_calibrate:
retval = error;
}
out:
- enable_irq(client->irq);
+ enable_irq(data->irq);
mutex_unlock(&data->sysfs_mutex);
return retval ?: count;
}
@@ -711,7 +712,7 @@ static ssize_t acquire_store(struct device *dev, struct device_attribute *attr,
if (retval)
return retval;
- disable_irq(client->irq);
+ disable_irq(data->irq);
data->baseline_ready = false;
@@ -753,7 +754,7 @@ out_disable_calibrate:
retval = error;
}
out:
- enable_irq(client->irq);
+ enable_irq(data->irq);
mutex_unlock(&data->sysfs_mutex);
return retval ?: count;
}
@@ -1026,6 +1027,9 @@ static int elan_probe(struct i2c_client *client,
struct elan_tp_data *data;
unsigned long irqflags;
int error;
+ int irq;
+
+ irq = client->irq;
if (IS_ENABLED(CONFIG_MOUSE_ELAN_I2C_I2C) &&
i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
@@ -1041,6 +1045,11 @@ static int elan_probe(struct i2c_client *client,
return -EIO;
}
+ if (irq <= 0) {
+ dev_err(dev, "no IRQ provided.\n");
+ return -ENODEV;
+ }
+
data = devm_kzalloc(&client->dev, sizeof(struct elan_tp_data),
GFP_KERNEL);
if (!data)
@@ -1049,6 +1058,7 @@ static int elan_probe(struct i2c_client *client,
i2c_set_clientdata(client, data);
data->ops = transport_ops;
+ data->irq = irq;
data->client = client;
init_completion(&data->fw_completion);
mutex_init(&data->sysfs_mutex);
@@ -1121,12 +1131,12 @@ static int elan_probe(struct i2c_client *client,
*/
irqflags = client->dev.of_node ? 0 : IRQF_TRIGGER_FALLING;
- error = devm_request_threaded_irq(&client->dev, client->irq,
+ error = devm_request_threaded_irq(&client->dev, data->irq,
NULL, elan_isr,
irqflags | IRQF_ONESHOT,
client->name, data);
if (error) {
- dev_err(&client->dev, "cannot register irq=%d\n", client->irq);
+ dev_err(&client->dev, "cannot register irq=%d\n", data->irq);
return error;
}
@@ -1179,12 +1189,12 @@ static int __maybe_unused elan_suspend(struct device *dev)
if (ret)
return ret;
- disable_irq(client->irq);
+ disable_irq(data->irq);
if (device_may_wakeup(dev)) {
ret = elan_sleep(data);
/* Enable wake from IRQ */
- data->irq_wake = (enable_irq_wake(client->irq) == 0);
+ data->irq_wake = (enable_irq_wake(data->irq) == 0);
} else {
ret = elan_disable_power(data);
}
@@ -1200,7 +1210,7 @@ static int __maybe_unused elan_resume(struct device *dev)
int error;
if (device_may_wakeup(dev) && data->irq_wake) {
- disable_irq_wake(client->irq);
+ disable_irq_wake(data->irq);
data->irq_wake = false;
}
@@ -1215,7 +1225,7 @@ static int __maybe_unused elan_resume(struct device *dev)
dev_err(dev, "initialize when resuming failed: %d\n", error);
err:
- enable_irq(data->client->irq);
+ enable_irq(data->irq);
return error;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 8/8] Input: elan_i2c - add Host Notify support
From: Benjamin Tissoires @ 2016-10-10 16:42 UTC (permalink / raw)
To: Wolfram Sang, Dmitry Torokhov
Cc: Jean Delvare, Jonathan Corbet, KT Liao, linux-i2c, linux-input,
linux-doc, linux-kernel
In-Reply-To: <1476117755-8113-1-git-send-email-benjamin.tissoires@redhat.com>
The Thinkpad series 13 uses Host Notify to report the interrupt.
Add elan_smb_alert() to handle those interrupts and disable the irq
handling on this case.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
new in v4 (was submitted on linux-input with the .alert callback)
---
drivers/input/mouse/elan_i2c_core.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index 6f16eb4..4aaac5d 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1040,6 +1040,21 @@ static int elan_probe(struct i2c_client *client,
I2C_FUNC_SMBUS_BLOCK_DATA |
I2C_FUNC_SMBUS_I2C_BLOCK)) {
transport_ops = &elan_smbus_ops;
+
+ if (!irq) {
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_HOST_NOTIFY)) {
+ dev_err(dev, "no Host Notify support\n");
+ return -ENODEV;
+ }
+
+ irq = i2c_smbus_host_notify_to_irq(client);
+ if (irq < 0) {
+ dev_err(dev,
+ "Unable to request a Host Notify IRQ.\n");
+ return irq;
+ }
+ }
} else {
dev_err(dev, "not a supported I2C/SMBus adapter\n");
return -EIO;
--
2.7.4
^ permalink raw reply related
* [PATCH] i2c: xgene: Avoid dma_buffer overrun
From: Hoan Tran @ 2016-10-10 17:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: linux-kernel, Phil Endecott, Loc Ho, tnhuynh, patches, Hoan Tran
SMBus block command uses the first byte of buffer for the data length.
The dma_buffer should be increased by 1 to avoid the overrun issue.
Reported-by: Phil Endecott <phil_gjouf_endecott@chezphil.org>
Signed-off-by: Hoan Tran <hotran@apm.com>
---
drivers/i2c/busses/i2c-xgene-slimpro.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c b/drivers/i2c/busses/i2c-xgene-slimpro.c
index 4233f56..3c38029 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -105,7 +105,7 @@ struct slimpro_i2c_dev {
struct mbox_chan *mbox_chan;
struct mbox_client mbox_client;
struct completion rd_complete;
- u8 dma_buffer[I2C_SMBUS_BLOCK_MAX];
+ u8 dma_buffer[I2C_SMBUS_BLOCK_MAX + 1]; /* dma_buffer[0] is used for length */
u32 *resp_msg;
};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 02/10] mfd: ptxpmb-cpld: Add documentation for PTXPMB CPLD
From: Rob Herring @ 2016-10-10 17:38 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Mark Rutland, Wolfram Sang, Linus Walleij, Guenter Roeck,
Wim Van Sebroeck, linux-mtd, linux-i2c, Frank Rowand,
Alexandre Courbot, Lee Jones, JawaharBalaji Thirumalaisamy,
Guenter Roeck, devicetree, linux-watchdog, linux-gpio,
Debjit Ghosh, Georgi Vlaev, Rajat Jain, linux-kernel,
Brian Norris, David Woodhouse, Peter Rosin
In-Reply-To: <1475853451-22121-3-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:17:23PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add DT bindings document for the PTXPMB CPLD MFD device.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> .../devicetree/bindings/mfd/jnx-ptxpmb-cpld.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/jnx-ptxpmb-cpld.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-cpld.txt b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-cpld.txt
> new file mode 100644
> index 0000000..cc3cbb9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-cpld.txt
> @@ -0,0 +1,76 @@
> +* Device tree bindings for Juniper's PTXPMB CPLD FPGA MFD driver
> +
> +The device supports a number I2C muxes, hardware watchdog and a gpio block.
> +Those devices bindings are described in the jnx-i2c-mux-ptxpmb-cpld,
> +jnx-ptxpmb-wdt and jnx-gpio-ptxpmb-cpld documents.
> +
> +Required properties:
> +
> +- compatible: "jnx,ptxpmb-cpld", "jnx,ngpmb-bcpld". They differ
bcpld? looks like a typo?
> + in the i2c-mux blocks.
> +
> +- reg: contains offset/length value for device state control
> + registers space.
> +
> +Optional properties:
> +
> +- interrupts: The interrupt line(s) the /IRQ signal(s) for the device is
> + connected to.
> +
> +- interrupt-parent: The parent interrupt controller.
> +
> +Example:
> +
> +cpld@0,0 {
What bus is this on? If just simple-bus, then just '...@0'
> + compatible = "jnx,ptxpmb-cpld";
> + reg = <0x0 0 0x10000>;
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 04/10] watchdog: ptxpmb-wdt: Add ptxpmb-wdt device tree bindings
From: Rob Herring @ 2016-10-10 17:41 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Wim Van Sebroeck, Guenter Roeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, JawaharBalaji Thirumalaisamy,
Rajat Jain, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1475853451-22121-5-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On Fri, Oct 07, 2016 at 06:17:25PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
>
> Add binding document for the watchdog driver of PTXPMB CPLD.
>
> Signed-off-by: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/watchdog/jnx-ptxpmb-wdt.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/jnx-ptxpmb-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/jnx-ptxpmb-wdt.txt b/Documentation/devicetree/bindings/watchdog/jnx-ptxpmb-wdt.txt
> new file mode 100644
> index 0000000..34b64f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/jnx-ptxpmb-wdt.txt
> @@ -0,0 +1,17 @@
> +Juniper's PTXPMB FPGA watchdog driver
> +
> +Required properties:
> +
> +- compatible: Should be "jnx,ptxpmb-wdt"
> +
> +Optional properties:
> +
> +- reg : Specifies base physical address and size of the registers. It is
> + optional since the MFD parent driver supplies it, but can be overridden.
What the driver does is irrelevant. It should be required or there's no
point to have the node. If the parent knows the address, then it knows
the type of device too and DT is not needed.
> +
> +Example:
> +
> +wdt {
s/wdt/watchdog/
> + compatible = "jnx,ptxpmb-wdt";
> + /* no properties defined */
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 06/10] i2c: i2c-mux-ptxpmb-cpld: Add device tree bindings
From: Rob Herring @ 2016-10-10 17:45 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Wim Van Sebroeck, Guenter Roeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, JawaharBalaji Thirumalaisamy,
Rajat Jain, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1475853451-22121-7-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On Fri, Oct 07, 2016 at 06:17:27PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
>
> Add binding document for the i2c driver of PTXPMB CPLD.
>
> Signed-off-by: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt | 50 ++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt
> new file mode 100644
> index 0000000..3b201f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt
> @@ -0,0 +1,50 @@
> +* Juniper PTXPMB CPLD I2C Mux
> +
> +I2C mux on the PTXPMB CPLD on Juniper series of routers.
> +
> +Required properties:
> +
> + - compatible: Must contain one of the following.
> + "jnx,i2c-mux-ptxpmb-cpld", "jnx,i2c-mux-ngpmb-bcpld"
> + - num-enable: Number of muxes to enable.
No. Use status property.
> +
> + The following required properties are defined externally:
> +
> + - Standard I2C mux properties. See i2c-mux.txt in this directory.
> + - I2C child bus nodes. See i2c-mux.txt in this directory.
> +
> +Optional Properties:
> +
> + - num-channels: Number of channels. If not present the default is 8.
What's a channel?
> + - base-bus-num: Base bus number. If not present it is 0.
No. Linuxism and why do you care?
> + - use-force: Use the force method of the controller.
> +
> +
> +Example:
> +
> +cpld-i2c-mux {
mux {
> + compatible = "jnx,i2c-mux-ptxpmb-cpld";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c-parent = <&i2c1>;
> +
> + num-enable = <1>;
> +
> + i2c@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* PMB devices are accessed through FPC */
> +
> + temp-sensor@1a { /* FPC */
> + compatible = "maxim,max6697";
> + reg = <0x1a>;
> + smbus-timeout-disable;
> + resistance-cancellation;
> + alert-mask = <0xff>;
> + over-temperature-mask = <0xff>;
> + };
> + };
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 08/10] gpio: ptxpmb-cpld: Document bindings of PTXPMB's CPLD GPIO
From: Rob Herring @ 2016-10-10 18:08 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Wim Van Sebroeck, Guenter Roeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, JawaharBalaji Thirumalaisamy,
Rajat Jain, devicetree, linux-kernel, linux-gpio, linux-i2c,
linux-mtd
In-Reply-To: <1475853451-22121-9-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:17:29PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add device tree bindings document for the GPIO driver of
> Juniper's PTXPMB/NGPMB CPLD.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> .../bindings/gpio/jnx,gpio-ptxpmb-cpld.txt | 30 ++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-cpld.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-cpld.txt b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-cpld.txt
> new file mode 100644
> index 0000000..1122021
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-cpld.txt
> @@ -0,0 +1,30 @@
> +Juniper PTXPMB CPLD GPIO block
> +
> +Required properties:
> +
> +- compatible:
> + Must be "jnx,gpio-ptxpmb-cpld"
> +
> +- #gpio-cells:
> + Should be <2>. The first cell is the pin number (within the controller's
> + pin space), and the second is used for the following flags:
> + bit[0]: direction (0 = out, 1 = in)
> + bit[1]: init high
> + bit[2]: active low
Use and/or add standard flags.
> +
> +- gpio-controller:
> + Specifies that the node is a GPIO controller.
> +
> +Optional properties:
> +
> +- reg:
> + Address and length of the register set for the device. Usually supplied by
> + the parent MFD driver
Make this mandatory.
> +
> +Example:
> +
> +gpio_cpld: cpld_gpio {
> + compatible = "jnx,gpio-ptxpmb-cpld";
> + #gpio-cells = <2>;
> + gpio-controller;
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 10/10] mtd: ngpmb_nvram: Add bindings for Juniper's ngpmb NVRAM
From: Rob Herring @ 2016-10-10 18:18 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Wim Van Sebroeck, Guenter Roeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, JawaharBalaji Thirumalaisamy,
Rajat Jain, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1475853451-22121-11-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On Fri, Oct 07, 2016 at 06:17:31PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
>
> Add device tree binging document for the ngpmb NVRAM device.
>
> Signed-off-by: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/ngpmb-nvram.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/ngpmb-nvram.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/ngpmb-nvram.txt b/Documentation/devicetree/bindings/mtd/ngpmb-nvram.txt
> new file mode 100644
> index 0000000..297ad0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ngpmb-nvram.txt
mtd is really flash. sram/ or nvmem/ are probably better choices.
> @@ -0,0 +1,22 @@
> +Non Volatile RAM device on a Juniper NG PMB FPGA
> +
> +These devices are found in the PTX series of Juniper routers.
> +
> +Required properties:
> +- compatible : must be "jnx,ngpmb-nvram"
Compatible with mmio-sram?
> +
> +Optional properties:
> +- reg : memory address for the RAM, note that this is not
> +required since usually the device is a subdevice of the SAM MFD
> +driver which fills in the register fields.
> +
> +For the rest of the properties, see mtd-physmap.txt.
> +
> +The device tree may optionally contain sub-nodes describing partitions of the
> +address space. See partition.txt for more detail.
sram or nvmem style partitioning is probably more appropriate.
> +
> +Example:
> +
> +ngpmb_nvram {
> + compatible = "jnx,ngpmb-nvram";
> +};
> --
> 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
* Re: [PATCH 02/10] mfd: sam: Add documentation for the SAM FPGA
From: Rob Herring @ 2016-10-10 19:47 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, Maryam Seraj, devicetree,
linux-kernel, linux-gpio, linux-i2c, linux-mtd, linux-watchdog,
netdev
In-Reply-To: <1475853518-22264-3-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:18:30PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add DT bindings document for the SAM MFD device.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> Documentation/devicetree/bindings/mfd/jnx-sam.txt | 94 +++++++++++++++++++++++
> 1 file changed, 94 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/jnx-sam.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/jnx-sam.txt b/Documentation/devicetree/bindings/mfd/jnx-sam.txt
> new file mode 100644
> index 0000000..b4af7ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/jnx-sam.txt
> @@ -0,0 +1,94 @@
> +Device-Tree bindings for Juniper Networks SAM MFD
> +
> +Required properties:
> +
> +- compatible - Must be: "jnx,sam"
Kind of generic. Only 1 FPGA version or some other way to tell the
version?
> +
> +Optional properties:
> +
> +- pma-coefficients: A set of tupples containing the configuration of the PMA.
What's a PMA? What type of configuration? How many entries?
> +Device Description
> +------ -----------
> +jnx,i2c-sam : I2C mux driver
> +jnx,gpio-sam : GPIO block
> +jnx,flash-sam : MTD Flash
> +jnx,mdio-sam : MDIO interfaces
> +
> +All these optional nodes are described in their respective binding
> +documents.
> +
> +Example node:
> +
> +pci-0000-10-00.0 {
What are the numbers?
> + compatible = "jnx,sam";
If this is a PCI device, then it should use PCI compatible string
syntax.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pma-coefficients = <4 0x0>;
> +
> + i2c-sam@10 {
> + compatible = "jnx,i2c-sam";
> + mux-channels = <2>;
> + master-offset = <0x10000>;
> + };
> +
> + gpiogpqam0: gpio-sam@10 {
gpio@...
Where does 10 come from?
> + compatible = "jnx,gpio-sam";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-count = <297>;
> + interrupt-controller;
> + /*
> + * 1st cell: gpio interrupt status bit
> + * 2nd cell: 1st pin
> + * 3rd cell: # of pins
> + */
> + gpio-interrupts =
> + <0 0 12>, /* phy_int_monitor_en [16] */
> + <1 235 24>, /* qsfpp_fpga_int_monitor [17] */
> + <2 259 24>, /* qsfpp_fpga_modprs_monitor [18] */
> + <3 295 1>, /* si5345_fpga_monitor [19] */
> + <4 294 1>; /* fpc_pic_int_monitor [20] */
> + };
> +
> + flash-sam@10 {
> + compatible = "jnx,flash-sam";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + reg = <0x0 0x400000>;
> + label = "pic0-golden";
> + read-only;
> + };
> + partition@400000 {
> + reg = <0x400000 0x400000>;
> + label = "pic0-user";
> + };
> + };
> +
> + mdio-sam@10 {
> + compatible = "jnx,mdio-sam";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x40000>;
> +
> + /* mii_bus types */
> + mdio0: mdio-sam@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0>;
> + };
> +
> + mdio1: mdio-sam@4000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x4000>;
> + };
> +
> + mdio2: mdio-sam@8000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x8000>;
> + };
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 04/10] i2c: i2c-sam: Add device tree bindings
From: Rob Herring @ 2016-10-10 19:54 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, Maryam Seraj, devicetree,
linux-kernel, linux-gpio, linux-i2c, linux-mtd, linux-watchdog,
netdev
In-Reply-To: <1475853518-22264-5-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:18:32PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add binding document for the i2c driver of SAM FPGA.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> .../devicetree/bindings/i2c/i2c-sam-mux.txt | 20 ++++++++++
> Documentation/devicetree/bindings/i2c/i2c-sam.txt | 44 ++++++++++++++++++++++
> 2 files changed, 64 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sam.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt b/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
> new file mode 100644
> index 0000000..10ddffa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
> @@ -0,0 +1,20 @@
> +Juniper's SAM FPGA I2C accelerator mux
> +
> +The SAM FPGA I2C mux is present only on Juniper SAM FPGA PTX series
> +of routers.
> +
> +The definition of the i2c sam bus is located in the i2c-sam.txt document.
> +
> +Required properties:
> +- compatible: should be "jnx,i2c-sam-mux".
> +- reg: master number and mux number.
This is not how i2c muxes are done.
> +
> +Optional properties:
> +- speed: If present must be either 100000 or 400000. No other values supported.
> +
> +Examples:
> +
> +pe1i2c: i2c-sam-mux@1,0 {
i2c-mux@...
> + compatible = "jnx,i2c-sam-mux";
> + reg = <1 0>;
> +};
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-sam.txt b/Documentation/devicetree/bindings/i2c/i2c-sam.txt
> new file mode 100644
> index 0000000..4830b48
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-sam.txt
> @@ -0,0 +1,44 @@
> +Juniper's SAM FPGA I2C accelerator
> +
> +The SAM FPGA accelerator is used to connect the large number of
> +I2C muxes that are present on Juniper PTX series of routers.
> +While it's an i2c bus, no other devices are located besides
> +i2c-sam-mux devices.
> +
> +The definition of the i2c sam mux is located in the i2c-sam-mux.txt document.
> +
> +Required properties:
> +- compatible: should be "jnx,i2c-sam".
> +- #address-cells: should be 2.
> +- #size-cells: should be 0.
> +- mux-channels: number of mux channels present
What is this needed for?
> +
> +Optional properties:
> +- reg: offset and length of the register set for the device are optional since
> + typically the register range is provided by the parent SAM MFD device.
> +- master-offset: Offset of where the master register memory starts.
> + Default value is 0x8000.
Make this required.
> +- reverse-fill: Fill the start entries of transactions in reverse order
Needs a better explanation.
> +- priority-tables: Use the pre-programmed priority tables in the FPGA
What does not present mean?
> +- i2c-options: list of options to be written to the option field in the
> + FPGA controlling things like SCL push-pull drives, hold-times, etc.
> +- bus-range: start of bus master range and number of masters.
Needs a better explanation.
> +
> +Examples:
> +
> +i2c-sam {
> + compatible = "jnx,i2c-sam";
> + mux-channels = <2>;
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + /* PE0 */ pe0i2c: i2c-sam-mux@0,0 {
i2c-mux@...
> + compatible = "jnx,i2c-sam-mux";
> + reg = <0 0>;
> + };
> +
> + /* PE1 */ pe1i2c: i2c-sam-mux@1,0 {
> + compatible = "jnx,i2c-sam-mux";
> + reg = <1 0>;
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 06/10] gpio: sam: Document bindings of SAM FPGA GPIO block
From: Rob Herring @ 2016-10-10 20:03 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, Maryam Seraj, devicetree,
linux-kernel, linux-gpio, linux-i2c, linux-mtd, linux-watchdog,
netdev
In-Reply-To: <1475853518-22264-7-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:18:34PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add device tree bindings document for the GPIO driver of
> Juniper's SAM FPGA.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> .../devicetree/bindings/gpio/jnx,gpio-sam.txt | 110 +++++++++++++++++++++
> 1 file changed, 110 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
> new file mode 100644
> index 0000000..514c350
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
> @@ -0,0 +1,110 @@
> +Juniper SAM FPGA GPIO block
> +
> +The controller's registers are organized as sets of eight 32-bit
> +registers with each set controlling a bank of up to 32 pins. A single
> +interrupt is shared for all of the banks handled by the controller.
> +
> +Required properties:
> +
> +- compatible:
> + Must be "jnx,gpio-sam"
> +
> +- #gpio-cells:
> + Should be <2>. The first cell is the pin number (within the controller's
> + pin space), and the second is used for the following flags:
> + bit[0]: direction (0 = out, 1 = in)
> + bit[1]: init high
> + bit[2]: active low
> + bit[3]: open drain
> + bit[4]: open drain
Use and/or add to standard flags.
> +
> +- gpio-controller:
> + Specifies that the node is a GPIO controller.
> +
> +Optional properties:
> +
> +- reg:
> + This driver is part of the SAM FPGA MFD driver, so the
> + address range is supplied by that driver. However you can
> + override using this property.
> +
> +- gpio-base:
> + Base of the GPIO pins of this instance. If not present use system allocated.
This probably needs to go.
> +
> +- gpio-count:
ngpios instead.
> + Number of GPIO pins of this instance. If not present read the number from
> + the one configured in the FPGA data. Maximum number is 512.
> +
> +- #interrupt-cells:
> + Should be <2>. The first cell is the GPIO number, the second should specify
> + flags. The following subset of flags is supported:
> + - bits[16,4:0] trigger type and level flags
> + bit 0: rising edge interrupt
> + bit 1: falling edge interrupt
> + bit 2: active high interrupt
> + bit 3: active low interrupt
> + bit 4: enable debounce
> + bit 16: signal is active low
What does this mean?
> + See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +- gpio-interrupts:
> + A number of triples that define the mapping of interrupt groupsb to a range of
> + pins. The first cell defines the interrupt group, the second is the start of
> + the pin range and the third the number of pins in the range.
Needs a vendor prefix.
> +
> +- gpio-exports:
> + A subnode containing the list of pins that will be exported to user-space.
DT doesn't know about userspace. Drop this.
> + Each subnode contains:
> + Required properties:
> + - pin: The gpio to be exported and the relevant flags.
> + Optional properties:
> + - label: The label to use for export; if not supplied use the node name.
> +
> +Example:
> +
> +gpio20: gpio-sam {
> + compatible = "jnx,gpio-sam";
> + gpio-controller;
> + interrupt-controller;
> + /* 1st cell: gpio pin
> + * 2nd cell: flags (bit mask)
> + * bit 0: rising edge interrupt
> + * bit 1: falling edge interrupt
> + * bit 2: active high interrupt
> + * bit 3: active low interrupt
> + * bit 4: enable debounce
> + * bit 16: signal is active low
> + */
> + #interrupt-cells = <2>;
> + #gpio-cells = <2>;
> + gpio-count = <340>;
> + /* 1st cell: gpio interrupt status bit
> + * 2nd cell: 1st pin
> + * 3rd cell: # of pins
> + */
> + gpio-interrupts =
> + <0 0 32>, /* TL / TQ */
> + <1 32 32>, /* PIC 1 */
> + <2 32 32>, /* PIC 1 spare */
> + <7 148 32>, /* PIC 0 */
> + <8 170 32>, /* PIC 0 spare */
> + <16 318 22>; /* FPC */
> +
> + gpio-exports {
> + /*
> + * flags:
> + * GPIOF_DIR_IN bit 0=1
> + * GPIOF_DIR_OUT bit 0=0
> + * GPIOF_INIT_HIGH bit 1=1
> + * GPIOF_INIT_HIGH is raw, not translated
> + * GPIOF_ACTIVE_LOW bit 2=1
> + * GPIOF_OPEN_DRAIN bit 3=1
> + * GPIOF_OPEN_SOURCE bit 4=1
> + * GPIOF_EXPORT bit 5=1
> + * GPIOF_EXPORT_CHANGEABLE bit 6=1
> + */
> + tl0-rst {
> + pin = < 8 0x24 >;
> + };
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 08/10] mtd: flash-sam: Bindings for Juniper's SAM FPGA flash
From: Rob Herring @ 2016-10-10 20:07 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
Georgi Vlaev, Guenter Roeck, Maryam Seraj,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475853518-22264-9-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
gOn Fri, Oct 07, 2016 at 06:18:36PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
>
> Add binding document for Junipers Flash IP block present
> in the SAM FPGA on PTX series of routers.
>
> Signed-off-by: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/flash-sam.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/flash-sam.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/flash-sam.txt b/Documentation/devicetree/bindings/mtd/flash-sam.txt
> new file mode 100644
> index 0000000..bdf1d78
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/flash-sam.txt
> @@ -0,0 +1,31 @@
> +Flash device on a Juniper SAM FPGA
> +
> +These flash chips are found in the PTX series of Juniper routers.
> +
> +They are regular CFI compatible (Intel or AMD extended) flash chips with
> +some special write protect/VPP bits that can be controlled by the machine's
> +system controller.
And where's the description of the sys ctrlr?
> +
> +Required properties:
> +- compatible : must be "jnx,flash-sam"
> +
> +Optional properties:
> +- reg : memory address for the flash chip, note that this is not
> +required since usually the device is a subdevice of the SAM MFD
> +driver which fills in the register fields.
> +
> +For the rest of the properties, see mtd-physmap.txt.
> +
> +The device tree may optionally contain sub-nodes describing partitions of the
> +address space. See partition.txt for more detail.
> +
> +Example:
> +
> +flash_sam {
> + compatible = "jnx,flash-sam";
> + partition@0 {
This should have a heirarchy of a controller node, a flash child node,
partitions child node, and partition child nodes.
> + reg = <0x0 0x400000>;
> + label = "pic0-golden";
> + read-only;
> + };
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3] hwmon: Add tc654 driver
From: Chris Packham @ 2016-10-10 20:08 UTC (permalink / raw)
To: Guenter Roeck, linux-hwmon@vger.kernel.org
Cc: Masahiko Iwamoto, Joshua Scott, Kevin Tsai, Wolfram Sang,
Rob Herring, Mark Rutland, Jean Delvare, Jonathan Corbet,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <b8294ac3-7bac-eeb3-8923-ed569a19cab2@roeck-us.net>
On 10/11/2016 02:22 AM, Guenter Roeck wrote:
>> + if (val)
>> > + data->config |= TC654_REG_CONFIG_DUTYC;
>> > + else
>> > + data->config &= ~TC654_REG_CONFIG_DUTYC;
> I just realized that this won't work as intended. Problem is that you
> only fill data->config when reading an attribute. So, if a set function
> is called prior to reading an attribute, data->config will be 0, and
> you end up overwriting the original configuration.
>
Should I just read it in the probe function or fill it in with the
documented hardware defaults?
^ permalink raw reply
* Re: [PATCH 2/4] mfd: ptxpmb-ext-cpld: Add documentation for PTXPMB extended CPLD
From: Rob Herring @ 2016-10-10 20:10 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Mark Rutland, Alexandre Courbot, linux-watchdog, devicetree,
Frank Rowand, Linus Walleij, linux-kernel,
JawaharBalaji Thirumalaisamy, linux-gpio, linux-mtd, linux-i2c,
netdev, Georgi Vlaev, Lee Jones, Guenter Roeck
In-Reply-To: <1475853574-22339-3-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:19:32PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add DT bindings document for the PTXPMB extended CPLD device.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> .../bindings/mfd/jnx-ptxpmb-ext-cpld.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
> new file mode 100644
> index 0000000..098a548a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
> @@ -0,0 +1,35 @@
> +* Device tree bindings for Juniper's PTXPMB Extended CPLD FPGA MFD driver
> +
> +The device supports a gpio block which is described in the
> +jnx-gpio-ptxpmb-ext-cpld document.
> +
> +Required properties:
> +
> +- compatible: "jnx,ptxpmb-ext-cpld"
> +
> +- reg: contains offset/length value for device state control
> + registers space.
> +
> +Optional properties:
> +
> +- interrupts: The interrupt line(s) the /IRQ signal(s) for the device is
> + connected to.
> +
> +- interrupt-parent: The parent interrupt controller.
> +
> +Example:
> +
> +ext-cpld@1,0 {
> + compatible = "jnx,ptxpmb-ext-cpld";
> + reg = <0x1 0 0x1000>;
What's the bus type here? Unit address is probably wrong.
> + interrupt-parent = <&mpic>;
> + interrupts = <7 2>, <8 2>;
> +
> + gpio_ext_cpld: cpld-ext-gpio {
> + compatible = "jnx,gpio-ptxpmb-ext-cpld";
> + #gpio-cells = <2>;
> + #interrupt-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> + };
> +};
> --
> 1.9.1
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 4/4] gpio: ptxpmb-ext-cpld: Document bindings of PTXPMB extended CPLD
From: Rob Herring @ 2016-10-10 20:19 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Georgi Vlaev, Guenter Roeck,
JawaharBalaji Thirumalaisamy, devicetree, linux-kernel,
linux-gpio, linux-i2c, linux-mtd, linux-watchdog, netdev
In-Reply-To: <1475853574-22339-5-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:19:34PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add device tree bindings document for the GPIO driver of
> Juniper's PTXPMB extended CPLD.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> .../bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt | 36 ++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
> new file mode 100644
> index 0000000..87f01b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
> @@ -0,0 +1,36 @@
> +Juniper PTXPMB extended CPLD GPIO block
> +
> +Required properties:
> +
> +- compatible:
> + Must be "jnx,gpio-ptxpmb-ext-cpld"
Generally, '-gpio' would be last.
> +
> +- #gpio-cells:
> + Should be <2>. The first cell is the pin number (within the controller's
> + pin space), and the second is used for the following flags:
> + bit[0]: direction (0 = out, 1 = in)
> + bit[1]: init high
> + bit[2]: active low
Same comment as all the other gpio bindings...
> +
> +- gpio-controller:
> + Specifies that the node is a GPIO controller.
> +
> +- interrupt-controller:
> + Specifies that the node is an interrupt controller.
> +
> +Optional properties:
> +
> +- reg:
> + Address and length of the register set for the device. Usually supplied
> + by the parent MFD device.
Make it required.
> +
> +
> +Example:
> +
> +gpio_ext_cpld: cpld-ext-gpio {
> + compatible = "jnx,gpio-ptxpmb-ext-cpld";
> + #gpio-cells = <2>;
> + #interrupt-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 04/10] i2c: i2c-mux-i2cs: Add device tree bindings
From: Rob Herring @ 2016-10-10 20:25 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, Richard Purdie, Jacek Anaszewski,
Jean Delvare, Peter Rosin, Avirup Banerjee, Georgi Vlaev,
Guenter Roeck, JawaharBalaji Thirumalaisamy, devicetree,
linux-kernel, linux-gpio, linux-i2c, linux-leds, linux-hwmon
In-Reply-To: <1475853669-22480-5-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:21:03PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add binding document for the i2c mux driver of Juniper's I2CS FPGA.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> .../devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
> new file mode 100644
> index 0000000..03d917f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
> @@ -0,0 +1,27 @@
> +* Juniper I2C Mux on I2CS
> +
> + I2C mux driver for switching the RE access to the FPC i2c bus.
What is RE?
> + Compatible with the FPC variant of the I2CS.
> +
> +Required properties:
> +
> + - compatible: "jnx,i2cs-mux-i2cs".
> +
> +The following required properties are defined externally:
> +
> + - Standard I2C mux properties. See i2c-mux.txt in this directory.
> + - I2C child bus nodes. See i2c-mux.txt in this directory.
> +
> +Example:
> +
> +fpc0_mux {
> + compatible = "jnx,i2c-mux-i2cs";
> + #address-cells = <1>;
> + #size-cells = <0>;
Needs some address?
> +
> + fpc0i2c0: i2c@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 10/10] hwmon: i2cs-fan: Add hwmon dts binding documentation
From: Rob Herring @ 2016-10-10 20:29 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, Richard Purdie, Jacek Anaszewski,
Jean Delvare, Peter Rosin, Avirup Banerjee, Georgi Vlaev,
Guenter Roeck, JawaharBalaji Thirumalaisamy, devicetree,
linux-kernel, linux-gpio, linux-i2c, linux-leds, linux-hwmon
In-Reply-To: <1475853669-22480-11-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:21:09PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Adds the I2CS Fan Tray hwmon device tree node documentation.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> Documentation/devicetree/bindings/hwmon/i2cs-fan.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt b/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
> new file mode 100644
> index 0000000..4ef880c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
> @@ -0,0 +1,19 @@
> +Hwmon driver for Juniper fan trays on I2CS Slave FPGA
This is a h/w description, not a driver.
> +
> +Required properties:
> +
> +- compatible: "i2cs-fan-hwmon"
I doubt any fan control h/w has "hwmon" in the name.
> +
> +Optional properties:
> +
> +- num-fans: fans per tray (default 14)
> +
> +- tach-factor: TACH count scaling factor (default 120)
vendor prefixes needed.
> +
> +Example:
> +
> +fan-hwmon {
> + compatible = "jnx,i2cs-fan-hwmon";
> + num-fans = <6>;
> + tach-factor = <33>;
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 02/10] mfd: dt-bindings: Add bindings for the Juniper I2CS MFD
From: Rob Herring @ 2016-10-10 20:23 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
Frank Rowand, Wolfram Sang, Richard Purdie, Jacek Anaszewski,
Jean Delvare, Peter Rosin, Avirup Banerjee, Georgi Vlaev,
Guenter Roeck, JawaharBalaji Thirumalaisamy, devicetree,
linux-kernel, linux-gpio, linux-i2c, linux-leds, linux-hwmon
In-Reply-To: <1475853669-22480-3-git-send-email-pantelis.antoniou@konsulko.com>
On Fri, Oct 07, 2016 at 06:21:01PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
>
> Add device tree bindings for the Juniper I2CS MFD driver.
>
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
> Documentation/devicetree/bindings/mfd/jnx-i2cs.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt b/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
> new file mode 100644
> index 0000000..0ec103b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
> @@ -0,0 +1,68 @@
> +Device-Tree bindings for Juniper Networks I2CS FPGA MFD
> +
> +Required properties:
> +- compatible - Must be one of:
> + "jnx,i2cs-rcb" (Routing Engine or Control Board FRUs)
> + "jnx,i2cs-fpc" (Flexible Port Concentrator FRUs)
> + "jnx,i2cs-sib" (Switching Interface Board FRUs)
> + "jnx,i2cs-fan" (Fan Tray FRUs)
> +
> +Optional properties:
> +
> +Depending on the FRU, the I2CS MFD has varied group of sub-devices:
> +
> +Device Description
> +------ -----------
> +jnx,i2cs-gpio : Virtual gpio mapping driver
> +jnx,i2cs-fan-hwmon : hwmon driver for fan trays
> +jnx,i2c-mux-i2cs : I2C Mux driver for FPC FRUs
> +jnx,leds-i2cs : Led driver
> +
> +All these optional nodes are described in their respective binding
> +documents.
> +
> +Example node:
> +
> +i2cs@54 {
> + compatible = "jnx,i2cs-fpc";
> + reg = <0x54>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> +
> + fpc2_mux {
Generic node names please.
mux {
> + compatible = "jnx,i2c-mux-i2cs";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + fpc2i2c0: i2c@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + };
> + };
> +
> + fpc2_gpiomap: gpio-jnx-i2cs {
gpio@54 {
> + compatible = "jnx,gpio-i2cs";
> + reg = <0x54>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> +
> + /*
> + * Map bits [0-3] of reg 0x21 as gpio inputs, bits [4-7]
> + * as gpio outputs
> + */
> + i2c-gpio-map = <0x21 0x0f>;
> + };
> +
> + leds-jnx-i2cs {
leds {
> + compatible = "jnx,leds-i2cs";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sib8-active {
> + reg = <0>;
> + linux,default-trigger = "sib8-active";
> + };
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCHv3] hwmon: Add tc654 driver
From: Guenter Roeck @ 2016-10-10 20:59 UTC (permalink / raw)
To: Chris Packham
Cc: linux-hwmon@vger.kernel.org, Masahiko Iwamoto, Joshua Scott,
Kevin Tsai, Wolfram Sang, Rob Herring, Mark Rutland, Jean Delvare,
Jonathan Corbet, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <f82bbcd4330e4389990f95bd9d0d7b02@svr-chch-ex1.atlnz.lc>
On Mon, Oct 10, 2016 at 08:08:14PM +0000, Chris Packham wrote:
> On 10/11/2016 02:22 AM, Guenter Roeck wrote:
> >> + if (val)
> >> > + data->config |= TC654_REG_CONFIG_DUTYC;
> >> > + else
> >> > + data->config &= ~TC654_REG_CONFIG_DUTYC;
> > I just realized that this won't work as intended. Problem is that you
> > only fill data->config when reading an attribute. So, if a set function
> > is called prior to reading an attribute, data->config will be 0, and
> > you end up overwriting the original configuration.
> >
>
> Should I just read it in the probe function or fill it in with the
> documented hardware defaults?
Reading it would be better - that leaves the option open that it was configured
by ROMMON or BIOS.
Guenter
^ permalink raw reply
* [PATCHv4] hwmon: Add tc654 driver
From: Chris Packham @ 2016-10-10 21:26 UTC (permalink / raw)
To: linux, linux-hwmon
Cc: iwamoto, Joshua.Scott, Chris Packham, Kevin Tsai, Wolfram Sang,
Rob Herring, Mark Rutland, Jean Delvare, Jonathan Corbet,
linux-i2c, devicetree, linux-kernel, linux-doc
In-Reply-To: <b8294ac3-7bac-eeb3-8923-ed569a19cab2@roeck-us.net>
Add support for the tc654 and tc655 fan controllers from Microchip.
http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Changes in v4:
- tab-align values in #defines
- ensure locking in set_pwm covers updating cached values
- populate the cached value for the config register in tc654_probe()
Changes in v3:
- typofix in documentation
- add missing value to tc654_pwm_map, re-generate based on datasheet.
- remove unnecessary hwmon_dev member from struct tc654_data
- bug fixes in set_fan_min() and show_pwm_mode()
- miscellaneous style fixes
Changes in v2:
- Add Documentation/hwmon/tc654
- Incorporate most of the review comments from Guenter. Additional error
handling is added. Unused/unnecessary code is removed. I decided not
to go down the regmap path yet. I may circle back to it when I look at
using regmap in the adm9240 driver.
.../devicetree/bindings/i2c/trivial-devices.txt | 2 +
Documentation/hwmon/tc654 | 31 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/tc654.c | 514 +++++++++++++++++++++
5 files changed, 559 insertions(+)
create mode 100644 Documentation/hwmon/tc654
create mode 100644 drivers/hwmon/tc654.c
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 1416c6a0d2cd..833fb9f133d3 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -122,6 +122,8 @@ microchip,mcp4662-502 Microchip 8-bit Dual I2C Digital Potentiometer with NV Mem
microchip,mcp4662-103 Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (10k)
microchip,mcp4662-503 Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (50k)
microchip,mcp4662-104 Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (100k)
+microchip,tc654 PWM Fan Speed Controller With Fan Fault Detection
+microchip,tc655 PWM Fan Speed Controller With Fan Fault Detection
national,lm63 Temperature sensor with integrated fan control
national,lm75 I2C TEMP SENSOR
national,lm80 Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
new file mode 100644
index 000000000000..91a2843f5f98
--- /dev/null
+++ b/Documentation/hwmon/tc654
@@ -0,0 +1,31 @@
+Kernel driver tc654
+===================
+
+Supported chips:
+ * Microship TC654 and TC655
+ Prefix: 'tc654'
+ Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
+
+Authors:
+ Chris Packham <chris.packham@alliedtelesis.co.nz>
+ Masahiko Iwamoto <iwamoto@allied-telesis.co.jp>
+
+Description
+-----------
+This driver implements support for the Microchip TC654 and TC655.
+
+The TC654 uses the 2-wire interface compatible with the SMBUS 2.0
+specification. The TC654 has two (2) inputs for measuring fan RPM and
+one (1) PWM output which can be used for fan control.
+
+Configuration Notes
+-------------------
+Ordinarily the pwm1_mode ABI is used for controlling the pwm output
+mode. However, for this chip the output is always pwm, and the
+pwm1_mode determines if the pwm output is controlled via the pwm1 value
+or via the Vin analog input.
+
+
+Setting pwm1_mode to 1 will cause the pwm output to be driven based on
+the pwm1 value. Setting pwm1_mode to 0 will cause the pwm output to be
+driven based on the Vin input.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..8681bc65cde5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -907,6 +907,17 @@ config SENSORS_MCP3021
This driver can also be built as a module. If so, the module
will be called mcp3021.
+config SENSORS_TC654
+ tristate "Microchip TC654/TC655 and compatibles"
+ depends on I2C
+ help
+ If you say yes here you get support for TC654 and TC655.
+ The TC654 and TC655 are PWM mode fan speed controllers with
+ FanSense technology for use with brushless DC fans.
+
+ This driver can also be built as a module. If so, the module
+ will be called tc654.
+
config SENSORS_MENF21BMC_HWMON
tristate "MEN 14F021P00 BMC Hardware Monitoring"
depends on MFD_MENF21BMC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..c651f0f1d047 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
obj-$(CONFIG_SENSORS_MAX31790) += max31790.o
obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
+obj-$(CONFIG_SENSORS_TC654) += tc654.o
obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o
obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
diff --git a/drivers/hwmon/tc654.c b/drivers/hwmon/tc654.c
new file mode 100644
index 000000000000..04485f6d6983
--- /dev/null
+++ b/drivers/hwmon/tc654.c
@@ -0,0 +1,514 @@
+/*
+ * tc654.c - Linux kernel modules for fan speed controller
+ *
+ * Copyright (C) 2016 Allied Telesis Labs NZ
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/bitops.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include <linux/util_macros.h>
+
+enum tc654_regs {
+ TC654_REG_RPM1 = 0x00, /* RPM Output 1 */
+ TC654_REG_RPM2 = 0x01, /* RPM Output 2 */
+ TC654_REG_FAN_FAULT1 = 0x02, /* Fan Fault 1 Threshold */
+ TC654_REG_FAN_FAULT2 = 0x03, /* Fan Fault 2 Threshold */
+ TC654_REG_CONFIG = 0x04, /* Configuration */
+ TC654_REG_STATUS = 0x05, /* Status */
+ TC654_REG_DUTY_CYCLE = 0x06, /* Fan Speed Duty Cycle */
+ TC654_REG_MFR_ID = 0x07, /* Manufacturer Identification */
+ TC654_REG_VER_ID = 0x08, /* Version Identification */
+};
+
+/* Macros to easily index the registers */
+#define TC654_REG_RPM(idx) (TC654_REG_RPM1 + (idx))
+#define TC654_REG_FAN_FAULT(idx) (TC654_REG_FAN_FAULT1 + (idx))
+
+/* Config register bits */
+#define TC654_REG_CONFIG_RES BIT(6) /* Resolution Selection */
+#define TC654_REG_CONFIG_DUTYC BIT(5) /* Duty Cycle Control */
+#define TC654_REG_CONFIG_SDM BIT(0) /* Shutdown Mode */
+
+/* Status register bits */
+#define TC654_REG_STATUS_F2F BIT(1) /* Fan 2 Fault */
+#define TC654_REG_STATUS_F1F BIT(0) /* Fan 1 Fault */
+
+/* RPM resolution for RPM Output registers */
+#define TC654_HIGH_RPM_RESOLUTION 25 /* 25 RPM resolution */
+#define TC654_LOW_RPM_RESOLUTION 50 /* 50 RPM resolution */
+
+/* Convert to the fan fault RPM threshold from register value */
+#define TC654_FAN_FAULT_FROM_REG(val) ((val) * 50) /* 50 RPM resolution */
+
+/* Convert to register value from the fan fault RPM threshold */
+#define TC654_FAN_FAULT_TO_REG(val) (((val) / 50) & 0xff)
+
+/* Register data is read (and cached) at most once per second. */
+#define TC654_UPDATE_INTERVAL HZ
+
+struct tc654_data {
+ struct i2c_client *client;
+
+ /* update mutex */
+ struct mutex update_lock;
+
+ /* tc654 register cache */
+ bool valid;
+ unsigned long last_updated; /* in jiffies */
+
+ u8 rpm_output[2]; /* The fan RPM data for fans 1 and 2 is then
+ * written to registers RPM1 and RPM2
+ */
+ u8 fan_fault[2]; /* The Fan Fault Threshold Registers are used to
+ * set the fan fault threshold levels for fan 1
+ * and fan 2
+ */
+ u8 config; /* The Configuration Register is an 8-bit read/
+ * writable multi-function control register
+ * 7: Fan Fault Clear
+ * 1 = Clear Fan Fault
+ * 0 = Normal Operation (default)
+ * 6: Resolution Selection for RPM Output Registers
+ * RPM Output Registers (RPM1 and RPM2) will be
+ * set for
+ * 1 = 25 RPM (9-bit) resolution
+ * 0 = 50 RPM (8-bit) resolution (default)
+ * 5: Duty Cycle Control Method
+ * The V OUT duty cycle will be controlled via
+ * 1 = the SMBus interface.
+ * 0 = via the V IN analog input pin. (default)
+ * 4,3: Fan 2 Pulses Per Rotation
+ * 00 = 1
+ * 01 = 2 (default)
+ * 10 = 4
+ * 11 = 8
+ * 2,1: Fan 1 Pulses Per Rotation
+ * 00 = 1
+ * 01 = 2 (default)
+ * 10 = 4
+ * 11 = 8
+ * 0: Shutdown Mode
+ * 1 = Shutdown mode.
+ * 0 = Normal operation. (default)
+ */
+ u8 status; /* The Status register provides all the information
+ * about what is going on within the TC654/TC655
+ * devices.
+ * 7,6: Unimplemented, Read as '0'
+ * 5: Over-Temperature Fault Condition
+ * 1 = Over-Temperature condition has occurred
+ * 0 = Normal operation. V IN is less than 2.6V
+ * 4: RPM2 Counter Overflow
+ * 1 = Fault condition
+ * 0 = Normal operation
+ * 3: RPM1 Counter Overflow
+ * 1 = Fault condition
+ * 0 = Normal operation
+ * 2: V IN Input Status
+ * 1 = V IN is open
+ * 0 = Normal operation. voltage present at V IN
+ * 1: Fan 2 Fault
+ * 1 = Fault condition
+ * 0 = Normal operation
+ * 0: Fan 1 Fault
+ * 1 = Fault condition
+ * 0 = Normal operation
+ */
+ u8 duty_cycle; /* The DUTY_CYCLE register is a 4-bit read/
+ * writable register used to control the duty
+ * cycle of the V OUT output.
+ */
+};
+
+/* helper to grab and cache data, at most one time per second */
+static struct tc654_data *tc654_update_client(struct device *dev)
+{
+ struct tc654_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
+ int ret = 0;
+
+ mutex_lock(&data->update_lock);
+ if (time_before(jiffies, data->last_updated + TC654_UPDATE_INTERVAL) &&
+ likely(data->valid))
+ goto out;
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_RPM(0));
+ if (ret < 0)
+ goto out;
+ data->rpm_output[0] = ret;
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_RPM(1));
+ if (ret < 0)
+ goto out;
+ data->rpm_output[1] = ret;
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_FAN_FAULT(0));
+ if (ret < 0)
+ goto out;
+ data->fan_fault[0] = ret;
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_FAN_FAULT(1));
+ if (ret < 0)
+ goto out;
+ data->fan_fault[1] = ret;
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_CONFIG);
+ if (ret < 0)
+ goto out;
+ data->config = ret;
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_STATUS);
+ if (ret < 0)
+ goto out;
+ data->status = ret;
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_DUTY_CYCLE);
+ if (ret < 0)
+ goto out;
+ data->duty_cycle = ret & 0x0f;
+
+ data->last_updated = jiffies;
+ data->valid = true;
+out:
+ mutex_unlock(&data->update_lock);
+
+ if (ret < 0) /* upon error, encode it in return value */
+ data = ERR_PTR(ret);
+
+ return data;
+}
+
+/*
+ * sysfs attributes
+ */
+
+static ssize_t show_fan(struct device *dev, struct device_attribute *da,
+ char *buf)
+{
+ int nr = to_sensor_dev_attr(da)->index;
+ struct tc654_data *data = tc654_update_client(dev);
+ int val;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ if (data->config & TC654_REG_CONFIG_RES)
+ val = data->rpm_output[nr] * TC654_HIGH_RPM_RESOLUTION;
+ else
+ val = data->rpm_output[nr] * TC654_LOW_RPM_RESOLUTION;
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t show_fan_min(struct device *dev, struct device_attribute *da,
+ char *buf)
+{
+ int nr = to_sensor_dev_attr(da)->index;
+ struct tc654_data *data = tc654_update_client(dev);
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ return sprintf(buf, "%d\n",
+ TC654_FAN_FAULT_FROM_REG(data->fan_fault[nr]));
+}
+
+static ssize_t set_fan_min(struct device *dev, struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ int nr = to_sensor_dev_attr(da)->index;
+ struct tc654_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
+ unsigned long val;
+ int ret;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ val = clamp_val(val, 0, 12750);
+
+ mutex_lock(&data->update_lock);
+
+ data->fan_fault[nr] = TC654_FAN_FAULT_TO_REG(val);
+ ret = i2c_smbus_write_byte_data(client, TC654_REG_FAN_FAULT(nr),
+ data->fan_fault[nr]);
+
+ mutex_unlock(&data->update_lock);
+ return ret < 0 ? ret : count;
+}
+
+static ssize_t show_fan_alarm(struct device *dev, struct device_attribute *da,
+ char *buf)
+{
+ int nr = to_sensor_dev_attr(da)->index;
+ struct tc654_data *data = tc654_update_client(dev);
+ int val;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ if (nr == 0)
+ val = !!(data->status & TC654_REG_STATUS_F1F);
+ else
+ val = !!(data->status & TC654_REG_STATUS_F2F);
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static const u8 TC654_FAN_PULSE_SHIFT[] = { 1, 3 };
+
+static ssize_t show_fan_pulses(struct device *dev, struct device_attribute *da,
+ char *buf)
+{
+ int nr = to_sensor_dev_attr(da)->index;
+ struct tc654_data *data = tc654_update_client(dev);
+ u8 val;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ val = BIT((data->config >> TC654_FAN_PULSE_SHIFT[nr]) & 0x03);
+ return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t set_fan_pulses(struct device *dev, struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ int nr = to_sensor_dev_attr(da)->index;
+ struct tc654_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
+ u8 config;
+ unsigned long val;
+ int ret;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ switch (val) {
+ case 1:
+ config = 0;
+ break;
+ case 2:
+ config = 1;
+ break;
+ case 4:
+ config = 2;
+ break;
+ case 8:
+ config = 3;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ mutex_lock(&data->update_lock);
+
+ data->config &= ~(0x03 << TC654_FAN_PULSE_SHIFT[nr]);
+ data->config |= (config << TC654_FAN_PULSE_SHIFT[nr]);
+ ret = i2c_smbus_write_byte_data(client, TC654_REG_CONFIG, data->config);
+
+ mutex_unlock(&data->update_lock);
+ return ret < 0 ? ret : count;
+}
+
+static ssize_t show_pwm_mode(struct device *dev,
+ struct device_attribute *da, char *buf)
+{
+ struct tc654_data *data = tc654_update_client(dev);
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ return sprintf(buf, "%d\n", !!(data->config & TC654_REG_CONFIG_DUTYC));
+}
+
+static ssize_t set_pwm_mode(struct device *dev,
+ struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ struct tc654_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
+ unsigned long val;
+ int ret;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ if (val != 0 && val != 1)
+ return -EINVAL;
+
+ mutex_lock(&data->update_lock);
+
+ if (val)
+ data->config |= TC654_REG_CONFIG_DUTYC;
+ else
+ data->config &= ~TC654_REG_CONFIG_DUTYC;
+
+ ret = i2c_smbus_write_byte_data(client, TC654_REG_CONFIG, data->config);
+
+ mutex_unlock(&data->update_lock);
+ return ret < 0 ? ret : count;
+}
+
+static const int tc654_pwm_map[16] = { 77, 88, 102, 112, 124, 136, 148, 160,
+ 172, 184, 196, 207, 219, 231, 243, 255};
+
+static ssize_t show_pwm(struct device *dev, struct device_attribute *da,
+ char *buf)
+{
+ struct tc654_data *data = tc654_update_client(dev);
+ int pwm;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ if (data->config & TC654_REG_CONFIG_SDM)
+ pwm = 0;
+ else
+ pwm = tc654_pwm_map[data->duty_cycle];
+
+ return sprintf(buf, "%d\n", pwm);
+}
+
+static ssize_t set_pwm(struct device *dev, struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ struct tc654_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
+ unsigned long val;
+ int ret;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+ if (val > 255)
+ return -EINVAL;
+
+ mutex_lock(&data->update_lock);
+
+ if (val == 0)
+ data->config |= TC654_REG_CONFIG_SDM;
+ else
+ data->config &= ~TC654_REG_CONFIG_SDM;
+
+ data->duty_cycle = find_closest(val, tc654_pwm_map,
+ ARRAY_SIZE(tc654_pwm_map));
+
+ ret = i2c_smbus_write_byte_data(client, TC654_REG_CONFIG, data->config);
+ if (ret < 0)
+ goto out;
+
+ ret = i2c_smbus_write_byte_data(client, TC654_REG_DUTY_CYCLE,
+ data->duty_cycle);
+
+out:
+ mutex_unlock(&data->update_lock);
+ return ret < 0 ? ret : count;
+}
+
+static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, show_fan, NULL, 0);
+static SENSOR_DEVICE_ATTR(fan2_input, S_IRUGO, show_fan, NULL, 1);
+static SENSOR_DEVICE_ATTR(fan1_min, S_IWUSR | S_IRUGO, show_fan_min,
+ set_fan_min, 0);
+static SENSOR_DEVICE_ATTR(fan2_min, S_IWUSR | S_IRUGO, show_fan_min,
+ set_fan_min, 1);
+static SENSOR_DEVICE_ATTR(fan1_alarm, S_IRUGO, show_fan_alarm, NULL, 0);
+static SENSOR_DEVICE_ATTR(fan2_alarm, S_IRUGO, show_fan_alarm, NULL, 1);
+static SENSOR_DEVICE_ATTR(fan1_pulses, S_IWUSR | S_IRUGO, show_fan_pulses,
+ set_fan_pulses, 0);
+static SENSOR_DEVICE_ATTR(fan2_pulses, S_IWUSR | S_IRUGO, show_fan_pulses,
+ set_fan_pulses, 1);
+static SENSOR_DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
+ show_pwm_mode, set_pwm_mode, 0);
+static SENSOR_DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO, show_pwm,
+ set_pwm, 0);
+
+/* Driver data */
+static struct attribute *tc654_attrs[] = {
+ &sensor_dev_attr_fan1_input.dev_attr.attr,
+ &sensor_dev_attr_fan2_input.dev_attr.attr,
+ &sensor_dev_attr_fan1_min.dev_attr.attr,
+ &sensor_dev_attr_fan2_min.dev_attr.attr,
+ &sensor_dev_attr_fan1_alarm.dev_attr.attr,
+ &sensor_dev_attr_fan2_alarm.dev_attr.attr,
+ &sensor_dev_attr_fan1_pulses.dev_attr.attr,
+ &sensor_dev_attr_fan2_pulses.dev_attr.attr,
+ &sensor_dev_attr_pwm1_mode.dev_attr.attr,
+ &sensor_dev_attr_pwm1.dev_attr.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(tc654);
+
+/*
+ * device probe and removal
+ */
+
+static int tc654_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &client->dev;
+ struct tc654_data *data;
+ struct device *hwmon_dev;
+ int ret;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -ENODEV;
+
+ data = devm_kzalloc(dev, sizeof(struct tc654_data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->client = client;
+ mutex_init(&data->update_lock);
+
+ ret = i2c_smbus_read_byte_data(client, TC654_REG_CONFIG);
+ if (ret < 0)
+ return ret;
+
+ data->config = ret;
+
+ hwmon_dev =
+ devm_hwmon_device_register_with_groups(dev, client->name, data,
+ tc654_groups);
+ return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static const struct i2c_device_id tc654_id[] = {
+ {"tc654", 0},
+ {"tc655", 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, tc654_id);
+
+static struct i2c_driver tc654_driver = {
+ .driver = {
+ .name = "tc654",
+ },
+ .probe = tc654_probe,
+ .id_table = tc654_id,
+};
+
+module_i2c_driver(tc654_driver);
+
+MODULE_AUTHOR("Allied Telesis Labs");
+MODULE_DESCRIPTION("Microchip TC654/TC655 driver");
+MODULE_LICENSE("GPL");
--
2.10.0.479.g7c56b16
^ permalink raw reply related
* Re: [PATCH v4 8/8] Input: elan_i2c - add Host Notify support
From: Dmitry Torokhov @ 2016-10-10 21:39 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Wolfram Sang, Jean Delvare, Jonathan Corbet, KT Liao, Linux I2C,
linux-input@vger.kernel.org, linux-doc@vger.kernel.org, lkml
In-Reply-To: <1476117755-8113-9-git-send-email-benjamin.tissoires@redhat.com>
Hi Benjamin,
On Mon, Oct 10, 2016 at 9:42 AM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> The Thinkpad series 13 uses Host Notify to report the interrupt.
> Add elan_smb_alert() to handle those interrupts and disable the irq
> handling on this case.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
Why do we have to do this in the driver instead of having I2C core set
it up for us? I expect we'd be repeating this block of code for every
driver that has an option of using SMbus notify.
Thanks!
> ---
>
> new in v4 (was submitted on linux-input with the .alert callback)
> ---
> drivers/input/mouse/elan_i2c_core.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
> index 6f16eb4..4aaac5d 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -1040,6 +1040,21 @@ static int elan_probe(struct i2c_client *client,
> I2C_FUNC_SMBUS_BLOCK_DATA |
> I2C_FUNC_SMBUS_I2C_BLOCK)) {
> transport_ops = &elan_smbus_ops;
> +
> + if (!irq) {
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_HOST_NOTIFY)) {
> + dev_err(dev, "no Host Notify support\n");
> + return -ENODEV;
> + }
> +
> + irq = i2c_smbus_host_notify_to_irq(client);
> + if (irq < 0) {
> + dev_err(dev,
> + "Unable to request a Host Notify IRQ.\n");
> + return irq;
> + }
> + }
> } else {
> dev_err(dev, "not a supported I2C/SMBus adapter\n");
> return -EIO;
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* Re: [PATCHv4] hwmon: Add tc654 driver
From: Rob Herring @ 2016-10-10 21:54 UTC (permalink / raw)
To: Chris Packham
Cc: linux, linux-hwmon, iwamoto, Joshua.Scott, Kevin Tsai,
Wolfram Sang, Mark Rutland, Jean Delvare, Jonathan Corbet,
linux-i2c, devicetree, linux-kernel, linux-doc
In-Reply-To: <20161010212633.5436-1-chris.packham@alliedtelesis.co.nz>
On Tue, Oct 11, 2016 at 10:26:31AM +1300, Chris Packham wrote:
> Add support for the tc654 and tc655 fan controllers from Microchip.
>
> http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v4:
> - tab-align values in #defines
> - ensure locking in set_pwm covers updating cached values
> - populate the cached value for the config register in tc654_probe()
>
> Changes in v3:
> - typofix in documentation
> - add missing value to tc654_pwm_map, re-generate based on datasheet.
> - remove unnecessary hwmon_dev member from struct tc654_data
> - bug fixes in set_fan_min() and show_pwm_mode()
> - miscellaneous style fixes
>
> Changes in v2:
> - Add Documentation/hwmon/tc654
> - Incorporate most of the review comments from Guenter. Additional error
> handling is added. Unused/unnecessary code is removed. I decided not
> to go down the regmap path yet. I may circle back to it when I look at
> using regmap in the adm9240 driver.
>
> .../devicetree/bindings/i2c/trivial-devices.txt | 2 +
Expect a merge conflict with the IIO tree.
Acked-by: Rob Herring <robh@kernel.org>
> Documentation/hwmon/tc654 | 31 ++
> drivers/hwmon/Kconfig | 11 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/tc654.c | 514 +++++++++++++++++++++
> 5 files changed, 559 insertions(+)
> create mode 100644 Documentation/hwmon/tc654
> create mode 100644 drivers/hwmon/tc654.c
^ permalink raw reply
* Re: [PATCH 04/10] i2c: i2c-sam: Add device tree bindings
From: Peter Rosin @ 2016-10-11 7:13 UTC (permalink / raw)
To: Rob Herring, Pantelis Antoniou
Cc: Mark Rutland, Alexandre Courbot, devicetree, Florian Fainelli,
linux-watchdog, Georgi Vlaev, Wolfram Sang, Maryam Seraj,
Frank Rowand, Linus Walleij, linux-kernel, linux-gpio,
Wim Van Sebroeck, linux-mtd, Debjit Ghosh, netdev, Brian Norris,
Lee Jones, David Woodhouse, Guenter Roeck, linux-i2c
In-Reply-To: <20161010195458.GA20134@rob-hp-laptop>
On 2016-10-10 21:54, Rob Herring wrote:
> On Fri, Oct 07, 2016 at 06:18:32PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvlaev@juniper.net>
>>
>> Add binding document for the i2c driver of SAM FPGA.
>>
>> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
>> ---
>> .../devicetree/bindings/i2c/i2c-sam-mux.txt | 20 ++++++++++
>> Documentation/devicetree/bindings/i2c/i2c-sam.txt | 44 ++++++++++++++++++++++
>> 2 files changed, 64 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sam.txt
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt b/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
>> new file mode 100644
>> index 0000000..10ddffa
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
>> @@ -0,0 +1,20 @@
>> +Juniper's SAM FPGA I2C accelerator mux
>> +
>> +The SAM FPGA I2C mux is present only on Juniper SAM FPGA PTX series
>> +of routers.
>> +
>> +The definition of the i2c sam bus is located in the i2c-sam.txt document.
>> +
>> +Required properties:
>> +- compatible: should be "jnx,i2c-sam-mux".
>> +- reg: master number and mux number.
>
> This is not how i2c muxes are done.
>
>> +
>> +Optional properties:
>> +- speed: If present must be either 100000 or 400000. No other values supported.
>> +
>> +Examples:
>> +
>> +pe1i2c: i2c-sam-mux@1,0 {
>
> i2c-mux@...
>
>> + compatible = "jnx,i2c-sam-mux";
>> + reg = <1 0>;
>> +};
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-sam.txt b/Documentation/devicetree/bindings/i2c/i2c-sam.txt
>> new file mode 100644
>> index 0000000..4830b48
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-sam.txt
>> @@ -0,0 +1,44 @@
>> +Juniper's SAM FPGA I2C accelerator
>> +
>> +The SAM FPGA accelerator is used to connect the large number of
>> +I2C muxes that are present on Juniper PTX series of routers.
>> +While it's an i2c bus, no other devices are located besides
>> +i2c-sam-mux devices.
>> +
>> +The definition of the i2c sam mux is located in the i2c-sam-mux.txt document.
>> +
>> +Required properties:
>> +- compatible: should be "jnx,i2c-sam".
>> +- #address-cells: should be 2.
>> +- #size-cells: should be 0.
>> +- mux-channels: number of mux channels present
>
> What is this needed for?
>
>> +
>> +Optional properties:
>> +- reg: offset and length of the register set for the device are optional since
>> + typically the register range is provided by the parent SAM MFD device.
>> +- master-offset: Offset of where the master register memory starts.
>> + Default value is 0x8000.
>
> Make this required.
>
>> +- reverse-fill: Fill the start entries of transactions in reverse order
>
> Needs a better explanation.
>
>> +- priority-tables: Use the pre-programmed priority tables in the FPGA
>
> What does not present mean?
>
>> +- i2c-options: list of options to be written to the option field in the
>> + FPGA controlling things like SCL push-pull drives, hold-times, etc.
>
>> +- bus-range: start of bus master range and number of masters.
>
> Needs a better explanation.
>
>> +
>> +Examples:
>> +
>> +i2c-sam {
>> + compatible = "jnx,i2c-sam";
>> + mux-channels = <2>;
>> + #size-cells = <0>;
>> + #address-cells = <2>;
>> +
>> + /* PE0 */ pe0i2c: i2c-sam-mux@0,0 {
>
> i2c-mux@...
Hmm, I actually think i2c@... is the usual naming for i2c-mux children.
Cheers,
Peter
>> + compatible = "jnx,i2c-sam-mux";
>> + reg = <0 0>;
>> + };
>> +
>> + /* PE1 */ pe1i2c: i2c-sam-mux@1,0 {
>> + compatible = "jnx,i2c-sam-mux";
>> + reg = <1 0>;
>> + };
>> +};
>> --
>> 1.9.1
>>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 06/10] i2c: i2c-mux-ptxpmb-cpld: Add device tree bindings
From: Peter Rosin @ 2016-10-11 7:36 UTC (permalink / raw)
To: Rob Herring, Pantelis Antoniou
Cc: Mark Rutland, Alexandre Courbot, Georgi Vlaev, linux-watchdog,
Wolfram Sang, devicetree, Frank Rowand, Linus Walleij,
Guenter Roeck, linux-kernel, JawaharBalaji Thirumalaisamy,
linux-gpio, Wim Van Sebroeck, linux-mtd, Debjit Ghosh, Rajat Jain,
Brian Norris, Lee Jones, David Woodhouse, Guenter Roeck,
linux-i2c
In-Reply-To: <20161010174517.GA18097@rob-hp-laptop>
On 2016-10-10 19:45, Rob Herring wrote:
> On Fri, Oct 07, 2016 at 06:17:27PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvlaev@juniper.net>
>>
>> Add binding document for the i2c driver of PTXPMB CPLD.
>>
>> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
>> ---
>> .../bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt | 50 ++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt
>> new file mode 100644
>> index 0000000..3b201f7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-ptxpmb-cpld.txt
>> @@ -0,0 +1,50 @@
>> +* Juniper PTXPMB CPLD I2C Mux
>> +
>> +I2C mux on the PTXPMB CPLD on Juniper series of routers.
>> +
>> +Required properties:
>> +
>> + - compatible: Must contain one of the following.
>> + "jnx,i2c-mux-ptxpmb-cpld", "jnx,i2c-mux-ngpmb-bcpld"
>> + - num-enable: Number of muxes to enable.
>
> No. Use status property.
Reading the code, I understand this mux to be like a combination of
i2c switches (like pca9548) where the slave i2c busses can be
enabled individually using an "enable" bitmask in one register, and
"regular" i2c muxes (like pca9547) where you can only select one
slave i2c bus at a time using an enumeration.
num-enable would be the number of switches and num-channels would be
the number of muxes per switch channel. Or the other way around? This
is a real problem. The bindings are too tightly coupled to the way
Linux currently handles i2c switches (i.e. not very well, you can only
select one slave bus on an i2c switch, thus reducing the more
flexible switch hardware to a regular mux). The bindings should not
describe what the driver does, they should describe the hardware.
Basically, you need to describe the i2c topology of the hardware in
the bindings, because I'm just guessing all this, and I shouldn't
have to.
Cheers,
Peter
>> +
>> + The following required properties are defined externally:
>> +
>> + - Standard I2C mux properties. See i2c-mux.txt in this directory.
>> + - I2C child bus nodes. See i2c-mux.txt in this directory.
>> +
>> +Optional Properties:
>> +
>> + - num-channels: Number of channels. If not present the default is 8.
>
> What's a channel?
>
>> + - base-bus-num: Base bus number. If not present it is 0.
>
> No. Linuxism and why do you care?
>
>> + - use-force: Use the force method of the controller.
>> +
>> +
>> +Example:
>> +
>> +cpld-i2c-mux {
>
> mux {
>
>> + compatible = "jnx,i2c-mux-ptxpmb-cpld";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + i2c-parent = <&i2c1>;
>> +
>> + num-enable = <1>;
>> +
>> + i2c@0 {
>> + reg = <0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* PMB devices are accessed through FPC */
>> +
>> + temp-sensor@1a { /* FPC */
>> + compatible = "maxim,max6697";
>> + reg = <0x1a>;
>> + smbus-timeout-disable;
>> + resistance-cancellation;
>> + alert-mask = <0xff>;
>> + over-temperature-mask = <0xff>;
>> + };
>> + };
>> +};
>> --
>> 1.9.1
>>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ 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