All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Samuel Ortiz <samuel.ortiz@intel.com>
Cc: kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	"Ying-Chun Liu (PaulLiu)" <paulliu@debian.org>,
	"Philippe Rétornaz" <philippe.retornaz@epfl.ch>,
	"Marc Reilly" <marc@cpdesign.com.au>,
	"Mark Brown" <broonie@opensource.wolfsonmicro.com>,
	"Samuel Ortiz" <sameo@linux.intel.com>
Subject: [PATCH 2/7] MFD: mc13xxx workaround SPI hardware bug on i.Mx
Date: Thu, 12 Jul 2012 11:57:48 +0200	[thread overview]
Message-ID: <1342087073-3892-3-git-send-email-u.kleine-koenig@pengutronix.de> (raw)
In-Reply-To: <1342087073-3892-1-git-send-email-u.kleine-koenig@pengutronix.de>

From: Philippe Rétornaz <philippe.retornaz@epfl.ch>

The MC13xxx PMIC is mainly used on i.Mx SoC. On thoses SoC the SPI
hardware will deassert CS line as soon as the SPI FIFO is empty.
The MC13xxx hardware is very sensitive to CS line change as it
corrupts the transfert if CS is deasserted in the middle of a register
read or write.
It is not possible to use the CS line as a GPIO on some SoC, so we
need to workaround this by implementing a single SPI transfer to
access the PMIC.

Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Marc Reilly <marc@cpdesign.com.au>
Signed-off-by: Philippe Rétornaz <philippe.retornaz@epfl.ch>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Origin: next-20120712, commit:e4ecf6ea84d68aea5a9785e89f52672e1e126998
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/mfd/mc13xxx-spi.c |   65 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/mc13xxx-spi.c b/drivers/mfd/mc13xxx-spi.c
index 5d1969f..03df422 100644
--- a/drivers/mfd/mc13xxx-spi.c
+++ b/drivers/mfd/mc13xxx-spi.c
@@ -54,6 +54,67 @@ static struct regmap_config mc13xxx_regmap_spi_config = {
 	.max_register = MC13XXX_NUMREGS,
 
 	.cache_type = REGCACHE_NONE,
+	.use_single_rw = 1,
+};
+
+static int mc13xxx_spi_read(void *context, const void *reg, size_t reg_size,
+				void *val, size_t val_size)
+{
+	unsigned char w[4] = { *((unsigned char *) reg), 0, 0, 0};
+	unsigned char r[4];
+	unsigned char *p = val;
+	struct device *dev = context;
+	struct spi_device *spi = to_spi_device(dev);
+	struct spi_transfer t = {
+		.tx_buf = w,
+		.rx_buf = r,
+		.len = 4,
+	};
+
+	struct spi_message m;
+	int ret;
+
+	if (val_size != 3 || reg_size != 1)
+		return -ENOTSUPP;
+
+	spi_message_init(&m);
+	spi_message_add_tail(&t, &m);
+	ret = spi_sync(spi, &m);
+
+	memcpy(p, &r[1], 3);
+
+	return ret;
+}
+
+static int mc13xxx_spi_write(void *context, const void *data, size_t count)
+{
+	struct device *dev = context;
+	struct spi_device *spi = to_spi_device(dev);
+
+	if (count != 4)
+		return -ENOTSUPP;
+
+	return spi_write(spi, data, count);
+}
+
+/*
+ * We cannot use regmap-spi generic bus implementation here.
+ * The MC13783 chip will get corrupted if CS signal is deasserted
+ * and on i.Mx31 SoC (the target SoC for MC13783 PMIC) the SPI controller
+ * has the following errata (DSPhl22960):
+ * "The CSPI negates SS when the FIFO becomes empty with
+ * SSCTL= 0. Software cannot guarantee that the FIFO will not
+ * drain because of higher priority interrupts and the
+ * non-realtime characteristics of the operating system. As a
+ * result, the SS will negate before all of the data has been
+ * transferred to/from the peripheral."
+ * We workaround this by accessing the SPI controller with a
+ * single transfert.
+ */
+
+static struct regmap_bus regmap_mc13xxx_bus = {
+	.write = mc13xxx_spi_write,
+	.read = mc13xxx_spi_read,
 };
 
 static int mc13xxx_spi_probe(struct spi_device *spi)
