From: andy@warmcat.com (Andy Green)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3 10/18] I2C: OMAP2+: address confused probed version naming
Date: Tue, 15 Mar 2011 19:57:04 +0000 [thread overview]
Message-ID: <20110315195704.30000.56240.stgit@otae.warmcat.com> (raw)
In-Reply-To: <20110315195147.30000.86184.stgit@otae.warmcat.com>
The driver reflects the confusion that probed I2C revision
from the hardware of 0x40 means it is on an OMAP4430.
However, you will probe the same 0x40 ID on an OMAP3530. So
this patch changes the name to reflect that.
It also clarifies that the original name OMAP_I2C_REV_2 is
referring to some ancient OMAP1 revision number, not to be
confused with the IP revisions this patch series introduces.
Similarly the term "rev" is used in the ancient OMAP1 ISR,
the term is changed to use omap1 instead.
Cc: patches at linaro.org
Cc: Ben Dooks <ben-linux@fluff.org>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andy Green <andy.green@linaro.org>
---
drivers/i2c/busses/i2c-omap.c | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 14f5b50..ecb48c7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -42,12 +42,12 @@
#include <linux/pm_runtime.h>
/* I2C controller revisions */
-#define OMAP_I2C_REV_2 0x20
+#define OMAP_I2C_OMAP1_REV_2 0x20
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_4430 0x40
+#define OMAP_I2C_REV_ON_3530_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -314,7 +314,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
else
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
- if (dev->rev < OMAP_I2C_REV_2) {
+ if (dev->rev < OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
} else {
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
@@ -336,7 +336,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long internal_clk = 0;
struct clk *fclk;
- if (dev->rev >= OMAP_I2C_REV_2) {
+ if (dev->rev >= OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
omap_i2c_read_reg(dev, OMAP_I2C_CON_REG) &
@@ -379,7 +379,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev->westate = OMAP_I2C_WE_ALL;
- if (dev->rev < OMAP_I2C_REV_ON_4430)
+ if (dev->rev < OMAP_I2C_REV_ON_3530_4430)
omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
dev->westate);
}
@@ -723,7 +723,7 @@ static inline void i2c_omap_errata_i207(struct omap_i2c_dev *dev, u16 stat)
#ifdef CONFIG_ARCH_OMAP15XX
static irqreturn_t
-omap_i2c_rev1_isr(int this_irq, void *dev_id)
+omap_i2c_omap1_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 iv, w;
@@ -777,7 +777,7 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
#else
-#define omap_i2c_rev1_isr NULL
+#define omap_i2c_omap1_isr NULL
#endif
/*
@@ -1062,7 +1062,7 @@ omap_i2c_probe(struct platform_device *pdev)
* size. This is to ensure that we can handle the status on int
* call back latencies.
*/
- if (dev->rev >= OMAP_I2C_REV_ON_4430) {
+ if (dev->rev >= OMAP_I2C_REV_ON_3530_4430) {
dev->fifo_size = 0;
dev->b_hw = 0; /* Disable hardware fixes */
} else {
@@ -1078,7 +1078,8 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
+ isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
+ omap_i2c_isr;
r = request_irq(dev->irq, isr, 0, pdev->name, dev);
if (r) {
next prev parent reply other threads:[~2011-03-15 19:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 19:55 [PATCH 3 00/18] I2C: OMAP1: OMAP2+: I2C fixes, removal of cpu_is... from driver Andy Green
2011-03-15 19:55 ` [PATCH 3 01/18] OMAP2+: hwmod data: Set hwmod flags to only allow 16-bit accesses to i2c Andy Green
2011-03-15 19:56 ` [PATCH 3 02/18] I2C: OMAP2+: Name registers in I2C IP V2 only accordingly Andy Green
2011-03-15 19:56 ` [PATCH 3 03/18] I2C: OMAP2+: Introduce I2C IP versioning constants Andy Green
2011-03-15 19:56 ` [PATCH 3 04/18] I2C: OMAP2+: hwmod data: Tag all OMAP2+ hwmod definitions with I2C IP revision Andy Green
2011-03-15 19:56 ` [PATCH 3 05/18] I2C: OMAP: add rev to omap i2c platform data Andy Green
2011-03-15 19:56 ` [PATCH 3 06/18] I2C: OMAP1: set IP revision in " Andy Green
2011-03-15 19:56 ` [PATCH 3 07/18] I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added Andy Green
2011-03-15 19:56 ` [PATCH 3 08/18] I2C: OMAP2+: use platform_data ip revision to select register map Andy Green
2011-03-15 19:56 ` [PATCH 3 09/18] I2C: OMAP2+: Solve array bounds overflow error on i2c idle Andy Green
2011-03-15 19:57 ` Andy Green [this message]
2011-03-15 19:57 ` [PATCH 3 11/18] I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32 Andy Green
2011-03-15 19:57 ` [PATCH 3 12/18] I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data Andy Green
2011-03-15 19:57 ` [PATCH 3 13/18] I2C: OMAP2+: Pass flags up to omap i2c platform_data as well Andy Green
2011-03-15 19:57 ` [PATCH 3 14/18] I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test Andy Green
2011-03-15 19:57 ` [PATCH 3 15/18] OMAP2+: hwmod data: add correct functionality flags to all omap2plus i2c dev_attr Andy Green
2011-03-15 19:57 ` [PATCH 3 16/18] I2C: OMAP1: set i2c unit feature implementation flags in platform data Andy Green
2011-03-15 19:57 ` [PATCH 3 17/18] I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from " Andy Green
2011-03-15 19:58 ` [PATCH 3 18/18] I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info Andy Green
2011-03-15 22:28 ` [PATCH 3 00/18] I2C: OMAP1: OMAP2+: I2C fixes, removal of cpu_is... from driver Tony Lindgren
2011-03-16 7:22 ` Andy Green
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=20110315195704.30000.56240.stgit@otae.warmcat.com \
--to=andy@warmcat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).