MFD: DA9052 MFD core module v2

The DA9052 is a highly integrated PMIC subsystem with supply domain flexibility to support wide range of high performance application.

It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery control and other functionality.

Signed-off-by David Dajun Chen <[email protected]>

Signed-off-by Ashish Jangam <[email protected]>

-----Original Message-----
From: Arnd Bergmann [mailto:[email protected]]
Sent: Tuesday, July 05, 2011 8:25 PM
To: Ashish Jangam
Cc: Mark Brown; [email protected]; [email protected]; Dajun; [email protected]
Subject: Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

Quoted 1 line · On Tuesday 05 July 2011, ashishj3 wrote:

The DA9052 is a highly integrated PMIC subsystem with supply domain

flexibility

Quoted 2 lines

to support wide range of high performance application.

Quoted 5 lines

It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery control and other functionality.

Signed-off-by David Dajun Chen <[email protected]>

Signed-off-by Ashish Jangam <[email protected]>

Reviewed-by Arnd Bergmann <[email protected]>

Quoted 3 lines

-----Original Message-----
From: Arnd Bergmann [mailto:[email protected]]
Sent: Tuesday, July 05, 2011 8:25 PM

Can anyone ack this patch?

Quoted 13 lines

-----Original Message-----
From: Arnd Bergmann [mailto:[email protected]]
Sent: Tuesday, July 05, 2011 8:25 PM
To: Ashish Jangam
Cc: Mark Brown; [email protected]; [email protected]; Dajun; [email protected]
Subject: Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

Quoted 1 line · On Tuesday 05 July 2011, ashishj3 wrote:

The DA9052 is a highly integrated PMIC subsystem with supply domain

flexibility

Quoted 2 lines

to support wide range of high performance application.

Quoted 7 lines

Quoted 5 lines

It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery control and other functionality.

Signed-off-by David Dajun Chen <[email protected]>

Signed-off-by Ashish Jangam <[email protected]>

Reviewed-by Arnd Bergmann <[email protected]>

Can anyone ack this patch?

-----Original Message-----
From: Arnd Bergmann [mailto:[email protected]]
Sent: Wednesday, July 13, 2011 12:03 AM
To: Ashish Jangam
Cc: Mark Brown; [email protected]; [email protected]; Dajun; [email protected]
Subject: Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

Quoted 8 lines · On Monday 11 July 2011 08:57:46 Ashish Jangam wrote:

Quoted 8 lines

-----Original Message-----
From: Arnd Bergmann [mailto:[email protected]]
Sent: Tuesday, July 05, 2011 8:25 PM
To: Ashish Jangam
Cc: Mark Brown; [email protected]; [email protected]; Dajun; [email protected]
Subject: Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

Quoted 6 lines

Quoted 6 lines · On Tuesday 05 July 2011, ashishj3 wrote:

Quoted 1 line

The DA9052 is a highly integrated PMIC subsystem with supply domain

flexibility

Quoted 3 lines

to support wide range of high performance application.

It provides voltage regulators, GPIO controller, Touch Screen, RTC,

Battery

Quoted 7 lines

Quoted 6 lines

Quoted 4 lines

control and other functionality.

Signed-off-by David Dajun Chen <[email protected]>

Signed-off-by Ashish Jangam <[email protected]>

Reviewed-by Arnd Bergmann <[email protected]>

Can anyone ack this patch?

What do you think my message was? Reviewed-by is usually stronger than Acked-by, it means that I actually had a closer look and am now happy with the current state.

Of course, my Ack might not mean too much because I'm not a maintainer, but I still would expect to be included in 'anyone'.

Arnd

The DA9052 is a highly integrated PMIC subsystem with supply domain flexibility to support wide range of high performance application.

It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery control and other functionality.

Signed-off-by David Dajun Chen <[email protected]>

Signed-off-by Ashish Jangam <[email protected]>

---
Changes since v2:
- Drop da9052_irqs[] table.
- Move struct da9052_subdev_info[].
- Remove initialization of static member.
- Care for NULL pdata init().
- Check removal of subdevices on errors.
- Remove open source spi code.
- Remove '_spi' from the driver name.
- Move tbat_lookup table from header file.
- Remove irq.h
- Remove num_gpio variable from pdata

