* [PATCHv2 0/7] i2c: omap: updates
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
Does the followiing
- Make the revision a 32- bit consisting of rev_lo amd rev_hi each
of 16 bits.
- Also use the revision register for the erratum i207.
- Refactor the i2c_omap_init code.
Also more cleanup is possible will check on that subsequently.
Tested on OMAP4430sdp ,4460 ,omap3630 ,3430 and omap2430.
For omap2 testing the below patch was used
[PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
Also for using the pm testing below patches are used.
arm: sched: stop sched_clock() during suspend
ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
Also available through
git://gitorious.org/linus-tree/linus-tree.git i2c_omap/for_3.8
Shubhrajyoti D (7):
i2c: omap: Fix the revision register read
i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
i2c: omap: remove the dtrev
ARM: i2c: omap: Remove the i207 errata flag
i2c: omap: re-factor omap_i2c_init function
i2c: omap: make reset a seperate function
i2c: omap: Restore i2c context always
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 3 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 +-
drivers/i2c/busses/i2c-omap.c | 166 +++++++++++++++++-----------
include/linux/i2c-omap.h | 1 -
4 files changed, 104 insertions(+), 75 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCHv2 1/7] i2c: omap: Fix the revision register read
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352025873-27492-1-git-send-email-shubhrajyoti@ti.com>
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
Also use the scheme bit ie bit-14 of the hi register to know if it
is OMAP_I2C_IP_VERSION_2.
On platforms previous to OMAP4 the offset 0x04 is IE register whose
bit-14 reset value is 0, the code uses the same to its advantage.
Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
to fetch the revision register.
The dev->regs is populated after reading the rev_hi. A NULL check
has been added in the resume handler to prevent the access before
the setting of the regs.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 61 ++++++++++++++++++++++++++++++++---------
1 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..72fce6d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -49,9 +49,10 @@
#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_3530 0x3C
-#define OMAP_I2C_REV_ON_3630_4430 0x40
+#define OMAP_I2C_REV_ON_2430 0x00000036
+#define OMAP_I2C_REV_ON_3430_3530 0x0000003C
+#define OMAP_I2C_REV_ON_3630 0x00000040
+#define OMAP_I2C_REV_ON_4430_PLUS 0x50400002
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -202,7 +203,7 @@ struct omap_i2c_dev {
* fifo_size==0 implies no fifo
* if set, should be trsh+1
*/
- u8 rev;
+ u32 rev;
unsigned b_hw:1; /* bad h/w fixes */
unsigned receiver:1; /* true when we're in receiver mode */
u16 iestate; /* Saved interrupt register */
@@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
- if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
+ if (dev->rev < OMAP_I2C_REV_ON_3630)
dev->b_hw = 1; /* Enable hardware fixes */
/* calculate wakeup latency constraint for MPU */
@@ -1052,6 +1053,16 @@ static const struct of_device_id omap_i2c_of_match[] = {
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
#endif
+#define OMAP_I2C_SCHEME(rev) ((rev & 0xc000) >> 14)
+
+#define OMAP_I2C_REV_SCHEME_0_MAJOR(rev) (rev >> 4)
+#define OMAP_I2C_REV_SCHEME_0_MINOR(rev) (rev & 0xf)
+
+#define OMAP_I2C_REV_SCHEME_1_MAJOR(rev) ((rev & 0x0700) >> 7)
+#define OMAP_I2C_REV_SCHEME_1_MINOR(rev) (rev & 0x1f)
+#define OMAP_I2C_SCHEME_0 0
+#define OMAP_I2C_SCHEME_1 1
+
static int __devinit
omap_i2c_probe(struct platform_device *pdev)
{
@@ -1064,6 +1075,8 @@ omap_i2c_probe(struct platform_device *pdev)
const struct of_device_id *match;
int irq;
int r;
+ u32 rev;
+ u16 minor, major;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1117,11 +1130,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev->reg_shift = (dev->flags >> OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) & 3;
- if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
- dev->regs = (u8 *)reg_map_ip_v2;
- else
- dev->regs = (u8 *)reg_map_ip_v1;
-
pm_runtime_enable(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
pm_runtime_use_autosuspend(dev->dev);
@@ -1130,7 +1138,31 @@ omap_i2c_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(r))
goto err_free_mem;
- dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
+ /*
+ * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
+ * On omap3 Offset 4 is IE Reg the bit [15:14] is XDR_IE which is 0
+ * at reset. Also since the omap_i2c_read_reg uses reg_map_ip_* a
+ * raw_readw is done.
+ */
+ rev = __raw_readw(dev->base + 0x04);
+
+ switch (OMAP_I2C_SCHEME(rev)) {
+ case OMAP_I2C_SCHEME_0:
+ dev->regs = (u8 *)reg_map_ip_v1;
+ dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
+ minor = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
+ major = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
+ break;
+ case OMAP_I2C_SCHEME_1:
+ /* FALLTHROUGH */
+ default:
+ dev->regs = (u8 *)reg_map_ip_v2;
+ rev = (rev << 16) |
+ omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
+ minor = OMAP_I2C_REV_SCHEME_1_MINOR(rev);
+ major = OMAP_I2C_REV_SCHEME_1_MAJOR(rev);
+ dev->rev = rev;
+ }
dev->errata = 0;
@@ -1155,7 +1187,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev->fifo_size = (dev->fifo_size / 2);
- if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
+ if (dev->rev < OMAP_I2C_REV_ON_3630)
dev->b_hw = 1; /* Enable hardware fixes */
/* calculate wakeup latency constraint for MPU */
@@ -1198,7 +1230,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr,
- dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed);
+ dev->dtrev, major, minor, dev->speed);
of_i2c_register_devices(adap);
@@ -1264,6 +1296,9 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ if (!_dev->regs)
+ return 0;
+
if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 2/7] i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352025873-27492-1-git-send-email-shubhrajyoti@ti.com>
The errata i207 is enabled for 2430 and 3xxx. Use the revision check
to enable the erratum instead.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 72fce6d..e009985 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1166,7 +1166,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev->errata = 0;
- if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207)
+ if (dev->rev >= OMAP_I2C_REV_ON_2430 &&
+ dev->rev < OMAP_I2C_REV_ON_4430_PLUS)
dev->errata |= I2C_OMAP_ERRATA_I207;
if (dev->rev <= OMAP_I2C_REV_ON_3430_3530)
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 3/7] i2c: omap: remove the dtrev
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352025873-27492-1-git-send-email-shubhrajyoti@ti.com>
The dtrev is used only for the comments. Remove the same and use
the scheme instead to know if it is version2.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e009985..b62cd9d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -191,7 +191,6 @@ struct omap_i2c_dev {
u32 latency; /* maximum MPU wkup latency */
struct pm_qos_request pm_qos_request;
u32 speed; /* Speed of bus in kHz */
- u32 dtrev; /* extra revision from DT */
u32 flags;
u16 cmd_err;
u8 *buf;
@@ -1076,7 +1075,7 @@ omap_i2c_probe(struct platform_device *pdev)
int irq;
int r;
u32 rev;
- u16 minor, major;
+ u16 minor, major, scheme;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1108,7 +1107,6 @@ omap_i2c_probe(struct platform_device *pdev)
u32 freq = 100000; /* default to 100000 Hz */
pdata = match->data;
- dev->dtrev = pdata->rev;
dev->flags = pdata->flags;
of_property_read_u32(node, "clock-frequency", &freq);
@@ -1117,7 +1115,6 @@ omap_i2c_probe(struct platform_device *pdev)
} else if (pdata != NULL) {
dev->speed = pdata->clkrate;
dev->flags = pdata->flags;
- dev->dtrev = pdata->rev;
}
dev->dev = &pdev->dev;
@@ -1146,7 +1143,8 @@ omap_i2c_probe(struct platform_device *pdev)
*/
rev = __raw_readw(dev->base + 0x04);
- switch (OMAP_I2C_SCHEME(rev)) {
+ scheme = OMAP_I2C_SCHEME(rev);
+ switch (scheme) {
case OMAP_I2C_SCHEME_0:
dev->regs = (u8 *)reg_map_ip_v1;
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
@@ -1231,7 +1229,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr,
- dev->dtrev, major, minor, dev->speed);
+ scheme, major, minor, dev->speed);
of_i2c_register_devices(adap);
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 4/7] ARM: i2c: omap: Remove the i207 errata flag
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352025873-27492-1-git-send-email-shubhrajyoti@ti.com>
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207]
uses the revision id instead of the flag. So the flag can be safely removed.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 3 +--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 +++------
drivers/i2c/busses/i2c-omap.c | 3 +--
include/linux/i2c-omap.h | 1 -
4 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c455e41..b79ccf6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -76,8 +76,7 @@ static struct omap_hwmod_class i2c_class = {
static struct omap_i2c_dev_attr i2c_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_BUS_SHIFT_2 |
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..943222c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -791,8 +791,7 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
@@ -818,8 +817,7 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
/* I2C2 */
static struct omap_i2c_dev_attr i2c2_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
@@ -845,8 +843,7 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
/* I2C3 */
static struct omap_i2c_dev_attr i2c3_dev_attr = {
.fifo_depth = 64, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b62cd9d..8a54efc 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1029,8 +1029,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index df804ba..5c88187 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -21,7 +21,6 @@
#define OMAP_I2C_FLAG_SIMPLE_CLOCK BIT(1)
#define OMAP_I2C_FLAG_16BIT_DATA_REG BIT(2)
#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE BIT(3)
-#define OMAP_I2C_FLAG_APPLY_ERRATA_I207 BIT(4)
#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK BIT(5)
#define OMAP_I2C_FLAG_FORCE_19200_INT_CLK BIT(6)
/* how the CPU address bus must be translated for I2C unit access */
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 5/7] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352025873-27492-1-git-send-email-shubhrajyoti@ti.com>
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 75 +++++++++++++++++++----------------------
1 files changed, 35 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8a54efc..a87c20a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
- u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -275,9 +274,34 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+
+ /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
+
+ /* SCL low and high time values */
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
+ if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
+
+ /* Take the I2C module out of reset: */
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev->iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
+}
+
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 12000000;
unsigned long timeout;
@@ -327,11 +351,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev->westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev->westate);
}
}
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -416,28 +437,17 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
}
- /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
- /* SCL low and high time values */
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
- /* Take the I2C module out of reset: */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
- /* Enable interrupts */
dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
- if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- dev->pscstate = psc;
- dev->scllstate = scll;
- dev->sclhstate = sclh;
- dev->bufstate = buf;
- }
+
+ dev->pscstate = psc;
+ dev->scllstate = scll;
+ dev->sclhstate = sclh;
+
+ __omap_i2c_init(dev);
+
return 0;
}
@@ -1297,23 +1307,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
if (!_dev->regs)
return 0;
- if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the IE state is 0 as it can
- * cause deadlock.
- */
- if (_dev->iestate)
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
+ if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
+ __omap_i2c_init(_dev);
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 6/7] i2c: omap: make reset a seperate function
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352025873-27492-1-git-send-email-shubhrajyoti@ti.com>
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
todo: reprodue the errors and optimise the reset if possible.
drivers/i2c/busses/i2c-omap.c | 25 ++++++++++++++++---------
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a87c20a..70d43b7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -299,15 +299,9 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 12000000;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev->rev >= OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -353,6 +347,17 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev->westate = OMAP_I2C_WE_ALL;
}
}
+ return 0;
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 12000000;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -592,7 +597,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
dev->buf_len = 0;
if (timeout == 0) {
dev_err(dev->dev, "controller timed out\n");
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
return -ETIMEDOUT;
}
@@ -602,7 +608,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
/* We have an error */
if (dev->cmd_err & (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
return -EIO;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 7/7] i2c: omap: Restore i2c context always
From: Shubhrajyoti D @ 2012-11-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352025873-27492-1-git-send-email-shubhrajyoti@ti.com>
Currently the restore is done based on the flag
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE.
This helps the following
- The driver is always capable of restoring regardless
of the off mode support being there or not.
- While testing omap2430 it is found that in case of certain
error paths (timeout) a reset is done. However the restore
never happens as it is dependent on the POSTIDLE flag.
The other option would be to call a restore in the reset
case. As there are only a few registers to be restored
the penalty in the idle case should not be much.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
Todo: the flag could be deleted if the patch is accepted.
drivers/i2c/busses/i2c-omap.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 70d43b7..f66c5ab 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1314,8 +1314,7 @@ static int omap_i2c_runtime_resume(struct device *dev)
if (!_dev->regs)
return 0;
- if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
- __omap_i2c_init(_dev);
+ __omap_i2c_init(_dev);
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/9] ARM: at91: Remove unused struct at91sam9g45_isi_device and its resources
From: Lee Jones @ 2012-11-04 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121104101502.GI19021@game.jcrosoft.org>
On Sun, 04 Nov 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 23:02 Sat 03 Nov , Lee Jones wrote:
> > This the at91sam9g45_isi_device structure and its associated resources
> > were added in 2008 and have been unused ever since. Let's remove them.
> next time you need to Cc the matinaers
I did:
$ git show <sha1> | scripts/get_maintainer.pl
Russell King <linux@arm.linux.org.uk> (maintainer:ARM PORT)
linux-arm-kernel at lists.infradead.org (moderated list:ARM SUB-ARCHITECT...)
linux-kernel at vger.kernel.org (open list)
> NACK
Any particular reason?
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > arch/arm/mach-at91/at91sam9263_devices.c | 20 --------------------
> > 1 file changed, 20 deletions(-)
> >
> > diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> > index cb85da2..0562a9d 100644
> > --- a/arch/arm/mach-at91/at91sam9263_devices.c
> > +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> > @@ -901,26 +901,6 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
> >
> > #if defined(CONFIG_VIDEO_AT91_ISI) || defined(CONFIG_VIDEO_AT91_ISI_MODULE)
> >
> > -struct resource isi_resources[] = {
> > - [0] = {
> > - .start = AT91SAM9263_BASE_ISI,
> > - .end = AT91SAM9263_BASE_ISI + SZ_16K - 1,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - [1] = {
> > - .start = NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
> > - .end = NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
> > - .flags = IORESOURCE_IRQ,
> > - },
> > -};
> > -
> > -static struct platform_device at91sam9263_isi_device = {
> > - .name = "at91_isi",
> > - .id = -1,
> > - .resource = isi_resources,
> > - .num_resources = ARRAY_SIZE(isi_resources),
> > -};
> > -
> > void __init at91_add_device_isi(struct isi_platform_data *data,
> > bool use_pck_as_mck)
> > {
> > --
> > 1.7.9.5
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Possible regression in 3.7-rc3 on Marvell Kirkwood
From: Josh Coombs @ 2012-11-04 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121104091146.GF6832@lunn.ch>
Will do, I'm half curious now if I managed to pull down a copy from
git mid-commit or something, as I can't for the life of me make it
flake out the way it was prior and I see there has been updates to
3.7-rc3 since it was released. (I always thought once cut, no more
commits went to that branch.) Oh well, at least my build farm got a
good workout.
Josh C
On Sun, Nov 4, 2012 at 4:11 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sat, Nov 03, 2012 at 09:39:55PM -0400, Josh Coombs wrote:
>> As of now I can't reproduce, so I can only assume it was something
>> with my config. Once I nail down exactly what triggers the behavior
>> I'll post up. For now, ignore my suggestion that there is a
>> regression.
>
> O.K.
>
> I also tried reproducing it. On my QNAP Kirkwood I made a fresh
> checkout of the kernel and built it. No problems.
>
> If you do see it again, please let us know.
>
> Thanks
> Andrew
^ permalink raw reply
* [PATCH v3 10/11] ARM: davinci - migrate to common clock
From: Sekhar Nori @ 2012-11-04 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-11-git-send-email-m-karicheri2@ti.com>
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
> Currently migrate only DM644x as this is being reviewed. Once all
> platforms are migrated, the Makefile will be cleaned up to remove
> obsoleted files clock.o and psc.o
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/mach-davinci/Kconfig | 2 ++
> arch/arm/mach-davinci/Makefile | 11 ++++++++++-
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c5f9ae5..4611987 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -967,6 +967,7 @@ config ARCH_DAVINCI
> select ARCH_REQUIRE_GPIOLIB
> select ZONE_DMA
> select HAVE_IDE
> + select COMMON_CLK
> select CLKDEV_LOOKUP
> select GENERIC_ALLOCATOR
> select GENERIC_IRQ_CHIP
This list has to be sorted. Russell has a patch which fixed this all
across arch/arm/* which got merged for v3.7. This patch does not apply
to v3.7-rc3 anymore due to the same reason.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH net-next 2/2] cpsw: fix leaking IO mappings
From: Cyril Chemparathy @ 2012-11-04 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1c915a7d0301355342358db8f84560417609a61c.1351930782.git.richardcochran@gmail.com>
On 11/03/2012 09:25 AM, Richard Cochran wrote:
> The CPSW driver remaps two different IO regions, but fails to unmap them
> both. This patch fixes the issue by calling iounmap in the appropriate
> places.
Any thoughts on using devres helpers to keep the bail out path simpler?
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> ---
> drivers/net/ethernet/ti/cpsw.c | 17 ++++++++---------
> 1 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 6215246..7654a62 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -1252,14 +1252,12 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
> ret = -ENOENT;
> goto clean_clk_ret;
> }
> -
> if (!request_mem_region(priv->cpsw_res->start,
> resource_size(priv->cpsw_res), ndev->name)) {
> dev_err(priv->dev, "failed request i/o region\n");
> ret = -ENXIO;
> goto clean_clk_ret;
> }
> -
> regs = ioremap(priv->cpsw_res->start, resource_size(priv->cpsw_res));
> if (!regs) {
> dev_err(priv->dev, "unable to map i/o region\n");
> @@ -1274,16 +1272,14 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
> if (!priv->cpsw_wr_res) {
> dev_err(priv->dev, "error getting i/o resource\n");
> ret = -ENOENT;
> - goto clean_clk_ret;
> + goto clean_iomap_ret;
> }
> -
> if (!request_mem_region(priv->cpsw_wr_res->start,
> resource_size(priv->cpsw_wr_res), ndev->name)) {
> dev_err(priv->dev, "failed request i/o region\n");
> ret = -ENXIO;
> - goto clean_clk_ret;
> + goto clean_iomap_ret;
> }
> -
> regs = ioremap(priv->cpsw_wr_res->start,
> resource_size(priv->cpsw_wr_res));
> if (!regs) {
> @@ -1326,7 +1322,7 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
> if (!priv->dma) {
> dev_err(priv->dev, "error initializing dma\n");
> ret = -ENOMEM;
> - goto clean_iomap_ret;
> + goto clean_wr_iomap_ret;
> }
>
> priv->txch = cpdma_chan_create(priv->dma, tx_chan_num(0),
> @@ -1407,11 +1403,13 @@ clean_dma_ret:
> cpdma_chan_destroy(priv->txch);
> cpdma_chan_destroy(priv->rxch);
> cpdma_ctlr_destroy(priv->dma);
> -clean_iomap_ret:
> - iounmap(priv->regs);
> +clean_wr_iomap_ret:
> + iounmap(priv->wr_regs);
> clean_cpsw_wr_iores_ret:
> release_mem_region(priv->cpsw_wr_res->start,
> resource_size(priv->cpsw_wr_res));
> +clean_iomap_ret:
> + iounmap(priv->regs);
> clean_cpsw_iores_ret:
> release_mem_region(priv->cpsw_res->start,
> resource_size(priv->cpsw_res));
> @@ -1442,6 +1440,7 @@ static int __devexit cpsw_remove(struct platform_device *pdev)
> iounmap(priv->regs);
> release_mem_region(priv->cpsw_res->start,
> resource_size(priv->cpsw_res));
> + iounmap(priv->wr_regs);
> release_mem_region(priv->cpsw_wr_res->start,
> resource_size(priv->cpsw_wr_res));
> pm_runtime_disable(&pdev->dev);
^ permalink raw reply
* [PATCH v3 06/11] clk: davinci - add build infrastructure for DaVinci clock drivers
From: Sekhar Nori @ 2012-11-04 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-7-git-send-email-m-karicheri2@ti.com>
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
> This updates clk Makefile and Kconfig to integrate the DaVinci specific
> clock drivers. Also add new Kconfig and Makefile for these drivers.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
As mentioned before, this should be folded into previous patches which
actually add the particular functionality.
> ---
> drivers/clk/Kconfig | 2 ++
> drivers/clk/Makefile | 1 +
> drivers/clk/davinci/Kconfig | 44 ++++++++++++++++++++++++++++++++++++++++++
> drivers/clk/davinci/Makefile | 5 +++++
> 4 files changed, 52 insertions(+)
> create mode 100644 drivers/clk/davinci/Kconfig
> create mode 100644 drivers/clk/davinci/Makefile
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 7f0b5ca..1ad2ab0 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -33,6 +33,8 @@ config COMMON_CLK_DEBUG
> clk_flags, clk_prepare_count, clk_enable_count &
> clk_notifier_count.
>
> +source "drivers/clk/davinci/Kconfig"
> +
> config COMMON_CLK_WM831X
> tristate "Clock driver for WM831x/2x PMICs"
> depends on MFD_WM831X
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 5869ea3..b127b6f 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
> obj-$(CONFIG_PLAT_SPEAR) += spear/
> obj-$(CONFIG_ARCH_U300) += clk-u300.o
> obj-$(CONFIG_ARCH_INTEGRATOR) += versatile/
> +obj-$(CONFIG_DAVINCI_CLKS) += davinci/
>
> # Chip specific
> obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
> diff --git a/drivers/clk/davinci/Kconfig b/drivers/clk/davinci/Kconfig
> new file mode 100644
> index 0000000..e53bbc3
> --- /dev/null
> +++ b/drivers/clk/davinci/Kconfig
> @@ -0,0 +1,44 @@
> +menu "TI DaVinci Clock drivers"
> + depends on COMMON_CLK
> +
> +config CLK_DAVINCI_PSC
> + bool "TI DaVici PSC clock driver"
> + default n
> + ---help---
> + Selects clock driver for DaVinci PSC clocks. This clock
> + hardware is found on TI DaVinci SoCs and other SoCs that
> + uses this hardware IP. This hardware has a local power
> + sleep control module that gate the clock to the IP.
> +
> +config CLK_DAVINCI_PLL
> + bool "DaVici main PLL clock"
> + ---help---
> + Selects clock driver for DaVinci main PLL. This clock
> + hardware is found on TI DaVinci SoCs. This typically has
> + a multiplier, a pre divider and post driver. Some of the
> + SoCs has the the dividers fixed, and others have it
> + programmable
> +
> +config CLK_DAVINCI_PLLDIV
> + bool "DaVici PLL divider clock"
> + ---help---
> + Selects clock driver for DaVinci PLL divider. This clock
> + hardware is found on TI DaVinci SoCs. This typically has
> + a divider and an enable bit to bypass or enable the
> + divider.
> +
> +config DAVINCI_CLKS
> + bool "TI DaVinci common clocks"
> + default n
> + select CLK_DAVINCI_PSC
> + select CLK_DAVINCI_PLLDIV
> + ---help---
> + Selects common clock drivers for DaVinci. These clocks
> + are re-used across many TI SoCs that are based on DaVinci and
> + Keystone (c6x) families. This config option is used to select
> + the common clock driver for DaVinci based SoCs. SoCs specific
> + Kconfig option needs to select the driver for clocks specific
> + to the SoC.
> +
> +endmenu
I wonder if all these configurations are really required. For complete
clock functionality you anyway require all this functionality so I
wonder why anyone would not select any of these. And to differentiate
between architecture changes, conditional build based on architecture
can be used:
obj-$(CONFIG_ARCH_DAVINCI) += clk-pll.o
obj-$(CONFIG_ARCH_KEYSTONE) += clk-pll-keystone.o
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v3 07/11] ARM: davinci - restructure header files for common clock migration
From: Sekhar Nori @ 2012-11-04 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-8-git-send-email-m-karicheri2@ti.com>
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
> pll.h is added to migrate some of the PLL controller defines for sleep.S.
> psc.h is modified to keep only PSC modules definitions needed by sleep.S
> after migrating to common clock. The definitions under
> ifdef CONFIG_COMMON_CLK will be removed in a subsequent patch.
> davinci_watchdog_reset prototype is moved to time.h as clock.h is
> being obsoleted. sleep.S and pm.c is modified to include the new header
> file replacements.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
> arch/arm/mach-davinci/devices.c | 2 ++
> arch/arm/mach-davinci/include/mach/pll.h | 46 +++++++++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/psc.h | 4 +++
> arch/arm/mach-davinci/include/mach/time.h | 4 ++-
> arch/arm/mach-davinci/pm.c | 4 +++
> arch/arm/mach-davinci/sleep.S | 4 +++
> 6 files changed, 63 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/mach-davinci/include/mach/pll.h
With this patch a _third_ copy of PLL definitions is created in kernel
sources. The existing PLL definitions in clock.h inside mach-davinci
should be moved to mach/pll.h and the pll.h you introduced inside
drivers/clk in 5/11 should be removed (this patch should appear before
5/11).
The biggest disadvantage of this approach is inclusion of mach/ includes
in drivers/clk. But duplicating code is definitely not the fix for this.
Anyway, mach/ includes are not uncommon in drivers/clk (they are all
probably suffering from the same issue).
$ grep -rl "include <mach/" drivers/clk/*
drivers/clk/clk-u300.c
drivers/clk/mmp/clk-pxa168.c
drivers/clk/mmp/clk-mmp2.c
drivers/clk/mmp/clk-pxa910.c
drivers/clk/mxs/clk-imx23.c
drivers/clk/mxs/clk-imx28.c
drivers/clk/spear/spear6xx_clock.c
drivers/clk/spear/spear3xx_clock.c
drivers/clk/spear/spear1340_clock.c
drivers/clk/spear/spear1310_clock.c
drivers/clk/ux500/clk-prcc.c
drivers/clk/versatile/clk-integrator.c
drivers/clk/versatile/clk-realview.c
pll.h can probably be moved to include/linux/clk/ to avoid this. Would
like to hear from Mike on this before going ahead.
Anyway, instead of just commenting, I though I will be more useful and
went ahead and made some of the changes I have been talking about. I
fixed the multiple PLL definitions issue, the build infrastructure issue
and the commit ordering too.
I pushed the patches I fixed to devel-common-clk branch of my git tree.
It is build tested using davinci_all_defconfig but its not runtime tested.
Can you start from here and provide me incremental changes on top of
this? That way we can collaborate to finish this faster.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 6/9] uprobes: flush cache after xol write
From: Ananth N Mavinakayanahalli @ 2012-11-04 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121103163301.GA9496@redhat.com>
On Sat, Nov 03, 2012 at 05:33:01PM +0100, Oleg Nesterov wrote:
> On 10/29, Ananth N Mavinakayanahalli wrote:
> >
> > On Fri, Oct 26, 2012 at 06:39:51PM +0200, Oleg Nesterov wrote:
> > > >
> > > > > OTOH, I do not understand this stuff, everything is nop on x86. And
> > > > > when I look into Documentation/cachetlb.txt I am starting to think
> > > > > that may be this needs flush_icache_user_range instead?
> > > > >
> > > > > Rabin, Ananth could you clarify this?
> > > >
> > > > Yes. We need flush_icache_user_range(). Though for x86 its always been a
> > > > nop, one never knows if there is some Power4 or older machine out there
> > > > that is still being used. We are fine for Power5 and later.
> > >
> > > This is bad...
> > >
> > > flush_icache_user needs vma. perhaps just to check VM_EXEC...
> > >
> > > So let me repeat to be sure I really understand, do you confirm that
> > > _in general_ flush_dcache_page() is not enough?
> >
> > flush_dcache_page() on powerpc already checks for
> > CPU_FTR_COHERENT_ICACHE. So, yes, that is enough.
>
> Thanks Ananth.
>
> Still it is not clear to me if flush_dcache_page() would be always right
> if we add the new port.
>
> OK. So I assume we need the fix and I am going to apply the patch below.
>
> Ananth, Rabin, will you ack it (including the comment I affed) ?
>
> Oleg.
>
> ------------------------------------------------------------------------------
> [PATCH] uprobes: flush cache after xol write
>
> From: Rabin Vincent <rabin@rab.in>
>
> Flush the cache so that the instructions written to the XOL area are
> visible.
>
> Signed-off-by: Rabin Vincent <rabin@rab.in>
Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>
> --- x/kernel/events/uprobes.c
> +++ x/kernel/events/uprobes.c
> @@ -1199,6 +1199,11 @@ static unsigned long xol_get_insn_slot(s
> vaddr = kmap_atomic(area->page);
> memcpy(vaddr + offset, uprobe->arch.insn, MAX_UINSN_BYTES);
> kunmap_atomic(vaddr);
> + /*
> + * We probably need flush_icache_user_range() but it needs vma.
> + * This should work on supported architectures too.
> + */
> + flush_dcache_page(area->page);
>
> return current->utask->xol_vaddr;
> }
^ permalink raw reply
* [PATCH net-next 2/2] cpsw: fix leaking IO mappings
From: Richard Cochran @ 2012-11-04 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50966C6E.1000507@ti.com>
On Sun, Nov 04, 2012 at 02:23:58PM +0100, Cyril Chemparathy wrote:
> On 11/03/2012 09:25 AM, Richard Cochran wrote:
> >The CPSW driver remaps two different IO regions, but fails to unmap them
> >both. This patch fixes the issue by calling iounmap in the appropriate
> >places.
>
> Any thoughts on using devres helpers to keep the bail out path simpler?
I wasn't aware of devres before, but I just read through the doc. It
looks interesting, and if I were writting a new driver, then I might
use it.
But for this driver, it really isn't very complex. It only looks that
way, but I think this just accidental. I guess that the code was
adapted from the davinci emac driver.
Thanks,
Richard
^ permalink raw reply
* [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
From: Bedia, Vaibhav @ 2012-11-04 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50953DA4.10008@ti.com>
Hi Santosh,
On Sat, Nov 03, 2012 at 21:22:04, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > From: Vaibhav Hiremath <hvaibhav@ti.com>
> >
> > The current OMAP timer code registers two timers -
> > one as clocksource and one as clockevent.
> Actually OMAP also uses only one timer. The clocksource
> is taken care by 32K syntimer till OMAP4 and by realtime
> counter on OMAP5. There is a clocksource registration of
> timer is available but that is not being used in systems.
>
Yes, I guess the changelog should mention that AM33xx does not
have the 32k synctimer. I'll also add in the OMAP details that
you pointed out so that all the details get captured.
> > AM33XX has only one usable timer in the WKUP domain
> > so one of the timers needs suspend-resume support
> > to restore the configuration to pre-suspend state.
> >
> > commit adc78e6 (timekeeping: Add suspend and resume
> > of clock event devices) introduced .suspend and .resume
> > callbacks for clock event devices. Leverages these
> > callbacks to have AM33XX clockevent timer which is
> > in not in WKUP domain to behave properly across system
> > suspend.
> >
> So you use WKUP domain timer for clocksource and PER
> domain one for clock-event ?
Yes, that's correct.
>
>
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> > ---
> > arch/arm/mach-omap2/timer.c | 31 +++++++++++++++++++++++++++++++
> > 1 files changed, 31 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> > index 6584ee0..e8781fd 100644
> > --- a/arch/arm/mach-omap2/timer.c
> > +++ b/arch/arm/mach-omap2/timer.c
> > @@ -135,6 +135,35 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
> > }
> > }
> >
> > +static void omap_clkevt_suspend(struct clock_event_device *unused)
> > +{
> > + char name[10];
> > + struct omap_hwmod *oh;
> > +
> > + sprintf(name, "timer%d", 2);
> > + oh = omap_hwmod_lookup(name);
> > + if (!oh)
> > + return;
>
> You can move all the look up stuff in init code and then
> suspend resume hooks will be cleaner.
Will do. Kevin also pointed this out.
> > +
> > + omap_hwmod_idle(oh);
> > +}
> > +
> > +static void omap_clkevt_resume(struct clock_event_device *unused)
> > +{
> > + char name[10];
> > + struct omap_hwmod *oh;
> > +
> > + sprintf(name, "timer%d", 2);
> > + oh = omap_hwmod_lookup(name);
> > + if (!oh)
> > + return;
> > +
> > + omap_hwmod_enable(oh);
> > + __omap_dm_timer_load_start(&clkev,
> > + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
> > + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
> > +}
> > +
> OK. So since your clk_event stops when PER idles, how do you plan
> to support the SOC idle. For CPUIDLE path, you need your clock-event
> to wakeup the system based on next timer expiry. So you need your
> clock event to be active. Indirectly, you can't let PER idle which
> leads npo CORE idle->SOC idle.
>
> How do you plan to address this ? Os is SOC idle is not suppose
> to be added for AMXXX ?
>
We can't really have SOC idle on AM33xx or at least that's what I think.
The deepest that we should be able to support is MPU off with external
memory in self-refresh mode. I mentioned the reasons for that in the
reply to Kevin [1]. If there's any another approach that we could take
that would be great to know.
Regards,
Vaibhav
[1] http://marc.info/?l=linux-arm-kernel&m=135195053104053&w=2
^ permalink raw reply
* [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50953E26.40906@ti.com>
On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> > ---
> > arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++
> > 1 files changed, 11 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index bb31bff..e2cbf24 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -210,5 +210,16 @@
> > interrupt-parent = <&intc>;
> > interrupts = <91>;
> > };
> > +
> > + ocmcram: ocmcram at 40300000 {
> > + compatible = "ti,ocmcram";
> > + ti,hwmods = "ocmcram";
> > + ti,no_idle_on_suspend;
> > + };
> Whats the intention behind adding OCMRAM ?
> Sorry if I missed any comments from the cover letter ?
>
We need a mechanism to ensure that the clock to OCMC is kept running
during boot and that it doesn't get disabled as part of the suspend
sequence. Since the hwmod data for OCMC is already present and we have
the no_idle_on_suspend flag for hwmod entries we get the desired behavior.
This could also have been done via the clock tree but looks like we
want to avoid adding leaf nodes in the clock data, hence the hwmod +
DT approach.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 01/15] ARM: OMAP2+: mailbox: Add an API for flushing the FIFO
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50954063.5010901@ti.com>
On Sat, Nov 03, 2012 at 21:33:47, Shilimkar, Santosh wrote:
[...]
> > +static int omap2_mbox_fifo_needs_flush(struct omap_mbox *mbox)
> > +{
> > + struct omap_mbox2_fifo *fifo =
> > + &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
> type casting is generally avoided in linux code.
I was just trying to be consistent with the rest of the mailbox FIFO
related code :)
Will see how to get rid of these globally in the next version.
> > + return mbox_read_reg(fifo->msg_stat);
> > +}
> > +
> > +static mbox_msg_t omap2_mbox_fifo_readback(struct omap_mbox *mbox)
> > +{
> > + struct omap_mbox2_fifo *fifo =
> > + &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
> > + return (mbox_msg_t) mbox_read_reg(fifo->msg);
> same here.
Ok.
> > +}
> > +
> > /* Mailbox IRQ handle functions */
> > static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
> > omap_mbox_type_t irq)
> > @@ -205,19 +219,21 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
> > }
> >
> > static struct omap_mbox_ops omap2_mbox_ops = {
> > - .type = OMAP_MBOX_TYPE2,
> > - .startup = omap2_mbox_startup,
> > - .shutdown = omap2_mbox_shutdown,
> > - .fifo_read = omap2_mbox_fifo_read,
> > - .fifo_write = omap2_mbox_fifo_write,
> > - .fifo_empty = omap2_mbox_fifo_empty,
> > - .fifo_full = omap2_mbox_fifo_full,
> > - .enable_irq = omap2_mbox_enable_irq,
> > - .disable_irq = omap2_mbox_disable_irq,
> > - .ack_irq = omap2_mbox_ack_irq,
> > - .is_irq = omap2_mbox_is_irq,
> > - .save_ctx = omap2_mbox_save_ctx,
> > - .restore_ctx = omap2_mbox_restore_ctx,
> > + .type = OMAP_MBOX_TYPE2,
> > + .startup = omap2_mbox_startup,
> > + .shutdown = omap2_mbox_shutdown,
> > + .fifo_read = omap2_mbox_fifo_read,
> > + .fifo_write = omap2_mbox_fifo_write,
> > + .fifo_empty = omap2_mbox_fifo_empty,
> > + .fifo_full = omap2_mbox_fifo_full,
> > + .fifo_needs_flush = omap2_mbox_fifo_needs_flush,
> > + .fifo_readback = omap2_mbox_fifo_readback,
> > + .enable_irq = omap2_mbox_enable_irq,
> > + .disable_irq = omap2_mbox_disable_irq,
> > + .ack_irq = omap2_mbox_ack_irq,
> > + .is_irq = omap2_mbox_is_irq,
> > + .save_ctx = omap2_mbox_save_ctx,
> > + .restore_ctx = omap2_mbox_restore_ctx,
> You should do the indentation fix in another patch.
>
Ok will split it up.
> > };
> >
> > /*
> > diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-omap/include/plat/mailbox.h
> > index cc3921e..e136529 100644
> > --- a/arch/arm/plat-omap/include/plat/mailbox.h
> > +++ b/arch/arm/plat-omap/include/plat/mailbox.h
> > @@ -29,6 +29,8 @@ struct omap_mbox_ops {
> > void (*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
> > int (*fifo_empty)(struct omap_mbox *mbox);
> > int (*fifo_full)(struct omap_mbox *mbox);
> > + int (*fifo_needs_flush)(struct omap_mbox *mbox);
> > + mbox_msg_t (*fifo_readback)(struct omap_mbox *mbox);
> Do you think passing the msg structure as an argument and letting the
> function populate it will be better instead of returning the msg
> structure ? No strong opinion since from read_foo() point of view
> what you have done might be right thing. In either case, please
> get rid of typecasting.
>
Passing the msg structure looks fine. Will do that in the next version.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 02/15] ARM: OMAP2+: mailbox: Add support for AM33XX
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509541FD.4040307@ti.com>
On Sat, Nov 03, 2012 at 21:40:37, Shilimkar, Santosh wrote:
[...]
> > +#if defined(CONFIG_SOC_AM33XX)
> > + else if (soc_is_am33xx()) {
> > + list = am33xx_mboxes;
> > +
> > + list[0]->irq = platform_get_irq(pdev, 0);
> > + }
> > +#endif
> #ifdef in middle of the function looks really ugly. But I can't complain
> just for your patch because looks like rest of the mailbox code is
> flooded with #ifdeffery.
>
> Mailbox needs cleanup. and probably can be moved out of
> arch/arm/*omap*/ to some driver directory.
>
Tony pointed out that the movement to drivers directory
is underway [1]. Getting rid of the #ifdeffery could be next.
Regards,
Vaibhav
[1] http://www.spinics.net/lists/linux-omap/msg80702.html
^ permalink raw reply
* [PATCH 05/15] ARM: OMAP2+: AM33XX: Update WKUP_M3 hwmod entry for reset status
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50954321.8010908@ti.com>
On Sat, Nov 03, 2012 at 21:45:29, Shilimkar, Santosh wrote:
[...]
> >
> You are adding reset bit in this patch but using it in 4/15. Probably
> you can re-order it to keep git bisect happy.
>
Ok. Will reorder.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 06/15] ARM: OMAP2+: hwmod: Enable OCMCRAM registration in AM33XX
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5095436E.6030206@ti.com>
On Sat, Nov 03, 2012 at 21:46:46, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > The hwmod data for OCMCRAM in AM33XX was commented out.
> > This data is needed by the power management code, hence
> > uncomment the same and register the OCP interface for it.
> >
> Why this data is needed by PM code ?
>
It's needed to ensure that the clock to ocmcram is running
during boot and doesn't get disabled as part of the suspend
sequence. Will reword the changelog.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509543E8.60209@ti.com>
On Sat, Nov 03, 2012 at 21:48:48, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT
> > instead of ADDR_TYPE_RT to ensure the omap hwmod code
> > maps the memory space at init and writes to the SYSCONFIG
> > registers.
> >
> > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> > ---
> Sorry again similar question.
>
> Why CPGMAC0 should be mapped and sysconfig updated early ?
>
Hmm I need to revisit this one. CPGMAC0 was not going to standby
without this. Maybe something else is wrong in the hwmod data and
needs fixing.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 09/15] ARM: OMAP: AM33XX: Remove unnecessary include and use __ASSEMBLER__ macros
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50954683.4050302@ti.com>
On Sat, Nov 03, 2012 at 21:59:55, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > Get rid of some unnecessary header file inclusions
> > and also use __ASSEMBLER__ macros to allow the
> > various register offsets from PM assembly code
> > which be added in a subsequent patch.
> >
> > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>
> Ideally you should split header clean-up and assembler
> fix in seperate patches.
>
Ok. Will do.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
From: Bedia, Vaibhav @ 2012-11-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509546F2.8080505@ti.com>
On Sat, Nov 03, 2012 at 22:01:46, Shilimkar, Santosh wrote:
> >
> As mentioned on other patch comment, I think this might break your
> SOC idle.
>
Unfortunately we don't have SOC idle.
Regards,
Vaibhav
^ 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