Re: [PATCHv2 4/7] ARM: i2c: omap: Remove the i207 errata flag
On Sun, Nov 04, 2012 at 04:14:30PM +0530, Shubhrajyoti D wrote:
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 shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@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_POSTIDLEBIT(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_CLKBIT(6)
/* how the CPU address bus must be translated for I2C unit access */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2 5/7] i2c: omap: re-factor omap_i2c_init function
On Sun, Nov 04, 2012 at 04:14:31PM +0530, Shubhrajyoti D wrote:
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 shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@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 = 1200;
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
Re: [PATCHv2 6/7] i2c: omap: make reset a seperate function
Hi,
On Sun, Nov 04, 2012 at 04:14:32PM +0530, Shubhrajyoti D wrote:
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 shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@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 = 1200;
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 = 1200;
+ 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2 7/7] i2c: omap: Restore i2c context always
Hi, On Sun, Nov 04, 2012 at 04:14:33PM +0530, Shubhrajyoti D wrote: 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 shubhrajy...@ti.com Looks ok to me, one less unnecessary flag. Reviewed-by: Felipe Balbi ba...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
On 2012-11-02 20:54, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [121102 01:56]: On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote: On 2012-11-02 08:38, Santosh Shilimkar wrote: Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place. Tomi, Can we not get rid of the above memory reservation ? Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later. Hmm actually, is it safe to remove for omap1, or should we still keep it around for omap1? Why wouldn't it be safe? Do you mean that CMA doesn't work on omap1, or...? I'm no expert on CMA, but as far as I can see with it's ARM generic stuff. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v2] i2c: omap: ensure writes to dev-buf_len are ordered
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the fifo size, dev-buf_len was reset
to zero before we had an oportunity to handle XDR
Interrupt. Because dev-buf_len was zero, we entered
omap_i2c_transmit_data() to transfer zero bytes,
which would mean we would just silently exit
omap_i2c_transmit_data() without actually writing
anything to DATA register. That would cause XDR
IRQ to trigger forever and we would never transfer
the remaining bytes.
After adding the memory barrier, we also drop resetting
dev-buf_len to zero in omap_i2c_xfer_msg() because
both omap_i2c_transmit_data() and omap_i2c_receive_data()
will act until dev-buf_len reaches zero, rendering the
other write in omap_i2c_xfer_msg() redundant.
This patch has been tested with pandaboard for a few
iterations of the script mentioned above.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Changes since v1:
- use barrier() instead of wmb()
Note: this version was compile-tested only
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..ba03bec 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
dev-buf = msg-buf;
dev-buf_len = msg-len;
+ barrier();
omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev-buf_len);
@@ -579,7 +580,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
*/
timeout = wait_for_completion_timeout(dev-cmd_complete,
OMAP_I2C_TIMEOUT);
- dev-buf_len = 0;
if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
On Sat, Nov 03, 2012 at 02:32:59PM -0500, Joel A Fernandes wrote: beaglebone_defconfig: Add dummy regulator to init tlv320aic3x https://github.com/joelagnel/linux-kernel/commit/db5672dfe548d82625cf40ed688d05ba7cee5c93 This should never be done in production, you should ensure that the appropriate supplies are provided by the board file or device tree. signature.asc Description: Digital signature
Re: [PATCH v2 0/7] I2C patches for v3.8 merge window
Hi, On Thu, Oct 25, 2012 at 03:25:08PM +0300, Felipe Balbi wrote: Hi, here's another series for OMAP I2C driver. There are a few cleanups and one very nice new feature: we can now report how many bytes we transferred until NACK. Note that the implemementation for OMAP-I2C turned out to be a little more complex then I expected, mainly because of the way I2C_CNT register behaves and because of the very buggy register usage on that driver. I have boot tested all patches on beagle xM (3630) and pandaboard rev A3 (4430), will send boot-logs if anyone wants to see. All patches are available at [1] if anyone wants an easy way to test the patches. Wolfram, patches 1-5 are ok to apply, we just need to rework patches 6 and 7 so drivers can report how many bytes managed to be transferred. None of these patches cause any known regressions. let me know if you want me to resend only the 5 patches which should be applied. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 0/7] i2c: omap: updates
On Monday 05 November 2012 01:16 PM, Felipe Balbi wrote: include/linux/i2c-omap.h |1 - 4 files changed, 104 insertions(+), 75 deletions(-) since I have reviewed your previous version, it would be nice to Cc me so I don't loose your series ;-) OK will do that. thanks :-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/7] i2c: omap: Fix the revision register read
On Monday 05 November 2012 01:20 PM, Felipe Balbi wrote:
Hi,
On Sun, Nov 04, 2012 at 04:14:27PM +0530, Shubhrajyoti D wrote:
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 shubhrajy...@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_20x20
/* I2C controller revisions present on specific hardware */
-#define OMAP_I2C_REV_ON_24300x36
-#define OMAP_I2C_REV_ON_3430_3530 0x3C
-#define OMAP_I2C_REV_ON_3630_4430 0x40
+#define OMAP_I2C_REV_ON_24300x0036
+#define OMAP_I2C_REV_ON_3430_3530 0x003C
+#define OMAP_I2C_REV_ON_36300x0040
+#define OMAP_I2C_REV_ON_4430_PLUS 0x5042
/* 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;
unsignedb_hw:1; /* bad h/w fixes */
unsignedreceiver: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
comment is wrong. You talk about 2 bits and document only one of them.
Also, this is valid for all OMAPs until OMAP3, comment should probably
read: On OMAP1/2/3 offset 0x04 is.
will fix the comment.
+ * 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;
drop the 0xff. Top byte is supposed to be zero
yes.
and if it's
Re: [PATCHv2 3/7] i2c: omap: remove the dtrev
On Monday 05 November 2012 01:23 PM, Felipe Balbi wrote: Hi, On Sun, Nov 04, 2012 at 04:14:29PM +0530, Shubhrajyoti D wrote: 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 shubhrajy...@ti.com I would drop dtrev completely and not use scheme to emulate it. However for ver2 ie omap4plus and previous versions the register map is different. So the scheme may still be required. dtrev is wrong and unnecessary; it was only created due to the wrong assumption that HW revision register was wrong. Looks like that assumption was made based on the driver which is clearly wrong wrt revision detection. Also, when dropping dtrev, also drop it from platform_data and omap_hwmod database (could be done on a separate patch). OK would do that. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] OMAPDSS: HDMI: Create platform device for audio support
On 2012-11-03 02:31, Ricardo Neri wrote:
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation of the accessory
devices. Such devices are then used by domain-specific drivers; audio in
this case.
Also, this is in line with the DT implementation of HDMI, in which we will
have a single node to describe this feature of the OMAP SoC.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 62
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 4adf830..d6ce4c6 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -60,6 +60,9 @@
static struct {
struct mutex lock;
struct platform_device *pdev;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ struct platform_device *audio_pdev;
+#endif
struct hdmi_ip_data ip_data;
@@ -766,6 +769,54 @@ static void hdmi_put_clocks(void)
}
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+static int hdmi_probe_audio(struct platform_device *pdev)
+{
+ struct resource *res;
+ u32 port_offset, port_size;
+ struct resource aud_res[2] = {
+ DEFINE_RES_MEM(-1, -1),
+ DEFINE_RES_DMA(-1),
+ };
+
+ hdmi.audio_pdev = ERR_PTR(-EINVAL);
I don't like this. I think ERR_PTR stuff should be used only for return
values, not when storing pointers. I think it's much more natural and
less error prone to do if (hdmi.audio_pdev == NULL) than if
(IS_ERR(hdmi.audio_pdev)).
So store the return value from platform_dev_register first to a local
variable, check IS_ERR for that, and only then store it to hdmi.audio_pdev.
+ res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ DSSERR(can't get IORESOURCE_MEM HDMI\n);
+ return -EINVAL;
+ }
+
+ /*
+ * Pass DMA audio port to audio drivers.
+ * Audio drivers should not ioremap it.
+ */
+ hdmi.ip_data.ops-audio_get_dma_port(port_offset, port_size);
+
+ aud_res[0].start = res-start + port_offset;
+ aud_res[0].end = aud_res[0].start + port_size - 1;
+
+ res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0);
+ if (!res) {
+ DSSERR(can't get IORESOURCE_DMA HDMI\n);
+ return -EINVAL;
+ }
+
+ /* Pass the audio DMA request resource to audio drivers. */
+ aud_res[1].start = res-start;
+
+ /* create platform device for HDMI audio driver */
+ hdmi.audio_pdev = platform_device_register_simple(
+ omap_hdmi_audio,
+ -1, aud_res,
+ARRAY_SIZE(aud_res));
Not a problem for the time being, but the above prevents us from having
two HDMI outputs. Perhaps you could use hdmi pdev's ID instead of -1 above?
Otherwise I think the series is ok.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
On 2012-11-02 13:56, Archit Taneja wrote: On Friday 02 November 2012 04:58 PM, Tomi Valkeinen wrote: On 2012-11-02 13:09, Archit Taneja wrote: On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote: On 2012-11-02 12:44, Archit Taneja wrote: Hmm, that makes sense. Anyway, I don't think it's really bad if we refer to dssdev-channel for now. It is, because dssdev-channel doesn't exist with DT. With DT we either need to figure out the channel in omapdss at runtime, or add a property to the DT data telling the channel. And adding such a property is not correct, as DT should be about describing the HW. Ok. I don't totally agree with your idea of figuring out the manager in panel the panel's probe. If it's done in the panel driver's probe itself, then by this point of time we have already set mgr-output-device links. If omapdss only does this stuff, then Hmm, I'm not sure I understand what's your point above? If figuring out the mgr is done in panel's probe, the mgr-output link is not yet made before that time. My point is that we are trying to find a manager at panel's probe itself. It think that's what we do now. But one of your recent patch moves that to omapfb. Ah. Yes, that's true. omapfb/omapdrm have just the job of connecting the overlays to the manager. Do you think that's okay? Yes, that's how I think it should be. I don't see why omapfb/omapdrm should care about which manager is being used for the output, it doesn't really matter as long there is one and it works. Then again, I don't have anything against omapfb/omapdrm choosing the manager, but I don't see how they would have any better idea of which manager to use than omapdss. But as doing the connections at probe time is a bit problematic, perhaps we should have a new step in this whole sequence. Something like connect or whatever, which would lock the required blocks in the whole pipeline, and acquire the required resources that couldn't be gotten at probe time. But even then, choosing the manager is not easy, as whoever chooses the manager needs to observe all the possible displays used at the same time... Right. I was wondering if omapfb/omapdrm could understand the 'all possible displays information' better compared to a panel's probe. Even omapdrm/omafb can't be perfect because we could insert a panel driver module at any time, and omapfb/omapdrm may miss that out. True, omapdrm/fb may have a better idea. It's still unclear though. Currently we have quite strict order in the sequence the modules need to be loaded, which is quite bad and causes issues. We should make things more dynamic, so that the initialization of the drivers could happen more freely. But that creates more problems: when booting up, omapfb starts. But omapfb can't know if all the panel drivers have already been loaded. omapfb may see that DVI is the default display, but what should it do if DVI doesn't have a driver yet? It could wait, but perhaps the driver for DVI will never even be loaded. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv2 1/7] i2c: omap: Fix the revision register read
Hi, On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote: @@ -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 */ looks like this was applicable to 4430 too, what happened ? No actually this can be deleted completely once the start - transaction - stop sequence recommendation is followed. yes, but we're not there just yet and this patch is changing the behavior of the driver in ways which don't belong to $SUBJECT. -- balbi signature.asc Description: Digital signature
RE: [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Sun, Nov 04, 2012 at 20:54:17, Bedia, Vaibhav wrote: 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.be...@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. Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. I'll make the changes in the next version. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/7] i2c: omap: remove the dtrev
Hi, On Mon, Nov 05, 2012 at 02:14:48PM +0530, Shubhrajyoti wrote: On Monday 05 November 2012 01:23 PM, Felipe Balbi wrote: Hi, On Sun, Nov 04, 2012 at 04:14:29PM +0530, Shubhrajyoti D wrote: 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 shubhrajy...@ti.com I would drop dtrev completely and not use scheme to emulate it. However for ver2 ie omap4plus and previous versions the register map is different. So the scheme may still be required. fair enough, but drop it from debugging messages. -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Paul, On Mon, Nov 5, 2012 at 4:15 AM, Paul Walmsley p...@pwsan.com wrote: Hi Jean, On Sat, 3 Nov 2012, Jean Pihet wrote: The setup is as identical as possible to yours: - U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58) from http://www.pwsan.com/tmp/3530es3beagle-MLO-u-boot-20121023.tar.bz2. Please note that the MLO image does not run on my board and so I had to use my known-to-work image. Interesting... The result is that I could reproduce the issue but it happens much more rarely on my side (only once vs quasi 100% on ~50 boot cycles). Hmm... The issue is triggered by running 'hwclock --systohc' while the system is heavily loaded (running depmod etc.). OK. More investigation on-going, so more to come! Great, keep us posted. I ran some intensive stress tests on the I2C and ... unfortunately I could not trigger the problem. It looks like the issue is caused by some transient situation where the CORE and/or I2C is in a low power state. Here are the tests that have been performed from the user space: - stress test the I2C IRQ handler by reading and writing the RTC, and checking the amount of IRQs for the I2C bus. In that case the CORE never goes in low power mode, - stress test the CORE low power and wake-up transition by adjusting the autosuspend delay (e.g. /sys/devices/platform/omap_i2c.1/power/autosuspend_delay_ms) and accessing the RTC after the CORE has gone in low power. Those tests have been run for hours (20 IRQs) and the I2C timeout issue could not be observed. The target low power mode is RET (not tried with OFF). The next step is to detect an error situation and have data logged about the state at that moment. What do you think? This brings an interesting discussion. As you indicated earlier, withtout CPU_IDLE enabled nothing except the autosuspend delay is preventing the power domains to go in low power mode. This could lead to situations where latency constraints are not respected. The easy and straight forward solution is to enable CPU_IDLE and use the PM QoS constraints. What do you think? Regards, Jean Will try to kick off those tests you requested within the next 24-48 hours. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/7] i2c: omap: remove the dtrev
On Monday 05 November 2012 02:35 PM, Felipe Balbi wrote: egister map is different. So the scheme may still be required. fair enough, but drop it from debugging messages. OK thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Support for AM33xx PWM Susbsytem
In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to PWM subsystem. All these submodules shares the resources (clock) has a clock gating register in PWM Subsystem. This patch series creates a parent PWM Subsystem driver to handle access synchronization of shared resources clock gating from PWM Subsystem configuration space. Also Device tree nodes populated to support parent child relation between PWMSS, ECAP EHRPWM submodules. In addition EHRPWM module requires explicit clock gating from control module is handled by patch #2 6. Patch #4 5 submitted is a second revision as suggested by Thierry for handling clock gating with a global function . This requires config space handling done independent from driver and is done at parent driver. So the parent-child relation adopted to handle 1. pm runtime synchronization 2. PWM subsystem common config space clock gating for PWM submodules. Patches supports - Driver support for parent child relation handled patch #1 - Optional EHRPWM tb clock in patch #2 - Parent child in HWMOD handled at patch #3 - Device tree binding support handled in patch #4-6 - DT node populated in patch #7-8. This patch series based on linux-next/20121102 and tested on AM335x-evm. It depends on [1] 1. https://lkml.org/lkml/2012/10/29/589 pwm: Device tree support for PWM polarity Philip, Avinash (8): PWMSS: Add PWM Subsystem driver for parent-child relationship ARM: am33xx: clk: Add optional clock for EHRPWM ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem pwm: pwm-tiecap: Add device-tree binding support for APWM driver pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver pwm: pwm-tiehrpwm: Adding TBCLK gating support. ARM: dts: AM33XX: Add PWMSS device tree nodes ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm .../devicetree/bindings/pwm/pwm-tiecap.txt | 22 + .../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 25 ++ Documentation/devicetree/bindings/pwm/tipwmss.txt | 30 ++ arch/arm/boot/dts/am335x-evm.dts | 21 + arch/arm/boot/dts/am33xx.dtsi | 90 + arch/arm/mach-omap2/clock33xx_data.c | 37 ++ arch/arm/mach-omap2/control.h |8 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 414 +--- drivers/pwm/Kconfig| 11 + drivers/pwm/Makefile |1 + drivers/pwm/pwm-tiecap.c | 36 ++- drivers/pwm/pwm-tiehrpwm.c | 53 +++- drivers/pwm/tipwmss.c | 136 +++ drivers/pwm/tipwmss.h |8 + 14 files changed, 754 insertions(+), 138 deletions(-) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt create mode 100644 Documentation/devicetree/bindings/pwm/tipwmss.txt create mode 100644 drivers/pwm/tipwmss.c create mode 100644 drivers/pwm/tipwmss.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP EHRPWM).
To handle resource sharing IP integration
1. Rework on parent child relation between PWMSS and
ECAP, EQEP EHRPWM child devices to support runtime PM.
2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional
clock gating from control module.
3. Add HWMOD entries for EQEP PWM submodule.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 ad8d43b... c419269... M
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 414 +++-
1 files changed, 278 insertions(+), 136 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..c419269 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -768,9 +768,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
},
};
-/*
- * 'epwmss' class: ecap0,1,2, ehrpwm0,1,2
- */
+/* pwmss */
static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
.rev_offs = 0x0,
.sysc_offs = 0x4,
@@ -786,18 +784,23 @@ static struct omap_hwmod_class am33xx_epwmss_hwmod_class
= {
.sysc = am33xx_epwmss_sysc,
};
-/* ehrpwm0 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
- { .name = int, .irq = 86 + OMAP_INTC_START, },
- { .name = tzint, .irq = 58 + OMAP_INTC_START, },
- { .irq = -1 },
+
+static struct omap_hwmod_class am33xx_ecap_hwmod_class = {
+ .name = ecap,
};
-static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
- .name = ehrpwm0,
+static struct omap_hwmod_class am33xx_eqep_hwmod_class = {
+ .name = eqep,
+};
+
+static struct omap_hwmod_class am33xx_ehrpwm_hwmod_class = {
+ .name = ehrpwm,
+};
+/* epwmss0 */
+static struct omap_hwmod am33xx_epwmss0_hwmod = {
+ .name = epwmss0,
.class = am33xx_epwmss_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .mpu_irqs = am33xx_ehrpwm0_irqs,
.main_clk = l4ls_gclk,
.prcm = {
.omap4 = {
@@ -807,63 +810,68 @@ static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
},
};
-/* ehrpwm1 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
- { .name = int, .irq = 87 + OMAP_INTC_START, },
- { .name = tzint, .irq = 59 + OMAP_INTC_START, },
+/* ecap0 */
+static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
+ { .irq = 31 + OMAP_INTC_START, },
{ .irq = -1 },
};
-static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
- .name = ehrpwm1,
- .class = am33xx_epwmss_hwmod_class,
+static struct omap_hwmod am33xx_ecap0_hwmod = {
+ .name = ecap0,
+ .class = am33xx_ecap_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .mpu_irqs = am33xx_ehrpwm1_irqs,
+ .mpu_irqs = am33xx_ecap0_irqs,
.main_clk = l4ls_gclk,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
};
-/* ehrpwm2 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
- { .name = int, .irq = 39 + OMAP_INTC_START, },
- { .name = tzint, .irq = 60 + OMAP_INTC_START, },
+/* eqep0 */
+static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
+ { .irq = 79 + OMAP_INTC_START, },
{ .irq = -1 },
};
-static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
- .name = ehrpwm2,
- .class = am33xx_epwmss_hwmod_class,
+static struct omap_hwmod am33xx_eqep0_hwmod = {
+ .name = eqep0,
+ .class = am33xx_eqep_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .mpu_irqs = am33xx_ehrpwm2_irqs,
+ .mpu_irqs = am33xx_eqep0_irqs,
.main_clk = l4ls_gclk,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
};
-/* ecap0 */
-static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
- { .irq = 31 + OMAP_INTC_START, },
+/* ehrpwm0 */
+static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
+ { .name = int, .irq = 86 + OMAP_INTC_START, },
+ { .name = tzint, .irq = 58 + OMAP_INTC_START, },
{ .irq = -1 },
};
-static struct omap_hwmod am33xx_ecap0_hwmod = {
- .name = ecap0,
+/*
+ * Optional clock entry is provided to support additional clock
+ * gating for EHRPWM module from control module.
+ */
+static struct omap_hwmod_opt_clk ehrpwm0_opt_clks[] = {
+ { .role = tbclk, .clk =
[PATCH 5/8] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
Add support for device-tree binding for EHRWPM driver.
Also size of #pwm-cells set to 3 to support PWM channel number, PWM
period polarity configuration from device tree.
Also enable clock gating in PWM subsystem common config space.
Also when here set .owner member in platform_driver structure to
THIS_MODULE.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
---
Second version
- Combined with HWMOD changes DT bindings.
- Remove the custom of_xlate support.
:00 100644 000... aa2ed0a... A
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
:100644 100644 d3c1dff... 1e63652... M drivers/pwm/pwm-tiehrpwm.c
.../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 25 +
drivers/pwm/pwm-tiehrpwm.c | 37 ++-
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
new file mode 100644
index 000..aa2ed0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -0,0 +1,25 @@
+TI SOC EHRPWM based PWM controller
+
+Required properties:
+- compatible : Must be ti,am33xx-ehrpwm
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+ First cell specifies the per-chip index of the PWM to use, the second
+ cell is the period cycle in nanoseconds and bit 0 in the third cell is
+ used to encode the polarity of PWM output.
+- reg: physical base address and size of the registers map.
+
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the EHRPWM:
+ ehrpwmx, x being the 0-based instance number from the HW spec
+- tbclkgating: platforms require tbclk gating from control module
+ should populate
+
+Example:
+
+ehrpwm0: ehrpwm@0 {
+ compatible = ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48300200 0x100;
+ ti,hwmods = ehrpwm0;
+ tbclkgating;
+};
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index d3c1dff..1e63652 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -25,6 +25,10 @@
#include linux/err.h
#include linux/clk.h
#include linux/pm_runtime.h
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+
+#include tipwmss.h
/* EHRPWM registers and bits definitions */
@@ -107,6 +111,10 @@
#define AQCSFRC_CSFA_FRCHIGH BIT(1)
#define AQCSFRC_CSFA_DISSWFRC (BIT(1) | BIT(0))
+#define EPWMCLK_EN_SHIFT 8
+
+#define PWM_CELL_SIZE 3
+
#define NUM_PWM_CHANNEL2 /* EHRPWM channels */
struct ehrpwm_pwm_chip {
@@ -392,12 +400,27 @@ static const struct pwm_ops ehrpwm_pwm_ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct of_device_id ehrpwm_of_match[] = {
+ {
+ .compatible = ti,am33xx-ehrpwm,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
+#endif
+
static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
{
int ret;
struct resource *r;
struct clk *clk;
struct ehrpwm_pwm_chip *pc;
+ struct pinctrl *pinctrl;
+
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, failed to configure pins from driver\n);
pc = devm_kzalloc(pdev-dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
@@ -419,6 +442,7 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
pc-chip.dev = pdev-dev;
pc-chip.ops = ehrpwm_pwm_ops;
+ pc-chip.of_pwm_n_cells = PWM_CELL_SIZE;
pc-chip.base = -1;
pc-chip.npwm = NUM_PWM_CHANNEL;
@@ -437,8 +461,11 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
return ret;
}
-
pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
+ pwmss_submodule_state_change(pdev-dev.parent, EPWMCLK_EN_SHIFT, true);
+ pm_runtime_put_sync(pdev-dev);
+
platform_set_drvdata(pdev, pc);
return 0;
}
@@ -447,6 +474,10 @@ static int __devexit ehrpwm_pwm_remove(struct
platform_device *pdev)
{
struct ehrpwm_pwm_chip *pc = platform_get_drvdata(pdev);
+ pm_runtime_get_sync(pdev-dev);
+ pwmss_submodule_state_change(pdev-dev.parent, EPWMCLK_EN_SHIFT, false);
+ pm_runtime_put_sync(pdev-dev);
+
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
return pwmchip_remove(pc-chip);
@@ -454,7 +485,9 @@ static int __devexit ehrpwm_pwm_remove(struct
platform_device *pdev)
static struct platform_driver ehrpwm_pwm_driver = {
.driver = {
- .name = ehrpwm,
+ .name = ehrpwm,
+ .owner = THIS_MODULE,
+
[PATCH 6/8] pwm: pwm-tiehrpwm: Adding TBCLK gating support.
Some platforms (like AM33XX) requires clock gating from control module
explicitly. So adding optional TBCLK handling if DT node populated with
tbclkgating. This helps the driver can coexist for Davinci platforms.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 1e63652... cf69da3... M drivers/pwm/pwm-tiehrpwm.c
drivers/pwm/pwm-tiehrpwm.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 1e63652..cf69da3 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -123,6 +123,7 @@ struct ehrpwm_pwm_chip {
void __iomem*mmio_base;
unsigned long period_cycles[NUM_PWM_CHANNEL];
enum pwm_polarity polarity[NUM_PWM_CHANNEL];
+ struct clk *tbclk;
};
static inline struct ehrpwm_pwm_chip *to_ehrpwm_pwm_chip(struct pwm_chip *chip)
@@ -461,6 +462,20 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
return ret;
}
+
+ /* Some platforms require explicit tbclk gating */
+ if (of_property_read_bool(pdev-dev.of_node, tbclkgating)) {
+ pc-tbclk = clk_get(pdev-dev, tbclk);
+ if (IS_ERR(pc-tbclk)) {
+ dev_err(pdev-dev, Could not get EHRPWM TBCLK\n);
+ return PTR_ERR(pc-tbclk);
+ }
+ }
+
+ /* Enable tbclk leave */
+ if (pc-tbclk)
+ clk_enable(pc-tbclk);
+
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);
pwmss_submodule_state_change(pdev-dev.parent, EPWMCLK_EN_SHIFT, true);
@@ -478,6 +493,8 @@ static int __devexit ehrpwm_pwm_remove(struct
platform_device *pdev)
pwmss_submodule_state_change(pdev-dev.parent, EPWMCLK_EN_SHIFT, false);
pm_runtime_put_sync(pdev-dev);
+ if (pc-tbclk)
+ clk_disable(pc-tbclk);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
return pwmchip_remove(pc-chip);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] ARM: dts: AM33XX: Add PWMSS device tree nodes
Add PWMSS device tree nodes in relation with ECAP EHRPWM DT nodes to
AM33XX SoC family. Also populates device tree nodes for ECAP EHRPWM by
adding necessary properties like pwm-cells, base reg set disabled as
status.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Second version
- Combined with HWMOD changes DT bindings.
- Handling Parent- child relation ship for PWM subsystem
:100644 100644 bb31bff... cf5e049... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 90 +
1 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..cf5e049 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,95 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ epwmss0: epwmss@4830 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x4830 0x10
+ 0x48300100 0x80
+ 0x48300180 0x80
+ 0x48300200 0x80;
+ ti,hwmods = epwmss0;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
+
+ ecap0: ecap@48300100 {
+ compatible = ti,am33xx-ecap;
+ #pwm-cells = 3;
+ reg = 0x48300100 0x80;
+ ti,hwmods = ecap0;
+ status = disabled;
+ };
+
+ ehrpwm0: ehrpwm@48300200 {
+ compatible = ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48300200 0x80;
+ ti,hwmods = ehrpwm0;
+ status = disabled;
+ tbclkgating;
+ };
+ };
+
+ epwmss1: epwmss@48302000 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x48302000 0x10
+ 0x48302100 0x80
+ 0x48302180 0x80
+ 0x48302200 0x80;
+ ti,hwmods = epwmss1;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
+
+ ecap1: ecap@48302100 {
+ compatible = ti,am33xx-ecap;
+ #pwm-cells = 3;
+ reg = 0x48302100 0x80;
+ ti,hwmods = ecap1;
+ status = disabled;
+ };
+
+ ehrpwm1: ehrpwm@48302200 {
+ compatible = ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48302200 0x80;
+ ti,hwmods = ehrpwm1;
+ status = disabled;
+ tbclkgating;
+ };
+ };
+
+ epwmss2: epwmss@48304000 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x48304000 0x10
+ 0x48304100 0x80
+ 0x48304180 0x80
+ 0x48304200 0x80;
+ ti,hwmods = epwmss2;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
+
+ ecap2: ecap@48304100 {
+ compatible = ti,am33xx-ecap;
+ #pwm-cells = 3;
+ reg = 0x48304100 0x80;
+ ti,hwmods = ecap2;
+ status = disabled;
+ };
+
+ ehrpwm2: ehrpwm@48304200 {
+ compatible = ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48304200 0x80;
+ ti,hwmods = ehrpwm2;
+ status = disabled;
+ tbclkgating;
+ };
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
PWM output from ecap0 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Second version
- Combined with HWMOD changes DT bindings.
- No changes
:100644 100644 185d632... 9857050... M arch/arm/boot/dts/am335x-evm.dts
arch/arm/boot/dts/am335x-evm.dts | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..9857050 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -18,6 +18,14 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ ecap0_pins: backlight_pins {
+ pinctrl-single,pins =
+ 0x164 0x0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
@@ -31,6 +39,12 @@
reg = 0x2d;
};
};
+
+ ecap0: ecap@48300100 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = ecap0_pins;
+ };
};
vbat: fixedregulator@0 {
@@ -40,6 +54,13 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ backlight {
+ compatible = pwm-backlight;
+ pwms = ecap0 0 5 0;
+ brightness-levels = 0 51 53 56 62 75 101 152 255;
+ default-brightness-level = 8;
+ };
};
/include/ tps65910.dtsi
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
Add support for device-tree binding for ECAP APWM driver.
Also size of #pwm-cells set to 3 to support PWM channel number, PWM
period polarity configuration from device tree.
Also enable clock gating in PWM subsystem common config space.
Also when here set .owner member in platform_driver structure to
THIS_MODULE.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
---
Second version
- Combined with HWMOD changes DT bindings.
- Remove the custom of_xlate support.
:00 100644 000... fe24cac... A
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
:100644 100644 d6d4cf0... 7ea5bea2.. M drivers/pwm/pwm-tiecap.c
.../devicetree/bindings/pwm/pwm-tiecap.txt | 22
drivers/pwm/pwm-tiecap.c | 36 +++-
2 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
new file mode 100644
index 000..fe24cac
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -0,0 +1,22 @@
+TI SOC ECAP based APWM controller
+
+Required properties:
+- compatible: Must be ti,am33xx-ecap
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+ First cell specifies the per-chip index of the PWM to use, the second
+ cell is the period cycle in nanoseconds and bit 0 in the third cell is
+ used to encode the polarity of PWM output.
+- reg: physical base address and size of the registers map.
+
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the ECAP:
+ ecapx, x being the 0-based instance number from the HW spec
+
+Example:
+
+ecap0: ecap@0 {
+ compatible = ti,am33xx-ecap;
+ #pwm-cells = 3;
+ reg = 0x48300100 0x80;
+ ti,hwmods = ecap0;
+};
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index d6d4cf0..7ea5bea 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -25,6 +25,10 @@
#include linux/clk.h
#include linux/pm_runtime.h
#include linux/pwm.h
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+
+#include tipwmss.h
/* ECAP registers and bits definitions */
#define CAP1 0x08
@@ -37,6 +41,10 @@
#define ECCTL2_SYNC_SEL_DISA (BIT(7) | BIT(6))
#define ECCTL2_TSCTR_FREERUN BIT(4)
+#define ECAPCLK_EN_SHIFT 0
+
+#define PWM_CELL_SIZE 3
+
struct ecap_pwm_chip {
struct pwm_chip chip;
unsigned intclk_rate;
@@ -184,12 +192,27 @@ static const struct pwm_ops ecap_pwm_ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct of_device_id ecap_of_match[] = {
+ {
+ .compatible = ti,am33xx-ecap,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ecap_of_match);
+#endif
+
static int __devinit ecap_pwm_probe(struct platform_device *pdev)
{
int ret;
struct resource *r;
struct clk *clk;
struct ecap_pwm_chip *pc;
+ struct pinctrl *pinctrl;
+
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, failed to configure pins from driver\n);
pc = devm_kzalloc(pdev-dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
@@ -211,6 +234,7 @@ static int __devinit ecap_pwm_probe(struct platform_device
*pdev)
pc-chip.dev = pdev-dev;
pc-chip.ops = ecap_pwm_ops;
+ pc-chip.of_pwm_n_cells = PWM_CELL_SIZE;
pc-chip.base = -1;
pc-chip.npwm = 1;
@@ -231,6 +255,10 @@ static int __devinit ecap_pwm_probe(struct platform_device
*pdev)
}
pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
+ pwmss_submodule_state_change(pdev-dev.parent, ECAPCLK_EN_SHIFT, true);
+ pm_runtime_put_sync(pdev-dev);
+
platform_set_drvdata(pdev, pc);
return 0;
}
@@ -239,6 +267,10 @@ static int __devexit ecap_pwm_remove(struct
platform_device *pdev)
{
struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
+ pm_runtime_get_sync(pdev-dev);
+ pwmss_submodule_state_change(pdev-dev.parent, ECAPCLK_EN_SHIFT, false);
+ pm_runtime_put_sync(pdev-dev);
+
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
return pwmchip_remove(pc-chip);
@@ -246,7 +278,9 @@ static int __devexit ecap_pwm_remove(struct platform_device
*pdev)
static struct platform_driver ecap_pwm_driver = {
.driver = {
- .name = ecap,
+ .name = ecap,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ecap_of_match),
},
.probe = ecap_pwm_probe,
.remove = __devexit_p(ecap_pwm_remove),
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH 2/8] ARM: am33xx: clk: Add optional clock for EHRPWM
EHRPWM module requires explicit clock gating from control module.
Hence add clock node in clock tree for EHRPWM modules.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 17e3de5... 833260f... M arch/arm/mach-omap2/clock33xx_data.c
:100644 100644 a89e825... c0e34e6... M arch/arm/mach-omap2/control.h
arch/arm/mach-omap2/clock33xx_data.c | 37 ++
arch/arm/mach-omap2/control.h|8 +++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..833260f 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -995,6 +995,40 @@ static struct clk wdt1_fck = {
};
/*
+ * PWMSS Time based module clock node. This node is
+ * requred to enable clock gating for EHRPWM TBCLK.
+ */
+static struct clk ehrpwm0_tbclk = {
+ .name = ehrpwm0_tbclk,
+ .clkdm_name = l4ls_clkdm,
+ .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+ .enable_bit = AM33XX_PWMSS0_TBCLKEN_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .parent = l4ls_gclk,
+ .recalc = followparent_recalc,
+};
+
+static struct clk ehrpwm1_tbclk = {
+ .name = ehrpwm1_tbclk,
+ .clkdm_name = l4ls_clkdm,
+ .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+ .enable_bit = AM33XX_PWMSS1_TBCLKEN_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .parent = l4ls_gclk,
+ .recalc = followparent_recalc,
+};
+
+static struct clk ehrpwm2_tbclk = {
+ .name = ehrpwm2_tbclk,
+ .clkdm_name = l4ls_clkdm,
+ .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+ .enable_bit = AM33XX_PWMSS2_TBCLKEN_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .parent = l4ls_gclk,
+ .recalc = followparent_recalc,
+};
+
+/*
* clkdev
*/
static struct omap_clk am33xx_clks[] = {
@@ -1074,6 +1108,9 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, clkout2_ck, clkout2_ck,CK_AM33XX),
CLK(NULL, timer_32k_ck, clkdiv32k_ick, CK_AM33XX),
CLK(NULL, timer_sys_ck, sys_clkin_ck, CK_AM33XX),
+ CLK(NULL, ehrpwm0_tbclk,ehrpwm0_tbclk, CK_AM33XX),
+ CLK(NULL, ehrpwm1_tbclk,ehrpwm1_tbclk, CK_AM33XX),
+ CLK(NULL, ehrpwm2_tbclk,ehrpwm2_tbclk, CK_AM33XX),
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a89e825..c0e34e6 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -357,6 +357,14 @@
#define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2
#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 22)
+/* AM33XX PWMSS Control register */
+#define AM33XX_PWMSS_TBCLK_CLKCTRL 0x664
+
+/* AM33XX PWMSS Control bitfields */
+#define AM33XX_PWMSS0_TBCLKEN_SHIFT0
+#define AM33XX_PWMSS1_TBCLKEN_SHIFT1
+#define AM33XX_PWMSS2_TBCLKEN_SHIFT2
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS 0x044c
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] PWMSS: Add PWM Subsystem driver for parent-child relationship
In some platforms (like am33xx), PWM sub modules (ECAP, EHRPWM, EQEP)
are integrated to PWM subsystem. These PWM submodules has resources
shared and only one register bit-field is provided to control
module/clock enable/disable, makes it difficult to handle common
resources from independent PWMSS submodule drivers.
So the solution here implemented in this patch is, to create driver for
PWMSS and take the role of parent driver for PWM submodules. PWMSS
parent driver enumerates all the child nodes under PWMSS module. Also
symbol pwmss_submodule_state_change exported to enable clock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.
As this is only supported during DT boot, the parent-child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM ECAP as a child to PWMSS node.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
---
:00 100644 000... b6c2814... A
Documentation/devicetree/bindings/pwm/tipwmss.txt
:100644 100644 ed81720... 99ebcfa... M drivers/pwm/Kconfig
:100644 100644 acfe482... 1001bdb... M drivers/pwm/Makefile
:00 100644 000... d30a802... A drivers/pwm/tipwmss.c
:00 100644 000... 83fdc29... A drivers/pwm/tipwmss.h
Documentation/devicetree/bindings/pwm/tipwmss.txt | 30 +
drivers/pwm/Kconfig | 11 ++
drivers/pwm/Makefile |1 +
drivers/pwm/tipwmss.c | 136 +
drivers/pwm/tipwmss.h |8 ++
5 files changed, 186 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/tipwmss.txt
b/Documentation/devicetree/bindings/pwm/tipwmss.txt
new file mode 100644
index 000..b6c2814
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/tipwmss.txt
@@ -0,0 +1,30 @@
+TI SOC based PWM Subsystem
+
+Required properties:
+- compatible: Must be ti,am33xx-pwmss;
+- reg: physical base address and size of the registers map. For am33xx,
+ 4 set of register maps present, PWMSS config space, ECAP register space,
+ EQEP register space, EHRPWM register space.
+- address-cells: Specify the number of u32 entries needed in child nodes.
+Should set to 1.
+- size-cells: specify inumber of u32 entries needed to specify child nodes size
+ in reg property. Should set to 1.
+- ranges: describes the address mapping of a memory-mapped bus. Should set to
empty
+ as parent and child address space is identical.
+
+Also child nodes should also populated under PWMSS DT node.
+Example:
+pwmss0: pwmss@4830 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x4830 0x10
+ 0x48300100 0x80
+ 0x48300180 0x80
+ 0x48300200 0x80;
+ ti,hwmods = epwmss0;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
+
+ /* child nodes go here */
+};
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..99ebcfa 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -125,6 +125,7 @@ config PWM_TEGRA
config PWM_TIECAP
tristate ECAP PWM support
depends on SOC_AM33XX
+ select PWM_TIPWMSS
help
PWM driver support for the ECAP APWM controller found on AM33XX
TI SOC
@@ -135,6 +136,7 @@ config PWM_TIECAP
config PWM_TIEHRPWM
tristate EHRPWM PWM support
depends on SOC_AM33XX
+ select PWM_TIPWMSS
help
PWM driver support for the EHRPWM controller found on AM33XX
TI SOC
@@ -142,6 +144,15 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
+config PWM_TIPWMSS
+ tristate TI PWM Subsytem parent support
+ depends on SOC_AM33XX (PWM_TIEHRPWM || PWM_TIECAP)
+ help
+ PWM Subsystem driver support for AM33xx SOC.
+
+ PWM submodules require PWM config space access from submodule
+ drivers and require common parent driver support.
+
config PWM_TWL6030
tristate TWL6030 PWM support
depends on TWL4030_CORE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..1001bdb 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
+obj-$(CONFIG_PWM_TIPWMSS) += tipwmss.o
obj-$(CONFIG_PWM_TWL6030) += pwm-twl6030.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/tipwmss.c b/drivers/pwm/tipwmss.c
new file mode 100644
index 000..d30a802
--- /dev/null
+++
Re: [PATCHv2 1/7] i2c: omap: Fix the revision register read
On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote: @@ -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 */ looks like this was applicable to 4430 too, what happened ? No actually this can be deleted completely once the start - transaction - stop sequence recommendation is followed. yes, but we're not there just yet and this patch is changing the behavior No , earlier we were truncating the register for omap4 so OMAP_I2C_REV_ON_3630_4430 was there if we read both hi and lo for omap4 then we donot find 3630 and 4430 value to be similar. In this case the behavior is same as earlier also it enabled this for lower than 3630 and the same holds good even now. So in essence, Earlier OMAP_I2C_REV_ON_3630_4430 is named to OMAP_I2C_REV_ON_3630 and omap4 rev will have a 32bit value which is greater. of the driver in ways which don't belong to $SUBJECT. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: AM33XX: Enable system power off control in am335x-bone
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 40ea3c7..6f9c48e 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -38,6 +38,10 @@
};
};
+
+ rtc@44e3e000 {
+ ti,system-power-controller;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] pm: Add power off control
Add PM power_off control to rtc driver, along with this PMIC status is set to STATUS_OFF to shutdown PMIC if PWR_EN is toggled by RTC module. System power off sequence:- * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low * Enable PMIC_POWER_EN in rtc module * Set rtc ALARM2 time * Enable ALARM2 interrupt These patches were tested on AM335x-Bone. AnilKumar Ch (2): ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone ARM: dts: AM33XX: Enable system power off control in am335x-bone Colin Foe-Parker (2): mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle rtc: OMAP: Add system pm_power_off to rtc driver .../devicetree/bindings/regulator/tps65217.txt |4 + Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++ arch/arm/boot/dts/am335x-bone.dts |6 ++ drivers/mfd/tps65217.c | 12 +++ drivers/rtc/rtc-omap.c | 79 +++- 5 files changed, 105 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
From: Colin Foe-Parker colin.foepar...@logicpd.com
Set tps65217 PMIC status to OFF if power enable toggle is
supported. Also adds platform data flag, which should be
passed from board init data.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move the additions to tps65217 MFD driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
.../devicetree/bindings/regulator/tps65217.txt |4
drivers/mfd/tps65217.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d316fb8..4f05d20 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -11,6 +11,9 @@ Required properties:
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
+Optional properties:
+- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
+
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@@ -20,6 +23,7 @@ Example:
tps: tps@24 {
compatible = ti,tps65217;
+ ti,pmic-shutdown-controller;
regulators {
dcdc1_reg: dcdc1 {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 3fb32e6..c7f17d8 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
unsigned int version;
unsigned int chip_id = ids-driver_data;
const struct of_device_id *match;
+ bool status_off = false;
int ret;
if (client-dev.of_node) {
@@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return -EINVAL;
}
chip_id = (unsigned int)match-data;
+ status_off = of_property_read_bool(client-dev.of_node,
+ ti,pmic-shutdown-controller);
}
if (!chip_id) {
@@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return ret;
}
+ /* Set the PMIC to shutdown on PWR_EN toggle */
+ if (status_off) {
+ ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
+ TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
+ TPS65217_PROTECT_NONE);
+ if (ret)
+ dev_warn(tps-dev, unable to set the status OFF\n);
+ }
+
dev_info(tps-dev, TPS65217 ID %#x version 1.%d\n,
(version TPS65217_CHIPID_CHIP_MASK) 4,
version TPS65217_CHIPID_REV_MASK);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone
Set ti,pmic-shutdown-controller for BeagleBone in am335x-bone.dts
file, this flag is used by the driver to set tps65217 PMIC status
to OFF when PWR_EN toggle.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 91eee97..40ea3c7 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -44,6 +44,8 @@
/include/ tps65217.dtsi
tps {
+ ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-always-on;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Added while (1); after the above steps to make sure that no other
process acquire cpu. Otherwise we might see an unexpected behaviour
because we are shutting down all the power rails of SoC except RTC.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 79 +++-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..2d90170 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,24 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+#define SECS_IN_MIN60
+#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
+#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +307,58 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ spinlock_t lock;
+ unsigned long flags;
+
+ spin_lock_init(lock);
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
+
+ /* Wait few seconds instead of rollover */
+ do {
+ omap_rtc_read_time(NULL, tm);
+ if (WAIT_AFTER = tm.tm_sec)
+ mdelay(WAIT_TIME_MS);
+ } while (WAIT_AFTER = tm.tm_sec);
+
+ /* Add shutdown time to the current value */
+ tm.tm_sec += SHUTDOWN_TIME_SEC;
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /* Set the ALARM2 time */
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+ /* Enable alarm2 interrupt */
+ val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
+ writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
+ rtc_base + OMAP_RTC_INTERRUPTS_REG);
+
+ /* Do not allow to
[GIT PULL] omapdss fixes for 3.7-rc
Hi Florian, Here are a few omapdss fixes, two fixing crasher bugs and the third fixes a missing unlock. These are based on 3.7-rc1. I can rebase on top of something else if you prefer that. Tomi The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.7-rc5 for you to fetch changes up to dffc70ade1d13edd186f542718c4d78a31d92fb8: OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs() (2012-10-26 08:45:43 +0300) omapdss fixes for 3.7-rc5 omapdss fixes for two crashes bugs and one missing mutex unlock. Laurent Pinchart (1): omapdss: dss: Fix clocks on OMAP363x Tomi Valkeinen (1): OMAPDSS: DSI: fix dsi_get_dsidev_from_id() Wei Yongjun (1): OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs() drivers/video/omap2/dss/dsi.c | 13 +++-- drivers/video/omap2/dss/dss.c |4 ++-- drivers/video/omap2/dss/hdmi.c |4 +++- 3 files changed, 16 insertions(+), 5 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [PATCHv2 1/7] i2c: omap: Fix the revision register read
Hi, On Mon, Nov 05, 2012 at 02:54:32PM +0530, Shubhrajyoti Datta wrote: On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote: @@ -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 */ looks like this was applicable to 4430 too, what happened ? No actually this can be deleted completely once the start - transaction - stop sequence recommendation is followed. yes, but we're not there just yet and this patch is changing the behavior of the driver No , earlier we were truncating the register for omap4 so OMAP_I2C_REV_ON_3630_4430 was there if we read both hi and lo for omap4 then we donot find 3630 and 4430 value to be similar. In this case the behavior is same as earlier also it enabled this for lower than 3630 and the same holds good even now. So in essence, Earlier OMAP_I2C_REV_ON_3630_4430 is named to OMAP_I2C_REV_ON_3630 and omap4 rev will have a 32bit value. it's not same behavior because before dev-b_hw was set for omap4430, but now it won't be. This is the difference in behavior which I'm pointing out. -- balbi signature.asc Description: Digital signature
[PATCH] ARM: OMAP4: ID: Improve features detection and check
Replaces several flags bearing the same meaning. There is no need
to set flags due to different omap types here, it can be checked
in appropriate places as well.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Nishanth Menon n...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/id.c | 25 +++--
arch/arm/mach-omap2/soc.h |8 ++--
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index cf2362c..3c47a19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,9 @@
#include soc.h
#include control.h
+#define OMAP4_SILICON_TYPE_STANDARD0x01
+#define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
+
static unsigned int omap_revision;
static const char *cpu_rev;
u32 omap_features;
@@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
{
u32 si_type;
- if (cpu_is_omap443x())
- omap_features |= OMAP4_HAS_MPU_1GHZ;
-
+ si_type =
+ (read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) 16) 0x03;
- if (cpu_is_omap446x()) {
- si_type =
- read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
- switch ((si_type (3 16)) 16) {
- case 2:
- /* High performance device */
- omap_features |= OMAP4_HAS_MPU_1_5GHZ;
- break;
- case 1:
- default:
- /* Standard device */
- omap_features |= OMAP4_HAS_MPU_1_2GHZ;
- break;
- }
- }
+ if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
+ omap_features = OMAP4_HAS_PERF_SILICON;
}
void __init ti81xx_check_features(void)
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 0700964..f31d907 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -435,9 +435,7 @@ extern u32 omap_features;
#define OMAP3_HAS_IO_WAKEUPBIT(6)
#define OMAP3_HAS_SDRC BIT(7)
#define OMAP3_HAS_IO_CHAIN_CTRLBIT(8)
-#define OMAP4_HAS_MPU_1GHZ BIT(9)
-#define OMAP4_HAS_MPU_1_2GHZ BIT(10)
-#define OMAP4_HAS_MPU_1_5GHZ BIT(11)
+#define OMAP4_HAS_PERF_SILICON BIT(9)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -465,9 +463,7 @@ static inline unsigned int omap4_has_ ##feat(void) \
return omap_features OMAP4_HAS_ ##flag; \
} \
-OMAP4_HAS_FEATURE(mpu_1ghz, MPU_1GHZ)
-OMAP4_HAS_FEATURE(mpu_1_2ghz, MPU_1_2GHZ)
-OMAP4_HAS_FEATURE(mpu_1_5ghz, MPU_1_5GHZ)
+OMAP4_HAS_FEATURE(perf_silicon, PERF_SILICON)
#endif /* __ASSEMBLY__ */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM
Add pinmux configurations for gpio volume keys. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 8076e66..e087b87 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins =
@@ -37,6 +37,13 @@
0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT |
MODE7 */
;
};
+
+ volume_keys_s0: volume_keys_s0 {
+ pinctrl-single,pins =
+ 0x150 0x27 /* spi0_sclk.gpio0_2, INPUT |
MODE7 */
+ 0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
+ ;
+ };
};
ocp {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk
Add gpio based push buttons device tree data to am335x-evmsk device
by adding all the necessary parameters like key-code, gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0f825dd..f5a6162 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -139,6 +139,37 @@
default-state = off;
};
};
+
+ gpio_buttons: gpio_buttons@0 {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ switch@1 {
+ label = button0;
+ linux,code = 0x100;
+ gpios = gpio3 3 0;
+ };
+
+ switch@2 {
+ label = button1;
+ linux,code = 0x101;
+ gpios = gpio3 2 0;
+ };
+
+ switch@3 {
+ label = button2;
+ linux,code = 0x102;
+ gpios = gpio1 30 0;
+ gpio-key,wakeup;
+ };
+
+ switch@4 {
+ label = button3;
+ linux,code = 0x103;
+ gpios = gpio3 5 0;
+ };
+ };
};
/include/ tps65910.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK
Add pinmux configurations for gpio based keys to am335x-evmsk. In
this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 7262fa8..0f825dd 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0;
+ pinctrl-0 = user_leds_s0 gpio_keys_s0;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -42,6 +42,15 @@
0x1c 0x7/* gpmc_ad7.gpio1_7, OUTPUT |
MODE7 */
;
};
+
+ gpio_keys_s0: gpio_keys_s0 {
+ pinctrl-single,pins =
+ 0x94 0x27 /* gpmc_oen_ren.gpio2_3, INPUT
| MODE7 */
+ 0x90 0x27 /* gpmc_advn_ale.gpio2_2, INPUT
| MODE7 */
+ 0x70 0x27 /* gpmc_wait0.gpio0_30, INPUT |
MODE7 */
+ 0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT
| MODE7 */
+ ;
+ };
};
ocp {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk
Add gpio-leds device tree data to am335x-evmsk device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on am335x starter
kit.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 659ec5b..7262fa8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -100,6 +100,36 @@
regulator-name = lis3_reg;
regulator-boot-on;
};
+
+ leds {
+ compatible = gpio-leds;
+
+ led@1 {
+ label = evmsk:green:usr0;
+ gpios = gpio2 4 0;
+ default-state = off;
+ };
+
+ led@2 {
+ label = evmsk:green:usr1;
+ gpios = gpio2 5 0;
+ default-state = off;
+ };
+
+ led@3 {
+ label = evmsk:green:mmc0;
+ gpios = gpio2 6 0;
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@4 {
+ label = evmsk:green:heartbeat;
+ gpios = gpio2 7 0;
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+ };
};
/include/ tps65910.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE
Add pinmux configurations for gpio based user-keys to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 6f9c48e..0bd0355 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,6 +24,20 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = user_leds_s0;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins =
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x17 /* gpmc_a6.gpio1_22,
OUTPUT_PULLUP | MODE7 */
+ 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
MODE7 */
+ 0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM
Add pinmux configurations for gpio matrix keypad. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 513284f..9199456 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -24,6 +24,21 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = matrix_keypad_s0;
+
+ matrix_keypad_s0: matrix_keypad_s0 {
+ pinctrl-single,pins =
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x7/* gpmc_a6.gpio1_22, OUTPUT |
MODE7 */
+ 0x64 0x27 /* gpmc_a9.gpio1_25, INPUT |
MODE7 */
+ 0x68 0x27 /* gpmc_a10.gpio1_26, INPUT |
MODE7 */
+ 0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT |
MODE7 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm
Add gpio based volume keys device tree data to am335x-evm by adding
all the required parameters like keycode, gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e087b87..9f65f17 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -137,6 +137,27 @@
0x0101001c /* ENTER */
0x0201006c;/* DOWN */
};
+
+ gpio_keys: volume_keys@0 {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+ autorepeat;
+
+ switch@9 {
+ label = volume-up;
+ linux,code = 115;
+ gpios = gpio1 2 1;
+ gpio-key,wakeup;
+ };
+
+ switch@10 {
+ label = volume-down;
+ linux,code = 114;
+ gpios = gpio1 3 1;
+ gpio-key,wakeup;
+ };
+ };
};
/include/ tps65910.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK
Add pinmux configurations for gpio based volume keys to am335x-evmsk.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 6f53879..659ec5b 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -30,6 +30,20 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = user_leds_s0;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins =
+ 0x10 0x7/* gpmc_ad4.gpio1_4, OUTPUT |
MODE7 */
+ 0x14 0x7/* gpmc_ad5.gpio1_5, OUTPUT |
MODE7 */
+ 0x18 0x7/* gpmc_ad6.gpio1_6, OUTPUT |
MODE7 */
+ 0x1c 0x7/* gpmc_ad7.gpio1_7, OUTPUT |
MODE7 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone
Add gpio-leds device tree data to am335x-bone device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
[k...@dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 0bd0355..206c3eb 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -57,6 +57,36 @@
ti,system-power-controller;
};
};
+
+ leds {
+ compatible = gpio-leds;
+
+ led@2 {
+ label = beaglebone:green:heartbeat;
+ gpios = gpio2 21 0;
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+
+ led@3 {
+ label = beaglebone:green:mmc0;
+ gpios = gpio2 22 0;
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@4 {
+ label = beaglebone:green:usr2;
+ gpios = gpio2 23 0;
+ default-state = off;
+ };
+
+ led@5 {
+ label = beaglebone:green:usr3;
+ gpios = gpio2 24 0;
+ default-state = off;
+ };
+ };
};
/include/ tps65217.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm
Add matrix keypad device tree data to am335x-evm by adding all
the necessary parameters like keymap, row column gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9199456..8076e66 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -110,6 +110,26 @@
regulator-name = lis3_reg;
regulator-boot-on;
};
+
+ matrix_keypad: matrix_keypad@0 {
+ compatible = gpio-matrix-keypad;
+ debounce-delay-ms = 5;
+ col-scan-delay-us = 2;
+
+ row-gpios = gpio2 25 0/* Bank1, pin25 */
+gpio2 26 0/* Bank1, pin26 */
+gpio2 27 0; /* Bank1, pin27 */
+
+ col-gpios = gpio2 21 0/* Bank1, pin21 */
+gpio2 22 0; /* Bank1, pin22 */
+
+ linux,keymap = 0x008b /* MENU */
+ 0x019e /* BACK */
+ 0x0269 /* LEFT */
+ 0x0001006a /* RIGHT */
+ 0x0101001c /* ENTER */
+ 0x0201006c;/* DOWN */
+ };
};
/include/ tps65910.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] ARM: dts: AM33XX: Add device tree data
Add device tree date for GPIO based various drivers matrix keypad, volume keys, push buttons and use leds accross three AM33XX devices viz EVM, BeagleBone and Starter Kit. To make it functional this series also adds pinctrl data for all the GPIOs used by various drivers. In this series only default state pinmux/conf settings are added because of sleep/idle state pinctrl values are not available. These patches are based on linux-omap-dt:for_3.8/dts tree and these were tested on am33xx devices according to added functionality. AnilKumar Ch (10): ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk arch/arm/boot/dts/am335x-bone.dts | 44 +++ arch/arm/boot/dts/am335x-evm.dts | 63 +++ arch/arm/boot/dts/am335x-evmsk.dts | 84 3 files changed, 191 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
Hi Lokesh, On 11/05/2012 06:58 AM, Lokesh Vutla wrote: Hi, On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote: This patch series adds Device tree data for the EMIF sdram controllers in OMAP5 and LPDDR2 memory devices in OMAP5-evm board. Testing: - Boot tested on OMAP5430 evm. - Built EMIF as a module. Changes from v1: * Created a seperate dtsi file for Samsung LPDDR2 memory device used in OMAP5-evm. * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. Gentle ping on this series. Sorry, I missed it. It might be too late for 3.8, since Tony wanted us to push before -rc4. I'll pull the series anyway just in case. I have a least one comment. Regards, Benoit Thanks Lokesh Lokesh Vutla (3): ARM: dts: omap5-evm: Fix size of memory defined for EVM ARM: dts: omap5: EMIF device tree data for OMAP5 boards ARM: dts: omap5-evm: LPDDR2 memory device details for EVM arch/arm/boot/dts/omap5-evm.dts | 13 +- arch/arm/boot/dts/omap5.dtsi | 24 +++ arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 + 3 files changed, 103 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/7] i2c: omap: Fix the revision register read
Hi, On Mon, Nov 05, 2012 at 12:01:05PM +0200, Felipe Balbi wrote: Hi, On Mon, Nov 05, 2012 at 02:54:32PM +0530, Shubhrajyoti Datta wrote: On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote: @@ -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 */ looks like this was applicable to 4430 too, what happened ? No actually this can be deleted completely once the start - transaction - stop sequence recommendation is followed. yes, but we're not there just yet and this patch is changing the behavior of the driver No , earlier we were truncating the register for omap4 so OMAP_I2C_REV_ON_3630_4430 was there if we read both hi and lo for omap4 then we donot find 3630 and 4430 value to be similar. In this case the behavior is same as earlier also it enabled this for lower than 3630 and the same holds good even now. So in essence, Earlier OMAP_I2C_REV_ON_3630_4430 is named to OMAP_I2C_REV_ON_3630 and omap4 rev will have a 32bit value. it's not same behavior because before dev-b_hw was set for omap4430, but now it won't be. This is the difference in behavior which I'm pointing out. what I said is nonsense, since b_hw was set for anything older than 3630, so current code is no different. -- balbi signature.asc Description: Digital signature
Re: [PATCH V2 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5db33f4..445aeea 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -319,5 +319,29 @@
ti,buffer-size = 128;
ti,hwmods = mcbsp3;
};
+
+ emif1: emif@0x4c00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif1;
+ phy-type= 2;
+ reg = 0x4c00 0x3ff;
Should 0x400. This parameter is the size, not the end address.
+ interrupts = 0 110 0x4;
+ interrupt-parent = gic;
Please remove the interrupt-parent. It is not needed since DT will use
the parent node to get it. It will avoid duplicating the entry for every
nodes.
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+ emif2: emif@0x4d00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif2;
+ phy-type= 2;
Can you just add a comment to give more information. I know this is in
the binding documentation, but some more comment never hurt.
+ reg = 0x4d00 0x3ff;
0x400 as well.
+ interrupts = 0 111 0x4;
+ interrupt-parent = gic;
Ditto.
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
};
};
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
On Fri, Nov 02, 2012 at 20:55:54, Daniel Mack wrote:
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..c3616c6 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,7 +92,7 @@ static int omap2_nand_gpmc_retime(
static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
- if (!cpu_is_omap34xx()) {
+ if (!cpu_is_omap34xx() !soc_is_am33xx()) {
pr_err(BCH ecc is not supported on this CPU\n);
return 0;
}
Please add '!soc_is_am33xx()' check for BCH4 failure case also.
BCH4 support tested in AM335x.
https://lkml.org/lkml/2012/10/31/82
Thanks
Avinash
--
1.7.11.7
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 11 +
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67
+
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..ed1d1b5 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap5.dtsi
+/include/ samsung_k3pe0e000b.dtsi
/ {
model = TI OMAP5 EVM board;
@@ -82,3 +83,13 @@
0x020700d9;/* SEARCH */
linux,input-no-autorepeat;
};
+
+emif1 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
+
+emif2 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
diff --git a/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
new file mode 100644
index 000..b352d69
--- /dev/null
+++ b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Timings and Geometry for Samsung K3PE0E000B memory part
+ */
+
+/ {
+ samsung_K3PE0E000B: lpddr2 {
+ compatible = Samsung,K3PE0E000B,jedec,lpddr2-s4;
+ density = 4096;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
Nit, but the official unit is: MHz [1].
Regards,
Benoit
[1] http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
On 11/05/2012 11:51 AM, Benoit Cousson wrote: Hi Lokesh, On 11/05/2012 06:58 AM, Lokesh Vutla wrote: Hi, On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote: This patch series adds Device tree data for the EMIF sdram controllers in OMAP5 and LPDDR2 memory devices in OMAP5-evm board. Testing: - Boot tested on OMAP5430 evm. - Built EMIF as a module. Changes from v1: * Created a seperate dtsi file for Samsung LPDDR2 memory device used in OMAP5-evm. * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. Gentle ping on this series. Sorry, I missed it. It might be too late for 3.8, since Tony wanted us to push before -rc4. I'll pull the series anyway just in case. I have a least one comment. Could you just rebase on top of the for_3.8 branch, fix the minor comments and repost ASAP. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 16;
+ nand-ecc-mode = none;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 36;
+ gpmc,cs-wr-off = 36;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 24;
+ gpmc,adv-wr-off = 36;
+ gpmc,we-off = 30;
+ gpmc,oe-off = 48;
+ gpmc,access = 54;
+ gpmc,rd-cycle = 72;
+ gpmc,wr-cycle = 72;
+ gpmc,wr-access = 30;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
Can you take the timings (for example) from arago tree. The timings is tested
in am335x-evm
So the timings can be directly used to populate GPMC timings. Timings can found
at
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
[...]
+static int gpmc_probe_dt(struct platform_device *pdev)
Can you take care of the following section mismatch.
WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
from the function gpmc_probe_dt() to the function .init.text:gpmc_nand_init().
[...]
+
+ val = of_get_nand_ecc_mode(child);
+ if (val = 0)
+ gpmc_nand_data-ecc_opt = val;
This will fail for BCH. Index of soft_bch is 5 also don't have selection
option between for BCH4 BCH8 also.
Can you use the of_property_read_u32 (as done early) to pass the ecc selection
from dt file. This will help selection of BCH4 BCH8 ecc options.
Thanks
Avinash
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
Hi Benoit, On Monday 05 November 2012 04:33 PM, Benoit Cousson wrote: On 11/05/2012 11:51 AM, Benoit Cousson wrote: Hi Lokesh, On 11/05/2012 06:58 AM, Lokesh Vutla wrote: Hi, On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote: This patch series adds Device tree data for the EMIF sdram controllers in OMAP5 and LPDDR2 memory devices in OMAP5-evm board. Testing: - Boot tested on OMAP5430 evm. - Built EMIF as a module. Changes from v1: * Created a seperate dtsi file for Samsung LPDDR2 memory device used in OMAP5-evm. * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. Gentle ping on this series. Sorry, I missed it. It might be too late for 3.8, since Tony wanted us to push before -rc4. I'll pull the series anyway just in case. I have a least one comment. Could you just rebase on top of the for_3.8 branch, fix the minor comments and repost ASAP. OK I ll rebase and repost. Thanks Lokesh Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM33XX: Add usbss node
+ Felipe
Hi Afzal,
On 11/05/2012 06:59 AM, Afzal Mohammed wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg interrupt property addition]
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi Benoit,
This is based on your for_3.8/dts branch.
This is made on top of usb: musb: am335x support
(http://marc.info/?l=linux-omapm=135187391904863w=2)
and has been tested on Beagle Bone.
That looks good to me, I just like to get an Ack from Felipe for the
accuracy of the data part.
Regards,
Benoit
Regards
Afzal
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..78340a5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -321,5 +321,22 @@
ti,hwmods = spi1;
status = disabled;
};
+
+ usb_otg_hs@4740 {
+ compatible = ti,musb-am33xx;
+ reg = 0x4740 0x1000/* usbss */
+0x47401000 0x800 /* musb instance 0 */
+0x47401800 0x800; /* musb instance 1 */
+ interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port0-mode = 3;
+ port1-mode = 3;
+ power = 250;
+ ti,hwmods = usb_otg_hs;
+ };
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
Hi Kevin, On 11/03/2012 09:31 AM, Kevin Hilman wrote: On 10/30/2012 12:24 PM, Peter Ujfalusi wrote: When booting with DT the OF core can fill up the resources provided within the DT blob. The current way of handling the DT boot prevents us from removing hwmod data for platforms only suppose to boot with DT (OMAP5 for example) since we need to keep the whole hwmod database intact in order to have more resources in hwmod than in DT (to be able to append the DMA resource from hwmod). To fix this issue we just examine the OF provided resources: If we do not have resources we use hwmod to fill them. If we have resources we check if we already able to recive DMA resource, if no we only append the DMA resurce from hwmod to the OF provided ones. In this way we can start removing hwmod data for devices which have their resources correctly configured in DT without regressions. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.comke Acked-by: Kevin Hilman khil...@ti.com Benoit, feel free to take this one as well. Thanks, I'll do. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] ARM: dts: AM33xx: Add SPI node
On Thu, Nov 01, 2012 at 19:19:41, Cousson, Benoit wrote: Hi Avinash, On 10/31/2012 11:51 AM, Philip, Avinash wrote: Add McSPI data node to AM33XX device tree file. The McSPI module (and so as the driver) is reused from OMAP4. Signed-off-by: Philip, Avinash avinashphi...@ti.com Tested-by: Matt Porter mpor...@ti.com I've just realized the interrupt-parent was still there, so I removed both. Please find below the updated version. I tested it and thanks for the fix. Thanks Avinash -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/8] i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
The errata i207 is enabled for 2430 and 3xxx. Use the revision check to enable the erratum instead. Reviewed-by: Felipe Balbi ba...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@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 5c6f538..737d843 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/7] i2c: omap: updates
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. Adds a patch to remove the hardcoding sysc register. Instead read register ,reset and then writeback the read value. Also more cleanup is possible will check on that subsequently. Previous discussions can be found http://www.spinics.net/lists/linux-omap/msg81265.html 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 The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap/for_3.8 Shubhrajyoti D (8): 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 i2c: omap: cleanup the sysc write 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 | 202 include/linux/i2c-omap.h |1 - 4 files changed, 118 insertions(+), 97 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 8/8] i2c: omap: cleanup the sysc write
Currently after the reset the sysc is written with hardcoded values.
The patch reads the sysc register and writes back the same value
after reset.
- Some unnecessary rev checks can be optimised.
- Also due to whatever reason the hwmod flags are changed
we will not reset the values.
- In some of the cases the minor values of the 2430 register
is different(0x37) in that case the autoidle setting may be missed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 25f1564..a09acdc 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -302,7 +302,11 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
unsigned long timeout;
+ u16 sysc;
+
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
+ sysc = omap_i2c_read_reg(dev, OMAP_I2C_SYSC_REG);
+
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
omap_i2c_read_reg(dev, OMAP_I2C_CON_REG)
@@ -324,22 +328,8 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
}
/* SYSC register is cleared by the reset; rewrite it */
- if (dev-rev == OMAP_I2C_REV_ON_2430) {
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
- SYSC_AUTOIDLE_MASK);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
- dev-syscstate = SYSC_AUTOIDLE_MASK;
- dev-syscstate |= SYSC_ENAWAKEUP_MASK;
- dev-syscstate |= (SYSC_IDLEMODE_SMART
- __ffs(SYSC_SIDLEMODE_MASK));
- dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
- __ffs(SYSC_CLOCKACTIVITY_MASK));
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
- dev-syscstate);
- }
}
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 7/8] i2c: omap: Restore i2c context always
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. Reviewed-by: Felipe Balbi ba...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@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 7393017..25f1564 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1316,8 +1316,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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 6/8] i2c: omap: make reset a seperate function
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.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
todo: reprodue the errors and optimise the reset if possible
drivers/i2c/busses/i2c-omap.c | 39 ---
1 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 393bb22..7393017 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 = 1200;
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,
@@ -345,14 +339,27 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
dev-syscstate);
- /*
-* Enabling all wakup sources to stop I2C freezing on
-* WFI instruction.
-* REVISIT: Some wkup sources might not be needed.
-*/
- 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 = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
+ /*
+* Enabling all wakup sources to stop I2C freezing on
+* WFI instruction.
+* REVISIT: Some wkup sources might not be needed.
+*/
+ dev-westate = OMAP_I2C_WE_ALL;
+ }
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -592,7 +599,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 +610,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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 4/8] ARM: i2c: omap: Remove the i207 errata flag
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.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@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 5f0c06c..88358d8 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_I207BIT(4)
#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLKBIT(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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/8] i2c: omap: Fix the revision register read
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 shubhrajy...@ti.com
---
v3: Fix the comments.
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..5c6f538 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 0x0036
+#define OMAP_I2C_REV_ON_3430_3530 0x003C
+#define OMAP_I2C_REV_ON_3630 0x0040
+#define OMAP_I2C_REV_ON_4430_PLUS 0x5042
/* 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;
unsignedb_hw:1; /* bad h/w fixes */
unsignedreceiver: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 omap1/3/2 Offset 4 is IE Reg the bit [15:14] 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);
+ 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);
+
[PATCHv3 5/8] i2c: omap: re-factor omap_i2c_init function
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.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@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 88358d8..393bb22 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 = 1200;
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
[PATCHv3 3/8] i2c: omap: remove the dtrev
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 shubhrajy...@ti.com
---
v3: remove the scheme from the commments.
todo: remove the dtrev from hwmod etc.
drivers/i2c/busses/i2c-omap.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 737d843..5f0c06c 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 = 10; /* default to 10 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);
@@ -1230,8 +1228,8 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_unuse_clocks;
}
- dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, adap-nr,
-dev-dtrev, major, minor, dev-speed);
+ dev_info(dev-dev, bus %d rev%d.%d at %d kHz\n, adap-nr,
+major, minor, dev-speed);
of_i2c_register_devices(adap);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/3] ARM: dts: omap5-evm: Fix size of memory defined for EVM
Memory present for OMAP5-evm is 2GB. But in dts file
it is specified as 1GB. Correcting the same.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..88d3d9b8 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -15,7 +15,7 @@
memory {
device_type = memory;
- reg = 0x8000 0x4000; /* 1 GB */
+ reg = 0x8000 0x8000; /* 2 GB */
};
vmmcsd_fixed: fixedregulator-mmcsd {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
This patch series adds Device tree data for the EMIF sdram controllers in OMAP5 and LPDDR2 memory devices in OMAP5-evm board. Testing: - Boot tested on OMAP5430 evm. - Built EMIF as a module. Changes from v2: * Rebased on top of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts * Addressed few other comments from Benoit. Lokesh Vutla (3): ARM: dts: omap5-evm: Fix size of memory defined for EVM ARM: dts: omap5: EMIF device tree data for OMAP5 boards ARM: dts: omap5-evm: LPDDR2 memory device details for EVM arch/arm/boot/dts/omap5-evm.dts | 13 +- arch/arm/boot/dts/omap5.dtsi | 22 ++ arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 + 3 files changed, 101 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index ead74c8..790bb2a 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -474,5 +474,27 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ emif1: emif@0x4c00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif1;
+ phy-type= 2; /* DDR PHY type: Intelli PHY */
+ reg = 0x4c00 0x400;
+ interrupts = 0 110 0x4;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+ emif2: emif@0x4d00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif2;
+ phy-type= 2; /* DDR PHY type: Intelli PHY */
+ reg = 0x4d00 0x400;
+ interrupts = 0 111 0x4;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 11 +
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 +
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 88d3d9b8..8722c15 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap5.dtsi
+/include/ samsung_k3pe0e000b.dtsi
/ {
model = TI OMAP5 EVM board;
@@ -140,3 +141,13 @@
mcbsp3 {
status = disabled;
};
+
+emif1 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
+
+emif2 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
diff --git a/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
new file mode 100644
index 000..9657a5c
--- /dev/null
+++ b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Timings and Geometry for Samsung K3PE0E000B memory part
+ */
+
+/ {
+ samsung_K3PE0E000B: lpddr2 {
+ compatible = Samsung,K3PE0E000B,jedec,lpddr2-s4;
+ density = 4096;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_samsung_K3PE0E000B_533MHz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 5;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+
+ timings_samsung_K3PE0E000B_266MHz: lpddr2-timings@1 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 2;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
+
+nand@0,0 {
+reg = 0 0 0; /* CS0, offset 0 */
+nand-bus-width = 16;
+nand-ecc-mode = none;
+
+gpmc,sync-clk = 0;
+gpmc,cs-on = 0;
+gpmc,cs-rd-off = 36;
+gpmc,cs-wr-off = 36;
+gpmc,adv-on = 6;
+gpmc,adv-rd-off = 24;
+gpmc,adv-wr-off = 36;
+gpmc,we-off = 30;
+gpmc,oe-off = 48;
+gpmc,access = 54;
+gpmc,rd-cycle = 72;
+gpmc,wr-cycle = 72;
+gpmc,wr-access = 30;
+gpmc,wr-data-mux-bus = 0;
+
+#address-cells = 1;
+#size-cells = 1;
+
Can you take the timings (for example) from arago tree. The timings is tested
in am335x-evm
So the timings can be directly used to populate GPMC timings. Timings can
found at
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
[...]
+static int gpmc_probe_dt(struct platform_device *pdev)
Can you take care of the following section mismatch.
WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
from the function gpmc_probe_dt() to the function .init.text:gpmc_nand_init().
Sore, both fixed for v4.
[...]
+
+val = of_get_nand_ecc_mode(child);
+if (val = 0)
+gpmc_nand_data-ecc_opt = val;
This will fail for BCH. Index of soft_bch is 5 also don't have selection
option between for BCH4 BCH8 also.
Can you use the of_property_read_u32 (as done early) to pass the ecc selection
from dt file. This will help selection of BCH4 BCH8 ecc options.
Hmm. Shouldn't we rather teach of_get_nand_ecc_mode() that two modes and
bring the enum in sync?
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAPDSS: enable DSS for Panda SDP with devtree
Hi, OMAPDSS device tree support is still some way in the future. Tony has requested to get DSS working for Panda SDP boards with DT kernel, so that we'll have fully working boards with DT. This series makes a few hacks to get a working display on OMAP4 Panda and SDP boards. The idea is to setup the omapdss with the non-DT method, creating the omapdss devices and passing platform data to them. This setup code is called from board-generic for Panda and SDP boards. There was one problem with this approach: omapdss cannot get regulators using the omapdss's names fro the regulators. Thus there's a hack patch to get the regulators using the OMAP4 native regulator names, thus circumventing the problem. Tony, if these look good, how do you want to merge these? There are three parts here, and I think they can be merged independently if so wished: * .dts changes for the pinmuxing (2 patches) * dss-common.c and board-generic.c changes (3 patches) * DSS hack for the regulators (1 patch) If one of those parts is missing, DSS won't start with DT kernel, but otherwise there shouldn't be any problems. So to avoid conflicts, I suggest that you take the first two parts, and I'll merge the DSS hack via omapdss tree. Tomi Ricardo Neri (2): ARM/dts: omap4-panda: Add pinmux configuration for HDMI ARM/dts: omap4-sdp: Add pinmux configuration for HDMI Tomi Valkeinen (4): OMAPDSS: HACK: look for regulators with omap4 names OMAP: panda: move display init from board file to dss-common.c OMAP: omap4sdp: move display init from board file to dss-common.c OMAP: board-generic: enable DSS for panda sdp boards arch/arm/boot/dts/omap4-panda-a4.dts | 17 ++ arch/arm/boot/dts/omap4-panda.dts| 18 ++ arch/arm/boot/dts/omap4-pandaES.dts |9 + arch/arm/boot/dts/omap4-sdp-es23plus.dts | 17 ++ arch/arm/boot/dts/omap4-sdp.dts | 18 ++ arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-4430sdp.c | 157 + arch/arm/mach-omap2/board-generic.c | 10 ++ arch/arm/mach-omap2/board-omap4panda.c | 68 +--- arch/arm/mach-omap2/dss-common.c | 276 ++ arch/arm/mach-omap2/dss-common.h | 14 ++ drivers/video/omap2/dss/dsi.c|8 + drivers/video/omap2/dss/hdmi.c |4 + 13 files changed, 394 insertions(+), 224 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts create mode 100644 arch/arm/boot/dts/omap4-sdp-es23plus.dts create mode 100644 arch/arm/mach-omap2/dss-common.c create mode 100644 arch/arm/mach-omap2/dss-common.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] OMAP: omap4sdp: move display init from board file to dss-common.c
Device tree support for omapdss is still some way in the future. In an
effort to get a minimal DSS support for DT enabled kernel on selected
OMAP4 boards, we'll go for a temporary solution: We will call the same
non-DT omapdss setup code for OMAP4 SDP and Pandaboards from
board-generic.c, thus enabling DSS for those boards.
This patch moves the display setup code from board-4430sdp.c to
dss-common.c. dss-common.c will be called by the board-4430sdp.c when
running on non-DT kernel, and by board-generic.c when running on DT
enabled kernel.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 157 +---
arch/arm/mach-omap2/dss-common.c| 172 +++
arch/arm/mach-omap2/dss-common.h|2 +
3 files changed, 175 insertions(+), 156 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..8ce98ae 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -37,9 +37,6 @@
#include plat/usb.h
#include plat/mmc.h
#include omap4-keypad.h
-#include video/omapdss.h
-#include video/omap-panel-nokia-dsi.h
-#include video/omap-panel-picodlp.h
#include linux/wl12xx.h
#include linux/platform_data/omap-abe-twl6040.h
@@ -48,17 +45,13 @@
#include hsmmc.h
#include control.h
#include common-board-devices.h
+#include dss-common.h
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
-#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO 40
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
@@ -607,154 +600,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static struct nokia_dsi_panel_data dsi1_panel = {
- .name = taal,
- .reset_gpio = 102,
- .use_ext_te = false,
- .ext_te_gpio= 101,
- .esd_interval = 0,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct omap_dss_device sdp4430_lcd_device = {
- .name = lcd,
- .driver_name= taal,
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = dsi1_panel,
- .phy.dsi= {
- .module = 0,
- },
- .channel= OMAP_DSS_CHANNEL_LCD,
-};
-
-static struct nokia_dsi_panel_data dsi2_panel = {
- .name = taal,
- .reset_gpio = 104,
- .use_ext_te = false,
- .ext_te_gpio= 103,
- .esd_interval = 0,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct omap_dss_device sdp4430_lcd2_device = {
- .name = lcd2,
- .driver_name= taal,
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = dsi2_panel,
- .phy.dsi= {
-
- .module = 1,
- },
- .channel= OMAP_DSS_CHANNEL_LCD2,
-};
-
-static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct omap_dss_device sdp4430_hdmi_device = {
- .name = hdmi,
- .driver_name = hdmi_panel,
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = sdp4430_hdmi_data,
-};
-
-static struct picodlp_panel_data sdp4430_picodlp_pdata = {
- .picodlp_adapter_id = 2,
- .emu_done_gpio = 44,
- .pwrgood_gpio = 45,
-};
-
-static void sdp4430_picodlp_init(void)
-{
- int r;
- const struct gpio picodlp_gpios[] = {
- {DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- DLP POWER ON},
- {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
- DLP EMU DONE},
- {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
- DLP PWRGOOD},
- };
-
- r = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
- if (r)
- pr_err(Cannot request PicoDLP GPIOs, error %d\n, r);
-}
-
-static int sdp4430_panel_enable_picodlp(struct
[PATCH 3/6] OMAPDSS: HACK: look for regulators with omap4 names
Normally the omapdss driver gets the regulators using the regulator
names assigned for omapdss. However, in an effort to get a minimal DSS
support for DT enabled kernel on selected boards, we will add omapdss
devices and platform data the old way even for DT kernel. This causes
the problem that omapdss cannot find the regulators using omapdss's
regulator names.
This patch creates a temporary workaround for DSI and HDMI by trying to
get the regulators also using native OMAP4 regulator names.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |8
drivers/video/omap2/dss/hdmi.c |4
2 files changed, 12 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d64ac38..738f3c4 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1753,6 +1753,10 @@ int dsi_pll_init(struct platform_device *dsidev, bool
enable_hsclk,
vdds_dsi = regulator_get(dsi-pdev-dev, vdds_dsi);
+ /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
+ if (IS_ERR(vdds_dsi))
+ vdds_dsi = regulator_get(dsi-pdev-dev, VCXIO);
+
if (IS_ERR(vdds_dsi)) {
DSSERR(can't get VDDS_DSI regulator\n);
return PTR_ERR(vdds_dsi);
@@ -4972,6 +4976,10 @@ static int __init dsi_init_display(struct
omap_dss_device *dssdev)
vdds_dsi = regulator_get(dsi-pdev-dev, vdds_dsi);
+ /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
+ if (IS_ERR(vdds_dsi))
+ vdds_dsi = regulator_get(dsi-pdev-dev, VCXIO);
+
if (IS_ERR(vdds_dsi)) {
DSSERR(can't get VDDS_DSI regulator\n);
return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index a48a7dd..deaeb6c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -340,6 +340,10 @@ static int __init hdmi_init_display(struct omap_dss_device
*dssdev)
reg = devm_regulator_get(hdmi.pdev-dev, vdda_hdmi_dac);
+ /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
+ if (IS_ERR(reg))
+ reg = devm_regulator_get(hdmi.pdev-dev, VDAC);
+
if (IS_ERR(reg)) {
DSSERR(can't get VDDA_HDMI_DAC regulator\n);
return PTR_ERR(reg);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] OMAP: board-generic: enable DSS for panda sdp boards
Call the non-DT omapdss setup code from board-generic if the board is omap4-panda or omap4-sdp. This will give us working omapdss for those boards when using DT kernel. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/board-generic.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 601ecdf..8f5f21c 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -21,6 +21,7 @@ #include common.h #include common-board-devices.h +#include dss-common.h #if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)) #define intc_of_init NULL @@ -40,6 +41,15 @@ static void __init omap_generic_init(void) omap_sdrc_init(NULL, NULL); of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); + + /* +* HACK: call display setup code for selected boards to enable omapdss. +* This will be removed when omapdss supports DT. +*/ + if (of_machine_is_compatible(ti,omap4-panda)) + omap4_panda_display_init_of(); + else if (of_machine_is_compatible(ti,omap4-sdp)) + omap_4430sdp_display_init_of(); } #ifdef CONFIG_SOC_OMAP2420 -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] OMAP: panda: move display init from board file to dss-common.c
Device tree support for omapdss is still some way in the future. In an
effort to get a minimal DSS support for DT enabled kernel on selected
OMAP4 boards, we'll go for a temporary solution: We will call the same
non-DT omapdss setup code for OMAP4 SDP and Pandaboards from
board-generic.c, thus enabling DSS for those boards.
This patch moves the display setup code from board-omap4panda.c to
dss-common.c. dss-common.c will be called by the board-omap4panda.c when
running on non-DT kernel, and by board-generic.c when running on DT
enabled kernel.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/board-omap4panda.c | 68 +
arch/arm/mach-omap2/dss-common.c | 104
arch/arm/mach-omap2/dss-common.h | 12
4 files changed, 118 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/mach-omap2/dss-common.c
create mode 100644 arch/arm/mach-omap2/dss-common.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..fb38a9b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -279,4 +279,4 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
-obj-y += common-board-devices.o twl-common.o
+obj-y += common-board-devices.o twl-common.o
dss-common.o
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..ab505a2 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -36,26 +36,22 @@
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
-#include video/omapdss.h
#include common.h
#include plat/usb.h
#include plat/mmc.h
-#include video/omap-panel-tfp410.h
#include soc.h
#include hsmmc.h
#include control.h
#include mux.h
#include common-board-devices.h
+#include dss-common.h
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET62
#define GPIO_WIFI_PMENA43
#define GPIO_WIFI_IRQ 53
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
static struct ti_st_plat_data wilink_platform_data = {
@@ -409,68 +405,6 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
-/* Display DVI */
-#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-
-/* Using generic display panel */
-static struct tfp410_platform_data omap4_dvi_panel = {
- .i2c_bus_num= 3,
- .power_down_gpio= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct omap_dss_device omap4_panda_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = dvi,
- .driver_name= tfp410,
- .data = omap4_dvi_panel,
- .phy.dpi.data_lines = 24,
- .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
- .channel= OMAP_DSS_CHANNEL_LCD2,
-};
-
-static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct omap_dss_device omap4_panda_hdmi_device = {
- .name = hdmi,
- .driver_name = hdmi_panel,
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = omap4_panda_hdmi_data,
-};
-
-static struct omap_dss_device *omap4_panda_dss_devices[] = {
- omap4_panda_dvi_device,
- omap4_panda_hdmi_device,
-};
-
-static struct omap_dss_board_info omap4_panda_dss_data = {
- .num_devices= ARRAY_SIZE(omap4_panda_dss_devices),
- .devices= omap4_panda_dss_devices,
- .default_device = omap4_panda_dvi_device,
-};
-
-static void __init omap4_panda_display_init(void)
-{
-
- omap_display_init(omap4_panda_dss_data);
-
- /*
-* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-* later have external pull up on the HDMI I2C lines
-*/
- if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
- omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
- else
- omap_hdmi_init(0);
-
- omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
static void omap4_panda_init_rev(void)
{
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
new file mode 100644
index 000..62d7b15
--- /dev/null
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -0,0 +1,104 @@
+/*
+ *
[PATCH 2/6] ARM/dts: omap4-sdp: Add pinmux configuration for HDMI
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-sdp-es23plus.dts | 17 +
arch/arm/boot/dts/omap4-sdp.dts | 18 ++
2 files changed, 35 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-sdp-es23plus.dts
diff --git a/arch/arm/boot/dts/omap4-sdp-es23plus.dts
b/arch/arm/boot/dts/omap4-sdp-es23plus.dts
new file mode 100644
index 000..b4a40ff
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-sdp-es23plus.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ omap4-sdp.dts
+
+/* SDP boards with 4430 ES2.3+ or 4460 have external pullups on SCL SDA */
+dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ ;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5b7e04f..7b14bb3 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -124,6 +124,8 @@
dmic_pins
mcbsp1_pins
mcbsp2_pins
+ dss_hdmi_pins
+ tpd12s015_pins
;
uart2_pins: pinmux_uart2_pins {
@@ -194,6 +196,22 @@
0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT
| MODE0 */
;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP |
MODE 0 */
+ 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP |
MODE 0 */
+ 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP |
MODE 0 */
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x22 0x3/* gpmc_a17.gpio_41 OUTPUT | MODE3 */
+ 0x48 0x3/* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
+ 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
+ ;
+ };
};
i2c1 {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM/dts: omap4-panda: Add pinmux configuration for HDMI
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-panda-a4.dts | 17 +
arch/arm/boot/dts/omap4-panda.dts| 18 ++
arch/arm/boot/dts/omap4-pandaES.dts |9 +
3 files changed, 44 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts
b/arch/arm/boot/dts/omap4-panda-a4.dts
new file mode 100644
index 000..75466d2
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ omap4-panda.dts
+
+/* Pandaboard Rev A4+ have external pullups on SCL SDA */
+dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ ;
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index e8f927c..8060f5b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -65,6 +65,8 @@
twl6040_pins
mcpdm_pins
mcbsp1_pins
+ dss_hdmi_pins
+ tpd12s015_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -92,6 +94,22 @@
0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT
| MODE0 */
;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP |
MODE 0 */
+ 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP |
MODE 0 */
+ 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP |
MODE 0 */
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x22 0x3/* gpmc_a17.gpio_41 OUTPUT | MODE3 */
+ 0x48 0x3/* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
+ 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts
b/arch/arm/boot/dts/omap4-pandaES.dts
index d4ba43a..73bc1a6 100644
--- a/arch/arm/boot/dts/omap4-pandaES.dts
+++ b/arch/arm/boot/dts/omap4-pandaES.dts
@@ -22,3 +22,12 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* PandaboardES has external pullups on SCL SDA */
+dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ ;
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ARM/dts: omap4-panda: Add pinmux configuration for HDMI
Hi Ricardo,
On 2012-11-05 15:14, Tomi Valkeinen wrote:
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-panda-a4.dts | 17 +
arch/arm/boot/dts/omap4-panda.dts| 18 ++
arch/arm/boot/dts/omap4-pandaES.dts |9 +
3 files changed, 44 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
Ricardo, I modified this and the other dts patch to add new .dts files
for the board revisions with external pull on the SCL/SDA lines. Can you
verify that these are correct?
Tomi
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts
b/arch/arm/boot/dts/omap4-panda-a4.dts
new file mode 100644
index 000..75466d2
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ omap4-panda.dts
+
+/* Pandaboard Rev A4+ have external pullups on SCL SDA */
+dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ ;
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index e8f927c..8060f5b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -65,6 +65,8 @@
twl6040_pins
mcpdm_pins
mcbsp1_pins
+ dss_hdmi_pins
+ tpd12s015_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -92,6 +94,22 @@
0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT
| MODE0 */
;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP |
MODE 0 */
+ 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP |
MODE 0 */
+ 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP |
MODE 0 */
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x22 0x3/* gpmc_a17.gpio_41 OUTPUT | MODE3 */
+ 0x48 0x3/* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
+ 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts
b/arch/arm/boot/dts/omap4-pandaES.dts
index d4ba43a..73bc1a6 100644
--- a/arch/arm/boot/dts/omap4-pandaES.dts
+++ b/arch/arm/boot/dts/omap4-pandaES.dts
@@ -22,3 +22,12 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* PandaboardES has external pullups on SCL SDA */
+dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ ;
+};
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Nov 5, 2012, at 1:22 AM, Grant Likely wrote: On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Assuming that we do work on a DT object format, and that the runtime resolution mechanism is approved, then I agree that this part of the capebus patches can be dropped and the functionality assumed by generic DT core. The question is that this will take time, with no guarantees that this would be acceptable from the device tree maintainers. So I am putting them in the CC list, to see what they think about it. This is actually exactly the direction I want to go with DT, which the ability to load supplemental DT data blobs from either a kernel module or userspace using the firmware loading infrastructure. g. Hi Grant, That's pretty much our use case. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 16;
+ nand-ecc-mode = none;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 36;
+ gpmc,cs-wr-off = 36;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 24;
+ gpmc,adv-wr-off = 36;
+ gpmc,we-off = 30;
+ gpmc,oe-off = 48;
+ gpmc,access = 54;
+ gpmc,rd-cycle = 72;
+ gpmc,wr-cycle = 72;
+ gpmc,wr-access = 30;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
Can you take the timings (for example) from arago tree. The timings is
tested in am335x-evm
So the timings can be directly used to populate GPMC timings. Timings can
found at
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
[...]
+static int gpmc_probe_dt(struct platform_device *pdev)
Can you take care of the following section mismatch.
WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
from the function gpmc_probe_dt() to the function
.init.text:gpmc_nand_init().
Sore, both fixed for v4.
[...]
+
+ val = of_get_nand_ecc_mode(child);
+ if (val = 0)
+ gpmc_nand_data-ecc_opt = val;
This will fail for BCH. Index of soft_bch is 5 also don't have selection
option between for BCH4 BCH8 also.
Can you use the of_property_read_u32 (as done early) to pass the ecc
selection
from dt file. This will help selection of BCH4 BCH8 ecc options.
Hmm. Shouldn't we rather teach of_get_nand_ecc_mode() that two modes and
bring the enum in sync?
ecc_opt is for selecting different ecc layout and not for selecting ecc mode.
In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout
OMAP_ECC_HAMMING_CODE_HW_ROMCODE
OMAP_ECC_BCH4_CODE_HW
OMAP_ECC_BCH8_CODE_HW
So selection of ecc layout data should come from DT not ecc mode.
Thanks
Avinash
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/10] ARM: dts: AM33XX: Add device tree data
On Mon, Nov 05, 2012 at 16:15:40, AnilKumar, Chimata wrote: Add device tree date for GPIO based various drivers matrix keypad, volume keys, push buttons and use leds accross three AM33XX devices viz EVM, BeagleBone and Starter Kit. To make it functional this series also adds pinctrl data for all the GPIOs used by various drivers. In this series only default state pinmux/conf settings are added because of sleep/idle state pinctrl values are not available. These patches are based on linux-omap-dt:for_3.8/dts tree and these My bad, small correction in this statement, these patches apply cleanly on linux-omap-dt:for_3.8/dts tree with the below two patches. http://www.spinics.net/lists/arm-kernel/msg204872.html http://www.spinics.net/lists/arm-kernel/msg204873.html Thanks AnilKumar were tested on am33xx devices according to added functionality. AnilKumar Ch (10): ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk arch/arm/boot/dts/am335x-bone.dts | 44 +++ arch/arm/boot/dts/am335x-evm.dts | 63 +++ arch/arm/boot/dts/am335x-evmsk.dts | 84 3 files changed, 191 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/8] i2c: omap: Fix the revision register read
On Mon, Nov 05, 2012 at 05:53:36PM +0530, Shubhrajyoti D wrote:
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.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v3: Fix the comments.
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..5c6f538 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_35300x3C
-#define OMAP_I2C_REV_ON_3630_44300x40
+#define OMAP_I2C_REV_ON_2430 0x0036
+#define OMAP_I2C_REV_ON_3430_35300x003C
+#define OMAP_I2C_REV_ON_3630 0x0040
+#define OMAP_I2C_REV_ON_4430_PLUS0x5042
/* 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;
unsignedb_hw:1; /* bad h/w fixes */
unsignedreceiver: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_00
+#define OMAP_I2C_SCHEME_11
+
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 omap1/3/2 Offset 4 is IE Reg the bit [15:14] 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);
+ 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;
+
Re: [PATCHv3 3/8] i2c: omap: remove the dtrev
On Mon, Nov 05, 2012 at 05:53:38PM +0530, Shubhrajyoti D wrote:
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 shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
v3: remove the scheme from the commments.
todo: remove the dtrev from hwmod etc.
drivers/i2c/busses/i2c-omap.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 737d843..5f0c06c 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 = 10; /* default to 10 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);
@@ -1230,8 +1228,8 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_unuse_clocks;
}
- dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, adap-nr,
- dev-dtrev, major, minor, dev-speed);
+ dev_info(dev-dev, bus %d rev%d.%d at %d kHz\n, adap-nr,
+ major, minor, dev-speed);
of_i2c_register_devices(adap);
--
1.7.5.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv3 8/8] i2c: omap: cleanup the sysc write
Hi,
On Mon, Nov 05, 2012 at 05:53:43PM +0530, Shubhrajyoti D wrote:
Currently after the reset the sysc is written with hardcoded values.
The patch reads the sysc register and writes back the same value
after reset.
- Some unnecessary rev checks can be optimised.
- Also due to whatever reason the hwmod flags are changed
we will not reset the values.
- In some of the cases the minor values of the 2430 register
is different(0x37) in that case the autoidle setting may be missed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 25f1564..a09acdc 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -302,7 +302,11 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
unsigned long timeout;
+ u16 sysc;
+
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
+ sysc = omap_i2c_read_reg(dev, OMAP_I2C_SYSC_REG);
+
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
omap_i2c_read_reg(dev, OMAP_I2C_CON_REG)
@@ -324,22 +328,8 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
}
/* SYSC register is cleared by the reset; rewrite it */
- if (dev-rev == OMAP_I2C_REV_ON_2430) {
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
-SYSC_AUTOIDLE_MASK);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
- dev-syscstate = SYSC_AUTOIDLE_MASK;
- dev-syscstate |= SYSC_ENAWAKEUP_MASK;
- dev-syscstate |= (SYSC_IDLEMODE_SMART
- __ffs(SYSC_SIDLEMODE_MASK));
- dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
- __ffs(SYSC_CLOCKACTIVITY_MASK));
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
- dev-syscstate);
- }
not sure if this will work. What about the first time you call reset() ?
won't SYSC just contain the reset values ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv3 8/8] i2c: omap: cleanup the sysc write
On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote: -dev-syscstate); - } not sure if this will work. What about the first time you call reset() ? won't SYSC just contain the reset values ? No actually the hwmod sets the value. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 8/8] i2c: omap: cleanup the sysc write
Hi, On Mon, Nov 05, 2012 at 07:53:45PM +0530, Shubhrajyoti wrote: On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote: - dev-syscstate); -} not sure if this will work. What about the first time you call reset() ? won't SYSC just contain the reset values ? No actually the hwmod sets the value. ahaaa, ok good. Let's get an Ack from Benoit, then. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 5, 2012, at 1:22 AM, Grant Likely wrote: On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Assuming that we do work on a DT object format, and that the runtime resolution mechanism is approved, then I agree that this part of the capebus patches can be dropped and the functionality assumed by generic DT core. The question is that this will take time, with no guarantees that this would be acceptable from the device tree maintainers. So I am putting them in the CC list, to see what they think about it. This is actually exactly the direction I want to go with DT, which the ability to load supplemental DT data blobs from either a kernel module or userspace using the firmware loading infrastructure. g. Hi Grant, That's pretty much our use case. Regards Good. I'm about 80% though putting together a project plan of what is required to implement this. I'll post it for RFC shortly. I would appreciate feedback and help on flushing out the design. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
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.be...@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@4030 {
+ 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.
On OMAP the OCMC RAM is always clocked and doesn't need any special
clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only.
Isn't it same on AMXX ?
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.
Sure. I was just trying to see why AMXX is different with OMAP here.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On Sunday 04 November 2012 08:55 PM, Bedia, Vaibhav wrote:
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 hvaib...@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 hvaib...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@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.
Thanks for information.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
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.be...@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@4030 {
+ 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.
OK. I was just comparing the OCMC RAM on OMAP which is always
clocked and hence didn't need any of the above.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] ARM: OMAP2+: mailbox: Add an API for flushing the FIFO
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
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.
OK
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] ARM: OMAP2+: mailbox: Add support for AM33XX
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
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.
Thanks for the pointer. Nice to see mailbox is getting moved
to drivers directory.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] ARM: OMAP3+: move smartreflex-class3.c to drivers/power/avs
smartreflex.c now resides in drivers/power/avs directory,
but class driver is in mach-omap2. High time we move it
to drivers/power/avs.
This series *does not* try to fix VP/VC to be voltage
regulator OR introduce a new OMAP voltage regulator series.
Instead, it purely tries to do the minimal changes needed
to move code to drivers/power/avs as a start.
Baseline: k.org v3.7-rc4
Testing: Platform: beagle XM C1 (3730)
while [ 1 ]
do
echo -n 0 /sys/kernel/debug/smartreflex/smartreflex_core/autocomp
date
echo -n 1 /sys/kernel/debug/smartreflex/smartreflex_core/autocomp
done
Screen capture after the series(RFC): on inductor L5 (VDD2 - core):
https://plus.google.com/photos/112464029509057661457/albums/5715034179943520193/5802619719180530114
RFC: http://marc.info/?t=13510287673r=1w=2
Nishanth Menon (6):
PM / AVS / OMAP: move Kconfig definition of smartreflex to avs
directory
ARM: OMAP: voltage: remove duplicate header definitions
ARM: OMAP: voltage: move voltdm_reset to platform_data header
ARM: OMAP: SmartReflex: provide SoC integration API for VP
ARM: OMAP: SmartReflex: use pr_warn instead of pr_warning
PM / AVS / OMAP: move Smartreflex-class3 driver to power/avs
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/sr_device.c|5
arch/arm/mach-omap2/voltage.h |4 ---
arch/arm/plat-omap/Kconfig | 31
drivers/power/avs/Kconfig | 31
drivers/power/avs/Makefile |1 +
.../power/avs}/smartreflex-class3.c| 20 +
drivers/power/avs/smartreflex.c|2 ++
include/linux/platform_data/voltage-omap.h |1 +
include/linux/power/smartreflex.h | 18
10 files changed, 73 insertions(+), 41 deletions(-)
rename {arch/arm/mach-omap2 = drivers/power/avs}/smartreflex-class3.c (75%)
Regards,
Nishanth Menon
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: OMAP: SmartReflex: provide SoC integration API for VP
SoC integration of SmartReflex AVS block is varied. Some use
Voltage Processor for a hardware loop in certain OMAP SoC (called
hardware loop), while others have just the AVS block without
hardware loop automatic calibration mechanism for AVS block
to talk through. So provide the Voltage Processor API
to allow for SmartReflex class drivers to use the same.
NOTE: SmartReflex class 3 mode of operation mandates VP APIs
so, refuse to enable AVS driver if corresponding APIs are
not available.
As part of this change, remove the inclusion of voltage.h
which is no longer needed as smartreflex.h includes
linux/platform_data/voltage-omap.h which contain relevant
definitions used here.
Acked-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c | 16 +---
arch/arm/mach-omap2/sr_device.c |5 +
drivers/power/avs/smartreflex.c |2 ++
include/linux/power/smartreflex.h| 18 ++
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 1da8f03..7ccf57f 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -12,7 +12,6 @@
*/
#include linux/power/smartreflex.h
-#include voltage.h
static int sr_class3_enable(struct omap_sr *sr)
{
@@ -23,15 +22,26 @@ static int sr_class3_enable(struct omap_sr *sr)
__func__, sr-name);
return -ENODATA;
}
+ if (!sr-soc_ops.vp_enable) {
+ pr_warn(%s: no VP enable available. Cannot enable %s!!\n,
+ __func__, sr-name);
+ return -EINVAL;
+ }
- omap_vp_enable(sr-voltdm);
+ sr-soc_ops.vp_enable(sr-voltdm);
return sr_enable(sr-voltdm, volt);
}
static int sr_class3_disable(struct omap_sr *sr, int is_volt_reset)
{
+ if (!sr-soc_ops.vp_disable) {
+ pr_warn(%s: no VP disable available. Cannot disable %s!!\n,
+ __func__, sr-name);
+ return -EINVAL;
+ }
sr_disable_errgen(sr-voltdm);
- omap_vp_disable(sr-voltdm);
+
+ sr-soc_ops.vp_disable(sr-voltdm);
sr_disable(sr-voltdm);
if (is_volt_reset)
voltdm_reset(sr-voltdm);
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index f8217a5..6aac2c7 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -139,6 +139,11 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void
*user)
sr_data-enable_on_init = sr_enable_on_init;
+ if (sr_data-voltdm-vp) {
+ sr_data-soc_ops.vp_enable = omap_vp_enable;
+ sr_data-soc_ops.vp_disable = omap_vp_disable;
+ }
+
pdev = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
NULL, 0, 0);
if (IS_ERR(pdev))
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 24768a2..32a9e3e 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -920,6 +920,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-pdev = pdev;
sr_info-srid = pdev-id;
sr_info-voltdm = pdata-voltdm;
+ sr_info-soc_ops.vp_enable = pdata-soc_ops.vp_enable;
+ sr_info-soc_ops.vp_disable = pdata-soc_ops.vp_disable;
sr_info-nvalue_table = pdata-nvalue_table;
sr_info-nvalue_count = pdata-nvalue_count;
sr_info-senn_mod = pdata-senn_mod;
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index 4a496eb..203fc64 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -143,6 +143,21 @@
#define OMAP3430_SR_ERRWEIGHT 0x04
#define OMAP3430_SR_ERRMAXLIMIT0x02
+/**
+ * struct omap_sr_soc_ops - SoC specific APIs
+ * @vp_enable: Voltage Processor enable
+ * @vp_disable:Voltage Processor disable
+ *
+ * SmartReflex AVS module integration tends to be SoC
+ * variant. some are integrated with modules like
+ * Voltage Processor (VP), while, some SoC integration
+ * donot use VP. Provide that variance here.
+ */
+struct omap_sr_soc_ops {
+ void (*vp_enable)(struct voltagedomain *voltdm);
+ void (*vp_disable)(struct voltagedomain *voltdm);
+};
+
struct omap_sr {
char*name;
struct list_headnode;
@@ -165,6 +180,7 @@ struct omap_sr {
u32 senp_mod;
u32 senn_mod;
void __iomem*base;
+ struct omap_sr_soc_ops soc_ops;
};
/**
@@ -268,6 +284,7 @@ struct omap_sr_nvalue_table {
* @nvalue_table: table containing the efuse offsets and nvalues
*
[PATCH 2/6] ARM: OMAP: voltage: remove duplicate header definitions
remove duplicate definitions which are already present in linux/platform_data/voltage-omap.h Acked-by: Jean Pihet j-pi...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/voltage.h |3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 7283b7e..af9d469 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -142,7 +142,6 @@ extern void omap3xxx_voltagedomains_init(void); extern void am33xx_voltagedomains_init(void); extern void omap44xx_voltagedomains_init(void); -struct voltagedomain *voltdm_lookup(const char *name); void voltdm_init(struct voltagedomain **voltdm_list); int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct powerdomain *pwrdm); int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void *user), @@ -150,7 +149,5 @@ int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void *user), int voltdm_for_each_pwrdm(struct voltagedomain *voltdm, int (*fn)(struct voltagedomain *voltdm, struct powerdomain *pwrdm)); -int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); void voltdm_reset(struct voltagedomain *voltdm); -unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: OMAP: SmartReflex: use pr_warn instead of pr_warning
Minor cleanup to use the preferred pr_warn
Acked-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 7ccf57f..23d45f9 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -18,8 +18,8 @@ static int sr_class3_enable(struct omap_sr *sr)
unsigned long volt = voltdm_get_voltage(sr-voltdm);
if (!volt) {
- pr_warning(%s: Curr voltage unknown. Cannot enable %s\n,
- __func__, sr-name);
+ pr_warn(%s: Curr voltage unknown. Cannot enable %s\n,
+ __func__, sr-name);
return -ENODATA;
}
if (!sr-soc_ops.vp_enable) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] PM / AVS / OMAP: move Kconfig definition of smartreflex to avs directory
Don't see why the source should be in drivers/power/avs, but not config option Acked-by: Jean Pihet j-pi...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/plat-omap/Kconfig | 22 -- drivers/power/avs/Kconfig | 22 ++ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 82fcb20..b49cff3 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -47,28 +47,6 @@ config OMAP_DEBUG_LEDS depends on OMAP_DEBUG_DEVICES select LEDS_CLASS -config POWER_AVS_OMAP - bool AVS(Adaptive Voltage Scaling) support for OMAP IP versions 12 - depends on POWER_AVS (ARCH_OMAP3 || ARCH_OMAP4) PM - select POWER_SUPPLY - help - Say Y to enable AVS(Adaptive Voltage Scaling) - support on OMAP containing the version 1 or - version 2 of the SmartReflex IP. - V1 is the 65nm version used in OMAP3430. - V2 is the update for the 45nm version of the IP used in OMAP3630 - and OMAP4430 - - Please note, that by default SmartReflex is only - initialized and not enabled. To enable the automatic voltage - compensation for vdd mpu and vdd core from user space, - user must write 1 to - /debug/smartreflex/sr_X/autocomp, - where X is mpu_iva or core for OMAP3. - Optionally autocompensation can be enabled in the kernel - by default during system init via the enable_on_init flag - which an be passed as platform data to the smartreflex driver. - config POWER_AVS_OMAP_CLASS3 bool Class 3 mode of Smartreflex Implementation depends on POWER_AVS_OMAP TWL4030_CORE diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig index 2a1008b..466a391 100644 --- a/drivers/power/avs/Kconfig +++ b/drivers/power/avs/Kconfig @@ -10,3 +10,25 @@ menuconfig POWER_AVS AVS is also called SmartReflex on OMAP devices. Say Y here to enable Adaptive Voltage Scaling class support. + +config POWER_AVS_OMAP + bool AVS(Adaptive Voltage Scaling) support for OMAP IP versions 12 + depends on POWER_AVS (ARCH_OMAP3 || ARCH_OMAP4) PM + select POWER_SUPPLY + help + Say Y to enable AVS(Adaptive Voltage Scaling) + support on OMAP containing the version 1 or + version 2 of the SmartReflex IP. + V1 is the 65nm version used in OMAP3430. + V2 is the update for the 45nm version of the IP used in OMAP3630 + and OMAP4430 + + Please note, that by default SmartReflex is only + initialized and not enabled. To enable the automatic voltage + compensation for vdd mpu and vdd core from user space, + user must write 1 to + /debug/smartreflex/sr_X/autocomp, + where X is mpu_iva or core for OMAP3. + Optionally autocompensation can be enabled in the kernel + by default during system init via the enable_on_init flag + which an be passed as platform data to the smartreflex driver. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: OMAP: voltage: move voltdm_reset to platform_data header
Move voltdm_reset to include/linux/platform_data/voltage-omap.h Acked-by: Jean Pihet j-pi...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/voltage.h |1 - include/linux/platform_data/voltage-omap.h |1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index af9d469..0665f21 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -149,5 +149,4 @@ int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void *user), int voltdm_for_each_pwrdm(struct voltagedomain *voltdm, int (*fn)(struct voltagedomain *voltdm, struct powerdomain *pwrdm)); -void voltdm_reset(struct voltagedomain *voltdm); #endif diff --git a/include/linux/platform_data/voltage-omap.h b/include/linux/platform_data/voltage-omap.h index 5be4d5d..4eb3d43 100644 --- a/include/linux/platform_data/voltage-omap.h +++ b/include/linux/platform_data/voltage-omap.h @@ -36,4 +36,5 @@ int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); +void voltdm_reset(struct voltagedomain *voltdm); #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