---
 drivers/mfd/Kconfig               |   25 ++
 drivers/mfd/Makefile              |    7 +
 drivers/mfd/da9052-core.c         |  539 +++++++++++++++++++++++++
 drivers/mfd/da9052-i2c.c          |  168 ++++++++
 drivers/mfd/da9052-irq.c          |  168 ++++++++
 drivers/mfd/da9052-spi.c          |  132 +++++++
 include/linux/mfd/da9052/da9052.h |   91 +++++
 include/linux/mfd/da9052/pdata.h  |   43 ++
 include/linux/mfd/da9052/reg.h    |  777 +++++++++++++++++++++++++++++++++++++
 9 files changed, 1950 insertions(+), 0 deletions(-)
 create mode 100755 drivers/mfd/da9052-core.c
 create mode 100755 drivers/mfd/da9052-i2c.c
 create mode 100755 drivers/mfd/da9052-irq.c
 create mode 100755 drivers/mfd/da9052-spi.c
 create mode 100755 include/linux/mfd/da9052/da9052.h
 create mode 100755 include/linux/mfd/da9052/pdata.h
 create mode 100755 include/linux/mfd/da9052/reg.h

drivers/mfd/da9052-core.c new file +29 -0

+
+	if (da9052->read_dev == NULL || da9052->write_dev == NULL) {
+		ret = -ENODEV;
+		goto err;
+	}
+
+	ret = da9052->read_dev(da9052, reg, 1, &val);
+	if (ret < 0)
+		goto err;
+
+	val &= ~bit_mask;
+	val |= reg_val;
+
+	ret = da9052->write_dev(da9052, reg, 1, &val);
+	if (ret < 0)
+		goto err;
+
+	mutex_unlock(&da9052->io_lock);
+
+	return 0;
+
+err:
+	mutex_unlock(&da9052->io_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(da9052_reg_update);
+
+int da9052_set_bits(struct da9052 *da9052, unsigned char reg,
+		     unsigned char bit_mask)

drivers/mfd/da9052-core.c new file +28 -0

+
+	if (da9052->read_dev == NULL || da9052->write_dev == NULL) {
+		ret = -ENODEV;
+		goto err;
+	}
+
+	ret = da9052->read_dev(da9052, reg, 1, &val);
+	if (ret < 0)
+		goto err;
+
+	val |= bit_mask;
+
+	ret = da9052->write_dev(da9052, reg, 1, &val);
+	if (ret < 0)
+		goto err;
+
+	mutex_unlock(&da9052->io_lock);
+
+	return 0;
+
+err:
+	mutex_unlock(&da9052->io_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(da9052_set_bits);
+
+int da9052_clear_bits(struct da9052 *da9052, unsigned char reg,
+		       unsigned char bit_mask)

drivers/mfd/da9052-core.c new file +25 -0

+
+	if (da9052->read_dev == NULL || da9052->write_dev == NULL) {
+		ret = -ENODEV;
+		goto err;
+	}
+
+	ret = da9052->read_dev(da9052, reg, 1, &val);
+	if (ret < 0)
+		goto err;
+
+	val &= ~bit_mask;
+
+	ret = da9052->write_dev(da9052, reg, 1, &val);
+	if (ret < 0)
+		goto err;
+
+	mutex_unlock(&da9052->io_lock);
+
+	return 0;
+
+err:
+	mutex_unlock(&da9052->io_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(da9052_clear_bits);

drivers/mfd/da9052-i2c.c new file +22 -0

+static int __devinit da9052_i2c_probe(struct i2c_client *client,
+				       const struct i2c_device_id *id)
+{
+	struct i2c_adapter *adapter;
+	struct da9052 *da9052_i2c;
+	int ret;
+
+	da9052_i2c = kzalloc(sizeof(struct da9052), GFP_KERNEL);
+	if (!da9052_i2c)
+		return -ENOMEM;
+
+	adapter = to_i2c_adapter(client->dev.parent);
+
+	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
+		dev_info(&client->dev, "Error in %s:i2c_check_functionality\n",
+			 __func__);
+		return -ENODEV;
+	}
+
+	da9052_i2c->i2c_client = client;
+	da9052_i2c->dev = &client->dev;
+

drivers/mfd/da9052-i2c.c new file +9 -0

+	if (ret != 0)
+		goto err;
+
+	return 0;
+
+err:
+	kfree(da9052_i2c);
+	return ret;
+}

drivers/mfd/da9052-spi.c new file +4 -0

+int da9052_spi_read_device(struct da9052 *da9052, unsigned char reg,
+			    unsigned bytes, unsigned char *val)
+{
+	int ret, raddr;

drivers/mfd/da9052-spi.c new file +14 -0

+}
+
+static int da9052_spi_probe(struct spi_device *spi)
+{
+	int ret;
+	struct da9052 *da9052_spi = kzalloc(sizeof(struct da9052), GFP_KERNEL);
+
+	if (!da9052_spi)
+		return -ENOMEM;
+
+	spi->mode = SPI_MODE_0 | SPI_CPOL;
+	spi->bits_per_word = 8;
+	spi_setup(spi);
+

Review

Quoted 1 line · On Tue, Jul 05, 2011 at 08:07:00PM +0530, ashishj3 wrote:

(quoted diff) +1 -0

+	mutex_lock_interruptible(&da9052->io_lock);

Compile warning as below.

"warning: ignoring return value of ‘mutex_lock_interruptible’, declared with attribute warn_unused_result"

Quoted 3 lines · Shawn Guo

Quoted 1 line · On Tue, Jul 05, 2011 at 08:07:00PM +0530, ashishj3 wrote:

+ mutex_lock_interruptible(&da9052->io_lock);

Quoted 4 lines

Compile warning as below.

"warning: ignoring return value of ‘mutex_lock_interruptible’, declared with attribute warn_unused_result"

Although the bigger problem is why are these interruptible? That's very unusual.

Quoted 2 lines · On Thursday 21 July 2011 16:47:48 Mark Brown wrote:

Although the bigger problem is why are these interruptible? That's very unusual.

Well, the default should really be to use _interruptible or at least _killable with the appropriate error handling, and only use noninterruptible locks in cases where that's not possible.

In the funtions that Shawn pointed out, there is an error return, so it would be possible to do that, but the callers would need to be audited carefully.

We went round this analysis already with the underlying I2C drivers (which also end up needing to take mutexes and so on) - it really does work out better to just make the I/O noninterruptible, the I/O is fast enough to not really be worth interrupting and the handling for actual I/O errors should normally be sufficiently different to that for user initiated aborts that it just adds complication.

For example, if the user interrupts while we're in the middle of some lengthy series of operations or wait what we really want to do is to tear down the high level thing we're doing in an orderly fashion. If we allow the interrupt to be noticed as part of an I/O operation then what we often end up doing is failing that and we then have to work out why the I/O failed, if actually happened on a physical level and how we deal with that. Usually none of these paths will be well tested.

The overall result is that the system generally becomes more complicated and less robust.

Yes, that makes sense. There are also cases where a mutex should really be a spinlock (which is by definition not interruptible), or vice versa. I don't know if this is one of them.

The DA9052 is a highly integrated PMIC subsystem with supply domain flexibility to support wide range of high performance application.

It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery control and other functionality.

Signed-off-by David Dajun Chen <[email protected]>

Signed-off-by Ashish Jangam <[email protected]>

---

include/linux/mfd/da9052/pdata.h new file +25 -0

new file mode 100755
index 0000000..75d82a3
@@ -0,0 +1,43 @@
+/*
+ * Platform data declarations for DA9052 PMICs.
+ *
+ * Copyright(c) 2011 Dialog Semiconductor Ltd.
+ *
+ * Author: David Dajun Chen <[email protected]>
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#ifndef __MFD_DA9052_PDATA_H__
+#define __MFD_DA9052_PDATA_H__

include/linux/mfd/da9052/pdata.h new file +6 -0

+	int irq;
+	int irq_base;
+	int num_regulators;
+	int gpio_base;
+	struct regulator_init_data *regulators[DA9052_MAX_REGULATORS];
+};