@@ -78,7 +139,9 @@ static int mc13xxx_spi_probe(struct spi_device *spi)
 	mc13xxx->dev = &spi->dev;
 	mutex_init(&mc13xxx->lock);
 
-	mc13xxx->regmap = regmap_init_spi(spi, &mc13xxx_regmap_spi_config);
+	mc13xxx->regmap = regmap_init(&spi->dev, &regmap_mc13xxx_bus, &spi->dev,
+					&mc13xxx_regmap_spi_config);
+
 	if (IS_ERR(mc13xxx->regmap)) {
 		ret = PTR_ERR(mc13xxx->regmap);
 		dev_err(mc13xxx->dev, "Failed to initialize register map: %d\n",
-- 
1.7.10.4


WARNING: multiple messages have this Message-ID (diff)
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/7] MFD: mc13xxx workaround SPI hardware bug on i.Mx
Date: Thu, 12 Jul 2012 11:57:48 +0200	[thread overview]
Message-ID: <1342087073-3892-3-git-send-email-u.kleine-koenig@pengutronix.de> (raw)
In-Reply-To: <1342087073-3892-1-git-send-email-u.kleine-koenig@pengutronix.de>

From: Philippe R?tornaz <philippe.retornaz@epfl.ch>

The MC13xxx PMIC is mainly used on i.Mx SoC. On thoses SoC the SPI
hardware will deassert CS line as soon as the SPI FIFO is empty.
The MC13xxx hardware is very sensitive to CS line change as it
corrupts the transfert if CS is deasserted in the middle of a register
read or write.
It is not possible to use the CS line as a GPIO on some SoC, so we
need to workaround this by implementing a single SPI transfer to
access the PMIC.

Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Marc Reilly <marc@cpdesign.com.au>
Signed-off-by: Philippe R?tornaz <philippe.retornaz@epfl.ch>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Origin: next-20120712, commit:e4ecf6ea84d68aea5a9785e89f52672e1e126998
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 drivers/mfd/mc13xxx-spi.c |   65 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/mc13xxx-spi.c b/drivers/mfd/mc13xxx-spi.c
index 5d1969f..03df422 100644
--- a/drivers/mfd/mc13xxx-spi.c
+++ b/drivers/mfd/mc13xxx-spi.c
@@ -54,6 +54,67 @@ static struct regmap_config mc13xxx_regmap_spi_config = {
 	.max_register = MC13XXX_NUMREGS,
 
 	.cache_type = REGCACHE_NONE,
+	.use_single_rw = 1,
+};
+
+static int mc13xxx_spi_read(void *context, const void *reg, size_t reg_size,
+				void *val, size_t val_size)
+{
+	unsigned char w[4] = { *((unsigned char *) reg), 0, 0, 0};
+	unsigned char r[4];
+	unsigned char *p = val;
+	struct device *dev = context;
+	struct spi_device *spi = to_spi_device(dev);
+	struct spi_transfer t = {
+		.tx_buf = w,
+		.rx_buf = r,
+		.len = 4,
+	};
+
+	struct spi_message m;
+	int ret;
+
+	if (val_size != 3 || reg_size != 1)
+		return -ENOTSUPP;
+
+	spi_message_init(&m);
+	spi_message_add_tail(&t, &m);
+	ret = spi_sync(spi, &m);
+
+	memcpy(p, &r[1], 3);
+
+	return ret;
+}
+
+static int mc13xxx_spi_write(void *context, const void *data, size_t count)
+{
+	struct device *dev = context;
+	struct spi_device *spi = to_spi_device(dev);
+
+	if (count != 4)
+		return -ENOTSUPP;
+
+	return spi_write(spi, data, count);
+}
+
+/*
+ * We cannot use regmap-spi generic bus implementation here.
+ * The MC13783 chip will get corrupted if CS signal is deasserted
+ * and on i.Mx31 SoC (the target SoC for MC13783 PMIC) the SPI controller
+ * has the following errata (DSPhl22960):
+ * "The CSPI negates SS when the FIFO becomes empty with
+ * SSCTL= 0. Software cannot guarantee that the FIFO will not
+ * drain because of higher priority interrupts and the
+ * non-realtime characteristics of the operating system. As a
+ * result, the SS will negate before all of the data has been
+ * transferred to/from the peripheral."
+ * We workaround this by accessing the SPI controller with a
+ * single transfert.
+ */
+
+static struct regmap_bus regmap_mc13xxx_bus = {
+	.write = mc13xxx_spi_write,
+	.read = mc13xxx_spi_read,
 };
 
 static int mc13xxx_spi_probe(struct spi_device *spi)
@@ -78,7 +139,9 @@ static int mc13xxx_spi_probe(struct spi_device *spi)
 	mc13xxx->dev = &spi->dev;
 	mutex_init(&mc13xxx->lock);
 
-	mc13xxx->regmap = regmap_init_spi(spi, &mc13xxx_regmap_spi_config);
+	mc13xxx->regmap = regmap_init(&spi->dev, &regmap_mc13xxx_bus, &spi->dev,
+					&mc13xxx_regmap_spi_config);
+
 	if (IS_ERR(mc13xxx->regmap)) {
 		ret = PTR_ERR(mc13xxx->regmap);
 		dev_err(mc13xxx->dev, "Failed to initialize register map: %d\n",
-- 
1.7.10.4

  parent reply	other threads:[~2012-07-12 10:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-12  9:57 [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver Uwe Kleine-König
2012-07-12  9:57 ` Uwe Kleine-König
2012-07-12  9:57 ` [PATCH 1/7] MFD: Fix mc13xxx SPI regmap Uwe Kleine-König
2012-07-12  9:57   ` Uwe Kleine-König
2012-07-12  9:57 ` Uwe Kleine-König [this message]
2012-07-12  9:57   ` [PATCH 2/7] MFD: mc13xxx workaround SPI hardware bug on i.Mx Uwe Kleine-König
2012-07-12  9:57 ` [PATCH 3/7] rtc/mc13xxx: use MODULE_DEVICE_TABLE instead of MODULE_ALIAS Uwe Kleine-König
2012-07-12  9:57   ` Uwe Kleine-König
2012-07-12  9:57 ` [PATCH 4/7] rtc/mc13xxx: add support for the rtc in the mc34708 pmic Uwe Kleine-König
2012-07-12  9:57   ` Uwe Kleine-König
2012-07-12  9:57 ` [PATCH 5/7] mfd/mc13xxx: drop modifying driver's id_table in probe Uwe Kleine-König
2012-07-12  9:57   ` Uwe Kleine-König
2012-07-12  9:57 ` [PATCH 6/7] mfd/mc13xxx: change probing details for mc13xxx devices Uwe Kleine-König
2012-07-12  9:57   ` Uwe Kleine-König
2012-07-13 15:22   ` Uwe Kleine-König
2012-07-13 15:22     ` Uwe Kleine-König
2012-07-12  9:57 ` [PATCH 7/7] mfd/mc13xxx: add support for mc34708 Uwe Kleine-König
2012-07-12  9:57   ` Uwe Kleine-König
2012-07-12 23:02 ` [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver Marc Reilly
2012-07-12 23:02   ` Marc Reilly
2012-07-13  8:48   ` Uwe Kleine-König
2012-07-13  8:48     ` Uwe Kleine-König
2012-07-13 19:39     ` Junio C Hamano
2012-09-05 14:22   ` Fabio Estevam
2012-09-05 14:22     ` Fabio Estevam
2012-10-04 13:01     ` Fabio Estevam
2012-10-04 13:01       ` Fabio Estevam
2012-10-04 13:51       ` Samuel Ortiz
2012-10-04 13:51         ` Samuel Ortiz
2012-10-04 14:11         ` Uwe Kleine-König
2012-10-04 14:11           ` Uwe Kleine-König
2012-10-27 19:19         ` Fabio Estevam
2012-10-27 19:19           ` Fabio Estevam
2012-11-06 22:24           ` Samuel Ortiz
2012-11-06 22:24             ` Samuel Ortiz
2012-08-02 15:52 ` Fabio Estevam
2012-08-02 15:52   ` Fabio Estevam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1342087073-3892-3-git-send-email-u.kleine-koenig@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc@cpdesign.com.au \
    --cc=paulliu@debian.org \
    --cc=philippe.retornaz@epfl.ch \
    --cc=sameo@linux.intel.com \
    --cc=samuel.ortiz@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.